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.
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
- ECMAScript 4
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"
compiler from Adobe) in order to be usable by programmers.
- 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.
- 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.
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)
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.
- Browser vendors can still wring large speedups out of ES3 and 3.1
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.
- 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.