Harmony Fallout

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.
  • Adobe had not donated “ActionScript 3” to Mozilla nor Open Sourced ActionScript 3. Adobe had donated a high-performance byte-code VM which a separate front-end compiler targeted. It is absolutely possible that the Tamarin VM can and will run whatever syntax for the next version of JavaScript is ratified. The design of the VM is, of course, predicated upon the language semantics but lets not confuse the front-end compiler and the language that it consumes with the VM and byte-code format which it executes. The front-end compiler was not donated to Mozilla (although something similar exists in the OSS’d Flex SDK) nor does it ship inside of the Flash player today. Adobe can continue to evolve their developer languages and byte-code VMs independently so long as they never ship an 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.
  • Like Adobe, Microsoft has jumped ahead in the evolution of JavaScript via the seemingly forgotten JScript.NET. Like Adobe, Microsoft has had to come back from that position to meet the web where it really is. Microsoft now ships 3 – yes, that’s right, three – JavaScript-ish languages which are capable of running in a browser:
    • JScript (via Windows Scripting Host)
    • JScript.NET
    • JScript for the DLR (via Silverlight)

    Make no mistake about it, these are all separate implementations which likely share little if any code. The DLR variant is even new in the last several years. Creating a new JavaScript compiler and runtime is not an overly onerous task for MSFT and clearly not one that will take a long time should the occasion arise. What’s confusing and can likely be tied to strategic wrangling is the puzzling lack of progress in the WSH version of JScript (the one everyone uses day-to-day). Any strategic discussion of JScript as a platform needs to start from this perspective.

  • Much in ES4 was new. The gradual typing system (which I’m a big supporter of) was something of a large-scale experiment coupled with as much rigor as I’ve ever seen in a standards body in proving things out in an RI. The Class system (which I wasn’t a big supporter of) needed to marry class-based inheritance to prototypal inheritance in ways which were new. ES4 contained many good features and syntactic forms which were borrowed from other places, but as Brendan Eich has said, it was a process of synthesis plus invention. In my opinion, much of the failure of ES4 as an initiative can be traced to significant failings of ActionScript 3 as a language. AS3 is a Java-like language with a Java-like execution model. JavaScript is a dynamic language with a dynamic execution model. The gulf in expectations between those camps turns up in every corner of the language design. For instance: what does it mean to load new code? Are classes forever “closed” or can they be re-opened? Do you really need the static and final keywords? 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.
  • Adobe can still chose to implement a language which implements an ECMA spec. They can do this any time they damn-well please. It may not align so cleanly with their current technology roadmap, but it’s absolutely feasible and when Mozilla ships a “regular JavaScript” front-end to the Tamarin back-end, it’ll be even easier. Note that this plan can be done in parallel with AS3 evolution since Tamarin (as a VM) need not be aware of any language semantics on its own.
  • Browser vendors can still wring large speedups out of ES3 and 3.1

What died here wasn’t Adobe’s attempts to “own” a spec. If there were such hopes in play, they had been quietly put down one rational, backwards compatible decision after another in the year preceding the Oslo meeting. What died was an assumption that the web can evolve without implementations being out in front of the spec. AS3 was one implementation of a JavaScript-like language that might have been a contender for crown of “the next one”, but so was JScript.NET. That neither of them “won” simply because they had been built in good faith is as true a sign as I can find that the process is working. Adobe gets it. Lets end the silly meme that “Adobe lost” or that “Microsoft won”. The game has hardly begun and it won’t be settled in a standards body anyway. What matters – and what we all need to keep our eyes keenly trained on – is what the big implementations do in the way of compatibility, performance, and feature set once ES3.1 arrives.

5 Comments

  1. RichB
    Posted August 15, 2008 at 2:07 am | Permalink

    I think you’re a little confused about WSH. WSH is Windows Script Host. It has nothing to do with web browsers – it is a host for Active Scripting languages within Windows and can be executed via the cscript.exe and wscript.exe binaries.

    WSH is not a virtual machine, it is a host process which communicates with Script Engines via COM interfaces. In fact, VBScript and JScript have separate ‘virtual machines’ – due to refcount vs gc semantics.

    There are several Active Scripting hosts:
    * WSH
    * Internet Explorer
    * IIS (ASP Classic)

    So, Internet Explorer is an Active Scripting host, which is how it’s capable of running VBScript, JScript, ScreamingMonkey, Python etc

  2. Posted August 15, 2008 at 2:22 am | Permalink

    Rich:

    Of course, you’re right, WSH and ActiveScripting are different. It was lazy and inaccurate of me to conflate them. The clarification is appreciated.

    Regards

  3. Posted August 15, 2008 at 5:24 pm | Permalink

    Great article,

    But believe it or not, they have more than 3 interpreters running JScript side by side:

    JScript in the WSH (version 5.6 – 5.7 WScript global),

    Classic ASP JScript (5.6 – 5.7, different global)

    JScript compact profile (ECMA-327)

    The browser JScript (5.6)

    JScript.NET (CLR, version 8.0)

    ManagedJScript (DLR, complete rewrite)

  4. Posted August 17, 2008 at 4:44 pm | Permalink

    As an implementor of ES4, I agree that the gradual typing system was very nice to use. Being able to define APIs and library definitions exactly and document (and enforce) the required types is much easier than alternative approaches. Many other parts of ES4 were very nice and I hope much is learned in ES-Harmony.

    I agree also that implementations must lead the standards process to test ideas and solutions. Jscript.NET, ActionScript and Ejscript have all tested new concepts.

    Ejscript (http://www.ejscript.org) will evolve and track ES-Harmony, but will keep quite a bit of ES4. Much like ActionScript, it will have extensions if ES-Harmony does not adopt some of these features from ES4.

  5. Posted August 18, 2008 at 12:10 am | Permalink

    As hot as passions seem to have been over the last year or so, I think the main concern for most working web developers is not the feature set or syntax of ECMA3. Speaking for myself, my wishlist looks like this:

    1. Faster end-user adoption of newer browsers, promoted by browser vendors (Microsoft, you and only you can kill IE6, the single greatest gift you can possibly give to the Web of 2008. Just do it.)
    2. Improved browser feature set and performance (support for Canvas, HTML5)
    3. Extended CSS features (constants, macros, more flexibility in specifying layout, animations, etc.)
    4. Continued improvements in VM performance for the existing ECMA3 language
    5. Improvements to/better implementations of DOM and other standard APIs

    Actually, language changes to ECMA3 are WAAAY down on my wishlist. In fact, I’d rather the parties involved invest more energy in discussing these other issues, as the shortcomings of ECMA3 — numerous though they may be — pale in comparison to the desire for such improvements. I can only speak for myself, but I imagine many in the greater Web community might agree.

2 Trackbacks

  1. […] We have other postings going on in the community too. Douglas Crockford writes an opinion on how The Only Thing We Have To Fear Is Premature Standardization, Mike Chambers wraps up the thoughts of Adobe on ActionScript 3 and ECMAScript 4, and Alex Russell talks sense into the fallout. […]

  2. […] Here’re some voices from the Flash and Dojo community: The future of Actionscript | JavaScript Stalled, AS3 Orphaned – Microsoft to Blame? | Ru Roh! Adobe Screwed By EcmaScript Standards Agreement | ActionScript 3 and ECMAScript 4 | Thoughts on Harmony | Harmony Fallout […]