Explain server side rendering like I'm five. Why client side frameworks are there if they need/use server rendering?

Comments

[Kasey Speakman]

Client-side rendering is like getting a large toy at Christmas that requires assembly. Server-side rendering is like getting the same large toy pre-assembled and batteries included. If you get it fully assembled, you might still disassemble and reassemble parts of that toy (server-side + client-side rendering).

Scenario 1 (Client-side rendering)

You open a very large present to discover it is a barbie princess castle set, and it is completely disassembled. Dad hands you a screwdriver and says have fun. You put your construction hat on and spend hours going back and forth between the manual and the under-construction castle, putting it together step-by-step. Eventually construction is done. Your fiends come over, and they play with it.

Translation

You open a complex web app and it is completely client rendered. The CDN hands you all the assets and says have fun. You start initializing the client app and spend milliseconds or seconds going back and forth between the app's data API and the under-construction app, constructing the UI step-by-step. Eventually construction is done. Everything is now ready for the user, and they play with it.

Scenario 2 (Server-side rendering)

You open a very large present to discover it is a barbie princess castle set, and it is fully assembled. Your friends come over, and they play with it.

Translation

You open a complex web app, and it is fully server rendered. Everything is pre-loaded for the user, and they play with it.

---

AFAIK, server-side rendering is primarily to speed up the initial page load. Afterward, the client side takes over and can re-render parts of the UI as needed.

[Rajeev R. Sharma]

Thanks.

[Kasey Speakman]

Not sure if I addressed the point of: Why not just use server-side rendering all the time? Initial versions of web applications did just that, because Javascript didn't have enough features or performance to render client-side. To get new information from the server, you had to send the current state of the page back to the server (via form post, before AJAX) and let the server run logic, decide what to render next, and then render it as HTML+JS before returning to the client. Submitting a form caused the whole page to go into a loading state, effectively freezing the UI, until a network round trip + server processing was finished. Client-side rendering came later to make the UI stay interactive/responsive while requests were sent to the server. This provided a much better user experience, but often the initial load times were slow as the application files downloaded and initialized. Server-rendering comes back into the picture now as an optimization for the initial page load. Server-rendering can pre-compute the initialization phase of an otherwise client-side rendered app to save app startup time.

[Rajeev R. Sharma]

This one complements the previous reply and covers the second part very well. So it is a case of optimization which one should do for faster loading (initial load with server side rendering) and making use of client CPU for further route changes. Right?

But, what role SEO plays here? If we need to have server side rendering for SEO purposes then it won't just remain the case of initial page load, isn't it? We will need to have server side rendering for all those pages for which we need SEO, right? If yes, then why go for client side rendering at all?

[Kasey Speakman]

This is a good question that I unfortunately don't know the answer to. The vast majority of my work has been behind logins, so SEO is a non-issue. I actually have the opposite experience of setting up robots.txt and other things to block search engine crawlers.