Duplicate: https://news.ycombinator.com/item?id=28156831

Doesn't look like your project Tim? (so the title shouldn't include Show HN). The blog post [0] from James seems to be a better link.

https://jlongster.com/future-sql-web

If you're not the author, you should not post it as "Show HN".

Show HN is for sharing your personal work and has special rules.

https://news.ycombinator.com/newsfaq.html

I love absurd ideas like this because they sort of push the notion of what is possible. Some of my favorite projects have started out with "Crazy ideas but..."

Thanks for sharing. Love it.

That's actually not that absurd. It provides a familiar way to deal with data in scenarios where using IndexedDB alone would be difficult at the very least.

I feel a bit stupid but I don't understand what his project does, so if someone is kind enough to ELI5 I would be grateful.

IndexedDB is a dumpster fire we all got screwed over with by Mozilla after they declared "inelegant developer aesthetics" of WebSQL and killed real life usable SQL engine https://hacks.mozilla.org/2010/06/beyond-html5-database-apis... This is how we ended with a cow shit IndexedDB nobody uses without some middle layers. This is one of those middle layers making using SQL database client side actually viable, by hiding IndexedDB as deep as possible.

tldr: Mozilla's fault

My understanding:

    SQLite: SQL -> SQLite C query engine -> POSIX Filesystem

    Absurd-SQL: SQL -> (WASM) SQLite C query engine -> "filesystem" shim code -> IndexedDB

So if I get it, he talks directly to SQLite through WASM because it's faster than IndexedDB.

Why keep IndexedDB in the loop then?

It is what available for persistent storage. IndexedDB run queries very slow but throughput is good enough so rather big chunks of data stored in single cell to offset latency. And IndexedDB is just one storage backend. Author says he experimented with webkitFileSystem but didn't matched IndexedDBs througput. Point of this project is storage medium abstracted so in future it will be replaced with what's better.

When you're running a webapp it's the primary cross-platform storage facility provided. It sounds like he's doing some buffering and bulk writes to optimize the use of indexeddb rather than just passing through each query to try to mask some of the slowness of the end storage.