In May 2019 I attended a talk by Mike Taylor who works on webcompat at Mozilla. Mike told the sordid story of window.event, a non-standard IE invention that was replicated in Konqueror, which showed up in Webkit, which stuck around in Blink, and was now Mike’s problem in Firefox. It was a good story fraught with ups and downs and literal “Breaking the Web” level changes for a tiny feature rollout.

At the end of the talk Mike threw out a pretty prescient question (Edge had just released its Chromium beta) and I’ve been mulling over it ever since:

What is the value of browser diversity? If Firefox switched to Chromium tomorrow, what would we lose?

– Mike Taylor, a traitor (apparently)

Mike made it clear that the question was purely theoretical and no serious talk about this was happening at Mozilla at the time. Nonetheless, it was a challenging thought. Throwing away all sunk costs, what is the value of the colossal expense required to employ engineering teams to chase Chrome’s tail?

I’ve thought about these questions for over a year and narrowed my feelings of browser diversity down to two major value propositions:

  1. Browser diversity keeps the Web deliberately slow
  2. Browser diversity fosters consensus and cooperation over corporate rule

They are similar, but slightly different concepts for me.

Slow, like brisket.

I think the Web platform’s most frustrating aspect is also its greatest asset: it’s slow. It’s not just slow, it’s “it took 10 years1 to ship the <main> element which is just a spicy <div>” kind of slow. It’s glacial.

This can be agonizing while you wait for a much needed feature to roll out in all browsers, only to find out five years in the process one browser refuses the entire premise of the feature (RIP HTML Imports). The big tradeoff is that web platform features have to run the gauntlet and more thinking is applied over time: robustness, naming, internationalization, accessibility, security, etc. all have proper time for consideration and aren’t rushed through like it’s a product sprint.

There’s a lot of value in slow thinking. You use the non-lizard side of your brain. You make more deliberate decisions. You prioritize design over instant gratification. You can check your gut instincts and validate your hypothesis before incurring mountains of technical debt.

I think just enough iteration before a release produces better products. Because once it’s out, it’s out. There’s no turning back or major API changes. This part of the standards process creates a buffer against the Web platform becoming just a collection of trends. I’m not saying the process is perfect, it takes entirely too long right now, but that weakness is also its strength.

Cooperation, not corporation.

Browser diversity means browser vendors are hindered from shipping features that only benefit themselves (e.g. ActiveX in IE, -webkit-box-reflect, etc). Good ideas have to be open and meet a pseudo-requirement of ubiquitous utility. To make good platform features requires consensus, not competition, and the web’s potential is born out of cooperation, not a single corporation.

It’s hard to quantify this, but if all aspects of the Web (development, browsing, searching, hosting) are ceded to a single corporation, all it takes is one heavy-handed manager or executive hellbent on hitting some OKRs to push their thumb on the scale of the Web. If the Web is governed by a single corporation, it will start looking like that corporation’s vision of the Web, ultimately limiting its own potential. Trading short term gain on new shiny features for long term vision.

As it stands today, to truly ship in multiple engines requires great consensus. I’m aware of the downsides of consensus in product development; it often means you end up with something over-engineered, and watered down. And to be honest, there are a handful of HTML, CSS, and JS features that I don’t use for that very reason.

Those features aren’t bad, just not my favorite. “Bad” usually comes in the form of unilaterally shipped features that take a long time to fix, retroactively standardize, or undo (e.g. vendor prefixes, <dialog>, window.event, etc). Again, once shipped, they’re shipped. They linger around in the platform, working in some browsers, never in another, frustrating developers. It produces brittleness.

The corporate landscape is setup for competition that produces this kind of disparity. Free markets and invisible hands work occasionally, but if browsers compete, the chance that we gain better choice options is probably less likely than a features arms race with enormous fallout. But if browsers cooperate, I think we all win.

What would we lose?

Back to Mike’s original question… If all browsers switched to a single engine, does this change the things I value? I don’t know.

I’ve been sitting on this post for over a year, but the browser diversity situation has become a more sincere concern in last month as Mozilla laid off 25% of their staff. Chris and I speculated on ShopTalk 427 that Mozilla might be switching to Chromium. Thankfully, Marcos Cáceres dispelled our speculation in a Twitter thread:

I’m happy to hear this news, but I feel our speculation was warranted because there hasn’t been a clear commitment to Gecko from Mozilla through all of this. The layoff post only cites a vague commitment to a “New focus on community”, but meanwhile, all the departments I interface with as a developer (MDN, WebVR, DevTools, etc) were wholesale laid off. It’s hard for me, a person who cares about this stuff, to understand the plan or roadmap that brings Firefox back.

It would be incredibly sad to lose Firefox. Lots of talented people, lots of jobs. But abstracting the issue outside of the very real human costs, what is the value of browser diversity? What would we lose?

Maybe we’ve already reached the tipping point. We’re already in a situation where if Google wants it, then it’s immediately available in multiple browsers. True, other Chromium browsers can turn that feature flag off, but there’s nearly no incentive for Edge, Samsung Internet, Opera, Beaker, or Brave to have less features and more webcompat issues. Frankly, it would be bad optics.

I’d love to be proven wrong, but it seems like Google already controls the roadmap. There’s other concerning moves, like Google’s denial of Metastream’s Widevine DRM application and AMP. But one giant looming concern for browser diversity is the sheer complexity of what a browser has to be nowadays. As Mike Healy pointed out, maybe the Web has already “priced itself out of the market”:

A positive sign that the system is still working is how Safari, Mozilla, and now Brave have pushed back against a dozen or so features in Google’s Project Fugu roadmap. Brave is notable because it’s also Chromium-based. While there are definitely some cool platform features on the threshing room floor after this and while I don’t perfectly understand the privacy concerns raised (because privacy is a big complicated issue with a lot of boogeymen), I have to hope stalling progress is not just corporate warfare, but genuinely in the interest of a safer, more secure foundation for the Web going forward.

If we do see a major reduction in browser diversity, I think we lose the intentional slowness and the cooperation mechanisms we have in place. Who knows what will happen, but my hope is that just like iron can sharpen iron, maybe chromium can sharpen chromium.

  1. Adrian Roselli on Twitter pointed out the <main> element is actually an HTML success story. It was officially proposed in 2012 and landed all major browsers by 2014. That’s impressive! Apologies for any disinformation, but it’s also worth noting the idea of a maincontent element had been in the cultural zeitgeist since as early as 2005 or 2006 based on the same research that informed the naming of other HTML5 elements. ↩