bruant.d at gmail.com
Tue Nov 6 10:47:17 PST 2012
In a post to public-script-coord yesterday, Alex Russel wrote the
"[Web]IDL *is handy. *More to the point, it's the language of the specs
we have now, and the default mode for writing new ones is "copy/paste
some IDL from another spec that looks close to what I need and then hack
away until it's close". This M.O. is exacerbated by the reality that
most of the folks writing these specs are C++ hackers, not JS
developers. For many, WebIDL becomes a safety blanket that keeps them
from having to ever think about the operational JS semantics or be
confronted with the mismatches."
I wasn't aware of this and then read through about a dozen WebAPIs 
between yesterday and today and... discovered it's the case. In my
opinion, one of the most absurd example is the DOMRequest thing which
readonly attribute DOMString readyState; // "processing" or "done"
readonly attribute DOMError? error;
attribute EventListener onsuccess;
attribute EventListener onerror;
attribute readonly any? result;
Read it carefully and you'll realize this is actually a promise... but
it has this absurd thing that it has to have both an error and result
field while only one is actually field at any given point.
chainability and the excellent error forwarding that comes with it
off-the-shelf. Also, the lack of a built-in Q.all really doesn't promote
good code when it comes to event synchronization.
Oh yes, of course, you can always build a promise library on top of the
current APIs, blablabla... and waste battery with these libraries .
I'm coming with the following plan:
1) get promises in ECMAScript
2) get WebIDL to support ECMAScript promises
3) get browser APIs to use WebIDL promises
About the first step, there is a strawman  that contains promises and
it requires to define the event loop, so that's probably too much for
ES6. Yet, it doesn't prevent to agree on a promise API that will be
adopted in ES7.
Besides the strawman, promises have run a long way from CommonJS  to
jQuery  to Q  to Irakli's excellent post  to Domenic's recent
rant  and I've missed a lot of other examples probably. The JS
community is ready for promises. The idea has been used a lot.
Different libraries have different APIs and I have no preference. The
only things I really care about is chaining (with error forwarding) and
a promise-joining function à la Q.all. I'll let people who care about
I'm sure TC39 can come to an agreement *before* ES7 standardization,
agreement that can be used by WebIDL and browser APIs (why not
implemented long before ES7 work has even started).
If you're a JS dev and care about promises, please show some support to
this proposal :-)
More information about the es-discuss