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 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.

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.

About the author

Stephen Shankland has been a reporter at CNET since 1998 and covers browsers, Web development, digital photography and new technology. In the past he has been CNET's beat reporter for Google, Yahoo, Linux, open-source software, servers and supercomputers. He has a soft spot in his heart for standards groups and I/O interfaces.
See full bio