What does WebKit actually mean?

WebKit is an open source web browser engine. WebKit is also the name of the Mac OS X system framework version of the engine that’s used by Safari, Dashboard, Mail, and many other OS X applications. WebKit’s HTML and JavaScript code began as a branch of the KHTML and KJS libraries from KDE.

Which basically means that WebKit is the browser engine behind Safari, which we already knew. In addition, Apple uses the Nitro JavaScript engine within Safari alongside WebKit.

What’s interesting about WebKit is that it now stretches way beyond Apple. WebKit is also at the core of Google Chrome:

Chromium uses the WebKit rendering engine. Instead of building Chromium-specific implementations, we prefer to contribute as much code as possible upstream to improve all WebKit-based browsers.

So this means Chrome uses the Nitro engine? No. Chrome has its own JavaScript engine called V8). In short, it uses WebKit but it also has it’s own implementation for JavaScript execution. V8 is also the JavaScript engine that powers Node.js.

Opera will be using the Chromium implementation of WebKit, as well as the V8 engine. This means that while Opera is using the ‘WebKit’ name, it’s not in fact using the same bits and pieces that make up some other WebKit browsers like Safari. This is an important concept to grasp if you want to be objective about the current situation.

How many forks of WebKit exist today?

So we already know that WebKit powers, or will be powering 3 of the popular browsers out there today. But how many other implementations of WebKit exist?

How do the various WebKit forks differ?

There is often an assumption that because these browsers all share the same ‘WebKit’ name they will all support the same features, and support them in the same way. Although this is true for many basic features, this is often untrue for the newer, more niche features.

For example, while the Gamepad API has landed in Chrome, it is yet to and unlikely to ever land in Safari. Another example is WebGL, a technology that has long been in Chrome but has only just started to see the light of day within Safari (still behind a developer preference). Of course, these are larger, more experimental examples but the underlying point remains.

How do new features get into WebKit, and who has to vet them?

The WebKit commit and review page mentions that new committers and reviewers to the core can only be nominated by existing reviewers and commiters. This makes sense. However, whatever the existing members of WebKit decide, it is still down the Apple to make it happen:

Once someone is successfully nominated for WebKit Committer status, Apple will take care of sending the committer agreement and setting up a Subversion account once signed and received.

There is no ulterior motive with this, but it does highlight that WebKit, like a lot of open-source projects, isn’t truly distributed and democratic. Power is and has to be centralised and unified so things can actually get done and so decisions can actually get made.

If a browser moves to WebKit, does that mean there is one less browser to test on?

No. Each browser will still have its own quirks, performance differences, design, and functionality. These should all be tested for.

Does a feature getting into WebKit actually mean that it’ll be used by other browser?

Arguably not, for example the Gamepad API. Paul Irish highlighted the fact that WebKit browsers can pick and choose which APIs they put in their build:

What does Opera moving to WebKit actually mean?

The shift to WebKit means more of our resources can be dedicated to developing new features and the user-friendly solutions.”

It also means that they won’t continue to develop their own web rendering engine Presto.

The same source & diversity

What above questions and answers teaches us, it’s clear that WebKit comes from the same source. It’s available in a multitude of versions, but at the end of the day it’s the same base.

This means that you can have optimized WebKit builds for mobile, for performance, for whatever other purpose you can think of. It’s a good thing, and it definitely leads to various implementations and more input on how to fix things, and in the best of worlds, all this progress gets fed back and everyone gains from it.

There are a lot of major interests behind it, and that’s why we believe it’s just as important to have rendering engines that come from a completely different place, run by other people and interests in addition to that.

When Apple started with WebKit, based on KHTML, it was a good thing. They could have done it based on Gecko, but they did something new, added diversity and was part of leading to the enormous improvements we’ve seen in the web browser space in the last few years – a direct result of the open competition.

If they had “just” done another version of Gecko, for instance, we’re not sure we would be where we are today.

Not the same rendering

