More flexibility in the ECMAScript part? (was: Re: Futures (was: Request for JSON-LD API review))
allen at wirfs-brock.com
Wed Apr 17 12:06:41 PDT 2013
On Apr 17, 2013, at 10:48 AM, Tab Atkins Jr. wrote:
> On Wed, Apr 17, 2013 at 10:28 AM, David Bruant <bruant.d at 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss