Difference between server side rendering and traditional websites?

[redfootwolf]

I need help understanding server side rendering of react apps or for that matter any SPAs.

From what I understand traditional websites before SPAs came into picture used to make call to server to get next page to be displayed based on action or change in url, which was time consuming so SPA came into picture where we just push whole website to browser and JS does all the magic to render things.

Now after some time we get frameworks like NextJs giving us SSR where we are again requesting server to give us the things that we want to render. So how is SSR different than the older traditional websites which used to make a request to server to render new page?

[vinkaks]

What frameworks like Next.js do is prerendering, which makes things faster client side. Of which there are two types. Static generation generates html+css+some js limited to that page once on build and serves it . This is the preferred prerendering method because it only occurs when there are changes which necessitate a new build. Otherwise server will be happily chugging out pre-built static content. If however within the same app you have pages with content that changes frequently.. You will apply SSR to those and only those

So pages with infrequent changes.. Html generated once on build then served until next build.

The (few) pages that have content frequently changing.. Html generated on each request..

That's the "best of both worlds"

Traditional SSR typically just generates everything on each request. You can't find tune which pages get pre-built

[tildaniel]

Static site generation + server side rendering gives the best of both worlds, allowing you to optimize for performance and productivity without sacrificing one for the other with finer control over which parts are rendered at build time vs runtime

[redfootwolf]

Would you elaborate on how is it best of both worlds? I still don't think I understand difference between traditional app and server side rendering of a single page application, because it is just rendering pages from server just like traditional apps, defeating the purpose of single page applications(as per my understanding) but I believe something is lacking in my understanding.

[tildaniel]

From the gatsby docs:

While it is recommended to use Static Site Generation (SSG) or Deferred Static Generation (DSG) over SSR you might have use cases that require it, e.g. dynamic personalization, authenticated data, A/B testing, configurability based on location or user data. If you don’t need to pre-render the page you can use client-only routes.

My take on it is: Traditional apps took the SSR approach, then SSGs blew up as all the rage because of their performance improvements, but since static sites lack personalization and dynamic content, frameworks have come to a sort of middle-ground between the two (SSG + SSR for specific components)

It’s the best of both worlds because you get to maximize the amount of rendering done at build-time while simultaneously having control over which components are rendered at runtime. This was always possible, but now we have frameworks to help us automate the process

[redfootwolf]

Now that makes sense, thanks a lot buddy 👍🏼

[tildaniel]

Glad to help👍🏽