Putting WebKit aside for a moment, what is it about all browsers using the same engine that appeals to developers? Will a move like this actually achieve that? Does it equal a better Web? Is it easier for developers?

Developers will test in fewer web browsers, assuming they’re all the same since they are WebKit-based

Developers will test less in other web browser engines

Developers will use rendering engine-specific code more, instead of focusing on web standards

The most probable outcome is that developers will choose to – or be led to – believe that it will be easier, but over time, they will realize that WebKit can mean many different things.

Where does this leave IE and Firefox?

Let’s take a sober look what this means for Microsoft and Mozilla. There are being voices raised that they should implement WebKit in Internet Explorer and Firefox.

But is it really that easy? All major players and their products would then come from the same source – but in different variations, forks, add-ons and more – and to us, that doesn’t seem to be the optimal way to reach true diversity.

And what if IE and Firefox don’t switch rendering engines? This competition might be amazing and lead to a bright future. But it could also lead to a very hard fight for Microsoft and Mozilla to compete on all levels of standards support, performance and much more.

Diminishing market share and complete WebKit dominance? Or that people will use IE and Firefox, just as to not use WebKit?

Is there a risk of Firefox and IE becoming obsolete over the coming years? Or will they be the differentiating factor?

What’s the incentive for a web browser vendor?

Beside the fact of there being many WebKit versions out there, you have a lot of web browsers out there trying to compete, trying to be unique. Some believe that a lot of that competition will be in the UX field. It will be, but far from only there.

As touched on in Tragedy of the WebKit Commons, who will be interested in spending their money and resources to, basically, fix bugs for competing web browser vendors?

It seems far more likely that most efforts will go into new features, shiny stuff, that will make them stand out against their competitors.

And on that topic, how will you detect that? Feature detection to some extent, sure, but then what? And with CSS, what will a -webkit imply? Nothing really, more than it could be any web browser in the world but IE or Firefox.

So what’s the next step then? Even more vendor prefixes?

WebKit is good

Allow us to emphasize that WebKit is good. It has an open process and great contributors. We just want to shed some light on the apparent misconceptions that one WebKit = all WebKit, and the belief that if everyone uses WebKit, it will be easier for developers.

WebKit will be great for some things, just as the diversity of having multiple completely independent web rendering engines are.

54 Comments

Excellent post Robert. I don’t suscribe to the hysteria on either side of this issue, but I generally think that Opera moving to webkit as a ‘good thing’, especially for them. Opera was a pain to develop for, and that made it some what irrelevant.

[…] WebKit is an open source web browser engine. WebKit is also the name of the Mac OS X system framework version of the engine that’s used by Safari, Dashboard, Mail, and many other OS X applications. WebKit’s HTML and JavaScript code began as a branch of the KHTML and KJS libraries from KDE. (more here) […]

Do you think this will make it harder to standardize, if there is one fewer browser implementer? For example the Web SQL database stalled because all implementors used the same backend: http://www.w3.org/TR/webdatabase/

[…] WebKit: An Objective View — the post covers the most common issues concerning WebKit rendering engine as well as the possible outcomes of its total use by top web browsers for both software retailers and programmers. […]

Excellent post as always.
I remember that there were rumors for a long time saying that Opera wanted to replace Presto with Webkit. Now that this is official, I feel really sad because this could slow down innovation.

Presto is a very nice engine which I don’t think is inferior compared to Webkit, Gecko, or Trident. The real problem was not Opera’s fault, it was the lazy developer or designer that avoiding to add another line of code with the “-o” prefix (and sometimes even avoiding the properties without prefixes at all), has killed an excellent engine.

I thought that we were over the “This website is optimized for Blah browser” time; however, I can see in the near future the same thing happening. “Optimized for a Webkit browser.”

Much like Safari, the Camera app, the App Store and i – Pod, Game Center has no
option to be deleted when editing your apps. The only downside
of it in a lot of people’s eyes is the fact that there is no multiplayer content. t love the unself-conscious little boy or girl, the undaunted miniature explorer who moves with unbridled enthusiasm to experience life.