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.
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?
"I'd rather base my opinion on my own personal anecdote than based on stats". My "they are" was referring not to your specific Motorola, but to the "bottom barrel". Which, while improving, still doesn't even remotely justify the bundle sizes or "fat networks".
--- start quote ---
The median mobile page is now 2.6 MiB, blowing past the size of DOOM (2.48 MiB) in April [2025]. The 75th percentile site is now larger than two copies of DOOM. P90+ sites are more than 4.5x larger, and sizes at each point have doubled over the past decade.
...
Compared with early 2024's estimates, we're seeing budget growth of 600+KiB for three seconds, and a full megabyte of extra headroom at five seconds
--- end quote ---
Translation: for P75 (aka for 75% of users) to get a site load in three seconds you need to ship at most 600KB of Javascript
It's not 2010 anymore. Client compute is fast. Server compute is slow and expensive. 4G is ubiquitous and 3G is being phased out.
You can send a tiny amount of JS from a CDN and render on the client. You will save money because the server is efficiently serving JSON instead of doing a gazillion calls and string interpolation per request. The user won't notice.
Also, now that the server is responding with JSON it doesn't need to run any JS at all, so you can rewrite the server in an even more efficient language and save even more money.
Yes it is. Even a cheap Xiaomi is fast enough to render any application you can think of.
React is not the bottleneck. The bottleneck is all the bloat in the application code.
Webdevs act as if optimization isn't a thing and the only solution to any performance issue is to add more hardware. This explains the popularity of server-side rendering: it's a way of solving a performance issue by "adding more hardware" to the user's phone.
Yet, the user's phone was always perfectly capable of doing what they needed it to do. The problem is their application code is an unoptimized turd. They could optimize it but that would be work. Fortunately, a helpful cloud computing service has the solution: just offload your unoptimized turd to servers in the cloud!
"Sounds fantastic," the webdevs said. "Anything to avoid opening devtools."
Except, that's two bad technical decisions. The first is spending money on compute that they don't even need. The second is that compute now has to be JavaScript. What could be a highly efficient Rust or Go API server blasting out JSON at light speed is now stuck running JS and React. Somewhere, someone at Vercel looks at their quarterly earnings and smiles.
Just because data can be rendered to DOM on the client doesn't mean it always should be.
I'll try to render HTML wherever the data is stored. Meaning, if the data lives in a hosted database I'll render on the server. If data is only stored on the client, I'll render there.
Its less about bundle size in my opinion and more about reduced complexity and data security.
That said, I've never been a fan of RSC and don't see it solving the "reduced complexity" goal.
It's a really weird situation, but using public transport WiFi cured me of this thinking.
The amount of times that the initial HTML, CSS and JS came through, but then choked on fetching the page content was insane. Staring at a spinner is more insulting than the page just not loading.
That being said, I'm not a huge fan of RSCs either. Dumping the entire VDOM state into a script tag then loading the full React runtime seems like a waste of bandwidth.
Why should a low-powered Android phone be downloading and running a full Markdown parser or syntax highlighter? Stuff like that is obviously something that should be handled by the server and just returned as final HTML.
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.
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.
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.
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.
One example is that I have a fancy visualization in my app that is rendered in the server via RSC and just some interactive tidbits get sent to the client. If I packaged the whole visualization library it would have bloated my bundle size but instead I ship barely any JS and still get a nice interactive vector data viz experience. And the code just looks like normal react component nesting more or less.
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.
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. :)
We are also currently inmidst a migration from NextJS to TanStack Start and it's worth for the performance and resource gains alone.
NextJS' dev server takes around 3-4 GB memory after a few page click while TanStack / Vite consumes less than a GB.
This is something I noticed, originally I thought "AI" was the perfect tool for Vercel and Nextjs (current standard = future standard), but then I realized is the total opposite, their moat/stick is gone now, and Rouch that is smart I think knows this.
I switched a middle sized app to Tanstack Router + Vite while I was walking my dogs. Then 30 minuts-1 hour QA and it was done. This should have never happened before AI.
(I did switch because I was tired of the bloated network tab with 100 unnecesary RSC calls, the 5 seconds lag when clicking on an internal link, the 10 seconds "hot reload" after a change... I'm on a M4 MAX with 64GB of ram....)
Vercel's moat is DX in hosting, not NextJS. Consider, people who switch to TanStack Start still need a place to host and many would continue to choose Vercel.
Same principle applies, hosting in Railway has slightly worse UX, but with LLM's you don't need to write a single docker line anymore, so deploying on railway is way way less cumbersome than before, and you gain more control and less costs.
Having developed multiple react web apps from scratch over the last 5+ years at work, I always start with a fresh repo and add what I need myself. Nowadays, booting up a project with vite, eslint, prettier, redux (and rtk-query), tailwind etc. takes no time at all. Don't care about SSR.
Am I missing something by not using tanstack? LLMs tell me many things, all of which seem irrelevant (e.g. not using react router, SSR, request-deduplication etc. which are covered by the basic few deps I added)
> 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.
RSC was dead on arrival and frameworks like Tanstack and React Router only really adopted them because you wouldn't be considered a modern and idiomatic React framework without their support. So I get it. Cool, I guess. Not to diminish the massive effort the maintainers had to put in to support it btw, since the core React team made zero effort to help anybody but Vercel on this.
It's telling that we're 6 years in from announcement, and like 4 years in from the initial Vercel implementation (fuelled by the React core team working at Vercel) for this to land in the major React frameworks.
But nobody really wants this. There are better patterns surfaced in frameworks like SvelteKit and Solid. What people want is implicit RPC functions. That covers 90% of the use-case for RSC anyways.
My personal opinion is that all of this is BS anyways, and we're building on foundations that are fundamentally flawed. But I'm also well outside the JS ecosystem at this point, rejecting it for greener pastures (wasm). But that's besides the point.
Big ups to Tanner tho, Tanstack is the de facto best React framework at this point.
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.
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.
Agree that TypeScript is nice, especially for sharing templates and types between server and client. But you can still use TypeScript on the server without sending it all to the client, and without a complex and insecure protocol like RSC. I’m working on making this as simple and dependency-free as possible: https://mastrojs.github.io
Coming from years of Angular, I had convinced myself I wouldn't like JSX before even using it. Now, 4 years in, and I wouldn't trade it for anything. I spent almost 6 years writing Angular templates and I don't want to go back.
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".
Thank you. Every time I see a "Why can't we just go back to simpler days" comment it takes everything in me not to reply "No one is stopping you".
The idea that complexity arose out of nowhere and not because the web is doing things we couldn't have even imagined 10 years ago has always been wild to me.
Complexity mostly rose out of necessity, but the problem is it keeps being applied where it isn’t needed. Most projects don’t need Kafka, or Elastic, or Redis, or GraphQL, etc.
My main complaint is that by and large, the people who are applying these technologies heavy-handedly are doing so because they either think it’s needed, or because they don’t understand that simpler tools exist that could solve their problem.
> Most projects don’t need Kafka, or Elastic, or Redis, or GraphQL, etc.
I guess I just don't really see this being a problem outside of social media.
And I think another aspect that gets lost is that 20 years, your options were slim. Which means picking the right tool for the job was easier (because even if it wasn't the right tool, chances are it was as close as you were gonna get).
Things are different right now. Even something as ubiquitous as authentication is vastly different than it was back then. There's way more at play when picking tools nowadays, so it doesn't surprise me when people get it wrong.
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'
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.
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?
> Even bottom of the barrel motorolas are not wimpy nowadays
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
I am going to base my opinion on using the bottom of the barrel Motorola that I own rather than reading that novel
"I'd rather base my opinion on my own personal anecdote than based on stats". My "they are" was referring not to your specific Motorola, but to the "bottom barrel". Which, while improving, still doesn't even remotely justify the bundle sizes or "fat networks".
--- start quote ---
The median mobile page is now 2.6 MiB, blowing past the size of DOOM (2.48 MiB) in April [2025]. The 75th percentile site is now larger than two copies of DOOM. P90+ sites are more than 4.5x larger, and sizes at each point have doubled over the past decade.
...
Compared with early 2024's estimates, we're seeing budget growth of 600+KiB for three seconds, and a full megabyte of extra headroom at five seconds
--- end quote ---
Translation: for P75 (aka for 75% of users) to get a site load in three seconds you need to ship at most 600KB of Javascript
Is serialising a model and building JSON that much more expensive than rendering HTML?
It's not 2010 anymore. Client compute is fast. Server compute is slow and expensive. 4G is ubiquitous and 3G is being phased out.
You can send a tiny amount of JS from a CDN and render on the client. You will save money because the server is efficiently serving JSON instead of doing a gazillion calls and string interpolation per request. The user won't notice.
Also, now that the server is responding with JSON it doesn't need to run any JS at all, so you can rewrite the server in an even more efficient language and save even more money.
> It's not 2010 anymore. Client compute is fast.
It's not: https://infrequently.org/2025/11/performance-inequality-gap-...
Yes it is. Even a cheap Xiaomi is fast enough to render any application you can think of.
React is not the bottleneck. The bottleneck is all the bloat in the application code.
Webdevs act as if optimization isn't a thing and the only solution to any performance issue is to add more hardware. This explains the popularity of server-side rendering: it's a way of solving a performance issue by "adding more hardware" to the user's phone.
Yet, the user's phone was always perfectly capable of doing what they needed it to do. The problem is their application code is an unoptimized turd. They could optimize it but that would be work. Fortunately, a helpful cloud computing service has the solution: just offload your unoptimized turd to servers in the cloud!
"Sounds fantastic," the webdevs said. "Anything to avoid opening devtools."
Except, that's two bad technical decisions. The first is spending money on compute that they don't even need. The second is that compute now has to be JavaScript. What could be a highly efficient Rust or Go API server blasting out JSON at light speed is now stuck running JS and React. Somewhere, someone at Vercel looks at their quarterly earnings and smiles.
Seems like using a low tier android gives you a nice reality check.
Just because data can be rendered to DOM on the client doesn't mean it always should be.
I'll try to render HTML wherever the data is stored. Meaning, if the data lives in a hosted database I'll render on the server. If data is only stored on the client, I'll render there.
Its less about bundle size in my opinion and more about reduced complexity and data security.
That said, I've never been a fan of RSC and don't see it solving the "reduced complexity" goal.
It's a really weird situation, but using public transport WiFi cured me of this thinking.
The amount of times that the initial HTML, CSS and JS came through, but then choked on fetching the page content was insane. Staring at a spinner is more insulting than the page just not loading.
That being said, I'm not a huge fan of RSCs either. Dumping the entire VDOM state into a script tag then loading the full React runtime seems like a waste of bandwidth.
Why should a low-powered Android phone be downloading and running a full Markdown parser or syntax highlighter? Stuff like that is obviously something that should be handled by the server and just returned as final HTML.
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.
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.
One example is that I have a fancy visualization in my app that is rendered in the server via RSC and just some interactive tidbits get sent to the client. If I packaged the whole visualization library it would have bloated my bundle size but instead I ship barely any JS and still get a nice interactive vector data viz experience. And the code just looks like normal react component nesting more or less.
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.
SEO is a good reason.
Because with RSC you don't have a shitload of loading indicators and layout shifts.
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. :)
I have switched from the bloated mess of Nextjs to Vite+TSS and never looked back.
We are also currently inmidst a migration from NextJS to TanStack Start and it's worth for the performance and resource gains alone. NextJS' dev server takes around 3-4 GB memory after a few page click while TanStack / Vite consumes less than a GB.
This is something I noticed, originally I thought "AI" was the perfect tool for Vercel and Nextjs (current standard = future standard), but then I realized is the total opposite, their moat/stick is gone now, and Rouch that is smart I think knows this.
I switched a middle sized app to Tanstack Router + Vite while I was walking my dogs. Then 30 minuts-1 hour QA and it was done. This should have never happened before AI.
(I did switch because I was tired of the bloated network tab with 100 unnecesary RSC calls, the 5 seconds lag when clicking on an internal link, the 10 seconds "hot reload" after a change... I'm on a M4 MAX with 64GB of ram....)
Vercel's moat is DX in hosting, not NextJS. Consider, people who switch to TanStack Start still need a place to host and many would continue to choose Vercel.
Same principle applies, hosting in Railway has slightly worse UX, but with LLM's you don't need to write a single docker line anymore, so deploying on railway is way way less cumbersome than before, and you gain more control and less costs.
The react framework de jour. I wonder what would be the reason to rewrite react apps in 2027.
Thanks guys!
that said the documentation is rough, especially for their support for non-React frameworks
Having developed multiple react web apps from scratch over the last 5+ years at work, I always start with a fresh repo and add what I need myself. Nowadays, booting up a project with vite, eslint, prettier, redux (and rtk-query), tailwind etc. takes no time at all. Don't care about SSR. Am I missing something by not using tanstack? LLMs tell me many things, all of which seem irrelevant (e.g. not using react router, SSR, request-deduplication etc. which are covered by the basic few deps I added)
React query is a lot leaner and safer than handful redux even w rtk query
This is an interesting approach.
> 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.
RSC was dead on arrival and frameworks like Tanstack and React Router only really adopted them because you wouldn't be considered a modern and idiomatic React framework without their support. So I get it. Cool, I guess. Not to diminish the massive effort the maintainers had to put in to support it btw, since the core React team made zero effort to help anybody but Vercel on this.
It's telling that we're 6 years in from announcement, and like 4 years in from the initial Vercel implementation (fuelled by the React core team working at Vercel) for this to land in the major React frameworks.
But nobody really wants this. There are better patterns surfaced in frameworks like SvelteKit and Solid. What people want is implicit RPC functions. That covers 90% of the use-case for RSC anyways.
My personal opinion is that all of this is BS anyways, and we're building on foundations that are fundamentally flawed. But I'm also well outside the JS ecosystem at this point, rejecting it for greener pastures (wasm). But that's besides the point.
Big ups to Tanner tho, Tanstack is the de facto best React framework at this point.
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.
Though I don't see it nearly as much as I did then, there were quite a few "you'll never have to write an api again" takes that haven't aged too well.
When RSC's were framed as a different way to write BFF's, it finally clicked for me.
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.
Agree that TypeScript is nice, especially for sharing templates and types between server and client. But you can still use TypeScript on the server without sending it all to the client, and without a complex and insecure protocol like RSC. I’m working on making this as simple and dependency-free as possible: https://mastrojs.github.io
JSX is easily the most productive templating language out there, I fail to see your point.
I am not a fan of React, but they killed it with JSX, absolutely beautiful
Coming from years of Angular, I had convinced myself I wouldn't like JSX before even using it. Now, 4 years in, and I wouldn't trade it for anything. I spent almost 6 years writing Angular templates and I don't want to go back.
What’s stopping you from using those?
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".
Thank you. Every time I see a "Why can't we just go back to simpler days" comment it takes everything in me not to reply "No one is stopping you".
The idea that complexity arose out of nowhere and not because the web is doing things we couldn't have even imagined 10 years ago has always been wild to me.
Complexity mostly rose out of necessity, but the problem is it keeps being applied where it isn’t needed. Most projects don’t need Kafka, or Elastic, or Redis, or GraphQL, etc.
My main complaint is that by and large, the people who are applying these technologies heavy-handedly are doing so because they either think it’s needed, or because they don’t understand that simpler tools exist that could solve their problem.
> Most projects don’t need Kafka, or Elastic, or Redis, or GraphQL, etc.
I guess I just don't really see this being a problem outside of social media.
And I think another aspect that gets lost is that 20 years, your options were slim. Which means picking the right tool for the job was easier (because even if it wasn't the right tool, chances are it was as close as you were gonna get).
Things are different right now. Even something as ubiquitous as authentication is vastly different than it was back then. There's way more at play when picking tools nowadays, so it doesn't surprise me when people get it wrong.
I was on the same boat, coming from Django, but having used JSX, I absolutely love it, to the point that I try to use JSX in Vue and Django
Fingers crossed for Preact support in Router next.
Coming soon!
Am I the only one that despise TanStack docs? most of them seem AI-generated, incomplete and repetitive.
You’re the only one
It's so beautiful I nearly cried
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'
Thank you!