Next.js made React easy. TanStack Start made React feel like React again.
If you're picking a framework for something real in February 2026, this ...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for this. Ironically, Tanner Linsley himself shared this link on Twitter, hence I'm here.
I started coding 4 years ago, and I'm presently trying to stabilize as a Freelance developer so for now I'm sticking with Nextjs (PayloadCMS) and just trying to make a living. But always great to know viable alternatives exist.
Not sure why small org or big ones would pay Vercel per seat. You can setup one admin user and write your own ci/cd using their cli and not require extra user! Just don't use their auto deploy feature from GH and you're done.
That may be so. But I discarded Tanner Linsley when he started arguing that we don't need referential stability in React 😛 maybe he has since changed his ways (I hope) but the impact that had on React ecosystem as a whole, will be felt for decades with all the extra partial rerenderings it creates 😛 Adopting an entire framework written by those guys, seems worse to me than asking chatgpt to file my tax reports. It might work, until it doesn't and then you have no way back 😛
"It can't access your database, can't run server-side logic, and has a fundamentally different execution model from your route handlers."
Of course it can. You can do whatever you like in proxy.js, it is executed by the node.js runtime. The point is that you should not do network operations at the proxy layer. It runs ahead of most route visits, and thus network calls would slow the app down.
Couple of other observations:
1) We run Next.js 16 in a Kubernetes cluster and never had issues.
2) PageProps and LayoutProps in Next.js give the same type safety you describe at the top. They are generated automatically on build.
3) In my opinion, Server Components are solid, and PPR is fantastic, even for highly interactive apps. The only tricky part is caching and cache invalidation, and Cache Components did not make it easier.
Thanks for sharing all of these findigs.
That SEO feature for TanStack with type-safety is dope.
And the memory climibing issue, I did not even know about. But I can say Next.js on dev env is slow and resource hungry. Plus on every route visit it generate the build and take 4-5 seconds on it.
Overall I love how TanStack Start is getting better day-by-day.
Nice article, but let me also add a couple of pointers for the use client directive. Yes we did have confusions in the beginning while working on NextJs. What we eventually ended up doing is to get page.tsx which is the entry for the route to always render a first level client component called Module.tsx which is typically a page component holding filters, sort, api hooks using react query etc, which typically holds the "use client" directive.
Any component rendered from here on is a clear client component unless it's something like a Modal that explicitly required it. Yes, that's the only confusion we still face, and when we load the page, nextjs errors out if it uses a client side code and mentions clearly it's got to be driven by a use client directive. Not that these errors are unclear. Just that sometimes it is hard to know where to add it for special cases like Modals.
Once we had this model in place, our module.tsx are the only ones in our 160+ route app that have this directive and maybe a few related to the special cases.
On the memory part, yes we did have a few spikes that kept increasing over time. After our recent upgrade to 16.1.6 haven't really noticed anything as such. But I'm more than willing to revisit this comment and update if it still does.
Honestly deploying TanStack Start on cloudflare was a hellish experience. I moved it over to Vercel+Nitro
TanStack Start is a great experience though
Mental model is kind of easier and fun to deal with
oh nice
Good article.
Very nice piece!
I agree with this. Since building a separate backend Next JS for me has been just a vehicle for tanstack query.