Infrequently Noted

The rumors seem to have been true...the gBrowser is real. And it looks like it will simply be awesome. To my friends who have been toiling on it in deep secrecy for so very long, congratulations. Yes, yes, more to do, blah blah...screw that. You shipped! Huzzah!

So what does Chrome mean for those of us who aren't breaking out the champagne? Well, first, it's the second sign (after Gears and YBP (har!)) that the content authors are taking back the web from the "browser guys". I've been fascinated for the last 6 months or so by the strategic mis-alignment which results when both the browsing and authoring experience in the hands of organizations only care about one but not the other. Mozilla gets paid by search-box revenue and users download it because it's better for browsing, therefore Mozilla is incented to build new ways to browse, but their investments in content are somewhat mis-aligned (and, frankly, it shows). Google and Yahoo, on the other hand, are critically dependent on the content getting better, so they produce plugins to augment HTML in un-intrusive ways. Chrome crosses over into the browser business from the perspective of content, and it also shows, albeit in a good-ish way. I guess we'll need to wait and see how browsing-oriented Chrome gets (e.g., will it sprout an extensions platform – ala Firefox – or will the propsect of an ad-blocking plugin for the Google browser make that proposal D.O.A.?).

Regardless of how Chrome evolves as a product, the important question now is: how will it be distributed? The obviously non-evil thing to do is to say "look, it's great, it's free" and hope that the world discovers it on its own thanks to word-of-mouth and/or leverage of the Google brand. Given that Chrome delivers new awesome things which are end-user-visible (some "end-user-awesome", if you will), there's some real chance that Chrome can get to roughly Firefox level market-share without breaking too much of a sweat. Not that Firefox's market share is anything to really covet, given that MoFo/MoCo have been toiling at it for a decade now. To get real, honest-to-god leverage out of this process, Chrome is going to need something like 60+% market share, and that means changing ingrained user habits. I put the probability of that happening without distribution channel love at roughly bupkis.

Microsoft killed Netscape by bundling the browser with the OS. Apple is making inroads by bundling. Firefox is even getting aggressive. So where does this leave "don't be evil"? Given the toolbar promotional deals which Google has cut in the past, I think there's some organizational capacity inside the Goog to use the distribution channels they've already created as a way of getting to critical mass. What I don't see, though, is a view of how to bring the mission of Gears into alignment with Chrome (or vice versa). They're both important, but Chrome is a long-term bet while Gears is the near-future solution. They are not in opposition, but their strategies for gaining leverage over the problems facing content authors are very different.

We need what Gears can offer to every browser right now while Chrome dukes it out for market share on the browsing experience merits. Hopefully, if nothing else, the Chrome installer will add Gears to other browsers on the system that users install Chrome to. Even if they don't pick the googly experience for browsing day-to-day, perhaps Chrome can still serve to give new tools to the content-author side of the house. Other browser vendors won't do such a thing since they win or loose on an exclusive "I must replace the other guy" basis. Here, Google (and by "Google", I mean "the open web") wins either way. Hopefully Google's interest in making the content experience better trumps the "we're all browser guys now" instinct in this case.

We'll find out tomorrow, I guess. Here's to hoping.

As outlined by JQuery lead John Resig in this post, it's hard not to notice how much Dojo's query engine stomps on the the competition on current browsers. Dojo will load even quicker when we're able to remove the XPath branch in the query engine which is currently only being kept on life support for the benefit of Firefox. The rest of Dojo has been designed with the same eye to real-world performance factors in mind, hence the build and package systems which help you implement Steve Souders' performance recommendations gradually, without major code changes.

Regardless of how good it feels to see our numbers recognized for all the hard work that has gone into the Dojo design, I think it's also good to keep them in perspective. Most of the available query engines are "fast enough" – although there's really no reason why your query engine of choice should be twice as slow as Dojo's, given that ours is 100-point Open Source. Having a native implementation is nice, but the primary benefit now is in reducing the number of bytes we need to send on the wire, not in actual query speed advantages. Making queries faster isn't in the critical path for improving the real-world performance of any Dojo apps I know of, and I bet the same is true for JQuery users. Reducing the size of the libraries, on the other hand, is still important. Now that we're all fast enough, it's time that we stopped beating on this particular drum lest we lose the plot and the JavaScript community continue to subject itself to endless rounds of benchmarketing.

