React's adoption was misguided
Since everyone is now talking exclusively about AI, allow me to do a bit of retrospection and take us back to the glorious days when people did the coding themselves and remotely understood what they were doing. Here I'd like to focus on the big move to React circa 2015-onwards.
My proposition is that React's main selling point, its React-ivity, wasn't at all the reason why it was adopted. The reason React was born, the Facebook-scale kind of problems it solved, were absolutely irrelevant to the majority of other web shops.
Facebook back then had timelines, events, users, an embedded chat, and a bunch of brilliant engineers inventing GraphQL and React and Flow (JS types before Typescript) to cope with the surreal amount of data they had to deal with before re-selling them to third parties.
Did every other website have the same needs? Absolutely not.
Was it necessary to tank every single pageload on the Internet with entire megabytes of uglified JS bundles that a miraculously-working Webpack config written 14 month before had managed to produce? Absolutely not.
Was the client-request-server-response insufficient to the needs of e-commerce shops, profile lists, rental shops, booking listings and admin tables? Did they have to tear apart their application state onto the client AND the server, only to reconcile it painfully after fixing the infinity of bugs that escaped through the crack? Absolutely not.
Was it worth the money, the time and the complexity to rewrite everything because a pageload was considered too slow? Absolutely not, unless you're Facebook and it's still 2013, which is when React was born.
The reason React was such a big success in the industry is because it provided some software patterns and conventions, namely about how to render some HTML and react to it.
The other frameworks had done that for the rest of the web stack: Rails and Django had already figured out ways to write code without letting programmers ruin it all with their rampant mediocrity: it was branded "Convention over Configuration" and it meant that you could only screw your business logic rather than the standards ways of working with a web application.
But they'd kinda left out the frontend, maybe because it was still complex to devise something that worked well in a blank HTML page, with its evolving specs and diverging browser support. You had views and some templating language but that wasn't structured enough to prevent a bunch of lousy programmers from writing terrible code and undecipherable frontends.
Some people invented jQuery, others BackboneJS, but despite the beautiful vision they'd set out to fix the ungodly world of frontend other people used these to write even more ungodly code as they hammered unnecessary features and proceeded to invent a vast repertoire of UX antipatterns in the process.
React brought the structure of programming into views and turned them into actual software: it forced the distinction of entities (components) into classes or functions, with callbacks, parameterization, dependency injection and the whole spellbook of software programming to it, be it tests, coverage, linting, etc.
This forced the terrible programmers to observe a bunch of established software conventions, patterns and rules that made the whole experience a lot easier for engineering teams. It didn't prevent them from shipping bad software to their users, i.e the rest of us navigating bloated pages full of loading spinners, interactivity bugs and flickering data, but at least the code was somehow manageable.
And that's what React was about: making view development structured and pushing it past the stage of substituting strings into some giant HTML-like file. Its adoption was a benefit to the engineering world1 and in hindsight didn't actually do much in regards to the actual experience of the web (let alone the painful period of transition when nothing actually worked in 2017): we still mostly fill in forms and browse pages sorted in menus: the fact that we now ship it over the page to avoid some obsolete speed benefit is irrelevant.
But it made bad programmers a bit less bad, and that's always something to cheer for. AI is also promising to do that at the moment but it's only making them worse by removing the one thing they had to get better at.
Hopefully they can keep it on for a bit longer before we realise the problem was never, and probably never will be, the machine and its capabilities but the terrible people who write code behind them.
Footnotes:
which subsequently went to reinvent routing, state management, database ORMs and everything they'd left in the beautiful world of web servers, where it belongs.