Polishing the Chrome

I’ve just finished reading Scott McCloud’s comic book introduction to Google Chrome, Google’s new browser that will be released tomorrow in some fashion. I am very intrigued by this new player and I think McCloud’s work is an accessible introduction to the basic ideas behind the design. (Of course, it could have been summarized in a single page or blog entry much more efficiently than being spread over 40 pages but McCloud did a great job in explaining things.)

When Jason Kottke first began speculating that Google was working on its own browser, I dismissed it just like I did his notion of Google OS—a Linux distro with Google branding. (I’m not sure Kottke can count this as a win, by the way, since five years worth of bupkis does not make for a successful prediction.) It seemed like an overreach for Google, well outside its focus. The intervening years have proven that Google views its mission as pretty much everything on or related to the Internet.

But I think Google Chrome makes a lot of sense. For one thing, Google now has some skin in the game. It can act in such a way that Microsoft and Apple have for so long: if there’s some special feature that it would like to be prevalent, it can implement it in its browser and propose it as a standard to some friendly standards body. Microsoft got XMLHttpRequest in there early (among many other examples) and Apple got the canvas element accepted in exactly that way. Google, previously, had to work within the Microsoft-Apple-Mozilla constraints and now it gets to be the interloper, the mole. I think that’s a powerful position and likely well worth whatever money Google is throwing at this project.

Also, it clearly has some innovations to bring forth. Putting each tab in its own process is genius. At once it solves the issue of memory leaks and the expansive memory footprint that afflicts every modern browser as well as protecting the user from malicious code in a very effective way. Google also developed its own Javascript virtual machine called V8 to couple to the open-source WebKit. Refactoring the Javascript engine has become a hobby with the browser makers: SquirrelFish from Apple, TraceMonkey from Mozilla, and excuses from Microsoft (paraphrased thusly: “Oh, Javascript isn’t really that important. We focused our performance improvements in IE8 on everything else that stunk about IE.”) The neat thing about Google’s Javascript optimizations is that they took a completely different approach to speeding things up, which means the other browser makers will likely copy them. Innovation in the browser space is an unmitigated good thing.

Finally, as the most popular set of properties on the Internet, Google can drive adoption of its browser by offering improved performance and heightened functionality when visited using Chrome. It can tie its sites into the browser in a way that it never could if it weren’t a browser maker itself.

In the end, each of these reasons for developing its own browser also benefit the user so I applaud Google’s decision and hope that they can succeed in following through—which has always been a problem in Google’s application ADD environment.

[UPDATE (9/2/2008): Google Books has a better version, so I’ve updated the Google Blogoscoped link to point there.]

Advertisements

%d bloggers like this: