Reflecting Upon Chrome

By Kurt Cagle
September 3, 2008 | Comments: 2


Scott McCloud may not have intended to become the icon for Google's most recent efforts, but the choice of the veteran cartoonist (and semiotician) was a master stroke on the part of Google for introducing their new web browser, Chrome. McCloud's spare, clean lines, intellectual positing and delicious manipulation of symbols could not better have captured Google's secret skunkworks project.

McCloud was commissioned to create a series of web comic pages that would explain the inner workings of the new Google Chrome browser, intended for release later this month, but a fan of McCloud's work apparently leaked the comic early, forcing Google to announce their latest (and arguably most audacious) project to date.

As it turns out, the extra month or so of work probably wouldn't have made that much difference - even in beta, it is likely that Chrome has completely changed the balance of power on the web. Rumors that Google has been working on a web browser have been repeatedly heard for years now, but the assumption has long been that Google's physical proximity to Mozilla's headquarters and its general commitment to server-side technology precluded any real benefit for Google in building a browser of its own. Those assumptions, however, appear now to have been wrong.

Chrome represents a change in the way that Google is choosing to play the game, putting them on a far more equal footing with the other browser vendors. Chrome is an aggressive assertion that it is not playing with the rules that Microsoft has set out (and may also be a not so subtle slap against Redmond about their attempts to take over Yahoo). Google has the penetration and the reach to get a browser anywhere that Internet Explorer can go, and it also provides a reminder to Mozilla that even they are mortal ... and that the sometimes legendary intransigence that the Mozilla developer team has shown about going its own way, sometimes at the expense of those very web standards that they champion, may well be about to end.

Tabbing Chrome

Before digging into these implications, however, its worth spending a few moments discussing what exactly Chrome is ... and how it presents itself. I cannot help but wonder if more than just the web comic was commissioned of Scott McCloud. The interface is Google spare, going for a lightweight minimalism that sometimes makes you wonder if you're actually in a browser at all, and the icons and interface touches all have that "this is not a pipe" feel to them that seems so emblematic of McCloud's work.

The design team finally did something that Mozilla had started to do, but never quite complicated - it flipped the tabs around to the top so that they are in fact the central part of the browser. In essence a tab is a browser. If you drag a tab on to the desktop from one window, it creates a new window holding that tab. If you drag a second tab from the first window to the second, then the tab appears in the new window next to the previous tab.

This bit of legerdemain may seem like nice eye candy until you realize (thanks to Mr. McCloud's wonderful comic) that the appearance goes deeper than just a bit of visual trickery. Each tab runs in its own process space, under its own set of threads. If you go to a tab pane where an unbreakable infinite loop occurs in Internet Explorer or Firefox, you might as well kill the browser process entirely - you won't be escaping it alive.

In Chrome, however, if an infinite loop occurs (or some other process locks the window), the only thing that locks is that window. You can continue working with other tabs just fine, even as the dead window displays an graphic remarkably reminiscent of the old dead Macintosh icons of yore. Not only does this make debugging web applications much less stressful, it also means that if you have a blog entry half finished in one pane, and an email entry half finished in a second, you haven't lost all of this work because of an errant web page.

On this topic, the influence of Google Gears is subtle but profound here. When Gears was announced early last year, most people thought that it was simply a mechanism for making "offline" applications possible. While this certainly appears to have been achieved, a larger goal for Gears, of serving as the foundation for many of the asynchronous operations that seem both necessarily and not well supported elsewhere in contemporary web applications.

This browser has a memory, one that acts not only to insure that in the event of a catastrophic failure that you probably won't lose your data but that also is able to intelligently analyze your patterns - keeping track of those sites that you visit most often, for instance, and displaying screen-shots of these as the initial pane of a newly opened anonymous tab. This feature seems obvious in retrospect, but its amazingly useful in practice. I work heavily through my browser (indeed, I'm opening up such apps as word processors less and less often over time), and for the system to be able to present to me those places that I spend most of my time, without me asking the system to remember these, is very helpful indeed.

Now, suppose, for a moment, that there are places that you don't want the browser to remember - places where a spouse or significant other might raise an eyebrow perhaps, or at least discover a surprise that you'd rather keep secret. It's possible in those cases to launch what Chrome calls an incognito window, though what I suspect may in time become known as "porn mode". Anything launched from within this window does not get remembered - period.

Admittedly, for all of the potential for illicit use, this also can serve as a very useful mechanism to launch e-commerce sites in, so that if someone does manage to get access to your laptop for instance they can't just surf through the History to get access to your bank account info or your credit card numbers.

