Why Chromium Forked WebCore to Create Blink in 2013

In April 2013, Google announced that its open-source Chromium project would fork the WebCore component of the WebKit rendering engine to create a new engine called Blink. This decision was driven by growing architectural divergences between Chromium and other WebKit-based browsers, excessive code complexity, and a desire to accelerate the pace of web platform innovation. By breaking away from the shared codebase primarily maintained alongside Apple, Google aimed to streamline development, remove millions of lines of legacy code, and build a rendering engine tailored specifically for Chromium’s unique multi-process architecture.

Conflicting Multi-Process Architectures

From its inception in 2008, Chromium was built to use a multi-process architecture. This design isolates individual tabs, extensions, and plugins into separate processes to improve security and prevent a single crashing webpage from bringing down the entire browser.

Because WebKit was not originally designed for this model, Google engineers had to build complex abstraction layers to make WebCore function within Chromium. In 2010, Apple introduced its own multi-process framework for WebKit, known as WebKit2. However, WebKit2 was fundamentally incompatible with Chromium’s existing sandboxing and process models. As a result, the shared WebKit codebase had to maintain two completely different multi-process architectures. This duplication created friction, bugs, and slowdowns for both Google and Apple engineers.

Eliminating Code Bloat

WebKit was designed to be highly portable, supporting multiple operating systems, frameworks, and browser vendors—including Apple, Google, BlackBerry, and Nokia. Each version was known as a "WebKit port."

While this flexibility helped WebKit become the dominant rendering engine for mobile and desktop browsers, it eventually became a maintenance burden. Chromium engineers had to navigate thousands of conditional compile flags and code paths that only existed to support other ports. By forking WebCore into Blink, Chromium was able to strip away all non-Chromium code. Within the first few months of the fork, Google deleted roughly 7,000 files and 4.5 million lines of redundant code, making the engine lighter, easier to debug, and faster to compile.

JavaScript Engine Friction

A browser's rendering engine must communicate constantly with its JavaScript engine. While Apple’s Safari used WebKit’s native JavaScriptCore engine, Chromium used Google's V8 JavaScript engine.

Supporting both engines within WebCore required maintaining two separate sets of "bindings"—the glue code that allows JavaScript to manipulate the Document Object Model (DOM). Whenever an engineer wanted to add a new web feature or change how the DOM worked, they had to write, test, and maintain code for both JavaScriptCore and V8. Forking WebCore allowed Google to completely remove the JavaScriptCore bindings and deeply integrate V8 directly into Blink, resulting in better memory management and faster performance.

Accelerating the Pace of Innovation

By 2013, Google and Apple had diverging visions for the future of the web. Because they shared a codebase, major architectural changes required consensus from reviewers at both companies. This governance model slowed down development, as patches that benefited Chromium might be blocked if they negatively impacted Safari, and vice versa.

Google had ambitious plans that required deep, disruptive changes to the rendering engine. These plans included:

  • Out-of-process iframes (OOPIFs): Running embedded content in separate processes for enhanced security.
  • Web Components: Introducing a new standard for reusable custom elements, which required significant changes to the DOM.
  • Rendering Pipeline Overhauls: Moving scrolling, animations, and compositing off the main thread to ensure smooth performance on mobile devices.

Attempting to execute these massive rewrites within WebKit without breaking other ports was no longer practical. Creating Blink gave Chromium engineers the autonomy to radically alter the engine's internals, experiment with new web standards, and ship features at their own pace.