Comment by Mario Giambanco on "What's server side rendering?"

The term became more popular with NodeJS and Javascript frameworks but it basically means, assembling or compiling the HTML and other various resources on the server side first; then spitting it out to the client.

Before frameworks and libraries and such - you could say most programming languages did this - and still do to a certain point. In PHP for example (cause that's what I know best) - you could do echo "<div>hello world</div>"; on the server and that html would be outputted to the client - server side rendered.

"Rendering" has taken on a much more complex form now though - now, rendering means to determine what is needed; build the components and send that to the client. So in the case of auth - the server might determine the logged in user is an Admin - compile and "render" an Admin menu item and send that to the client.

React and other frameworks rely heavy on this (not a react pro) - they do most of the heavy lifting on the server side and the client gets just what it needs to interact with the page / site.

You could consider it a separation of duties, but IMO, not in a traditional sense. It can be more efficient for the client as your taking the load off of the client and putting it on the server, but it can also be more expensive as now the server is responsible for more heavy lifting (and your paying for the server) and the client is doing less (your not paying for the clients power)

From what I know, React is a client-side framework, and all the work is done by the client (all the code is in the client). That's why they're called a Single Page Application (SPA), all the logic is in the client and always calculates what to render.

From MSDN: "Single-Page Applications (SPAs) are Web apps that load a single HTML page and dynamically update that page as the user interacts with the app. SPAs use AJAX and HTML5 to create fluid and responsive Web apps, without constant page reloads. However, this means much of the work happens on the client side, in JavaScript."

A Single Page App has nothing to do with server side rendering. You could very well have a SPA - be it react or AJS that makes an ajax call to a server running your language of choice and return html / css / js that can be injected into the SPA.

Nothing would stop me from assigning ng-app to the top most div in a AJS app - checking the url via ui-router and calling out to index.php (server side render) and returning the contents and injecting it into the div. It would be a bit clunky for sure and I'm not sure why you would want to do it, but it sure is possible.

My use of react in my response is that generally, react apps need to be interpreted and that interpretation generally happens on the server side in NodeJS. Can react be used by itself? Sure! It's just a view - but it's 99% of the time used on the server side, rendered, and just the outcome is sent to the client.

From here

The most common use case for server-side rendering is to handle the initial render when a user (or search engine crawler) first requests our app. When the server receives the request, it renders the required component(s) into an HTML string, and then sends it as a response to the client. From that point on, the client takes over rendering duties.

We will use React in the examples below, but the same techniques can be used with other view frameworks that can render on the server.

Re-read the link in your last comment - specifically server.js and renderFullPage code block. Is React not used in that code? Does that code not exist on the server side? That block is rendered via React and NodeJS on the server side. What the client does with it is a completely different question as this question pertains to server side rendering; not client side.

Search Hashnode