HTML5 Development Center

Developed for you in part by
 
518-chrome-11

Blink: Chrome’s New Rendering Engine

By | April 8, 2013 | Browsers | HTML5 | News | Open source | Web standards

19

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?…

Craig Buckler

Craig is a Director of OptimalWorks, a UK consultancy dedicated to building award-winning websites implementing standards, accessibility, SEO, and best-practice techniques.

More Posts - Website

Tagged as: apple, chrome, Google Tutorials & Articles, HTML5 Dev Center, webkit

{ 19 comments }

Patrick April 11, 2013 at 9:00 am

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

Blink.

Angyork April 8, 2013 at 11:14 pm

Getting ready to add -blink to all css hehehehe

James Robinson April 8, 2013 at 5:54 pm

If you read the WebKit breakdown by Paul Irish: http://paulirish.com/2013/webkit-for-developers/ 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.

Craig Buckler April 8, 2013 at 11:38 pm

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…

Alexandre April 8, 2013 at 3:20 pm

Spooning leads to forking

DaveMaxwell April 8, 2013 at 12:08 pm

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.

Petit Paul April 8, 2013 at 10:07 am

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?

Craig Buckler April 8, 2013 at 11:27 pm

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.

Tom B April 8, 2013 at 9:03 am

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?

Blake Petersen April 8, 2013 at 12:51 pm

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.

Tim April 8, 2013 at 8:53 am

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

Yuppy Soul April 8, 2013 at 9:34 am

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 April 8, 2013 at 9:42 am

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 April 8, 2013 at 10:06 am

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 April 8, 2013 at 12:52 pm

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.

Blake Petersen April 8, 2013 at 1:02 pm

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 April 8, 2013 at 2:11 pm

“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.

Craig Buckler April 8, 2013 at 11:29 pm

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 April 9, 2013 at 3:19 pm

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.

Comments on this entry are closed.