8 ms·

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 s

by stinos 2mo ago

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 2mo ago
IME, this absolutely doesn't go unnoticed, except in trivial cases.
- tenacious_tuna 2mo ago
  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 2mo ago
    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 2mo ago
      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 2mo ago
  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 2mo ago
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 https://developer.mozilla.org/en-US/docs/Glossary/Debounce

by stinos 2mo ago

silon42 2mo ago

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

tenacious_tuna 2mo ago
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 2mo ago
  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 2mo ago
    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 2mo ago
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 2mo ago

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 https://developer.mozilla.org/en-US/docs/Glossary/Debounce