If you can isolate that DOM performance bottleneck or point me to a live example, I'm happy to pare it down to a minimal test case and make sure it gets fixed.

(We have some enormous architectural changes inbound which should help, but I'd still love to make sure we have a test to prevent regressing)

unfortunately for Firefox, performance issues are a case of death by a thousand cuts.

Here's a product that I'm working on

https://www.ux-app.com/dev/editor?m=trial

In Chrome it's buttery smooth on any decent computer made in the past 5 or 6 years. In Firefox it's usable on a powerful computer, but notably worse than Chrome.

On an under powered laptop Chrome is still very usable, not quite 60fps, but probably 30-40fps on moderately complex designs.

Firefox is a choppy mess on low end hardware.

This is a recurring issue with Firefox. It's just ok for regular web browsing, and it's a hot mess for any web app that needs to do any moderately taxing DOM manipulation.

As much as I love Firefox, it's just leagues behind Chrome in regard to performance.

That's a pretty niche issue though, Firefox is much faster web browsing and uses far less resources than Chrome.

Impressive app.

Thanks :)

So long as my web browser is competitive when web browsing I'm happy.

The single largest issue is https://bugzilla.mozilla.org/show_bug.cgi?id=1159042, but as another comment mentioned, there are many different cases that trigger performance bottlenecks.

I agree completely, I only use Chrome and only open FF when I'm about to push a feature or if QA kicks something back. In the same way I don't use a production size DB locally when writing new code (but need to test performance after the feature is complete) I don't use a slower browser in my day to day development because why would I? It would be like given the choice between two computers to work on choosing the slower of the two.