ES4 News
Some news on language size: the proposed ECMAScript 4th edition (ES4) grammar is a bit more than twice as big as ES3’s, counting several ways (concrete productions, abstract syntax tree node types):
Syntax ES3 ES4 ------ --- --- Concrete 238 490 Type Exprs 50 Classes & Interfaces 23 Patterns 17 Abstract 33 77
This is not out of line given the eight years since ES3, which came less than three years after ES1. Much of ES4 has been developed and shipped in ES3-based languages: AS3 in Flash, JS1.6 and 1.7 in Firefox, Opera’s extensions including array destructuring. And we’re being generous with syntactic conveniences, which desugar to a smaller core language. On the compatibility front, we have a new document on known incompatibilities between ES3 (ECMA-262 Edition 3 the spec, not real-world behavior of ES3 implementations in browsers — note well) and ES4.
Contradiction
Chris Wilson: “… I don’t think the other Microsoft guys ever intended to say ‘everything about ES4 is bad’.” Pratap Lakshman (Microsoft): “We do not support or agree to the current ES4 proposal, either in whole or in part.” Individual intentions can be hard to judge, and anyway matter less than effects. My point is not to guess about intentions, only to point to statements and actions.
Clarification
It’s a relief to learn that Chris’s charge of “shouting down dissent” — confusingly juxtaposed with his words “I think it’s a shame that dissenting opinion has been hidden from view”, which seem to point to the ECMAScript standards body’s majority in a way that left many readers thinking that someone in Ecma TC39-TG1 actually shouted at Microsoft reps during a meeting — was really just a complaint about bloggers “shouting” (which is news-at-11 fodder, don’t you think? I’ve seen shouting from all sides on this one).
That leaves the charge of “ignoring”, which was not aimed at the blogosphere — that accusation was aimed straight at “the TG-1 committee chair”, presumably me (I’m TG1 Convenor). But it is simply false to claim I’ve ignored compatibility concerns or anything else raised by a member of TG1.
Still, if we can make progress by agreeing that bloggers sometimes shout, or show bad manners, I’m all for it. My manners aren’t perfect, and I’m sorry when they fail. But morals trump manners, and the overarching issue before us remains: is it right for ES4 to be stalled in committee, or for ES3 to be forked into a now-hidden “ES3.1”, because Microsoft and Doug Crockford object to ES4 on general grounds?
Consistency
Whatever you think of ES4 (and it’s not done yet — we just released a reference implementation update), the history nicely reconstructed by Neil Mix should make clear that it has been a long time coming, most of the time without anyone refusing to support it “in whole or in part”. The July 2006 meeting notes include a statement from Pratap that ES4 would be implemented in the next major IE release after IE7.
Of course this all changed, starting early in 2007, officially only in March. But why did it change? Was all the pre-history, including Microsoft’s implementation of JScript.NET, a big mistake? Did JScript.NET really “fail”, and fail in any way that bears on ES4 itself or its future on the client side of the web? I think not, and the generalities about breaking the web, or the web not needing to change much, do not explain this about-face from 2006 to 2007.
Anyone who reads the face-to-face meeting notes can see that everyone working on ES4, including me, would work on topics of interest with whomever attended meetings. And we worked together well enough when focused on technical issues. Allen Wirfs-Brock of Microsoft, in particular, is very knowledgeable and insightful.
Rejection
But the cold hard fact, documented in that September face-to-face meeting note, is that the dissenting minority in TG1 rejects ES4 in whole and in part. There does not seem to be room for compromise.
As TG1 Convenor, I’ve tried to keep any “3.1” work in the context of ES4, to avoid a fork of ES3 into incompatible derivative languages. In particular, any ES3.1 should be a subset of the ES4 reference implementation, so it can be tested. This seemed agreeable in March, and Allen reiterated agreement in April.
Since April, it has been impossible for the majority of TG1 to evaluate ES3.1. There has been no work on the wiki, and almost no communication to the majority of TG1 about what’s in ES3.1 or how it will be tested for backward compatibilty with ES3 and forward compatibility with ES4.
Do The Right Thing
Neither a hidden and unready alternative proposal, nor general objections from a minority in the group, should halt a standard in progress. ES4 should be delayed or abandoned only on technical demerits, demonstrated specifically. There are enough implementors working together to make a standard, and ES4 as it has evolved has always been the expected successor standard. To block it based on general fears and opinions prejudges both the final standard and the market for it. The market, not Ecma TC39-TG1, should decide ES4’s fate.
It should be clear by now that the majority of TG1, who favor ES4, want to keep the group from splitting, or otherwise risking incompatible forks of ES3. Everyone loses in that scenario. We wouldn’t have spent all the time in the wiki and at meetings if we all, including me, didn’t want a win-win outcome for all players. And I personally suggested to Chris in March that Microsoft could be a big winner by backing ES4 and supporting it in IE.
Is it still possible for everyone to win? I have to say I’m not as positive as I used to be. If we all work on testable compatibility via the reference implementation, then I’m somewhat more hopeful. But it will take a better stance than rejection of ES4 “in whole [and] in part” to get somewhere.
I think you are assuming Microsoft is as interested in the technical merits as you are. I think Microsoft is likely also looking at the “market share” angle, and possibly has determined that an open script language would be a threat its dominance.
I think Microsoft is likely deliberately “sabotaging” ES4 by helping cause a split into ES3, ES3.1, and ES4, and, of course, Microsoft’s own proprietary solution. That way, the competition is fractured and Microsoft’s offering is the only one that exists and runs well on the majority of computers (with Internet Explorer).
I know this might sound like a conspiracy theory, but it is consistent with Microsoft’s past actions, and the fact that Microsoft is primarily profit (as opposed to ideology) driven.
I suggest you keep the door open for Microsoft, but you don’t waste too much time futilely trying to convince them of the technical merits – they already know … and don’t care.
Peter: you could be right; there’s evidence (private communication from people I trust, who are witnesses to secret Microsoft outreach attempts) for the idea that they aim to fork ES3 in an incompatible fashion from ES4, and anyway minimize change from ES3 in “their” fork.
But I’m going to proceed the only way the Ecma group as chartered can go: trying to uphold a single, compatible evolutionary pathway. That requires finding common ground and assuming the best from everyone. This is not easy, and I sometimes fail. It seems necessary.
/be
Since the last time the standards body has agreed to something has been 1999, I think delay is simply stupid. Please keep moving forward.
I use JavaScript as a full-time profession and must agree that there are things that need improvement. The issues with Javasscript are completely obvious to anyone who uses it every day. Simply put, it has stagnated and needs improvements. The web pages we were doing in 1999 are nothing like what we are doing now! So, it stands to reason that we need to improve the language.
You must change or die!
As far as incompatibility – I think you need to address this with specific test cases. You must put together a massive automated set of Javascript tests to validate compatibility. I suspect that the complaints revolve around what are really Microsoft bugs – which, obviously require a bug fix from Microsoft, but not necessarily a change in the standard!
As far as the language getting too large, that’s really best determined by the number of lines of C++ code it takes to implement, the memory footprint, the execution speed. So, I would suggest that the reference implementations better darn well demonstrate that these language changes are wise. After all, these standards will go into mobile phones!
As far as the language getting too complicated for people just trying to hack some code – this seems a spurious argument as long as the language is backwards compatible. So, just make sure it stays backwards incompatible.
I urge you to do the best job you can. My long-term livelihood depends upon you.
Scott.