More flexibility in the ECMAScript part? (was: Re: Futures (was: Request for JSON-LD API review))

David Bruant bruant.d at
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> 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 [1] 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 [2] 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 [3] 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 
this message.
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 [2].
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 
promise/future mess?
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 mailing list