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.
Pick up any e-commerce web or mobile app today, and you’ll be holding a mashup of interconnected applications and services from a variety of different providers. For instance, when you connect to Amazon’s e-commerce app, cookies, tags and pixels that are monitored by solutions like Exact Target, BazaarVoice, Bing, Shopzilla, Liveramp and Google Tag Manager track every action you take. You’re presented with special offers and coupons based on your viewing and buying patterns. If you find something you want for your birthday, a third party manages your wish list, which you can share through multiple social- media outlets or email to a friend. When you select something to buy, you find yourself presented with similar items as kind suggestions. And when you finally check out, you’re offered the ability to pay with promo codes, gifts cards, PayPal or a variety of credit cards.Get the Guide
|Non-Linux FOSS: Screenshotting for Fun and Profit!||Oct 20, 2016|
|Nasdaq Selects Drupal 8||Oct 19, 2016|
|Canonical Ltd.'s Ubuntu Core||Oct 19, 2016|
|Build Your Own Raspberry Pi Camera||Oct 18, 2016|
|Netlist, Inc.'s HybriDIMM Storage Class Memory||Oct 17, 2016|
|Secure Desktops with Qubes: Compartmentalization||Oct 13, 2016|
- Non-Linux FOSS: Screenshotting for Fun and Profit!
- Build Your Own Raspberry Pi Camera
- Nasdaq Selects Drupal 8
- Canonical Ltd.'s Ubuntu Core
- Secure Desktops with Qubes: Compartmentalization
- Linux Journal October 2016
- Polishing the wegrep Wrapper Script
- Netlist, Inc.'s HybriDIMM Storage Class Memory
- A New Mental Model for Computers and Networks
- The Peculiar Case of Email in the Cloud