On September 1st, 2008, Google announced its new open source browser, Google Chrome. The introduction of a new web browser by Google, a major player in the web by anyone's standards, has predictably resulted in a flurry of attention, analysis and soothsaying.
The official announcement was preceded by a fair amount of buzz on the internet as the comic introduction that Google made to introduce Chrome made its first appearance before the announcement and before the release of the Windows beta of Chrome on September 2nd, 12pm PDT.
InfoQ has taken some time to compile some of the perspectives and analysis from the community, news media and blogosphere in order to assemble comprehensive coverage of the Google Chrome launch and its impact.
Introducing Chrome
Google introduced the browser through a comic designed for journalists and bloggers, drawn by Scott McCloud, the well-known author of Making Comics. The script was a collaboration between McCloud and the developers themselves, who McCloud interviewed and paraphrased. The comic introduces some of the areas where Google tried to differentiate Chrome from its competition: a focus on serving applications rather than content, a process-oriented approach to achieve a separation between isolated, sandboxed processes, a simplified tab-centric user interface, fast rendering and javascript engines and a built-in incognito browsing mode.
Chrome features a very simple user interface with tabs, an address/navigation bar and an optional toolbar. Although simplified interfaces are a common feature in modern web browsers, Google has taken this a step farther than most of its competitors. As Ars Technica puts it:
Google's approach with Chrome is different. Rather than removing features from existing web browsers, Google has taken its brightly colored forearm and swept the table absolutely clean. Forget about menu separators; why even have a bookmarks menu? Hell, why have a menu bar at all? Start with nothing. Assume nothing. Add features only as needed, and only in service of a well-defined design concept.
It's not that any particular feature of Chrome is so wonderful, or even that the sum of those features puts Safari back on its heels in the browser wars. It's the idea that someone other than Apple has taken such clear leadership in this area. Google Chrome makes Safari's user interface look conservative; it makes Apple look timid. And when it comes to innovation, overall daring counts for a lot more than individual successes or failures on the long-term graph.
This simplified interface is meant to distract less from the primary content: the web site or web application with which the user is interacting. For web applications in particular, Chrome can be stripped down even further with an interface that lacks even the navigation toolbar and dedicated links so that the resulting window looks that much more like an application instead of a web browser. Chrome also ships with Google Gears, whose primary purpose is to extend the capabilities of web applications and make them more like desktop applications, such as allowing them to function even when the user is disconnected from the internet.
Google has given the tabbed interface primary emphasis by placing the tabs at the top of the browser and allowing the tabs to be dragged not only within the frame but outside of it to create new windows or to move a tab from one window to another. These tabs are isolated from each other and sandboxed so that they are treated more like individual applications, where one misbehaving tab won't spoil the experience for the entire web browser. Although the comic introduction talks about process separation in some detail, the Chromium site goes into more detail of the four process models supported by Chromium and their strengths and weaknesses:
For its beta release, Chromium supports four different process models to allow experimentation and measurements, which will help us select a default model that best fits most users.
By default, Chromium uses a separate OS process for each instance of a web site the user visits. However, users can specify command-line switches when starting Chromium to select one of the other architectures: Chromium can instead use one process per web site, or it can isolate each group of connected tabs, or it can place everything in a single process. These models differ in whether they reflect the origin of the content, the browser's user interface, or both.
Topics of processes and threads draw regular controversy and this announcement is no exception.
Chrome also contains a private browsing mode called Incognito which allows the user to browse in a read-only session that doesn't save browser history and whose cookies are erased when the window is closed.
Technology and Internals
The Chrome browser is the result of the Chromium project, which connects the WebKit web browser engine with the new Google V8 JavaScript Engine, the Skia vector graphics engine, and Google Gears.
The WebKit browser engine began its life as a fork of the KDE project's KHTML and KJS engines by Apple, becoming the basis of the Safari browser. WebKit was later re-adopted by KDE. Google already employs WebKit within their Android mobile phone platform, and it became the obvious solution for them. As the comic introduction to Chrome states:
It uses memory efficiently, was easily adapted to embedded devices, and it was easy for new browser developers to learn to make the code base work. Browsers are complex. One of the things done well with WebKit is that it's kept SIMPLE.
The version of WebKit used in the initial Windows beta seems to be WebKit 525.13, which is not the most recent version, and has some security vulnerabilities (see Security below). Some users have also noticed rendering differences from Safari's WebKit rendering to Chrome's, including antialiasing and shadows. This may be the result of the Skia graphics engine used under the hood.
Talking about the integration with WebKit, the Chromium FAQ says:
The Chromium source code includes a copy of the WebKit source. We frequently snapshot against the WebKit tip of tree or specific branches according to our release needs.
Our goal is to reduce the size and complexity of the differences between the copy we maintain in order to work more effectively as a participant in the WebKit community and also to make periodic updates occur more smoothly.
The V8 JavaScript Engine is open-source and hosted on Google Code, but was written for Chrome, rather than adopting an existing JavaScript engine. V8 is written in ~100,000 lines of C++ and can be run standalone or embedded in C++ applications.
The foremost reason for V8's creation seems to be performance. The V8 Design Documentation states, "V8 is ... designed for fast execution of large JavaScript applications." The Chromium Blog on V8 is entitled "The Need for Speed" and states:
Google Chrome features a new JavaScript engine, V8, that has been designed for performance from the ground up. In particular, we wanted to remove some common bottlenecks that limit the amount and complexity of JavaScript code that can be used in Web applications.
V8 claims a number of performance improvements and innovations, from fast property access using hidden classes, dynamic machine code generation and efficient garbage collection (stop-the-world, generational, accurate, compacting), small object hreaders, multi-threaded from the ground up. The team that created V8 was headed by Lars Bak, who, as Avi Bryant says, was "the technical lead for both Strongtalk and the HotSpot Java VM, and a huge contributor to the original Self VM" and has a number of VM-related patents to his name.
V8 is not a virtual machine in the classic sense as Matthieu Riou points out: there's no intermediate representation or byte-code. As a result, you cannot write your own language that compiles to "V8 byte code", although you can cross-compile to JavaScript. Despite this, Dave Griswold believes that V8 could serve as the engine for other dynamic languages:
I think these properties will rapidly make V8 the dominant VM for dynamic languages. It ought to make a great platform for Smalltalk.
Google Gears has also moved into the Chromimum Project, as pointed out in the FAQ:
With Gears as a plug-in to Chromium we're carrying two copies of sqlite and two copies of V8. That's silly. We're integrating the code so Gears can run great in Chromium. We plan to continue to build Gears for other browsers out of the same code base.
Although Google Chrome supports plugins for content handling like Flash and PDF, it does not currently support browser extensions, although that is planned.
History
Niall Kennedy documented the history behind Google Chrome. He starts by describing Google's push for browser enhancements starting with its heavy use of Ajax and working with Ian Hickson on HTML5 and browser 'acid' compliance, through to browser extensions like Google Gears, Browser Sync and Safe Browsing. From there, he talks about Google's Android project with its WebKit browser acquired with Reqwireless, the Skia vector graphics library and the GreenBorder security sandbox. Finally, he describes the Chrome team headed by Ben Goodger and the V8 team headed by Lars Bak.
Wired's Steven Levy also covers some of the back-story behind the development of Chrome with his Inside Chrome: The Secret Project to Crush IE and Remake the Web, tracing its genesis back to 2001:
"The browser matters," CEO Eric Schmidt says. He should know, because he was CTO of Sun Microsystems during the great browser wars of the 1990s. Google cofounders Larry Page and Sergey Brin know it, too. "When I joined Google in 2001, Larry and Sergey immediately said, 'We should build our own browser,'" Schmidt says. "And I said no."
Levy covers the initial prototype, the V8 team, and despite some early leaks, the surprise launch:
It's incredible that something as potentially game-changing as a Google browser has stayed under wraps for two years. It wasn't until mid-2007, about a year into the project, that the team let employees outside the group even see what they were doing. At the first of a series of Tech Talks featuring the current prototype (events designed, in part, as a way of recruiting internally for the ever-growing team) the reaction was volcanic. Googlers broke into spontaneous applause when various features, like dragging a tab into a new window, were demo'd. As the number of people who knew about Chrome increased, the inevitable occurred — word did leak out to a blog or two, yet nothing came of those stray items. No reporter put it all together. "I think it was because rumors about Google browsers have been around so long — it's like sightings of Bigfoot or the Loch Ness Monster," Upson says
The Launch: Windows-Only, Carpet-bombing, Privacy, EULA
Google's launch truly began when the comic surfaced, after which there was a blog post and a day's delay before the software beta became available. In the meantime, the comic itself gathered a lot of attention. Josh Evnin applauded the use of "actual Googlers" named in the comic and the way technical topics were both present and well-explained:
And another thing Google did well here was in not trying to over-engineer their explanations of highly technical processes. They simplified their message down to bare essentials, and I felt enlightened after reading this document. Most technical documentation talks down to people, assuming that all the basics are already understood. Google removed some barriers to entry by explaining their new technologies in a way that almost anyone with a little technical know-how can understand. This is something almost every other open source project out there fails at. Technical documentation is far more than simply documentation…it’s an implicit invitation to take part in the experience.
At the end of the day, I’m really impressed at the quality of this documentation. I actually read the entire thing, which is much more than I can say about the technical documentation for any other software I use. Who knew that I could find the difference between multiple threads and multiple processes interesting?
Google Chrome is currenly only available in Beta form on Windows, although other platforms are due soon. Both Mac and Linux versions have been referenced, but there are no explicit dates for their launch. The Mac version of Chromium is eagerly anticipated, and made an appearance in the press when Sergey Brin said the lack of a Mac version was "embarassing". The Mac version of Chrome has been benefiting from the efforts of Mike Pinkerton, the Project Lead and Lead Developer of Camino as well as a Google employee working on Google Desktop for Mac.
Amanda Walker notes on the Google Mac that although the Chrome team includes people with a lot of expertise in particular operating systems, they're still one team, and each member of the team contributes on all platforms. On the current state and progress, Walker wrote:
Right now, both are in the "pieces build and pass tests, but there's no Chromium application yet." While we're working hard and fast on catching up to the Windows version, we're not setting an artificial date for when they'll be ready--we simply can't predict enough to make a solid estimate, and we expect to learn a lot from the Windows public beta as well. On the plus side, since the project is now public, you'll be able to watch (and maybe even contribute to) the progress from week to week. As these versions stabilize, we will create official betas, much as we are now for the Windows version. While we can't give any dates yet, we'll keep everyone informed as we get closer.
If you're interested in following the development of Chromium for Linux and Mac OS X, the Chromium development site is probably the resource to watch.
The launch of Chrome has not gone without its share of missteps. Chrome is apparently vulnerable to a carpet-bombing flaw that has been publicized and fixed in later versions of WebKit than Google has integrated. Although Chrome is a beta product, the comic introduction touts the security inherent in its design.
Similarly, some people feel that Chrome oversteps its bounds in terms of privacy. The omnibox (location bar, to those of you not yet speaking Chrome's lingo) offers suggestions as you type, and in order to do so, regularly sends data to the selected search engine, which defaults to Google. This leads some to argue that Chrome and privacy is a situation already worse than you think, although Google has already responded to concerns about the amount of this data that is retained.
Matt Cutts has spoken with the Google Chrome team to learn when Chrome "phones home", and summarized:
I knew that as soon as Google Chrome launched, some readers would ask tough questions about privacy and how/when Google Chrome communicates with google.com. So I decided to tackle this issue head-on. I talked to the Chrome team to find out if there’s anything to worry about. The short answer is no.
Despite these assurances, Germany's federal office of information security is reported to have warned users to avoid Chrome.
The Terms of Service have also come under fire for implying that Google retains a license to all content viewed in Chrome. Matt Cutts and Rebecca Ward, senior product counsel for Google Chrome agreed the terms were a mistake; the terms were revised on Wednesday, September 3rd, and the controversy has largely quietened.
Browser Wars and Other Motives
Many people have heralded the launch as the renewal of the browser wars once fought between Microsoft and Netscape / Mozilla (those were the primary contenders, although every browser has its contigent willing to trumpet its strengths). Some are willing to count Chrome out already, while others are adopting a wait and see stance.
Many argue that Google doesn't wish to compete with other browsers, simply to advance the state of network-delivered applications to where they are indistinguishable from desktop applications and in so doing, push the operating system into the background.
In particular, people telling this story love to cast Microsoft in the opposing role, so that one can imagine the two titans clashing.
Other Browsers: Comparisons and Impact
Some believe that Chrome is merely re-iterating what other browsers have already done. Georgios Kasselakis argued on OSNews that Chrome's process models aren't that different from IE8 and its tabs are pretty similar to those offered by Opera, a sentiment echoed by an Opera user.
Although V8 claims high speed backed by benchmarks, other browser manufacturers have been making similar claims to improved speed on their development lines.
Mozilla's Firefox 3.1 has TraceMonkey, which offers speed improvements, and Brendan Eich has done some testing of his own.
He believes TraceMonkey is already faster than V8 in some categories, and "in the game" in other categories, although he notes:
V8 is great work, very well-engineered, with room to speed up too. (And Chrome looks good to great -- the multi-process architecture is righteous, but you expected no less praise from an old Unix hacker like me.)
What spectators have to realize is that this contest is not a playoff where each contending VM is eliminated at any given hype-event point. We believe that Franz&Gal-style tracing has more "headroom" than less aggressively speculative approaches, due to its ability to specialize code, making variables constant and eliminating dead code and conditions at runtime, based on the latent types inherent in almost all JavaScript programs. If we are right, we'll find out over the next weeks and months, and so will you all.
The WebKit team has already been working on a new JavaScript interpreter, dubbed Squirrelfish, as previously described on InfoQ. John Resig has a detailed performance analysis in which SquirrelFish seems to come out on top, at least in places.
What everyone agrees on is that a focus on JavaScript performance is a good thing for the end users, who'll end up with much faster JavaScript engines no matter who's building them.
Many wonder what the introduction of another web browser will do to the existing web browsers on the market. Some feel that Microsoft is already losing ground as Internet Explorer continues to lose market share. Others fear that Firefox is more likely to suffer as Internet Explorer and Safari come preinstalled on Windows and Mac OS X, and many users simply use these without making an explicit choice, while Firefox and Chrome will fight for the same, smaller segment of the market that makes an explicit choice to download a browser. Early stats seem to support this. Google counters by arguing that the increased attention will remind people that they have a choice in terms of what browser they use, perhaps a choice they will exercise. Even Marc Andressen seems to feel that Chrome will bring a rising tide of competition to lift all ships.
Additional Analysis
Although this addresses the most common perspectives and analyses on Google Chrome, there are any number of smaller conversations going on about Chrome and its impact:
- Carsten Knobloch has already released a portable version of Google Chrome, although non-German-speaking readers may want to read an english summary.
- Some KDE developers feel as if their contributions to the origin of WebKit go uncredited too often.
- The Chrome Help group operated by Google already contains more than 1500 feature requests and suggestions (e.g. FTP support, themes, launching chrome in icognito mode, etc.)
- A number of people seem to feel that Chrome is the next step in Google's drive to cloud computing Information Week does a good job of assembling the zeigeist here.
- Jesper notes in his first impressions that the WebKit inspector seems very out of place in Chrome.
- Yakov Fain notes that Google Chrome requires Java 6 U 10, which he believes will please JavaFX developers, who are already riding the Chrome hype with a JavaFX/Chrome demo.
- New chrome users may be interested to get some tips, such as the special about pages.
- Google's Android may pick up parts of the Chrome stack, although details remain sketchy.
- Toolkit fans may want to know how Google will be doing cross-platform development:
We're too early in the port to have incorporated a toolkit. Most of the custom drawing goes through a library called Skia, which is comparable to Cairo in that it draws lines and rectangles but not buttons and checkboxes.
Many people have strong opinions about the toolkit, and part of the reason it's so divisive is because both libraries are quite capable of meeting Chromium's needs. In fact, because most of Chromium is just custom rendering for showing a web page -- for example, even the popup of an HTML select control is custom-drawn by WebKit -- we anticipate the only real places the toolkit will be visible are in the way some form controls look and in various dialogs like the preferences and "save as" dialogs.
With all of that said, the plan is to use GTK. It's not due to any dislike of Qt, but just because there's more experience on the team with GTK and it matches the existing Firefox dependency on Linux. Please keep calm. :)
Resources
Due to the sheer volume of links, analysis and perspectives contained above, I'll highlight the most common resources for Google Chrome one last time for those interested in learning more and staying in touch with Google Chrome: