> The tools that it turns out were a bad idea will die. And those that are good will thrive.
We saw that happen with WebSQL vs IndexedDB. A well-designed API (with a syntax every decent webdev knows) vs a bullshit spec (ohai callback hell FOR DOING A SIMPLE FUCKING SORT AND GROUP), and the bullshit won.
All because Microsoft wouldn't break down and embed SQLite into their browser like everyone else did for WebSQL. It's actually really disappointing.
IndexedDB could be built on top of WebSQL as a shim... you can't really do the reverse so easily. It's really disappointing... WebSQL/SQLite with a template string builder interface would be amazing. (I know it's an ES6 thing).
I will say, that I do want what's on deck for ES6/7 (2015/2016) to make it into the browsers... async/await is such a useful feature.
Sorry, I had thought Mozilla had WebSQL with SQLite... I know chrome/safari supported it at least.. I thought MS was the main holdout there. It looks like there's a Firefox plugin for it though.
Hmm... would it be possible, using Promises, to create a sorta-shim, you give it a SQL query and a callback function.
The shim does asynchronously all the stuff a DB engine does (most people are going to use "SELECT cola,colb,colc FROM x WHERE foo=bar and baz=quux ORDER BY cola ASC GROUP BY colb" and nothing more complex anyway), then tracks all the stuff it needs to do in its own promise tracker. Once all is done, it assembles the returned row(s), stores them and calls the callback.
The biggest problem I see is locking as all the crap is async so you'd need some sort of locking and query ordering to maintain data consistency.
If you don't really need true locking pessimism it's more possible... There are actual SQL engines in JS though.
Using a single queue to run queries through would be relatively easy to do... a stage 1 analysis of what collections you need to query could then push the query into one of several queues for pipeline requests.
It would be interesting, but I don't mind IndexDB (or localStorage for that matter) enough to really bother with it.
1. The spec died, because it didn't get two independent implementations.
Everyone merely wrapped sqlite, which meant sites could rely on being bug-compatible with all the sqlite weirdnesses (e.g. column type "floating point" parses as integer column type), and making any future upgrades or fixes of sqlite a Web-wide version of pain of upgrading IE6 used for an intranet site.
2. IndexedDB API is a pain to use, because it's designed to be used directly. In the spirit of extensible web manifesto, it's a low-level primitive for JS libraries to build convenient higher-level abstractions on top of.
It's like an "assembly" of storage. It's supposed to enable building higher-level databases on top, so you can have SQL or NoSQL with whatever dialect you want, without burdening the platform with it. Use Dexie, localForage, ydn or such.
We saw that happen with WebSQL vs IndexedDB. A well-designed API (with a syntax every decent webdev knows) vs a bullshit spec (ohai callback hell FOR DOING A SIMPLE FUCKING SORT AND GROUP), and the bullshit won.