Recently, I’ve been seeing more and more teams migrating projects from Next.js to TanStack. Cases like Inngest, which reduced local dev time by 83%, OpenPanel, and Documenso are becoming increasingly common. And every time I read one of these stories, I can’t help but wonder: was Next really the right choice from the start?

Don’t get me wrong. I’m aware of the challenges since the Pages Router to App Router migration, the impact this had on the developer experience, discussions around Vercel lock-in, and even some security concerns that emerged along the way. But maybe the main point isn’t “Next is bad.” Perhaps the real question is: did most of these projects really need to use Next in the first place?

What Next.js Really Is

Next is primarily, an opinionated framework for building React applications, with a huge focus on server-side rendering. It was designed for SSR, ISR, SSG, and all those letters Vercel helped popularize.

The initial goal was very clear: pre-render as much as possible, serve HTML to optimize SEO, reduce loading times, and deliver an extremely performant experience after the build. Ideally, you generate static pages, invalidate caches when needed, and deliver faster pages.

Almost perfect use cases for this include:

• Blogs
• News portals
• Landing pages
• Marketplaces with public catalogs
• SEO-focused e-commerce

In other words: products where content can be pre-rendered, and SEO is critical for success.

When the Choice Doesn’t Make Sense

The problem arises when we take a tool designed for the server side and apply it to fully dynamic, client-dependent systems:

• Internal systems with heavy interactivity
• Applications with multiple filters, modals, complex local states, and frequent data updates
• Products where almost everything depends on who’s logged in and what they just did

In these cases, almost nothing can be statically generated. SEO isn’t a priority. Pre-rendered HTML doesn’t matter. What really matters is state management and interactivity.

Where TanStack Fits In

And this is where TanStack comes in.

TanStack follows a model closer to a traditional SPA, with SSR as an opt-in feature rather than an architectural premise. The standard workflow is simple: route, query, mutation, invalidation.

There’s no constant concern about whether a component should be server or client side. The application is essentially client-first, and using server rendering is a conscious choice—not the starting point.

Perhaps what’s happening now isn’t a “rejection of Next.” It might just reflect choosing the framework of the moment over decisions based on architecture and product (props to React for having competitors that offer more elegant solutions, but that’s a topic for another post).