This article on the development of the Google Chrome cross-platform browser started off like any other interview. I interacted with Google by e-mail and phone and started pulling together the responses to my questions. It turned out that the “official” responses were much shorter than I was used to. “Why are these guys so shy?”, I thought. In interviews, I typically have to whittle down my respondents' answers because they love telling their story—in glorious detail!

The Google Chrome Development Team (Photo Credit: Jeromy Henry)

So, I went back to Google to see what was up. “Free your developers to speak!”, I exclaimed. “We want to know the gritty insiders' take on Google Chrome development!” My contact there told me that interviews are challenging because a direct quote is like going “on record” and needs to be vetted by several layers of management (and maybe attorneys?). And, when you're the big fish in the pond, you have to be careful what you say. I am not used to such caution, and I certainly don't like it, but I indeed understand it.

After this and subsequent discussions, I realized we had a pretty complete picture of what Google Chrome is all about. The only hitch is that one part of the material came from direct interviews and another part came from more informal discussions and e-mail messages. Thus, we agreed that while I could talk freely about Google Chrome, only authorized material could be quoted. What follows, then, is a summary of my discussions with Google, followed by an interview with Google Chrome developers Evan Martin and Mads Ager. Martin is a Senior Google Software Engineer and Linux enthusiast working on all platforms of Google Chrome. Before working on Chrome, Martin worked on Google's search-result ranking. Mads Ager is Tech Lead for the V8 JavaScript engine project and and its integration in the Google Chrome browser; he is based in the Aarhus, Denmark, office.

In some of my earliest conversations with Google, we talked about the company's motivations for building Chrome. After developing a range of rich and complex Web apps, the company saw that it was time to build a browser from scratch that could better handle “today's Web”. From the beginning, they focused on a browser that innovated in four key areas, namely speed, simplicity, security and stability. Early on, the Google Chrome team realized that the linchpin for innovating in these key aspects, as well as to handling the new Web apps, would be a much more efficient handling of JavaScript. Thus, the V8 JavaScript engine, explained further below, was conceived and became central to the Google Chrome Project.

Google hopes that innovations like V8 will change the feel of the desktop, making the Web apps we're using more and more feel like native ones. Besides the internal code needed to achieve efficient JavaScript processing, Google Chrome hopes to maximize this native feel by keeping the UI minimal, including an "app mode" that lets one create a desktop icon that links to a URL with merely a tiny UI around the edges.

From a development standpoint, Google noted the difficulty in making this user experience acceptable on platforms with very different capabilities and conventions. Rather than just doing a brute-force port, the Google Chrome team has focused on often taking a step back from the code and looking at the larger picture of what a certain part of the code accomplishes for the user and then translated that into more abstract benefits for the respective Linux, Mac OS or Windows user. On some platforms, native capability exists in whole or in part for core functionality, such as sandboxed processes, but not on others. This fact has required a wide range of refactoring or writing new code depending on existing functionality found on the respective platform.

One example of making Google Chrome good on the Mac platform is what the company did with WebKit. The team first had to come to terms with what it meant to use WebKit for Chrome and determine what it could provide. Interestingly, Google says that in the examples of Chrome or Safari, only about half the code is WebKit. In addition, WebKit was never really designed to be run in a separate process from the rest of the browser UI. In order to accomplish this, Google had to write much of its own drawing and event handling “plumbing” rather than simply dropping a WebView into a window in Interface Builder. However, the developers have been able to draw on much of the work that was done for the Windows version to solve this problem.

Of course, Google Chrome's entire development process is much more efficient and potent given its open-source nature. More important than trying to “win the browser war” in the traditional sense—that is, get people to use Google Chrome as their primary browser—the company feels its open-source efforts with Chrome already have stimulated and seeded a great deal of innovation and made other browsers better than they would have been in Google Chrome's absence. In fact, Google takes at least some credit for speed improvements and security enhancements that have taken place in other browsers during the past year, which is advantageous for everyone.

