4 ms·

What scenario can you think of where you have state updates while the user is scrolling?

brundolf 6y ago
Here are a couple cases we ran into: 1) We had a querying interface that would allow the user to construct a query and then it would return potentially thousands of results, asynchronously, over a websocket. We only displayed the first 300 on screen at a time, but sometimes the updates would come in so rapidly during that first 300 that one render wouldn't be finished before more results were available and the next render triggered. Things would get really backed-up and the UI would hang for multiple seconds at a time. So we decided to throttle the rendering - get the results as fast as possible, but only render once every 500ms or something. But during this time the user still might want to scroll around and look at other parts of the page, so we didn't want it to pause for 100ms every 500ms. It was a constant battle to keep things responsive while all this was going on. 2) We had another screen that would load another massive list (thousands and thousands) of entities as soon as you visited. These also came in gradually over time to spare the user from waiting for the last result before they could see the first. Similar deal: we throttled, but we needed to keep things responsive even during that throttling because the user would be scrolling up and down the results as they were coming in.
- ng12 6y ago
  Both of these sound like side-effects of trying to render massive amounts of UI artifacts that the user doesn't actually need or want to see. Whether you use JS+React or Rust+Yew you're going to get yourself into trouble with firehose-style data handling.
  - brundolf 6y ago
    Our users specifically demanded to see this much data. They actually complained that we couldn't show more. Once again you're making bold claims about a subset of use-cases that you clearly have no context for commentating on. I never claimed that switching languages would have magically solved all our problems, but in our case it could've been a significant boon to performance which could've been one factor of many that contributed to a solution, and I just can't figure out why you have such a problem with that idea.
    - rpedela 6y ago
      I'm an old 3d graphics programmer. One of performance rules is only render what will be displayed in that frame because rendering is expensive. That is why there are various culling algorithms, some are quite complicated. The reward for implementing all these advanced culling algorithms is very fast frame renders that give you more time to draw special effects, draw more characters, etc in a single frame. I am a data engineer now and sometimes have to build web interfaces for scrolling large data tables. Just like in the 3d graphics world, the trick to responsiveness is culling. Only download and display the amount of data that the user will see at a given time, plus some overhead so the user never sees gaps when scrolling. While Rust may have solved the problem in #1, it is unlikely to solve the problem in #2 because you are also fighting the network where Rust is useless. Need culling.
      - brundolf 6y ago
        Unfortunately because web content is automatically positioned/sized in a way that's (mostly) opaque to JavaScript code, this is a pretty hair problem (compared to graphics where you have all the numbers on-hand). So most of the time you'd either have to a) try and replicate the math the layout engine ends up doing which makes things more brittle, or b) directly measure the computed dimensions/positions/visibility/scroll position of different elements, which tends to be a pretty large performance liability and in many cases would eliminate any gains you might receive. There are some edge cases where these techniques can work - like if you have a really simple layout, and you can give a fixed-height to every item (table row or otherwise), and you assume the user is never going to resize their browser window - but it isn't nearly as obvious of a win as it is for 3D rendering and we just never decided it was worthwhile to try going down that rabbit-hole.
        rpedela 6y ago
        > Unfortunately because web content is automatically positioned/sized in a way that's (mostly) opaque to JavaScript code, this is a pretty hair problem (compared to graphics where you have all the numbers on-hand). Exactly the same for 3d graphics. The auto-positioning is different but conceptual similar. Yes B is my recommended approach. Since we are talking about performance, we should really be putting limits on what fast and slow mean. That is because it doesn't really matter if something is fast or slow, what matters is the performance difference between different approaches. For B on average, performance will in the microsecond range, DOM rendering will be in the millisecond range, and the network is >100ms to seconds range. It is unlikely that B will be equal or slower to brute force rendering everything. Those X microseconds spent figuring out the culling window saves Y milliseconds rendering and saves Z milliseconds to seconds querying the network.

Here are a couple cases we ran into: 1) We had a querying interface that would allow the user to construct a query and then it would return potentially thousands of results, asynchronously, over a websocket. We only displayed the first 300 on screen at a time, but sometimes the updates would come in so rapidly during that first 300 that one render wouldn't be finished before more results were available and the next render triggered. Things would get really backed-up and the UI would hang for multiple seconds at a time. So we decided to throttle the rendering - get the results as fast as possible, but only render once every 500ms or something. But during this time the user still might want to scroll around and look at other parts of the page, so we didn't want it to pause for 100ms every 500ms. It was a constant battle to keep things responsive while all this was going on. 2) We had another screen that would load another massive list (thousands and thousands) of entities as soon as you visited. These also came in gradually over time to spare the user from waiting for the last result before they could see the first. Similar deal: we throttled, but we needed to keep things responsive even during that throttling because the user would be scrolling up and down the results as they were coming in.

ng12 6y ago
Both of these sound like side-effects of trying to render massive amounts of UI artifacts that the user doesn't actually need or want to see. Whether you use JS+React or Rust+Yew you're going to get yourself into trouble with firehose-style data handling.
- brundolf 6y ago
  Our users specifically demanded to see this much data. They actually complained that we couldn't show more. Once again you're making bold claims about a subset of use-cases that you clearly have no context for commentating on. I never claimed that switching languages would have magically solved all our problems, but in our case it could've been a significant boon to performance which could've been one factor of many that contributed to a solution, and I just can't figure out why you have such a problem with that idea.
  - rpedela 6y ago
    I'm an old 3d graphics programmer. One of performance rules is only render what will be displayed in that frame because rendering is expensive. That is why there are various culling algorithms, some are quite complicated. The reward for implementing all these advanced culling algorithms is very fast frame renders that give you more time to draw special effects, draw more characters, etc in a single frame. I am a data engineer now and sometimes have to build web interfaces for scrolling large data tables. Just like in the 3d graphics world, the trick to responsiveness is culling. Only download and display the amount of data that the user will see at a given time, plus some overhead so the user never sees gaps when scrolling. While Rust may have solved the problem in #1, it is unlikely to solve the problem in #2 because you are also fighting the network where Rust is useless. Need culling.
    - brundolf 6y ago
      Unfortunately because web content is automatically positioned/sized in a way that's (mostly) opaque to JavaScript code, this is a pretty hair problem (compared to graphics where you have all the numbers on-hand). So most of the time you'd either have to a) try and replicate the math the layout engine ends up doing which makes things more brittle, or b) directly measure the computed dimensions/positions/visibility/scroll position of different elements, which tends to be a pretty large performance liability and in many cases would eliminate any gains you might receive. There are some edge cases where these techniques can work - like if you have a really simple layout, and you can give a fixed-height to every item (table row or otherwise), and you assume the user is never going to resize their browser window - but it isn't nearly as obvious of a win as it is for 3D rendering and we just never decided it was worthwhile to try going down that rabbit-hole.
      - rpedela 6y ago
        > Unfortunately because web content is automatically positioned/sized in a way that's (mostly) opaque to JavaScript code, this is a pretty hair problem (compared to graphics where you have all the numbers on-hand). Exactly the same for 3d graphics. The auto-positioning is different but conceptual similar. Yes B is my recommended approach. Since we are talking about performance, we should really be putting limits on what fast and slow mean. That is because it doesn't really matter if something is fast or slow, what matters is the performance difference between different approaches. For B on average, performance will in the microsecond range, DOM rendering will be in the millisecond range, and the network is >100ms to seconds range. It is unlikely that B will be equal or slower to brute force rendering everything. Those X microseconds spent figuring out the culling window saves Y milliseconds rendering and saves Z milliseconds to seconds querying the network.