51–60 of 200 posts
Earlier quoted context omitted.
surprise! it's been there for decades: https://en.wikipedia.org/wiki/Web_SQL_Database
It was there for a decade: https://caniuse.com/sql-storage
Slight point of confusion: that page says: > These components were initially released for public beta with version 3.40 and will tentatively be made API-stable with the 3.41 release, pending community feedback. But the most recent release of SQLite is 3.46.1 (from 2024-08-13) Presumably they are now "API-stable" but the page hasn't been updated yet. It would be great if the SQLite team published an official npm packa…
Though it seems to be somewhat limited. I couldn't even check what version it has, since sqlite_version() was missing. Version in the repository [1] is 3.38.1, which is from quite a ways ago.
At the moment DuckDB web shell can't load SQLite extension, since that hasn't been released for yesterday's 1.1.2. Earlier version does work using recently updated WASM edition. That can be extended with spatial including GDAL, vector search etc [2]. Making your own "SQL web shell" wasn't too hard, though docs weren't quite complete enough for me.
[1] https://github.com/duckdb/sqlite_scanner/blob/main/src/sqlit... [2] https://github.com/duckdb/duckdb-wasm/releases/tag/v1.29.0
How long until we see WebAssembly/WebGPU become a platform independent choice for deploying server side code as well?
disclaimer: I work there
Earlier quoted context omitted.
1.3MB seems perfectly reasonable in a modern web app, especially since it will be cached after the first visit to the site. 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…
A megabyte here, a megabyte there, pretty soon you’re talking about a really heavyweight app.
Is there any hope of that happening? Instead of abstracting and over specifying sqlite, can the spec just specify a version of the SQLite API browsers should support and roll the version periodically?
How long until we see WebAssembly/WebGPU become a platform independent choice for deploying server side code as well?
I wasn't able to tell from a quick look through the page: could someone help me understand the use cases here? More specifically, would this be able to be a "replacement" for indexedDB? Does the data persist, or do I need to keep the sqlite file in the filesytemAPI (or indexedDB/localstorage) myself?
> Specific Goals of this Project
> Insofar as possible, support persistent client-side storage using available JS APIs. As of this writing, that includes the Origin-Private FileSystem (OPFS) and (very limited) storage via the window.localStorage and window.sessionStorage backend.
Earlier quoted context omitted.
It was there for a decade: https://caniuse.com/sql-storage
I wonder why it was unmaintained/dropped. Was there something wrong with it, and if so, would that also apply to this kind of wasm implementation?
From the latest spec [1]:
> The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path.
[1]: https://www.w3.org/TR/webdatabase/
This won't be a problem for wasm SQLite because it isn't a standard being shipped by browsers, just another dependency.
As a general question, in what scenarios is it more beneficial to send the full DB and let the browser handle the queries? Maybe phrased a better way - when would I use this to improve a user experience over the traditional server-hosted db model?
I can even do Sqlite's full text search without downloading the entire FTS database. Just most of it, if the search term is short enough.
So after downloading from the official downloads page and stripping away all the mjs files and "bundler-friendly" files, a minimal sqlite wasm dependency will be about 1.3MB. 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.
It's pretty compressible at least, sqlite3.js+wasm are 1.3MB raw but minifying the JS and then compressing both files with Brotli gets them down to 410KB.
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.