It's hardly grandstanding when it's the standard everyone agreed on.

I agree that IndexedDB is awful and WebSQL was much better, but go shout at the W3C, not Mozilla.

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 was Mozilla's insistence on IndexedDB that tipped the balance. WebSQL was already well supported in Chrome and Safari and if Mozilla hadn't inexplicably come down on Microsoft's side we would have a reasonable client-side database solution today.

Lest this particular piece of villainy be forgotten: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...

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.

> canning WebSQL for spurious reasons

The way to implement WebSQL is to copy SQLite 3.1.9. That is not exactly a baked specification, that is the kind of crap companies used to pull to make unimplementable "standards" for everyone who doesn't license their code and doing that a few times over a decade would make w3c compliant browsers pretty crappy.

So instead, invent something that's a piece of crap, and make the Web worse than what Android and iOS developers get for offline storage.

SQLite is public domain, there's no need to license it.

Sometimes worse is a better, and insisting on standards process purity in this case I think harmed developers and didn't help the Web at all. There was nothing wrong with SQLite from a licensing standpoint, and everyone could have used it, and reverse engineered a spec later.

Reverse engineering a spec from an active product which regularly fixes bugs or adds new features? I'm not saying that it couldn't work, but I am not very optimistic.

Plus, I don't remember that anybody in w3c or whatwg actively defended that approach.

It would have made much more sense to use that as a basis for a new, more formal spec than to pull some new NoSQL spec that nobody wanted out of their ass.