What Does The Chrome/WebKit Split Mean For Web Devs?

Earlier this week, Google announced it would be forking WebKit to start its own web rendering engine, called Blink. Google’s argument is that free of certain constraints imposed by WebKit, it’ll be better able to improve Chrome — and other browsers that adopt Blink — above and beyond what is possible now. That’s great for users, but what about those of us neck-deep in web dev?

Google’s stated its long-term plans for Blink are to foster a “healthier codebase” and as part of that edict, nothing we need to worry about should change for a while. To quote software engineer Adam Barth on the Chromium Blog:

In the short term, Blink will bring little change for web developers. 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 7000 files — comprising more than 4.5 million lines — right off the bat.

As any developer can appreciate, cutting this much cruft from a project is only going to make it easier to maintain and improve on.

The post also mentions that having multiple rendering engines will “spur innovation” and “improve the health of the entire open web ecosystem”, as one would expect from any industry with many competitors. Like with graphics APIs OpenGL and DirectX, vendors can add their own extensions (more so with OpenGL these days) that, if deemed useful, are rolled into the core specification.

When it comes to adding new features, Google will be employing a system based on “compatibility risk” to determine what should get priority. The process is described on the Blink project page, but essentially, any proposed “web platform features” with a high compatibility risk will be examined more closely before getting the go-ahead. The risk is based on the following factors:

Other vendors shipping compatible implementations
A mature specification in the relevant standards body
Positive signals from other browser vendors
A small API footprint

There’s even some rules of thumb. For example, if two browsers have the feature in their “stable” releases, it’s consider a “de facto standard”. When exceptions arise, the feature will be proposed to the “relevant standards group” and publicly discussed with other browser vendors.

So, until Google changes its methodology, I don’t see Blink being a problem for designers. Browsers have come a long way in the past 5-10 years — even Internet Explorer — and the number of crazy hacks one has to employ has diminished significantly.

Still, for the sake of completeness, we’ll be adding one more browser to the test list and it’s difficulty to find anything positive to say about that. In fact, there’s a point that seems to have gone unnoticed as far as I can tell — the performance gap.

We’re already seeing it now with WebGL — some browsers just handle 3D better than others. One of Blink’s aims is to improve the speed of web rendering; Google’s even provided a list of proposed changes, some of which could result in noticeable boosts:

Experiment with moving the DOM into the JS heap
Increase multicore use (e.g., html parser, style engine, javascript parser)
Remove obscure parts of the DOM and make backwards-incompatible changes to obscure parts of the DOM that benefit performance or remove complexity.
Use a modern, faster tcmalloc throughout all of Mac chrome
Experiment with incremental or parallel layout
Fix memory leaks by removing the ScriptValue/ScriptState abstractions now that there’s only one JavaScript engine.
Bring WebCore up to speed with DOM3 Events / [DOM] UI Events.

And this is just the start, I’m sure. JavaScript engines have matured considerably and while their are speed differences between browsers, they’re not as pronounced as they once were. WebGL, on the other hand, is still being tweaked by vendors. The danger is that if you spend all your time developing in one browser where performance appears acceptable, even snappy, you could fire up another and find that your beautiful site is sluggish or worse still, unusable.

This is an issue developers have struggled with forever — performance on different hardware — but between browsers on the same platform? I don’t know if it’s going to be that big a problem, but it’s one I’ll be keeping an eye on as Google pushes ahead with Blink. The company made headlines with its V8 JavaScript engine, who’s to say it won’t take regular web rendering in the same direction, leaving other vendors to play catch-up?

In the long-term, it’s certainly a good thing, but perhaps we’re in for a few headaches as the browser landscape adjusts.

Blink: A rendering engine for the Chromium project [Chromium Blog, via VentureBeat]