For an in-browser app, that seems a bit much but of course wasm runs in other places these days where it might make more sense.
For an in-browser app, that seems a bit much but of course wasm runs in other places these days where it might make more sense.
Also worth considering parsing of wasm is significantly faster than JS (unfortunately couldn't find the source for this claim, there is at lease one great article on the topic)
https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_A...
If you’re just storing user preferences, obviously don’t download SQLite for your web app just to do that… but if you’re doing something that benefits from a full database, don’t fret so much about 1MB that you go try to reinvent the wheel for no reason.
If the other comment is correct, then it won’t even be 1.3MB on the network anyways.
I played around with warm sqlite too. That was really nice but I decided against it due to the fact that it was totally unsupported.
Also, WASI is very far from answer (so far). The SQLite amalgamation builds fine for WASI but concurrency is an unsolved issue.
I had to build a VFS from scratch to get my Wasm based SQLite driver into a usable shape.
https://github.com/ncruces/go-sqlite3/blob/main/vfs/README.m...
In a regular compiler/linker scenario it would just be a static compilation. Here we have a JS app and WASM library.
Adding 400 for such a high quality piece of DB actually borders reasonability.
And makes me think: what the hell are frontend devs thinking!? Multiple MB's in JS for a news website. Hundreds of KB's for HTML. It's totally unreasonable.
They're thinking, "adding [some fraction of existing total payload] for such a high quality [feature] actually borders reasonability". Wash. Rinse. Repeat.
The pending 3.47 release has some build-side tweaks which enable a user to strip it down to "just the basics," but we've not yet been able to get it smaller than about 25-30% less than it otherwise is:
cd ext/wasm
make barebones=1 ; # requires GNU Make and the Emscripten SDK
Doing that requires building it yourself - there are no plans to publish deliverables built that way.The build process also supports including one's own C code, which could hypothetically be used to embed an application and the wasm part of the library (as distinct from the JS part) into a single wasm file. Its primary intended usage is to add SQLite extensions which are not part of the standard amalgamation build.
> Or is there a way to prune it having the used API surface?
Not with the provided JS pieces. Those have to expose essentially the whole C library, so they will not be pruned from the wasm file.
However, you could provide your own JS bindings which only use a small subset of the API, and Emscripten is supposedly pretty good about stripping out C-side code which neither explicitly exported nor referenced anywhere. You'd be on your own - that's not something we'll integrate into the canonical build process - but we could provide high-level support, via the project's forum, for folks taking that route.
Context makes all the difference here. If you're considering a big chunk of size for a relational database engine, you need to ask: are you making a complex application, or a normal web page? If it's the latter, then it's not reasonable at all.
And anything that makes the HTML itself that big is almost certainly bloat, not "high quality", and shouldn't be used in any context.
High quality software is something I rarely see nowadays when browsing "modern" websites.