I had developed sites for 25 years. I still have a corporate site that was developed 20 years ago, and it returns more results, and is faster to render than most of new fangled SPA I seen deployed on servers 20x larger.
I do agree with you that SPA (react and its ilk) have cleaner benefit of composability of components, but I would posit that AJAX and component state/props has made for less reliable web. I often find myself in situation where SPAs crash mid way during concert or flight purchase - be it JS error, or network instability. Reloading the page doesn't get SPA to resume where it crashed, but often throws additional errors, saying I am already mid way in checkout (but I can't continue), or invalidating session (but still remembering that my other session was in process of buying a seat, so I can't reselect the seat I wanted. Finally, they are terrible for bookmarking or sharing.
So the composability of components, a benefit, came with a need for developer to be extra careful about failure modes, resuming states, bookmarking directly to specific content. Most developers are not careful, and the old html per page model forces different mentality for dealing with failures, and content availability.
1) Annoyed by page refreshes
2) SPA's is a special skill now, frontend developers take pride in knowing everything about React, Vue, Angular and spending hours and hours updating their NPM dependencies. How can they justify all the time spent if it's not almost like a science?
3) Separates the frontend guys from the backend guys. Technologies like HTMX allows the backend developer to pretty much do the whole job, which concerns a few people.
I've looked a bit for examples of HTMX in the wild, and the only times I've found it it's been so slow I would have preferred a full page refresh which at least lets me bookmark/navigate properly and involves no JS at all. Not enough data to really form a strong opinion though, I freely admit.
I've seen that quite a few times. Basically moving the entire business logic to the frontend, so that the backend can remain elegant and generic (yet somehow complicated too). In the end it actually makes for a slower app experience and may cause insane complexity on the frontend.
But backend developers often need or have a desire to build a perfectly usable frontend for their service, without relying on a frontend person to start with. This could be due to project ambitions or budget.
but...
am i out of touch?
no, it is the children who are wrong...
Don’t mistake activity for achievement.