3 ms·

SQLite on WASM[0] is absolutely what you are looking for. There is also “Absurd SQL”[1] which extends it to use indexedDB as a VFS for storage allowing proper a

SQLite on WASM[0] is absolutely what you are looking for. There is also “Absurd SQL”[1] which extends it to use indexedDB as a VFS for storage allowing proper atomic transactions and not loading the whole thing into memory. Combine it with the various JavaScript ORMs and you have a nice developer UX. I’m waiting for someone with more time than myself to build a syncing feature on top of SQLites Sessions[2] so that changes locally are synced back to the server. (Feel like I’m a cheer leader posting this comment every week) 0: https://sql.js.org/ https://sql.js.org/ 1: https://github.com/jlongster/absurd-sql https://github.com/jlongster/absurd-sql 2: https://www.sqlite.org/sessionintro.html https://www.sqlite.org/sessionintro.html

steve_adams_86 5y ago
Would this suffer from the overhead of using WASM, both to make the calls and to transfer the data back to the UI thread? I'm not sure but I expect it would depend on your use cases. High frequency i/o of small data might be slower compared to low frequency i/o of very large data. Mind you I'm working off of a cursory understanding of WASM performance issues from 2 years ago. Maybe this has changed a lot, or my understanding was incorrect in the first place. Do you know much about this?
vaughan 5y ago
Absurd is really cool. I've always thought it would be great to have an SQL db implemented in native JS though. With the database running in the same process as your app, you could store native JS Objects of your table rows in the cache, which you could bind events to. So if you modify a row in a table in the db, events could be instantly propagated to the UI. Haven't thought it through fully yet. SQL is also a bit cumbersome for things like deeply nested data, hierarchies, trees, graphs which a lot of client-side application state ends up being. Sessions looks cool!
dotancohen 5y ago
> (Feel like I’m a cheer leader posting this comment every week) I haven't seen it yet, so thank you! And in the name of others like me who haven't seen it yet, keep cheering please.

steve_adams_86 5y ago

Would this suffer from the overhead of using WASM, both to make the calls and to transfer the data back to the UI thread? I'm not sure but I expect it would depend on your use cases. High frequency i/o of small data might be slower compared to low frequency i/o of very large data. Mind you I'm working off of a cursory understanding of WASM performance issues from 2 years ago. Maybe this has changed a lot, or my understanding was incorrect in the first place. Do you know much about this?

vaughan 5y ago

Absurd is really cool. I've always thought it would be great to have an SQL db implemented in native JS though. With the database running in the same process as your app, you could store native JS Objects of your table rows in the cache, which you could bind events to. So if you modify a row in a table in the db, events could be instantly propagated to the UI. Haven't thought it through fully yet. SQL is also a bit cumbersome for things like deeply nested data, hierarchies, trees, graphs which a lot of client-side application state ends up being. Sessions looks cool!

dotancohen 5y ago

> (Feel like I’m a cheer leader posting this comment every week) I haven't seen it yet, so thank you! And in the name of others like me who haven't seen it yet, keep cheering please.