I honestly think it's about a quarter of the code. Yes, there's a bit of ceremony around state management (but you are also free not to use Redux). But it's mostly boilerplate with a prescribed structure, so IMO it's pretty difficult to get it wrong.

On the other hand, most of the code has always been DOM manipulation, and having that declarative rather than imperative is a huge win. The alternative used to be using a template engine like handlebars, but that did a complete re-render every time any state changed, so for anything moderately complex that was too slow and you had to fallback to manual DOM manipulation, and manually keeping the DOM in sync with your state. And that was a large amount of rope in which to hang yourself

Yet we all managed to write complex web applications without much trouble that performed better than React ever can. DOM manipulation was needed rarely actually - usually you replace subtrees anyways (switch tabs, etc).

If DOM manipulation is rarely needed then your web app isn't complex, it's at most a collection of CRUD pages. UI Frameworks like React are for building UI's that accomplish a lot more than that through frequent DOM manipulation. If all you need is CRUD then templating frameworks still exist, are well maintained, and widely in use.

Even in complex apps, most of the DOM remains the same and you are changing several properties (some text, changing some classes).

That's not true as soon as your UI contains conditional logic or a list of elements, at least one of which will be present in almost every web application.

> ... and having that declarative rather than imperative is a huge win. The alternative used to be using a template engine like handlebars

While React markets itself as a declarative DOM manipulation library, any kind of HTML templating system is declarative out of necessity. Why? Because they all produce HTML in the end, which is itself a declarative markup language.