There’s a lot of weirdness going on around the Harmony announcement. This post in particular tries to dig into some of the wrangling that caused the ES4/3.1 split and what the Oslo resolution “means”, but I’m afraid that much of the analysis is being done without the benefit of an inside view of the WG process.
At the risk of talking too much out of school, I want to set the record straight in some ways. First, let me set some facts out:
- ES4, as outlined last fall, was not ActionScript 3. Major changes to the semantics of Adobe’s initial contribution ensured that any truly compliant ES4 implementation from Adobe would have required many concessions, including the inclusion of a client-side compiler. ES4 without
eval()(ala AS3) would never have cut it as a “real” ES4.
eval()feature. Even if they do, there are other (harder to swallow) options available, but no road is cut off to Adobe which was not already long-since abandoned in other ways by the ES4 process.
- JScript (via Windows Scripting Host)
- JScript for the DLR (via Silverlight)
finalkeywords? Solving these issues in the context of the old is easy. In the context of the new, it’s hard. ES4 suffered because it had to do it in a new world which no one was yet writing code for.
So, lets pop up and talk about strategy for a minute. Fundamentally, very little has changed in terms of available strategic options for any of the players:
- MSFT can still hold the web hostage to their ailing WSH VM by continuing to ignore its performance, regardless of bug fixes and syntactic updates. Doesn’t matter if it’s amputation or debilitating arthritis, crippled is crippled. For what it’s worth, my interactions with the MSFT reps on TC39 give me no reason to believe that they won’t be improving their VM.
- Browser vendors can still wring large speedups out of ES3 and 3.1