Server side rendering with next.js vs traditional SSR

Question

I am very used to the approach where SSR meant that the page got a full refresh and received a full HTML from the server, where it gets rendered with razor/pub/other depending on the backend stack. So every time the user would click on the navigation links, it would just send a request to the server and the whole page would refresh, receiving a new HTML. That is the traditional SSR which I understand.

With SPA however, we have for example react or angular, where we receive almost empty HTML on the beginning and then the JS so that the whole app gets initialized on the client side. We can then have some REST API to get json data and render views on the frontend (client side routing and rendering) without any page refresh. We don't even need any server really.

Now, what I have a problem understanding is how SSR (such as next.js) works with react.

From what I am reading, the first request returns full HTML+CSS (which helps with SEO etc - I get that), but what happens later? What happens after that first/initial request? Does the whole react app initialize in the browser and then it just behaves EXACTLY as if it was a normal SPA (meaning we have client side routing and rendering from now on, without any need to make requests to that server)? In other words, does next.js still make any server requests after the initial one, or does it act like a typical SPA with CRA from now on?

I spent lots of time reading but all the articles mainly focus on the initial request and SEO and time to first byte, paint etc. and I am simply trying to understand why its called SSR since it seems to work different than the traditional SSR which I described on the beginning.

Denture

Answer 1

does next.js still make any server requests after the initial one, or does it act like a typical SPA with CRA from now on?

You got it right. The first (initial) request is handled by the server and after that the frontend handles the routing (at least in the case of Next.js).

If you want to see an example OpenCollective is built with Next.js. Try playing around with it and see the Network tab in the DevTools.

I am simply trying to understand why its called SSR since it seems to work different than the traditional SSR which I described on the beginning.

It is called SSR because the app is effectively being rendered on the server. The fact that frontend routing takes over after the initial render doesn't remove the fact that the server did the work of rendering the app as oppose to the user machine.

Villegas

"server did the work of rendering the app as oppose to the user machine", so Next.js sends requests to server (like node) and gets the rendered page? or it just "behaves" like a server? – Graaf

Not sure what do you mean by "behaves like a server". Next.js is a Node server. It takes the js files of your app, builds them, and sends HTML/CS/JS back to the client. – Villegas

The effective difference with NextJS here is that it "hydrates" the page again using client side JS (React) in its SSR methodology. As @JohnnyZabala pointed out, its more of a node server, than a client side framework/React framework. – Rettke

Answer 2

That's Not all the things that happen with Next.js, In Next.js You can build something called Hybrid apps.

In traditional SSR, all of your client requests get handled by the server. Every request goes to the server and gets responses. In classic CSR with something like React, as you said, all the things happens in the browser via the client-side javascript.

But, in Next.js you can define three different approaches (mainly two according to the docs) for pages to get delivered. based on the app needs and requirements, you can serve a couple of pages in pure traditional SSR mode, a couple of them in classic CSR mode, and a couple of in SSR mode via dynamic data that get fetched and rendered into the pages on the fly.

these features bring lots of flexibility to design a web-app that behaves perfectly in every different scenario that is needed.

Marielamariele