[stinos]

Even without this performance hit, an often used way for implementing 'auto scroll to top/bottom' is to first check if there's no other stuff coming in before starting to actually scroll. This goes unnoticed by the user but drastically reduces the number of updates (and in this case, number of calls to scrollHeight) needed when a lot of data is coming in in batches. Principle is like: receive message, add to buffer and start timer of like 50ms. Upon timer tick copy everything from buffer (which in the meantime can have accumulated more data) to rendering and only then update scroll.

[silon42]

IME, this absolutely doesn't go unnoticed, except in trivial cases.

[tenacious_tuna]

Drives me nuts whenever I reach the bottom of a scroll window and I can feel the network call happening before stuff starts loading again. It's 8ms from me to the local CDN and I've got gigabit, but it feels like every dang site is slow as hell these days.

[Groxx]

Preloading certainly does seem to be a lost art at times, yeah. It's just so complicated, we might never climb back to such heights.

[tenacious_tuna]

i feel that way about most web design principles these days. For a brief window it seemed like every website had automatic handling for dark/light mode based on system preference, or at least a toggle, but I feel like that's gone the way of the dodo. Or popups, consent banners, images loading and reflowing an entire article...

maddening.

[stinos]

I was talking message logs for example; is that trivial? I.e. what do you mean exactly? Do you notice the difference between 1 line of text being added every 16.6ms vs 3 lines every 50ms? And if so is that a problem?

[robertlagrant]

Indeed. It's the same principle[0] the other way too - start a timer from user typing for an autocomplete function and only refetch after the timer expires.

[0] https://developer.mozilla.org/en-US/docs/Glossary/Debounce