Two Big Projects Just Ditched Next.js (And Why It Makes Sense)

Two major projects announced their framework switches within hours of each other on December 6th, 2025. T3 Chat dropped Next.js for TanStack Start. Mastra Cloud moved to Vite. The Reddit thread hit 294 upvotes and 139 comments in a day.​

This wasn't drama. It was practical.

Theo from T3 Chat said it out loud: they were barely using Next.js anyway. They had forced React Router into Next with what he called "nasty hacks". For a dynamic chat app, that made no sense. But here's the thing. They stayed on Vercel. No vendor lock-in escape. Just picking the right tool.​

Mastra Cloud cited performance. That's it. No long post about philosophy. Just "we moved to Vite for performance reasons."​

You've probably felt this tension. You pick a framework because it's familiar. Then you spend months fighting it.

Why They Actually Moved

Theo admitted something most developers don't say publicly. He picked Next.js because it was the easiest way to deploy a complex React frontend and TypeScript backend together. He still thinks that's true.​

But T3 Chat is a real-time chat app. Everything happens client-side. Server rendering doesn't help much. They needed fast route transitions and client interactivity. Next.js kept getting in the way.​

The timeline matters. They started planning this move in April. This wasn't reactive. They waited until their database, auth, and Effect migrations were done. Then they switched frameworks.​

This took months of planning. Not a weekend rewrite.

One Reddit commenter nailed it: "It's quite typical to create an initial version using familiar tools, launch it quickly, test the concept, achieve some early growth, and then refine it with solutions that are more suitable for the product"​.

What TanStack Start Actually Offers

TanStack Start is client-first by default. It treats your app like a SPA. That means faster route transitions. Better client interactivity.​

But it doesn't skip server features. Full document SSR still works. Streaming works. Server functions work. You get both worlds.​

Here's what people miss about this migration. Theo didn't do it. His coworker Jullerino went full-time and decided TanStack was the right move. He did the migration without much oversight. Tanner Linsley (creator of TanStack) helped when Theo first tried to rebuild it.​

Most tutorials tell you framework choice matters on day one. That's wrong. T3 Chat proved you can ship fast with what you know, then optimize later when you understand your actual needs.

The Vite Switch

Mastra Cloud's move was simpler. They went from Next.js to Vite for performance. No long explanation. No blog post defending the choice.​

Vite is fast by default. It uses aggressive caching. Build times drop. Hot module replacement is instant. For a cloud platform, that matters.​

The interesting part? Mastra still documents Next.js integration extensively. They didn't abandon Next.js users. They just stopped using it for their own product. That tells you something.​

And look, this is the pattern now. Build your product with a framework. Realize it's not the right fit. Switch before it's too late.

Dev Twitter Had Opinions

The tweets came fast. Someone mentioned ChatGPT moved away from Next.js too. Another person said SPAs make more sense for AI chat interfaces. True or not, it spread.​

One reply asked what OpenAI switched to. No one knew. The rumor lived anyway.​

But here's the weird part. Most comments weren't negative toward Next.js. People understood. Different apps need different tools. A static blog needs different architecture than a real-time chat app.

Random Thing About Framework Names

TanStack used to be React Query. Then React Table. Then all these other React libraries. At some point Tanner Linsley said "forget it, we're TanStack now."

It's a good name. Short. Memorable. Doesn't promise anything it can't deliver. Compare that to Next.js which implies forward progress, or Remix which implies remixing React itself.

Framework names matter less than you think. But they stick in your head. You remember "Vite" because it sounds like "veet" which sounds fast. You remember "TanStack" because it's weird and specific.

Names are half the marketing. The other half is actually working well.

Real Talk

Most of you don't need to switch frameworks. Your Next.js app is probably fine. T3 Chat had specific problems. Real-time updates everywhere. Client-heavy interactions. Routing hacks piling up.​

If your app is mostly static content with some interactive bits, stay put. The migration cost isn't worth it. Theo's team spent months planning. They had a full-time developer do the work. You probably don't.​

And here's what they won't tell you: both frameworks will have new problems. TanStack Start's ecosystem is smaller. Fewer examples. Fewer Stack Overflow answers. That's the trade.​

Switching frameworks is expensive. Make sure you're actually solving a problem, not just chasing new tech.

The Reddit thread had one comment that stuck with me. Someone said to wait for a post-mortem from the T3 team before pushing agendas. Smart. We don't have all the details yet. Just tweets and Reddit posts.​

What This Means

Both teams picked tools that matched their actual use case. Not their imagined use case. Not what Twitter said was good. What actually worked for their specific apps.

T3 Chat needed client-first. Mastra needed faster builds. They moved. Simple as that.​

The lesson isn't "abandon Next.js." It's "understand what you're actually building." If you're making a real-time chat app, server rendering every route is waste. If you're building a documentation site, Vite's client-first approach is overkill.

Framework debates miss this. People argue about technical specs. They skip the part where you match the tool to the job. Theo said it: Next.js helped them get there in the first place. Now they're somewhere else.​

i keep thinking about that Reddit comment. The one about shipping with familiar tools first. That's how you actually build things. Pick what you know. Ship it. Learn what sucks. Fix that specific thing.​

Not every project needs a framework migration. But some do. And when they do, you'll know because you'll be writing nasty hacks to force your framework to do what it doesn't want to do.