The best retelling of events, I think, is this one: http://nolanlawson.com/2014/04/26/web-sql-database-in-memori...
Has some very good details. And it's certainly funny to see what was said during the discussion with how things turned out in practice.
Edit: I'd sum it up as "Google and Apple argue for a solution that will work on mobile; Mozilla and Oracle don't care about mobile, are weirdly obsessed with the idea that developers hate SQL, and use political manoeuvring to win the fight". (Oracle's role in this seems especially odd, but perhaps they had some longer term strategy in mind.) In any case, in retrospect ignoring mobile was a bad idea, and ditching SQL seems to have had no real benefit.
It does show the total need for a fast, JITable intermediate language, and the silliness in not having one from the start, or at least long, long ago.
Not entirely true either. From the link:
> Hixie has said before he’s willing to fully spec the SQL dialect used by [WebSQL]. But since Mozilla categorically refuses to implement the
spec (apparently regardless of whether the SQL dialect is specified), he doesn’t want to put in the work since it would be a comparatively
poor use of time.
Even in that article, the a dev says he's queried the SQLite version in order to detect which exact FT options are available.
The argument for it is basically "eh but it's handy", ignoring the idea of the Web.
If you don't want to just use Sqlite (understandable), and you don't want to write something that is as good as Sqlite (also understandable), then you're going to have a crap database implementation. There's just not a lot of other options there. Jonas' comment just reiterates the lack of choices.
But given the three bad choices, the question does arise: Was IndexedDB really the best of a bad lot? In 2009, a lot of very optimistic things were said about IndexedDB performance, adoption, usage on mobile, developer acceptance. It's been 6 years, and I think it's safe to say that IndexedDB hasn't lived up to anyone's hopes.