←back to thread

Sqlite3 WebAssembly

(sqlite.org)
506 points whatever3 | 5 comments | | HN request time: 0.001s | source
Show context
simonw ◴[] No.41851270[source]
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 package bundling the WASM version, could be a neat distribution mechanism for them. (UPDATE: They do, see replies to this post.)

My favourite version of SQLite-in-WASM remains the Pyodide variant, which has been around since long before the official SQLite implementation. If you use Pyodide you get a WASM SQLite for free as part of the Python standard library - I use that for https://lite.datasette.io/ and you can also try it out on https://pyodide.org/en/stable/console.html

    import sqlite3
    print(sqlite3.connect(':memory:').execute(
        'select sqlite_version()'
    ).fetchall())
That returns 3.39.0 from 2022-06-25 so Pyodide could do with a version bump. Looks like it inherits that version from emscripten: https://github.com/emscripten-core/emscripten/blob/main/tool...
replies(5): >>41851515 #>>41851565 #>>41851901 #>>41852552 #>>41853076 #
sgbeal ◴[] No.41853076[source]
> Presumably they are now "API-stable" but the page hasn't been updated yet.

That's correct. i'll try my best to remember to update that reference the next time i'm back on the computer.

> It would be great if the SQLite team published an official npm package

Not a chance. We publish only vanilla JS and adamantly refuse to go down the rabit hole of supporting out-of-language tools (none of which any of our project members use). We support an "officially sanctioned" npm build, maintained by Thomas Steiner, but do not actively develop for any JS frameworks.

Direct support for any given framework (npm included) would give the impression that we endorse that framework, and endorsement of third-party projects is something we actively avoid.

replies(1): >>41853135 #
rezonant ◴[] No.41853135[source]
> We publish ONLY vanilla JS and adamantly refuse to go down rabit hole of supporting the frameworks du jour

A bit confused at this, NPM is just a package manager / distribution mechanism, not a framework. Totally fair if you don't want to publish for all the package managers, though for Javascript there's only a few that are relevant. NPM has been around for a decade.

replies(1): >>41853181 #
1. sgbeal ◴[] No.41853181[source]
> A bit confused at this, NPM is just a package manager / distribution mechanism, not a framework

It's an out-of-language packaging/distribution framework (and it's not the only one). It's not part of the JS standards.

My comments above have been edited to reframe our stance on npm and frameworks in general.

replies(2): >>41853749 #>>41853977 #
2. rezonant ◴[] No.41853749[source]
I don't think there will ever be a package manager dictated by the Ecmascript standards.
replies(1): >>41854172 #
3. samatman ◴[] No.41853977[source]
I think the communication barrier here is that in JavaScript, framework very distinctly means things like React, Vue, Angular, and so on. It definitely does not refer to projects like Node/npm/Bun/Deno, those are toolchains, sometimes called ecosystems for obscure reasons.

If you changed the word "framework" to "toolchain" in your post I think it would make a lot more sense to people.

replies(1): >>41854657 #
4. syndicatedjelly ◴[] No.41854172[source]
Then ES will continue to remain an outlier among major language implementations
5. sgbeal ◴[] No.41854657[source]
> If you changed the word "framework" to "toolchain" in your post I think it would make a lot more sense to people.

Fair point but the edit window has passed ;). For the sake of clarity for those still following along: "framework," in the context of my above comments, includes any non-formally-standardized tools or APIs which are built atop the standardized core.