Parts of EcmaScript 4 deemed unsound for the Web

This was the conclusion of an EcmaScript meeting in Oslo last month. Specifically, as Brendan Eich explains, three features – packages, namespaces and early binding – were considered too heavyweight unsuitable for a browser scripting language. Here is Eich’s “Executive summary”:

The committee has resolved in favor of these tasks and conclusions:

1. Focus work on ES3.1 with full collaboration of all parties, and target two interoperable implementations by early next year.

2. Collaborate on the next step beyond ES3.1, which will include syntactic extensions but which will be more modest than ES4 in both semantic and syntactic innovation.

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

4. Other goals and ideas from ES4 are being rephrased to keep consensus in the committee; these include a notion of classes based on existing ES3 concepts combined with proposed ES3.1 extensions.

This means that the evolution of JavaScript is now on a new path, focused for now on a more modest enhancement to the language called EcmaScript 3.1.

Given how loudly Eich protested about EcmaScript 3.1 last October, it is a surprising turn of events. Was Eich convinced by the arguments of Microsoft and Yahoo in support of a more lightweight JavaScript?

What this means is that JavaScript 2.0 won’t happen as previously envisaged. John Resig:

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

Eich and Resig are keen to stress that JavaScript will still be a highly capable language. Still, the obvious conclusion is that this will be good for plug-ins which support more powerful languages: Adobe Flash, Microsoft Silverlight, Sun Java or Java/FX. Personally I’m disappointed.

It is also presenting Adobe with a tricky problem, as it implemented much of an earlier specification for EcmaScript 4 in ActionScript 3. Rather than being a standard language, as Adobe had planned, it looks like this will now be more of an Adobe language. I doubt this will have much practical impact on developers.

PS Brendan Eich has commented below.

5 thoughts on “Parts of EcmaScript 4 deemed unsound for the Web”

  1. Hi Tim, a few comments.

    First, “unsound for the web” does not equal “too heavyweight”. Unsound means a premise from which conclusions about namespaces were reached was false. The premise was that namespaces could be used by unrelated scripts to define names in the global scope, without making conflicts of a new kind, worse and different from the conflicts you can get today between scripts trying to set and get a single global variable foo.

    The problem with namespaces and early binding is technical, in other words — not political or aesthetic — not about “weight”. As my message noted, packages already were cut by the ES4 working group this past April.

    This does not mean that ES4 will never happen (it’s the next major Edition number), or that the language won’t evolve (perhaps some would prefer that, but they’re Luddites). The ES standard will evolve and Mozilla has already contributed results from its JS1.x versions to inform emerging standards such as ES3.1. That’s the good news of Harmony.

    The bad news, if it is bad news, is that namespaces, packages, and early binding will have to remain ActionScript extensions to ES3 and future ECMAScript standards. The ES3 spec allows extensions, and it’s important to do so explicitly, to let implementations experiment, precisely in order for the language to evolve.

    I view Harmony as a victory for those who want the language to evolve, rather than stay at ES3 or even shrink into a pet subset that everyone would use (if only they had the good taste of the subset’s advocates).

    The Web is a shortest-path evolving system. It’s anywhere from silly to evil to try to stagnate JS evolution. The commitee seems agreed to this, although of course Microsoft tried to stagnate not only JS but all web standards not so long ago, and changed course only under competitive pressure.

    It is definitely “fighting the last battle” (from 10 years ago) to fret about premature standardization. The web standards are way out of date and must catch up to track those evolutionary paths that are already well-trodden.

    /be

  2. Tim: me again, finding your post via its headline (or lede? I don’t know the jaron), and getting more irate. “EcmaScript 4 deemed unsound for the Web” is simply not accurate. The namespace and early binding proposals were one small part of ES4. I hope you will change the headline.

    /be

  3. Brendan,

    First, thanks for your comments, which are very helpful and welcome.

    I’ve added “Parts of” to the headline and corrected “heavyweight”. I’ve also added your executive summary.

    By way of explanation, I was trying to reflect what you wrote here:

    … early binding in any dynamic code loading scenario like the web requires a prioritization or reservation mechanism to avoid early versus late binding conflicts.

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

    I did not intend to misrepresent you and apologise if that was the case.

    Thanks again for your comments.

    Tim

  4. Tim, thanks very much for the update. It’s hard to communicate technical conclusions from a language standards body clearly, just due to the intrinsic complexities. Then everyone who has an ax to grind wants to put a political spin on the technical facts. So every bit of clarification helps. Thanks again,

    /be

Comments are closed.