Poorly written React (which is a lot of it) has terrible performance. Properly written React (just like properly written anything) has great performance.
The reason you experience it as terrible is because it's today's visual basic: it's so easy to start with that everyone does, without needing to understand programming or specifically how React works. You can just throw shit together and it'll work. It's empowered an entire generation of web and app makers, with the cost being "and they're not good at that, through no fault of their own, but they are just good enough to be dangerous".
It isn't even that new, in terms of approach... a LOT of game and simulation would work with state driven rendering... each frame is rendered against the current state. Similar workflows to React+Redux were in pretty broad use, the tools just brought it to web development... from there, React as a model for UI abstraction became more popular for other applications outside web use. It makes a lot of sense.
If you already understand the idea behind state driven updates, you're already writing better React than the majority of folks using it. React made it easy enough to write working UIs without having a clue what's actually happening, when, and why. (which is also why there's a never-ending stream of stackoverflow questions about why obvious state mutations don't immediately kick in)
Poorly written React (which is a lot of it) has terrible performance. Properly written React (just like properly written anything) has great performance.
The reason you experience it as terrible is because it's today's visual basic: it's so easy to start with that everyone does, without needing to understand programming or specifically how React works. You can just throw shit together and it'll work. It's empowered an entire generation of web and app makers, with the cost being "and they're not good at that, through no fault of their own, but they are just good enough to be dangerous".
It isn't even that new, in terms of approach... a LOT of game and simulation would work with state driven rendering... each frame is rendered against the current state. Similar workflows to React+Redux were in pretty broad use, the tools just brought it to web development... from there, React as a model for UI abstraction became more popular for other applications outside web use. It makes a lot of sense.
If you already understand the idea behind state driven updates, you're already writing better React than the majority of folks using it. React made it easy enough to write working UIs without having a clue what's actually happening, when, and why. (which is also why there's a never-ending stream of stackoverflow questions about why obvious state mutations don't immediately kick in)
In fact, afair react was made to make the page faster. (as dom manipulation was WAY slower back then)
It has adequate performance and the ease of development is worth it not being the most performant way to do things.