It seems to me that having a single pervasive open source web rendering engine is actually the ideal state of affairs. How is fragmentation helpful in this area? It's duplicated effort and it makes Web development harder (and less efficient) for the millions of Web developers out there. I personally don't see people taking this approach to, say, Linux; generally people are happy that it's dominant in the server realm and that they can learn one thing and use it everywhere.
IE used a proprietary rendering engine. It's now being replaced with a free and open source one. This seems like a strict improvement. It's the opposite situation -- a single proprietary engine being dominant -- that is the doomsday scenario, and that's what we saw a decade and a half ago with IE. The farther we get from that being a possibility, the better.
For related reasons, I'm not happy that DRM has become part of the standard Web feature set.
> It seems to me that having a single pervasive open source web rendering engine is actually the ideal state of affairs. How is fragmentation helpful in this area?
Because the Chromium monoculture has allowed Google to dominate the web standards process. They can veto any feature or force one through by shipping it and pushing sites to depend on it (including their own).
There is an army of Googlers whose job it is to keep tacking on new web standards. And Google will implement the features before proposing the specs, so their competitors—well, now it's just Mozilla and Apple, I guess—are kept playing constant catch-up. Meanwhile, anything that comes from outside of Google will have to brave the same army trying to smother it in committee.
Just ask anyone who's dealt with web standards politics from outside of Google. It isn't fun anymore.
(Oh, yeah, and because there's essentially no accountability now, plenty of these new features rushed through the door are buggy and introduce security holes. It's like IE all over again.)
Apple’s WebKit is kept in-sync with Chromium - whenever Google adds something then Apple gets it for free within a couple of months - though Apple tends to disable or vendor-prefix new features it doesn’t like.
Ah - my mistake. I was operating on the assumption the Blink and WebKit teams were exchanging patches regularly.
That's a dang shame then :/
Apple's a big company - but we saw how they mishandled their own first-party Maps service after divorcing from Google - I can see Apple's Safari potentially falling behind badly if they can't keep-up with Google's work on Blink.
They already are; there are some pretty glaring bugs/missing features in webkit nowadays.
In fact, I can't think of any webkit developments that positively surprised me the past few years; development seems glacial, at best. A list of somewhat notable stuff chromium and gecko have that webkit is still missing:
Stuff because it's better to make your devs pay licenses for no good reason:
The monoculture around Linux is actually a problem. Linux' design is suboptimal in many ways, particularly how drivers run with full privilege. (For a sobering look at how this impacts security, watch [1].) It's unfortunate that the monoculture of Linux is going to make this very difficult to change.
There are significant architectural differences in components of Blink, WebKit, Gecko. For example, the CSS style recalculation is very different—Blink uses a single-threaded engine in C++, WebKit uses a C++ JIT, and Gecko does multithreaded style recalculation in Rust. It would be hard to do WebKit or Gecko's approach with the current Chromium governance, because WebKit's CSS JIT uses parts of JavaScriptCore (per my understanding) and because Chromium doesn't currently allow Rust code.
Sure, but not impactful enough to matter in practice. FreeBSD can claim a lot of architectural differences too and yet they don't solve the problems you were talking about. And the actually different OSes that can help with those problems are not really usable except for some niche use cases.
It's about governance and dominance, not implementation.
It doesn't matter if the code for a single web rendering engine is available if the standards process is closed.
Although in fact there are also implementation issues. Nowhere has it been proven that open source implementations are optimally efficient, secure, and robust. In fact the various debacles around SSL etc strongly suggest otherwise.
The fact that development is either open source or proprietary continues to be a huge problem. They both have strong points, but they also have obvious weaknesses. Realistically neither is optimal for critical public infrastructure.
Currently Google has far too much over influence over infrastructure - rather like Microsoft did in the late 90s, but even more so.
Open source won't fix this. Anti-trust action - which is long overdue - might.
IE used a proprietary rendering engine. It's now being replaced with a free and open source one. This seems like a strict improvement. It's the opposite situation -- a single proprietary engine being dominant -- that is the doomsday scenario, and that's what we saw a decade and a half ago with IE. The farther we get from that being a possibility, the better.
For related reasons, I'm not happy that DRM has become part of the standard Web feature set.