6 ms·
What practical benefit would that really have over just using your choice of SQL engine with wasm, though?
by CorpusCalcium 9y ago
What practical benefit would that really have over just using your choice of SQL engine with wasm, though?
- virtualwhys 9y agoI don't know, is my choice of SQL engine (sqlite) via WASM a realistic solution? How does one compile sqlite to WASM, and how is this made available to the end user? sql.js[1] is a pure JS implementation of sqlite and it weighs a ton (2.6MB) compared to browser supplied native sqlite. Ideally the user doesn't have to pay the price of downloading a large binary (on top of already large SPA). [1] https://github.com/kripken/sql.js/ https://github.com/kripken/sql.js/
- CorpusCalcium 9y agoSure, but that's the JS version. wasm is meant to produce smaller, less resource-intensive versions (and there is a wasm version of sqlite I believe [1]). I'd much rather see CDN and caching tech improve along with other low-level tools such as wasm and CSS Houdini to let us build whatever we'd like. I can see that being better for devs than waiting for vendors to standardize a watered-down spec for each feature we might want like SQL (and there's a lot of them). [1] https://github.com/mandel59/sqlite-wasm https://github.com/mandel59/sqlite-wasm
- virtualwhys 9y agoAgreed, browser vendors may not always have the best interests of developers in mind. If WASM approach can deliver a relatively small binary with better-than-js performance, then that may be a viable alternative, thanks.