Yesterday Google announced they were going to create a new rendering engine based on WebKit. The new engine will be named Blink and it is going to be an integral part of Chromium, their open source browser on which Chrome is based.

Why did they leave WebKit and how is this going to affect Safari and other browsers based on WebKit?

What is WebKit anyway?

Back in 2001 Apple needed a rendering engine for their own web browser. They chose the open-source KHTML and KJS projects and worked in secret to create a fork called WebCore and JavascriptCore. When Steve Jobs announced Safari on stage and told the crowd they chose KHTML almost everybody was surprised. Rumors suggested Apple was going to use Gecko. At the time KHTML hardly looked like a match for Gecko.

Apple made many changes to KHTML, improved standards support and made it faster. Much faster. Even though their forks were open-source, it was developed internally at Apple and once in a while they published a big code dump with all of their changes.
After the announcement there was initially some hope that Apple’s work on WebCore would eventually trickle down to KHTML. But this quickly became more and more difficult. As the two projects started to diverge, patches from WebCore became more and more difficult to integrate into KHTML. This is when people started accusing Apple of abusing the principles of open-source and not giving back to the community.

As a response Apple opened up the development of WebCore and JavascriptCore and released their newly created wrapper around the two: WebKit. The open-source WebKit project was born. Even though KHTML still exists today, WebKit has supplanted it completely.

WebKit grew very popular and it was ported to many other platforms, but Apple remained the main contributor.

Opening WebKit did have advantages for Apple, the help they got from the community improved WebKit. And the scale of the project made sure that web developers had to take WebKit into account when creating new websites. If Apple never opened WebKit, it probably would have been seen as a quant little engine that nobody had to take seriously. At least not until they released the iPhone.

But I’m sure they were also well aware that they were basically helping their direct competitors create better browsers. I can imagine they were not very pleased when Google based the Android browser on ‘their’ code.

One WebKit?

The growth of WebKit also meant that the WebKit code grew in size and complexity.

The biggest myth about WebKit is that it is a ‘single’ rendering engine. Sure, web developers can dream about only having to test on a single port. In reality each port adds its own platform dependent code and renders just a little bit different compared to its siblings.

Ports basically do not share the network stack, the graphics stack, video and audio codecs and many more smaller subsystems. Even when Apple decided to bring Safari to Windows, they did not reuse some of the already existing platform code for Windows, but instead completely ported their own network and graphic stack from OS X to Windows.

And what about Chromium?

When Google decided they needed to create their own browser, they based it on WebKit. Instead of creating a straightforward port, they created a wrapper around WebKit called Chromium. Although open-source, Chromium itself was never contributed to WebKit. Only the ‘glue’ that allows WebKit to plug into Chromium became part of WebKit.

One other important change was that Google did not use JavascriptCore, but instead wrote their own V8 engine. V8 did not replace JavascriptCore in WebKit, both were available and each port could now choose which engine they used. Apple never moved to V8 and instead kept improving JavascriptCore.

With Chromium, the dream of a single WebKit was completely shattered.

A fragile collaboration

Back in 2008 Apple and Google were still best friends. But even then I can imagine the original contributors were not too pleased when Google decided to completely change the architecture of WebKit and dump the result back into the project without any collaboration on the design. Kinda like how it felt for the KHTML project, I guess.

But Google was accepted and quickly supplanted Apple as the most active contributor on WebKit.

But any love between Google and Apple quickly cooled when Google started competing with the iPhone. Regardless of your own feelings about this, you can imagine that this didn’t help the collaboration between Apple and Google on the WebKit project.

This didn’t hurt WebKit much. WebKit became so popular that it almost completely replaced all other rendering engines on mobile. So popular that even Opera gave up on their own Presto engine and recently announced they were moving to Chromium and WebKit.

And so we have come to Blink

Yesterday Google announced that Chromium will use a new rendering engine. But besides the name, Blink is basically still WebKit. But not for long. Just like when WebKit forked KHTML, I expect the code bases will quickly diverge.

But first, why did Google fork WebKit?

When Google first created Chrome, the use of WebKit allowed it to quickly come of age. It didn’t have all the problems a new engine inherently runs into. But having to cooperate with others also caused problems, not only political problems. Also simply not being able to change things as quickly and as much as they wanted, because other ports were not ready for those changes. So what started out as an advantage grew to be a distraction.

