> But what I find is that most large, complex applications I've worked on are not in particular hindered by the choice of React as a technology.
AKA, React is accidental complexity. Solving accidental complexity issues may be required some time, but more often than not, it's just something you endure as the alternative choices are not that much better.
Why are the alternatives not better if, as you say (and I agree), react solves its own problems (accidental complexity)? not some essential complexity (at least not anymore).
State management and optimized DOM manipulation can be achieved with vanillajs nowadays and I'm not saying that as a purist, it is just good enough that React is not needed. To help a bit with the ergonomics, I use lit-html/uhtml for the templating but they are both based on template literals, a native JS feature.
> Why are the alternatives not better if, as you say (and I agree), react solves its own problems (accidental complexity)? not some essential complexity (at least not anymore).
The essential complexity was the interactive need of your UI. Any of the current web framework can be a solution. The only reason to go for React is hireability (almost anyone knows it) and devex (so many prebuilt components). But it's not like that the others are so hard to learn and components are hard to build.
> and devex.
> But it's not like that components are hard to build.
I think we need to be clear about what scope we are talking about. A full fledged data-heavy B2B application, or something simpler like a web shop?