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.