John Resig - WebKit is the jQuery of Browser Engines

The news has just come out that Opera is switching all of their browsers (both mobile and desktop) to use WebKit (specifically, Chromium). I’ve seen a lot of gnashing of teeth on Twitter and I feel like I can respond because I use to feel the same way back in 2008-2009. However this is 2013 and the Chrome/Chromium team has made it obvious that any form of stagnation or lack of innovation does not need to occur when using WebKit. In fact it possibly gives you the ability to accelerate your development, spending less time worrying about implementing common standards. I would argue that WebKit (a common framework for implementing the standards-compatible portion of a web browser) is exactly like jQuery (a common framework for implementing a DOM standards-compatible experience in a web page) at this point.

These are a few arguments against the switch that I’ve seen so far:

A browser switching to WebKit will result in stagnation

That is demonstrably not true. KDE created KHTML, Apple created WebKit based upon that, Google created WebKit/Chromium based upon that. I don’t think anyone can successfully argue that Chome/Chromium isn’t a better browser than Safari which isn’t a better browser than Konqueror. The Chrome team has proved that stagnation when using WebKit is merely a choice, as a contributor to WebKit you have the complete ability to drive it in a direction you wish (often for the better). I see no reason why the highly-skilled development team at Opera won’t be able to do the same. They can implement a number of their Opera-specific features into WebKit and it’s likely that those features will start to trickle back into other WebKit-using browsers as well.

This is helping to making WebKit a de facto standard, bugs-and-all

I don’t see this argument as being relevant any more, WebKit is already a de facto standard. I mean, everyone remembers when the browsers decided to implement -webkit vendor prefixes? It’s obvious that the “WebKit is an de facto standard” horse has already left the gate. As to the bugs: WebKit is a common code base that a number of browsers contribute to, however every browser vendor has the ability to make changes to their own fork of the code base. I see no reason why these “now-standard” WebKit bugs wouldn’t be fixed by any single vendor. Having a bug in the engine does not mean that a single browser vendor is incapable of fixing it — they would just be willfully not fixing it (as the browser vendors currently willfully clone -webkit prefixes).

In the case of JavaScript libraries virtually everyone has standardized upon jQuery at this point. This didn’t result in stagnation, which was a major concern, instead it’s resulted in a number of interesting and hyper-popular second-tier frameworks which build upon jQuery, such as: Twitter Bootstrap, HTML5 Boilerplate, and Backbone.js.

This will affect Opera’s ability to influence standards

I don’t see the switch to WebKit causing this. I do see Anne van Kesteren‘s move to Mozilla as being a massive blow to Opera’s ability to push standards though. I don’t know anything about the situation but if his moving was caused by the switch to WebKit then yes, Opera’s move to WebKit has affected their ability to influence standards.

Opera switching to WebKit is a slippery slope and/or Opera is a small player, Firefox or IE switching to WebKit would be a bigger problem

I think one this is clear already: WebKit has completely and unequivocally won mobile at this point. They are nearly the only rendering engine used on the vast majority of mobile browsers, including the soon-to-switch Opera Mini/Mobile browsers too. There is no reason to worry about a slippery slope, the slope has already been slid down. In order for any other browser to remain relevant in the world of mobile (which, you must admit, is quickly becoming the only world we live in) they must keep feature parity with WebKit. Let’s follow this to its logical conclusion: In a world in which WebKit is now virtually the only mobile browser vendor Mozilla and Microsoft will feel increased pressure to switch their browser engines over to WebKit in order to keep pace. Google has proved that with Chrome that WebKit stagnation is simply a choice so there’s no reason why these other companies shouldn’t be able to build off of WebKit (and possibly create WebKit hybrids, such as WebKit + IonMonkey).

The big question becomes: Should they switch?

At this point it’s honestly a business/engineering decision for Mozilla and Microsoft (as it always has been). If some percentage of your developer force is spending all of their time implementing the same standards that everyone else is implementing then switching to a common code base will give you the ability to free up some of your developers to work on something else. You saw what happened in the case of Chrome: They used their extra developer time to completely crush the competition on performance. This resulted in the everyone-wins race to become the fastest browser.

Ultimately it’s important to remember that WebKit is not a monolithic entity. It’s a shared codebase that a number of corporations contribute to. (In this respect it’s different from jQuery: Almost all contributions to jQuery comes back into the main codebase, whereas with WebKit some come back to the main codebase and some stay in a fork.) There is a lot of code sharing going on but it isn’t the be-all and end-all of browser development. Innovation can clearly still occur when working on a shared codebase and performance will almost certainly continue to improve.