What the hell is WebKit anyway? An all-purpose guide

Additional reporting by Rob Hawkes

When Opera announced that it would be moving its various browsers over to WebKit, the global tech press seemed to rejoice without really knowing what it meant. We would like to, in a factual manner, break down what the possible outcomes of having a majority of web browsers based on WebKit are, for web browser vendors and developers alike.

Let’s start with some common questions:

• What does WebKit actually mean?
• The term ‘WebKit’ has been thrown around a lot recently – for good reason – but what is it exactly?

Officially:

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 three of the popular browsers out there today. But how many other implementations of WebKit exist?

It turns out that there are many, many variations of WebKit, and particularly on mobile. There are likely many more forks of WebKit then there are of any other browser.

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.

Even more basic, everyday functionality differs between forks – PPK highlights a whole range of these kinds of WebKit differences.

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

There are a large number of companies contributing to WebKit.

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

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:

@keithamus @robhawkes so take Gamepad. Most of the impl is at the WebKit level but trac.webkit.org/wiki/FeatureFl… allow Safari to disable

— Paul Irish (@paul_irish) February 13, 2013

What if other WebKit browsers want to implement their own version or changes to a feature?

For example, how would today’s WebRTC situation with Microsoft play out if we all used WebKit? Would we need browser-specific prefixes, like webkit-ieWebRTC() and webkit-chromeWebRTC()?

What does Opera moving to WebKit actually mean?

It means that Opera will put some engineering focus into WebKit, but most likely, shift a good bit into building other features specifically for Opera:

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

The biggest risks with developers believing it’s “the same” rendering engine are:

• 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. Some think 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.

---

This article by Robert Nyman originally appeared on Roberts talk and is republished with permission.