By Craig Buckler

5 Reasons to Reject the WebKit Monoculture

By Craig Buckler

Opera’s WebKit announcement has divided developer opinion. Some are pleased there are fewer rendering engines to support (not that many developers actively tested Opera). Others state this is the beginning of the WebKit monoculture and IE6-like doom is upon us. The truth is somewhere in between but there are several reasons for concern.

1. WebKit != IE6, but…

WebKit is an open source rendering engine. It is not owned or controlled by a single organisation; anyone can use and modify the code. In comparison, IE (and its Trident engine) is owned by Microsoft and only available on Windows. Microsoft decision to abandon browser development could not occur in the WebKit world.

However, it’s important to remember that Apple and Google — two of the most powerful global IT companies — are in control of the most popular WebKit browsers. Apple is also responsible for handling WebKit developer agreements and either company can accept, reject or modify WebKit features to their commercial advantage. While you may be able to update the core engine, it won’t matter unless those changes eventually reach Chrome and Safari.

2. WebKit is not one engine

Some developers believe cross-browser compatibility issues will disappear if all vendors use the same engine. It would certainly make development easier, but it’s naive to think all problems would be eradicated. Test a reasonably complex design in Chrome and Safari today and you will encounter differences.

WebKit is forked and evolves along different paths. Vendors have different devices, deployment schedules and requirements. For example, Apple regularly add proprietary iOS-specific properties which may never reach the W3C or appear as recommendations.

3. WebKit is not the best engine

Those who support the monoculture argue that WebKit has won; it’s beaten Gecko and Trident. They are wrong. No engine is perfect, but you learn to forgive or avoid issues when you concentrate on a single browser.

WebKit is excellent and it was certainly the first to hit the CSS3 animation headlines. But if you think it’s ahead of all others, try using SVGs. Attempt animating pseudo elements. Use an unprefixed transform, animation or calc() function. Code using newer HTML5 form elements. Try persuading Firebug fans to abandon their favorite development tool. Don’t take my word for it — Dave Methvin of the jQuery core team and president of the jQuery Foundation states:

Each release of Chrome or Safari generates excitement about new bleeding-edge features; nobody seems to worry about the stuff that’s already (still!) broken. jQuery Core has more lines of fixes and patches for WebKit than any other browser. In general these are not recent regressions, but long-standing problems that have yet to be addressed.

When we started our jQuery 2.0 cleanup to remove IE 6/7/8 hacks, we were optimistic that we would also be able to remove some bloat from lingering patches needed for really old browsers like Safari 2. But several of those WebKit hacks still remain. It’s starting to feel like oldIE all over again, but with a different set of excuses for why nothing can be fixed.

WebKit, Gecko, Presto and Trident are all good rendering engines. They have strengths, they have weaknesses, but none is an outright winner in all areas.

4. A monoculture means and end to standards

One group of people was wholly responsible for the IE6 debacle…

web developers

IE6’s longevity was not the fault of system administrators, slow-moving organizations or an evil Microsoft. Ten years ago, developers targeted IE — not web standards. IE6 was the standard born from a monoculture; few considered a future where IE did not exist.

While there may never be a single WebKit engine, developers will choose it over W3C standards. If something works in WebKit browsers, it won’t matter whether that feature is proprietary, implemented incorrectly or fails elsewhere: it becomes the standard. At that point, you have to hope WebKit is never superseded by a better alternative — a horrible thought.

5. Competition is good

I’m saddened to see the demise of Presto but Opera made a logical business decision. Their primary market is mobile devices and Apple control the only HTML engine permitted on the iPhone and iPad. However, those restrictions do not apply to Microsoft and Mozilla. They have nothing to gain from switching to WebKit:

  • If Microsoft scrapped Trident, it would affect every Windows application using web integration. It would cause chaos. I’m sure it would be technically possible to implement an API translation bridge, but how long would that take and what commercial benefit would it offer?
  • Mozilla is not a commercial operation; there are no stakeholders or profit targets. The organization exists because it has Gecko, XUL and a range of related technologies. While they could switch to WebKit, it would end major projects such as Firefox OS.

