Re: More flexibility in the ECMAScript part? (was: Re: Futures (was: Request for JSON-LD API review))
Ecma does official HTML now. /be Tab Atkins Jr. wrote: unofficial HTML version for everything. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
More flexibility in the ECMAScript part? (was: Re: Futures (was: Request for JSON-LD API review))
[es-discuss only fork] Hi, 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 erig...@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 [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 topic. 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 [4]. 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 platform? 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. David [1] https://github.com/slightlyoff/DOMFuture [2] http://wiki.ecmascript.org/doku.php?id=strawman:concurrency [3] https://mail.mozilla.org/pipermail/es-discuss/2012-November/026188.html [4] http://dom.spec.whatwg.org/#futures ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More flexibility in the ECMAScript part? (was: Re: Futures (was: Request for JSON-LD API review))
On Wed, Apr 17, 2013 at 10:28 AM, David Bruant bruan...@gmail.com wrote: 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. Speaking as someone who's been doing W3C work for years, I find ISO standardization a non-issue, and Word/PDF an anti-feature. I can't *stand* the ES draft as it's published today, and rely on the unofficial HTML version for everything. I strongly support any efforts to move JS standardization into the umbrella of the W3C. I also strongly support any efforts to move JS standardization to a module-based affair, where parts can level independently. I think we've accumulated more than enough evidence over the last decade that monolithic specs are not the right way to develop standards for the web. (The one counter-argument, HTML, is an important exception to learn from, as it is a monolithic *document* but a modular and independently-advancing *spec*.) ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More flexibility in the ECMAScript part? (was: Re: Futures (was: Request for JSON-LD API review))
On Apr 17, 2013, at 10:28 AM, David Bruant wrote: ... 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]. i don't think the mention observation is totally correct. More generally, it is the actual TC39 participants who set the agenda for meetings and who build the necessary consensus to advance proposals. That is how the ES7 observe proposal has advanced as rapidly as it has. It is up to champions of specific proposal (such as Alex or Mark, in this case, but it could be others) to add appropriate agenda items and to move the process forward. 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 [4]. TC39 does not exclusively do monolithic specs. See for example Ecma-402, the ECMAScript initialization API [5] which is a modular addition to Ecma=262. It is also a good example of domain experts working within the context of TC39 to focus attention on a specific feature area. However, there is a very good reason that the ECMAScript Language specification is a monolithic spec. Language design is different from library design. Programming language designs are notorious for the cross-cutting syntactic and semantic issues that arise when new langue level features are added. It would be irresponsible to try to introduce a new features without considering how it interacts with all other features of the language. It also, isn't best practice to to only sequentially design in new features as this may lead to decision decisions that are hostile to other feature requests that are in the pipeline. There is stuff in Ecma-262, particularly as ES6 emerges, that are basically library features and there has been casual conversations within TC39 about the desirability and practicality of of having separate standards for some library components. Ecma-402 is an example of this. However, some care needs to be exercised here because sometimes library based features are actually cross-cutting language semantic extensions that are just masquerading as a library. 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 platform? 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? Language design is what it is, and to responsibly extend ECMAScript you need to have experienced language designers engaged. I think organizational venues and process has very little to do with the actual pragmatics of how you design extensions for a language as prominent as JavaScript. 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. I would express this as, the web platform is the most important host environment for ECMAScript (that's how TC39 thinks of it). It is important that the architects of the web platform communicate their requirements, priorities, and timeframes to TC39 as the maintainers of ECMAScript and that TC39 is responsive to them. There really are no barriers to this, after all, many of us work for organizations that actively participate in both W3C and TC39 activities. Regarding WebIDL, while it has improved it is still a terrible fit to ECMAScript and attempts to extend the ECMAScript language semantics via WebIDL is a really bad idea as it circumvents the language design best practices mentioned above. WebIDL is not a good rallying point for better W3C/TC39 convergence. Allen David [1] https://github.com/slightlyoff/DOMFuture
Re: More flexibility in the ECMAScript part? (was: Re: Futures (was: Request for JSON-LD API review))
On Apr 17, 2013, at 10:48 AM, Tab Atkins Jr. wrote: On Wed, Apr 17, 2013 at 10:28 AM, David Bruant bruan...@gmail.com wrote: 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. Speaking as someone who's been doing W3C work for years, I find ISO standardization a non-issue, and Word/PDF an anti-feature. I can't *stand* the ES draft as it's published today, and rely on the unofficial HTML version for everything. Note that there is an official HTML version http://www.ecma-international.org/ecma-262/5.1/ I strongly support any efforts to move JS standardization into the umbrella of the W3C. I also strongly support any efforts to move JS standardization to a module-based affair, where parts can level independently. I think we've accumulated more than enough evidence over the last decade that monolithic specs are not the right way to develop standards for the web. (The one counter-argument, HTML, is an important exception to learn from, as it is a monolithic *document* but a modular and independently-advancing *spec*.) See my response to David's message. In many ways HTML is more like a langue design effort than a library design effort. But regardless, I'm confident that wherever JS is standardized, the basic process of how you evolve a language of this importance will be much the same, and so will be the time frames. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More flexibility in the ECMAScript part? (was: Re: Futures (was: Request for JSON-LD API review))
On Wed, Apr 17, 2013 at 12:06 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Note that there is an official HTML version http://www.ecma-international.org/ecma-262/5.1/ Thanks! This apparently has bad google-juice, and is not linked prominently in the first couple results that I look at whenever I search for the ES draft. We can probably fix the latter, since most of those pages are under close-by people's control. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
