I find that these days the browsers are all about the same performance-wise and it ends up not mattering much. PCs are so fast that it's very rarely the browser that is the bottleneck. Cool that they're still working to keep it snappy though.
I will say mobile is a bit different. I prefer mobile browser to apps when possible so I can have ad-blocking, but some websites run like complete garbage on mobile browser. They're so slow it's almost unusable. I'm almost 100% certain that's not on the browser itself though.
In my experience speed differences between browsers are indeed negligible on properly engineered sites/apps. Every so often I run into one that was only ever developed for and tested against Chromium and has major performance issues under Gecko and/or WebKit. Some of it might come down to poorly pruned or outdated polyfills, which in many cases are filling in for features that those engines gained support for quite some time ago.
I wish there were something that could thwart the “Chromium by default” assumption at large amongst devs, because it’s making the web worse than it needs to be.
I daily drive Firefox serving a Chrome User-Agent, out of frustration with a couple applications that work perfectly on Firefox, but because they didn't test on Firefox, they just assume it won't work and block my connection (If there's any Devs at Snapchat who wants a free ticket completion, you can "Add Firefox support" by deleting your UA check)
I noticed this exact thing. While a lot of sites worked perfectly fine when I was informing them I was using Firefox, when I started lying, they ran faster. Drove me nuts.
Frontend Devs: If your code reads the user-agent string for any reason but logging/spying, you're doing it wrong.
This is the natural consequence of the notion at large that non-Blink web engines are lightyears behind, which was never true in the strictest sense and has only become less true with time as the gap has narrowed. Besides that, even if you’re relying on some feature that Chrome has implemented as an early draft spec thing or something, maybe consider toggling off that one feature instead of blocking off the whole app.
To clarify, I didn't mean don't check if the feature you want to use exists on the user's browser. I meant don't come to that conclusion using User-Agent strings. JavaScript makes if very easy to check if a method you want to use exists or not: just check if the function is undefined.
If you do it the right way, if/when another browser implements the feature you used, suddenly you support that browser, with no code changes. If you check UAs, then you need to keep tabs on browser updates and manually update your website when features get added to browsers, and you need to check what version people are using because maybe it's out of date, it's a whole thing.
What drives me nuts is that the right way is the easy way.
We’re in full agreement here, all I was saying is that the menality that leads to user agent sniffing is likely the idea that engines that aren't Blink are so incapable and will break the site/app so badly that it’s better to just rule out their usage altogether. Checking on a per-function basis (or alternatively, just not insisting on using bleeding edge features in the first place) is absolutely the way to go about avoiding brokeness.
The past few projects I've done, I've made some effort to just not polyfill anything, it's always too easy to wind up with fills for things long supported in every major browser for the past 3-5 years.
On the flip side... if you're running something bespoke relying on an older JS engine, it's becoming harder to find pure polyfills/shims that aren't a tangled mess relying on DOM specific features.
While there are some newer features I don't mind seeing early, I've mostly just avoided touching some of the more recent features for now, only to avoid the mess that are the current state of fills.
> I wish there were something that could thwart the “Chromium by default” assumption at large amongst devs...
I don't think that is possible. It used to be that lazy devs assumed people were on IE, these days lazy devs assume people are on Chrome. In the future if there is a new browser with a majority of the market, lazy devs will assume people use that browser. The problem isn't any one browser, it's that some people are lazy and seek out shortcuts rather than doing things the correct way.
> Every so often I run into one that was only ever developed for and tested against Chromium and has major performance issues under Gecko and/or WebKit
This feels generally true but there's some exceptions. For example: I use Firefox as my daily driver, but if I want to watch more than one Twitch stream in parallel I'm forced to use Chromium. Opening multiple Twitch streams on Firefox grinds the browser to a halt.
As a counter example, I remember that I needed to do big reviews in GitHub using Firefox because Chrome would slow to a crawl in the Files tab in GitHub, while Firefox was just as fast as it was with small reviews.
I don't think this is an issue anymore, but it shows that a few things have completely performance in different browsers.
I wonder how experiences can differ so much with the same program. I've never had an issue having 3-5 twitch streams open at the same time, across multiple computers and multiple FireFox versions.
I will say mobile is a bit different. I prefer mobile browser to apps when possible so I can have ad-blocking, but some websites run like complete garbage on mobile browser. They're so slow it's almost unusable. I'm almost 100% certain that's not on the browser itself though.