Google’s decision to branch off from WebKit and develop its own Blink browser rendering engine is a matter of speed not fragmentation and control, one Chrome team developer has argued, pointing out that what’s currently the de-facto standard has already become a weight around devs’ necks. “To make a better platform faster, you must be able to iterate faster” Google London’s Alex Russell argues, likening the sluggishness of adding and tweaking WebKit features to the inefficiency of using an old computer when newer, faster ones are available. As a bonus, he points out, developers will be less likely to inadvertently break something when modifying the Blink engine, a situation Russell says can often occur when dealing with WebKit.
“Blink gives developers much more assurance that when they change something, it’s only affecting the things they think it’s affecting” he explains, thanks to the engine’s Content API boundary. That’s the part of Blink which – though for the large part following the WebKit API design – differs in that it isolates Chrome developers “from inner workings of content.”
For Russell, though – and presumably Google as a whole, given its web/cloud-centric focus – the speed potential for jumping ship to Blink is what really makes the fragmentation worthwhile. The Chromium team has enjoyed such streamlining in Google’s own “Chromey” parts, he points out, and now will get the same in the underlying engine. That, the reasoning goes, means a browser that is improved faster and keeps better pace with the demands of users and developers.
“Directness of action matters, and when you’re swimming through build files for dozens of platforms you don’t work on, that’s a step away from directness. When you’re working to fix or prevent regressions you can’t test against, that’s a step away. When compiles and checkouts take too long, that’s a step away. When landing a patch in both WebKit and Chromium stretches into a multi-day dance of flags, stub implementations, and dep-rolls, that’s many steps away. And each step hurts by a more-than-constant factor” Alex Russell, Chrome team, Google
The losses from adopting Blink are the obvious ones, Russell says: divorcing development from “a community of hugely talented people” working on WebKit, for instance. Some old faces are likely to be present, however; Opera has confirmed, TNW reports, that it too will be using Blink having already committed to switching to Chromium back in February.
“When we announced the move away from Presto, we announced that we are going with the Chromium package, and the forking and name change have little practical influence on the Opera browsers” Opera spokesperson
Who will follow next remains to be seen, though given Google’s footprint in smartphones and tablets with Android, not to mention its push to move users onto the web in Chrome OS, developers certainly won’t be able to avoid Blink moving forward.