There still seems to be an amazing amount of FUD going around regarding the Harmony announcement. There is clearly a very different perspective from those who have been sitting inside the WG for the past year (as Kris Zyp and I have been lucky to). Inside the WG, the change seems a welcome way to break a logjam of reasonably held opinions of people who are all acting in good faith. From the outside, it all looks like confusion and game-playing.

One of the things, though, that keeps getting me frustrated as I read the "coverage" is that the names people use are confused. Probably because the names are confusing. Here's a quick glossary:

ECMAScript 3

Aka: "JavaScript", "ES3", "ECMAScript 262-3", and "JScript".

The current JavaScript that every browser implements (more or less). This is the current ratified standard and represents the 3rd edition of the ECMAScript spec. It is very old. Nothing else in this list is (yet) a ratified standard of any sort.

ECMAScript 4

Aka: "ES4", "JavaScript 2"

A new language which was to be mostly backwards compatible but add optional (gradual) typing and class-based inheritance. Based loosely on Adobe's ActionScript 3. This is the language effort which died as a result of Harmony.

ECMAScript 3.1

Aka: "ES3.1"

A set of small additions to ES3. Working drafts are available and will likely go to the standards process with few changes. Planning for this edition was started at Microsoft and Yahoo's behest late last year, causing the split in the working group which has been healed by the Harmony announcement.

ActionScript 3

Aka: "AS3"

Adobe's current JavaScript-like language, only with many features lifted from languages like Java which also enforce types and class-based semantics. This was the starting point for much of the work which became known as ES4.

Tamarin

A JIT-ing byte-code virtual machine (VM) which is at the core of the Flash Player and was donated by Adobe to the Mozilla Foundation. This is the VM that runs ActionScript 3 code today but will likely run "real" JavaScript for Mozilla in the future. It is not a full implementation of ES3 or ES4, but instead implements its own byte-code and needs to be wedded to a "front end" (like the ActionScript 3 compiler from Adobe) in order to be usable by programmers.

Tamarin-tracing

A VM which implements the same byte-code language as Tamarin (known as "ABC") but which is designed for use in mobile devices and other scenarios where code size and VM footprint are important. It implements trace-tree JIT-ing as a way to speed up hot-spots. Also donated to Mozilla by Adobe.

TC39

The name of the ECMA technical committee which is chartered to evolve the JavaScript language.

Harmony

A new code-name for a language which is to come after ES3.1. It will feature many of the things ES4 was trying to accomplish, but may attempt them from different directions and will focus much more on incremental, step-wise evolution of the language.

JavaScript 2

A now-defunct name. This name was originally given to Waldemar Horwat's first proposal at a large-scale evolution of the JavaScript language in 1999. That effort did not succeed (although Microsoft implemented some of it in JScript.NET) and subsequent work via the current TC39 charter to build ES4 has sometimes been given the name "JavaScript 2", but it never really stuck. Not a name that describes any ratified standard or current proposal.

ECMAScript

The formalized name of the JavaScript language. Since Sun Microsystems owns the name JavaScript and has no idea what to do with the trademark (but has been benevolent thus far), the ECMA committee which standardized the language was forced to adopt a different name.

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.

So the announcement about "Harmony" is up over at Ajaxian. Long story short: this is really good news. I won't get into the background on this since at this point it doesn't matter and much of it is embargoed behind ECMA rules anyway, but here are the key points from my perspective:

• ES 3.1 is on target to be short-run "cleanup" language and work after that will proceed starting from that baseline and not the previous ES4 proposals.
• We can probably have movement on ECMAScript.Next very soon. All eyes are on Redmond to see what the JScript team will commit to for IE 8.
• Both sides of the working group have put down the crack pipes. The new language won't be Java (protests not withstanding) or ActionScript 3 and it'll be a lot better than the lowest-common-denominator language that we're writing to now.
• ECMAScript.Next will not be able to be cast as a "performance improvement" on the basis of a lazy understanding of what makes JavaScript go fast. Classes are for structuring code and (sometimes) managing complexity. Types are for saying something about code and APIs. VMs are for speed. Implementations should be able to nail the "types/classes==speed" form of mental illness dead in the interim.
• The working group is working. I have a lot more faith in this process than I did 6 months ago.

Commenting on how things will evolve from here is absolutely premature...no one really knows. What's exciting, though, is that the important implementations of the existing language and their developer constituency seem to be in the drivers seat and progress is now predicated on solving their pressing issues. If a language like ES4 is going to evolve and be successful it will now need to prove that it can grow a serious constituency of its own before it is given permission to throw the rest of the web under the bus.

Thank goodness.