Hacker News Reader

Comment by loa_in_ | Hacker News Reader

I love Firefox but some JS heavy demos etc. just don't work fast enough. I hate that I know exactly why. It's because they were only ever tested on Chrome during development.

View on HN

Lets be clear here. They were only tested on some developer's fast machine on Chrome. All the users are going to be using it on some bag of shit $300 laptop running crapware infested Edge so they will be suffering like your Firefox users are.

The problem is the left hand side of the chain. Stop pulling in thousand layer garbage abstractions and making the user pay the penalty for it.

All web developers should be required by law to work on 4gb 3ghz laptops with a 3G mobile connection.

No, Firefox just flat out has some worse JavaScript performance and bugs/incompatibility with other browsers.

I’ve been/am currently burned by Firefox’s pretty poor IndexedDB support and performance. IDBObjectStore.getAll() fails with a cryptic exception if you store too much in IndexedDB (iirc 256mb is the limit), whereas Chrome and Safari have no problem with it. It also has terrible performance - about 4x slower than Chrome, with Safari having the best performance.

That's a microscopic problem in a macroscopic ocean of shit.

Interesting, I haven't run into it as upto now and I was checking some pretty cool and intense CodePens earlier.

I'll look into some threeJS demos to see how it goes (ex. https://bruno-simon.com/ ). Are there any other specific JS demos you've had a bad experience with?

