Google parts ways with Apple over WebKit, launches Blink

A years-long marriage of convenience that linked Google and Apple browser technologies is ending in divorce.

In a move that Google says will technologically liberate both Chrome and Safari, the company has begun its own offshoot of the WebKit browser engine project called Blink. Initially it uses the same software code base that all WebKit-based browsers share, but over time it will diverge into a totally separate project, Google announced today.

The move marks the end of years of direct WebKit programming cooperation between the two rivals. WebKit is an open-source project, meaning that anyone can use and modify the software, but previously Google and Apple were all contributing to the same code base. With Blink, each company will go its own way, working separately to add new features and to support new Web standards rather than being able to capitalize on the other's work.

Major "forks" in open-source projects can be divisive and bitter, though a certain collegiality among Web programmers seems likely to forestall that negative outcome in the case of Blink. The pains of forking WebKit into Blink are worth it, argued Linus Upson, the Google vice president of engineering for Chrome.

"We're confident this will allow us to move faster and allow the rest of the WebKit community to move faster, which ultimately will allow the Web to move faster," Upson said.

Apple declined to comment for this story. Opera Software, which scrapped its own Presto engine and adopted Google's Chromium version of WebKit, will use and contribute to Blink, according to Opera Web evangelist Bruce Lawson.

The Blink name is a reference to the despised and now extinct blink tag of early HTML that made text blink off and on. It follows the pattern of Google naming projects after what it deems relics from the past: Chrome is designed to minimize user-interface "chrome" that surrounds Web pages; the Chromebook Pixel's high-resolution screen is designed to make pixels disappear; and Blink is designed to do away with browser engine irritations.

WebKit is a browser engine, software with the job of processing Web pages' instructions and rendering the result on a computing device's screen. Google used WebKit to give its browser a running start, but now Chrome is mature enough to stand on its own.

It's not just technical matters that led to the split, though. There never has been a single WebKit agenda for Apple and Google, and social tensions persisted as the two groups tried to work together.

Technical differences: Multiprocess design
One major example of how the Apple and Google WebKit projects have diverged involves how the browsers divide up computing processes running in parallel.

"Chromium has a very different multiprocess architecture than the other WebKit-based browsers," said Alex Komoroske, product manager for Google's Open Web Platform team. And because that's such a foundational part of the software, not some high-level module tacked onto the core, it's really hard to accommodate multiple approaches, he said.

One example of something Google would like to do is assign different sections of Web pages called iframes to various computing processes. "It would be great for security and stability and performance if we could have iframes embedded in pages be a separate process," Komoroske said. "But it would require a lot of change that would really disrupt the rest of the WebKit community."

As Web apps have become more sophisticated and the Internet has become a foundation for so much work, entertainment, communication, and learning, Web engines have risen commensurately in importance. They're now effectively operating systems unto themselves -- sometimes explicitly, as in the case of Google's Chrome OS and Mozilla's Firefox OS. Those heavy browser responsibilities mean core design decisions, such as multiprocess management, are critical.

Initially, Blink and WebKit will be identical as the former first splits off from the latter. But from that point forth, divergence becomes a reality.

"Over time they'll evolve in different directions, which will make it harder to share code," Komoroske said. "It'll be increasingly difficult to share a straightforward patch."

That forking also means others using the WebKit engine -- a list that includes Samsung, BlackBerry, Opera, Amazon, and others -- will have to decide which side of the fence they want to end up on.

WebKit growing pains
In principle, WebKit benefits from many contributors and from a dominant foothold among mobile browsing by virtue of iOS and Android. In practice, however, WebKit has been fragmenting as more and more parties get involved.

Google's Paul Irish described the WebKit variety well in February, shortly after Opera announced its plan to scrap Presto. Apple and Google WebKit implementations differ in how they display text and graphics, use hardware acceleration, and communicate over the network, for example. And even from its first days in public, Chrome had a different engine for running JavaScript programs.

In addition to Opera's big move, Google and Apple have also been expanding WebKit. Previously, Google's Android browser was a separate project, although based on WebKit, but the company pulled it into the main WebKit code base as it built Chrome for Android.

And Apple is doing the same thing, "upstreaming" elements of its iOS browser into the main WebKit project rather than maintaining them downstream in a separate software repository. (Open-source software development is an exercise in metaphor: Code comes in trees that can branch or fork into separate projects, and code changes can flow downstream to subprojects or upstream to higher-level master repositories.)

Apple's iOS move illustrated some frictions between Google and Apple engineers.

In one discussion, Chrome programmer Adam Barth objected to what he called a "growing trend of unilateral action by Apple in this project."

In response, Apple's Maciej Stachowiak tried to ease diffferences:

If we'd taken an equally hard line when Google wanted to merge the Chromium port to trunk, with a number of design choices in place that we didn't agree with but which were hard to change, it probably still wouldn't be in the tree to this day. I don't think that would have been a good thing for the WebKit project.

Perhaps the most succinct summary of the situation came in a long post titled "WebKit wishes" by Chrome programmer and former Safari programmer Eric Seidel. He pointed to the difficulties of supporting no fewer than eight separate systems for building software off the same code base; to the lack of an overarching decision-making process to decide upon what new features to bring to a huge fraction of Web users; and to social difficulties between the Apple and Google teams:

The WebKit community is full of brilliant engineers. Yet I frequently feel a lack of trust in my (or others') judgment, or witness hot-headed remarks on bugs, lists or IRC...Social problems are perhaps harder to solve for us technical types, but I worry that for many of us it's just become "us" and "them," and we've stopped trying.

Compatibility changes?
WebKit's power on the Web -- especially in the mobile world -- has triggered some angst and teeth-gnashing. Mozilla and Opera, for example, fretted when Web programmers built mobile sites that worked only with WebKit browsers.

When Opera threw in its lot with WebKit, more people fretted at the loss of an independent browser engine.

But Blink means that some of that independence is returning.

"It's our belief that having multiple rendering engines will spur innovation," Komoroske said. "In the long term, we're increasing our commitment to standards."

One downside of that independence means that Web programmers will have to test their sites with more browsers. To invoke existing features that aren't yet standards on Blink, programmers will be able to use the "-webkit" prefix in their code. For new features, Google wants to avoid such prefixes altogether by adopting Mozilla's practice of keeping immature features behind a flag. Users must specifically set the flag before the feature is enabled.

Another downside is that programmers won't be able to share as much work supporting new features.

"By sharing the code base, we gain certain efficiencies," Upson said. Overall, though, it's worth it, he argued. There are inefficiencies, too, in trying to get engineers to agree on a single approach or to accommodate different approaches. "We only wanted to do this if the net efficiency gain would be positive for everyone."