Sqlite3 WebAssembly

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?

Mozilla refused to support it because then every implementation would have simply used SQLite, which would have promoted any implementation details to a de facto standard. (Even caniuse erroneously describes the feature as "allows SQLite database queries".)

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.

i have a feeling that it set back the web by a decade

https://x.com/chxy/status/1822858746307170640

Did they really assume that they were going to be able to _restandardize_ SQL? No wonder IndexDB is hot useless garbage.

The standardization issues around SQL already exist, are already widely known, and where common workarounds are already in practice. It's also an open source project that could have _easily_ incorporated compatibility code for this specific use case anyways.

They made blind fealty to process more important than the outcome to end users.

What a waste.

> Did they really assume that they were going to be able to _restandardize_ SQL?

The core issue was not the SQL, but the underlying storage engine.

Microsoft's office doc formats aside, standards bodies, as a general rule, require that a standard be built around multiple independent, conformant implementations. WebSQL did not measure up there because all vendors implementing it chose the only viable option they had for the underlying storage: SQLite.

I've seen and understood that in hardware. I'm less convinced it's reasonable in this context. If there wasn't an _independent_ implementation it might barely make sense, but given that sqlite exists separately and can be installed separately, this is more of a "package management" or "system library access" problem than it is one of actual standardization by an independent body.

Which if you standardized this generic interface you could have multiple independent database engines available not just ones that are SQL based, although, SQL in particular was readily available through SQLite, and would clearly be exceptionally popular.

Huge miss when organizations stick the the routine rather then take an opportunity to explore and examine new ways forward. Meanwhile everyone is being held hostage by V2 to V3 manifest changes by _one_ vendor.

> It's also an open source project that could have _easily_ incorporated compatibility code for this specific use case anyways.

As I pointed out in a separate comment:

Richard Hipp committed to creating and maintaining a flag in SQLite that would force SQLite to use whatever subset of SQL the WebSQL people settled on for their API. That would have of course worked independently of the SQLite version. (He also offered to write the SQL part of the spec.)

https://news.ycombinator.com/item?id=41860067

It was such a lost opportunity. I'm sure the SQLite guys would still be happy to do the work, but there certainly isn't any momentum on the browser side anymore.