Developer

Good, bad, or ugly? Chromium forks WebKit to create Blink

Blink is the recently announced fork of the WebKit-rendering engine for Google Chrome, but is it good news for users and developers, or purely a business move?

The folks at the Google Chromium Projects have decided to fork the WebKit-rendering engine for Chrome and are now putting their energies toward the Blink open source browser rendering engine, with the mission, "To improve the open web through technical innovation and good citizenship."

The forked version, according to The Chromium Blog, is now a primary focus since Chromium has historically used a distinctive multi-process-architecture which is unlike WebKit-based browsers. It grew to become more complex, which resulted in stalling innovation and progress. The project is concentrated on simplifying the code base from what now stands at just over 4.5 million lines, and they hope to remove over 7,000 files which comprise seven build systems. The blog goes on to say that little will change for web developers in the short term, but with Blink, one has to ask what might be the implications for the long haul?

Blink is an open source community of supporters who value transparency and are open to anyone wanting to participate in the discussion, no matter the organization or affiliation. Several places for ongoing discussions include the Chromium Bug Tracker, Code Reviews, the #blink IRC channel on Freenode, and the Blink-Dev Group on Google Groups, which help to keep the momentum and development moving ahead.

The good

The chief motives behind the shift include a need to improve performance, speed, stability, and security of the web platform in Chrome, so this will be a good thing for growing population of Chrome browser users...eventually. With Chrome ahead of the pack in terms of worldwide web browser usage and hovering around 38% as of March 2013, it continues to show user growth while other browsers (IE 29.3%, Firefox 20.87%, and Opera 1.17%) have shown a steady decline, with the exception of Safari (8.5%).

Specifically, the project is concentrating on delivering a speedier DOM and JS engine, keeping the platform secure, refactoring for performance, and enabling a more powerful rendering and layout, including multi-threading. Combined with the project focus of speeding up development and improving overall performance benchmarks, the refocus bodes well for both developers and users alike.

The bad

With Apple having a large stake in the WebKit-rendering engine, it made good business sense for Chrome to distance itself and create a rendering engine of its own. But, what does that really mean for web standards? Like I mentioned above, don't expect any new web standards or Chrome innovations just yet; this may be more of a political move and business posturing for Google Chrome through the long haul. While the project maintains that it is an open source community, how many software developers outside of the current browser smokestacks are ready to dive into the realm of rendering engine code?

The ugly

The Blink Developer FAQ answers plenty of questions you might ask about the motives behind the move. However, to get the "read between the lines" explanation, you might want to take a look at Rob Isaac's cutting, yet comedic translation on selected portions of the frequent questions. Rob takes a witty approach to exposing what could be the real reason behind Blink, but only time will tell if Google's motivations are well intentioned.

About

Ryan has performed in a broad range of technology support roles for electric-generation utilities, including nuclear power plants, and for the telecommunications industry. He has worked in web development for the restaurant industry and the Federal g...

4 comments
laseray
laseray

The article linked to in "The ugly" is just a clear example of the same kind of FUD that Microsoft is well-known, now we see it from an Apple fanboy also. Apple clearly took (stole) the code from an open source project to make its browser and then acted to not participate well in that. Now when Google tries to fork similar code, not just take without participating, it is frowned upon. Double standards from apple zealots, no, that couldn't be possible ;)

Gisabun
Gisabun

When Google completely switches over to Blink, expect another massive batch of vulnerabilities. If you know what is the last Chrome version with WebKit, I'd turn off auto-upgrading until Google gets it's act fixed because vulnerabilities and bugs will plague Chrome for a long while - in addition to the problems it already has.

Rauno
Rauno

WebKit was forked from Khtml in 2003. Khtml is developed since 19999 by just a few KDE developers. Yet the KDE web browser Konqueror has become one of the most innovative and standard compliant browser in just a couple of years. It had omnibox many years before Chrome, right-to-left writing second after IE, SVG support since 2001... Apple forked Khtml in a way that prevented the open source community to benefit from the development. Apple worked secretly during more than a year. They made changes specific to their platform. They did not let access to their bug report system and they commited changes in large patches. Yet Khtml is still alive. It has still a really small user share. It still run great. So Blink may force Apple to put more resources on WebKit development. Yet it is unlikely to really affect Safari. It also means more rendering engines which leads to better standard compliance: there is good compliance only since the spread of browser usershare.

jcollake
jcollake

Sometimes, this is what it takes to get something done with open source projects ;p. No, I don't completely buy that it was purely for technical reasons. I'm glad to see Google forking it, and believe it will result in superior code development; and probably more bugs too.

Editor's Picks