[jcsiracusa]

We already have two or three powerful entities working on WebKit, pulling it in whatever directions suit their needs. If they ever pull hard enough or far enough in different directions, it could tear (fork) and the cycle begins again. And anyone is free to learn from WebKit and create something better (as Apple learned from Gecko before adopting KHTML).

"Monoculture" is a loaded word. The differing priorities that might manifest in completely separate web rendering engines still have plenty of room to manifest when multiple big players are working on WebKit, with nothing stopping any of them from forking if the differences get too large.

(And anyway, Gecko does still exist, after all…)

[azakai]

With a very optimistic outlook like yours, there is nothing to worry about: Everything will work out, these are just cycles in the industry. What could go wrong?

But we already see problems today from WebKit's dominance on mobile. Non-WebKit browsers have trouble rendering the mobile web which was designed with only WebKit in mind. It got so bad that Opera just gave up and adopted Chromium (not even just WebKit).

The remaining non-WebKit browsers, IE and Firefox, are left with an even bigger problem and it is even harder for them to disrupt the WebKit mobile web. And it would be even harder for a completely new engine.

So general arguments about cycles and all that might sound good, but we already see the damaging effects of WebKit monoculture (you argue it's a loaded word, but it fits).

[jcsiracusa]

I'd say we already see the benefits of having so many people work together on WebKit. Would we be better off if Google had to create and maintain its own desktop and mobile web rendering engine from scratch? If there's a monoculture problem in mobile web browsing, it's due to the disproportionately large percentage of it that's done using Mobile Safari on iOS. Single-vendor/closed-platform will always be a problem. WebKit is neither.

Yes, over-use of vendor prefixes in CSS and other browser-specific features is bad. But that's an authoring issue as much as it's a WebKit issue. Having -moz-, -o-, and -webkit-* plus JavaScript shims to hide the differences in multiple browsers is a great argument for standards, but not a great argument for a larger variety of independently developed and maintained web rendering engines.

[azakai]

> I'd say we already see the benefits of having so many people work together on WebKit.

Of course, as I already agreed before. There are benefits to centralization.

It's a question of degree, not absolutes. As I said, 10 or 100 might be too many rendering engines, while 1 is too few. 2 or 3 seems, to me, to be optimal, but again this is a matter of degree so others may prefer a little more or less.

> Yes, over-use of vendor prefixes in CSS and other browser-specific features is bad. But that's an authoring issue as much as it's a WebKit issue. Having -moz-, -o-, and -webkit-* plus JavaScript shims to hide the differences in multiple browsers is a great argument for standards, but not a great argument for a larger variety of independently developed and maintained web rendering engines.

Agreed, this is not just a WebKit monoculture issue - plenty of other problems in that area as well, as you say.