Can anybody explain server-side rendering to me like I'm five? :/

Sounds more complex than it is
Basically take images and put them on top of each other, or draw text on some image (generally called canavas if that's what you're working on)
After you are done you output the result somewhere

@Kimmax I think you took it literally.

@fyzrn Let's take a website which uses a modern JS framework to render the webpage.

When you go to that website, the server sends a webpage which has a JS script that renders the whole website. So by default, the webpage is empty (There is a minimal amount of HTML code) . If the page fails to load that JS script, it won't render anything, you will see a blank white page. That script is responsible for rendering everything on that webpage.

What is the problem here? First one is easy, if you have a very slow internet speed, downloading that JS script might take a second or two (or even more). So with a slow internet connection, the client will be waiting for 2-3 seconds before they see anything in that page.

This affects the search engines a lot. An engine like Google won't want to wait for that 2-3 seconds for the page to render to scrap information, as it has millions of pages to scrap every day.

What is the solution? The solution is to render parts of HTML from the server before it send the webpage to client. Server has fast access to the JS script and database. What the server can do is take that JS script and render part of the HTML (or everything) and send that to client. In that way, when the client receives webpage it's not completely blank. The client has something to look at or read while the JS script is loaded in the background.

For example, you can render the front banner from the server-side and leave the rest of the page unrendered. When the client visits the website, they see the front banner. While they are busy looking at that, the JS script in the background finishes loading and renders rest of the page.

Feel free to ask more questions.

@tahnik righhhht
I thought of the devbanner rendering lol
Did too much with that in the last days

@tahnik awesome answer. Can I ask as well?

But, wont it be like giving too much extra load to the server?

@IndoDev sure.

Depends. Most of the time, compared so the power of a server, it doesn't put that much extra load. If you think about the days when web applications were non-existent, the server was doing all the rendering using PHP or something else.

But if you have a website that is served to millions of users and you get thousands of requests per second, you obviously need to plan the server load carefully. That's why rather than rendering the whole page, you only render some areas. Areas that really matters and will hold the attention of the client for a second.

There is also this concept called Code Splitting. Where a webapp is divided into multiple chunks and loaded asynchronously. But that's a whole different story.

@tahnik that's a complete, explanation. Thanks for it, I can kinda figure it out now 😁

Here is the most simple explanation I can give.

The server builds the Dom before it sends the code as apose to sending just the JS and templates and letting the client build the Dom.

It helps with seo and load times.

@jamesharrington also it helps forget about fouc, and many other small subtle thing on SAP building. Tbh I think it's a bless especially when frameworks support it out of the box (react / Vue)

@DLMousey @tahnik so if I run a Rails backend with ERB or HAML template injected with some Ruby code, and parts of the page are rendered client-side by JS, it counts as server-side rendered?

Great explanation btw! :D

@f7u12 yeah my dad mocked me yesterday because I don't use SSR on my website 😂

"Talk to me when you finished implementing SSR!", he said.

Lol jk, I'm 23 and my dad doesn't even know what a website is

It's like the server is mommy bird who eats shit and pukes it into the baby birds (clients) mouth..

@fyzrn yes, part of your website is using server-side rendering.