ECMAScript Harmony: New Life for JavaScript

One by one, the core standards that define the Web are getting a new lease on life. First, the W3C rebooted its development of HTML by abandoning its single-minded focus on XHTML and embracing the work of the WHAT-WG’s HTML 5 draft as a new beginning. Now, at a meeting in Oslo at the end of July, the long-divided standards body responsible for the JavaScript language has managed to find new unity through compromise.

The standard that describes JavaScript is called ECMAScript (because “JavaScript” is a trademark owned by Sun Microsystems). The last full update to ECMAScript, ECMA-262 3rd Edition, was published in 1999. In the over eight years since its publication, progress of JavaScript as a web standard has barely budged.

The lack of change to ECMAScript in that time has not been due to the language’s maturity. ECMA-262 3rd Edition has widely-recognized issues that real-world browsers have had to work around for years, so there has been plenty of need for a 4th Edition. In the absence of one, browser makers have had to reverse-engineer each other’s implementations in order to decide how to deal with the holes in the spec—pretty much the worst-case scenario for all concerned.

The Split in TC39

The ECMA Technical Committee 39 (TC39, the committee responsible for developing ECMAScript standards) certainly hasn’t been sitting idle during this time. Discussion of the features that should go into the 4th Edition of ECMA-262 have been ongoing pretty much non-stop, but consensus has been elusive.

Within TC39, representatives from Mozilla, Adobe, Opera, and Google wanted to undertake major enhancements to the language, and began assembling a list of new features shortly after the release of the 3rd Edition. Many of these features (like namespaces, generators, optional static typing, and getters/setters) have been added into real-world implementations of ECMAScript over the years (e.g. ActionScript 3 in Flash/Flex, JavaScript 1.7 and 1.8 in Firefox).

But not everyone within TC39 favored these kinds of changes. Over a year ago, representatives of Microsoft and Yahoo! within the committee stated that they felt a relatively minor update to the language, to fix the problems that had become apparent in the 3rd Edition, was more appropriate. They pointed out, for example, that features like packages, namespaces, and early binding that had been implemented in ActionScript 3 would present performance challenges if anyone tried to implement them in browsers.

This split within the committee led to the formation of two groups, each with its own draft: those seeking to add major features called their draft “ECMAScript 4.0,” while the more conservative group called its draft “ECMAScript 3.1.” But there could only be one ECMA-262 4th Edition, so as long as the two groups worked in parallel, the future of ECMAScript would remain unknown.

All that changed last month in Oslo. Read on below to find out what happened.

Harmony at the Oslo Meeting

What had been scheduled to be a regular meetup of the divided TC39 in Oslo at the end of July turned out to be a massive turning point for the committee and—we have good reason to hope—the JavaScript language itself.

The members of TC39 agreed that a divided committee was good for no one, and forged an agreement that would allow work to continue on a single, unified draft for the 4th Edition of ECMA-262, under the name “ECMAScript 3.1.” To reflect the historic settling of differences that this represented, the effort has been dubbed ECMAScript Harmony.

Under Harmony, each side of the debate has made a key concession:

• The “ECMAScript 4.0” group has conceded that packages, namespaces, and early binding are all features that are unsuitable for the Web. They have been permanently ruled out of being included in any future version of the ECMA-262 standard.
• The “ECMAScript 3.1” group has conceded that some of the features that were proposed for ECMAScript 4.0 do have merit, and these will be reworked for inclusion in a release to follow ECMAScript 3.1. That subsequent release is being called “ES-harmony”.

Moving forward, the committee anticipates being able to deliver a 4th Edition of ECMA-262 in the first half of 2009, with at least two real-world implementations (i.e. two of the four major browsers) in the wild. No new features will be added to this release that are not already present in at least three of the four major browsers (e.g. getters and setters will make it in).

The official announcement by Mozilla’s Brendan Eich can be read at Ajaxian, and the reactions from other JavaScript notables like John Resig, Douglas Crockford, Mike Chambers, and Alex Russell make worthwhile reading (with varying levels of technical detail). Also, Episode 2 of the newly-launched Open Web Podcast brings a lot of these people together to discuss the change in direction.

What’s It All Mean?

Obscure dropped features aside, the fundamental point here is that TC39 has realized the same thing that the W3C was forced to realize about HTML last year: writing standards and hoping that the browsers will follow doesn’t work. No matter how good the W3C’s recommendation for XHTML2 looked on paper, it wasn’t going to force Microsoft to support it in Internet Explorer. With HTML 5, the W3C is letting the browsers try out new ideas, and is forging standards from the good stuff.

Similarly, the members of TC39 could add all the features in the world to ECMAScript 4.0, but the only way to find out if a feature works on the Web is to build it into a real-world browser first. Then you can decide if it should make it into the standard.

And now for the obvious question: is CSS next? I for one will be keeping a close eye on the W3C’s CSS Working Group in the weeks ahead.