We lost Opera when they went Chrome in 2013. Same deal with Edge when it also went Chrome earlier this year. Mike Taylor called these changes a “Decreasingly Diverse Browser Engine World” in a talk I’d like to see.
So all we’ve got left is Chrome-stuff, Firefox-stuff, and Safari-stuff. Chrome and Safari share the same lineage but have diverged enough, evolve separately enough, and are walled away from each other enough that it makes sense to think of them as different from one another.
I know there are fancier words to articulate this. For example, browser engines themselves have names that are distinct and separate from the names of the browsers.
Take Chrome, which is based on the open-source project Chromium, which uses the rendering engine Blink and the JavaScript engine V8.
Firefox uses Gecko as its browser engine, which is turning into Quantum, which has sub-parts like Servo for CSS and rendering.
Safari uses WebKit as a browser engine, which has parts like WebCore and JavaScriptCore.
It’s all kinda complicated and I’m not even sure I quite understand it all. My brain just thinks of it as everything under the umbrella of the main browser name.
The two extremes of looking at this from the perspective of decreasing diversity:
- This is bad. Decreased diversity may hinder ecosystems from competing and innovating.
- This is good. Cross-engine problems are a major productivity loss for the world. Getting down to one ecosystem would be even better.
Whichever it is, the ship has sailed. All we can do is look forward.
Random thoughts:
- Perhaps diversity has just moved scope. Rather than the browser engines themselves representing diversity, maybe forks of the engnies we have left can compete against each other. Maybe starting from a strong foundation is a good place to start innovating?
- If, god forbid, we got down to one browser engine, what happens to the web standards process? The fear would be that the last-engine-standing doesn’t have to worry about interop anymore and they run wild with implementations. But does running wild mean the playing field can never be competitive again?
- It’s awesome when browsers compete on features that are great for users but don’t affect web standards. Great password managers, user protection features, clever bookmarking ideas, reader modes, clean integrations with payment APIs, free VPNs, etc. That was Opera’s play, and now we see many more in the same vein. Vivaldi is all about customization, Brave doubles down on privacy and security, and Puma is about monetization.
Brian Kardell wrote about some of this stuff recently in his “Beyond Browser Vendors” post. An interesting point is that the remaining browser engines are all open source. That means they can and do take outside contributions, which is exactly how CSS Grid came to exist.
Most of the work on CSS Grid in both WebKit and Chromium (Blink) was done, not by Google or Apple, but by teams at Igalia.
Think about that for a minute: The prioritization of its work was determined in 2 browsers not by a vendor, but by an investment from Bloomberg who had the foresight to fund this largely uncontroversial work.
And now, that idea continues:
This isn’t a unique story, it’s just a really important and highly visible one that’s fun to hold up. In fact, just in the last 6 months engineers as Igalia have worked on CSS Containment, ResizeObserver, BigInt, private fields and methods, responsive image preloading, CSS Text Level 3, bringing MathML to Chromium, normalizing SVG and MathML DOMs and a lot more.
What we may have lost in browser engine diversity we may gain back in the openness of browser engines and outside players stepping up.
I tend to see the decreasing numbers of browser-engines as a way of maturing the web platform.
I all my talks about the difference between frontend and backend I cannot emphasize enough, that we in the frontend don’t know which counterpart we are aiming at. Whereas a backend-developer always knows, which server he is aiming at and which version of PHP, Java or whatelse this server hosts. AND: there is only ONE interpreter with 100% capabilities and no errors. If an error occurs on the backend, it is YOUR error.
How different the frontend is. We have multiple browser enginges, none of them has a 100% knowledge of HTML, CSS and JS. And if they would, their knowledge and implementation would differ. There would be additional differences coming from the operation systems, especially according to the implementation of form controls and the communication with the accessibility layer.
I have a dream: it would be good, if all the browser vendors could concentrate on implementing the existing standards as perfect and interoperable as possible into all the existing browsers.
Safari is a pure joke in my eyes:
– New issues with every update.
– Partially/not implemented standards.
– Scroll issues.
– Bug reports closing with won’t fix.
– Inconsistencies between desktop and mobile.
– And the list goes on…
It’s basically the new IE11, our codebase is simply full with isSafari and if(getVersion()…) calls, -webkit- hacks.
Just as en example, their latest update (13) made our gradient layers come out of boxes with overflow:hidden. Solution: translateY(0)…
Couldn’t agree more with you on this one. I’ve had to come up with some solutions to Safari bugs in the past. It’s not terrible, but it does feel like it’s digressing into the IE11 territory. Considering I develop primarily on Windows it only amplifies the issue since it’s rather annoying having to use tools such as Browserstack, other emulators, and or using a Virtual Machine to run Safari 12+.
while I do agree that monopoly isn’t optimal sacrificing power for the sake of diversity is worse than sacrificing diversity for the sake of power
looking at you Mozilla
Chrome and Firefox are both funded by Google. And with Edge now using WebKit too, it seems like Google now has a monopoly on web standards. Now I’m not saying that this is a bad thing as I’m quite a fan of Google but paraphrasing you somewhat, “variety is the spice of life”.
if only chrome stands then good luck keeping up to all the stuff they come with every week which is still being discussed on TC39. and will be TC39 even worth any more? and what if you start developing a browser 10 years from now? how much stuff will you need to implement? what will your reference be? no thanks, google all the way does not compute for me
An important point is often missing, and that’s cost. Developing and operating an evergreen browser is extremely costly, and it’s a good explanation why fewer and fewer organizations can afford it.
In an interesting twist, we as developers who like to see feature after feature added to the technical specs contribute to driving that cost up. And, with that, to driving browsers out.
(It would be great if vendors could comment on that cost, whether it’s only in the millions, or straight in the billions. Specific numbers could help understand what maintaining a browser really means these days.)
Very good points you have highlighted! What does it mean that there is a lower engine diversity?
I think Edge switching over to a Chromium engine is a good thing. As was mentioned, the diversity is just a different scope. Microsoft have definitely stepped up their stances as to what goes into Chromium, and what goes into their own fork.
Also, as long as the companies that are a part of ECMA are pushing web standards, then the browsers are probably in safe hands.
Compare this what happened to IE and Microsoft. IE was proprietary, Microsoft had a very solid hold on browser share, and Microsoft didn’t contribute to the web standards very well. They did their own thing. IE failed really quick.
Whereas Chromium and Google are doing the opposite. Chromium is open sourced and Google is a big contributor for web standards. True Chrome does hold the browser share very good like IE back in the day, but the more important things to note is the open sourced software and contributing to web standards. Open sourced software means anyone not tied to Google can also contribute. And Google discussing web standards with other companies is encouraging.
A simpler vendor landscape is obviously good. But if Google is at the helm, how long before this becomes an anti-trust issue?
Pretty obvious that most browser developers choose Chromium as their engine. Apple does its own thing as Apple often does and has loads of money and people to develop WebKit on its own. Mozilla on the other hand should fear Chromium more because of Firefox’s dwindling market share. The biggest issue with Chromium browser dominating browser market is standards. Power in numbers as they say brings the ability for Chromium to set them not just adhere to them. The obvious elephant in the room is the combined engineering power of Microsoft and Google developing Chromium. Can Firefox team even mange to keep up with such a power house of engineers? This is probably Mozilla’s biggest fear and finding partners to help seems a reach right now. I would suggest to Mozilla to dump Gecko and moved to WebKit and work along with Apple in that engine development. Otherwise Gecko does seem to be the obviously loser in this.
Except… Mozilla’s engine is vastly superior to WebKit now. Good luck getting Apple to adopt Quantum and work together with Mozilla. I too have experienced the pain of “Safari is the new IE” many times.
I am just surprised more developers don’t hate on Apple for making every browser use WebKit on IOS. Maybe because most IOS users don’t even know that Edge, or Opera, or Chrome don’t use their native engine because Apple won’t allow it. Sadly it’s not much different with Android and considering how much mobile influences the web these days. We have some problems with this requirement. The other elephant in the room is how both Chromium and WebKit are considered open sourced but are mainly developed by major private companies like Apple, Google and Microsoft. Other than being considered open source in spirit are either engines really that open?