Hacker News Reader

Comment by jodrellblank | Hacker News Reader

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

View on HN

> 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