One could argue that it's not that React can't handle increasingly complex situations for you and that's why you spend more time on them, but that frontend as a craft has evolved due to React having solved the easy parts and has raised the bar, and therefore these complex situations belong to the next breeding site wherein the community is arguing about new solutions all the time, at the current time. It's healthy to retrospect how we got to this breeding site, yet there's always a certain doubt or even bias that what brought us here today is not what takes us forward tomorrow. It's like the reverse of Shiny Object Syndrome.
In time, I believe React can still take us forward.
What React does is no longer novel. People have both cloned React and have made other libraries/frameworks that accomplish the same thing differently or even faster in some cases.
Frontend craft has also become too complex in general. We really need to step back and decide whether all this fucking shit around SPA, SSR, route splitting, transpiling, everything-as-a-type, "me too" features between frameworks, overemphasis on trendy designs, package managers that wrap around other package managers, REST or GraphQL or RPC, etc. etc. etc. Much of which serves mostly to create corporate careers for developers more than to actually serve users.
React takes us forward in the sense that most of us don't want to go back to direct DOM manipulation or jQuery, and it's simple enough that it doesn't come with the same baggage as Vue, Angular, Ember, and so on. Even if React itself were to fade, the institution that is React I think will continue on for the foreseeable future.
> React takes us forward in the sense that most of us don't want to go back to direct DOM manipulation
There was recently a demo of what a Todo MVC app might look like if written in vanilla JS with today's apis. It looks fairly decent; I could see myself going back to something like that:
It's definitely feasible and even pleasant to write a frontend app in vanilla JS, if it's relatively simple. I hate to be that guy, but... does it scale?
Perhaps it can. I haven't really tried to write a large scale frontend app in vanilla that is similar in complexity to apps I've worked on that have millions of users. Maybe it's feasible, but it would take a lot of dedication to "do things right" by the developers on the team.
Also, reactive templates pretty much kill any desire I would have to by relying on direct DOM calls. With something like React or Svelte alone, there's practically no disadvantage to using them even strictly for rendering besides added file size. With vanilla, it would take more effort to make things efficient because you don't necessarily just want to call render() whenever something changes. It's really nice having a templating system that allows you to change things surgically without doing a lot of extra work rerendering things that shouldn't actually change.
However, I think vanilla JS rendering definitely has a place in terms of writing small, purposeful, modular components. Frameworks should make it straight forward to use vanilla components so that things that would be more succinct in vanilla can be written as such.
> Much of which serves mostly to create corporate careers for developers than to actually serve users.
I'm a developer that's done with this, but it brings in VC money so in my experience it serves mostly to create opportunities for CEOs to get some more money on the table via buzzword pitches.
In time, I believe React can still take us forward.