Concerns about DOMRequest

I noticed that in the System Application Runtime: Execution and Security Model [1] document there is the following statement:

"DOMRequest intend to be used instead of those callbacks to make those APIs more developer-friendly and help code readability."

I have some reservations about DOMRequest and the claims above (and all the derivative interfaces defined by the WG, like AlarmRequest, etc). DOMRequest seems to be at the core of complexity associated with IndexedDB [2] and suffers from some serious design flaws:

1. It confuses events and callbacks by switching one for the other.

2. Forces developers to write synchronous code to handle asynchronous functionality (i.e., it tries to be a promise, but while - as one developer described it to me - "taking all the fun out of promises"). This is because any code relying on DOMRequest must be run in a synchronous function call. 

3. Because of 2, APIs can't be easily run interactively in a JS console - which makes learning, development, and manual testing tedious. This leads to developers then having to build libraries on top of the standardised ones to actually make the API usable.  

4. Leads to far illegible programming patterns, leading to less legible code (see [3] as well as the angry comments from [3]).

I would kindly request that the group only use this pattern, if, and when, absolutely necessary - or consider better patterns like the one used by XHR, promises, or the DOMFuture proposal [4] (which will soon be merged into DOM4). If the APIs need asynchronous execution, then the most appropriate pattern should be considered on a case-by-case basis, not taken wholesale. 

I'll note that wholesale adoption of patterns was a noticeable issue in all the WAC APIs (which tried to copy Geolocation without really understanding what was good/bad about that pattern and when it's actually appropriate to use it). It would be a shame if this group made the same mistakes as WAC when it comes to API design by naively adopting DOMRequest when better solutions exist for particular use cases/APIs. 

[1] http://jungkees.github.com/sysapps/proposals/Runtime/Overview.html#domrequest-interface
[2] http://lists.w3.org/Archives/Public/www-tag/2013Feb/0003.html
[3] http://www.html5rocks.com/en/tutorials/indexeddb/todo/#toc-step2
[4] https://github.com/slightlyoff/DOMFuture
-- 
Marcos Caceres
http://datadriven.com.au

Received on Wednesday, 13 February 2013 18:41:42 UTC