Next.js’s real disadvantages are a fast-moving API surface, the app router and React Server Components changed enough between versions to make older tutorials actively wrong, caching behaviour that is easy to misconfigure and hard to reason about, file-based routing that resists anything outside its conventions, a development server that gets slower as a project grows, and a framework whose defaults assume you are deploying to its own creator’s platform. None of these make Next.js a bad choice, they make it the wrong choice for some projects and irrelevant friction for others, and the difference is mostly project shape, not opinion.
Next.js is popular enough that criticizing it reads as contrarian, which is unfair to the actual trade-offs. This is not an anti-Next.js post, it is the list a team should read before committing, so the surprises show up in a planning doc instead of three months into a build.
Table of contents
- The API Surface Moves Fast
- Caching Confusion
- File-Based Routing Rigidity
- The Dev Server
- A Hosting-Shaped Framework
- When the Cons Don’t Matter
- Self-Hosting Reality: The Standalone Output
- Decision by Project Shape
- How this fits the rest of the stack
- FAQ
The API Surface Moves Fast
The move from the pages router to the app router, the introduction of Server Components, and the repeated changes to data-fetching patterns, getServerSideProps, then fetch with caching options, then more caching option changes, mean a two-year-old tutorial is a reasonable way to learn outdated patterns. Upgrading a real app across a major version sometimes means rewriting how pages fetch data, not just bumping a package number.
This is the cost of a framework developing quickly in public. It is a real cost, and teams maintaining an app for years should expect to pay it periodically, budgeted the way any dependency upgrade with breaking changes gets budgeted.
Caching Confusion
The app router’s caching model, request memoization, the data cache, the full route cache, and the router cache, each with different default behaviour and different ways to opt out, is powerful and genuinely hard to reason about. Debugging why a page is stale usually means understanding which of four caching layers is responsible, not one.
Teams report shipping bugs where a page silently served stale data because a cache default was not what they expected. That is not a rare edge case, it is a common enough complaint to be one of the most searched Next.js problems, and the fix is usually to set explicit revalidation rather than trust the default for anything that changes.
File-Based Routing Rigidity
The filesystem-as-router convention is convenient until a routing need does not map cleanly onto folders, deeply nested dynamic segments, route groups that need to share layout but not a URL segment, or middleware logic that would be a few lines in an explicit router and requires learning a specific convention here. It is opinionated by design, and the opinion does not fit every application’s URL structure.
Route groups, parallel routes, and intercepting routes each solve a specific version of this, but each is its own naming convention to learn, and a team coming from an explicit router spends real time mapping their mental model onto folder names instead of code.
The Dev Server
Startup and hot-reload times noticeably degrade as a Next.js project’s page and component count grows, a common complaint predating and partly addressed by the Turbopack rewrite of the dev server. On a large monorepo, a slow dev server is a daily tax on every contributor, not a one-time inconvenience.
Turbopack closes much of the gap for new projects, but a large existing codebase migrating onto it can still hit compatibility issues with older plugins or loaders, which means the fix for a slow dev server is sometimes itself a migration, and the schedule for that migration is worth planning rather than discovering mid-sprint.
A Hosting-Shaped Framework
Features like Image Optimization, Incremental Static Regeneration, and middleware are built assuming a specific runtime environment, and some of them degrade or require extra configuration off of that environment. This is not unique to Next.js, most frameworks work best on infrastructure shaped like their defaults, but it is worth knowing before assuming every feature works identically everywhere.
The gap is smaller than it used to be. Most of what a typical app needs, rendering, routing, API routes, works the same regardless of where the Node process actually runs, and the parts that differ are usually a config option away rather than a rewrite.
When the Cons Don’t Matter
A new project with no legacy pages-router code inherits none of the migration pain. A team that reads the caching docs once and sets explicit revalidation instead of relying on defaults avoids most of the caching surprises. A site with conventional routing needs, a blog, marketing pages, a standard app shell, never bumps into the routing rigidity at all.
The cons above are real but front-loaded: they cost the most to a team maintaining an old app across major versions or fighting the framework’s conventions, and cost little to a team starting fresh and reading the current docs before writing the first page.
Self-Hosting Reality: The Standalone Output
Next.js supports a standalone output mode (output: ‘standalone’ in next.config) that bundles a minimal Node server and only the dependencies actually used, deployable as a plain Node process or a container. Most core rendering, SSR, static generation, API routes, works the same off of its creator’s platform.
What changes off that platform: Image Optimization needs a loader configured for wherever images are actually served from, and some newer caching and revalidation behaviours assume infrastructure the standalone build does not provide out of the box. Neither is a blocker, both are configuration you would not need on the platform Next.js is built by.
Decision by Project Shape
A content-heavy marketing site or blog with standard routing gets the most Next.js benefit for the least friction, the conventions fit, caching defaults are forgiving for mostly-static content, and the ecosystem of examples targets exactly this shape. A highly custom application with unconventional routing, or a team that cannot tolerate periodic framework churn, pays the costs listed above without getting proportional benefit from the parts that fit.
The decision is not Next.js versus nothing, it is Next.js versus a lighter React setup, or a different meta-framework with different trade-offs, chosen for what the specific project’s routing and rendering needs actually look like.
How this fits the rest of the stack
None of the cons above are reasons to avoid Next.js outright, they are reasons to read the caching docs before shipping and to know what changes in the standalone build before assuming parity. Next.js runs as a service built from a repository the same way any other framework does, standalone output included, with the build log and the live route in one place. What a Next.js service costs next to a database is on the RunxBuild hosting calculator.
Useful related references:
- The Next.js Framework: What It Adds and What It Costs
- Next.js Middleware: What Belongs In It and What Will Bite You
- Next.js img vs Image: When the Component Is Worth It
- Next.js services on RunxBuild
FAQ
Is Next.js worth it?
For content-heavy sites, blogs, and applications with conventional routing needs, yes, the framework’s defaults fit that shape well. For highly custom routing, a team that cannot tolerate periodic API churn, or a project where React Server Components add complexity without a clear benefit, a lighter setup is often a better fit.
What are the disadvantages of Next.js?
A fast-moving API surface that has made past tutorials outdated more than once, a caching model with several layers that is easy to misconfigure, file-based routing that resists unconventional URL structures, a dev server that slows down on large projects, and defaults built around its creator’s own hosting platform.
Is Next.js overkill for small projects?
Often, yes. A small static site or a simple landing page gets little benefit from Server Components, the app router, or incremental static regeneration, and pays the framework’s learning curve and build complexity anyway. A plainer static site generator or a lighter React setup does the same job with less to configure.
Can Next.js be self-hosted?
Yes, using the standalone output mode, which bundles a minimal Node server and only the dependencies actually used into a deployable build. Server-side rendering, static generation, and API routes work the same off its creator’s platform; image optimization needs a loader configured for wherever images are served from.