Thoughts on Blink, Google’s new rendering engine

Yesterday, Google announced that they’re moving from the WebKit rendering engine to their own, named Blink, for Chromium (and thus all Google products based on WebKit).

What is Blink?

Blink is a rendering engine based on WebKit. For now, it will be very similar to what WebKit is, but as it develops over time, I’m sure we will see a number of differences.

One good thing to notice – as outlined in their Developer FAQ on Blink – is that they won’t be adding any new prefixes, like -blink-border-radius etc.

Instead, they’ve chosen the same approach as Mozilla, to instead have developers enable new experimental features in about:flags in Google Chrome. They will, however, support already implemented -webkit prefixes.

What it means

It means we’re getting a new rendering engine, thus contributing to the needed diversity I talked about in The WebKit culture & web rendering engine diversity.

It’s a fairly logical move to me, and as Rob Hawkes and I outlined in WebKit: An Objective View, WebKit and the options and differences are much bigger than most people seem to think.

Google is a business. They aim to be as streamlined and flexible as possible, and this is their way of doing that. I don’t have a problem with that, and I hope it leads to more healthy competition in the web browser rendering engine space.

It also means that all those people saying that WebKit was good for everything when Opera switched to it, defending it as the only rendering engine that mattered were, well, not entirely correct…

I also hope, and believe, there will be less voices suggesting that Internet Explorer and Firefox switch to WebKit as well, and understand that different companies have differences approaches.

Finally, it will change the mindset of many web developers who have put an equal sign between WebKit and Web, and especially the mobile web as that. This is good.

WebKit != Web != Mobile Web

but rather

[All rendering engines] == Web == Mobile Web

What does this mean for WebKit’s future?

I think this is by far the most interesting implication.

It’s a big shift for WebKit development, with Google currently having the top number of reviewers. That Apple will need to evaluate their role in WebKit, and what time and efforts they will put in, or any potential changes to make.

I also wonder if the result could be that Safari will fall behind other web browsers with far less contributors?

I think, long-term, it will definitely affect iOS and the web browsing experience in general, and I also wonder if other parties using WebKit now will consider Blink. And where contributor loyalty will be.

The web is indeed an exciting sector to be in!


  • I agree it will make the competition in the web space more healthy. Its probably mainly bad news for Apple and Opera as it seems like Google has been driving the innovation for them.

  • James Brooks says:

    Bruce Lawson has already stated that Opera will be using Blink, here, so it’s good news for Opera already.

    Still, Apple will lose out from this, but web developers will hopefully gain!

  • Todd Bloom says:

    I don’t understand how flags are better than prefixes? If experimental features have to be enabled per browser, then the use of these newer features will get even less use.

    I mean, are you going to slap a big banner on your page telling a visitor that “you’re sorry but to view this site you need to access this developer screen in your browser and enable these features”?

    Prefixes are a pain, sure, but at least you can handle everything in a CSS file rather than hoping that each visitor has them turned on.

  • I also hope, and believe, there will be less voices suggesting that Internet Explorer and Firefox switch to WebKit as well

    They will change their tune… to Blink. :-\

  • Robert Nyman says:


    Yep, mainly I’d say it’s bad for Apple.


    Not sure it’s good news for Opera, though. I believe they did the WebKit move partly for the reason to get a strong presence on iOS. That’s not an option with this.


    The idea with prefixed CSS features aren’t to use them in production, though, but experimental for testing. Basically, for developers.


    Nah, not the same approach. Before the reasoning was that EVERYONE used WebKit, and as we can see, that is changing as we speak.

  • njn says:

    And Apple is removing V8 from WebKit.

  • Robert Nyman says:


    Right. Things change.

  • Alex Voda says:

    I think this will force Apple to start releasing Safari for Windows again.
    Unless they want Windows using web developers to stop testing on webkit.

  • Robert Nyman says:


    It might very well happen. Or Windows might be excluded, not seen as a necessary/too much of a hassle to support. Future is interesting, indeed!

  • Magnus Fedec says:

    There I was thinking that WebKit was about to take over the world wide web… of browsers. I welcome this change – as long as future web technologies, specifically HTML and CSS are implemented consistently with other rendering engines 🙂

  • Robert Nyman says:


    Well, as consistent as possible. 🙂
    The benefit of a number of implementations is to see what seems right from a specification point of view, from actual implementation perspective and end user experience.

    I believe that through that we can get the best implementations, instead of one de facto one (that might be wrong).

  • A. I. Sajib says:

    I have this feeling that after ditching WebKit and going to blink, the Chrome’s performance has become slightly sluggish. It may be just me on Windows 8, but some of my friends from Windows 7 reports the same, too.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.