Browser engine forking isn't the end of the world
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.