W3C home > Mailing lists > Public > www-tag@w3.org > February 2013

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

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Thu, 07 Feb 2013 10:51:56 -0500
Message-ID: <5113CD9C.1000909@openlinksw.com>
To: www-tag@w3.org
On 2/7/13 10:33 AM, Ashok Malhotra wrote:
> Hi Marcos:
> I have been following this space and am aware of the dissatisfaction 
> with existing local storage solutions
> although, I must admit, I did not realize how strong the feelings 
> about IndexedDB were.
> I have been arguing for some time that we need a JS API to SQL -- the 
> real SQL standard -- and not
> SQLite which we tried and failed with http://www.w3.org/TR/webdatabase/

Well, you can actually bind that API to ODBC [1] or XMLA for Tabular 
Data [2][3]. The problem (yet again) was the marketing i.e., pitching it 
as being SQLite specific which was myopic beyond description.

As for IndexedDB, it is an API can actually sit atop the likes of SPARQL 
and other APIs to backend DBMS engines.

The big elephant in this room remains an instinctive penchant on the 
part of many developers to undermine the timeless utility of DBMS 
agnostic data access layers.

In my eyes, HTML5's WebDB API  is the SQL RDBMS API and IndexedDB the 
API for so called NoSQL DBMS engines.


[1] http://bit.ly/14V382C -- HTML5 WebDB to ODBC Bridge (binds to ODBC 
Drivers) .
[2] http://bit.ly/11PJXaE -- HTML5 WebDB to XMLA bridge (enables binding 
to remote servers that are bound to ODBC Drivers) .
[3] http://bit.ly/YcWb6r -- Live demo and usage guide .

> All the best, Ashok
> On 2/7/2013 9:47 AM, Marcos Caceres wrote:
>> Hi,
>> 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!!
>> https://twitter.com/Paul_Kinlan/status/72993324306411520
>> [[
>> Mikeal:
>> 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.
>> ]]
>> https://twitter.com/tobie/status/236196232463257601
>> (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
>> https://plus.google.com/103349380055842606923/posts/TjCKpCpLVa5
>> "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."
>> http://blog.harritronics.com/2011/03/on-web-sql-database-and-indexeddb.html 
>> "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."
>> http://badassjs.com/post/42434864654/idbwrapper-a-cross-browser-indexeddb-wrapper-for 
>> Comments from:
>> http://www.html5rocks.com/en/tutorials/indexeddb/todo/
>> [[
>> 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."
>> http://infrequently.org/2012/12/reforming-the-w3c-tag/
>> 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."
>> https://twitter.com/adrianba/status/236249951049502720
>> What do you think?
>> Kind regards,
>> Marcos
>> [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



Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

Received on Thursday, 7 February 2013 15:52:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:19 UTC