3 ms·

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

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.

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.