Okay, after leaving the red-light district (including its icon, the rather disreputable looking guy in the trench coat - something that I had to chuckle over) it's worth looking at one other benefit that these in process tabs offered - a much lower overall memory footprint.

Again taking my cue from Scott McCloud's wonderful comic, an application such as Internet Explorer or Mozilla Firefox work by allocating new memory every time a new tab is opened. However, because both tend to have fairly conservative garbage collection (though Firefox 3 is much better about this) memory that gets allocated isn't necessarily always completely released, because of the single-threaded nature of the collection. This means that the longer you spend online, the more fragmented your memory becomes, and the more sluggish performance becomes. Firefox has developed a reputation for being a memory hog precisely because of this behavior.

Because Chrome tabs control their own processes, they have a much tighter handle on memory allocation. In essence, a Chrome tab is a separate browser from a memory standpoint, and as such it is far better at using the native garbage collection inherent in the operating system when the tab closes than a Firefox tab does, since the latter has to create its own garbage collection layer. The separate process approach costs a little more in terms of initial memory overhead, but I was surprised to find when running the same pages in Chrome and Firefox 3 that Chrome was taking up perhaps 25% of the memory that Firefox was.

One other reason for this difference is the very successful use of the Webkit core as the foundation for Chrome. Webkit is well known as the engine that runs Apple's Safari browser as well as the Konqueror browser, and has long gained plaudits in the industry for both its efficiency and the fact that the Webkit core is open source.

Revving Up JavaScript with V8

However, as with Safari and Apple, Google realized that there were other efficiencies that it could introduce, not least of which being a concept that was radical as recently as six months ago but is now finding its way into many contemporary browsers - the use of a JavaScript virtual machine and "trace tree" algorithms.

The Google V8 team out of Denmark were handed the challenge of making JavaScript much more efficient in the browser. Their solution, based upon recent work in rethinking parse trees, depended upon looking at common JavaScript constructs and applying localized optimizations that handled the 95% of cases while providing a way of "learning" from the remaining ones. These kinds of optimizations are pretty much standard for virtual machine supported languages such as C# or Java, but the idea of applying these to JavaScript has largely been resisted because of its dynamic type nature.

However, it turns out that such optimizations can be applied quite effectively to JavaScript, making it in some cases close to the speeds expected from more traditional "compiled" languages. This approach is not unique to Chrome - Brendan Eich outlined a similar Trace Tree mechanism to me in an interview with him earlier this year that is being incorporated into Tamarin for Firefox 3.1.

However, the implications in all cases is that JavaScript running in browsers will become (or are becoming, as Chrome illustrates) comparable in speed to stand-alone applications written in compiled languages. This should have a profound effect upon the role that such applications have moving forward, and raise some uncomfortable questions about the future of stand-alone applications.

I'm hoping in the near future to put Chrome through its paces in terms of how well it measures up on the JavaScript front, though its encouraging to me that, after nearly a day of surfing through some fairly heavy JavaScripted sites, I've seen few indications that Chrome's managed to raise a sweat.

Exploring Media

One of the metrics I've used in the past for how well a web browser performs is the degree to which it handles various types of media, including images, video and sound. On that front, Chrome seems to be doing quite nicely - in the Vista build, I was able to easily watch AVI files, MPG video, Flash FLVs (indeed, Flash in general seems to do quite well in Chrome), Quicktime MOV files and others without significant hiccup or notification that I was missing this or that critical plug-in. Typing about:plugins into the main URL bar (which also, conveniently doubles as the search bar) brings up an exhaustive list, including Real Player files, Adobe Acrobat, Silverlight and Yahoo application state.

I've heard, anecdotally, that Silverlight has some problems running in Chrome, but haven't yet run into an instance where that seems to be true.

SVG aficionados will be happy to know that SVG 1.1 is supported, though as seems to be the trend for browsers, is not supported completely. Animations are lacking, masking is a little sporadic, filters appear not to be supported at all and there's some issues with adding gradient fills to text - which puts its support below that of Opera 9.5 and roughly at par with Firefox 3 ... and once more makes Microsoft the odd man out with regard to SVG support. A cursory stroll though the Open Clipart collection was, for the most part, a fairly satisfying experience, as Chrome seemed to display nearly all of the images that I could throw at it.

I hope to get a better idea soon about whether additional SVG support is in the works, but even from the rather dreary state of support for SVG in browsers in 2006, the recent state of SVG in browsers is looking encouraging, to say the least. Because Chrome is built upon the WebKit core, the support for Canvas holds true as well.

