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..."
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.
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.
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.
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.
11 comments
[ 2.9 ms ] story [ 38.7 ms ] threadThanks for sharing. Love it.
https://jlongster.com/future-sql-web
Show HN is for sharing your personal work and has special rules.
https://news.ycombinator.com/newsfaq.html
Why keep IndexedDB in the loop then?
tldr: Mozilla's fault