I understand if it was the early 2010s where mobile devices had limited power but today every user's phone and computer is going to be more than capable of handling whatever Javascript you throw at it.
EDIT: for more detail even on my M1 Max MacBook Pro, it is still very noticeable how long it takes JS-heavy SPAs to become interactive. Clicking things doesn’t even work for several seconds often because downloading and executing JS takes that long.
Now take into account users around the world on crappy internet connections with slow business laptops or the cheapest Android phones ever trying to load your SPA… bad times.
Even putting device performance aside, doing fetches and computation on people’s browsers somewhere distant in the world on a crappy 3G connection, rather than between colocated servers on speedy networks, is a recipe for bad web performance.
And that’s putting aside the need to protect secrets, optimize SEO (to serialize webpages for robots that won’t run your JS), simplify your application (server rendering eliminates the need for 90% of frontend state management, no need to expose API endpoints just to expose data on pages), the list goes on.
SSR to help with page loading seems like a poor reason. I'm sure there are exceptions, but so many sites make gobs of requests for bazillions of elements (trackers, ads, etc.) anyway. Seems like there is lower hanging fruit we should check out first.
Doing it for SEO just makes me sad - a major architectural change just to try to keep up in the never-ending chase to make Google happy is depressing.
The big upside in moving dynamic rendering to the client for me was that it then made it far easier to have a cleaner separation of duties between a web designer and a developer. You take a graphical designer and have them master HTML/CSS and they can then create the initial design, make it into valid HTML/CSS files, be responsible for things like site responsiveness on different screen sizes, browser quirks, most of accessibility tasks, etc. The developer's job is to "wire it up" - things like populating the data, making the site react to user input, and so forth.
The big win was that this division of labor is not only enabled at the outset, but it is relatively easy to maintain through the entire life of the site. We had tons of sites where there were design refreshes with little (and in a few cases, no) developer work. When I see SSR tools now (as well as client frameworks that chop up the HTML into chunks and then intertwine them with code) my first impulse is to wonder how that gets maintained and updated. Like, when the UI is redesigned and reorganized, does all of that code have to be rewritten? When something doesn't work right on Safari, can the web designer help much or is it all on the shoulders of the dev?
Sad for me is also current state of responsiveness - we had 20 or maybe 200 times slower hardware and website felt faster than now. Maybe it’s how the stars are aligned, but maybe it’s building multiple virtual element trees and discard them every click or event that happens on webpage. I dream about feeling this 20x increase in responsiveness as hardware should allow.
80% of contents are texts, I can't understand why this whole internet become slower. I bet it would be slower even if we get personal quantum computer or whatever that has supercomputing power.
more animation, more effects, more popup, more crap ... that does not improve UX even 0.001%.
API key secrecy, SEO, etc