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.
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.
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.
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.
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 Mozilla.com, 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.
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.