Wednesday, February 13, 2013

Opera knows the power of the Dark Side of the WebKit Force

Opera announced today that their custom HTML/CSS rendering engine, Presto, will be decommissioned in place of WebKit (specifically, it will use code from Google Chrome's open source version Chromium, including presumably V8, its benchmark-obsessed JavaScript compiler). Essentially this turns Opera into little more than a Chrome shell, and liberates the company from the significant development resources they had to invest in Presto/Carakan's maintenance.

I have ranted multiple times in E-mail, here and elsewhere about the danger an unchecked WebKit de facto monopoly holds for the Web. We damned Internet Explorer when it crushed Netscape, and in a few years we will damn WebKit in the same way. Already WebKit, based on its tremendous installed base on iOS and Android, is the uncontested dominant rendering platform on mobile, and while Opera represented only a fraction of the desktop browsing market, it was a large player in mobile and feature handsets which will now be ceded to WebKit in effect. More importantly, it represented another way to render HTML 5 that kept developers honest instead of "developing for WebKit." Now all that's left, other than very tiny specialized engines like Dillo and NetSurf, is Trident (IE), Gecko, and the swelling juggernaut of WebKit largely due to Google Chrome, Safari and a host of other minor shell browsers like Midori, OmniWeb, possibly the future Camino (if it even makes it to 3.0) and now Opera itself.

Every so often I get questions about why I bother with a Firefox port "when Google Chrome would work so much better." Besides the fact I dispute the premise, and that Google Chrome or Chromium has never run on a big-endian platform, let alone PowerPC, the answer simply comes down to trust. The Mozilla Foundation is non-profit, community-invested and dedicated to open standards and the Web; they have no interest in lock-in, only to act as a standards-compliant supported option. Mozilla is kept honest because of its competition and its high level of user and volunteer commitment, including yours truly. While WebKit is open source, allowing people like Tobias to maintain Leopard WebKit, it is still largely controlled by Apple and Google because they have the largest financial and practical interest in it (not to mention their proprietary browsers based on it) and its gatekeepers and reviewers are Apple and Google staff. Their browsers are revenue generators, and while WebKit is important to Apple from the context of iTunes and the App Store interface (remember that Safari is only the browser manifestation), Chrome is unapologetically Google's effort to optimize their user experience. It is less important to them what happens to the rest of the Web than that their users have a good experience (and preferably the superior experience) with Chrome on their services (preferably their pay services), and it has already been demonstrated that it is also less important to them the user experience of their services on other browsers.

None of that is unreasonable per se, but it is unreasonable, and even dangerous, when the rendering core that they have a large stake in and modify for their purposes continues to accumulate market share. The standards canard is particularly insidious; "standards" are proposed and immediately implemented with a vendor prefix, but no one else may have implemented them or done so in the same way. Vendor prefixes again are not inherently bad and are necessary for proper testing and review, but they become another means for lock-in when people start developing their code for the set of vendor prefixes in their target browser to the exclusion of other rendering libraries. When WebKit is seen as the dominant rendering system, people only write code that works in WebKit, just as they did for Internet Explorer, and their dominant market position is only reinforced.

I'm a free-markets bastard, but a free market can only exist as long as there is adequate competition. The desired state of business in a particular industry is rent-seeking monopoly, and that's as bad here as it is with your electric bill. Opera Presto was a well-regarded standards-compliant alternative to WebKit which is now gone. The possible future outcome of a single browser rendering core means not only the loss of the community standards process and standardization around its attendant and sometimes significant quirks, but locks the way we use the Web in the hands of a governance process where the open Web's welfare is only secondary.


  1. I read about that, too, and I'm concerned. WebKit = IE6 all over again. Dangerous.

  2. CK:

    Reading this today, I just wanted to say thank you for what you're continuing to do with 104F. Not just for the software, but for the nuanced understanding of the digital world behind it, made manifest in code.

    The world needs more smart people like you. But there are ... always enough, for those with eyes to see. Yes, we might be going down the road of monoculture in browsers right now. But Mozilla rose from ashes once, and Linux grows in a thousand cracks in the smooth aqua sidewalk, and we who care will always find a way, so long as we, and you, continue to pursue the just.

    Blessing on ya.


  3. This comment has been removed by the author.

  4. I think, it depends greatly on the will of the web developers - who will mostly choose the way of least resistence, which will be incompatibility with browsers other than the mainstream ones.

    WebKit has had a good effect on the browser "market", contributing to break the IE monopoly. But when mozilla decided to abandone embedded Gecko, WebKit became the only actively developed open source web rendering engine to support embedding on a variety of platforms. In fact you are almost forced to use WebKit if you want to build a modern web browser for your own platform (proprietary or open source) or if you want to release a new product (with a current core) for various platforms. Sure, you can always fork mozilla but that would undoubtedly be much more work - and the mozilla code base is significantly more complex than WebKit.

    1. I totally agree that Gecko dropping embedding support was a bad idea, killing both Camino and K-Meleon, plus the handful of Gecko-embedded Linux variants. I certainly hope Mozilla reconsiders embedding in light of Opera's decision. But, as you say, Gecko was always a bigger ball of wax to deal with even when it did support it, which is of course why Apple modified KHTML to make WebKit to begin with. That didn't stop people from using it then.

      Similarly, I don't fault people for choosing the easiest way to go (necessarily). For Leopard WebKit, at least, that seems to have paid off since you don't need to maintain the browser docshell, just the rendering library. But, in the end, the core that they choose may well end up working against the purposes for which they chose it in the first place.

      WebKit has done some good to crack IE, just as IE made Netscape realize it was vulnerable. But when IE got too large, it fed back negatively into the market, and I strongly suspect a similar outcome awaits us now.


Due to an increased frequency of spam, comments are now subject to moderation.