665K sqlite3.wasm
306K sqlite3.wasm.gz (-54% compared to uncompressed)
266K sqlite3.wasm.br (-13% compared to gz, -60% compared to uncompressed)So, "hefty" seems like a bit of an exaggeration to me. All other things equal, lighter is always better, but 266KB for all the functionality SQLite offers isn't that bad, IMO.
On the topic of caching, since SQLite is (intentionally or not) going to be setting an example with their docs and demos[0], I would suggest that SQLite should demonstrate the industry best practices with regards to caching as well. Static assets like WASM and JavaScript should be served with a very high cache duration, and the name of the asset should include a hash of the asset. This way, the site maintainer can update the HTML to reference the new SQLite bundles by the new hash whenever they upload new versions, and browsers will immediately request the new versions, but they will otherwise instantly load the cached version after the first visit whenever there isn't a new version.
doesn't seem possible to do without leaking data
> so it is effectively a one time penalty for a given website
which shows that I already acknowledged the demise of cross-origin caching.
Each website the user visits that uses this library has to pay a 266KB penalty once, which isn't that bad. (Well, once, unless the site developer decides to upgrade the library, then the penalty applies once more, but that's expected behavior.)
That can't work on the documentation site because the wasm file is being served from the Fossil SCM and fossil cannot cache resources which are fetched by name because a new version may be checked in at any given moment (they're currently updated very often: https://sqlite.org/wasm/finfo/jswasm/sqlite3.wasm). Fossil can hypothetically cache resources which are fetched by hash, but that's not a feasible way for us to maintain the documentation on that site.
They're not relevant to the wasm/js deliverables. They're an implementation detail of the server which happens to be serving the related documentation. If you have specific verbiage which you feel would improve the docs in this regard, please feel free to send it. i'm likely to miss most responses in HN, so please use email (stephan at sqlite dot org) or the sqlite forum: https://sqlite.org/forum.
i think you'll find that many high-end websites often download more than a megabyte of CSS and JS code. imdb.com home page: 2.13mb transferred for 6.odd mb data. drive.google.com: 4.75mb transferred for nearly 15mb of data(!!!).
266kb doesn't even register nowadays for app-centric pages.
That is interesting, but the repository you're looking at is a Fossil SCM repo and the wasm file is being served directly from it. Fossil does the compression transparently and doesn't support brotli. (Edit: i'll investigate whether brotli compression would be interesting for us to add to fossil.)
However, the sqlite project will not be hosting shared copies of the wasm/js files for use by arbitrary 3rd-party sites. It's up to each site to host their own (and even build their own if they need to customize the build), so they're free to use whatever compression they like.
Sqlite updates are solid and as far as I know, do not break your code.
Almost every major SQLite release has a few minor releases after it which fix bug and regressions, including things like queries returning the wrong result.
s/millions/billions/g. It is widely believed to be either the single most widely-deployed piece of software in the world, or maybe second behind zlib (we have no way of being sure).
If every site embeds their own version, the application developers can choose their own version that runs the same across every browser. Or even compile it themselves if they want, so they can use extensions. The download size is unfortunate but remember - unlike javascript, wasm bytecode loads almost instantly. Having a 250k wasm module is more like having a 250k image on your site than 250k of javascript. (Though it might still affect time-to-interactive depending on how the site is built)
Nope. The downside is that some applications that want to use new one would have to download it, and the remaining 90% could use builtin one
Once you start giving special privileges to specific wasm binaries, the floodgates are open for a hundred different vendors to demand the same special treatment because 10% of websites use their .wasm blob. And then you've created a barrier to entry for competition. Nobody wins in the long run except a couple of your friends.
Browser behaviour changes (and even breaks) way often than SQLite does.
That applies to the C code. The wasm code is still in beta, and won't see a public beta release until 3.40 is released in November. See the notes about API stability here: <https://sqlite.org/wasm/doc/trunk/api-index.md>