TanStack Start Now Support React Server Components

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.

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. :)

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)

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?

> 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.

Am I the only one that despise TanStack docs? most of them seem AI-generated, incomplete and repetitive.

Fingers crossed for Preact support in Router next.

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.

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'