Chromium and the Browser Monoculture Problem
Some major problems with the &quot;let&#x27;s all use Chromium&quot; approach:<p>Google controls Chromium because they do the heavy lifting. All the companies that use Chromium are using it <i>because</i> they want Google to do the heavy lifting, so that isn&#x27;t going to change, even if Google decides to put an open governance face on it, and there&#x27;s no sign they&#x27;re going to do even that. Should Google really be ceded complete power over the Web?<p>A single browser codebase hurts the maintainability of the Web platform. To the extent Chromium has a monopoly, Chromium bugs <i>are</i> the standard and sites will depend on them. Yes, this is already true to some extent, but it could get much worse. So fixing bugs would get harder.<p>A single codebase makes radical implementation experiments more difficult. Companies can patch Chromium but architectural divergence gets expensive fast. Say you want to rewrite the Chromium style system for parallelism with Rust, like Mozilla did with Firefox, and Google says no? Good luck maintaining that long-term. (A good example was how JSC vs V8 caused endless friction between Google and Apple in Webkit, leading up to the Blink fork.)<p>Another problem is that it would be very hard to block Web features that Google implements in Chromium. (P)NaCl&#x2F;Pepper is a good example. &quot;It&#x27;s a ton of work to implement (especially if there&#x27;s no spec)&quot; is a helpful argument for not implementing a feature that&#x27;s bad for the Web, both in public and to one&#x27;s own product management. Hard to hold the line on something like PNaCl&#x2F;Pepper or WebSQL if it&#x27;s just a matter of flipping a configuration flag to increase Web compatibility. If the world was all-Chromium a few years ago there&#x27;s no doubt we&#x27;d have PNaCl&#x2F;Pepper instead of WebAssembly --- and we&#x27;d be stuck with the insane duplication of Pepper vs standard Web APIs, the bloat of LLVM everywhere, etc.