What you, as Web developers, can do, is use Firefox while developing your site to ensure it really works well on non-Chromium browsers. And do your level best to encourage your developer friends to do the same. If they're on Mac and would rather use Safari, that'll do too.

Then, every time you see any site or any Web developer satisfied with "works in Chrome", do what you can to let them know that's not acceptable. In a polite, loving, and extremely firm manner of course.

A decent idea of course, but you are going to run in to the same issue as everybody else who tries that: unless Firefox has a significant market share, it is just not worth throwing resources after it.

What you can do is develop automatic filters to make chrome specific CSS prefixes general, etc. Those are probably worth using since a few hours/days of engineering time easily is worth the larger market share.

Firefox already implements a bunch of -webkit prefixed features for compatibility reasons. Are there specific Chrome-only features that aren't yet supported that you think should be? If so, file Firefox bugs!

Gotta help get the user base bigger

I'm still working out the details, but when I get to the point where I'm selling software on my site, I plan to offer small discounts (maybe a dollar) to anyone I detect on a Firefox browser. I'm considering doing the same thing for Ad Blockers.

I know I can't convince normal people to care about the web ecosystem, and yelling at users about behavior is just another way to annoy them. I like the idea of having a small (likely secret) list of browser behaviors that reward users, rather than punishing them. It makes it feel more like a game or a cheat code or easter egg to me than a heavy handed lecture.

If someone is visiting on an unconfigured browser, or something I don't recognize, they won't get an error message or performance hit or any notification at all. But if someone visits and they're doing the right thing, maybe they get a "good job" and a discount or extra download. And then hopefully if they recommend my software to a friend they'll also let them know about the "secret."

> I like the idea of having a small (likely secret) list of browser behaviors that reward users, rather than punishing them. It makes it feel more like a game or a cheat code or easter egg to me than a heavy handed lecture.

While that is nice, you run the risk of nobody noticing.

For some strange reason, I wanted to comment to your post and you didn't have a reply button initially. I had to refresh and then is showed up. Huh, never seen that behavior on HN.

Agreed, but the point is specifically not to nag people -- I don't think that works for Open Source communities; people just get mad. So yeah, tradeoffs.

To put it specifically in advertising terms, I'm also optimizing for conversion rate, not impressions. I'll make a (light) prediction that the few people who know in advance about a system like this will be more likely to try out a browser to save a dollar than they will be to switch a browser to stop a negative experience they're already in.

And on a less practical note, I think I'm OK with fewer people discovering something like this if the ones who do notice end up feeling really good. I want someone's reaction to be, "You noticed! You're right, I am awesome for using an ad blocker!" I want the feeling to be, "sometimes people don't hate me for doing this, and sometimes doing the right thing has benefits."

> you didn't have a reply button initially.

HN rate-limits replies to recent posts.

I like this idea. You could perhaps add a small logo that says "optimized for Firefox and AdBlocked browsers".

When the reply button is hidden - to reduce arguments and "over-posting" - you can click the date to go to a page only showing that comment, that page always has a reply option.

It's largely proven by decades of experience at this point that you cannot make the average software user care about ideological concerns. Especially if you use terms like libre that don't makes any sense to people that haven't drunk the FOSS koolaid.

Ok, then it could be played a little harder, for example by introducing a (small) performance penality for visitors that use chrome.

> Ok, then it could be played a little harder, for example by introducing a (small) performance penality for visitors that use chrome.

Good luck convincing your product owner of the necessity of that change. Most large enterprises won't do something like this.

That's not the place to target such a change, if anyone's to do it.

If there's the support of a major maintainer of a popular library, merging changes which incrementally incur larger performance penalties in Blink may be more effective.

If there's no support from a major maintainer, then simply writing contributions which are largely tested in firefox for performance but are tested in Blink for mere functionality should succeed over time in inducing the same.

In the end, the libraries are lock-in for larger SaaS providers far more than they might be aware, and if such changes start making it into e.g. React, there's not all that much that many product teams can do to work around it other than replying via support channels that Firefox seems to take less of a performance penalty.

That's the black hat in me talking. Resuming white hat status now.

No need to blackhat; rather than intentionally degrading it for one browser, just optimize for the other. I'm reasonably confident that there are areas where FFx is more performant; use them.

> If there's the support of a major maintainer of a popular library, merging changes which incrementally incur larger performance penalties in Blink may be more effective.

That library will get forked by industry.

If its license does not permit forking, it's incredibly unlikely that it can get traction in the first place.

You could just add more intrusive ads to your site. The site owner will be thrilled, and the users not thrilled at all. It would work very well for all concerned!

Well, apparently, all you'll need to do is put ads on your site and people will probably start switching ;)

I really do appreciate the kind of symmetry behind the idea of "Google ads for Google Chrome users, freedom from ads for free software users"

Ignore the "proven by experience" pessimist comment.

Yes we can, go ahead and do it. This is a "Do not do X" nudge not a "Do Y" command.

It is proven by thousands of years of history that humans are best served by negative commandments.

Most sites and content are monetized by ads. Your suggestion is to slow down the browser that allows those ads to exist? What publisher would accept this?

Then you simply lose users. How do they know Chrome is the reason your site is slow when others’ aren’t?

Well, if we're fighting fire with fire, they know because you put in a little dialogue on the page that says, "switch to Firefox for better performance".

We have that already! Except it goes the other way; using non-Chrome on Google properties gives you a slightly worse experience. YouTube on Firefox desktop is still terrible.

> It could say something like "today is free web day, upgrade your browser to Firefox or any other libre browser"

Love it!

I'd suggest a small change: It could say something like "today and every other day is free web day, upgrade your browser to Firefox or any other libre browser"

Huh, developers using electron and/or whole NodeJS/ Javascript ecosystem for their products are already causing big annoyance for users.

If there were whole bunch of conscientious developers we would not be in place where browser engines embedded or otherwise would be the most dominant way to deliver services or products to users.

The market clearly wants a cross platform GUI runtime.

Java didn’t cut it. Neither did Tcl/GTK/Wxwidgets.

Web apps won because of universality and zero touch deployment. Nothing to install, it just works (mostly).

Platform-native apps simply doesn’t achieve the major “it just works” goal, and always havw their own compromises.

HTTP status code 452: Unavailable for ideological reasons.

You could make use of features that work in Firefox but don't yet work in Chrome, such as SVG favicons and position: sticky (Chrome supports but only on th elements)

There's probably a way to compile a list of such features from caniuse data.