Six months ago, I would have laughed at this title.
TanStack? The React Query people? Eating an ecosystem?
I had been using React Query for years — loved it, recommended it to everyone. But I thought of TanStack as one library. A great library. Not a movement.
Then I updated a project last month and realized something had quietly happened while I wasn't paying attention.
I was already using TanStack Query. TanStack Router. TanStack Table. TanStack Form was replacing React Hook Form in my new projects. TanStack Start had replaced my Next.js setup entirely.
I looked at my dependencies file and felt something strange.
Half my stack was TanStack.
Not because I had planned it. Because one library at a time, over months, TanStack had simply become the better choice. And I had followed the better choice — without ever stopping to realize where I was going.
This is the story nobody is telling about React in 2026. 🧵
First — What Even Is TanStack Now?
Two years ago, TanStack meant one thing: React Query. The best data fetching library in the React ecosystem. Simple, powerful, solved a real problem.
Today? TanStack is eight interconnected libraries that form a complete frontend platform:
| Library | What It Replaces | Status |
|---|---|---|
| TanStack Query | Manual fetch + useEffect | ✅ Stable — 68% usage |
| TanStack Router | React Router / Next.js routing | ✅ Stable |
| TanStack Table | Every table library ever | ✅ Stable |
| TanStack Form | React Hook Form | ✅ Stable |
| TanStack Start | Next.js / Remix | 🚀 RC — growing fast |
| TanStack Store | Zustand / Redux | ✅ Stable |
| TanStack DB | Firebase / Supabase client | 🔬 Beta |
| TanStack AI | Every AI SDK | 🧪 Alpha |
Two years ago: one library.
Today: an entire platform that can replace your framework.
And somehow, most developers are still sleeping on this.
The Moment That Changed Everything For Me
I need to tell you about the PR that woke me up.
Eight months ago, I was debugging a routing issue in a Next.js project. Specifically — URL search params. The kind where you want your filters, pagination, and sort state to live in the URL so users can share links and the back button works correctly.
In Next.js, this required:
// The Next.js way — spread across multiple hooks and conversions
const searchParams = useSearchParams();
const router = useRouter();
const pathname = usePathname();
// Reading a filter value
const category = searchParams.get('category') ?? 'all';
const page = Number(searchParams.get('page') ?? '1');
// Updating search params
const updateFilters = (newCategory) => {
const params = new URLSearchParams(searchParams);
params.set('category', newCategory);
router.push(`${pathname}?${params.toString()}`);
};
It worked. But it was verbose. And it wasn't type-safe — searchParams.get('category') returns string | null and TypeScript couldn't tell me what valid values were.
Then I saw a colleague using TanStack Router for the same thing:
// The TanStack Router way — fully type-safe, one place
const Route = createFileRoute('/products')({
validateSearch: (search) => ({
category: search.category as string ?? 'all',
page: Number(search.page ?? 1),
}),
});
// In the component — fully typed, no casting
const { category, page } = Route.useSearch();
// Updating — type-safe, can't typo the key
const navigate = Route.useNavigate();
navigate({ search: (prev) => ({ ...prev, category: 'electronics' }) });
TypeScript knew exactly what category and page were. It would error at compile time if I tried to set an invalid value. The URL state and the TypeScript types were in perfect sync.
I stared at this for a long time.
Then I opened a new branch and started migrating.
The Real Numbers — State of React 2026
Here's where this stops being my personal story and becomes something bigger.
The State of React survey — over 3,700 developers — was published in February 2026. The results were striking.
Next.js, which once looked set to become the standard choice for full-stack React, is widely used but not particularly beloved. 80 percent of respondents have used it, but 17 percent have a negative sentiment, with most complaints focused on excessive complexity and too-tight integration with its main sponsor Vercel.
And then this:
TanStack Query, used for data fetching, has 68 percent usage, 42 percent positive sentiment, and just 1 percent negative.
1 percent negative sentiment. For a library used by 68 percent of React developers.
That is an extraordinary number. For comparison, Next.js has 17x more negative sentiment than TanStack Query despite being used by roughly the same proportion of developers.
The ecosystem is speaking. Most people just aren't listening yet.
Why TanStack Is Winning — The Real Reason
Here's what I've figured out after months of thinking about this:
TanStack wins because it has a philosophy. And that philosophy is better than what it's replacing.
The philosophy: own your code, not your framework.
Every TanStack library is headless by design. It handles logic. You handle UI. There is no TanStack component you have to override. No TanStack style you have to fight. No TanStack opinion about how your app should look.
Compare this to Next.js — where your image tags, fonts, routing, and server behavior are all controlled by the framework. You get power, but you pay with lock-in.
"Vendor lock in, complex APIs, and too much noise in the Next.js ecosystem make it a no-go for me," said one developer in the survey.
TanStack's answer to that complaint is architectural. It's not a framework. It's a set of building blocks.
You own the code. You own the decisions. TanStack just handles the hard parts.
The Five Libraries You Should Know Now
1. TanStack Query — You Probably Already Use This
If you're not using TanStack Query, stop reading and go install it right now. I'll wait.
// Before TanStack Query — the pain we all forgot
const [users, setUsers] = useState([]);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);
useEffect(() => {
setLoading(true);
fetch('/api/users')
.then(res => res.json())
.then(data => {
setUsers(data);
setLoading(false);
})
.catch(err => {
setError(err);
setLoading(false);
});
}, []);
// After TanStack Query — this is all you need
const { data: users, isLoading, error } = useQuery({
queryKey: ['users'],
queryFn: () => fetch('/api/users').then(res => res.json()),
});
Caching, background refetching, stale-while-revalidate, optimistic updates, infinite scroll, devtools — all included. This is the gateway drug to the TanStack ecosystem, and it's where most people start.
2. TanStack Router — The One That Will Surprise You Most
This is the library that converted me completely.
Full type-safety across your entire routing layer. Not just route paths — search params, route context, loader data — everything is typed end-to-end.
// Your routes are fully typed — everywhere
const Route = createFileRoute('/users/$userId')({
loader: async ({ params }) => {
// params.userId is typed as string
return fetchUser(params.userId);
},
component: UserPage,
});
function UserPage() {
const user = Route.useLoaderData();
// user is fully typed — no casting needed ✅
const { userId } = Route.useParams();
// userId is typed as string — can't typo it ✅
}
If you've ever had a bug because useParams() returned undefined and TypeScript didn't warn you — TanStack Router is the answer.
3. TanStack Form — React Hook Form's Successor
React Hook Form is great. TanStack Form is what React Hook Form would be if it was built today, with TypeScript first.
const form = useForm({
defaultValues: {
email: '',
password: '',
},
onSubmit: async ({ value }) => {
// value is fully typed — value.email is string, not unknown
await loginUser(value);
},
});
// Fields are typed — no register('email') string magic
<form.Field
name="email" // TypeScript errors if this field doesn't exist ✅
validators={{
onChange: ({ value }) =>
!value.includes('@') ? 'Invalid email' : undefined,
}}
children={(field) => (
<input
value={field.state.value}
onChange={(e) => field.handleChange(e.target.value)}
/>
)}
/>
4. TanStack Start — The Next.js Alternative Nobody Expected
This is the newest and most controversial addition.
TanStack Start is less magic and more control. You decide how data loads, where it runs, and what gets rendered. The type safety is excellent, and it plays beautifully with the rest of the TanStack ecosystem.
It's a full-stack framework built on TanStack Router. SSR, streaming, server functions — all the things Next.js does, but without the Vercel dependency and with full type safety throughout.
// Server function — fully type-safe, no API route needed
const getUser = createServerFn({ method: 'GET' })
.validator((userId: string) => userId)
.handler(async ({ data: userId }) => {
return db.users.findById(userId);
// Return type is inferred — available in the component ✅
});
// In your component — type safe end to end
const user = await getUser({ data: userId });
// user has the correct type from the server function ✅
No more guessing what your API returns. The types flow from database to component without a single manual annotation.
5. TanStack DB + AI — The Future Being Built Right Now
There are several TanStack sub-projects in varying states of readiness. Alongside Query and Start, others include the TanStack DB data store in beta, TanStack AI in alpha, and TanStack CLI including an MCP server for use by AI agents.
TanStack DB is a reactive client-side data store — think Firebase but without the vendor lock-in. TanStack AI is a unified interface across AI providers — same API whether you're calling Claude, GPT-4, or Gemini.
A powerful, open-source AI SDK with a unified interface across multiple providers. No vendor lock-in, no proprietary formats, just clean TypeScript and honest open source.
These are alpha and beta — not production ready. But they tell you where this is going.
TanStack isn't building libraries. It's building a platform.
The Honest Counterargument
I've been making TanStack sound like a silver bullet. It's not.
If your team knows Redux and React Router well, the productivity hit of learning new tools might not be worth it. Next.js has years of production battle-testing. More developers know Redux than TanStack — this matters for team scaling. If you need boring, predictable technology, stick with the defaults.
That's real. If you're hiring, more developers know Next.js than TanStack Start. If you need React Server Components today with full production support — Next.js is still the answer. If your team is deep in Redux and changing means months of retraining — the cost might not be worth it.
TanStack is excellent. But it's not always the right choice.
Use it when its strengths align with your needs.
So — Should You Switch?
Here's my honest recommendation after six months of living in the TanStack ecosystem:
Start with Query today. If you're not already using it, this is the highest-ROI change you can make to a React codebase. Lower risk, immediate value, and it's the gateway to understanding how TanStack thinks.
Try Router on your next greenfield project. Don't migrate an existing app — the value is clearest when you start with type-safety from day one. Build something new with TanStack Router and feel the difference.
Watch Start carefully. It's not Next.js-stable yet. But the trajectory is clear. The developers who learn it now will have a significant advantage when it hits 1.0.
Keep an eye on DB and AI. Both are too early for production. But they reveal TanStack's ambition — and if the team's track record means anything, these will be excellent when they're ready.
The Bigger Picture
Here's what I keep coming back to.
TanStack isn't winning because it's marketing itself better than Next.js. It's not winning because of viral tweets or conference talks.
It's winning because it solves the problem that React developers actually have in 2026: too much magic, too much lock-in, too much complexity that lives in the framework and not in your code.
TanStack gives you back control. Full type safety. No hidden behavior. No vendor dependency. Just well-designed primitives that do exactly what they say.
In an era where AI is writing more and more of our code, that clarity matters more than ever. AI tools work better with explicit, type-safe code than with magic framework conventions.
TanStack didn't plan to eat the React ecosystem.
It just built better tools. And developers followed the better tools.
That's how ecosystems actually change. Not with announcements. With pull requests.
Are you using TanStack in production? Which libraries have replaced what in your stack? I'd genuinely love to see what setups people are running in the comments — especially if you've made the full switch to TanStack Start. 👇
Heads up: AI helped me write this.But the migration experience, the code examples, and the opinions are all mine — AI just helped me communicate them better. I believe in being transparent about my process! 😊
Top comments (10)
I came across something which might be even better than TanStack - it's called "RedwoodSDK", this article gives a really good overview of the thinking behind it:
medium.com/@roman_fedyskyi/redwood...
Pretty radical and innovative in its approach, although it might not be for everyone ...
Great share! Redwood SDK's server-first pivot is fascinating moving GraphQL from core to optional, embracing Web APIs and React Server Components is a bold bet. It's less magic, more standards. Can't really compare to TanStack (apples vs oranges framework vs library), but for new edge projects, this could be a cleaner foundation. Migration for existing RedwoodJS apps? That's the tough part.
Yeah I have been reading quite a bit about it over the weekend, and can't help being pretty excited - I have a project in mind for which this "stack" (RedwoodSDK on CloudFlare) would fit like a glove, it would solve a host of problems and would cut out 90% of the complexity, compared to the stack that we considered until now ...
I think these people have got the vision!
P.S. had been looking at RedwoodJS previously, but wasn't fully convinced - this new framework (RedwoodSDK) looks MUCH more compelling to me ...
Love the enthusiasm! Cuts out 90% of the complexity that's the kind of promise that makes a developer's heart skip a beat. When a framework just fits your problem domain and gets out of the way, it feels like magic.
And you're absolutely right about the RedwoodJS vs RedwoodSDK distinction. The old one was GraphQL-centric, which felt heavy for many use cases. The new server-first, edge-native approach especially on CloudFlare feels like it's stripping away the abstractions and getting back to web standards.
I think the team's vision is spot-on. By embracing Web APIs and React Server Components, they're betting on where the platform is heading, not where it's been. Would love to hear how your project goes once you start building fits like a glove' is the highest praise a framework can get. Keep us posted.
Yeah it's that feeling you get when it seems all the pieces of the puzzle are suddenly falling into place ...
When I'm getting started building something with this stuff, I'm planning to post some articles about it on dev.to !
That feeling when the pieces finally click nothing beats it. The puzzle solving moment is where the real magic happens.
And yes! Writing about it on dev.to is a great idea. Your experience with this new stack (RedwoodSDK on CloudFlare) will be super valuable for others navigating the same decisions. Looking forward to reading your articles when they're out. Happy building!
Had the exact same realization a few months back. Checked my package.json and it was like — wait, when did TanStack become my entire stack?
The type-safe search params in TanStack Router is what sold me too. I was doing so much manual URLSearchParams parsing with zod schemas bolted on top, and it was always fragile. One typo in a param name and you're debugging for an hour.
One thing I'd push back on slightly — TanStack Form is good but I wouldn't call it a React Hook Form "successor" just yet. RHF's uncontrolled approach still has some real performance advantages for large forms with lots of fields. I've tried both on a form with 40+ fields and RHF was noticeably snappier. TanStack Form's DX is nicer though, I'll give it that.
Also worth noting that TanStack Start's hosting story is way more flexible than Next.js. You can deploy it basically anywhere that runs Node, no special adapter or platform tie-in needed. That alone is a huge win for teams that don't want to be on Vercel.
Absolutely right! The TanStack ecosystem is truly becoming a game-changer. The type-safe search params feature is such a huge relief - I also used to struggle with URLSearchParams and writing zod schemas, yet bugs would still creep in somewhere.
Thanks for sharing your experience comparing TanStack Form and React Hook Form! Good to know about the performance difference with 40+ fields. I hadn't tested at such a large scale yet, so it's useful to know that RHF might still be better for heavy forms.
And yes, the deployment flexibility point about TanStack Start is really important. With Next.js, people become dependent on Vercel, which isn't ideal for all teams. Being able to deploy anywhere on a Node environment is definitely an advantage.
What have you built with the TanStack ecosystem? Have you used it in any production projects?
Another day another framework/package/library to learn and migrate into in the JS world. Sorry for sounding so cynical. I had really bad JS fatigue. Been following Tanstack popularity grow slowly over the last few months.
Exactly The JS fatigue is real. But what I love about TanStack is that it's not just another random library it's actually solving real problems with better developer experience. Their libraries are framework agnostic too, so at least the learning is transferable! 😅