> 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.
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?
> 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.