4 ms·

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 el

by 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.
  - naikrovek 7y ago
    Yup, and I got a few downvotes for my trouble.
Jasper_ 7y ago
From my preliminary profile, it's spending an abnormal amount of time recalculating the style, which is bizarre as nothing major has changed. Admittedly, my own experiences have been for large data tables where you tend to reuse cell nodes as data gets repurposed, so styles aren't updated as often. I also used scoped styles to ensure that nodes wouldn't search the whole tree to find their styles (something that has since been removed from Chrome). Supposedly this is replaced now by Display Locking [0], but I wasn't able to get it to work for this example in my limited testing. Going back to my old project, it also seems to have regressed in performance. Grr. I will admit that DOM is some serious black magic, the browser is an unfortunate moving target, and when I say "should be able to update 10k", I am lying as much blame at the feet of the browser developers as I am at the frameworks. I would go back and edit my old post now, since you're clearly right in this case, but it seems the time limit on it has run out. [0] https://github.com/WICG/display-locking/blob/master/README.md https://github.com/WICG/display-locking/blob/master/README.m...
csande17 7y ago
It's important to note that a large portion of the frame time in that demo is spent in browser code, recalculating styles and redrawing. I modified the demo to display the amount of time spent in the actual function that updates the DOM nodes, and I can crank it to 50,000 before that number exceeds 16 milliseconds: https://fiddle.jshell.net/btzqw47u/show/ https://fiddle.jshell.net/btzqw47u/show/ For comparison, my quick-and-dirty React version of the demo spends around 100 ms in React/updating DOM elements when you have 50,000 particles: https://jsfiddle.net/t6js8k5e/ https://jsfiddle.net/t6js8k5e/ (If you try that one at home, be warned that the browser might hang for a few seconds when you click the "Animate" button.) I'm certainly not a web performance expert by any means, but this seems to support Jasper_'s assertion that you can make tens of thousands of DOM updates in 16 ms and that frameworks add substantial overhead to this. (And FWIW, my modified non-React version of the demo maintains 60fps with 2,000 particles in Safari on my MacBook Pro from 2015. Admittedly, that's without many other programs/tabs running.)
- Jasper_ 7y ago
  Ah, indeed, it seems like modifying transform is a lot more expensive than modifying left, for some reason. I didn't think to check that and assumed they were roughly equivalent. I'm guessing browsers do extra work on setting transform to recalculate style. What a bizarre result. Nice work!
- exogen 7y ago
  > a large portion of the frame time in that demo is spent in browser code, recalculating styles and redrawing This was my point actually, not that React adds no overhead which of course it does. Updating a property on a bunch of DOM nodes, without actually waiting for their effects to be applied by the browser, is of course very fast. But the browser code (reflow, paint, etc.) is part of the frame budget, and the number of nodes you can change – accounting for those changes actually appearing on screen – within that budget is embarrassingly small regardless of whether you are doing raw DOM operations vs. using a framework like React. It doesn't really count to say "ah yes, but the code that technically made the update was fast!" when the updates haven't actually been committed to the screen yet.

by exogen 7y ago

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.
- naikrovek 7y ago
  Yup, and I got a few downvotes for my trouble.

Jasper_ 7y ago

From my preliminary profile, it's spending an abnormal amount of time recalculating the style, which is bizarre as nothing major has changed. Admittedly, my own experiences have been for large data tables where you tend to reuse cell nodes as data gets repurposed, so styles aren't updated as often. I also used scoped styles to ensure that nodes wouldn't search the whole tree to find their styles (something that has since been removed from Chrome). Supposedly this is replaced now by Display Locking [0], but I wasn't able to get it to work for this example in my limited testing. Going back to my old project, it also seems to have regressed in performance. Grr. I will admit that DOM is some serious black magic, the browser is an unfortunate moving target, and when I say "should be able to update 10k", I am lying as much blame at the feet of the browser developers as I am at the frameworks. I would go back and edit my old post now, since you're clearly right in this case, but it seems the time limit on it has run out. [0] https://github.com/WICG/display-locking/blob/master/README.md https://github.com/WICG/display-locking/blob/master/README.m...

csande17 7y ago

It's important to note that a large portion of the frame time in that demo is spent in browser code, recalculating styles and redrawing. I modified the demo to display the amount of time spent in the actual function that updates the DOM nodes, and I can crank it to 50,000 before that number exceeds 16 milliseconds: https://fiddle.jshell.net/btzqw47u/show/ https://fiddle.jshell.net/btzqw47u/show/ For comparison, my quick-and-dirty React version of the demo spends around 100 ms in React/updating DOM elements when you have 50,000 particles: https://jsfiddle.net/t6js8k5e/ https://jsfiddle.net/t6js8k5e/ (If you try that one at home, be warned that the browser might hang for a few seconds when you click the "Animate" button.) I'm certainly not a web performance expert by any means, but this seems to support Jasper_'s assertion that you can make tens of thousands of DOM updates in 16 ms and that frameworks add substantial overhead to this. (And FWIW, my modified non-React version of the demo maintains 60fps with 2,000 particles in Safari on my MacBook Pro from 2015. Admittedly, that's without many other programs/tabs running.)

Jasper_ 7y ago
Ah, indeed, it seems like modifying transform is a lot more expensive than modifying left, for some reason. I didn't think to check that and assumed they were roughly equivalent. I'm guessing browsers do extra work on setting transform to recalculate style. What a bizarre result. Nice work!
exogen 7y ago
> a large portion of the frame time in that demo is spent in browser code, recalculating styles and redrawing This was my point actually, not that React adds no overhead which of course it does. Updating a property on a bunch of DOM nodes, without actually waiting for their effects to be applied by the browser, is of course very fast. But the browser code (reflow, paint, etc.) is part of the frame budget, and the number of nodes you can change – accounting for those changes actually appearing on screen – within that budget is embarrassingly small regardless of whether you are doing raw DOM operations vs. using a framework like React. It doesn't really count to say "ah yes, but the code that technically made the update was fast!" when the updates haven't actually been committed to the screen yet.