Hacker News Reader

Comment by danielhep | Hacker News Reader

Without RSC you have to wait for the user to download the application bundle before the request for content can even be sent to the server. So that means that the db queries and stuff are not even initiated until the client has the bundle and runs it, vs with RSC that stuff is all launched the moment the first request comes in from the user.

View on HN

That doesn't seem to be how this implementation of RSC is intended to work. Here, client code triggers the RSC fetch, which is treated as any other sort of data fetch. Presumably, it still waits for client code to load to do that.

Also SSR, even in React, existed well before RSCs did, and that seems to be really what you are talking about.

Correct. People need to stop conflating SSR with RSC. Well said.

TanStack uses streams as the basis for loading RSC data, and recommends using a route loader to access them:

https://tanstack.com/start/latest/docs/framework/react/guide...

AFAIK, at least when using TanStack Router, this RSC implementation seems just as capable as the others when it comes to reducing server round trips.

SSR is different and does not provide the same performance of RSCs. With SSR you get the advantage of an initially rendered page, but you don’t have access to data or state. So you are just rendering placeholders until it hydrates and the client can request the data.

RSCs allow you to render the initial page with the content loaded right away.

That said, I am not sure about Tanstack’s implementation. Need to spend more time reading about this.

Here’s a nice post explaining why RSCs do what SSR cannot: https://www.joshwcomeau.com/react/server-components/

You have it reversed. SSR in react without RSC gives you access to data and state on the client. That's what the hydration does. RSC strips it out to make the bundle smaller. There is no hydration

I mean the state from the client, like cookies and URL params. You can get access to that in SSR through the framework specific APIs like getServerSideProps in Next, but it’s not a great solution.

> Without RSC you have to wait for the user to download the application bundle before the request for content can even be sent to the server.

This is an argument for not putting all your JS in one monolithic bundle and instead parallelizing data loading and JS loading. It's not an argument for RSC.

Even if you split up the bundle you will still need multiple round trips to the server to fetch the data.

Ignoring TLS we have:

1st RT: HTML and loader script (CDN)

2nd RT: data (app server) and code (CDN) in parallel

Therefore you need two. But not all roundtrips are equal. A roundtrip to a CDN is much faster than a roundtrip to an application server and database, unless you have some funky edge database setup.

If you render on the server, your first roundtrip is slow because the client has to wait for the application server and database before it can show anything at all. If you render on the client then your first roundtrip is fast but the second one is slow.

Reply on news.ycombinator.com