WebKit, Blink, and the big split

The WebKit web rendering engine is used by free software projects of just about every flavor, from embedded Linux products to desktop browsers. Until recently, it was also the rendering engine that powered Google's Android and Chrome. At LinuxCon North America 2013 in New Orleans, Juan Sanchez from Igalia presented an inside look at the history of WebKit, and shared some thoughts on how the project will be affected by Google's decision to fork WebKit and create its own Blink engine.

Considering all the talk about HTML5 as the future of application development, Sanchez said, people talk surprisingly little about the actual components that go into delivering that future. WebKit is a key player, he explained. It is essentially the only practical choice for free software developers who want to embed web rendering into their code; Mozilla's Gecko is a highly capable rendering engine as well, but it is tied to the internals of Firefox in ways that make it less flexible for other uses. Igalia is one of the top contributors to WebKit; the company maintains the WebKitGTK+ "port" (a term with a specific meaning in the WebKit community) and it does a lot of consulting work for other companies which often includes embedding the WebKit engine.

The bird's eye kit

Sanchez reviewed the history of the project, and how the architecture of the code has evolved along with the community. WebKit started off as a fork of the KHTML renderer and KJS JavaScript engine from KDE. Apple began WebKit development in 2001, then opened the project up (with its contributions under a permissive BSD license) in 2005. WebKit's scope is limited: it just provides an engine that can understand and render HTML, CSS, JavaScript, and the Document Object Model (DOM), plus ways to interact with those web page contents. It does not attempt to be a browser on its own, and project members are not interested in turning WebKit into one. The project's focus is on compatibility: adhering to standards and providing components that are rigorously tested for compliance. As such, the project is pragmatic about its decision making—or as Sanchez put it, "WebKit is an engineering project, not a science project."

The entirety of what is commonly called WebKit consists of a few discrete parts, he said. There is the component called "WebKit," which simply provides a thin API layer for applications above it in the stack. Underneath this layer is "WebCore," which contains the rendering engine, page layout engine, and network access—the bulk of the functionality. In addition, there is a JavaScript engine (although which one is used varies from one WebKit-based application to another), and a platform-specific compatibility layer that hooks into general-purpose system libraries.

A "port" in WebKit is a version of WebKit adapted to specific target platform. The main ports maintained by the project are iOS, OS X, GTK+, Qt, EFL (for Tizen), and Google's Chromium. One new port is being discussed: WebKitNIX, which would be a lightweight port for OpenGL. But there are many smaller ports of WebKit as well, such as those for Symbian and Blackberry. To further illustrate how ports are designed, Sanchez explained how the WebKitGTK+ port is structured: The WebKit API layer becomes webkit/gtk, the JavaScript engine is JavaScriptCore, and the platform-specific compatibility layer calls out to GNOME components like libsoup, GStreamer, Cairo, and the Accessibility Toolkit (ATK).

Recent history and changes

In addition to the architecture described above, there is also another, known as WebKit2, which is currently in development. As Sanchez explained, WebKit2 is intended to replace the "WebKit" API layer, primarily to support a split-process model. In the new model, the user interface runs in one process, the main parsing and rendering of web content runs in a second process, and browser plugins run in a third. The goals are increased stability and performance, plus better security brought about by isolating the processes. Apple initiated the WebKit2 effort, and the code is currently working in the GTK+ and Qt ports as well. It is more-or-less complete, so that WebKit1 will move into maintenance mode shortly.

A major issue, however, is that WebKit2 is unrelated to Google's own work adapting Chrome to a split-process design. Chrome draws the "split process" barrier lower, so that each Chrome instance can have several rendering processes. This difference of opinion between Apple and Google goes back quite a ways, but it certainly contributed to Google's recent decision to fork WebKit and create Blink.

Another possible factor in the split related to project governance. The project has long had just two officially-defined roles: committer and reviewer. A committer must have sent in 20 to 30 patches and demonstrated a commitment to the project's rules: once designated a committer, a person can submit changes, although their changes are always reviewed. Becoming a designated reviewer is more difficult: around 300 patches are required, and three existing reviewers must vouch for the candidate. But once designated, a reviewer can commit changes directly, without review. More recently, though, Apple introduced the new top-level role of "owner," and declared that only owners would be allowed to commit changes to WebKit2.

Google abruptly left WebKit in April, via a surprise announcement that Sanchez said came as a shock to the WebKit community. Over the preceding years, as it had contributed to WebKit for Chrome, Google had risen to the point of equaling Apple in terms of the number of commits—each company contributed about one third of the changes to the code, with the remaining third coming from everyone else (Igalia included). In addition to the number of commits, Google actually had more engineers working on WebKit than did any other company (including Apple, who had fewer developers even though those developers produced as many patches as Google's).

WebKit from here on out

The divergence of Chrome and WebKit's multi-process model and Apple's desire to add a top-tier level of committer were both factors in Google's decision to start Blink, but there were other factors, too. Sanchez said that Google expressed its desire to simplify Blink's architecture, eliminating the concept of ports altogether and building the rendering engine specifically to suit Chrome's needs. The Blink code has already started to diverge, he said, and so far the Blink governance model is far simpler: there is no official code review, just people submitting changes and looking at others' changes informally. The majority of the Blink developers are Google employees, he said, but outside contributors have begun to appear, too.

Google's departure will certainly have an impact on WebKit, Sanchez said, although how much remains to be seen. The company obviously contributed a lot of code, so the developer-power will be missed, as will Google's ability to balance out Apple. With Apple as the largest remaining contributor to the project (and by a large margin), it will likely be more difficult for other companies or volunteers to have a say in steering the project.

The WebKit community is already seeing the impact of Google's departure in terms of orphaned modules that now need new maintainers. But there are also several instances of downstream projects dropping WebKit in favor of Blink. Sanchez noted that Opera had announced it would switch to WebKit just a few days before the Blink announcement; the company then issued a follow-up announcement announcing that it would be switching from WebKit to Blink. More recently, of course, Qt announced that it would adopt Blink as its HTML rendering engine, too.

On the other hand, Sanchez said, there were positive outcomes to Google's departure. Apple now seems likely to drop its proposal for a formal "owner" contributor role. There are also several hacks put into WebKit specifically for Chrome support that have already been removed. But that also means that the two rendering engines have already begun to diverge, and Sanchez said he was not sure how long code would remain portable between the two. It is good that free software developers now have two engines to choose from when creating an embedded web application, after so many years of WebKit being the only viable option. But the divergence could ultimately prove bad for the community, at least in some ways. Only time will tell.

[The author would like to thank the Linux Foundation for assistance with travel to New Orleans.]