Google's Evan Martin and Mads Ager discuss the challenges behind making a browser work well on Linux, Mac OS and Windows.
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!
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.
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?
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?
JG: Can you tell us more about V8, its history, your rationale for developing it and who the key people were behind it?
JG: What innovations and new approaches does V8 bring to the browser?
JG: What language(s) is Chrome/V8 written in?
JG: What platforms does V8 support?
MA: V8 runs on Windows, Linux and Mac.
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”.
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!