https://github.blog/2023-06-21-crafting-a-better-faster-code-view/

That blog post is painful to read.
Just look at passages like:

As we dug in, we discovered that there were a few things at play:

• When there are many DOM nodes on the page, style calculations and paints take longer.
• When there are many DOM nodes on the page, DOM queries take longer, and the results can have a significant memory footprint.
• When there are many React nodes on the page, renders and DOM reconciliation both take longer.

It’s worth noting that none of these are problems with React specifically; any page with a very large DOM would experience the first two problems, and any solution where a large DOM is created and managed by JavaScript would experience the third.

Who writes this trash?

The first bullet point is not the axiom the words chosen make it seem to be. Style recalculations are not affected by the number of DOM nodes on the page. They are affected by the size of the subtree receiving the potential changes. Browsers are very good at providing early-out behavior here. But if you want, you can be explicit about it by using CSS containment and guide them down the right path.
You can isolate t