Why do people seem to prefer Chrome's devtools over Firefox's? | Hacker News Reader

Why do people seem to prefer Chrome's devtools over Firefox's?

old.reddit.com

35 pointsthunderbong96 comments

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.

Can you modify and resend a request in Chrome yet?

You can copy the request as it's equivalent fetch call and run it in the console with changes

In the next version: https://www.theregister.com/2023/08/17/chrome_117_developer_...

I develop, test, and debug on browsers that my users are using, and that ain't Firefox.

Are you comfortable handing Google the power to dictate the future of the Internet?

It's the customers handing power to google, not the devs.

It’s both, however, developers have a disproportional amount of power to tip the balance.

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 because Firefox was better then IE. It felt better to use. It was faster.

Firefox has no compelling reason to exist for the average user unless privacy is a really high priority for you.

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.

Firefox was a better product because it was faster, had tabs, etc and it generally rendered pages as expected.

That, in a large part, was on web developers, making sure the user who took the leap had a good time on arrival.

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.

It's both, as in a vicious circle.

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.

Of course, Firefox users may just skip your sites because they don't work in FF...

All none of them? All none users?

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.

Perhaps you should read the comment I'm replying to?

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 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.

Thank you for the thorough answer! Learned something new today.

Even if they didn't work, which they do, that would be a neglectible amount of users.

This is the correct answer. You look at your stats and put your time where it is needed.

I like Firefox but it just not popular. And getting a few more devs to use it will not help.

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.

Try to use WebUSB or WebGPU on Firefox.

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.

So it isn't as well defined as the parent was making it.

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.

That is not true, two harmful environments does not make either one a saviour, they are simply making web development worse.

Sorry to break it to you, without Apple, Google would have won already.

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.

Even if the enemy of my enemy is my friend, it doesn't need to be my best friend.

Apple is as bad for the web as Google. They refuse to allow other engines on their mobile, money-making OS.

You have completely missed the point they’re making to you: that refusal, however bad, is the only reason Chrome is not overwhelmingly dominant.

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.

WebGPU is fairly recent and WebUSB is in the category of “why would I ever want my browser to access USB”, for me.

Both aren't supported by FF, and I can remember of other examples, that for all practical purposes make Chrome the new IE.

IE had 95% market share at some point and was closed source.

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.

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.

Sure, keep thinking that way, we all know how Brave is going to take over.

Lovely contribution to the conversation. Thanks.

> why would I ever want my browser to access USB

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/

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.

What, this doesn't work in FF?

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.

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

Firefox has been faster than Chrome for many years now.

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.

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.".

Use --new-instance.

Gives me the exact same behavior:

    Firefox is already running, but is not responding.

Have you tried it?

Perhaps you need a different profile? (Not tested)

Yeah, same here. Worked fine in the past.

https://megous.com/dl/tmp/b82a40ffb92bb11b.png

Console says:

    [GFX1-]: glxtest: ManageChildProcess failed
    [GFX1-]: glxtest: libEGL initialize failed
    [GFX1-]: glxtest: X error, error_code=2, request_code=152, minor_code=3

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?

Just my command line tool telling me "Now look at the following page" and open a browser window with a url.

I'm not the GP, but for me it was an issue while wanting FF open for regular use and debugging, and another to run for automated feature tests.

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.

I think that would mess up your user profile if two instances tried to handle it at the same time.

Depending on your use case Docker may be a solution.

I don't want "two instances".

I just want to trigger Firefox to open a new window. Just like it does when I press CTRL+n.

Ah, I see now. Try: Try sudo -i -u $user firefox or sudo -E -u $user firefox ?

Both don't work. Why don't you try before you post?

I am working from memory, on my smartphone in public transit in a heatwave.

I'd sacrifice some karma but I am hesitant so go see yourself out and off to https://stackoverflow.com instead.

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.

This does it for me:

    firefox --new-window google.com

No, that does not work from a different environment.

You probably inherited the environment from the process that started FF.

How did you try to do it from a new environment?

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.

You may need --no-remote and/or -P

--no-remote seems to have no effect

-P asks me to select a profile. That's not what I want. I simply want a new Firefox window.

You may need to combine them like "Firefox --no-remote -P myotherprofile

I don't have (nor want) another profile.

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.

That does seem to be a quirk of Firefox profiles. You could workaround with a secondary profile that uses Firefox Sync to make them nearly equivalent.

Because they're used to it.

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.

[1] https://hacks.mozilla.org/2019/10/firefoxs-new-websocket-ins...

Why isn't there an API for writing devtools, so that we can have some more competition in this space?

We need less API/standard, not more.

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.

There’s no way to simplify web standards without breaking existing websites.

Websites should be built based on widely accepted standards, not quirks or monoculture 'standards'.

When there were legally enforced browser ballots they had to ... and they did.

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.

[1] https://developer.chrome.com/blog/smooshgate/

> 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.

What solution can you think of that doesn’t involve breaking any existing websites?

Look, I don’t like how complex web browsers are any more than you do. But it’s the situation we’re in today.

There is none, but we should have a transition period to make a simpler web spec, entirely immutable (to ensure no future bloat).

We have no reason to indefinitely use our web.

Okay, but “a simpler spec” is not a compelling reason to switch to or build for another one. There’s a reason no one uses Gemini.

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.

There’s already a DevTools API, no need to beg.

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.

My bad then, I stand corrected.

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.

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.

> Writing an API is less work than writing the devtools

aka How to tell that you don't design APIs without telling that you don't design APIs.

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.

Reply on news.ycombinator.com