Yep. I think these examples are probably fine for the SPA style approach. What gets me is the other 98% of web apps out there, that are not collaborative document editors, calendars, or the handful of other use-cases where this approach can make some sense. It feels like a lot of complexity that has been cargo-culted into the mainstream.
Much of the "progress" in web development in the past decade feels like it's just fixing problems that only exist because we're building web applications this way. React, Redux, Typescript, Server Side Rendering.. these are solutions to problems we created for ourselves by using an architecture with a dubious value proposition in most of our use-cases.
Yeah, anything like what you described are going to be web apps and need all that logic. That being said for the majority of the web (news sites, simple message boards, shopping sites, etc) couldn't they all be rendered on the server?
I have to wonder how much of the client-side rendering framework use is mainly from people forming a cargo-cult around "it's what Facebook does" when at the end of the day what Facebook does is way different from your use case.
By strictly numbers, most engineers don't work at one of those tech giants, but at small firms making CRUD apps that don't really need all that responsiveness.
"Majority of the web" is _not_ news sites and message boards and shopping sites. It's bank websites, ERP software, various CRMs (granted, like news sites...), time tracking, logistics sofware....
And, importantly, a lot of those websites have complex admin-side backends to deal with a lot of things as well! Of course in those cases you might say that the UX requirements are lower (true), but when you are basically serving as a DB frontend, you want to be able to do things quickly, even on a really bad connection.
There's a lot of cool work into partials for SSR, but React and friends are also very nice because you can build out complex UIs that operate through an API, without having to figure out a bunch of workarounds for stateless HTTP/HTML (form wizards anyone?)
All those sites have content, which require elaborate, interactive, collaborative editing and reasonably complex, flexible data models. Meaning you’re going to want to re-use much of the work you did for the editing/publishing part and you want those things to be integrated to such a degree that changing and extending things is reasonably ergonomic.
Collaborative editors are the 1% of sites that are actually applications and need a SPA.
But Yelp is nothing like that. What part of the interface is so advanced? It's just a few links and buttons to navigate to pages and submit reviews. A few JS event handlers can handle AJAX/partial updates without an entire React frontend.
Personally I think htmx is an interesting strategy because it unifies the rendering tech on the server (you still gotta be careful to properly scope your incremental changes).
"Advanced forms" come up all the time, and are usually when you have even a bit of non-trivial business logic. For example "if people pick this set of options, show this other option" (but you want to avoid having a form wizard, cuz then you're having to track state across multiple page loads). There's also stuff like in business applications, previewing calculations and the like.
"A few JS event handlers" can handle a lot of tiny things, but many B2B SaaS have a handful of pages with a loooot of these things, and at the end of the day you could have your hacks, or you could try to be principled about loading it.
Though it's also about just finding the right mix, there are people who can architecture their stuff "correctly", completely SSR + some JS flavoring. But it requires having people who are really good at backend and frontend figuring out the right pieces and putting it together. That diligence is hard!
Much of the "progress" in web development in the past decade feels like it's just fixing problems that only exist because we're building web applications this way. React, Redux, Typescript, Server Side Rendering.. these are solutions to problems we created for ourselves by using an architecture with a dubious value proposition in most of our use-cases.