I still don't get why RSC is better. This post takes things for granted that don't seem obvious to me. Why would I want heavy rendering tasks to all be done on my wimpy aws box instead of the clients macbooks and iphones?
Shipping moment for dates is a pain sure but that can be chunked and cached too? It's hard to imagine the benefit of reducing bundle by X kbs could really be worth doing a roundtrip to server whenever I need format a date in the UI.
RSC seems like something only library maintainers like, although I appreciate tanstack not forcing them down my throat like next I guess.
If your use-cases don't benefit from RSC performance characteristics then they probably aren't outright better.
But I do think they're a compelling primitive from a DX standpoint, since they offer more granularity in specifying the server/client boundary. The TanStack Composite/slots API is the real selling point, IMO, and as far as I can tell this API is largely (entirely?) thanks to RSCs.
The article lists the significant performance gains. Why render on wimpy phones over bad network when a cheap aws box can do it for you?
That aside, Next.js and the recent related vulnerabilities made me weary of RSC and I struggle to see the benefit of RSCs over the previous server side rendered and hydrated model. Chances are TanStack will do a better job than Vercel and yet the bumpy ride of the last few years tarnished the whole idea.
1. Rendered content, if there is enough of it, will be more content to send across wire than a cached bundle.
2. Cached bundles are cached. Network doesnt matter when its cached
3. Even bottom of the barrel motorolas are not wimpy nowadays
4. The obvious reasons why I dont want my aws box to do rendering is because it will need to everyone's rendering, and how big "everyone" is in not constant. It's another moving part in a complex system that can break. Also because I have to pay for the box.
5. Fast networks are becoming more and more ubiquitous
6. The performance gains are for a static site, which won't necessarily be representative of typical saas. How do you measure the risk and cost of my site breaking because my date rendering server got overloaded?
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.
> 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.
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.
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.
I've been a big fan of TanStack start and have a few small apps (<10k users) in production running on TSS.
The DX is smooth, the defaults are sane, and things generally makes sense if that makes sense. There are plenty of skills available so Claude Code and Codex know how to work with it too.
If you're maybe finding Next a bit bloated these days, I'd recommend giving this a try. Plus Tanner, the creator, responds to almost every mention on Twitter so it's easy to get eyeballs on issues that you might face. :)
> Next.js App Router is server-first: your component tree lives on the server by default, and you opt into client interactivity with 'use client'.
> TanStack Start is isomorphic-first: your tree lives wherever makes sense. At the base level, RSC output can be fetched, cached, and rendered where it makes sense instead of owning the whole tree. When you want to go further, Composite Components let the client assemble the final tree instead of just accepting a server-owned one.
The sudden server-first change on Next.js App Router definitely trips some people, especially since React started as client-only library.
Excited to try it out. I'm perhaps less excited about having to wrap RSC's in special functions, but given the Query example I suppose it makes sense. I'll reserve judgement until I've properly tried it out.
How does this work with Suspense (without Query) and the 'use' hook from React?
It works, but once again, you will be left without a stable native caching mechanism in React unless you put the stream into state. Use Query, or Router, or something.
> We intentionally do not support 'use server' actions, both because of existing attack vectors and because they can create highly implicit network boundaries
Mmm. Very nice.
Explicitly avoiding turning react into “webforms” and focusing on the actual point of RSC seems like the path RSC should have had from the beginning.
Magical RPC so you could “use server” and not bother to write an API properly was never the point of RSC, and the CVEs showed why it was a bad idea.
If NextJS isn't nearly entirely replaced by TanStack Start universally in the next 2-3 years we'll know VC money has landed the final blow in 'VC vs Js Ecosystem'
Can we please go back to template-based server rendering (e.g. JSP, PHP, ASP, Handlebars/Mustache) and use JS for user interactivity only? Tired of seeing this cycle play out with a new framework every 5-6 years.
There are benefits to having the same type system throughout a code base. Also Typescript is a really nice language.
The other issue is, many websites are basically apps. The HTML is a byproduct, it isn't the main event. The template based systems are fine if you have mostly plain HTML with some interactivity sprinkled in, but for people who are building complex web apps, there is typically a tiny bit of HTML and a lot of logic.
The old template based systems fall to pieces for really complicated sites.
In regards to language, if you are going to pick a JITed or interpreted language, may as well pick one that has had a lot of effort put into making it fast, and the JS runtimes are really optimized by now. Java is faster, but Typescript is a much better language (and more type safe!) than Java.
I have good news: all that you mention is still available and ready for you to use! It has not been deprecated in any form and as far as I know it has not been made illegal.
If, instead, you wanted to say "can everyone please use the things I like?", I'm sorry but that's not how it works. You don't get to tell people what they should do just because you're "tired".
Shipping moment for dates is a pain sure but that can be chunked and cached too? It's hard to imagine the benefit of reducing bundle by X kbs could really be worth doing a roundtrip to server whenever I need format a date in the UI.
RSC seems like something only library maintainers like, although I appreciate tanstack not forcing them down my throat like next I guess.
But I do think they're a compelling primitive from a DX standpoint, since they offer more granularity in specifying the server/client boundary. The TanStack Composite/slots API is the real selling point, IMO, and as far as I can tell this API is largely (entirely?) thanks to RSCs.
That aside, Next.js and the recent related vulnerabilities made me weary of RSC and I struggle to see the benefit of RSCs over the previous server side rendered and hydrated model. Chances are TanStack will do a better job than Vercel and yet the bumpy ride of the last few years tarnished the whole idea.
2. Cached bundles are cached. Network doesnt matter when its cached
3. Even bottom of the barrel motorolas are not wimpy nowadays
4. The obvious reasons why I dont want my aws box to do rendering is because it will need to everyone's rendering, and how big "everyone" is in not constant. It's another moving part in a complex system that can break. Also because I have to pay for the box.
5. Fast networks are becoming more and more ubiquitous
6. The performance gains are for a static site, which won't necessarily be representative of typical saas. How do you measure the risk and cost of my site breaking because my date rendering server got overloaded?
They are: https://infrequently.org/2025/11/performance-inequality-gap-...
That said, RSCs and the rest of the "let's render a static site but let's also send a multimegabyte bundle for 'hydration'" is still wrong
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.
Also SSR, even in React, existed well before RSCs did, and that seems to be really what you are talking about.
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/
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.
The DX is smooth, the defaults are sane, and things generally makes sense if that makes sense. There are plenty of skills available so Claude Code and Codex know how to work with it too.
If you're maybe finding Next a bit bloated these days, I'd recommend giving this a try. Plus Tanner, the creator, responds to almost every mention on Twitter so it's easy to get eyeballs on issues that you might face. :)
> How does this compare to Next.js App Router?
> Next.js App Router is server-first: your component tree lives on the server by default, and you opt into client interactivity with 'use client'.
> TanStack Start is isomorphic-first: your tree lives wherever makes sense. At the base level, RSC output can be fetched, cached, and rendered where it makes sense instead of owning the whole tree. When you want to go further, Composite Components let the client assemble the final tree instead of just accepting a server-owned one.
The sudden server-first change on Next.js App Router definitely trips some people, especially since React started as client-only library.
How does this work with Suspense (without Query) and the 'use' hook from React?
Mmm. Very nice.
Explicitly avoiding turning react into “webforms” and focusing on the actual point of RSC seems like the path RSC should have had from the beginning.
Magical RPC so you could “use server” and not bother to write an API properly was never the point of RSC, and the CVEs showed why it was a bad idea.
If NextJS isn't nearly entirely replaced by TanStack Start universally in the next 2-3 years we'll know VC money has landed the final blow in 'VC vs Js Ecosystem'
The other issue is, many websites are basically apps. The HTML is a byproduct, it isn't the main event. The template based systems are fine if you have mostly plain HTML with some interactivity sprinkled in, but for people who are building complex web apps, there is typically a tiny bit of HTML and a lot of logic.
The old template based systems fall to pieces for really complicated sites.
In regards to language, if you are going to pick a JITed or interpreted language, may as well pick one that has had a lot of effort put into making it fast, and the JS runtimes are really optimized by now. Java is faster, but Typescript is a much better language (and more type safe!) than Java.
If, instead, you wanted to say "can everyone please use the things I like?", I'm sorry but that's not how it works. You don't get to tell people what they should do just because you're "tired".