Browsers are not rendering engines

An interesting writeup by Brian Kardell on web engine diversity and ecosystem health, in which he puts forward a thesis that we currently have the most healthy and open web ecosystem ever, because we’ve got three major rendering engines (WebKit, Blink, and Gecko), they’re all cross-platform, and they’re all open source. This is, I think, true. Brian’s argument is that this paints a better picture of the web than a lot of the doom-saying we get about how there are only a few large companies in control of the web. This is… well, I think there’s truth to both sides of that. Brian’s right, and what he says is often overlooked. But I don’t think it’s the whole story.

You see, diversity of rendering engines isn’t actually in itself the point. What’s really important is diversity of influence: who has the ability to make decisions which shape the web in particular ways, and do they make those decisions for good reasons or not so good? Historically, when each company had one browser, and each browser had its own rendering engine, these three layers were good proxies for one another: if one company’s browser achieved a lot of dominance, then that automatically meant dominance for that browser’s rendering engine, and also for that browser’s creator. Each was isolated; a separate codebase with separate developers and separate strategic priorities. Now, though, as Brian says, that’s not the case. Basically every device that can see the web and isn’t a desktop computer and isn’t explicitly running Chrome is a WebKit browser; it’s not just “iOS Safari’s engine”. A whole bunch of long-tail browsers are essentially a rethemed Chrome and thus Blink: Brave and Edge are high up among them.

However, engines being open source doesn’t change who can influence the direction; it just allows others to contribute to the implementation. Pick something uncontroversial which seems like a good idea: say, AVIF image format support, which at time of writing (May 2020) has no support in browsers yet. (Firefox has an in-progress implementation.) I don’t think anyone particularly objects to this format; it’s just not at the top of anyone’s list yet. So, if you were mad keen on AVIF support being in browsers everywhere, then you’re in a really good position to make that happen right now, and this is exactly the benefit of having an open ecosystem. You could build that support for Gecko, WebKit, and Blink, contribute it upstream, and (assuming you didn’t do anything weird), it’d get accepted. If you can’t build that yourself then you ring up a firm, such as Igalia, whose raison d’etre is doing exactly this sort of thing and they write it for you in exchange for payment of some kind. Hooray! We’ve basically never been in this position before: currently, for the first time in the history of the web, a dedicated outsider can contribute to essentially every browser available. How good is that? Very good, is how good it is.

Obviously, this only applies to things that everyone agrees on. If you show up with a patchset that provides support for the <stuart> element, you will be told: go away and get this standardised first. And that’s absolutely correct.

But it doesn’t let you influence the strategic direction, and this is where the notions of diversity in rendering engines and diversity in influence begins to break down. If you show up to the Blink repository with a patchset that wires an adblocker directly into the rendering engine, it is, frankly, not gonna show up in Chrome. If you go to WebKit with a complete implementation of service worker support, or web payments, it’s not gonna show up in iOS Safari. The companies who make the browsers maintain private forks of the open codebase, into which they add proprietary things and from which they remove open source things they don’t want. It’s not actually clear to me whether such changes would even be accepted into the open source codebases or whether they’d be blocked by the companies who are the primary sponsors of those open source codebases, but leave that to one side. The key point here is that the open ecosystem is only actually open to non-controversial change. The ability to make, or to refuse, controversial changes is reserved to the major browser vendors alone: they can make changes and don’t have to ask your permission, and you’re not in the same position. And sure, that’s how the world works, and there’s an awful lot of ingratitude out there from people who demand that large companies dedicate billions of pounds to a project and then have limited say over what it’s spent on, which is pretty galling from time to time.

Brian references Jeremy Keith’s Unity in which Jeremy says: “But then I think of situations where complete unity isn’t necessarily a good thing. Take political systems, for example. If you have hundreds of different political parties, that’s not ideal. But if you only have one political party, that’s very bad indeed!” This is true, but again the nuance is different, because what this is about is influence. If one party wins a large majority, then it doesn’t matter whether they’re opposed by one other party or fifty, because they don’t have to listen to the opposition. (And Jeremy makes this point.) This was the problem with Internet Explorer: it was dominant enough that MS didn’t have to give a damn what anyone else thought, and so they didn’t. Now, this problem does eventually correct itself in both browsers and political systems, but it takes an awfully long time; a dominant thing has a lot of inertia, and explaining to a peasant in 250AD that the Roman Empire will go away eventually is about as useful as explaining to a web developer in 2000AD that CSS is coming soon, i.e., cold comfort at best and double-plus-frustrating at worst.