Given that Google Chrome is open source, we were curious to know how involved outside developers have been to its development. Although my contacts were unable to give me specific numbers, I was told that outside participation is very high, especially in terms of bug reports from users of the early developer builds of the browser. Google also works very closely with the WebKit team, so changes made by WebKit developers at Apple or others in the WebKit community are integrated into Google Chrome as well.

And now, on to the interview with Evan Martin and Mads Ager.

JG: In a nutshell, what inspired Google to create Chrome and how did it come about?

EM: We built Google Chrome because we believed we could add real value for users and help drive innovation on the Web. Google Chrome is built for speed, has a very simple interface and uses innovative technology to ensure it is always secure and stable, providing a great experience for users as they browse the Web. But what's more, by making Google Chrome open source and developing a powerful new JavaScript engine, V8, we believe we can help spur innovation in the industry and provide developers with the platform with which to build the next generation of Web applications. This is good for users, and good for Google, as we benefit directly when the Web gets better.

LJ: What is the Google Chromium Project?

EM: After we wrote the code for Google Chrome, we open sourced it under the name Chromium. Much like Firefox is a trademark of Mozilla, Google Chrome is a trademark of Google; the name Chromium is not, so distributions are free to use it to refer to the same project. We hope that developers and browser vendors take a look at the Chromium source code and that it will be useful for new projects built by the Open Source community in the future.

JG: This being our cross-platform development issue, we're curious to explore the challenges and innovations in that area. What have been the major issues in making Chrome great on all of its platforms?

