Yep. The only reason why Firefox, Safari, and eventually Chrome were able topple IE is because devs started writing predominantly for those browsers. Without that push IE would’ve lived on, because users don’t switch that kind of thing unless they really have to.
Devs often also have disproportionate sway over the technical choices of friends and family, which is where Firefox got much of its footing earlier on.
That's not really how I remember it. I remember everyone switching to Mozilla and Firefox because they had great features around bookmarks, themes, and extensions. Then I remember everyone switching to Chrome because it was so fast to launch.
Meanwhile, devs were still targeting IE because it was where the users were. It was totally preferable to develop for Chrome or Firefox, but I recall spending countless hours still getting that stuff to IE, because that's what customers were using.
Sure, developers helped speed along adoption, but I think the new browsers ultimately succeeded because they're better products for the customer.
We can see a common sentiment by developers on this thread that they mostly test on Chrome, because that's where users are. I don't think it's likely many developers put in the effort for making the experience of using Firefox better when Firefox had such few users.
Sometimes "customers" don't really hold that much power. For example, I have to use my YubiKey with AzureAD at work. This is broken on Firefox on Linux, but works on Chrome. I can't just not log on to my work email and such. I would have chosen something else than AzureAD, but here we are.
I hate having to use multiple browsers, but I still want to support Firefox and only use chrome whenever I depend on AzureAD and make it a point to complain about it. What good did that do? MS sure doesn't care about it. "Just use windows". Right.
I'd argue many "customers" could possibly be convinced to drop Chrome in favor of Firefox, I don't think they care as much as HN posters do about this subject. They just want a thing that works. But if half the sites don't work, for whatever reason, they won't be wrangling two browsers like me. They'll just use Chrome and call it a day.
So whose fault is it that sites don't support Firefox? 90% of my colleagues couldn't code to save their lives (it's not their job, granted). And the other 10% will just go for what's quicker / easiest to implement. "Everyone uses chrome? Testing on chrome, it is.".
Depends, many devs are too keen in using only Chrome and shipping desktop applications packaged in a Chrome shell, because "writing portable code is soooo hard.".
Many of whom only care about Safari, because contrary to Firefox, Apple gets to say Chrome doesn't own their platforms.
The Firefox foundation is the one who ceded power through poor decisions. Devs don't get to decide what users browse on. All users use chrome today and that's it.
Firefox had no choice in the matter of Chrome's dominance. Google controls the biggest web properties and has the most money to spend advertising and bundling it. Anti-trust has had no teeth in decades. The web was theirs for the taking.
Developing in Chrome doesn’t mean the end result doesn’t work in Firefox. Web standards are there for a reason. I develop in Chrome (by develop I mean the full interactive development cycle) but also check in Firefox and Safari once in a while. This post is explicitly about why people use Chrome’s devtools, so you’re just attacking a strawman.
I read it, and it’s exactly what I do — develop, test and debug in Chrome. Then I check the site isn’t broken in Firefox and Safari once in a while. It basically never is.
Would you mind spelling the difference a bit more clearly? The comment chain has another comment that the browsers developers actually develop for a specific browser (usually Chrome because larger userbase), and this choice developers make influences which browsers users like to use because websites supposedly work better on that browser. So there seems to be variation in implementing the standards you refer to.
I don't know much about browser diversity (Chrome and Firefox give near-identical experiences to me as a user), so I personally don't feel that the argument developers significantly influence users holds much water (of course facts don't care about my feelings which may be wrong). I think the only time I noticed a significant difference as a user was when Firefox didn't implement a certain download API allowing for large downloads like Chrome, and I only encountered that difference in using Mega (the upload service).
caniuse and MDN compat data is really good these days, so you usually don't even need to crack open Firefox to be able to decide whether a JS API or a CSS feature is portable. For instance, in the Mega case, I assume they use the FileSystem API (since they have to download a large encrypted blob to a staging area first), and it's very easy to check availability of that API on all major browsers. As long as you don't chase the latest standards or WICG proposals, your code is likely going to work across all major browsers.[1] As I said in another comment, I occasionally check whether my sites work in Firefox and Safari, and they're just fine almost all of the time.
It seems to me that some diehard Firefox fans assume that just because some sites don't work on Firefox, all developers have to dedicate special attention to Firefox or their sites will be broken. That's very far from truth.
[1] More care is needed for mobile Safari, which often imposes additional non-obvious constraints, but that's a separate topic.
Browsers are so similar these days, web standards are so well defined, I see little reason to code Chrome-only sites.
Having been through the IEs of the 90s/00s, I feel proud that we managed to scape what seemed an irreversible fate and a sense of responsibility to do whatever I can to help prevent it from happening again.
I’m not sure about WebGPU, but WebUSB was pushed through by Google without any regard at all for Mozilla’s and Apple’s concerns, so it’s not too surprising it’s a Chrome exclusive.
I know that, but this is often spun as a positive for Apple and it's not: it's an accidental side-effect of their own anti-competitive stance. If anything, it works as a fig leaf to Google's monopoly. Apple should stop their stupid policy, open their platform, and instead make it plain to antitrust authorities that Google needs reigning in.
Foolish dreamers anyone that thinks Chrome being open source makes a difference in Google's Web domination masterplan.
US is one country among 195, and the other 50%, which are mostly from Safari, are one of the reasons why the Web isn't yet fully assimilated as ChromeOS.
It’s foolish to think it doesn’t. Blink was a fork of WebKit. There’s nothing stopping someone from forking it either. Certainly a lot easier than reverse engineering IE bug for bug.
The US is the largest economy in the planet and home to most tech companies and all browser engine makers. Calling it “one country among 195” is dodging the issue.
That’s not to say that Google isn’t on a quest to conquer the Web and that Chrome isn’t incredibly popular. It’s just that comparing it to IE is a bridge too far.
With ESPHome[1] I could edit, compile and up upload firmware to my ESP device directly in my browser without installing any tools.
I had planned on using VSCode, but I got some extension conflicts due to some other extension (Platform.io IIRC).
I had the similar reaction when first reading about WebUSB as you, but after seeing how smooth it was, I admit I thought it was pretty darn neat. It drastically lowers the barrier of entry for those who aren't that technical.
For some reason, new Firefox windows can only be launched from the same environment from which the first window has been started. Even the same user who started FF cannot launch a new window from a new shell. That constantly interferes with my workflow.
Example: Say firefox has been started from the Destop already and now I want to start a new Firefox window from a root terminal:
su desktopuser firefox
It does not work. It gives me "Firefox is already running, but is not responding.".
I don't mean this as a dig, but I am curious to know what your use case is for launching new browser windows from different environments is. Something along the lines of remote debugging?
It works if you use -E both when leaving the user environment and when reentering it. There's something in the environment variables that needs to be set for the new firefox instance to communicate with the old one to pass along the new window command, and using -E both times carries it along.
Also ssh is somehow able to load this from somewhere without carrying it along. You can "ssh desktopuser@localhost" to restore it, though this does mean you need to set "DISPLAY=:0" manually.
No it's from a new environment. I had to set DBUS_SESSION_BUS_ADDRESS and DISPLAY and also allow it with xhost then it worked fine. I don't know how to do that with wayland though.
One of the things that FF's devtools are def. lacking is the ability to jump to a CSS variable's declaration. I keep on jumping back to Chrome just to be able to resolve that.
RIP Firebug. Didn't keep a journal to remember the exact features or reasons but I switched after Firebug went away.
Also performance mostly. My site is slow, running in debug mode is slow, and using dev tools is slow. Combine all 3 and it makes a difference. Prob some little features to that are in different places. Firefox when I need to edit and resend a request though.
There was a particular way firebug put web requests (ajax) into the console tab that I really liked, that helped with seeing the order things occurred that I remember missing when it went away.
To have more competition in web devtools, we need to simplify the web standard so more browser can appear instead of forcing some new fancy API on our almost monopoly.
When I say “web standards”, I mean official W3C standards, and I think we should be actively hostile to corporate attempts to take over that process.
But I disagree that we shouldn’t also try to accommodate quirks. That’s why we have `Array.flat` instead of `Array.flatten` — the standards body decided to come up with a slightly atypical name for the feature rather than breaking a bunch of websites.[1] Our collective history is too valuable for us to be breaking stuff just to make engineers’ lives easier.
> we should be actively hostile to corporate attempts to take over that process.
Hard agree. I've become convinced their power to ignore, replace, and EEE standards requires legal intervention. So far it seems only randomized browser ballots can effect any meaningful change. Otherwise websites will just build for the dominant browser regardless of any agreements among them.
> Our collective history is too valuable for us to be breaking stuff just to make engineers’ lives easier.
I'd argue that software standards make it harder for everyone to write a "history". How many people simply gave up on their own websites and outsourced their work to an entity they do not control the actions of?
How much of that fancy web standard is about optional visual? What are we really getting from it? Would you consider a new API for drawing rectangles "progress"?
Your `Array.flat` example may make sense, but only because we are way too deep to even consider alternatives. We have mostly no idea how these standards will evolve and decided to keep on putting band aids to remain afloat.
The best way to keep information accessible is to make it understandable by a human without mandatory automation. Don't you find it horrible that all the information websites can provide you is actually dependent on a thousands pages long spec? Is it really the only solution you can think of?
The resiliency of the web is mostly equivalent to papyrus, if not worse.
A simpler spec means more competition, which is more sustainable than 50 standardized APIs. More competition means having an easier time finding the perfect browser (or even make your own).
I do not know about Gemini but the problem with current minimal formats is that they cannot evolve without change to the spec, they lack emergence. And therefore when you want to expand on it, you need to add complexity to the spec, not your code.
One of the idea I had was to make all websites provide natural language text, without any standardization (send whatever text you want).
Which would have these benefits:
- Ease website development, your goal is to make the text as simple as possible to understand for a human.
- (also means that website won't have the luxury to send unnecessary data anymore)
- More performant.
- Literally cannot break as it does not depend on any standard. Text will remain understandable forever.
- You can have an infinite amount of browsers, some may only render the raw text, some may render the text and give you very fast tips as to how you should render it, and others dedicated to specific disabilities.
- You can have a working browser in a matter of hours. And the way you expand on it is independent from how the server operates.
- No fancy standard can appear to break this simplicity, as many people would depend on the text being unopinionated.
- Can still support anything the web currently does, but tracking without contentment will become harder. As users would have a deeper understanding of what the website actually is, its text is on plain sight.
This isn't how anything works. If you want a better alternative compiler, you build a new compiler. You don't build an entirely new operating system that includes a new compiler. Want a better grep? Make a better grep, not a whole new shell. Forcing everybody to make their own entire browser in order to provide an alternative devtool is ... madness? What does making a devtool have to do with making a browser? Why should making one require making the other?
It is how it works. What's your suggestion for the fancy devtools API? Beg Google?
Making the implementation of the web standard simpler means increasing the options available, meaning more chance of finding a devtools you appreciate and possibly modify.
APIs/Standards deprecate. It is not even a question of "if" but "when". Lowering the barrier of entry is much more sustainable than engineering a whole new spec every time we encounter a problem.
Another tool you might have heard of that uses the Chrome Devtools Protocol are NodeJS APIs for remote-controlling browsers: Puppeteer (from Google), and Playwright (from Microsoft). You can access the underlying CDP connection from Playwright: https://playwright.dev/docs/api/class-cdpsession
Chrome extensions can add tabs to the Chrome devtools built into the browser. So, a competitor dev tool can be distributed as a Chrome extension and opened with the devtools keyboard shortcut. A user can “switch” to the alternative devtools by put the tabs it adds first and hiding the built in devtools tabs.
It simply isn't. Just look at how Linux works. Combining tools over agreed upon interfaces. If you want to replace one tool with another, you don't need to change every other tool and have knowledge of every other problem domain. What you're suggesting is replacing everything, which makes no sense and it's not how anybody does anything in the real world.
We are only talking about the browser here, where the few choices come from the extreme complexity of the spec.
However, I do believe the same for operating systems and application binary in general. Nobody would ever complain about X or Y operating system if writing your own was sufficiently easy.
Not saying that we can simplify operating systems the same way we can browser, but we can make it easier to start from a clean base and quickly support Windows, Linux, macOS, Android & iOS app binaries. As an example, how hard is it to interpret an android app binary? Is this complexity really necessary? Couldn't we depend on languages with more emergent behaviors to ease the implementation of VM/interpreters?
Just to be clear, I am NOT and have never said that we should all write our own browser or OS, but that simplifying them would result in more choice and no more begging from users to support X or Y features (which happen in every single standardized/monopoly situation)
> which makes no sense and it's not how anybody does anything in the real world.
In the real world you have people begging everywhere for features to be implemented in software they have no control on. Software standards have never solved any issue, they increase the barrier of entry and make users powerless.
I don't see how that makes sense. Writing an API is less work than writing the devtools (which needs some kind of API anyway internally). So without a universal API, any serious new browser would take more effort to build.
Designing an API is a ton of work, especially if you care about backward compatibility (otherwise you may as well use that internal API). And at some point will be deprecated for removal.
Without a standardized way of writing devtools - assuming the web standard is overall simplified - you can expose a more specialized API without the baggage associated with standards, break it every so often, and make it as easy as possible for developers (potentially even users) to port other devtools to it.
I believe that instead of finding the "universal API", we should embrace the fact that there will be 15+ of them, and therefore simplify the porting process.
There kind of is - there’s the extensions API. Extensions can add new tabs to the existing devtools (eg redux-devtools, react-devtools do this). Plus you could conceivably use content scripts and an extension page running in a popup window to make a whole alternative ‘devtools’ (which is roughly how Firebug worked). I imagine you wouldn’t be able to do anything like the Network tab though, as I don’t think extensions can monitor requests, and almost certainly can’t do things like throttling bandwidth etc. Thinking about it, I guess there’s quite a lot that modern devtools does you couldn’t do with an extension.
Must join the choir and say that eventhough I have been a die hard FF fan, its gotten to the point of an impending divorce if performance doesn’t get better. I find myself switching to chromium more and more often. And then there are the extensions, that I sometimes can’t find for Firefox. That’s a minor annoyance than anything else though.
There are also a bunch of things that keeps me with FF. multi container tabs is one of my most loved ones. But I simply don’t get why the Team does make that feature even better. Like making it much easier to distinguish which container tab I am in. And adding even more customisability pr container-type.
Regarding DevTools, I really do t think I have a strong preference at all. But the stronger/more consistent performance the DevTools in chromium comes out slightly ahead.
For me it’s the overall experience which makes it a close race
I don’t think that’s true for devtools. I use FF devtools ever day, and it frequently crashes. Even the view source page has horrible performance issues when using cmd+f.
Whatever. I just keep using Firefox on Linux, Windows and MacOS for browsing the web and development. Haven't noticed any impediments with the latter. Actually, as alluded in another comment here, I recently learned to modify requests inside FF so I didn't need to start Postman for just a simple test.
currently FF has comparable devtools, but back in the day, FF was lacking a lot of features, like websocket inspection which was implemented around 2019 [1] where in chrome you could do that since 2011 via net-internals (i'm unable to find the date when it was implemented in devtools). so I think because of thing like these, the popularity of chrome devtools was just getting bigger and bigger.
100 comments
[ 1.7 ms ] story [ 189 ms ] threadDevs often also have disproportionate sway over the technical choices of friends and family, which is where Firefox got much of its footing earlier on.
Firefox has no compelling reason to exist for the average user unless privacy is a really high priority for you.
Meanwhile, devs were still targeting IE because it was where the users were. It was totally preferable to develop for Chrome or Firefox, but I recall spending countless hours still getting that stuff to IE, because that's what customers were using.
Sure, developers helped speed along adoption, but I think the new browsers ultimately succeeded because they're better products for the customer.
That, in a large part, was on web developers, making sure the user who took the leap had a good time on arrival.
Sometimes "customers" don't really hold that much power. For example, I have to use my YubiKey with AzureAD at work. This is broken on Firefox on Linux, but works on Chrome. I can't just not log on to my work email and such. I would have chosen something else than AzureAD, but here we are.
I hate having to use multiple browsers, but I still want to support Firefox and only use chrome whenever I depend on AzureAD and make it a point to complain about it. What good did that do? MS sure doesn't care about it. "Just use windows". Right.
I'd argue many "customers" could possibly be convinced to drop Chrome in favor of Firefox, I don't think they care as much as HN posters do about this subject. They just want a thing that works. But if half the sites don't work, for whatever reason, they won't be wrangling two browsers like me. They'll just use Chrome and call it a day.
So whose fault is it that sites don't support Firefox? 90% of my colleagues couldn't code to save their lives (it's not their job, granted). And the other 10% will just go for what's quicker / easiest to implement. "Everyone uses chrome? Testing on chrome, it is.".
Many of whom only care about Safari, because contrary to Firefox, Apple gets to say Chrome doesn't own their platforms.
Editing to not extend the thread: the comment says they do NOT test on anything than Chrome. You maybe do that, the top comment author doesn't.
I don't know much about browser diversity (Chrome and Firefox give near-identical experiences to me as a user), so I personally don't feel that the argument developers significantly influence users holds much water (of course facts don't care about my feelings which may be wrong). I think the only time I noticed a significant difference as a user was when Firefox didn't implement a certain download API allowing for large downloads like Chrome, and I only encountered that difference in using Mega (the upload service).
It seems to me that some diehard Firefox fans assume that just because some sites don't work on Firefox, all developers have to dedicate special attention to Firefox or their sites will be broken. That's very far from truth.
[1] More care is needed for mobile Safari, which often imposes additional non-obvious constraints, but that's a separate topic.
I like Firefox but it just not popular. And getting a few more devs to use it will not help.
Having been through the IEs of the 90s/00s, I feel proud that we managed to scape what seemed an irreversible fate and a sense of responsibility to do whatever I can to help prevent it from happening again.
Thanks to Chrome worshipping, there is no Web anymore, Apple is the only wall preventing Web developers to replace Web with ChromeOS on their CV.
Doesn't matter how good or evil they happen to be.
No one cares about Firefox, apparently not even the large majority of HN folks.
Apple is as bad for the web as Google. They refuse to allow other engines on their mobile, money-making OS.
Chrome is open source and on mobile in the US is close to 50%.
There are similarities, but it’s far from the same situation.
US is one country among 195, and the other 50%, which are mostly from Safari, are one of the reasons why the Web isn't yet fully assimilated as ChromeOS.
The US is the largest economy in the planet and home to most tech companies and all browser engine makers. Calling it “one country among 195” is dodging the issue.
That’s not to say that Google isn’t on a quest to conquer the Web and that Chrome isn’t incredibly popular. It’s just that comparing it to IE is a bridge too far.
With ESPHome[1] I could edit, compile and up upload firmware to my ESP device directly in my browser without installing any tools.
I had planned on using VSCode, but I got some extension conflicts due to some other extension (Platform.io IIRC).
I had the similar reaction when first reading about WebUSB as you, but after seeing how smooth it was, I admit I thought it was pretty darn neat. It drastically lowers the barrier of entry for those who aren't that technical.
[1]: https://esphome.io/
Example: Say firefox has been started from the Destop already and now I want to start a new Firefox window from a root terminal:
It does not work. It gives me "Firefox is already running, but is not responding.".https://megous.com/dl/tmp/b82a40ffb92bb11b.png
Console says:
It's been a few years since I've tried, so I might be forgetting the exact circumstance, but there was some issue like that.
Depending on your use case Docker may be a solution.
I just want to trigger Firefox to open a new window. Just like it does when I press CTRL+n.
I'd sacrifice some karma but I am hesitant so go see yourself out and off to https://stackoverflow.com instead.
Also ssh is somehow able to load this from somewhere without carrying it along. You can "ssh desktopuser@localhost" to restore it, though this does mean you need to set "DISPLAY=:0" manually.
You probably inherited the environment from the process that started FF.
How did you try to do it from a new environment?
-P asks me to select a profile. That's not what I want. I simply want a new Firefox window.
I just want Firefox to launch a new window. No matter if there already are Firefox windows active or not.
Chromium has no problem doing so. So that is the reason I use Chromium and not Firefox.
Also performance mostly. My site is slow, running in debug mode is slow, and using dev tools is slow. Combine all 3 and it makes a difference. Prob some little features to that are in different places. Firefox when I need to edit and resend a request though.
To have more competition in web devtools, we need to simplify the web standard so more browser can appear instead of forcing some new fancy API on our almost monopoly.
When there were legally enforced browser ballots they had to ... and they did.
But I disagree that we shouldn’t also try to accommodate quirks. That’s why we have `Array.flat` instead of `Array.flatten` — the standards body decided to come up with a slightly atypical name for the feature rather than breaking a bunch of websites.[1] Our collective history is too valuable for us to be breaking stuff just to make engineers’ lives easier.
[1] https://developer.chrome.com/blog/smooshgate/
Hard agree. I've become convinced their power to ignore, replace, and EEE standards requires legal intervention. So far it seems only randomized browser ballots can effect any meaningful change. Otherwise websites will just build for the dominant browser regardless of any agreements among them.
I'd argue that software standards make it harder for everyone to write a "history". How many people simply gave up on their own websites and outsourced their work to an entity they do not control the actions of?
How much of that fancy web standard is about optional visual? What are we really getting from it? Would you consider a new API for drawing rectangles "progress"?
Your `Array.flat` example may make sense, but only because we are way too deep to even consider alternatives. We have mostly no idea how these standards will evolve and decided to keep on putting band aids to remain afloat.
The best way to keep information accessible is to make it understandable by a human without mandatory automation. Don't you find it horrible that all the information websites can provide you is actually dependent on a thousands pages long spec? Is it really the only solution you can think of?
The resiliency of the web is mostly equivalent to papyrus, if not worse.
Look, I don’t like how complex web browsers are any more than you do. But it’s the situation we’re in today.
We have no reason to indefinitely use our web.
I do not know about Gemini but the problem with current minimal formats is that they cannot evolve without change to the spec, they lack emergence. And therefore when you want to expand on it, you need to add complexity to the spec, not your code.
One of the idea I had was to make all websites provide natural language text, without any standardization (send whatever text you want).
Which would have these benefits:
- Ease website development, your goal is to make the text as simple as possible to understand for a human.
- (also means that website won't have the luxury to send unnecessary data anymore)
- More performant.
- Literally cannot break as it does not depend on any standard. Text will remain understandable forever.
- You can have an infinite amount of browsers, some may only render the raw text, some may render the text and give you very fast tips as to how you should render it, and others dedicated to specific disabilities.
- You can have a working browser in a matter of hours. And the way you expand on it is independent from how the server operates.
- No fancy standard can appear to break this simplicity, as many people would depend on the text being unopinionated.
- Can still support anything the web currently does, but tracking without contentment will become harder. As users would have a deeper understanding of what the website actually is, its text is on plain sight.
Making the implementation of the web standard simpler means increasing the options available, meaning more chance of finding a devtools you appreciate and possibly modify.
APIs/Standards deprecate. It is not even a question of "if" but "when". Lowering the barrier of entry is much more sustainable than engineering a whole new spec every time we encounter a problem.
The Chrome devtools work by connecting to the browser using the Chrome DevTools Protocol. You can find a description of it here: https://chromedevtools.github.io/devtools-protocol/
Another tool you might have heard of that uses the Chrome Devtools Protocol are NodeJS APIs for remote-controlling browsers: Puppeteer (from Google), and Playwright (from Microsoft). You can access the underlying CDP connection from Playwright: https://playwright.dev/docs/api/class-cdpsession
Chrome extensions can add tabs to the Chrome devtools built into the browser. So, a competitor dev tool can be distributed as a Chrome extension and opened with the devtools keyboard shortcut. A user can “switch” to the alternative devtools by put the tabs it adds first and hiding the built in devtools tabs.
Although the rest of my message remains correct, if writing a dummy browser only took a few hours/days, nobody would ever ask for new APIs.
However, I do believe the same for operating systems and application binary in general. Nobody would ever complain about X or Y operating system if writing your own was sufficiently easy.
Not saying that we can simplify operating systems the same way we can browser, but we can make it easier to start from a clean base and quickly support Windows, Linux, macOS, Android & iOS app binaries. As an example, how hard is it to interpret an android app binary? Is this complexity really necessary? Couldn't we depend on languages with more emergent behaviors to ease the implementation of VM/interpreters?
Just to be clear, I am NOT and have never said that we should all write our own browser or OS, but that simplifying them would result in more choice and no more begging from users to support X or Y features (which happen in every single standardized/monopoly situation)
> which makes no sense and it's not how anybody does anything in the real world.
In the real world you have people begging everywhere for features to be implemented in software they have no control on. Software standards have never solved any issue, they increase the barrier of entry and make users powerless.
Without a standardized way of writing devtools - assuming the web standard is overall simplified - you can expose a more specialized API without the baggage associated with standards, break it every so often, and make it as easy as possible for developers (potentially even users) to port other devtools to it.
I believe that instead of finding the "universal API", we should embrace the fact that there will be 15+ of them, and therefore simplify the porting process.
aka How to tell that you don't design APIs without telling that you don't design APIs.
There are also a bunch of things that keeps me with FF. multi container tabs is one of my most loved ones. But I simply don’t get why the Team does make that feature even better. Like making it much easier to distinguish which container tab I am in. And adding even more customisability pr container-type.
Regarding DevTools, I really do t think I have a strong preference at all. But the stronger/more consistent performance the DevTools in chromium comes out slightly ahead.
For me it’s the overall experience which makes it a close race
[1] https://hacks.mozilla.org/2019/10/firefoxs-new-websocket-ins...