Next.js was great, until it wasn't

Next.js Was Great, Until It Wasn’t

If you’re into meta frameworks, Next is the obvious choice, as it is powered by the dominant React. It’s been the market leader since 2018, according to the latest State of JS.

But meta frameworks are two-edged swords. They make our lives easier until their choices start changing too often or stop making sense altogether.

You can see that shift in the positivity and satisfaction scores from the same survey.

And the upcoming one will definitely look much worse.

Let me list everything that is going wrong lately for me with the framework.

The Framework Can’t Sit Still

Every major version feels like a new framework hiding behind the same name.

First, it was Pages Router. Then App Router. Then Server Components. Each release promises the future of React™ until the next one quickly replaces it.

And I really don’t mind changes when they make sense. But with Next, I never know if I’m learning something resilient or just chasing another experiment. One month it’s getServerSideProps, then generateStaticParams, then fetch() inside Server Components.

Each one aged like milk.

My team has spent way too much time rebuilding the same app with new rules rather than actually building new features. For enterprises with large codebases, this translates to a lot of money and big delays.

Overengineered Architecture

Next started out simple. File-based routing, SSR and React components. You could onboard a new developer in ten minutes.

Then came middleware. Then edge functions. Then server actions. Then layouts, nested routes, and now RSC. Suddenly, “just use Next” turned into “read six RFCs before touching anything”.

What used to be one mental model is now five competing ones.

Every new feature tries to solve a problem that Next itself created two versions ago.

Need to fetch data? You have four ways to do it, depending on whether your component runs on the server, client, or something in between. Need to handle authentication? Good luck deciding between API routes, middleware, or server actions.

Next used to be the framework that got out of our way. Now it is the framework we have to wrestle with just to build something basic.

It’s not just you, Next.js is getting harder to use | Hacker News

Performance Claims vs Reality

Next loves to talk about performance in every release notes. Server-side rendering, static generation, and edge functions were all introduced to improve performance. But in practice, it rarely feels that way.

Cold starts are slow, build times keep growing, and every new abstraction adds another millisecond to the stack. The framework that was supposed to make performance easy now needs entire guides just to stay fast.

SSR and ISR look great in theory, but in real projects, they often create inconsistent page loads and unnecessary re-renders. You manually optimise endlessly, chasing metrics that used to come free with plain React.

Next.js App Router SSR Guide: Optimising for Performance

Weak Backend Support

Next tries to do everything, but it never became good as a backend. API routes and server actions work for simple tasks, but anything more demanding quickly turns messy.

Running jobs, managing databases, or building real APIs needs extra tools and custom setups. Frameworks like Nitro (used by Nuxt and H3) show how a true backend layer should work.

Security and Stability Risks

Next moves fast and breaks things. Frequent updates add features but also regressions and breaking changes that make upgrades risky. And when upgrades are hard, we delay them, and that delay becomes a security problem. Outdated projects miss critical patches and stay exposed to known vulnerabilities.

The 2025 middleware authorisation bypass is a perfect example (Vercel Postmortem, ProjectDiscovery Analysis, GitHub Advisory). It showed how one small change in Next’s core could open serious security holes across many apps.

Vendor Lock-In and Self-Hosting Pain

Next claims it works anywhere, but it is clearly built for Vercel. Most new features, like image optimisation, edge functions, server actions, and ISR, work best there. Try to host the same project on AWS, Netlify, or your own server, and you will run into slow builds, missing features, or long setup guides.

Running Next outside of Vercel is possible but painful. You need extra configuration, caching layers, and deployment tweaks just to get a similar result. Every new release seems to make that harder.

This is not an accident. Vercel owns Next and steers it toward its platform. Each update adds more integrations that make leaving Vercel difficult.

That dependency becomes expensive over time. Scaling costs, limits, and platform rules start to shape your app more than your own choices. Even if you do not use Vercel, you still feel its influence.

Next may be open source, but in practice, it feels like a Vercel product.

Secret knowledge to self-host Next.js

Political Aspect

This article was sitting in my drafts for a while. What pushed me to publish it was the completely justified movement to step away from Vercel after its CEO publicly supported a war criminal.

A framework choice should never have to be political. But pretending it is not a problem, when it funds or aligns with something that crosses moral lines, it is complicity.