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."
Linus Upson, vice president of engineering for Chrome, speaking at Google I/O in 2011.
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."