CSS support too is dependent upon WebKit (from all indications) and as such is extensive, though many CSS 3.0 features in particular are still "experimental" (given the rather ambiguous nature of the spec's current status), and thus require a "-webkit-" prefix in much the same way that Mozilla uses the -moz- prefix.

The one facet that is not yet available in Chrome (and that's unclear will ever be available) is the ability to extend it with third party add-ons a la Firefox, one of the biggest selling point of that particular browser. It's not an insignificant omission - I firmly believe that Firefox has made the inroads that it has because of its easy extensibility, and for Google not to supply this could prove a deal breaker for a lot of devoted Firefox fans, not matter how fast the browser.

One other aspect of Chrome that may prove intriguing is the use of the libXSLT as part of the WebKit environment, something which has definitely been ported to Chrome. XSLT support in Firefox, based as it is on the older (and definitely more primitive) Transformiix libraries, has long been substandard compared to such support elsewhere. LibXSLT is a considerably more robust engine that, especially in conjunction with the V8- based JavaScript virtual machine, may actually kick start XSLT usage on the browser again.

Chromatic Implications

Google's Chrome is a game-changer - there is absolutely no question in my mind about that. Google's entry into the browser space raises a large number of questions, not least of which being the degree to which Google will start tailoring its services specifically to work with its own browser.

This is not a trivial question - Google has become the de facto portal to the web for billions of users globally, and by making certain services available only through its own user interfaces could create a potential for lock-in that would make the long-standing assumptions about Microsoft Office's domination of that space seem minor in comparison. Indeed, while the benefits of providing such a browser may be obvious to Google, the drawbacks, including the threat of anti-trust actions, should not be forgotten if they wish to build Chrome into a first class client on the web.

That this complicates the already dizzying realm of browser selection also becomes an issue, and I suspect that web developers may not necessarily be excited about having to learn about the intricacies and idiosyncrasies of yet another browser. I think it encouraging that Google has a place on the ECMAScript 3.1 (a.k.a. Harmony) committee, and my first pass impression of Chrome's JavaScript is that it hews remarkably close to the pre-1.7 Mozilla JavaScript implementation which seems to have become the de facto "base" that most of the web is standardizing on.

The choice of Chrome as a name is perhaps inauspicious. Microsoft's ChromeEffects represented the first example of an XML driven graphical user interface in the late 1990s, an effort shelved for several years because computers were simply not powerful enough - much of these later re-emerged in Silverlight. Similarly, chrome is a critical part of the Firefox milieux, a point that will likely cause more than a little confusion among browser developers.

Ultimately, I do not see Chrome as being something produced to gain marketshare (at least not directly). It's purpose may be more subtle - Chrome is a statement. It's intent is to give Google some say in the evolution of web standards from a browser developer standpoint, to assert that here as elsewhere they expect, at a minimum, to have a seat at the table.

John Lilly, CEO of, recently asserted that he wasn't worried about Chrome; Google is signed up to contribute both financially and technically to Mozilla until 2011 at a minimum, and relations between the two companies remain cordial. Whether this is whistling past the graveyard remains to be seen, though, especially as the announcement of Chrome could be seen as a direct challenge to Microsoft's Internet Explorer's (7 and the upcoming 8's beta) existing market share, which Mozilla too would like to eat into.

Chrome may also have a negative impact on Opera, especially given that Android, Google's open source telephony application, is similarly driven by WebKit. Opera has established itself as the primary browser on hand-held and telephone units, but between Safari (itself a WebKit based application) on the iPhone and Android's WebKit interfaces, Opera's potential for growth in that market may be limited.

As to what Chrome means to Microsoft, I suspect strongly that there are a number of people on the Internet Explorer 8 team that are tearing Chrome apart in order to understand how it impacts them. Even with the backing of Google, I suspect that adoption of Chrome will likely end up being far more sedate than Firefox's meteoric rise, but if you look at Chrome not as an end-user product but as the basis for additional applications coming out of Google, then Chrome certainly has to be worrying people in Redmond.

Given Google's propensity to release applications that may appear "harmless" but that can, seemingly overnight, change the way people think about data, then giving Google a browser of its own to play opens up the door to dedicated clients for viewing and editing medical and business information, stand-alone widget toolkits, integrated mail clients specifically designed to tie into Gmail, geoinformatics systems that integrate GoogleEarth/GoogleMaps with dynamic real-time displays and so forth.

Indeed, this last point gives a very key insight into how Chrome plays into the overall Google strategy. Google Earth currently supports an in-client web browser (in this case IE), but the integration is fairly awkward and of course completely non-portable. By running Chrome instances as in-proc views in Google Earth, not only is Google much more able to work cross platform, but they are also able to build more effective hooks for back-channel communication between the two applications, making such things as real-time resource distribution tracking systems feasible (especially when combined with Google Maps interfaces that do the same thing, possibly tied in with Chrome Canvas overlays).

The one thing I'm a little surprised not to see at this stage is a more beefed up forms strategy as part of the core toolkit, a la XForms. The presence of something like that has the potential to put a significant dent in the enterprise application space, as well as the medical space that they have already invested fairly heavily in.

Moreover, unlike Microsoft, Google has absolutely no need to stay locked on the Windows platform (Chrome itself is still in beta on Windows though Mac and Linux versions are under development), which means that these same applications can be rolled out on the same day on Macintosh and Linux boxen, further weakening the hold Microsoft's grip on the desktop that's already beginning to look pretty tenuous.

Couple that with high performance JavaScript environments (furthering that language's increasingly dominant role as the "BASIC" of the twenty-first century), integrated 2D (and likely 3D) graphics, support for Flash (and rumor of support for Adobe Air, though I haven't seen this yet) and what emerges is that Google Chrome has the potential to be a credible threat to Microsoft.

Scott McCloud is one of those people who you should watch carefully, because he has the habit, using deceptively simple graphics and ideas, to coerce you into understanding profound concepts. His involvement with Chrome should be seen as an interesting endorsement. Something unusual is about to happen here ... pay attention.

Kurt Cagle
is Online Editor for O'Reilly Media.

You might also be interested in:


In regards to that their goals is not to gain market share and just get a "seat at the tables" I'd like to inform you of that the landing now has a link to download Chrome and they have between 1 and 3 percent market share already less than 48 hours after their release according to some website logs...
This is FAR more than just a "ticket to a seat at the tables"... ;)

