Blink
However, Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects. This has slowed down the collective pace of innovation - so today, we are introducing Blink, a new open source rendering engine based on WebKit.
By forking WebCore to create Blink, Google claims that all WebKit users will be able to innovate more quickly. Google can remove infrastructure that exists only to support WebKit2’s features, with the company claiming that in one fell swoop it can discard 7,000 files and 4.5 million of lines of code that exist only to support WebKit2’s architecture. In turn, this removes the ongoing cost of supporting this infrastructure.
Conversely, the WebKit project no longer needs to worry about making changes that might break WebCore for the way Chrome uses it.
Why couldn’t those cycle-time-improving changes happen inside WebKit? After all, much work has happened in the past 4 years (often by Googlers) to improve the directness of WebKit work: EWS bots, better code review flow, improved scripts and tools for managing checkins, the commit queue itself. The results have been impressive and have enabled huge growth and adoption by porters. WebKit now supports multiple multi-process architecture designs, something like a half-dozen network stack plug-ins, and similar diversity at every point where the engine calls back to outside systems for low-level implementation (GPU, network, storage, databases, fonts…you name it). The community is now committed to enabling porters, and due to WebKit’s low-ish level of abstraction each new port raises the tax paid by every other port.
The Chromium FAQ:
We want to do for networking, rendering and layout what V8 did for JavaScript. Remember JS engines before V8? We want the same sort of healthy innovation that benefits all users of the web, on all browsers.
[…]
We’ve seen how the proliferation of vendor prefixes have caused pain for developers and we don’t want to exacerbate this. As of today, Chrome is adopting a policy on vendor prefixes, one that is similar to Mozilla’s recently announced policy.
Update (2013-04-04): Maciej Stachowiak (via Daniel Jalkut):
Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute their multiprocess support back to WebKit, so that we could build on it. They said no.
At that point, our choices were to do a hostile fork of Chromium into the WebKit tree, write our own process model, or live with being single-process forever.
1 Comment RSS · Twitter
It's not a schism. The Chromium guys are just leaving to spend more time with their families…
