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.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://www.magain.com/ mattymcg

    Good food for thought, Kev. We wouldn’t have Ajax if Microsoft hadn’t pushed the envelope in IE so many years ago. I disagree a bit with this statement though (which, I suppose, is actually the crux of your argument):

    writing standards and hoping that the browsers will follow doesn’t work

    By the same token, allowing browser vendors a free-for-all and hoping that they’ll permit themselves to be reigned in doesn’t work either — this is the exact situation that resulted in the so-called “browser wars”, ActiveX and the death of Netscape.

    It needs to be a bit of both. Measured innovation, if you will. The W3C still has a place, it’s just not the one-way process they’ve always attempted to make it.

  • http://www.seydesign.com seyDoggy

    This is good news in my view. W3C has done one thing if nothing else, raised the awareness around why standards should exist. Maybe their approach was a bit too intense but look at what it’s done for the web experience as a whole. I hope TC39 and their new found love for each other can do the same for javascript.

  • anonymous3

    Maybe the W3C should create a browser.

  • http://www.mikeborozdin.com/ Mike Borozdin

    So, what will be changed in the new version of JavaScript?

  • Brian Lowe

    Wait though…

    I thought the W3C included representation from the major players, so surely the big browsers have a pretty loud voice when it comes to defining the ‘standard’.

    If the W3C doesn’t already include Mozilla and Microsoft reps then it has been wasting its time.

  • http://www.50000steps.co.uk sfrost2004

    “writing standards and hoping that the browsers will follow doesn’t work…With HTML 5, the W3C is letting the browsers try out new ideas, and is forging standards from the good stuff”

    So does this mean that the “traditional” way of creating standards has been turned on it’s head? Whereas standards were once created by global bodies and the industry had to seek to “achieve” those standards, it sounds like the industry can now do what it likes and the standards are just a collation of the best bits.

    This sounds to me like web standards are becoming less of a gold standard (no pun intended) for good web development practice and more of an excuse for ratifying new browser features. What I’m worried about is that the less exciting or more difficult aspects of web standards (like promoting accessibility) will be gradually forgotten and left behind.