Google Chrome: the Making of a Cross-Platform Browser
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.
As we go to press, Google just announced its Chrome operating system. Chrome OS will be based mainly on Web applications and will add an interesting dimension to the “Google World”, as it will be possible to run a completely Google-based desktop environment. Although the Chrome OS will be a separate OS, it will run Linux under the hood. We're not surprised. Keep reading LJ both here and on-line for more information on the Chrome OS and what it means for Linux users.
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.
James Gray is Products Editor for Linux Journal.
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released