You don't need something like React for building rich GUI today but once you have a sufficiently large codebase and a large team of developers, you're going to end up building inferior in-house versions of libraries/frameworks like React/Redux just to have any sane structure in maintaining the application as well as support future feature development. The currents state of front-end is complicated but I absolutely prefer it over the chaos of old timey vanilla javascript.

s/inferior/superior/ but not widely understood.

React is a great way to do progressive enhancement: you can have the same component code run on the server and client. On the server, it will only be used for creating static html. On the client, the component code will bind to the already generated HTML and allow client-side interactivity.

Writing rich UIs with progressive enhancement without this benefit was over-complicated pain before React. All of your UI code would either be based around binding to static HTML generated by the server or be based on locally-generated elements; if you ever had a widget that had been generated by the server that you now want to generate client-side in some context, or vice-versa, then you had to have multiple separate code paths on the client for that in addition to the separate server-side code for the widget. Having the component's code defined once in a way that works for all three contexts (client-side generation, server-side generation, client-side binding to server-generated HTML) is great.

I think people assume that because React is a newer way of doing things that it doesn't work well at the old goals (progressive enhancement) but the opposite is true!

It doesn't need to be this complicated. Unless you want to efficiently re-render the minimal amount when something changes, which you probably do if you have a big UI and want your users to like using it.

If you're trying to write applications in a web browser (putting aside all arguments about if we should) then you need to care about rendering performance. And that means dealing with the underlying problem, which is correctly invalidating and regenerating the minimal subgraph of a big dependency graph. And the framework people are constantly trying to find the best way to present the inherent complexity of this problem in a good way, without too much additional complexity.

A tiny dom lib like https://github.com/WebReflection/uhtml is more than enough for very complicated UI, with understanding how events work, will be able to implement very thin state management on top. With game programming styled manual render() call here and there as needed, pretty neat.