Reading some of the comments on the Blink launch, I've noted a little confusion over the relative roles of WebKit/WebKit2/Chromium code modules.WebCore
is the actual layout engine. My understanding is that it's not intended to be consumed by people directly.WebKit
provides an embedding API around WebCore. Different ports provided different implementations for various UI frameworks like Cocoa, Gtk, etc.WebKit2
is similar, but using a multi-process harness.
For Chrome, we provided our own implementation of the WebKit API intended to be used by only one customer - our Content API
layer which is the real embedding API that the rest of Chrome is built on. It provides some level of isolation from WebKit/Core for the rest of the Chrome codebase. All of our ports are done in the Content layer, since WebCore is run in a separate process with limited privileges (these processes can't even create a platform native widget). Content layer provides the native widget onto which the rendering engine can draw, the bridge to the native event system, networking, and other necessary pieces.
Content does not provide a stable API - it's primary purpose is to support the development of the Chrome browser. It changes quite a lot, so to use it you either need to develop in lockstep with it at tip-of-tree like Chrome does, or use a third party solution like CEF
(Chromium Embedded Framework
) which wraps Content in a more stable API.
Note that Content predates WebKit2 by several years, it was one of the first pieces of code developed for Chrome and has grown significantly since. Content is a foundational piece of the architecture of Chrome, and much of our application code is built on its behavior and abstractions.
A multi-process architecture for a browser is a complex and nuanced thing. One example, in a cross platform world when you're supporting NPAPI plugins, you end up having to support native UI framework quirks and possible deadlocks that are very platform specific (I'm looking at you, Win32). The Chrome team has spent a huge amount of time over the past ~ half decade hunting down this kind of nastiness.
For these reasons, just "replacing" Content with another upstream library (e.g. WebKit2) designed with potentially different constraints in mind without understanding its behavior would be a major undertaking.