Stephen Smith's Blog

All things Sage 300…

Google Forks WebKit

with one comment


WebKit is the underlying HTML rendering library used primarily by the Apple Safari and Google Chrome browsers. It is used in a lot of other projects like the Blackberry Browser, Opera, Tizen, Kindle and even some Microsoft e-mail clients. Even Nokia was a big WebKit user before switching to Windows Phone. Generally it’s been considered a great success, rallying the web around standards and making life easier for web developers.


WebKit is a solid open source project with lots of support. This is one reason it’s so successful. Currently in Internet browsers there are three main HTML rendering engines: the Internet Explorer Trident engine, the Mozilla Firefox Gecko engine and then WebKit.

The big news around the Internet on this front recently is that Google is forking WebKit (meaning starting a new open source project based on WebKit) and then taking it in its own direction with a project called Blink. This raises all sorts of questions: like what it means to web developers? What is Google’s real agenda? Will this damage web standards? Will this slow WebKit development? In this blog posting I want to give my perspective on a few of these questions.


Actually WebKit was started out of a similar controversy. Back in 2001, Apple forked the KHTML/KJS HTML rendering engine used by the browser that is part of the KDE Linux User Interface system. Basically Apple wanted something better and more tuned for its OS X project. The result was the Safari browser built on the first WebKit HTML engine. At the time no one in the Linux community was happy about this, but in the end looking back, success makes everything all right.

So now that Google is forking WebKit, claiming that it’s for the same reasons that Apple forked KHTML, will history repeat itself and a much better HTML rendering engine will emerge? Or will this just fragment the market into more slightly different HTML rendering engines making life more difficult for web developers?

WebKit’s Mobile Success

In recent years, now that Android and the iPhone have completely taken over the mobile phone market, developing web sites with HTML5 and JavaScript has become much easier. This is because WebKit is used in both of these families of devices. This means to cover 95% of the mobile market you just need to target WebKit. This greatly simplifies development and testing. Further WebKit follows web standards diligently, it keeps up with evolving standards, has great performance and great quality.

I think that WebKit has been a major contributor to the combined success of both Android and the iPhone. You can easily browse most websites from these devices. Plus when Apps incorporate browser controls they are using WebKit.

Further both Apple and Google are contributing actively to WebKit. It’s been an interesting combination of co-operation and competition. When new hardware devices come out, initially it tends only be accessible for Apps. But Google tends to very quickly add JavaScript APIs for the device to WebKit. Then Apple tends to follow suite quite quickly. Further each is driven to keep incorporating the latest version into their devices since they don’t want to let the other get ahead of them.

One of the worries of Google forking WebKit and going its own way is that we will lose the competitive nature of Apple versus Google that has been driving WebKit forwards.

Why Fork?

So why is Google forking WebKit? A lot of opinion on the Internet is that this is a strategy to sabotage Apple. I guess Google could be egomaniacal enough to think that WebKit will fail without them participating. But Apple is such a big company with so much money and talent, I think they can do just fine with WebKit, after all they did start it without Google’s help. Further I suspect the army of independent open source programmers that contribute to WebKit will continue to do so and won’t switch to Blink.

Google’s official reason is that the code in WebKit is getting too burdened with supporting code for Safari, Chrome and all the other various things it does. That if they take WebKit and remove anything that Chrome doesn’t use then they will have a smaller, faster and easier to develop code base. Basically they claim they want to move the HTML engine forwards more tightly coupled with their multi-processor architecture to improve security and performance. That doing this while supporting competing architectures within the same code base is getting harder and harder.

When Apple started WebKit and later when Google joined it, both Google and Apple were primarily worried about Microsoft and wanted to have Browser technology clearly superior to Internet Explorer. Now with their success, Microsoft is now pretty well non-existent in the mobile world. I think as a result Google isn’t feeling threatened by Microsoft anymore and is turning its attention to Apple. Generally relations between the two companies have been getting colder and colder in recent years.

Actually Google currently only uses the HTML and CSS rendering part of WebKit called WebKitCore. They stopped using the JavaScript component JavaScriptCore in favor of their own V8 JavaScript engine. The V8 JavaScript engine has been blowing away the competition in JavaScript benchmarks for some time now. In fact the V8 JavaScript engine is also the heart of Node.js the highly successful JavaScript server side processing framework. I think Google is looking to get the same sort of success out of Blink that they got from V8.

What’s the Problem?

The problem is for developers. Right now developing good web pages that run nicely anywhere means targeting IE, FireFox and WebKit which then covers the main HTML/CSS rendering engines. Unfortunately HTML and CSS are very complicated and quite subtle. Although all adhere to the published web standards, there are differences in interpretation. Also there are emergent properties that get exploited as features, things that aren’t really in the standard but have appeared in an implementation.

In the mobile world right now, developers have it easier since they can target Android, iOS, Blackberry, Tizen and Symbian by just targeting WebKit. This makes life much easier since you really can develop once and deploy pretty much anywhere. It will be a pity to lose this, and potentially quite expensive for smaller development organizations.

I imagine that many source code files will continue to be shared by WebKit and Blink. But for how long? When will we have to pay attention between differences between Blink based browsers and WebKit based browsers?


Although I find it appealing that Google is hoping to do for HTML/CSS rendering speed what it did for JavaScript execution speed with V8, I’m really worried that this is going to fragment HTML5 development for mobile devices. I tend to think this will cause more web developers to decide that if I need to develop Android and iOS separately then I may as well do both natively in Apps. To me this will be a sad further fragmentation and polarization of mobile developer communities.

Written by smist08

April 13, 2013 at 3:40 pm

One Response

Subscribe to comments with RSS.

  1. […] Introduction WebKit is the underlying HTML rendering library used primarily by the Apple Safari and Google Chrome browsers. It is used in a lot of other projects like the Blackberry Browser, Opera,…  […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: