Taking a page (or is it a post?) from Brad DeLong's long-running laments on the state of journalism in general, I have been reading the coverage of the Chrome announcement and keep asking myself "why, oh why, can't we have better tech journalism?"
Take, for example, ZDNet's gutter-to-gutter coverage which, I'm afraid, simply ends in the intellectual gutter. Larry Dignan's piece does the profession no favors by simply recycling the tried-and-true blogger formula for traffic generation:
I know about X, Google did Y, which is clearly *all about* X
The best of this flavor of "story" approaches the quality level of a plausible but objectively outlandish conspiracy theory, often pulling together bits of fact with a healthy dose of wild speculation (journalistically couched as the unfounded and unquestioned opinion of some supposedly credible third party).
ZDNet piles all aboard the loony-bin express with Paula Rooney's "analysis" piece, helpfully asking the non-question "is this a prelude to Google acquiring Mozilla?". In what twisted alternate universe would this wild, hair-brained straw-man garner a full 'graf in a legit online publication, let alone a respected print daily? A small, tiny dig into the strategy of Google's Mozilla search placement deal and the infrastructure of the Chrome browser would lead anyone (and everyone) to conclude that Google's interest here is in keeping the browser a viable platform by any means necessary, not that they would ever gain anything by "acquiring" MoCo or MoFo (an even more nutty idea, since it would be difficult for a 501(c)3 organization to transfer resources and assets to a for-profit entity anyway).
The strategic and tactical incoherence continues with the daringly dumb quote:
Larry Dignan of ZDnet suggests that perhaps Google and Mozilla are working together as a tag team to defeat Microsoft’s Internet Explorer, and that Google may perhaps purchase the Mozilla Firefox crew and integrate the two code bases to deliver a kock out punch to Microsoft’s IE. Will Mozilla become Google browser labs? Given the close cooperation of the two projects, it’s more than possible.
The coupe-de-disgrace belongs to PC World, though. After laying out 7 sensible, but "we're just cribbing this from the press release, really" reasons to like Chrome they proceed to indulge in 7 forehead-slappingly idiotic reasons why you might consider something announced as a Beta to be...well...a beta. It feels kinda dirty just linking to it. Luckily, the PC World crew was able to get it together enough to publish a scoop-free "I played with it for 5 minutes" piece that WaPo wasn't embarrassed to run, although the "like being there!" aspect really looses it's punch when anyone can download the beta and, well, be there.
At least with Wired you know you'll be getting fawning access journalism without the pretense of objectivity, but damnit, it'll be well written and vaguely cogent.
I won't even start on the blags. It's to depressing. I'll except Ajaxian and Philipp Lenssen here as they added some useful background from the inside perspective and scooped the story (respectively). "Citizen journalism" has a loooong way to go before it earns a place in the 4th estate, though.
Why, oh why, can't we have better tech journalists?
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