5 ms·

That is exactly what I'm talking about. Everything you referenced is an architecture problem, not a JavaScript problem. You can write slow apps in JavaScript+Re

by ng12 6y ago

That is exactly what I'm talking about. Everything you referenced is an architecture problem, not a JavaScript problem. You can write slow apps in JavaScript+React, you can write slow apps in Rust. Unless milliseconds matter (doubtful in browser-land) you won't get the kind of performance you want for free just by switching languages.

brundolf 6y ago
Milliseconds absolutely matter. Every React render cycle (the entire relevant subtree from top to bottom because again, it's all synchronous) that takes more than 16 milliseconds presents to the user as a dropped frame. In fact that 16ms also has to include any DOM updates and the resulting browser reflow, which you have much less control over and are usually more expensive than your JS, so really the window is smaller than that. Also, many of the optimizations I listed above can make code less readable in small ways. Many of them are things you should not do eagerly (premature optimization is the root of all evil), and should only go back and do once you've identified a specific problem. If an across-the-board speed increase prevents them from ever becoming problems, that's a win. If you're thinking I'm a JS-hater, you're wrong. I think JS is a good language and I love using it where it's appropriate. But there are some usecases that benefit from a faster technology, and it's absolutely bonkers to try and argue that that technology shouldn't exist because "you can still make something slow with it if you really try".
- K0nserv 6y ago
  16ms with 60fps targets, but there are higher frequency displays hitting the markets so that target might shift to 8ms or lower in the future.
- rpedela 6y ago
  60 fps is rarely needed in web apps.
  - bschwindHN 6y ago
    60 fps should be the bare minimum given the kind of hardware we run these days.
    - rpedela 6y ago
      No it should based on the need of the use case, as always. Very few websites, even highly dynamic ones that require React, need to be rendered at 60 fps.
  - brundolf 6y ago
    <60fps results in a noticeably worse user experience, especially when scrolling. "Need" is relative, but I was really just trying to make the point that milliseconds matter: even if we cut that in half to 30fps, that's still 32ms maximum per render cycle.
    - viklove 6y ago
      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.

by ng12 6y ago

brundolf 6y ago

Milliseconds absolutely matter. Every React render cycle (the entire relevant subtree from top to bottom because again, it's all synchronous) that takes more than 16 milliseconds presents to the user as a dropped frame. In fact that 16ms also has to include any DOM updates and the resulting browser reflow, which you have much less control over and are usually more expensive than your JS, so really the window is smaller than that. Also, many of the optimizations I listed above can make code less readable in small ways. Many of them are things you should not do eagerly (premature optimization is the root of all evil), and should only go back and do once you've identified a specific problem. If an across-the-board speed increase prevents them from ever becoming problems, that's a win. If you're thinking I'm a JS-hater, you're wrong. I think JS is a good language and I love using it where it's appropriate. But there are some usecases that benefit from a faster technology, and it's absolutely bonkers to try and argue that that technology shouldn't exist because "you can still make something slow with it if you really try".

K0nserv 6y ago
16ms with 60fps targets, but there are higher frequency displays hitting the markets so that target might shift to 8ms or lower in the future.
rpedela 6y ago
60 fps is rarely needed in web apps.
- bschwindHN 6y ago
  60 fps should be the bare minimum given the kind of hardware we run these days.
  - rpedela 6y ago
    No it should based on the need of the use case, as always. Very few websites, even highly dynamic ones that require React, need to be rendered at 60 fps.
- brundolf 6y ago
  <60fps results in a noticeably worse user experience, especially when scrolling. "Need" is relative, but I was really just trying to make the point that milliseconds matter: even if we cut that in half to 30fps, that's still 32ms maximum per render cycle.
  - viklove 6y ago
    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.