Mozilla Standards Blog

Standards meetings rarely generate the kind of buzz that the ECMAScript meeting Brendan and I attended in Oslo did; check out John Resig’s blog post, and then Doug Crockford’s. And, there’s also the Open Web Podcast on ECMAScript Harmonization that John Resig, Alex Russell, and Dion Almaer hosted Brendan and I on. Turns out that time spent indoors with computer language design mavens in sunny Oslo in late July have sowed the seeds of harmony. But first, some back story.

Just So Stories about why exactly JavaScript became the de facto programming language of the web abound; that it is very popular is either a blessing or a curse for its creator, who says he still sees it as the “quickie love child between C and Self.” Its programming language antecedents, at least in terms of inspiration and influence, have resulted in a language with Java-like syntax, Scheme-like first class functions, and Self-like prototypes. It is implemented, with differences, in every browser, and is here to stay. But how should it evolve? As an integral part of the web platform, what should it be capable of in the future? And, what guiding principles should inform these weighty decisions? Glad you asked. This is a blog post about harmony in the ECMAScript process; or, about how opinionated technologists forgo stalemates and arrive at some measure of reconciliation.

ECMAScript as a standard informs implementations such as JavaScript (in Firefox, Safari, and Opera, to name a few), JScript (in Microsoft’s Internet Explorer) and ActionScript (in Flash). The current version is ECMAScript 3 (formally called ECMA-262 revision 3 [Link to HTML Version]). Note, however, that whatever is sanctioned by the specification remains frozen in time, and I don’t just mean the discovery of errata as time goes on. The language grows; amongst other things, new APIs and programming constructs get introduced. More importantly, developers, particularly those that give other developers useful, reusable stuff like prototype, dojo, or JQuery, want the language to evolve, whether that includes syntactic conveniences or features.

Evolutionary steps are often tentative and experimental, till market popularity dubs them otherwise. JavaScript 1.6 in Mozilla (implemented in Firefox 1.5) introduced Array extras as syntactic sugar, on top of what ECMAScript 3 says you can do with Arrays:


//location or index methods
indexOf
lastIndexOf


//iterative methods
every()
filter()
forEach()
map()
some()


It also included support for E4X, which itself was standardized via an ECMA activity (see ECMA-357: ECMAScript for XML).

Then, JavaScript 1.7 (which is in Firefox 2.0) introduced generators (the yield keyword, for example, typically used in conjunction with while loops) and iterators (the Iterator object and next()), Array comprehensions (ways to initialize arrays using generators and iterators), elegant destructuring assignments ([a,b] = [b,a]), and let as the new “scope restricted” var.

Most recently, JavaScript 1.8 (which is in Firefox 3.0) gives us lambda-like function declarations (function(x) x*x // look Ma, no curly braces or return! ), more syntactic sugar around generator expressions, and a few more Array extras (reduce and reduceRight).

It made sense to have a revision to ECMAScript 3, perhaps to acknowledge reality, and to standardize the moving parts that were already coming into vogue via JavaScript 1.6 and 1.7 (including catering to the clamoring for getters and setters). Getters, setters, and the Array extras (extremely useful for DOM manipulation, among other things) in particular became hot ticket items.

In parallel, visions for the longer term future of ECMAScript were also being distilled, under the name ECMAScript 4. Adobe’s ActionScript 3.0, for example, introduced packages, namespaces, classes and interfaces, along with type annotations as potential optimizations (check out syntax like var x:int=80), based on early ideas that accumulated within the ECMAScript 4 framework.

Thus, two standardization endeavors under the aegis of the ECMA TC39 group: ECMAScript 3.1 and ECMAScript 4, respectively. ECMAScript 3.1 (ES3.1) would be a revision of ECMAScript 3, which had been untouched for a long time. And ECMAScript 4 (ES4) would look at the more evolutionary aspects of the language, introducing newer syntax, constructs, and capabilities. They would exchange ideas on two different mailing lists. Of course, it made sense that ES3.1 would be a subset of ES4. There would be a modest update (ES3.1) and a longer term endeavor (ES4), which sums up some of the back story (at least in terms of aspirations).

But of course, it wasn’t that simple (is it ever?). The ES3.1 group was informed by design goals including simplicity and security (which are definitely laudable and good goals for the Web, any resultant discord notwithstanding); in particular, notions of object capability played a role in language design, given its constituents, who include the folks behind E and SmallTalk. It became clear that the agenda for ES3.1 wasn’t merely {ES3 + “The Recognition of Reality (Defacto Standards)”}. A few saw it as a chance to clean up problems in a misunderstood language. There was the introduction of a secure subset mode to better enable safer mashups, and library additions such as Object.freeze() which enforced the readonly-ness of object properties. Various notions of types were also deemed slippery slopes that ought to be traversed with caution, lest the dynamic nature of ECMAScript languages be irreversibly compromised. In general, newer syntax in ES4 was viewed as a sort of troubling adventurism by the ES3.1 group, while similar misconceptions about ES3.1’s conservative approach to ECMAScript were harbored by the ES4 group. Doug Crockford (of JSON fame) along with Microsoft put forth a proposal to refocus efforts, suggesting that ES4 was too much of a radical departure, making it a totally different language.

Much can be made about disharmony in the ECMAScript process — about security considerations and design philosophies pitted against each other, thwarting the advent of newer capabilities to the language. Discord, however, is NOT the big story. At the meeting in Oslo that took place in July, the ECMAScript group arrived at the notion of ECMAScript Harmonized, a reconciliation between the two groups. Some design compromises needed to be arrived at, but they are good for the Web. To quote Brendan’s executive summary:

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.

Namespace usage implies a module system of some sort (and namespaces and packages go hand in hand, here), but in the case of the Global Object, the module inclusion system is our tried and tested (albeit problematic) <script src=>. Then there’s also:

Plus, as some JS implementors have noted with concern, multiple open namespaces impose runtime cost unless an implementation works significantly harder.

So let’s agree to forgo namespaces in the global object. John Resig asked me on the podcast if namespaces and packages was one concession too many to make, made under pressure from the ES3.1 group (who see the present namespace proposal as anathema to their design principles). Actually, it was the ES4 group that proposed forgoing packages and namespaces, voluntarily, as better for the reality of scripts on the Web today. I suppose these can exist as particular extensions within ActionScript to whatever the newly harmonized language looks like.

But, classes as syntactic sugar are still in, and that’s a really exciting instrument of abstraction (and syntactic sugar). I talk on the podcast about how we spent a lot of time in Oslo engaging in desugaring exercises as useful for harmony, proving that classes can be desugared to ES3.1 syntax, with Object.freeze.

As Brendan’s email shows, our work is still cut out for us. Some discussion around nominal vs. structural typing needs to occur, as well as harmonization around generators and iterators. And then there’s the issue of inheritance, which still needs to be worked out, while preserving the prototype-based inheritance that exists today. Zero, single, or multiple? What do developers really want? Let’s start easy, and then think about it.

Concern about security by those that pave the Web is, of course, good for the Web. But so is evolution. A hung committee full of implementers serves neither goal. Now that we’re all harmonized, let’s get back to rough consensus and running code, and let’s get on with it. I’m looking forward to it.