Can someone explain the use case for these frameworks i.e. why do I do want to render things server side.
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.
especially with mobile there are millions situations where your internet is bad, slow and patchy. you have A LOT of people using low-end devices in battery saving mode so also throttling the already bad performing devices – read this series if you need to understand why doing server side rendering is an exercise in accessibility https://infrequently.org/2024/08/the-landscape/
Agreed, and so far the replies to your question are (for me at least) deeply unsatisfying. We already had SSR back in the CGI days, and it was awesome when we moved a lot of that stuff to the client. I know this is all a giant Wheel of Time, but I'm not ready for us to go back just yet. :)
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?
Over-taking that approach we have 20MB+ websites (images excluded) and maybe hardware is faster, but connections are not improving at the same pace.
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.
HTML streaming from the server is 1 single request to the server and the user sees the changes much earlier. On the other hand, if you render from the client, only if you need data, you already have to make requests to the server and the user will see the data much later. However, if your pages are static, you can do this rendering process in build-time and you can avoid having a server and upload the files to a CDN already pre-rendered.
Even in MBA M2 2003 laptop, still so many sites are slow.
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%.
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.