Browser engine forking isn't the end of the world
If you’re a fan of Web standards and compatibility, two announcements from last week probably have you clutching your cascading style sheets in terror. First, Firefox maker Mozilla struck a partnership with Samsung in which the handset manufacturer pledged to help bring an experimental Web browser engine called Servo to phones with ARM processors running the Android operating system. (ARM chips power most Android phones—and most mobile devices.) Then Google’s browser team said it would be “forking”—creating a new branch of code—from the WebKit engine that Apple helped bring into being and develop for its Safari browser.
This sparked a torrent of tizzies among Web developers and users with long memories. Surely, Twitter tweeters and Web commenters wailed, having different versions of the engines that browsers rely on to transform the HTML code in pages into graphical layouts in browsers means the return of incompatibility! Google (or Samsung or Mozilla) will use its deviance from WebKit to create new properties and options that will either break the display of standards-compliant existing sites or add new options that only users of browsers powered by the new engines can take advantage of! Or both!
Fear not, world. It won’t play out that way. In fact, structurally, it can’t. Nobody has enough control over desktop or mobile browsers—not even Apple with iOS—to win a new battle of the broken browsers. Still, for people who remember the way things were back to 2006 and earlier, last week’s browser machinations may have triggered some not-so-pleasant flashbacks. Let me talk them (and you) down from the ledge.
Engine of creation
A browser’s engine is the unseen motive force that, when you visit a webpage, requests the page’s HTML file and all the images and media associated with it, and turns them into something you can interact with graphically. What we think of as a browser comprises the front-end user interface that we poke at and view, and the hidden engine that handles parsing, scripting, formatting, networking, plug-in architecture, and display. (Like any other software, the browser leans on the operating system to hand off tasks such as drawing fonts and processing mouse clicks.)
In the dark days of the Web, between about 1999 and 2006, Microsoft held a dominant share (around 90 percent) of the market; but its Internet Explorer 5 browser was full of fail, and version 6 didn’t improve matters once it arrived in 2001. In that era, to make Web styles (CSS or Cascading Style Sheets) work correctly in layouts with any degree of object placement, you had to break CSS. You had to write a combination of good code (that did what you wanted) and bad code (that smart browsers would ignore but IE 5 and IE 6 would pay attention to). Each version had different broken parts, too.
In 2003, Apple released Safari, built on top of what it called WebKit—a fork of the Linux-oriented KHTML project. In 2004, Mozilla released Firefox, based on a thoroughly overhauled Gecko engine it had inherited from Netscape. Four years later, Google’s Chrome, also built on WebKit, emerged.
Browsers based on WebKit and Gecko were faster, produced better-looking and more-interactive pages, and had fewer security flaws when used with Windows. More important, Apple put Safari on every Mac; Google promoted Firefox in its ever-more-popular search engine; and then Google encouraged visitors to download its own Chrome offering when that became available. These days, though IE still maintains a marketshare of at least 50 percent, Firefox, Chrome, and Safari split up most of the rest on the desktop. (Specifically, the numbers as of March 2013 are 56, 20, 16, and 5 percent for IE, Firefox, Chrome, and Safari, respectively, according to figures from Net Applications.)
On the mobile side, smartphones had a negligible share of overall browser usage until Apple released the iPhone in 2007 with a version of WebKit-based Safari. Android adopted WebKit from the beginning of its development in 2009. The two platforms together account for more than 90 percent of mobile browsing, according to Akamai. The separately available mobile Chrome (based on WebKit) and Opera Mini take most of the remaining share of usage. Opera, which currently has its own engine, said in February 2013 that it would move to WebKit, but then last week amended that plan to adopt Blink instead.
The world today
We’re in a world now in which Microsoft’s IE (using its little-mentioned Trident engine), Firefox’s Gecko, and the Apple-backed WebKit control substantial fiefdoms. Microsoft’s desktop dominance continues to erode, however, and it has multiple competitors there. Meanwhile, WebKit may own mobile, but Apple’s substantial share (in the form of mobile Safari) doesn’t give it absolute power—as the Blink fork shows. And Apple must contend with versions of IE, Firefox, and Chrome on the desktop, where Safari has only a tiny piece of the market.
In this environment, every engine and browser project is under marketplace pressure to render pages as well as every other browser, since any substantial deviation could drive users to other options. Even on iOS, where Apple requires third-party browsers to use the WebKit engine (that goes for you, too, Firefox and Chrome), mobile users may switch the browser front-end or ditch an iPhone for another platform if they’re frustrated enough by a not-very-compliant browser.
In this context, neither the Google announcement nor Mozilla/Samsung one gives me much pause. If anything, the fact that browser makers are heading in a different direction gives me hope for the kind of improvements that came in the disruptive wake of Gecko and then WebKit. Google isn’t abandoning WebKit, and Mozilla and Samsung aren’t planning some crazy move into incompatible standards. The competition is no longer about standards; it’s about mobile device marketshare expressed through speed and eyeballs.
Google said that Blink, its WebKit fork, had to happen because WebKit is now an unwieldy ball of crufty code designed for many system types, most of them irrelevant to Google. The company said the first stage of Blink’s transition will involve dropping 4.5 million lines of code from the WebKit code that Blink is starting from. (As noted above, Opera will adopt Blink, too.)
When WebKit2 was announced in 2010, Google and Apple moved to parallel development paths, even though Google kept using most of WebKit. Google had one method for “multi-process architecture,” which handles different activities as distinct computing jobs to let each tab run as a separate and secure operation. A crash doesn’t bring down the whole browser, and (ostensibly, anyway) a security exploit doesn’t compromise all open tabs or the browser itself. In its handling of the same task, Apple’s WebKit2 didn’t adopt Google’s code. Google says that working within Apple’s constraints has slowed development down.
The Mozilla and Samsung announcement is more about the long game than any short-term disruption. At February’s Mobile World Congress, Mozilla, which largely missed out on the move to mobile, announced Firefox OS, a Linux-based system that will boot on many current Android phones. The OS relies on some of the same free or open-source components as Android. For its part, Samsung is the only truly profitable handset maker besides Apple, taking about a third of the profit in the smartphone segment to Apple two-thirds—but it relies on Google.
Mozilla is writing the code for its new engine, Servo, in a new and more secure programming language called Rust that’s just a few years old. Rust aims to enable programmers to write code that is far less susceptible to exploitation through the many common paths available in existing languages. It’s also better designed for both the Internet and contemporary mobile devices to carry out many tasks efficiently at once. But it’s not ready for the big time yet: At this point, Servo remains an experimental engine written in still-in-development Rust. Samsung’s work with Mozilla to get Rust and Servo working on ARM chips is a long-range plan, with many months ahead before something production-worthy emerges.
Fork in the road ahead
What Blink and Servo have in common is the untangling of relationships among competitors in the mobile world. Samsung’s fortunes are tied to Android; and even as Google moves to Blink for its browsers, Samsung may want to fork Android or switch to Firefox OS. Google owns Samsung’s competitor Motorola, whose financial straits antedate Google’s acquisition by some years. Working with Mozilla on a browser engine appears to be a logical step for Samsung to take before adopting an OS that allows it to part from Google.
For its part, Google remains hobbled by ceding the future of WebKit to Apple. On a Hacker News thread, a Google developer pointed out that earlier this year Apple essentially laid claim to having the final say in all WebKit2 decisions. In an open-source project, the effectiveness of such an assertion depends on the willingness of the project’s leadership to accede. If they can’t resolve governance issues to their satisfaction, other parties are free to fork off—as Google did.
Though much of the surrounding rhetoric is nominally about performance, the core issues boil down to the sale of mobile devices and the viewing of advertisements on those devices. A better browser—one that is speedier and perhaps has enhancements to improve the experience—could help persuade users to purchase one device over another. Control of the browser can also mean control of the search engine it uses and of the display of ads.
But none of this translates into the kind of unruly world we had when Microsoft was the big dog and IE 5 and IE 6 were the steaming messes it left on our doorstep, which we’re still cleaning up. The relatively broad distribution of power today across multiple engines, companies, and platforms ensures that no individual party can strong-arm websites into updating in a way that breaks the experience for 40 to 80 percent of potential visitors. There may be a war in heaven, but the sky isn’t falling.