Google has announced it is moving forward with its own fork of WebKit called Blink. The new fork will power the Chromium and Chrome web browsers. Opera, which is tracking the Chromium build of WebKit, said, via employeeBruce Lawson’s blog, that it will be following Google’s fork and also using Blink. Google explained that it was forking because its multi-process browser architecture was different from other WebKit-using browsers and that the complexity and cost of supporting the multiple architectures was slowing it down in terms of development.
WebKit provides a rendering engine for many browsers and has its roots as Apple’s fork of the KHTML project which it used to create the Safari browser. The LGPL-licensed KHTML rendering code within the WebKit project was called WebCore and Apple, Google and others made their modifications to that using BSD-licensed code. Within the project, the ancillary functions such as JavaScript support and network access were handled by a collection of BSD-licensed code named WebKit.
But, Google, with its own JavaScript engine in the form of V8, had little use for that code and even less use for WebKit2 – the next generation of WebKit which is adding a multi-process architecture to the renderer – as it had already constructed Chrome to run in a multi-process fashion. By forking to create Blink, it can drop a large amount of code from WebKit – it believes that around seven build systems, 7,000 files and 4.5 million lines of code can be eliminated almost immediately. The company says it this should lead to a more stable, healthier code base over time.
The Blink project page emphasises that Google wants to run Blink as “an inclusive open source community” and invites outside developers to participate. It is already outlining its plans for the new code base. One leading change it plans is support for out-of-process iFrames which will allow for in-page sandboxing. Freed of older API obligations, Google also plans a revamp of the networking code it uses in Chromium and Blink. Among the more provisional plans is an idea to integrate the DOM (Document Object Model) as JavaScript data structures rather than as a standalone model; the hope is that this should increase the performance of JavaScript web applications.
Among other changes Google will be making, it is moving to a “no prefix” model of web enhancements. Vendor prefixes have been used in browsers to denote experimental features for many years. Unfortunately, web developers have often used, and relied on, those prefixes. With Blink there will be no prefixes except those inherited from WebKit. Instead, developers will have to turn on experimental features on an about:flags page until the feature is suitable to be enabled by default. Google points out that Mozilla is moving towards a similar policy and that the W3C is exploring a similar idea.
Underlying Google’s choice is, according to Chrome developer Alex Russell, the maxim “going faster matters”. In a personal blog post, Russell explains that faster in this case is not just the performance of the code but the complexity and time taken to build it. Despite work done to accelerate build times and make the entire process of development faster, Russell says that the fork will allow Google’s coders to iterate Blink, Chrome and Chromium faster and that they already know the benefits of fast iteration with the Chrome code.
Google has already been working on Blink and the first Blink-based Chrome should arrive in Chrome 28; Chrome 26 has just been released as a stable version. Opera is using theChromium Content API to work with WebKit and should have a relatively easy job of migrating to Blink. Google says that in the short term, the Blink fork should have little impact for web developers. Once it is established though, Google obviously plans to increase the velocity of its web browser development.
via The-H