So, a qualified hooray, I suppose. I concur with Brian that “things are better and healthier because we continue to find better ways to work together. And when we do, everyone does better.” There is a bunch of stuff that is uncontroversial, and does make the web better, and it is wonderful that we’re not limited to begging browser vendors to care about it to get it. But I think that definition excludes a bunch of “things” that we’re not allowed, for reasons we can only speculate about.

I'm currently available for hire, to help you plan, architect, and build new systems, and for technical writing and articles. You can take a look at some projects I've worked on and some of my writing. If you'd like to talk about your upcoming project, do get in touch.

More in the discussion (powered by webmentions)

  • Rodney 💚🌹☯ responded at twitter.com This is a really interesting post, and I agree with quite a lot of it, and you should read it! However... I have some thoughts. Since they'
  • Kamen Bundev responded at twitter.com This is a really interesting post, and I agree with quite a lot of it, and you should read it! However... I have some thoughts. Since they'
  • Kamen Bundev responded at twitter.com
  • Bruno Girin responded at twitter.com This is a really interesting post, and I agree with quite a lot of it, and you should read it! However... I have some thoughts. Since they'
  • Kamen Bundev responded at twitter.com
  • Léonie responded at twitter.com This is a really interesting post, and I agree with quite a lot of it, and you should read it! However... I have some thoughts. Since they'
  • Gamer Geek responded at twitter.com Stuart Langridge: Browsers are not rendering engines kryogenix.org/days/2020/05/2…
  • вкαя∂εℓℓ responded at twitter.com These are also interesting points by @sil /worth a read. I'm not suggesting there is nothing to this kind of factor, but rather that there are a lot…
  • вкαя∂εℓℓ responded at twitter.com great post, super impressive how fast you turned that around :)
  • Baldur Bjarnason @[email protected] responded at twitter.com “as days pass by — Browsers are not rendering engines” “The ability to make, or to refuse, controversial changes is reserved to the major browser ven…
  • Stuart Langridge responded at twitter.com bit stream of consciousness, but it largely distills my thoughts on a subject we have discussed before and I wanted to write them down somewhere while…
  • Adactio Links responded at twitter.com as days pass by — Browsers are not rendering engines kryogenix.org/days/2020/05/2…
  • Comandeer responded at twitter.com This is a really interesting post, and I agree with quite a lot of it, and you should read it! However... I have some thoughts. Since they'
  • вкαя∂εℓℓ responded at twitter.com
  • вкαя∂εℓℓ responded at twitter.com
  • Bruno Girin responded at twitter.com
  • Dr. Roy Schestowitz (罗伊) responded at twitter.com Stuart Langridge: #Browsers are not rendering engines kryogenix.org/days/2020/05/2… nowadays they're bloatware for running malicious scripts/code
  • Charles Bauer responded at twitter.com This is a really interesting post, and I agree with quite a lot of it, and you should read it! However... I have some thoughts. Since they'
  • zem responded at twitter.com
  • Charles Bauer responded at twitter.com
  • aardrian responded at twitter.com From @briankardell: “Web Engine Diversity and Ecosystem Health” bkardell.com/blog/Ecosystem… From @sil: “Browsers are not rendering engines” kryogeni…
  • Jason Karns responded at twitter.com
  • Peter Rushforth responded at twitter.com One of the things we're left to speculate about is maps for the Web, oddly, which I thought would not be controversial, since *everyone* uses maps. k…
  • Yoav Weiss responded at twitter.com Great posts both!! @sil - just a few inaccuracies I noticed: * Blink does have a built-in ad blocker, added by Google folks!! (against bad ads)
  • Bastien Calou responded at twitter.com "The open ecosystem is only actually open to non-controversial change" Où comment certains projets open source sont plus open que d'autres kryogenix.o…
  • Damien Huteau responded at twitter.com Moteur de rendu open source ? Et alors ?! ''browsers are not rendering engines'' kryogenix.org/days/2020/05/2…
  • Joulse responded at twitter.com Browsers are not rendering engines kryogenix.org/days/2020/05/2…