More flexibility in the ECMAScript part? (was: Re: Futures (was: Request for JSON-LD API review))
bruant.d at gmail.com
Wed Apr 17 10:28:49 PDT 2013
[es-discuss only fork]
I'm forking this as I feel it surfaces an issue which I analyse as being
rooted in the "ECMAScript organization". As I describe my opinion below,
please feel free to tell me I'm wrong in my analysis.
I'm sorry this is not a technical discussion, but I nonetheless believe
that it is a really important discussion to have.
Anne van Kesteren wrote:
> On Wed, Apr 17, 2013 at 4:56 PM, Mark S. Miller <erights at google.com> wrote:
> > Hi Anne, promises were already in progress for ES7. It was the w3c that
> > chose to fork the effort rather than participate and provide feedback.
> Okay, lets assume promises are not in the DOM specification. How soon
> do you think we can get a specification we can use for the dozens of
> APIs in development today?
> (Technically it's not part of any W3C draft by the way, but I guess
> the sentiment is the same either way.)
I don't think W3C forked the progress that was being done on the
ECMAScript side. I believe Alex Russel led an initiative  with a
handful of people. I believe in the good faith of this initiative.
This initiative isn't related to the W3C from what I know (Alex will
correct me if necessary). The reasons why Alex didn't choose to follow
up on the existing strawman ES-side  remain an unanswered question as
far as I'm concerned. It'd be interesting to have an expression on this
The major point here is that the different specs of the web platform
needs to stop reinventing the wheel when it comes to the Promise/Future
pattern and should agree on a shared idiom.
I have suggested  that promises should be part of ECMAScript, but
this didn't happen. Others seem to believe ECMAScript would be a better
place for a Promise/Future built-in library.
Why hasn't it happened? or, to repeat Anne's question: "How soon do you
think we can get a specification [for promise/future in ECMAScript] we
can use for the dozens of APIs in development today?"
I'm interested in the opinions of the different people who will read
My thoughts are as follow:
Although promises were planned for ES7, they weren't part of any formal
spec. As far as I know, no recent TC39 meetings even mentioned the
concurrency strawman .
No formally accepted and agreed upon spec makes ES7 promises and the
concurrency strawman virtually inexistent. The current largely informal
agreement on the concurrency strawman doesn't solve the current problem
of the web platform using promises/futures.
I believe the problem lies in that ECMAScript has a monolitic spec
snapshot model. This model doesn't allow the flexibility needed by
WebIDL and the web platform which are an important consumer of the spec.
I believe this is why the WHATWG was chosen to host the Future spec work
Assuming this is the agree cause, would it make sense for the ECMAScript
spec model to change to fit the flexibility needs of WebIDL and the web
I'm also going to ask a pretty violent question, but: does it still need
to be spec'ed by ECMA? The only argument I've heard in favor of staying
at ECMA is that some people still find ISO standardization and Word/PDF
important. Can this be re-assessed? Especially given the recent
Other parts of the platform (thinking of DOM, DOM Events, XHR,
forgetting about HTML5 specifically) have survived to the living
standard model with success. The rumor on the street is that their
latest editor draft of a lot of W3C is in HTML format; that would
encourage a tighter feedback loop.
Node.js is becoming more and more popular and I don't believe ECMAScript
5.1 being an ISO standard is that important for the people interested in
Node.js (probably even the business-focused ones).
To a large extent the flexibility I'm asking for is already in place
between TC39 and implementors (features are prototyped before being
fully spec'ed). It just needs to be extended to another important
consumer of the spec that is WebIDL.
More information about the es-discuss