Did Your Project Really Need Next.js?

Source: Dev.to

Introduction

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. Every time I read one of these stories, I wonder: was Next really the right choice from the start?

I’m aware of the challenges—Pages Router to App Router migration, the impact on developer experience, discussions around Vercel lock‑in, and 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 Is Designed For

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

The initial goal was clear:

• Pre‑render as much as possible
• Serve HTML to optimize SEO
• Reduce loading times
• Deliver an extremely performant experience after the build

Ideally, you generate static pages, invalidate caches when needed, and deliver faster pages.

Typical Use Cases

• 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 Next.js May Not Be the Best Fit

Problems arise 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, and pre‑rendered HTML doesn’t matter. What really matters is state management and interactivity.

TanStack as an Alternative

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:

1. Route
2. Query
3. Mutation
4. 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.

Closing Thoughts

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).

I’ve just started writing and sharing my thoughts on my personal blog. I’m open to new ideas and feedback! Visit: