3 ms·
We can finally get rid of IndexedDB, and it's only 900KiB extra bundle size!
by stefan_ 4y ago
We can finally get rid of IndexedDB, and it's only 900KiB extra bundle size!
- sgbeal 4y ago> and it's only 900KiB extra bundle size! Depending on how it's compiled, yes. It can be as large as 2MB when built with no optimizations.
- mwint 4y agoFor production use, presumably you’d use an optimized binary
- sgbeal 4y ago> For production use, presumably you’d use an optimized binary That particular one is built with -Oz (optimized for the smallest size). Development itself is done with -O0 (no optimizations) because the compile time difference is something like 2-3 seconds vs 15-20.
- josephg 4y ago330kb over the wire with brotli. Thats sizable, but definitely usable in a heavier web app. Honestly thats really impressive given it includes an entire SQL engine.
- sgbeal 4y ago> 330kb over the wire with brotli. Thats sizable, but definitely usable in a heavier web app. My almost-most-used website (boardgamegeek.com) currently serves 500-odd kb of minified CSS and 2MB of minified JS. That is to say: in the context of modern websites, 300-800kb arguably rates as a mere pittance.
- sgbeal 4y ago> We can finally get rid of IndexedDB, Not quite yet: indexeddb can be stored persistently whereas wasm-side sqlite dbs cannot (unless they're stored _in_ an indexeddb). Someday the JS filesystem APIs may offer such a thing, but right now there is no standard filesystem-like API which offers client-side persistence. The only half-workaround for the time being is the ability to upload and download the db image (something both sql.js and sqlite3's fiddle support).
- CRConrad 4y agoStore it in a really big cookie? ;-)
- mycall 4y agoAre you suggesting IndexedDB has a limited life remaining?