By Craig Buckler

Blink: Chrome’s New Rendering Engine

By Craig Buckler

In a surprise statement released last week Google announced that Chrome and Chromium are to adopt a new rendering engine named ‘Blink’. Blink is a fork of Webkit introduced because:

  • Chrome uses a different multi-process architecture to other Webkit browsers
  • It provides Google with further performance improvement opportunities.

Google stated:

Blink’s mission is to improve the open web through technical innovation and good citizenship.

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.

All very noble. But was Google’s decision politically motivated? Webkit is open source; there are no technical reasons why Google couldn’t implement improvements. However, Webkit is largely controlled by Apple — a competitor. At best, Safari would have the same technologies. At worst, Apple could block features which offered Google a competitive advantage (such as Dart).

Regardless of the reasons, Blink is good for the web.

Webkit has never been a single rendering engine so another fork will have little immediate impact. Over time, Blink will proceed along a different path unencumbered by Webkit stakeholders. The engine will be one of Google’s top priorities and should evolve rapidly.

Blink will appear in Chrome 28 and also be adopted by other browsers based on Chromium — including the new version of Opera and RockMelt. We may have lost Presto, but Blink goes some way to redress the balance. The web has four major rendering engines once more — even if two will be mostly identical for a few months.

Will There be a New Vendor Prefix?

No. Blink will continue to support some -webkit prefixes for legacy compatibility but all prefixes will eventually disappear. Experimental DOM, CSS and JavaScript features will be available without a prefix but the developer must enable those facilities with a single setting in about:flags.

I’m not wholly convinced it’s a major improvement. Unless other vendors embrace the policy, developers will have the same number of prefixes to manage and remember (or forget).

Other Downsides?

Apple has most to lose. Webkit’s development team has been cut by 50% and the engine has just lost almost 40% market share. The web is everything to Google but a distraction for Apple; Safari could fall behind other browsers.

Testing has also become a little more difficult for web developers. While you could never rely on Chrome-compatible code working in Safari, differences were rare. That’s no longer the case.

The situation was complicated further when Apple dropped Safari on Windows. Windows developers must either buy a Mac, hope other Webkit browsers are close (Dooble, QupZilla, SlimBoat) or rely on Apple providing test facilities like Microsoft did for OS X users.

Finally, while Blink is technically open source, it’s Google’s baby. Chrome’s dominance means Google can change Blink in ways that were not possible before. The company could be dictating web standards before we know it — especially if they enable non-prefixed features which operate differently in other browsers.

Despite the pitfalls, Blink seems an appropriate name — the web’s future just became a little brighter.

