> 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

> 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.