[krishadi]

> But I was equally surprised by how little this was being discussed, or (as far as I could tell) practiced in the real world. While there seemed to be endless threads on Twitter about server-side React (to get the UI generation closer to the data), no-one was talking about the opposite: moving the data to be closer to the UI, and onto the client!

This, I've wondered for a while. There is plenty of talk about server side rendering, which I don't think is useful for many apps out there. SSR is quite wasteful of the resources on the client side that can be made useful. And, I've seen many apps being developed with "use cliënt" littered all over, and that begs to wonder why do you even want SSR in your app.

[zwnow]

Wasn't the reason for SSR to have more control over security and offload work from the client to the server? Let's not forget that the majority of the worlds population is using slow ass tech. We cant simply put huge workloads to the client.

[indymike]

I think the main drive for the modern version SSR was SEO. The workload part? the whole point of SPAs was to move compute - especially fancy UI compute down to the client so the server only had to move data... so we're just completing the circle again.

[dplgk]

Funny that bad SEO was a big strike against Flash and a reason to move to HTML5

[krishadi]

It was mainly for SEO, and to some extent protecting against website scrapers and crawlers.

[ZYbCRq22HbJ2y7]

SSR just means you render on the server, it isn't whatever you are describing.

[krishadi]

It is exactly what I am talking about. Rendering the component on the server, takes up resources, as opposed to just sending that data to the client, and the client rendering it.

In Nextjs, "use client" is used to force the rendering to take place in the client, because many components cannot me rendered in the server. For example maps. In this case, it's unnecessary to use an SSR framework.