> I literally don't get why sqlite3, only, and specifically, still isn't usable by JS in 2022.
It is now :). We provide 4 separate APIs, from the lowest-level 1-to-1 C-via-WASM bindings to one quite similar to sql.js, plus all of the low-level pieces necessary to create your own.
Historical note: those of us within the sqlite project had never paid any attention to the unfortunately-named WebAssembly (which has been dubbed "neither web nor assembly") because it didn't seem to hold any relevance for us. It wasn't until April-ish 2022 that we took a look at it, and have been working on "officially" bringing it to the browser world ever since. Even so, folks have been producing WASM bindings of it for a number of years now, and the relative ease of doing so (sqlite3.c requires no changes whatsoever to compile to WASM) is possibly (i opine) why we didn't get requests from users to do this sooner.
Sidebar: someone is going to ask "if it's so easy, why did you need 6 months to get it out the door?" Fair question: we had some very specific technical goals which i'm not at liberty to elaborate on, and only a single developer to put on it. Plus, WASM was a completely new tech for us, so there was much learning and experimentation involved.
No, WASM applications aren't a built-in universal web API, they are a huge payload that needs to be sent, anew (thanks to per-site caching in modern browsers), that solves the problem I don't understand exists in the first place.
It's great that you went "what if we compile to WASM?" but this is something that's not on you: this is something that should have been on browser vendors to just _expose_ because every browser ships with sqlite baked in already. Every user already has it, they just can't use it.
> ... but this is something that's not on you: this is something that should have been on browser vendors to just _expose_ because every browser ships with sqlite baked in already.
Richard (the sqlite lead) has often described his definition of "freedom" as "being able to take care of yourself," a philosophy he lives and breathes with his software. The sqlite project providing wasm builds for folks, and the materials they need to make their own custom builds, is directly in line with that. Depending on every browser vendor to play along in sync is, quite frankly, a lost cause.
> ... they are a huge payload ...
If you truly believe that 500kb of content is "huge" nowadays, i challenge you to go watch (via the browser dev tools) how much stuff your favorite websites are serving. (HN, of course, is a spartan exception to the rule.) Hit any given news or social media site and you'll get at least a meg of content, most of which is constantly replaced (so caching it is of little use). Hit IMDB and you'll get 2+mb (compressed). Hit GDrive and you'll get 4.75mb compressed (nearly 15mb uncompressed!). i just hit www.google.com, which has a long history of minimalism, and it transferred 881kb (2.21mb uncompressed).
By comparison, 500kb-1mb (uncompressed) isn't even worthy of honorable mention.
> Depending on every browser vendor to play along in sync is, quite frankly, a lost cause.
Very true, but that is not mutually exclusive with not understanding why it's a lost cause. There's literally three browser vendors, and of those, really only one of them needs to go "fuck it, sqlite now has an API" and the other two kind of don't have a lot of choice but to follow suit. It's a Chrome world right now.
We could have easily done this, we chose not to. Why? (and you probably don't have the answer to that. I don't know if anyone does)
> There's literally three browser vendors, and of those, really only one of them needs to go "fuck it, sqlite now has an API" and the other two kind of don't have a lot of choice but to follow suit. It's a Chrome world right now.
In the general case, admittedly true. Note, however, that the Chrome folks have no say-so in the shape of this particular sqlite API, with the tiny exception that they are not willing to create a 100% synchronous API for OPFS, which complicates the sqlite-side development of that one small part of the API considerably[^1]. The shape/flavor/whatever we'd like to call it of the sqlite JS/WASM APIs is left 100% to the project members' discretion. If Chrome dies tomorrow, this API is still a thing, it will just have severely reduced client-side persistence options until the next hypothetical vendor creates one, at which point we'd latch onto that one.
[1] = When we consider that async APIs exist largely to account for network latency, and OPFS _has no latency_ beyond the local storage device, OPFS's interface being async is, IMHO, a design flaw stemming from the misled assumption of "it's on the web ergo it must be async" (and i've told them that in emails and meetings). Based on our testing metrics, the performance of the OPFS sqlite layer would increased by at least 30% if it had a 100% synchronous API to work with, as it tends to waste anywhere from the low-30s to mid-40s percentage points of its time waiting at cross-thread communication boundaries.
It is now :). We provide 4 separate APIs, from the lowest-level 1-to-1 C-via-WASM bindings to one quite similar to sql.js, plus all of the low-level pieces necessary to create your own.
Historical note: those of us within the sqlite project had never paid any attention to the unfortunately-named WebAssembly (which has been dubbed "neither web nor assembly") because it didn't seem to hold any relevance for us. It wasn't until April-ish 2022 that we took a look at it, and have been working on "officially" bringing it to the browser world ever since. Even so, folks have been producing WASM bindings of it for a number of years now, and the relative ease of doing so (sqlite3.c requires no changes whatsoever to compile to WASM) is possibly (i opine) why we didn't get requests from users to do this sooner.
Sidebar: someone is going to ask "if it's so easy, why did you need 6 months to get it out the door?" Fair question: we had some very specific technical goals which i'm not at liberty to elaborate on, and only a single developer to put on it. Plus, WASM was a completely new tech for us, so there was much learning and experimentation involved.