Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

The Appalling State of Tech Journalism: Reflected in the Chrome

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.

Ignoring the incestuous and dubious use of a fellow reporter's speculation as a source for an article, the idea that the Google would want much (if any) of the Firefox team (or vice versa) beyond those which they already pulled away. It does Google no good to reduce competition in the browser space, and one can imagine that there's no love lost at Mozilla over Chrome, particularly after Google shunned the Firefox rendering engine, replaced the JavaScript engine, and re-built the entire visual and end-user experience from-scratch with completely different technology (i.e., not XUL). Good sourcing might have fleshed out the idea and perhaps even made a case for the theory, but alas, that seems far too much for ZDNet to produce on deadline. I mean, it's not like they cover technology for a living...gosh, that'd be embarrassing. Quick tip for the next time they want to write this story: Google just became "Google's browser labs" after giving Mozilla a good long run at it. They're still strategically aligned, but Google seems impatient and is likely most interested in having direct leverage in the browser space (first via Gears and now Chrome) instead of the indirect influence they exerted over Firefox when it was still "Plan A".

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 Importance Of Chrome

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.

Dojo's Query System: No, Really, It's That Fast

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.

Name Soup

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.

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:

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:

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.

Older Posts

Newer Posts