Unless you think otherwise?…

  • Tim

    Why is it called “forking”. Every site I have read says Google is forking Webkit, but they never explain what forking means.

    • Yuppy Soul

      It’s like a fork in the road. You take something that exists now (like webkit) and you fork it off in a different direction from Webkit.

      Like happened what with OpenOffice and Libre Office. They started the same but forked in different directions.

    • Tuomas

      Surely it refers to the fact that Blink is based on WebKit. Right now, they don’t differ that much, but eventually will drift apart more and more.

      Oh, and great article by the way, couldn’t agree more. Will be interesting to see what Google cooks up, Chrome already lead the way for a good time now!

    • Adam

      I think that it is another example of needlessly converting a noun into a verb when another word better explains the concept. I am not sure what this process of derivation has to do with forks, other than perhaps being reminiscent of a fork in a road.

    • James

      Tim, forking is just a term for taking a copy of some existing code and developing it in a slightly different direction. The original project lives on but you are trying a different route . The history of the code now follows a forked path. It might as well be called “branching” if that makes more sense for you.

      Over time these two may themselves fork again and/or end up very far apart. Equally, they may both end up covering similar territory and re-merge.

    • It’s like a fork in the road.

      Forking is when you come to a point where you veer away from working on the original contribution (WebKit), and start working on something completely different and submit those changes to the fork (Blink), as opposed to the original. Earlier in the process, the vast majority of the codebase is the same, but as you commit more and more changes to the fork, it starts to take on a life of its own and you can pretty much see how you have now two distinct platforms stemming from one origin. You’d do this if you have special needs for the software that the contribution isn’t really roadmapped to support what you need, but redundancy of work should be avoided, meaning you should contribute to the original codebase before starting a fork, otherwise the fork and the origin may tackle the same problems and the effort to do the same thing twice could have been put towards fixing other issues.

    • Ben

      “Fork”-ing like a fork in the road; the old code will go in one direction, and the forked code will go in another direction. The longer they each stay on separate “roads”, the further “apart” they wil become.

    • Apologies Tim and thanks to everyone answering. ‘Fork’ is a term regularly used by developers; it’s easy to forget that it’s not used in every day conversation by normal people!

      • John Dablin

        I always thought ‘fork’ came from the Unix fork(2) system call. From the manual page of it’s descendent, Ubuntu Linux: “fork() creates a new process by duplicating the calling process. The new process, referred to as the child, is an exact duplicate of the calling process, referred to as the parent, except for the following points…”

        In other words, the new process starts off identical to its parent, but then goes off on its merry way.

  • Blink is a bizarre name. Firstly, because of the much despised tag that it reminds us of and secondly the idea seems like it describes something momentary and transient rather than something which is going to stick around for a while.

    I wonder what made them choose the name?

    • Blink evokes speed in my mind, like “Loading in the time it takes to…”. I think it’s a pretty dope moniker, actually.

      If they named in Marquee, I’d agree with you a bit more, lol.

  • Petit Paul

    While Chrome was available on the iOS because it was Webkit based, what will happen to the app when its rendering engine will no longer be Webkit? Most likely, Apple will not allow it anymore. Like Firefox or IE. What do you think?

    • You’re right but Chrome on iOS is a Safari skin now — it doesn’t use Chrome’s version of Webkit because Apple won’t allow that. The app could continue in its current form but I can’t see Google investing much effort in something they can’t change.

      This could come back to bite Apple if they’re unable to keep a reasonable pace of development. Safari updates are already relatively slow compared with Chrome.

  • DaveMaxwell

    Forking is a version control term. Basically what it means is taking the baseine code at a specific point in time and start developing it independently. It’s usually used when a team of developers are going to make a major revision to a code base, while the code base has to be supported for the current customers.

    It’s an old play on the concept of forks in the road – the road breaks off at some point, but eventually comes back to the main road.

    The ironic part of the term is Forking implies that at some point, it’s going to be brought back into the main code base. With Google taking their toys and going to play on their own, that fork will never go back to the code base.

  • Alexandre

    Spooning leads to forking

  • If you read the WebKit breakdown by Paul Irish: the fork of WebKit means that Chrome will no longer use the same version of Webcore – the only component it shared with Safari.

    It is absurd to suggest that Chrome will start dictating standards because they are using a modified HTML renderer in their browser.

    By forking WebKit both Google and Apple should be able to reduce their codebase and the separate teams should be able to make commits without worrying that they are going break something. Hopefully it will mean faster releases.

    Also, a fork does not imply that it will be later merged. WebKit was a fork of KHTML. Ubuntu is a fork of Debian. A fork is often a starting point for a separate entity.

    • With regard to dictating standards, Google has the biggest web presence and most-used browser. It’s a powerful position.

      Let’s say Microsoft and Mozilla implement a new feature in IE10 and Firefox (~25% of used browsers) which becomes a W3C standard. Google don’t like the feature so they either ignore the technology or implement it differently in Chrome (~40%). Either way, that feature is now unusable.

      I would hope Google never indulge in such tactics, but it was less likely to occur in the Apple/Webkit days. There’s nothing to prevent them now…

  • Angyork

    Getting ready to add -blink to all css hehehehe

  • Patrick

    Blink? Could it have anything to do with Google Glass?


Get the latest in Front-end, once a week, for free.