Wednesday, August 13th, 2008

ECMAScript Harmony: Coming together after Oslo

Category: JavaScript, Standards

I discussed my worries about JavaScript 2 recently. I could only do so as I saw some light at the end of the tunnel. That light came from an ECMA meetup in Oslo where it seems people came together to rally behind the idea that something needs to be done.

Brendan Eich posted to a mailing list on the work, and I think I will let him talk below:

It’s no secret that the JavaScript standards body, Ecma’s Technical
Committee 39, has been split for over a year, with some members
favoring ES4, a major fourth edition to ECMA-262, and others
advocating ES3.1 based on the existing ECMA-262 Edition 3 (ES3)
specification. Now, I’m happy to report, the split is over.

The Ecma TC39 meeting in Oslo at the end of July was very productive,
and if we keep working together, it will be seen as seminal when we
look back in a couple of years. Before this meeting, I worked with
John Neumann, TC39 chair, and ES3.1 and ES4 principals, especially
Lars Hansen (Adobe), Mark Miller (Google), and Allen Wirfs-Brock
(Microsoft), to unify the committee around shared values and a common
roadmap. This message is my attempt to announce the main result of
the meeting, which I’ve labeled “Harmony”.

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.

Detailed Statement

A split committee is good for no one and nothing, least of all any
language specs that might come out of it. Harmony was my proposal
based on this premise, but it also required (at least on the part of
key ES4 folks) intentionally dropping namespaces.

This is good news for everyone, both those who favor smaller changes
to the language and those who advocate ongoing evolution that
requires new syntax if not new semantics. It does mean that some of
the ideas going back to the first ES4 proposals in 1999, implemented
variously in JScript.NET and ActionScript, won’t make it into any ES
standard. But the benefit is collaboration on unified successor
specifications to follow ES3, starting with ES3.1 and continuing
after it with larger changes and improved specification techniques.

One of the use-cases for namespaces in ES4 was early binding (use
namespace intrinsic), both for performance and for programmer
comprehension — no chance of runtime name binding disagreeing with
any earlier binding. But 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.

For these reasons, namespaces and early binding (like packages before
them, this past April) must go. This is final, they are not even a
future possibility. To achieve harmony, we have to focus not only on
nearer term improvements — on “what’s in” or what could be in — we
must also strive to agree on what’s out.

Once namespaces and early binding are out, classes can desugar to
lambda-coding + Object.freeze and friends from ES3.1. There’s no need
for new runtime semantics to model what we talked about in Oslo as a
harmonized class proposal (I will publish wiki pages shortly to show
what was discussed).

We talked about desugaring classes in some detail in Oslo. During
these exchanges, we discussed several separable issues, including
classes, inheritance, like patterns, and type annotations. I’ll avoid
writing more here, except to note that there were clear axes of
disagreement and agreement, grounds for hope that the committee could
reach consensus on some of these ideas, and general preference for
starting with the simplest proposals and keeping consensus as we go.

We may add runtime helpers if lambda-coding is too obscure for the
main audience of the spec, namely implementors who aim to achieve
interoperation, but who may not be lambda-coding gurus. But we will
try to avoid extending the runtime semantic model of the 3.1 spec, as
a discipline to guard against complexity.

One possible semantic addition to fill a notorious gap in the
language, which I sketched with able help from Mark Miller: a way to
generate new Name objects that do not equate as property identifiers
to any string. I also showed some sugar, but that is secondary at
this point. Many were in favor of this new Name object idea.

There remain challenges, in particular getting off of the untestable
and increasingly unwieldy ES1-3.x spec formalism. I heard some
generally agree, and no one demur, about the ES4 approach of using an
SML + self-hosted built-ins reference implementation (RI).

We are going to look into stripping the RI of namespaces and early
binding (which it uses to ensure normative self-hosted behavior, not
susceptible to “user code” modifying the meaning of built-ins),
simplifying it to implement ES3.1plus or minus (self-hosted built-ins
may require a bit more magic). More on that effort soon.

ES3.1 standardizes getters and setters that were first implemented at
Mozilla and copied by Apple and Opera. More such de-facto
standardization is on the table for a successor edition in the
harmonized committee.

I heard good agreement on low-hanging “de-facto standard” fruit,
particularly let as the new var, to match block-scoped const as still
proposed (IIRC) in 3.1. Also some favorable comments about simple
desugarings such as expression closures and destructuring assignment,
and other changes in JS1.7 and 1.8 that do not require new runtime
semantic models.

Obviously, these require new syntax, which is appropriate for a major
post-3.1 “ES-harmony” edition. Syntax is user interface, there’s no
reason to avoid improving it. What’s more, the intersection semantics
of extended ES3 implementations conflict and choke off backward-
compatible *semantics* for syntax that may even parse in all top four
browsers (e.g., functions in blocks).

