There’s been some turmoil in the world of ECMAScript.

While many are – even, at least, vaguely – familiar with the development of ECMAScript 4 the devil is in the details. I’ve blogged about ES4 extensively in the past – and even did a speaking tour last fall educating developers about its details and implementations, however, a lot has happened since that time.

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 result was a set of concessions and a re-focus on simplicity and pragmatic language additions. Brendan Eich detailed the result in a lengthy email to the ECMAScript 3.1 and ECMAScript 4 lists.

The important part is the new set of goals for this, now dubbed, ECMAScript Harmony project:

Focus work on ECMAScript 3.1 with full collaboration of all parties, and target two interoperable implementations by early next year. Collaborate on the next step beyond ECMAScript 3.1, which will include syntactic extensions but which will be more modest than ECMAScript 4 in both semantic and syntactic innovation. Some ECMAScript 4 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 ECMAScript 4 are being rephrased to keep consensus in the committee; these include a notion of classes based on existing ES3 concepts combined with proposed ECMAScript 3.1 extensions.

This means a couple things: First, you can forget a lot of what you learned about ECMAScript 4, previously. Many of the complicated concepts contained in the language have been tossed. Instead there is a considerable amount of effort going in to making sure that new features will be easily duplicable through other means.

For example, ECMAScript 3.1 provides a new method – called Object.freeze() – which allows you to pass in an object and “freeze” it, preventing it from being modified any further. This is a subset of the functionality that is needed to implement classes in ECMAScript 4 (classes are immutable).

This means that classes will be a part of the new language but they will be defined as simply being syntactic sugar for a series of plain methods or conventions (such as using closures and Object.freeze to create a Class-like experience). Making sure that complex concepts break down into a simplified form will serve users well – giving them a considerable amount of leverage in using the language.

There is still some debate surrounding the remaining features of ECMAScript 4 – such as type annotations or if classes should support inheritance (and if they do, should the utilize the existing prototypal form of inheritance). A lot of this will become apparent over time.

The process that’s gone into developing ECMAScript 4 is being adapted to suit ECMAScript 3.1 development as well. This means that there will be a runnable reference implementation for the language (with as much of the language written in the language itself, as possible – self-hosting code is quite cool).

Probably the most important development within all this is the codification of existing de-facto standards. For example, the concept of JavaScript getters and setters (implemented by Mozilla, Apple, and Opera) are going to be quickly fast-tracked into the specification (in the case of getters and setters they already have been). Seeing real-world code quickly make a bee-line for standardization is truly heartwarming. We’ll probably see more of this for topics like ‘let’ and ‘expression closures’ – but which will arrive post-ECMAScript 3.1 (since they require new syntax).

There is still a significant amount of work left to do (both in the realm of specification and implementation) but there has been some important progress made here. Seeing an agreement between all of the largest players in the ECMAScript space (Mozilla, Microsoft, Apple, Opera, Google, Yahoo) is quite historic and will stand to serve users well.

—

I will be doing another Open Web Podcast tomorrow with Dion Almaer, Alex Russell, Brendan Eich, and Arun Ranganathan where we will be discussing ECMAScript Harmony.