Next.js isn't the best framework. It's the most reliable bet.

Next.js is the most used React meta-framework in the world and one of the most resented. The numbers say both things at once. The State of JavaScript 2025 survey puts its usage leadership beyond argument while noting, in the same breath, that satisfaction has slipped, and it names the culprits: the rising complexity of Server Components and the App Router. Spend any time near the discourse and you'll hear all of it. The framework is bloated. The App Router broke my mental model. RSC shipped half-baked. The whole thing is a funnel into Vercel's hosting. Some of that is fair, and I'll get to the parts that are. A lot of it is people who picked the wrong tool, or used the right one against its grain, and then blamed the tool.

I've built on Next.js for years, including platforms where the wrong decision would have cost real money and real users. So this is my two cents, offered as one practitioner's view rather than a verdict. I don't think Next.js is the best framework available. I think it's the most reliable bet, and those are not the same claim. Understanding the difference is the whole point.

Let's clear the strawman out of the way first, because it poisons every one of these arguments. There is no universal frontend framework, and anyone selling you one is selling you something. Programming doesn't work like that. One solution does not fit every problem, and the moment you believe it does, you've stopped engineering and started cheerleading.

So when someone says a competitor is "better" than Next.js, the honest question is: better at what? Astro is genuinely brilliant at static generation. For a content site that's mostly read and rarely changes, it's hard to beat. SvelteKit produces leaner output and a development experience a lot of people prefer; it scores consistently higher on developer satisfaction than Next.js does. These are real strengths, and on their chosen axis they often win outright.

The problem is that real projects are never one axis. They're a content site that also needs authenticated dashboards. A marketing platform that also needs preview workflows for editors. A static catalogue that also has to scale to millions of users without falling over. The framework that wins isn't the one that's strongest at any single thing. It's the one that doesn't collapse into a pile of workarounds the moment your requirements get plural.

This is where Next.js earns its position, and it has little to do with technical purity.

Take the moment your static site needs to stop being purely static. Next.js has Incremental Static Regeneration baked in, update one page after deployment without rebuilding the whole site, and it pioneered the pattern. Astro, for all its static brilliance, has no built-in ISR. By default, when content changes, the entire site rebuilds. You can approximate ISR-like behaviour, but only by reaching for CDN cache headers, a Redis or Cloudflare KV layer, or your hosting platform's own implementation. It's a request that has sat open on Astro's public roadmap for years, with developers in the thread calling the lack of it a dealbreaker for large content sites. None of that makes Astro bad. It makes it a different tool, strongest exactly where Next.js's complexity would be overkill.

The same shape repeats with editorial preview. Next.js ships Draft Mode as a first-class, deeply documented feature: flip into dynamic rendering, fetch unpublished content, see the draft without rebuilding. It's so much the reference implementation that the integration guides for Directus, DatoCMS, and Optimizely all lead with a section titled "Next.js Draft Mode." SvelteKit supports it too, so this isn't exclusive territory, but Next.js is the path of least resistance and the one every CMS documents first.

Beyond content delivery, what Next.js is really offering is a complete server-side platform sitting inside your frontend codebase. The edge runtime lets you run middleware and route handlers geographically close to the user, handling auth, redirects, and A/B flags before a page ever renders. Streaming with Suspense lets you send the static shell of a page immediately and stream in slow data as it resolves, so a single slow database query no longer blocks the entire render. Server Actions let you call server-side logic directly from a component without writing a separate API layer. And the built-in image and font optimisation pipeline handles format conversion, lazy loading, and layout-shift prevention without any configuration. Each of these is a capability you'd otherwise assemble yourself from separate tools, with all the integration surface area that implies. Together they mean the decision to use Next.js is not just a choice of rendering framework; it's a choice of how much application infrastructure you want the framework to own.

Then there's the thing nobody wants to admit matters: the model that's been trained on it. Next.js existed and was widely adopted well before large language models became a development tool. It sits on top of React, which dwarfs every other component ecosystem. Stack Overflow's 2025 survey of more than 49,000 developers puts React at 46.9% of professionals and Next.js at 21.5%, against Vue's 18.4% and Svelte's 6.9%. So when an AI assistant generates Next.js code, it generates good Next.js code, because the training corpus is enormous and the patterns are well established. Pick Nuxt and you inherit Vue's smaller footprint. Pick SvelteKit and you inherit Svelte's. The framework didn't get cleverer. The gravity underneath it is just heavier, and with roughly a third of all new code now AI-generated, that gravity is a delivery advantage you feel every single day.

The tooling has gone further than corpus size too. Next.js 16 ships with an MCP endpoint enabled by default, and Vercel's DevTools MCP server lets a coding agent query a running application directly for its errors, routes, and compiler diagnostics. Whatever you think of Vercel's commercial motives, and the funnel-into-hosting suspicion isn't baseless, the loop between "something's broken" and "the agent can see what's broken" is tighter here than anywhere else. That's not elegance. It's reliability, and reliability is what you actually ship on.

None of the above means the grievances are imaginary. Three of them are legitimate, and you should know what you're signing up for.

The first is that the opinionation cuts both ways. The same strong opinions that carry you when you align with them constrain you when your needs don't map cleanly onto Next's model. If you want half the features and don't need the other half, there's no clean way to take what you want and leave the rest. That's not a bug in the framework's thinking; it's the nature of opinionated tools. But it means Next.js is an all-in decision, and teams that try to use it selectively often end up fighting it on the dimensions they opted out of.

