You heard it here last. As always.
As all of you undoubtedly know by now, Google yesterday took the wraps off an open source project called Chrome, which is its Internet Explorer analogue. While the release of a browser is not ordinarily accorded as much fanfare – as many have wryly noted – several aspects of this launch make it worth commenting on, in my view. The fact that a firm like Google felt compelled to build it, not least of them.
As a result, I thought it worth indulging in a Q&A to explore some of the questions that I and others who’ve written in have about Chrome, its future and its potential for impact.
Q: Before we begin, do you have anything to disclose?
A: Microsoft, the author of a browser competitive to Chrome in IE, is a RedMonk client. Besides that, I’m unaware of any potential conflicts, as neither Apple (Safari) nor Mozilla (Firefox) are RedMonk clients, nor is Google itself.
Q: Can you summarize the details of the product announcement for us?
A: Google, as indicated by the premature release of Chrome documentation, launched on Tuesday an open source browser called Chrome. It is built from code taken from the open source project labelled Chromium, which in turn draws from Firefox and Webkit, the project upon which Apple’s Safari browser is built. The source code can be found here.
Q: Has anyone looked at the code yet? What have the reactions been?
A: Mostly positive. Miguel, for one, was impressed. Oddly, however, the source tree, as an individual noted on #redmonk yesterday, appears to include Cygwin.
Q: What differentiates the browser from Firefox, IE, or Safari?
A: Several things. It’s very lightweight on the traditional features – bookmarks, for example, are not enabled by default – but does some interesting things with tabs and such.
The more important differences, however, are fundamental. Architecturally, it’s distinguished by its counterparts (with the exception of IE8, reportedly) in its process-per-tab approach. Rather than spawn a single process per browser instance, as does Firefox, Chrome generates a process per tab – and plugin, if I understand correctly. This is unusual. As John Resig describes it:
If this is true and there’s a process manager which allows you to see how many resources are being consumed by a particular browser tab (including plugins!) this will be a 100% killer browser feature.
It simply isn’t possible to implement with current browser architectures which brings up two points: 1) Browsers haven’t tackled it due to the extreme amount of code rewrite that it would cause and 2) that there’s a general consensus that this architecture will actually consume more resources than the current architectures.
This is important. Since there’s no sharing going on between the tabs of the browser it’s not possible to easily reduce the amount of duplicate resources. For example, within the Mozilla Gecko engine there’s a lot of code reuse occurring, which allows for significantly reduced memory consumption (and optimized memory collection and defragmentation).
In theory, the advantages of this approach should be multiple. One rogue tab or plugin will not jeopardize the browser, as they often do today with Firefox. Also, Chrome should be able to better leverage the multi-core chips that are fast becoming the standard. Most compelling to some is the assertion that Resig makes: “The blame of bad performance or memory consumption no longer lies with the browser but with the site.”
In practice, however, the performance may not be as universally improved as we suspect. Talking to Mozilla’s Christopher Blizzard, Ars Technica’s Ryan Paul said “you were right about the memory implications of process-per-tab. Chrome is really a hog.”
Because Chrome is Windows only at the moment, I have done only cursory testing in a VMWare instance and thus cannot comment one way or another, but it will be interesting to see how the different architectural approach taken in Chrome proves itself over time.
To some extent, this is just cyclical history applied to software.
Q: What does that mean?
A: Well, in some sense Firefox is a victim of its own success. The plugins make Firefox successful, but they also introduce potential instability for users and they can hinder development (the transition to 3.0, for example, negatively impacted most of the plugins I use regularly). The platform ecosystem, as is nearly always the case, is both its biggest strength and its biggest weakness. This is not unique to Firefox, of course: every platform of a certain size and critical mass faces this. For example, there’s Windows and its struggles with legacy application support.
Q: Speaking of the Windows only decision, why would Google choose that approach for the launch? Tim Bray and many others had little affection for the single platform release strategy.
A: Not having seen an explanation forthcoming from Google, I can only speculate that they’d reached a stage of development where the Windows version was ready for release, while the Linux and Mac versions (that are planned) were further off. That, or they were compelled to launch before they were ready by leaks or something similar.
Either way, Windows will give them more than sufficient volume to assess both the appetite for and the performance of the project, even if their decision not to simultaneously ship versions for competing platforms raises the ire of the very audiences that would be the most welcoming to new browser technologies.
Q: What’s Chrome been like in your usage, limited though it may have been?
A: Exceedingly quick, as Michael Dolan and many others have noted, and Stephen Shankland’s initial benchmarking indicates. Apart from that, there have been some thoughtful tweaks of the browser UI – the Awesomebar-like type completion, for example – but nothing I would call revolutionary or killer. That said, Google has long recognized that speed is a feature, and Chrome is a chip off the old block in that sense.
While Chrome trounces the available browsers in the current speed tests, thanks in part to its C++ built V8 Javascript engine, I am interested to see how it compares to a Tracemonkey equipped version of Firefox. Tracemonkey, if you’re unfamiliar with it, is a much improved Javascript runtime that promises significant improvements for the forthcoming Firefox 3.1. Blizzard, in particular, disputes some of the claims that V8 is “many times faster,” and has run some numbers to back it up.
One minor personal nit with Chrome: some of the keyboard shortcuts from Firefox are functional in Chrome – CTL-ENTER to add a www and a .com to something typed into the location bar, as an example – but many are not. SHIFT-ENTER for .net, CTL-SHIFT-ENTER for .org and others have not been preserved, affecting its usability for me.
Q: How about the rendering?
A: In the 20 or 30 sites I visited, I had few issues. RedMonk’s homepage and blogs rendered appropriately, as did the bulk of other properties I visited. Google asserts that it should be as compatible as Safari, so that sites designed for Apple’s browser should render appropriately in Chrome, thanks to their shared Webkit foundation. Still, sites are breaking Chrome already.
Q: Does Chrome allow for the same plugin architecture that Firefox has leveraged with great success?
A: My understanding is that it does not, but that a plugin API is planned for future releases.
Q: You mentioned that Chrome is an open source project: what can you tell us about the licensing, governance and so on?
A: The source is entirely available at present under the permissive style licenses that Google (and many other commercial entities) favors. As for the governance, I’m unaware of any active external contributors at this time, although they will be accepting patches and I’m told code is already coming back. My assumption is that this will require the acceptance of a joint copyright agreement, but Google should feel free to correct me on that subject (I’m on a plane and can’t check).
Q: What about the rumors that Chrome is phoning home to Google? Are there legitimate privacy concerns?
A: According to Matt Cutts, the information being transmitted back to Google is fairly innocuous and this is done under logical circumstances. Still, many are asking legitimate questions about the “unique application numbers” mentioned in the Google Chrome privacy notice, and separate questions about the Terms of Service.
Q: What about concerns like David Berlind‘s that Chrome continues a trend whose result will be multiple, siloed internets rather than seamlessly available content?
A: Most web developers, even prior to the launch of Chrome, would tell you that developing web applications is anything but write-once, run-anywhere. Lack of standards consistency, differing developmental priorities and more have made web development a veritable quagmire when it comes to testing and deployment.
But while Chrome is another platform that will undoubtedly have to be tested, its Webkit roots ensure that it shouldn’t be that different from one of the existing platforms in Safari. And the open source nature of the entire platform does mitigate against the type of proprietary control users of IE and Safari are subject to.
Q: Now to the $64,000 question: what does Chrome mean for the existing browsers?
A: That is indeed the question. Interestingly, many are arguing that Chrome is aimed at IE, when I expect it to have little impact on that market. The bulk of IE’s still majority share of the browser market, in my view, are users that have not historically and are unlikely to – in future – choose their browser. These are path-of-least-resistance users, and they are by all available measures, the majority of the market. The availability of Chrome, in my view, is unlikely to change the dynamic of the casual browser, save the future availability of some currently unknown killer feature.
Likewise with Safari, the default browser choice for many if not most casual Mac users. If anything, Safari is poised to benefit, because by tieing its compatibility story to Apple’s browser, Chrome is likely to introduce new users to the Webkit ecosystem, making the platform that much more compelling as a development target.
It is rather browsers that depend on choice such as Firefox and Opera that, to me, are most vulnerable to the introduction of Chrome. Firefox is likely to be more resilient, both because many of the casual users that were originally persuaded to switch to it are unlikely switch again, and so soon, but also because of the strength of its application-like plugin ecosystem.
Q: What does this do, then, to the relationship that Google has long enjoyed with Mozilla?
A: The kind words from both sides following aside, I cannot see but how the introduction by Google of an offering directly competitive with Mozilla’s flagship project will do anything but strain the ties. It will not sever them, particularly with the financial relationship between the two recently renewed through 2011. But it can, it is, making the relationships more interesting on both sides.
Q: What does this mean, then, for the two market leading browsers in Firefox and IE, in terms of product plans?
A: Probably very little, tactically. IE development will proceed apace, as usual, and while Firefox may see the introduction of Tracemonkey sped up, I doubt you will see a dramatic re-architecture of the browser along the lines of Chrome.
Until, of course, that product wins significant share at the expense of one or the other. If the recent history of browser development (see IE’s stagnation and revival post-Firefox) is any guide, a competitor’s success is the surest path to radical change.
Q: What’s in this for Google?
A: Well, as a few people have commented, the flip answer is that more people using the internet more frequently is more better for Google, if you’ll pardon the phrasing. But the question, I think, is better phrased as “why would Google build another browser?”
My guess is that the answer to that comes in two parts: first, the impending threats posed by RIA environments, and second the ability of the existing browsers to respond to the RIA threat.
Google, you’ll recall, is built principally on the sale of advertisements. They have other revenue streams, yes, and I’m counted among those that believe the value of the data they’ve aggregated is both immense and underappreciated, but they’re day to day financial performance is predicated on the ability to effectively monetize browsing traffic through ad sales.
They can do this, and do it with remarkable efficiency, via most traditional browsers; AdBlock or similarly equipped browsers excepted. They are significantly less effective, however, at monetizing traffic deriving from RIA platforms such as AIR or Silverlight. It’s not that they can’t technically can’t monetize ad track on those platforms; they can and do. It’s rather that it’s less intuitive, less native than monetizing the browser. RIAs, after all, have the ability to transform the browsing experience into something more application-like. And how many ads do you have running today in your rich clients?
An RIA dominated internet, then, could well prove to be anoxic to Google, depriving them of the oxygen of ad sales. Browsers, therefore, are important to Google. Which should be obvious, given this launch. Hence their longstanding commitments technically to IE, Firefox and so on, and their less longstanding but no less important financial arrangement with the Mozilla corporation.
With the advent of the Olympics, however, the once far off threat of RIAs in general and Silverlight in particular became clearer. From the Wired account, the work that resulted in Chrome began at least two years ago, but I’m sure that the widespread distribution of the Silverlight player was yet another shot across Google’s bow, demonstrating once more that the need for Chrome was growing more acute.
Q: What need? Isn’t Firefox, at least, doing a good job of competing in the browser market?
A: Indeed it is. Firefox is continuing to show strong, sustained progress in its marketshare, and as I’ve been humorously reminded, its reach into aggressively non-technical userbases is impressive indeed. But with the introduction of Chrome, it seems self-evident to me that Google is attempting to solve a different problem than Mozilla.
Q: How so?
A: Consider the relative targets. Mozilla’s big competition, still, is IE. Credible efforts like Xulrunner and Prism aside – and I use it every day – the rich client story from Mozilla is still fundamentally immature. Not so, clearly, its browser story.
Google, on the other hand, is not only intent on sustaining its browser based ad revenues, it harbors ambitions of expanding the browser into application territories. Gmail, Google Apps, and so on are all alternatives to rich client based applications.
But two can play at that game, and it strikes me that Chrome indicates that Google is worried far less about the browser market, and far more about protecting that market. In a way, in fact, Chrome could counterintuitively be seen as an attempt to shield Firefox, rather than attack it.
Q: How so?
A: Well, what’s one of the principal advantages of rich client applications, in your experience, relative to the browser based competition? Speed, probably. “Rich clients are faster,” says the conventional wisdom. And for once, the conventional wisdom is right.
Not always, and not enough, in many cases – certainly not in mine – but enough that a rich client that was better integrated into the web could be a significant threat to the browsing experience that has come to characterize most internet usage while making Google a mint.
Firefox is fast relative to its browser competition, of course, but is it fast relative to a rich client? That’s debatable. Chrome, on the other hand, while far less ambitious in scope, should be reasonably competitive on that front. It also will include, natively, features to make it competitively in other areas. Think Gears: despite the availability of that piece of technology, and other Firefox efforts, Mozilla’s browser is still fairly stupid when offline (as I’m reminded as I write these words on a plane en route to San Francisco).
Q: How does that “shield” Firefox, then?
A: Remember that Chrome is open source, and permissively licensed. Consider Sergey Brin’s own words, “I hope big chunks of Chrome can make it into the next generation of Firefox.” My guess – and that’s all it is – is that Chrome is what Google believes Firefox should shoot for, performance-wise, to be competitive in a market that could soon be less browser vs browser, but browser vs rich client. If Firefox chooses to take the code and move Firefox to where Google thinks it should go, great. If not, they’ve hedged themselves against the continued incursion of rich clients.
Q: What do you predict, then, for Chrome as far as aspects of it being incorporated into other browsers?
A: It’s too early to say; I’ll wait and see what the various browser developers have to say on the subject. And remember that that doesn’t just include Firefox or other open source browsers: as a permissively licensed asset, bits and pieces of Chrome could well end up back in IE.
Q: What does this mean for Android?
A: Judging by the tiny size and the effort involved, it’s undoubtedly a platform as suited for the handset as the desktop. How, precisely, it will be implemented on top of Dalvik, the JVM reimplementation, I’m not sure.
Q: Will you, personally, use Chrome?
A: Not until they have a working Linux version, no. And even then, I’m somewhat wedded to a few key Firefox plugins. Will I install it and keep an eye on its progress, however? That I will. As soon as it’s available on Linux.
