Committee 39, has been split for over a year, with some members
favoring ES4, a major fourth edition to ECMA-262, and others
advocating ES3.1 based on the existing ECMA-262 Edition 3 (ES3)
specification. Now, I'm happy to report, the split is over...
The committee has resolved in favor of these tasks and conclusions:
Focus work on ES3.1 with full collaboration of all parties, and
target two interoperable implementations by early next year.
Collaborate on the next step beyond ES3.1, which will include
syntactic extensions but which will be more modest than ES4 in both
semantic and syntactic innovation.
Some ES4 proposals have been deemed unsound for the Web, and are
off the table for good: packages, namespaces and early binding. This
conclusion is key to Harmony.
Other goals and ideas from ES4 are being rephrased to keep
consensus in the committee; these include a notion of classes based
on existing ES3 concepts combined with proposed ES3.1 extensions.
John Resig, the designer of the popular JQuery Ajax library explains some background behind this decision:
The ECMAScript 4 specification development was very ad-hoc in nature (primarily tackled by Adobe, Mozilla, Opera, and Google): Implementors agreed upon a set of features that they wished to implement and a specification was molded out of the remaining consensus. Building a specification tailored by implementation is a very pragmatic means of reaching a reasonable result.
However there was a fundamental split related to how much of the specification should be implemented. Enter ECMAScript 3.1. This working group (lead by Microsoft and Yahoo) set out to implement some minor changes and bug fixes to ECMAScript 3 while remaining as a subset of full ECMAScript 4 functionality.
These two groups continued to work side-by-side but a struggle was inevitable. The ECMAScript 3.1 group wanted to add changes to the language that would affect the result of ECMAScript 4. This struggle over the past year finally came to a head this past month at the meeting of TC39 (the committee responsible for both ECMAScript 4 and ECMAScript 3.1). Dubbed "the Oslo meeting" this discussion between the two groups saw an ultimate conclusion: The two efforts had to be merged, otherwise neither one would succeed...
The most immediate loser from this decision is Adobe, a company that built an entire product portfolio on a draft version of ECMAScript 4. Not only is ActionScript 3, the language behing Flex 3, based on this draft specification, but so are numerous other Adobe products, including Acrobat.
In a blog post commenting on the ECMA decision, Hank Williams writes that politics were the most important reason for the failure to move ECMAScript 4 forward:
Unfortunately, while the technology of EcmaScript 4.0/ActionScript 3.0/Tamarin is compelling, the politics sucked.
Adobe and Microsoft are bitter rivals, and the last thing Microsoft would be willing to accept is wide-spread adoption of a language that is strategically critical to a competitor. If EcmaScript was accepted, [Adobe's virtual machine] Tamarin would have been the gold standard virtual machine. Microsoft would have needed to build their own compatible VM – a long painful process – or they would have had to (insert “gulp” sound) adopt Tamarin. The battles over the standard were nasty, personal, and public. But unfortunately for Adobe, control over Internet Explorer is a much better bargaining chip than control over Flash. And Microsoft was insistent that they would never support EcmaScript 4.0...
And so this meant EcmaScript 4.0 was stillborn. It was dead even before it’s head began to crown, because it was a win that Microsoft could not bequeath upon its bitter rival.
Adobe's Ryan Stewart comments that the ECMA decision won't mean that Adobe is going to remove features from ActionScript:
While ActionScript 3 was supposed to be an implementation of the ECMA 4 standard, it’ actually still based on ECMAScript 3 and will now be treated as an extension with some additional functionality. I think in a lot of ways this shows some of the difficulty in working with standards organizations. And Adobe will continue to track the progress of ECMA, but we’re not going to start removing namespaces and packages or changing ActionScript to comply with the “3.1″ version of ECMAScript. I’m sure we’ll have more news or transparency around the next version of ActionScript when it gets close, but we want to add functionality for our developers - not take it away. If anything, this gives us more freedom to incorporate your ideas and thoughts into the language while still being a part of the ECMA committee.
Committee standards Sucks Big Time!!, I think for the healthy of technology and programming languages is much better the Open Source Model with a leader, look at Linux, Look at Python those are a Success.
Open Source is the future, ECMA/ISO/ANSI sucks big time!, Committee standards are to slow for the dynamic IT/Computing world and we need a lead that it is not with a company politic agenda.
The underlying problem is a lack of alternatives. A collection of specialised formats, such as SMIL and XUL, could provide much complex functionality, but more sympathetically to web principles. There does even appear to be a (incipient) scheme for integrating them: 'Compound Document Format' http://www.w3.org/2004/CDF/ . But who knew that existed? And are the components really sufficient?
Java had these fairly well solved when it was first conceived and there's been a plenitude of libraries from day one. The wealth of libraries and frameworks for Java is its greatest strength.