Google going its own way, forking WebKit rendering engine | Ars Technica

Google announced today that it is forking the WebKit rendering engine on which its Chrome browser is based. The company is naming its new engine "Blink."

The WebKit project was started by Apple in 2001, itself a fork of a rendering engine called KHTML. The project includes a core rendering engine for handling HTML and CSS (WebCore), a JavaScript engine (JavaScriptCore), and a high-level API for embedding it into browsers (WebKit).

Though known widely as "WebKit," Google Chrome has used only WebCore since its launch in late 2008. Apple's Safari originally used the WebKit wrapper and now uses its successor, WebKit2. Many other browsers use varying amounts of the WebKit project, including the Symbian S60 browser, the BlackBerry browser, the webOS browser, and the Android browser.

Until now, Google has rigorously tracked the WebKit project, both integrating patches made by other WebKit developers and pushing its own changes made during the course of Chrome's development back upstream.

Linus Upson, vice president of Engineering at Google, and Alex Komoroske, product manager on the Open Web Platform team, told us that the costs of sharing code now outweighed the advantages. There is considerable complexity in WebCore that is there to support WebKit2 features that Google does not want or use.

For example, WebKit2 has its own multiprocess model for creating individual processes for each browser tab. For Chrome, Google developed its own multiprocess system. Similarly, WebKit2 has a sandboxing model to isolate each process. Google has a separate system for Chrome.

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.

Google also argues that the decision will introduce greater diversity into the browser ecosystem and might mitigate concerns that the mobile Web in particular was becoming a WebKit monoculture. Although WebKit is not a monolithic entity—different browsers based on WebKit use different options and have different behavior—the different variants are more or less convergent.

With Blink, Google will have greater freedom to diverge and go its own way, concentrating on the features it believes are most important.

For Web users and Web developers, there won't be any immediate differences. As of right now, Blink is essentially identical to WebCore, and the first pieces of work that Google does will be to clean the architecture up to remove extraneous pieces that it doesn't need. The first Canary builds will be built tonight or tomorrow, and these will trickle into developer, beta, and eventually stable releases at six-week intervals.

Longer term, we can expect to see Blink evolve in a different direction from WebKit. Upson and Komoroske told us that there were all manner of ideas that may or may not pan out that Google would like to try. The company says that forking WebKit will give it the flexibility to do so.

Update: Google has now published an FAQ about the project. Of particular interest to Web developers: there won't be any -blink or -chrome CSS prefixes; like Mozilla, all new experimental features will require developers to enable them in the browser's options page. And Opera has announced that it will be tracking and contributing to Blink. Back when it announced that it was switching to WebKit, the company said that it was tracking Chromium, so this makes sense.