3 ms·

That's super interesting, I've read your previous comments about adopting SQLite. With WASM SQLite nearly ready and the origin privet file system API becoming a

That's super interesting, I've read your previous comments about adopting SQLite. With WASM SQLite nearly ready and the origin privet file system API becoming available, do you expect to adopt that in the browser? And if so would you then align the mobile app closer to the web app by sharing that code? A while back I was working on a notes app, tying to go the single codebase route with Capacitor. The biggest problem I found was with the text selection cursor on iOS. It sits on a layer above all other elements and even appears outside of scrolling overflow, so it would appear over toolbars, really nasty UX. Did you come up against that? As far as I could tell the only solutions were to have a native UI and only use with webview for the editor (that immediately meant writing the UI twice), or create a custom carrot and selection indicator (nasty!).

jitl 4y ago
> do you expect to adopt that [SQLite via Origin-private filesystem] in the browser? And if so would you then align the mobile app closer to the web app by sharing that code? I'm interested in WASM+SQLite+OPFS. We currently use native SQLite on iOS, Android, as well as in our Electron app for macOS and Windows. WASM+SQLite+OPFS means we can use the same SQLite schema + caching code in the browser that we use on those other platforms, which would align web more with our native apps. We won't go the other way, and try to replace native SQLite with WASM+SQLite+OPFS on iOS or Android, because we have native code on those platforms that also talks to the same DB; on those platforms we've also moved some sync logic from webview into native land so we can sync in the background when the webview may be paused or destroyed. We want to be more native, not more web. We might consider replacing the native SQLite in Electron with WASM+SQLite+OPFS if the performance looks good, since we don't have any Electron-side code that interacts with the DB. > The biggest problem I found was with the text selection cursor on iOS. It sits on a layer above all other elements and even appears outside of scrolling overflow, so it would appear over toolbars, really nasty UX. Did you come up against that? This only occurs inside an `overflow: scroll` container; it doesn't happen if the body itself scrolls. Here's a possibly-related Webkit bug (opened in 2014): https://bugs.webkit.org/show_bug.cgi?id=138201 https://bugs.webkit.org/show_bug.cgi?id=138201 That means you can overcome with some clever structuring/styling of the DOM, which is how Dropbox Paper for mobile works IIRC. We also found a different work-around in 2018 but it costs too much performance. So, we still have this issue in Notion because our DOM is too tricky to rework to solve this mostly-unimportant issue. > create a custom carrot and selection indicator (nasty!). Google Docs does this and it sucks and feels super janky. None of the nice editing gestures work nicely in Docs. Instead of smoothly moving the cursor around via the long-touch -> trackpad gesture, the cursor jumps around in Docs. I'd rather have some weird render issue with the caret drawing over a toolbar at very specific scroll positions, than force my users to use a jank re-implementation of the native selection UX.
- samwillis 4y ago
  Thanks for the detailed response. I've also seen your contributions to CRDT discussions here and it seems Notion is doing lots of super interesting things at the forefront of "local first" collaborative development. (It's a pity you only hire in the US!) Yes, I found the "overflow: auto" issue with WebKit, unfortunately even scrolling the whole page doesn't solve the cursor above a "position: fixed" toolbar... hopefully one day Safari on iOS will catch up!

jitl 4y ago

> do you expect to adopt that [SQLite via Origin-private filesystem] in the browser? And if so would you then align the mobile app closer to the web app by sharing that code? I'm interested in WASM+SQLite+OPFS. We currently use native SQLite on iOS, Android, as well as in our Electron app for macOS and Windows. WASM+SQLite+OPFS means we can use the same SQLite schema + caching code in the browser that we use on those other platforms, which would align web more with our native apps. We won't go the other way, and try to replace native SQLite with WASM+SQLite+OPFS on iOS or Android, because we have native code on those platforms that also talks to the same DB; on those platforms we've also moved some sync logic from webview into native land so we can sync in the background when the webview may be paused or destroyed. We want to be more native, not more web. We might consider replacing the native SQLite in Electron with WASM+SQLite+OPFS if the performance looks good, since we don't have any Electron-side code that interacts with the DB. > The biggest problem I found was with the text selection cursor on iOS. It sits on a layer above all other elements and even appears outside of scrolling overflow, so it would appear over toolbars, really nasty UX. Did you come up against that? This only occurs inside an `overflow: scroll` container; it doesn't happen if the body itself scrolls. Here's a possibly-related Webkit bug (opened in 2014): https://bugs.webkit.org/show_bug.cgi?id=138201 https://bugs.webkit.org/show_bug.cgi?id=138201 That means you can overcome with some clever structuring/styling of the DOM, which is how Dropbox Paper for mobile works IIRC. We also found a different work-around in 2018 but it costs too much performance. So, we still have this issue in Notion because our DOM is too tricky to rework to solve this mostly-unimportant issue. > create a custom carrot and selection indicator (nasty!). Google Docs does this and it sucks and feels super janky. None of the nice editing gestures work nicely in Docs. Instead of smoothly moving the cursor around via the long-touch -> trackpad gesture, the cursor jumps around in Docs. I'd rather have some weird render issue with the caret drawing over a toolbar at very specific scroll positions, than force my users to use a jank re-implementation of the native selection UX.

samwillis 4y ago
Thanks for the detailed response. I've also seen your contributions to CRDT discussions here and it seems Notion is doing lots of super interesting things at the forefront of "local first" collaborative development. (It's a pity you only hire in the US!) Yes, I found the "overflow: auto" issue with WebKit, unfortunately even scrolling the whole page doesn't solve the cursor above a "position: fixed" toolbar... hopefully one day Safari on iOS will catch up!