4 ms·

> Updating the state of thousands of DOM nodes at a steady 16ms per frame in a browser is hard enough No, it's really not. I've done it before, and profiled it

> Updating the state of thousands of DOM nodes at a steady 16ms per frame in a browser is hard enough No, it's really not. I've done it before, and profiled it. 16ms is a super long time to a computer. You should easily be able to update tens, if not hundreds of thousands of DOM nodes, assuming you aren't doing anything weird like blocking on layout in one of them. Let's aim for frameworks that are in the ballpark of peak raw performance, before we look to parallelism and multi-threading as a solution. That someone possibly had the mistaken belief that this was peak performance for a hand-rolled WebGL codebase shows how low and out-of-touch our expectations for performance really are.

onion2k 7y ago
That someone possibly had the mistaken belief that this was peak performance for a hand-rolled WebGL codebase.. No one thought that though. This is a demo of good performance using a web framework on top of a WebGL framework. It's showing that a future version of React will make building a solid 60fps web app UI is within the reach of most web developers. Sure, you can hand-roll code to get that performance today if you know how, but this is about putting that performance in the hands of developers who can't (or, more often, aren't given the resources to). To argue that is unnecessary or actually bad is ridiculous. Libraries that make it easier to build better apps are universally good things.
- Jasper_ 7y ago
  The OP literally tweeted this: > I'm pretty sure it will run circles around even the best performing manual three or webGL apps out there soon. https://twitter.com/0xca0a/status/1199997563396612096 https://twitter.com/0xca0a/status/1199997563396612096
  - cercatrova 7y ago
    Correct; however, the tweet author's mistaken sense of arrogance does not invalidate the points made by your parent comment. To steel-man that argument, having this speed be default behavior allows developers to create much better UX than currently, at least on terms of responsiveness.
    - Jasper_ 7y ago
      Speed should indeed be the default behavior, which is why I'm so upset at React being so slow. It really shouldn't be; computers are fast. We shouldn't have to multi-thread updating 2,000 objects to get performance.
- csande17 7y ago
  > what you see above [the 2000-cube demo] simply would not be possible without scheduling, that is a fact. you can't expect any renderer to handle that amount of stress, it's a matter of capacity. https://twitter.com/0xca0a/status/1200121269339000838 https://twitter.com/0xca0a/status/1200121269339000838
naikrovek 7y ago
I really wish more people felt the way you do. You clearly have done the work to prove this to yourself. No one saying otherwise has done that work. Two things produce conviction in people regarding technical matters: ignorance and experience. You clearly have the experience. Tech needs more people like you.
- exogen 7y ago
  That might be true, if this person were not most likely just making things up. Jasper_ is vastly overstating things if not outright lying. Updating that many elements is possible with canvas maybe, but DOM nodes, no. Here's a dead simple demo in pure vanilla JavaScript: https://brianbeck.com/particles.html https://brianbeck.com/particles.html Go ahead and see what number you get to before it drops below 60fps. Personally I have to decrease it to 1000 or so on my 2018 MacBook Pro. And that's updating a style property that does not cause reflow calculation. Anyone including Jasper_ is welcome to post a similar demo of their 100x+ performance improvements on this, but I doubt they will.
  - naikrovek 7y ago
    > Anyone including Jasper_ is welcome to post a similar demo of their 100x+ performance improvements on this, but I doubt they will. Are you kidding? Look at any modern 3D video game on any platform, INCLUDING WebGL.
    - exogen 7y ago
      I think you missed what the conversation was about. > You should easily be able to update tens, if not hundreds of thousands of DOM nodes We're talking about updating multiple DOM nodes dude, not a 3D rendering engine or a single canvas element. People don't make React websites where everything is drawn in canvas.
      - pjmlp 7y ago
        Not yet, just wait for Flash Fenix to become widespread.
kilburn 7y ago
> had the mistaken belief that this was peak performance for a hand-rolled WebGL codebase I totally agree on this. > assuming you aren't doing anything weird like blocking on layout in one of them. An assumption that react cannot make. React's core promise is to make app developers lives easy, not to be performant. Performance is atrocious on the web in general, yet here it is as (one of?) the most dominant app development platforms. With that easiness what you get is plenty of horrible (from a performance perspective) applications that get their jobs done. Some even very elegantly on many other metrics. > Let's aim for frameworks that are in the ballpark of peak raw performance That is a nice aim, but performance can be traded for other things. Immutable data structures will never be as performant as mutable ones, yet plenty of people make the conscious decision of using the former. I see React's approach similary. I've built plenty of web applications in my life, and very rarely did (non-network) performance become a significant issue. As you said, computers are so powerful nowadays that most people (even devs!) cannot even comprehend it at an intuitive level. It is always the app's logic, changing business requirements, etc. that bite me in the ass. I want tools that make that part easier. React is definitely one of those tools today. And if they found a way to keep the easiness while being better performance-wise then... yay!
- adev_ 7y ago
  > As you said, computers are so powerful nowadays that most people (even devs!) cannot even comprehend it at an intuitive level. Yeah, and still a good number of electrons apps arrive to put my CPU at 100% for something as advance as "text editing". CPU are powerful when used right.
  - RussianCow 7y ago
    Text editing wasn't the best example here, because it's very technically involved and much more difficult to optimize than you seem to imply. (In fact, VS Code is much faster than any of the popular Java-based IDEs.) But replace "text editing" with "instant messaging" and your point still stands.
AriaMinaei 7y ago
> You should easily be able to update tens, if not hundreds of thousands of DOM nodes, assuming you aren't doing anything weird like blocking on layout in one of them Last I tried that was back in 2013. Haven't tried that particular benchmark since, but have tried others, and I don't believe things have changed much to move that particular needle. The benchmark was updating the translate3d(random, random, 1px) of multiple 20x20 divs with a black background. It would increase the number of divs until we'd start to have dropped frames. Obviously no re-layout, no repaint, practically no time spent on the script, and no GC. Compositor only. Chrome on Windows on a beefed up PC maxed out at around 400 squares (divs). So no, hundreds of thousands of divs would not be possible. Not on Blink's architecture at least. WebRender is trying to change that, but it's still too early to tell. I tried the same benchmark with hand-written WebGL, and made sure that the black squares are drawn one-by-one to simulate how Chrome did it (no batched draw calls). That maxed out at around 1k squares. Obviously all that time was being wasted back-and-forthing between the script and the GPU. Then tried batching the draw calls (square coords on a large typed array), and that got me to, iirc, millions. > That someone possibly had the mistaken belief that this was peak performance for a hand-rolled WebGL codebase shows how low and out-of-touch our expectations for performance really are. True. It is mathematically impossible for react to beat hand-optimized WebGL. I'd guess it won't come close to 1/100 of the raw throughput. It would require a different programming model. And then it would no longer be React.

onion2k 7y ago

That someone possibly had the mistaken belief that this was peak performance for a hand-rolled WebGL codebase.. No one thought that though. This is a demo of good performance using a web framework on top of a WebGL framework. It's showing that a future version of React will make building a solid 60fps web app UI is within the reach of most web developers. Sure, you can hand-roll code to get that performance today if you know how, but this is about putting that performance in the hands of developers who can't (or, more often, aren't given the resources to). To argue that is unnecessary or actually bad is ridiculous. Libraries that make it easier to build better apps are universally good things.

Jasper_ 7y ago
The OP literally tweeted this: > I'm pretty sure it will run circles around even the best performing manual three or webGL apps out there soon. https://twitter.com/0xca0a/status/1199997563396612096 https://twitter.com/0xca0a/status/1199997563396612096
- cercatrova 7y ago
  Correct; however, the tweet author's mistaken sense of arrogance does not invalidate the points made by your parent comment. To steel-man that argument, having this speed be default behavior allows developers to create much better UX than currently, at least on terms of responsiveness.
  - Jasper_ 7y ago
    Speed should indeed be the default behavior, which is why I'm so upset at React being so slow. It really shouldn't be; computers are fast. We shouldn't have to multi-thread updating 2,000 objects to get performance.
csande17 7y ago
> what you see above [the 2000-cube demo] simply would not be possible without scheduling, that is a fact. you can't expect any renderer to handle that amount of stress, it's a matter of capacity. https://twitter.com/0xca0a/status/1200121269339000838 https://twitter.com/0xca0a/status/1200121269339000838

naikrovek 7y ago

I really wish more people felt the way you do. You clearly have done the work to prove this to yourself. No one saying otherwise has done that work. Two things produce conviction in people regarding technical matters: ignorance and experience. You clearly have the experience. Tech needs more people like you.

exogen 7y ago
That might be true, if this person were not most likely just making things up. Jasper_ is vastly overstating things if not outright lying. Updating that many elements is possible with canvas maybe, but DOM nodes, no. Here's a dead simple demo in pure vanilla JavaScript: https://brianbeck.com/particles.html https://brianbeck.com/particles.html Go ahead and see what number you get to before it drops below 60fps. Personally I have to decrease it to 1000 or so on my 2018 MacBook Pro. And that's updating a style property that does not cause reflow calculation. Anyone including Jasper_ is welcome to post a similar demo of their 100x+ performance improvements on this, but I doubt they will.
- naikrovek 7y ago
  > Anyone including Jasper_ is welcome to post a similar demo of their 100x+ performance improvements on this, but I doubt they will. Are you kidding? Look at any modern 3D video game on any platform, INCLUDING WebGL.
  - exogen 7y ago
    I think you missed what the conversation was about. > You should easily be able to update tens, if not hundreds of thousands of DOM nodes We're talking about updating multiple DOM nodes dude, not a 3D rendering engine or a single canvas element. People don't make React websites where everything is drawn in canvas.
    - pjmlp 7y ago
      Not yet, just wait for Flash Fenix to become widespread.

kilburn 7y ago

> had the mistaken belief that this was peak performance for a hand-rolled WebGL codebase I totally agree on this. > assuming you aren't doing anything weird like blocking on layout in one of them. An assumption that react cannot make. React's core promise is to make app developers lives easy, not to be performant. Performance is atrocious on the web in general, yet here it is as (one of?) the most dominant app development platforms. With that easiness what you get is plenty of horrible (from a performance perspective) applications that get their jobs done. Some even very elegantly on many other metrics. > Let's aim for frameworks that are in the ballpark of peak raw performance That is a nice aim, but performance can be traded for other things. Immutable data structures will never be as performant as mutable ones, yet plenty of people make the conscious decision of using the former. I see React's approach similary. I've built plenty of web applications in my life, and very rarely did (non-network) performance become a significant issue. As you said, computers are so powerful nowadays that most people (even devs!) cannot even comprehend it at an intuitive level. It is always the app's logic, changing business requirements, etc. that bite me in the ass. I want tools that make that part easier. React is definitely one of those tools today. And if they found a way to keep the easiness while being better performance-wise then... yay!

adev_ 7y ago
> As you said, computers are so powerful nowadays that most people (even devs!) cannot even comprehend it at an intuitive level. Yeah, and still a good number of electrons apps arrive to put my CPU at 100% for something as advance as "text editing". CPU are powerful when used right.
- RussianCow 7y ago
  Text editing wasn't the best example here, because it's very technically involved and much more difficult to optimize than you seem to imply. (In fact, VS Code is much faster than any of the popular Java-based IDEs.) But replace "text editing" with "instant messaging" and your point still stands.

AriaMinaei 7y ago

> You should easily be able to update tens, if not hundreds of thousands of DOM nodes, assuming you aren't doing anything weird like blocking on layout in one of them Last I tried that was back in 2013. Haven't tried that particular benchmark since, but have tried others, and I don't believe things have changed much to move that particular needle. The benchmark was updating the translate3d(random, random, 1px) of multiple 20x20 divs with a black background. It would increase the number of divs until we'd start to have dropped frames. Obviously no re-layout, no repaint, practically no time spent on the script, and no GC. Compositor only. Chrome on Windows on a beefed up PC maxed out at around 400 squares (divs). So no, hundreds of thousands of divs would not be possible. Not on Blink's architecture at least. WebRender is trying to change that, but it's still too early to tell. I tried the same benchmark with hand-written WebGL, and made sure that the black squares are drawn one-by-one to simulate how Chrome did it (no batched draw calls). That maxed out at around 1k squares. Obviously all that time was being wasted back-and-forthing between the script and the GPU. Then tried batching the draw calls (square coords on a large typed array), and that got me to, iirc, millions. > That someone possibly had the mistaken belief that this was peak performance for a hand-rolled WebGL codebase shows how low and out-of-touch our expectations for performance really are. True. It is mathematically impossible for react to beat hand-optimized WebGL. I'd guess it won't come close to 1/100 of the raw throughput. It would require a different programming model. And then it would no longer be React.