Which means that they should have the market about sewn up by the end of the month, right? ;-)

I suspect that over the course of the next few months, Chrome will get a very healthy tryout from a lot of people. What I'd be much more interested in are the actually usage survey logs about six months from now. It will almost certainly cannibalize some Firefox usage (especially those that have felt frustrated with Firefox memory problems).

Given its distribution channel I also suspect it should also hit a not insignificant number of IE users who utilize Google via their homesite - especially since a lot of them are less likely to have been among the proportion of users that got onto the viral bandwagon of Firefox.

One question in my mind is the degree to which community extensions play a factor in people's browser usage, and how soon such an extensibility mechanism will end up in Chrome. If, as I suspect, it makes up a significant part of the user experience, then its likely that Chrome will languish if it fails to deliver there.

A second question is the degree of vulnerability that Chrome has - given that Safari on Windows has not really had that much of a field test, I'm not inclined to cede that security under Webkit is as solid as its evangelists would have you believe.

Finally, keep in mind that all of this is going in amid a backdrop of some fundamental changes all through the browser space, and the changes introduced by Google (which does not, in my mind, have all that solid a track record for application development, though a solid one for paradigm changing applications) are essentially the same as those coming from Mozilla, Opera, Microsoft and others in the next few months.

This isn't to say that I'm discounting a massive realignment of the browser space due to Google. I'd even speculate that there's about a 30% chance that this could end up being a tipping point phenomenon, one where Google could end up causing the collapse of Internet Explorer's market-share, simply because Google is effectively the first company to have provided a channel that may negate Microsoft's advantage in being able to bundle IE with Windows.

However, if the roll of the dice do not put them into that 30% chance, then I think other factors may very well keep their growth constrained after the first wave of downloads dies down.

Overall, I like Chrome, even though I've already found a few bugs (to be expected) - I'm actually responding to you via it - but I think the first 2-3% market presence is likely to be a given either way. If we're having this same conversation in a month, though, I'd be inclined to grant that Chrome could end up being a giant-killer. Watch how the developer community reacts, and watch the extensibility story.

One final point on that front - IF Google can create an insta-widget toolkit that will allow people to create extensions with comparatively little effort, then Chrome absolutely will give IE the coup de gras, and may even inflict some ancillary damage on Firefox. Firefox extension development, while simpler than the corresponding development for IE, is still too complex for all but specialists to engage in. If Google solves that particular conundrum, then expect their market penetration to shoot well above 40% in a few year's time.

As extensions are ultimately an architectural decision, I'd be inclined to suspect that if its not already baked into Chrome (and it may very well be, just not enabled yet) then it will be much harder for Chrome to retrofit a solution that doesn't eliminate the advantage of performance.

-- Kurt

News Topics

Recommended for You

Got a Question?