The Pros And Cons Of A WebKit Monoculture

The news that Opera is shutting down the development of its own browser rendering engine and moving to the open source WebKit engine caused quite a stir earlier this week. With WebKit powering the built-in browsers of Google’s Android and Apple’s iOS, it’s already the de-facto standard engine for mobile and it has the potential to do the same on the desktop. Worldwide, Chrome now holds a considerable lead over Microsoft’s Trident-powered Internet Explorer and Mozilla’s Gecko for Firefox already. The question is: are we better off because we have competing engines trying to outdo each other, or would we be better off if all the browser vendors just standardized on WebKit?

As an open source project, WebKit allows all the vendors to contribute and the combined efforts of Google, Apple, Mozilla, Microsoft, Opera and everybody else in the browser ecosystem who may want to contribute could quickly push the web forward. Those in favor of this kind of consolidation on one rendering engine also argue that this wold make life for developers considerably easier, given that they won’t have to work around the quirks of all the competing engines we have today.

As numerous commenters on this Hacker News thread point out, as long as we can trust those in charge of WebKit development to work together to innovate, an all-WebKit web would be a boon for developers and users.

The most vocal opposition to this kind of monoculture has come from Mozilla, which is obviously heavily invested in its own Gecko engine and Servo, its forthcoming successor. Mozilla CTO Brendan Eich argues that monoculture is a problem Mozilla must fight because of its mission. Adding to this, Mozilla engineer Steve Fink argued that an all-WebKit web – both on mobile and desktop – would prevent innovation and lead to a small number of companies controlling the web as a platform and just lead to added complexity and confusion in the long run.

Given that WebKit is an open source project, though, it could easily be forked if development stalled or one of the stakeholders started to block important changes for political reasons.

From Google's Chrome Launch Comic Book

From Google’s Chrome Launch Comic Book

On the Web, of course, we went through a period of stagnation thanks the total dominance of Microsoft’s Internet Explorer during the days of IE5 and IE6 (and the demise of Netscape and the 5-year lag between the launch of IE6 in 2001 and IE7 in 2006). On the other hand, the arrival of competition from Firefox starting around 2004 and Google’s WebKit-based Chrome in 2008 – with the stated mission to push the development of web standards, rendering engines and especially JavaScript performance forward – undoubtedly helped to turn the web into the powerful platform we are now used to.

Web vs. Apps

Even Opera, in its own announcement, argued that “monoculture is bad,” but then also added a somewhat defeatist note to this, saying that it “was never really in a position to prevent it in the first place,” because despite its considerable market share on mobile, “web developers still designed just for WebKit.”

The interesting twist in Opera’s argument, however, is that the real competition isn’t between browsers and rendering engines. Instead, it’s about the web competing with native apps. Opera’s move, the company argues, is more about the fully open web competing with “the closed world of ‘apps'” and switching to WebKit allows it to counter this more effectively.

Developers Care, But What About Users?

Ideally, of course, all the different vendors would just implement the same standard to the same specs and developers wouldn’t have to worry about which rendering engine will display their code. It would always look the same. Sadly, that’s obviously not what happens given that every implementation has its own quirks.

Most users obviously also don’t care about how exactly a given site or web app is rendered. To them, a browser is basically the chrome around the rendering engines. That’s where the features live that users care about (bookmarking, plugins, tabs etc.). Those are also the features that get users to switch (assuming speed remains comparable).

Mozilla argues that the best way to push those features forward is to control the browser stack from top to bottom. The WebKit-only proponents argue that Mozilla and Co. could just focus on bringing the best features to their users if they only let go of this notion.

Personally, I think having a few competing engines that all implement the same standard will lead to a faster innovation cycle. The web is still in a phase where that is more important than consolidating on a single engine. This involves extra work and may even break things at times, but it’s worth the effort in the long run.