The second is portability, and this one implicates Vercel-the-business more than Next-the-framework. For most of Next.js's life, deploying away from Vercel meant navigating undocumented behaviour. Netlify documented this publicly: Next.js contains undocumented options and code paths, and Vercel's own deployments use an internal flag called minimalMode that disables core framework features Vercel then reimplements inside its closed-source platform. A former Netlify engineer, commenting on Vercel's own RFC thread, said the routing and redirect rules were lightly and sometimes inaccurately documented, and that they had to reverse-engineer the order and logic before eventually resorting to standalone mode with what they called "lots of hacks." On video, Netlify's Next.js runtime engineer was more direct: Vercel doesn't provide an adapter API, so we read the open-source code and made transformations to reach feature parity. That's the vendor lock-in story, and it's not a vibe. It's documented engineering work the ecosystem had to do without Vercel's cooperation. The stable Adapter API that landed in Next.js 16.2 in March 2026 addresses this directly, developed by a working group that included Netlify, Cloudflare, AWS Amplify, Google, and the OpenNext maintainers. But the API arriving in 2026 is also an admission of where the priorities sat for the previous several years.

The third is the App Router transition, which was handled badly regardless of where the feature itself has since landed. The server and client component model represents a genuine shift in how you think about React, and it wasn't explained well at launch. The caching defaults confused teams for years: pages were cached aggressively by default, causing stale-data problems that weren't obvious until production. Version 16's fix, flipping to dynamic-by-default with explicit opt-in caching via the 'use cache' directive, is welcome, but it's also an acknowledgement that the original model caused real pain. The migration path created its own friction: Next.js always supported running both routers side by side, per route, but teams doing that in practice reported a disjointed experience, with inconsistent routing logic, layout handling, and data-fetching patterns living in the same codebase, making onboarding harder rather than easier. And once the compiler bundles everything, attributing a Web Vitals regression to a specific piece of code became genuinely harder. Teams still need strong observability tooling around caching and edge rendering behaviour to catch the things that won't surface on their own.

These are real costs. Accept them knowingly, or pick something else.

Here's the turn, and it's the part that actually matters.

None of the above means Next.js is the right choice for your project. It means it's the reliable choice, and reliability is only an advantage if you use the framework the way it wants to be used. Because Next.js is, above all, opinionated. Lean into those opinions and it carries you. Fight them and you lose, slowly, in ways that compound.

I know this precisely because I've watched it happen on a real project, and the lesson isn't that anyone made a mistake.

The setup: a Next.js platform built on a pod-per-locale Kubernetes architecture. Each locale gets its own pod. The ingress routes on path prefix (/fr/*, /en/*), and by the time a request reaches the Next.js pod, the locale prefix has been stripped; the app receives its locale only as an environment variable at boot. The model is paired with artifact promotion: one binary, promoted across environments, configured at runtime rather than at build. This is sound infrastructure thinking. Each locale scales independently on its own request load. The artifact promotion model is clean and operationally correct.

It is also, quietly, a decision to opt out of Next.js's routing contract.

Next's native i18n assumes the locale is part of the request the app sees. Here it isn't. So useRouter().locale returns undefined. Using next/link with the locale prefix in the href isn't recognised by the framework, which triggers a full page reload instead of client-side navigation, and broken Web Vitals immediately. Without the prefix, client navigation works but the URL drops the locale, so a hard refresh fails because the ingress has nothing to route on. Automatic hreflang tags, locale-aware sitemaps, locale-aware prefetching: all gone, because all of it assumes the framework owns the locale.

The fix is workable. A rewrite in next.config.js that teaches Next the prefix pattern, a custom next/link wrapper that prepends the locale from the environment variable, a lint rule banning direct next/link imports to enforce the convention. You ship. But hreflang, sitemaps, language switchers, locale-aware analytics, error pages, type safety on locale values: all of that becomes manual work. Each piece is small. The whole compounds into a permanent maintenance overhead and an onboarding tax on every developer who joins the project.

There was a framework-native path: one deployment serving all locales through middleware-based i18n, which would have preserved the artifact-promotion benefit without the workarounds. But the pod-per-locale model was chosen for request-level scaling, a sound reason and an independent engineering decision made before the framework conflict was visible. Nobody was wrong. Two coherent systems simply didn't compose cleanly, and the bill arrived later, in small instalments, across every feature that assumed Next.js owned the locale.

That's what fighting an opinionated framework actually looks like. Not a dramatic failure. A permanent, quiet tax.

That's what most of the Next.js discontent actually is, once you strip away the noise. It's rarely the framework failing on its own terms. It's teams choosing an opinionated tool and then spending months, sometimes years, working around the opinions they didn't want. Even the declining satisfaction numbers fit this reading: the complexity people resent is often the cost of capability they never needed, bolted onto projects that didn't call for it.

The grievances are real. The portability story was genuinely bad for a long time. The App Router transition was handled worse than it needed to be. The opinionation isn't always comfortable. Know all of that going in.

But if you're building something plural, something that has to hold up across a dozen requirements, in a team that will turn over, over several years, Next.js is still the bet that fails least often. Not because it's the most beautiful answer, but because the ecosystem, the tooling, the training data, and the sheer weight of prior art are all on your side.

Honour the contract and it carries you. Break it, even for the best of reasons, even when the infra team is completely right, and you'll spend the project paying for it in places you didn't expect.

The framework is almost never the problem. The fit is. Choose for the fit, and most of the war stories disappear before they start.