Fwd: IndexedDB, what were the issues? How do we stop it from happening again?

FYI, Marcos started a thread about IDB and API design on the www-tag 
list. If you have any replies, please send them to www-tag@w3.org


-------- Original Message --------
Subject:  IndexedDB, what were the issues? How do we stop it from 
happening again?
Resent-Date:  Thu, 7 Feb 2013 14:47:58 +0000
Resent-From:  <www-tag@w3.org>
Date:  Thu, 7 Feb 2013 14:47:28 +0000
From:  ext Marcos Caceres <w3c@marcosc.com>
To:  www-tag@w3.org <www-tag@w3.org>

Ever since IndexedDB was released in browsers, there has been a lot of criticism about the API from the developer community: mainly people saying "it sucks", but not clearly articulating *why* it sucks. For example:

Dear IndexedDB. You SUCK!!


IndexDB is a great go-to example of "here's how awful a committee can make an API"

Jan Lehnardt ‏@janl
it’s an unfortunate history and the resulting API sucks, while the idea is still great.


(Aside: the above twitter thread is a good read, actually… as it brings up gripes also with the accessibility of WebIDL to what I would consider highly-influential people in the developer community).

Patrick O'Reilly
It's no secret that I think #IndexedDB sucks, so what about porting +MongoDB for client-side use with a #localStorage backend? #HTML5


"I'm firmly in the camp that sees IndexedDB as a solution that'll result in more complex, more difficult to maintain, code, that'll encourage dependencies on bloated third party libraries. I'm not seeing the upside."

"In my opinion it is a terribly designed API and we lost a lot of power when we lost SQL, but I suppose JavaScript libraries can help make up for this."

Comments from:
You've got to be kidding. It's a joke, right? This is the state of the art in databases? No, it's a bunch of children recreating database assembly code from the 1960's. This is awful, awful stuff….

Looking at the example, I see spaghetti control flow and data flying in all directions, like a spoiled child throwing his broccoli at the wall. The key facts of the program are obscured under layers of callbacks and come-froms.

I was hoping for a usable API for regular programmers. What's shown here seems useful only to graduate students with unlimited time and no requirement to produce maintainable code on schedule.
i agree with you 100%. this is f*cking GARBAGE, and i will not use it.


And even from our own Alex Russell:
" since 2007 and in that time I’ve seen how the dysfunctional relationship with the W3C enables terrible API design. Needless to say, the results haven’t been great. For a small taste, go look at some IndexedDB samples."

I'm wondering if we can discuss what some of the issues are and get a coherent understanding about what actually sucks about IndexedDB. I'm personally concerned that we are seeing similar API patterns to IndexedDB being standardized in the System Apps APIs. If you take a look at the Alarm API [1], you see what appears to be similar patterns to those used in IndexedDB (in particular the AlarmRequest interface). You see the same XRequest patterns being applied to all of the "System APIs" (see list of specs at [2]). I'm told that this XRequest pattern is based on IndexedDB (and Mozilla's B2G Project's nonstandard "DOMRequest" object [3]).

I could be wrong, and the SysApps APIs might actually be great. But, for the sanity of developers and so we avoid a barrage of "THIS SUCKS!" again, I'm wondering if this is something the TAG can look into (specially "the reformists", who made pledges to look out for the interest of developers!;)).

And one more question I have, is it a goal or failure to have to rely on other's to build JS libraries on top of a standardised API to make it useful? It seems that it was the goal of IndexDB that it would not be developer friendly:

"The goal of IndexedDB was to allow multiple different query processors to be built in JS. We expected few people to use it directly."

What do you think?

Kind regards,

[1] http://www.w3.org/TR/web-alarms/
[2] http://www.w3.org/2012/sysapps/
[3] https://developer.mozilla.org/en-US/docs/DOM/DOMRequest
Marcos Caceres

Received on Thursday, 7 February 2013 15:15:29 UTC