In Next.js 15, is there a reason to use RSC and SSR together?

[jeongminsang]

Summary

Hello, I am a junior developer studying RSC.
In next.js 15, I know that all components are RSC by default. (Although RCC is possible individually)

1. But do I have to use SSR as well?
2. When I create a new project with create-next-app, only RSC is used by default and SSR cannot be found. Am I mistaken?
3. If it is true, isn't this a project that does not use SSR in the new project and does not take advantage of SSR?

Additional information

No response

Example

No response

[icyJoseph]

SSR is a blanket term, for generation/creation of HTML strings, on a server, which are then sent to a client. How this is created, how is it sent, etc, are implementation details.

RSC, are React Server Components. These are a new type of component, which, among other things:

• doesn't need to sent their JavaScript to the client, for hydration
• run exclusively server side

What you call RCC, I guess means, Client Components, these are the components we have used all the time, up to this point. Worth mentioning that Client Components, are also SSR'd, reactwg/server-components#4

rsc is also a format, used by React, to communicate the shape of a UI tree, from the server to the client, during runtime. You can use tools such as https://rsc-parser.vercel.app/, to understand this text format.

So using Server Components, necessarily, implies SSR.

Frameworks such as Next.js have also introduced a new SSR capability, build time generation. That is, pre-rendering pages, to have HTML, CSS, and JS, upfront, so that when the server is running serving requests, content can be served directly, without rendering on-demand, as the request arrives. That's fundamentally, the paradigm introduced by the Pages Router, and incrementally it was enhanced to regenerated, or even create new pre-rendered content, during runtime.

There's now an experimental feature called, Partial Pre Rendering, which aims to make a mix, of pre-rendering a React tree, leaving wholes for dynamic on-demand, subtrees.

[jeongminsang]

Thanks for the reply.
I don't quite understand the part "using Server Components, necessarily, implies SSR.".
Is the reasoning that using RSC implies SSR because RCC is SSR? Or is it because RSC passes the shape of a UI tree from server to client at runtime?

[icyJoseph]

I think we are using different terminology.

According to, https://react.dev/reference/rsc/server-components:

Server Components are a new type of Component that renders ahead of time, before bundling, in an environment separate from your client app or SSR server.

So, Server Components, render in a different environment than the client, typically a browser. The place where Server Components are rendered, is the server, that's why they fall under SSR.

[blf885]

I've been trying to understand some of this as well. I think I can bring some clarity, but also have some questions. "using Server Components, necessarily, implies SSR" because a server component is fully rendered on the server before bundling it with the other client components. This means that RSCs are rendered on the server as HTML and only HTML is delivered to the browser for that component. This also means that they cannot be interactive (There is no JavaScript delivered for the component). So they are used to get static data that the user will see but is never functionally interactive. Then, once RSCs are rendered and bundled with client components, they can, as a bundle, be rendered on the server (SSR) allowing the client to receive meaningful content filled initial data for client components as well (rather than receiving just the index.html file and rendered RSCs and having it hydrated with the JavaScript later). Then, when the app is hydrated with JS it can become interactive (Like we would typically would expect from React) utilizing state variables, hooks, and other client component only features.

Some implications then:

• If you only had CSR components in your project, SSR would be redundant (or not even possible because there is nothing more to render?) because the CSR components would already be being fully rendered as HTML (But the app could not be interactive at all). Another way to think about this could be that SSR is by definition a characteristic of CSR and thus no additional render handling on the server is necessary to get SSR.
• You can SSR "client components" (if that is all your project has) or you can SSR the bundle that has both "client components" and RSCs. (This one I am not as sure about because I'm not sure how the process of loading the content for the client component works so that it can be rendered on the client side).

Does this seem to be a correct and understanding or am I off?