Competition has been good for the web industry. A WebKit monoculture brings short-term development ease at the expense of long-term evolution and growth. Be careful what you wish for.

  • 5 stars.
    You should also mention the absurd policies of apple on ios so we can not have a browser with a different engine on ipad/iphone.
    The competition is a good thing, without competition, without Mozzila. we would still have IE 6.2 with 90% of users.

  • Heino

    I’m sorry, this article is BS.

    • Doesn’t Paul’s article simply expand on what I’ve said in point 2: there is no single WebKit engine?

  • I’m not sure it’s so bad for Opera to make a move. As mentioned, most of us didn’t test in it. Do I want to see Mozilla disappear? No. IE? Only the older ones. I don’t want a mono-web. Just one that’s not a circus for cross-browser standards.

  • Michael

    The biggest difference between all developers conforming to IE6 and all developers conforming to Webkit is that Webkit rapidly evolves.


    “Try persuading Firebug fans to abandon their favorite development tool.”

    What does Firebug have that Chrome doesn’t have built in? I made the switch years ago and can’t go back to Firebug, it’s not as easy to use.

    • sam

      I would like to hear peoples thoughts on this too. Firebug feels horrible and clunky to use compared to the developer tools in chrome. I can’t go back to it after using chrome and safari developer tools for a couple of years now.

    • Webkit does evolve rapidly, but would it do so without competition? I’m also concerned that it concentrates on shiny new stuff without addressing the broken, more mundane issues.

      Whatever tool you use is what you’ll prefer. Personally, I find Firebug more reliable and easier than the WebKit inspector, but that’s because I been using it most days since it was first released.

      • Rob

        Craig, obviously you aren’t aware of the original intent for Google to come out with Chrome. They stated they weren’t happy with how browsers performed and they wanted to build a better browser so the others would make better browsers; and that has happened. Chrome was developed to create competition and move the web forward. Saying that webkit wouldn’t evolve rapidly without competition is backwards.

      • Has Google’s intention for Chrome remained the same? I doubt it. It was all very noble in the early days, but they now have the most-used browser and search engine. It’s a powerful position to be in. Put it this way, would Google accept a Webkit feature which caused a commercial issue for them?

        The fact is, we don’t know what would happen. But, if history shows us anything, it’s that people and companies become complacent when they have a monopoly.

  • I hope all developers read this and take it to their hearts. I would also like to add 2 more arguments:

    1. Monoculture is never good in the long run for anything, in any human endeavour, but it keeps popping up because of its short term benefits. Thus, the fact that one can not see a problem today does not mean that it won’t come one further down the road. The monoculture is bad-argument is not a technological prediction, but wisdom that goes beyond bits and bytes.

    2. Although it is a monumental task, the day might one day appear when a project like Mozilla Servo actually will take the place of Gecko or WebKit. It might happen, it might not, but closing the door entirely is not a good idea. What if the processors of tomorrow will have thousands of cores? What if engineers and scientists one day actually do get a quantum computer up and running? If the web is tightly coupled to any rendering engine refactoring becomes exponentially more laborious. Tight coupling is bad in all software engineering!

  • Robert

    I have to apologize because I’m preventing the monoculture on my own from happening. I roll my own. :
    But I’m of course not distributing. :)

    I agree that there will never be a monoculture, differences between Safari and Chrome on Windows prove enough. For example rendering of the Steelfish Extra Bold Regular font at 48px with a text-shadow: 1.5px 1.5px 3px rgba(111, 111, 111, 0.5); (on a mid grey background) looks good/normal in Chrome and totally screwed up in Safari. The text-shadow fills up the holes in letters like B O P Q R, etc. You would expect things like that to be the same because they are both webkit.
    Also, Chrome recognizes -webkit-text-shadow and text-shadow, while Safari only recognizes text-shadow. So there is no way around it. Both end up using text-shadow I can’t use -webkit-text-shadow for Chrome and text-shadow for Safari.
    And I don’t know how Safari on OS X behaves. Sigh!

    • Sai Pc

      Technically speaking,you could add the -webkit- prefixed version of text shadow after the non prefixed version to get different behaviours in safari and chrome..though i wonder why you would want something like would use the -webkit-version while safari would ignore it..

  • Mac

    Very well written and very well put.

    The declining share of Firefox and IE9&10 is worrying. Monopoly of one software (open or close) is not good.

  • Rob

    Point 3 seems to say there is another engine that is better. While webkit may have its flaws, that doesn’t mean it can’t be the best of the rest. Putting trident in the same league as the others makes me question the calibre of the author’s knowledge.

    Point 4 puts blame squarely on the users. Something Microsoft is keen to do but apparently the author is forgetting, or wasn’t in this business, when not making your web page work in IE6 meant not having a working web page for 95% of the world. Shame on him.

    • The IE10 version of trident is, for the important parts of HTML and CSS, as good as Webkit. It’s taken too long to get there, but the days of IE6-like hassle are long gone. Turning that on it’s head — why exactly do you think it’s not in the same league?

      As for point 4, I’ve been in the business since 1995. It isn’t about not supporting IE6: it was about avoiding proprietary technologies and testing in a range of other browsers. Few people did that — including me. I take full responsibility and shame for all the IE6-only sites and applications I created. Do you?

  • I totally agree … but just as a point of debate – is there really anything wrong with developing standards from a formal reference implementation, rather than a formal document? To effectively say, “whatever x browser does, is the standard”?

    • In essence, isn’t that what happens now? However, at least two vendors must have the same implementation before it can become an approved W3C standard. It’s not clear what would happen if WebKit were the only engine?

      • Mr. Buckler, you bring up a very interesting point: is the requirement two vendors or two engines?

        I was under the impression that two vendors meant two separate browsers (for instance, Chrome and Internet Explorer). In this case (with Safari, Chrome, and Opera using the same engine), once Webkit implements a specification, there should be three implementations (under ideal situations). This would bode well for speedy Recommendations from the W3C and force IE and Firefox to step up.

        Now, if the two-vendor implementation means two independent engines, then I really do not foresee a monoculture insofar as Recommendations from the W3C are concerned.

        Would you please clarify for me what the W3C actually requires for two implementations? You seem to have your finger on the button and actually know what your talking about on these matters. Will be awaiting your reply.

  • I agree and disagree. At the end, the reason # 5 is the real truth: competition is the better alternative.

Get the latest in Front-end, once a week, for free.