> Thats interesting, so it will be an "official" WASM JS binding for SQLite?
That's not guaranteed/official yet but it has been discussed and seems to be where we're headed. In the end it's Richard's decision, though, not mine. (That said, i would like to see that happen but won't be soul-crushed if it doesn't because creating a wasm build of sqlite is _so easy_ to do that any project can create their own with little effort.)
It's currently in the sqlite3 trunk. After configuring the tree, run "make fiddle" or (cd ext/fiddle; make), though the latter approach requires GNU make, not some under-powered make-wannabe. (The top-level makefile is compatible with Lesser Makes.)
Edit: it requires emscripten and ext/fiddle/index.md provides an overview of how to get it going.
> If you are building an "official" WASM JS binding have you considered doing something similar to absurd SQL in order to achieve atomic persistence?
Not until we have JS APIs which are built for that type of thing. Absurd's approach is an interesting proof of concept but is aptly named. Absurd is a stopgap measure which will, with any luck, "soon" be obsoleted by ... how to put this... "less absurd" alternatives ;).
Thats interesting, so it will be an "official" WASM JS binding for SQLite? Is it available anywhere?
> With any luck, we'll have widespread JS-native persistent storage for sqlite within the next couple of/few years
If you are building an "official" WASM JS binding have you considered doing something similar to absurd SQL in order to achieve atomic persistence?