EM: Much of the challenges we've encountered on Linux stem from how heterogeneous the user base is—which, surely, is also the strength of Linux. This ranges from how to port simple UI decisions (Chrome's shade of blue was chosen to look good next to the blue seen on every Windows computer), to getting boring technical details (a binary built on Ubuntu won't work on a Fedora machine), to real problems that will require engineering work to solve.

One good example of the latter is adapting our sandboxing model for Linux. Getting a process sandboxed in a way that's useful to us is challenging on Windows, with the relevant source code consisting of more than 100 files, but it needed to be implemented only once to work everywhere. On Linux, there are a variety of easier-to-use but different sandboxing systems available, and different Linux distributions ship with different (or no) sandboxing APIs. Here's an article about a kernel patch we've proposed for discussion toward that end: lwn.net/Articles/332974.

JG: What innovations does Chrome bring to browsing?

EM: We did a lot of interesting things in building Google Chrome. First, it's simple and easy to use—we've designed Google Chrome to be as unobtrusive as possible, taking up the minimum amount of space on your screen, and allowing you to search and browse all from the address bar. Its multiprocessed architecture also ensures Google Chrome is fast and stable. Additionally, we designed Google Chrome for speed from the beginning, including building a new JavaScript engine called V8 from scratch to handle rich, complex Web applications.

JG: Can you tell us more about V8, its history, your rationale for developing it and who the key people were behind it?

MA: The V8 Project started in late 2006. At that time, existing JavaScript engines did not perform very well. The goal of the V8 Project was to push the performance of JavaScript engines by building a new JavaScript engine on which large object-oriented programs run fast. The V8 Project was pioneered by the dynamic duo of serial virtual machine builders Lars Bak and Kasper Lund in a farmhouse outside Aarhus, Denmark.

JG: What innovations and new approaches does V8 bring to the browser?

MA: V8 uses the concept of hidden classes and hidden class transitions combined with native code generation and a technique called inline caching to make property accesses and function calls fast. V8 uses precise generational garbage collection to make the engine scale to large object-oriented programs that use a lot of objects. In addition, V8 contains a JavaScript regular expression engine that was developed from scratch, is automata-based and generates native code for regular expressions.

JG: What language(s) is Chrome/V8 written in?

MA: V8 is mostly written in C++, but some of the basic JavaScript libraries are implemented in JavaScript itself.

JG: What platforms does V8 support?

MA: V8 runs on Windows, Linux and Mac.

JG: What CPU architectures does it support for native code compilation of JavaScript?

MA: V8 supports IA32 and ARM.

JG: Are there plans to extend it to other CPU architectures?

MA: We are working on a 64-bit version.

JG: Is the code generation better on some architectures than others?

MA: There are different trade-offs for the different architectures, and we try to make the code generators as good as we can for the different architectures. The code generator for IA32 does register allocation and does more inlining than the code generator on ARM. In general, the IA32 code generator has been tuned more than the ARM one.

JG: Did you name it after the internal combustion engine or the vegetable drink?

MA: The internal combustion engine. It was developed in the context of Google Chrome, and we thought that there should be a powerful V8 engine under the “chrome”.

JG: Why did Google choose to develop a new JavaScript engine and use WebKit rather than use code from Mozilla?

EM: We have always been and remain great supporters of Firefox—Mozilla helped lead the way in much of the innovation we've seen in the browser space during the last couple years, with features like tabs, search boxes in the browser chrome and extensions. They've also proved that you can build a mass-market software product using open-source technology and collaborative development in the open. However, we initially thought of our work in this space as an experiment and didn't want to impose our ideas on anyone else. Rather, we thought about developing a new JavaScript engine and open-sourcing it so that other browser developers could benefit.

We think that numerous open-source projects are good for the entire space because they allow developers to make advances and share them quickly. We continue to have a great relationship with Mozilla, and many of our engineers actively work on features in Firefox through Mozilla's public participation process.

JG: What can you tell us about the status, road map and challenges regarding the Linux version? We're salivating here.

EM: The Developer version is available for a few Linux distributions already. Although this is an early release and not ready for your average user, we hope you get an idea of what Google Chrome for Linux will be like and keep following our development in the open as we make progress on a beta and stable version.

JG: How many developers in how many locations are dedicated to Chrome development, and how many solely to the Linux version?

EM: Although we don't go into details about the number of Google employees on any particular product, we have a core team of engineers who are working hard to get the Linux build of Google Chrome up and running. As a team, to prevent fragmentation, we try to have all developers work on all platforms—I refactor code on Windows to make it work on Linux, and if someone on the Mac team breaks the Linux build, it's his or her responsibility to fix it. Pieces like the networking stack can be worked on from any platform, so developers can just pick their preference.

At one point, I counted Google developers contributing from more than a dozen different locations (some work from their homes); we have even more once you count the contributions we receive from other developers. One of my favorite experiences of this project has been filing a bug one evening, then waking up the next day to see a patch to fix it from someone in Europe.

We've also received many patches from outside of Google, and have even promoted some of our best contributors to committers themselves.

JG: Was there a specific Google application that prompted Google to decide it needed a bigger/faster browser?

EM: I think of Google Chrome as being less about making Google applications faster and more about making the Web as a whole faster.

JG: What toolkits are used to build Chrome? And, are there any interesting issues regarding tools worth mentioning?

EM: Google Chrome on Linux relies on a ton of free software—about:credits lists more than 15 subprojects we include source from—as well as standard system libraries like FreeType, NSS (the Mozilla SSL/TLS implementation) and GTK+. There has been a lot of discussion on-line over toolkit choice; it was surprisingly uncontroversial within the team to choose the one that Firefox and Flash depend on and that we had more experience with. I think other options would have been just as good, and I would, in particular, love to see someone knowledgeable about Qt contribute patches.

Regarding tools, I'd like to especially call out gold, the fast linker that is little known but has been a lifesaver for us.

JG: How has the development of Google Chrome for Linux been going? Can you share some ups and downs you've experienced so far?

EM: I run only Linux at home. For me personally, the biggest up was after working on Windows for so long, to be able to install and use it finally myself.

JG: Is there a tentative date for when a beta release will be ready for Linux?

EM: Not yet, but we're working hard on it. You can track our progress on Linux development by running the in-progress version available at dev.chromium.org/getting-involved/dev-channel or via the mailing lists and source found on the Chromium developer site at chromium.org.

JG: Will the Linux and Mac OS versions one day catch up with and enjoy equal functionality with the Windows release?

EM: Yes, it is one of our highest priorities right now.

JG: Thanks to you both for your fascinating insights on Google Chrome!