What is the difference?

Writing goes first into your local storage, then gets send to your remote storage, rather than vice versa. Same with searching, search local storage rather than remote one. Everything would load faster, latency would be less, could use it offline and so on.

On the other hand, Notion wouldn't have full control anymore, usage stats might be hard to get when some users are offline, and so on, so unlikely Notion would do such a thing. Certainly their investors wouldn't like it either.

(I work at Notion)

> Writing goes first into your local storage, then gets send to your remote storage

We do this already; writes are queued in SQLite or IndexedDB first and then asynchronously batched and streamed to the server. Our apps (Mac/Windows/iOS/Android) cache pages locally, and all platforms search a subset of documents locally in addition to server-side search. We’re actively improving this area as well.

Can you shed some light on why something like Google Docs is able to operate this way but not experience the lag or latency that your app does?

Typing latency in Notion is generally worse than Google Docs because our renderer & input handling is less efficient than Docs. Docs has substantial lead over Coda, Notion, Dropbox Paper, etc because they use a custom layout engine for presentation that is entirely separate from the input surface. Notion, Paper, etc instead use the Web’s built-in but flawed API for rich text editing called “ContentEditable”. In ContentEditable, generally the rendered output DOM nodes are also the input surface. This is much less expensive to implement, but comes with a bunch of limitations and constraints.

Thank you for the response, it was very illuminating. Is the reason you choose the built-in API instead of building a custom layout engine just due to complexity?

The latency. Accessing browser storage is slow, live syncing is slow.

Maybe ask the Google Docs team? They seem to have low latency online-first doc management figured out.