Oooff, 266 KB is a hefty price to pay. I really wish WebSQL would have won out over IndexedDB, because I would have loved to have been able to build libraries on top of that instead of the headache IndexedDB is.
"Hefty"... for an asset that can easily be cached long term, so it is effectively a one time penalty for a given website, and many web apps will load images larger than this. Certainly, just about any marketing/product page will load more bytes than this in the form of images, let alone videos.
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.
> 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
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.
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.
coder543|3 years ago
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.
[0]: https://sqlite.org/wasm/doc/trunk/demo-123.md
sgbeal|3 years ago
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.
fooey|3 years ago
doesn't seem possible to do without leaking data
sgbeal|3 years ago
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.