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.
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 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.
> 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?
> 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.
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.
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)
To tell you the truth, I first landed on TanStack Start docs page a few times earlier. But somehow just couldn't get past their Getting Started page because of the annoying Partner Logo Ads on their docs pages. Tho, I really like their apprach to RSC and therefore am surely giving TSS a try.
I know that a company needs to make money to grow the team and build good software. It's just that it would be really great if the Ads were not so intrusive! I kinda believe Docs pages hold some kind of sanctity in devs' minds, and frankly I initially (and my bad - incorrectly) judged the team who is willing to 'pollute' this place with such banners on "all" of their docs pages.
13 comments
[ 3.4 ms ] story [ 34.4 ms ] threadIf 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 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. :)
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.
> 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.
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.
It was even worse a few months ago when the background was constantly changing colors. Fortunately enough people complained and they removed it.
I know that a company needs to make money to grow the team and build good software. It's just that it would be really great if the Ads were not so intrusive! I kinda believe Docs pages hold some kind of sanctity in devs' minds, and frankly I initially (and my bad - incorrectly) judged the team who is willing to 'pollute' this place with such banners on "all" of their docs pages.