WebKit fracture puts a pinch on open-source browser efforts

The WebKit browser engine is becoming a less flexible foundation for open-source projects with the departure of Google from the project this week and Apple's consequent paring back of the project.

WebKit is a broad project that includes participation from many interested parties -- not just Apple and Google, but also BlackBerry, Samsung, Amazon, Oracle, Adobe Systems, and the programmers involved with the KDE and Gnome user interfaces for Linux. Indeed, the open-source project began as KDE's KHTML engine for the Konqueror browser before Apple got involved.

Google's Chrome team left WebKit this week, forking the open-source software into its own Blink browser engine so it can move faster and make deeper changes. And apparently Google isn't the only one keen on a tighter, easier-to-manage project: Apple now is "cleaning up" WebKit.

Google's departure means WebKit's sole remaining superpower, Apple, is streamlining the software. And that, in turn, means WebKit is becoming less a-la-carte, with a variety of modules and options and ways to extend it, and more prix-fixe, with a set collection of components.

That means that at least in some areas, it'll become harder to use WebKit as a foundation for other open-source projects that, like Chrome did, depart significantly from what Apple is doing with Safari.

A key one is JavaScript, the programming language that gives brains to the Web, converting static pages into interactive apps. With Google around, it was possible to add a different JavaScript engine, and indeed Google did so with its V8 engine.

But now? Tough beans.

"Supporting [Google's] V8 places a considerable burden on WebKit," said Apple's Oliver Hunt on the WebKit developer mailing list. "There are a number of large, cumbersome and expensive abstractions required to support multiple JS engines." If programmers don't like Apple's offerings, they should file bugs to request improvements, not add their own engines.

That new policy caught out Oracle, which has been working on marrying its own JavaScript engine to WebKit as part of its JavaFX software.

"We at Oracle are working on using WebKit with our own JavaScript engine, Nashorn," said Per Bothner on the mailing list. "We would find it unfortunate if it becomes more difficult to build WebKit with an alternative JavaScript engine."

Samsung, too, is affected. It's using WebKit with Google's V8 JavaScript engine, said Mario Sanchez Prada on the mailing list.

But Apple's Maciej Stachowiak shut down any hopes:

Supporting multiple JS [JavaScript] engines has been a pain, and we only agreed to it because it was a showstopper for Google, and we had the expectation that Google would be a valuable high-volume contributor. Which they were, during their time in the WebKit project. Even so, it caused significant code complexity, divergence of efforts, and friction on architectural direction, because of the differing characteristics of JSC and V8.

I personally would be reluctant to make that type of deal again.

Effectively, people looking for an open-source browser project now must choose between Blink and WebKit rather than being able to draw from a larger, broader code base. Of course, they also can choose Mozilla's Gecko, too, or its new Servo browser engine, which Samsung is involved in building.

At least in principle, WebKit and Blink each should now be a cleaner, more elegant engine, but no longer is there a broad project whose priorities are balanced by two major players.