Both the appropriateness of new syntax, and the need to make
incompatible (with ES3 extensions) semantic changes, motivate opt-in
versioning of harmonized successor edition. I believe that past
concerns about opt-in versioning requiring server file suffix to MIME
type mapping maintenance were assuaged (browsers in practice, and
HTML5 + RFC 4329, do not consider server-sent Content-Type — the web
page author can write version parameters directly in script tag type

Some expressed interest in an in-language pragma to select version;
this would require immediate version change during parsing. It’s a
topic for future discussions.

The main point, as important as cutting namespaces in my view, is
that the committee has a vision for extending the language
syntactically, not trying to fit new semantics entirely within some
combination of existing “three of four top browsers” syntax and
standard library extensions.

As Waldemar Horwat (Google) said on the final day, the meeting was
seminal, and one of the most productive in a long while. Much work
remains on 3.1 and Harmony, but we are now on a good footing to make
progress as a single committee.

There is still a lot to do, and I look forward to hearing Doug’s side of things too (going to blog about it Doug?).

What are your thoughts?

UPDATE: John Resig has added his thoughts.

Posted by Dion Almaer at 5:56 pm

4.1 rating from 24 votes


Comments feed TrackBack URI

I’ve detailed many of the changes that are taking place and provided some back story to what’s going on here:

Comment by JohnResig — August 13, 2008


Comment by genericallyloud — August 13, 2008

very exciting!

Comment by JustinMeyer — August 13, 2008

Sounds great. Too bad this will not see light until everyone has adopted the browsers that support the new language/standards.

It’s great to have all the big players in the room, but one issue that they all seem to lose sight of is adaptability. In contrast, ActionScript has shown faster maturity and language development than any other language [{missing reference}]. Why? Because Flash players have a tendency (understatement) of being up to date.

I wish there was a solution, but until all browsers surrender their engines to an Open Standard & Source Engine (do I need to trademark this?) and all browsers require their users to [automatically] upgrade (not a problem if **all** browsers require this).

It’s extreme — I know. One can dream, however.

Comment by ibolmo — August 14, 2008

Correction. There’s not need for an Open Standard & Source Engine. If all browsers used the same Engine(s) then there’s no need for standards.

Comment by ibolmo — August 14, 2008

This reminds me of the Java Generics fiasco. There, we got a much watered down version of parameterized types because they didn’t want to make any changes to VM semantics. Now it seems, we’ll only get language constructs in future JS versions which are essentially syntactic sugar for what you can already do.

If the Open Web guys were really gutsy, they’d make Javascript syntax just one of many syntaxes that can run on top of a standardized p-code interpreter. The problem I see is that JS 1.x semantics are essentially being enshrined as the fundamental browser VM semantics. Is this what we want going up against Silverlight and Flash in 5 years? 10 years? (It’s fine if you don’t want to use optional static typing, but why impose this restriction on everyone else?)

I think there is far too much focus on syntax because of language bias. The browser should really be a high performance VM for manipulating a DOM layout engine, optimized for speed.

And no, as is frequently stated, a more abstract intermediate representation does not mean you can’t “View Source”.

Comment by cromwellian — August 14, 2008

I’m concerned about how this kind of implies that the OpenWeb architecture is at “end of life” kind of like Java. What do I mean by this? Well, once too many people are invested in a previous technology, and way too much code depends on buggy semantics or previous design flaws, it becomes progressively hard to make future improvements.

You see this today with all of the folks protesting adding closures to Java, with the crappy Java Generics introduced in 1.5, with Internet Explorer being stuck in the past for fear of “breaking the web”, or breaking intranets. You see it with OpenGL 3.0, recently announced. People waited for AGES for a radically redesigned API, and what they got in the end was something akin to Harmony. Why? Legacy. No one wants to risk breaking existing apps.

Essentially, hands are being tied by decisions made in Netscape 2 and IE4 with respect to semantics. In those days, browser vendors would just introduce a proprietary change, without needing a commitee to approve it. We’re stuck with those decisions today.

This all seems to suggest that all future improvements to the browser will be bound by the mistakes make previously. They’ll innovate around the edges: syntactic sugar, storage, messaging, video, canvas, maybe 3D. No one seems willing to deprecate previously undesirable behavior with another mode switch.

I mean, it’s not that bad, but it seems kind depressing thinking about what the Web will be like in 10 years, in 2018. Will we still be limited by what was decided in 1995-7?

I would caution people to look at what happened with OpenGL vs DirectX.

Comment by cromwellian — August 14, 2008

I think comparing the ECMAScript spec to OpenGL and APIs in general is bit like apples and oranges. There really isn’t anything functional that future versions of ECMAScript will allow that are not possible with the current specs.
Things like video support aren’t dependant on language semantics: you can call “” in js today and it’ll be up to you how that’s implemented under the hood – the language will not barf.
I think language design decisions won’t compromise the future of the ajax/open web/whatever-you-wanna-call-it-next.

Comment by LeoHorie — August 14, 2008

Some one needs to create an browser that can render and display sites designed in uncompiled Flex code (MXML + AS), or the equivalent. Let it be able to read HTML and grab out the flash too (for sites that are all flash). We spend so much time bickering about how the web needs to catch up, that it might just be simpler to start over with a new syntax and design. People updated from paper to the web, let them update from the web to something better.

Comment by Jon Hartmann — August 14, 2008

Hartmann: If people really believed that, it would have already happened.

Comment by Diodeus — August 14, 2008

I’ll second the desire for an implementation of MXML/AS in the browser. (Although I’d prefer it if MXML could be implemented and allow any scripting language [eg JS] to manipulate it.)

Comment by eyelidlessness — August 14, 2008

Cold Hard Fact: They majority of Flash developers did NOT transition to AS3… The reason why is the reason that an AS3 like language in the browser would have failed too.

Comment by Chris Phillips — August 15, 2008

Here is the response by Ejscript – an early implementor of the future Javascript.

Comment by mob590 — August 17, 2008

Leave a comment

You must be logged in to post a comment.