The filesystem API was also nixed, so now people take to implementing fake filesystems on IndexDB, and implementing fake-SQL on top of IndexDB. On top of that, IndexDB performance isn't as great as it should be.

With something like SQLite, I think it's fine to take a super mature platform and retroactively extract a specification from it (while 99% of the people just keep the original implementation), than to start with a crap spec and try to make it mature.

IndexDB set the state of offline storage back, meanwhile Android and iOS developers are using SQLite or equivalents.

Well, the FileSystem API is still being worked on. Just quite different from what Chrome implemented (which was very Unix-centric, iirc).

Well, that's good to hear. My concern is, we need APIs that are predictable, straightforward, and easy to use for devs to create offline web apps. Right now, it's quite difficult, and hence hardly anyone does it. ServiceWorker may help a lot with one part of the equation, but it doesn't fix up the persistent storage story of the Web.

I find the IndexDB API maddening to use personally.

Agreed on all accounts.

I seem to remember that the current WIP is here: http://w3c.github.io/filesystem-api/Overview.html

Its not just you, it is maddening to use. A sane wrapper is mandatory.

It takes a special kind of myopia to call a decision inexplicable, and then to link to a very explicit description of their reasons for that decision.

Refuted by almost every single comment on the post, yes.

There's a difference between inexplicable and an explanation you disagree with.

Unfortunately, WebSQL had simply _no_ specifications. That's not good for a standard, and that's why IndexedDB won in the end.