With Google’s announcement yesterday to fork WebKit and build a new rendering engine called Blink, the WebKit team has announced plans to streamline the project. Since the rendering engine no longer needs to support the Chromium port, there’s a huge slew of code that can be removed.
Here’s the high-level plan:
Concepts we plan to remove:
Layering violations in WebCore/platform, where a Page* or Frame* is passed to a function
Supplementable and Supplement
WebLayer and its scrolling implementation
Features #defines that haven’t gained traction
Specific files we plan to remove:
.gyp build files
“We're hunting for awesome startups”
Run an early-stage company? We're inviting 250 to exhibit at TNW Conference and pitch on stage!
This is actually a good thing. Leaner code should not only ease development, but should speed it up as well. Furthermore, there are also security benefits to managing less: the more complex your software gets, the more potential there is for security holes.
Here’s what Google said yesterday:
The bulk of the initial work will focus on internal architectural improvements and a simplification of the codebase. 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 codebase leads to more stability and fewer bugs.
It’s not clear how much Chromium-specific code WebKit will be able to remove, but it’s certainly quite a large amount. The above paragraph from Google applies to both parties: at least in terms of efficiency, this is a good thing. Whether the Web will end up benefiting in the long term remains to be seen.
See also – Google’s Blink Q&A: New rendering engine will replace WebKit on all platforms in 10 weeks with Chrome 28 and Opera confirms it will follow Google and ditch WebKit for Blink, as part of its commitment to Chromium
Top Image Credit: Sebastian Danon