While I am looking forward to seeing Google freed from the shackles of the WebKit project and being able to move the web forward, I also see a downside. Blink is open-source and will surely thrive and of course Google will welcome others. But they already had a broad collaboration using WebKit which they just walked away from.

I also doubt Blink will be as open as WebKit ever was. When Google decided to build a new JavaScript engine from scratch, it was accepted in WebKit and ports could make their own choice. I doubt we’ll ever see JavascriptCore back in Blink. The modularity of WebKit certainly has disadvantages, but it also has advantages.

What is Blink today and where will it go from here?

The first step is to take the code from WebKit and remove all platform dependent code that is used by any of the other ports, including JavascriptCore. That leaves us with only the code that is currently used by Chromium.

Just this first step will allow Google to focus and develop faster. And while Chromium and Blink are right now still separate, over time they will integrate up till a point where they can no longer be separated. This will make the browser faster and more secure, but at this point Blink and WebKit will have diverged so much that it is no longer easy to share new features.

Once again we can see the advantages, but it is also a disadvantage not being able to share features. Sure, Apple and Google together have enough manpower to support developing two separate engines. And Apple certainly has very capable developers. Many of the CSS3 features we now almost take for granted like animation, transforms, transitions and gradients were pioneered by Apple in WebKit. Google got those completely for free – well almost, apart from the Chromium specific code required to get it working. That will no longer be the case.

Another issue I am slightly worried about is how the other developers of WebKit will react. Who will move from WebKit to Blink? I can’t imagine Apple abandoning WebKit, but that will mean that they will have to invest far more resources into WebKit just to keep the same development pace. Will they? Sure they can also remove some of the code currently used by Chromium from the WebKit repository, but they still have a couple of dozen other ports cramping their style.

So will Apple also pull a Blink? Perhaps not, in the past Apple never seemed to be worried about moving forward with their own agenda. Even though Google was the largest contributor to WebKit, in many cases Apple seemed to act like it was their own private project.

Who will use Blink?

Given that Chromium will use Blink, all browsers based on Chromium will move to Blink automatically. That includes Google Chrome (of course), but also Opera who recently switched to Chromium for their upcoming versions. And many more, like Maxthon, CoolNovo and Yandex, simply because they all based their browser on Chromium and when they update their code base, they will get a version of Chromium that uses Blink.
I am curious if Opera knew about the plans for Blink when they announced their move to WebKit. Did they choose for Chromium because it used WebKit, or because it was Chromium? Probably the latter. I doubt they are now being held ‘hostage’.

Even if we set aside any political issues, for browsers that currently use WebKit and are not based on Chromium, moving to Blink will not be trivial. Browsers cannot simply switch from WebKit to Blink, only from WebKit to Chromium.

First of all, a browser based on WebKit talks to the rendering engine through the WebKit API. If a browser moves to Chromium, they will have to rewrite their browser to use the Chromium Content Layer API instead. Secondly, they have to abandon their own platform code created for WebKit and probably completely write new platform code that fits into Chromium. This will probably still be easier than writing platform code for WebKit, because many issues that a developer has to solve on its own in WebKit are already included in Chromium by default. But moving to Chromium is still not trivial.

I am sure all users of WebKit will closely follow Blink and the first to move will probably do so because of a political decision. Right now it’s still a matter of who you trust most: Apple or Google.

And what about Android?

But there is one user of WebKit that I am particularly interested in: the Android WebView. Even though Google has been pushing for Chrome to take the place of the default browser, there are many, many applications that embed the Android WebView, which is still based on plain WebKit.

Changing to Chromium might not even be possible, because it could create incompatibilities that might potentially break apps. Something that Google will try to avoid. So, will Google keep using plain WebKit for Android? Or will Android 5 include a Chrome WebView as a replacement? Or maybe both: the current WebView for older apps and the new Chrome WebView for ‘Android 5 only’ apps. There have been many rumors in the past hinting about WebView moving to Chromium. Given the standards support of the default WebView this is certainly a welcome change.

Update: Google just published this this video and Chrome WebView is definitely coming. When and if it is going to replace the old WebView is still unknown.

Interesting times ahead!

And no @ppk, text-decoration: blink is still just as evil as it ever was.