Google’s Chromium products, from its Chrome browser to Chrome OS, need more flexibility than possible using its existing rendering engine, so the company’s developers have created a forked version that better meets the needs of the ongoing Chrome projects.
The announcement to move to “Blink,” a customized, forked version of the existing WebKit rendering engine, was made in an April 3 post by Adam Barth, a Google software engineer, on the Chromium Blog.
“WebKit is a lightweight yet powerful rendering engine that emerged out of KHTML in 2001,” Barth wrote. “Its flexibility, performance and thoughtful design made it the obvious choice for Chromium’s rendering engine back when we started. Thanks to the hard work by all in the community, WebKit has thrived and kept pace with the Web platform’s growing capabilities since then.”
The problem with continuing to use WebKit into the future, though, is that Google’s Chromium project, which includes the Chrome browser, Chrome OS and other applications, “uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects,” he wrote. “This has slowed down the collective pace of innovation—so today, we are introducing Blink, a new open-source rendering engine based on WebKit.”
The change in the architecture and history of the development projects was not taken lightly, he said.
“This was not an easy decision,” Barth wrote. “We know that the introduction of a new rendering engine can have significant implications for the Web. Nevertheless, we believe that having multiple rendering engines—similar to having multiple browsers—will spur innovation and over time improve the health of the entire open Web ecosystem.”
A rendering engine takes the entered code and translates it to create the images seen on a user’s screen when the information is viewed on a mobile device, desktop computer or other device.
“In the short term, Blink will bring little change for Web developers,” Barth wrote. “The bulk of the initial work will focus on internal architectural improvements and a simplification of the code base. For example, we anticipate that we’ll be able to remove 7 build systems and delete more than 7,000 files—comprising more than 4.5 million lines—right off the bat. Over the long term a healthier code base leads to more stability and fewer bugs.”
During the transition from WebKit to Blink, Google developers will “collaborate closely with other browser vendors to move the Web forward and preserve the compatibility that made it a successful ecosystem,” he wrote. “In that spirit, we’ve set strong guidelines for new features that emphasize standards, interoperability, conformance testing and transparency.”
The Blink project Web page says the effort means that developers will now have the “freedom to dream big for the Web. When Chromium started, our goal was to change as little of WebKit as possible, easing integration with the WebKit code base. With Blink we are excited to make large-scale architectural changes to the code, without having to worry about breaking other consumers of WebKit. “
A key upcoming change is the addition of “out-of-process iframes,” which will allow Chromium to separate individual parts of a page into separate sandboxed processes, according to organizers. “Implementing this will require large restructuring of how iframes are handled in WebKit. Some of this restructuring is incompatible with other WebKit ports and has thus been delayed until now.”
Also being eyed as a Blink goal is to “fix our networking code to be faster and simpler. Our current networking code in WebKit is limited by old Mac WebKit API obligations which cannot be changed. Chromium has worked around some of these limitations over the years, but these workarounds have proven fragile and have long been a source of bugs. With Blink, we’re excited to refresh this networking code without forcing other WebKit consumers to break their WebKit API obligations. “
Another potential idea is to eventually move “the entire Document Object Model (DOM) into JavaScript,” according to organizers. “This has the potential to make JavaScript DOM access dramatically faster, but will involve a very large rewrite of WebKit’s DOM implementation—something that would be difficult in WebKit, which has two supported JavaScript engines.”