While languages, such as Java, has evolved in numerous ways, JavaScript, perhaps the most frequently encountered language on the Web, has not developed much in over ten years. Although, standardization for the next-generation of JavaScript has been ongoing for many years under the ECMAScript 4 effort, the ECMA standards committee could not agree on a single set of features acceptable too all involved. Last week, the impasse finally broke, with the result that there would be no ECMAScript 4 version of the language at all.
Mozilla's Brendan Eich, who invented JavaScript while at Netscape, and is now the head of the standardization effort, reported in a detailed email to the ECMAScript users mailing list the result of a compromise reached in late July:
It's no secret that the JavaScript standards body, Ecma's Technical
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.
Although Eich's message puts a positive spin on this development, it also means that many language features aimed for ECMAScript 4 won't be implemented at all in the next version of JavaScript: Some of the important features defined for ECMAScript 4, such as Java-like classes, including inheritance, as well as packages, won't be part of next version JavaScript. This is significant, considering that effects of the most recent JavaScript standard had lasted over a decade in Web browser implementations, and that many of the language's shortcomings had to be remedied by external libraries to some extent.
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.
What do you think of the ECMA decision to not continue work on a more advanced version of JavaScript, and to revert back to a more modest version?
I think it's great for Adobe which is now free to pursue the evolution of ActionScript 3 without having to compromise with the rest of the world via a standard.
Subsequently, if ActionScript 3 is successful, perhaps it will become the de facto standard for people wanting "more" than ECMAScript 3.1.
I think that's a drawback. AS3 is quite powerful language and the only thing that should be removed is the namespace feature. It'd be great to have AS3 as a browser language running on the Tamarin baked in the browser. I don't really understand how could this happen... The M$ products just suck and they haven't developed a good software for ages. On a positive note, maybe it's time just to stick with pure JavaScript and hope that M$ will not mess it up either ;)
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.
Javascript specs and implementation should be driven with a Open Source Model and a Leader in the field as John Resig is a good candidate for the future of Javascript, Look at his framework is a Master Piece.
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.
Adding more complexity to JavaScript is unwise. If anything, the language should be *reduced*.
JavaScript is not just a language, it is part of the web. So it must be assessed primarily in that light. The 'Principle of Least Power' http://www.w3.org/DesignIssues/Principles.html#PLP advises against choosing complexity. As a 'full' programming language, that means JavaScript should be of very last resort. Making more complex what is already too popular can scarcely be good.
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?
Maybe it is best if JavaScript is painful. It can motivate building better alternatives.
One of the greatest weaknesses of JavaScript as a full-blown app development language is its lack of an modular library mechanism and namespace scoping of symbols.
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.
JavaScript has a fair number of pseudo libraries and frameworks, but they are difficult to intermix. Thanks to Microsoft this looks like it will remain JavaScript's eternal curse.
Google has one approach to dealing with JavaScript's myriad problems for complex app construction, which is GWT.
However, for building the GUI of web RIA apps, Adobe's MXML and ActionScript3 is a much better language combo to use than Java (that's where some of AS3's JavaScript heritage actually pays off).
Essentially ActionScript3 is a cross between JavaScript and Java, with some C# features thrown in to boot.
The irony is that with the Adobe Flash Player having a ~ 95% presence on the browsers actively surfing the Internet, ActionScript3 is already a greater defacto standard than the JavaScript running in the Microsoft IE browsers.
Adobe Flex, in reality, is a more universal standard (having greater breadth) to target programming to than the so-called web standards of HTML, CSS, DOM, and JavaScript. There's no one dialect of those that has as much reach as Flash Player 9.
Previous Topic
