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.
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
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).
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.