That 3D website ( https://bruno-simon.com/) ran well enough though it did cause my laptop's fans to run but I believe that happens in Chrome too.

So far, I haven't found much of a difference in performance of websites but it's still early times for me.

I tested this on FF/Chrome/Safari on an M1 Max, couldn't see any difference at all between FF and Chrome but on Safari it was incredibly slow (which actually let me drive the car, that thing turns fast). I also wasn't aware prior to clicking that it was even possible to create web apps like this.

That person (Bruno Simon) is fantastic at creating 3D experiences on the web. He has a course on three.js too that I hope to buy and go through hopefully within this year.

For me a good example have always been https://kangax.github.io/compat-table/es6/ which rendered very poorly on Firefox. I see it's better now, but still, try to hover over the table (do couple of mouse movement, some circles or something) and see that it's not as responsive as Chrome is.

Another example is iD[0] Editor on https://www.openstreetmap.org/. But there, to be fair, it's also slow on Chrome but I feel it's a bit slower on Firefox.

[0] https://github.com/openstreetmap/iD

> https://kangax.github.io/compat-table/es6/

Oh man this was a rough one both for FF and Chrome but Chrome did perform better slightly on cursory glance.

Thanks for providing these links, they're definitely a good rule of thumb benchmarks to test new browsers

Doppio (JVM implemented in JS) is absurdly slower for running java programs in Firefox compared to Chrome.

On the contrary, colossal GitHub diffs routinely crashed Chrome for me [in the past], while Firefox dealt with them effortlessly. Different browsers have different strengths.

To me it's not only a speed problem. Some pages directly won't work on Firefox because of some JS issue, but they do work in Chrome.

When that happens I just fire up a vanilla chrome and look at the js thingy there. It doesn't happen more than once per week.

Can you give an example of something JS heavy that is slow in Firefox? I haven't encountered something like that in a very long while.

This might be a bit niche, and not specifically JS, but drawing anything in a HTML <canvas> element which involves a CanvaAPI ShadowBlur[1] is guaranteed to make Firefox weep.

The issue was mentioned on Bugzilla (at least) 11 years ago[2], performance remains abysmal.

[1] - https://developer.mozilla.org/en-US/docs/Web/API/CanvasRende...

[2] - https://bugzilla.mozilla.org/show_bug.cgi?id=763120

SAP Concur

Idk if being JS heavy was the issue here, but Twitch had terrible performance on Firefox for years. I installed Brave specifically for Twitch (and Twitch alone), and could finally use the site without everything feeling sluggish and super laggy.

I don't use Twitch much anymore, but the one time I opened it recently (for NeoVimConf), it seemed much better.

If developers are writing in a vanilla style based on open standards, then why should there be performance idiosyncrasy among browsers?

> why should there be performance idiosyncrasy among browsers?

Because the engines work differently, some are better at some parts and worse at others. That's just the name of the game when you have different implementations of something.

Not saying that work shouldn't be done do make them on-par with each other, just providing a reasoning why things are like they are. I remember at one point some Google product was using some JavaScript API for lots of things and obviously only tested things in Chrome, when testing it in Firefox the performance was a lot worse, as Gecko performed worse than V8 using the data structure/API. They ended up disabling Firefox access to it because of this.

Eventually, Firefox got the bug fixed I think, so the product enabled support for Firefox.

I guess the point is, the standards around the web platform say how the user should be able to use some API/format/structure, not much about how said API/format/structure is internally implemented.

It shouldn't matter honestly, I didn't notice any performance difference in benchmarks for react.

It's interesting that you put the blame for the slowness on Firefox. I blame web developers for failing to build things for browsers rather than just Chrome.

This isn't blaming Firefox any more than one would blame other web browsers for a bad enterprise app requiring Internet Explorer, it's just the sad reality that users have to deal with.

Which part of their comment reads as blaming Firefox?

I love Firefox but some JS heavy demos etc. just don't work fast enough.

Have you read the last sentence as well?

> It's because they were only ever tested on Chrome during development.

That only means the developers didn't care if it was fast, or even works, in other browsers. It says nothing about Firefox. The first sentence, where the author complains that JS heavy apps are too slow in Firefox, is the part that's about Firefox.

What the OG commenter meant (as I read it) was that the page was slow in FF solely because the developer didn’t test the page in FF.

It does in no way imply that FF is worse than Chrome, but it does imply that (some) web developers are lazy.

That sentence is a simple statement of fact - that some apps are too slow in Firefox. It places no blame for the slowness. The blame comes later, and is put on lazy developers.

I recently wrote a small JS page, the core of it is a table of tens of thousands of items and a for(let i=0; i<len(array); i++) loop with DOM CSS changes to hide/show rows matching a filter in the inner loop.

In Edge the page loads quickly and the loop is typically under 20ms.

In FireFox the page lags many seconds while loading and rendering, and several seconds when the loop involves a lot of hide/show of the table.

It's not that I haven't tested, it's that FireFox just isn't as fast as Edge. This simple approach relies on the browser handling a lot of items because I can't write a complex indexer in JavaScript and don't want to spend more effort on a low-use page and I refuse to put up with 'paging'.

> It's not that I haven't tested, it's that FireFox just isn't as fast as Edge.

Only in this one specific case. You don't know the other cases. What you do is write code and check if it's fast enough in Chrome. If it's not you change your code. You never check if it's fast in Firefox instead and then go on with your day, saying "well chrome's just slow".

> "You don't know the other cases."

Why would I care about the other cases? It's no use to me if FireFox is really fast at caching if I'm not using caching.

> "What you do is write code and check if it's fast enough in Chrome. If it's not you change your code."

I can't change my code, it's at the limit of (my understanding of JavaScript/web performance) crossed with (how much work time I can spend developing this page). I've already got rid of function calls in the inner loops, trimmed the data set aggressively, pushed more into SQL than in client side, have an out-of-band dataset generator so querying the DB isn't part of page load it's a static page served with static compression, it's taken days longer than I wanted to get even this functionality fast enough to be as fast as I want, if it needs double the time and SpiderMonkey performance expertise to cater for FireFox then the result is tell people to use Edge for it.

> "You never check if it's fast in Firefox instead and then go on with your day, saying "well chrome's just slow""

I did check if it was fast in FireFox and it wasn't. I carried on trying to make it faster until I ran out of ability and it went from 'okay I guess' on Edge to 'great that's what I hoped for' on Edge. And sluggish on FireFox. The reason I don't go on saying "Chrome's just slow" is because Chrome isn't.

> Why would I care about the other cases?

Because you talk about the other cases when you make general statements like:

> it's that FireFox just isn't as fast as Edge.

> I can't change my code,

I wasn't suggesting you change anything about your code. Remember, the context of this conversation is this Statement by GP:

> I hate that I know exactly why. It's because they were only ever tested on Chrome during development.

The reality is that Firefox has a tiny market share at this point, so it is questionable how much time should be invested into optimizing pages to make them fast on Firefox. But that is a problem with Firefox's market position, not technology.

My point was that when code is slow in Chrome, you change it and never notice whether Firefox would have been faster in those cases. You only test code that is sufficiently fast in Chrome in Firefox. Thus, you don't usually see the cases where Firefox is faster than Chrome.

The context from the GP is relevant, my reply was to say no don't accuse laziness and ignorance, I do use FireFox as my daily browser, I did test with FireFox, I wanted my page to be equally good and I couldn't achieve that. The effort of rewriting to get 'great' responsiveness in Edge got 'sub-par' in FireFox - and it's not because I didn't bother trying.

Your last paragraph is probably true in general, and true specifically for me because the Windows server I was using had Edge and didn't have Chrome or FireFox.

I wouldn't make dom changes in a tight loop like that. Better would be to accumulate the changes that need to be made and then do a batch change operation instead of one at a time like it sounds like you're doing. That code would be slow in any browser.

You say "it would be slow in any browser" but that's not true. It's fast in Edge and Chrome and slow in FireFox.

> "then do a batch change operation"

What would the 'batch change' be if not a loop over all the changes, making the changes one by one?

One possibility would be to create all the matching rows of the table in text (<tr><td>...</td></tr>), and then replace the contents of the table in one assignment. That's pretty fast, although I'm not sure about OP's case.

Reply on news.ycombinator.com