Essentially the reactive state model - which imo is 'fast' to code in - currently has a horrendous limitation on how many components can be reactive.
A naive minesweeper implementation (that is state-connected) will get upset at a hundred cells, and terribly laggy at 900 (a standard 30x30 super expert board).
This means devs have to abandon reactive programming for parts of their code with a non trivial component count.
The demo is showing 'smooth' perf on these kinds of "state-connected" workloads.
The graphics side of things is a partial distraction, mainly it will mean web devs won't have to make the current performance vs ease of development tradeoff in webapps (think boring saas stuff).
The way in which it isn't a distraction is it will make it possible to get past CSS limitations inside of react in a very intuitive way.
As this raises the low bar react had for game perf, we will no doubt see more react games.
But have no doubt - this is about what the current state of reactive programming is capable of off the shelf.
That type of rendering is more about GPU load than of anything React (DOM) related.
As of DOM rendering of comparable number of nodes then this:
https://terrainformatica.com/2019/07/29/bloomberg-terminal-h...
900 elements re-rendered on each frame of kinematic scroll (60 FPS) with 10% CPU load. And 250 FPS max on typical high-DPI monitor.
In other tests underlying recordset is updated with 25 FPS frequency. The view observes and updates screen for visible rows - 2% CPU for that.
All that in main GUI thread so I do not understand the excitement.