I once watched a Next.js core contributor open an issue that was, by any honest measure, harmless and low priority. He wrote the code himself, then pushed to get it merged as a pull request fast. Not because the bug was urgent - because he’s paid to ship things. I won’t point to the exact issue here, but spend an afternoon browsing the Next.js repo and you’ll spot the pattern yourself soon enough.
Bugs pile up by the hundreds. Pull requests land daily. And somehow, the problems that actually hurt real projects move at a crawl.
SSR and ISR used to be a simple, brilliant idea
I ran Next.js for years. Credit where it’s due: for server-side rendering, it was genuinely good. SSR (server-side rendering) and ISR (incremental static regeneration) solve a real problem - and funny enough, most developers I know still can’t tell the two apart, let alone pick the right one for their own use case.
At its core, the idea was simple: combine static content with dynamic data pulled from an API or a database, bundle everything into the page the browser gets, and let the server do that work once instead of every client doing it separately. Simple. Efficient. It just worked.
The monolith nobody asked for
That simplicity didn’t survive contact with a growing product roadmap.
Piece by piece, Next.js started reaching into territory that used to belong to your backend. Database integrations bolted directly onto the framework. Plugins for auth, caching, and data fetching shipped as part of the framework itself instead of staying decoupled, optional add-ons.
A concept built to decouple things - keep the frontend and backend apart, keep each layer small enough to reason about, play nicely with microservices - is quietly turning into the opposite: a monolith that wants to own your entire stack. That’s not progress. That’s scope creep with better marketing.
The upgrade is where the pain actually lives
If you’ve maintained a real Next.js project across a couple of major versions, you already know exactly what I mean. Nothing sums up framework fatigue faster than a routine version bump that quietly breaks your build, your routing, your data fetching, and half your third-party plugins - all at once.
People are noticing - and saying it out loud
This isn’t just me being cranky. A recent Reddit thread - “Framework panic: why is everyone leaving Next.js?” - struck a nerve for a reason. Experienced developers are walking away, one team at a time. Meanwhile, the framework’s reputation still pulls in a steady stream of newcomers who haven’t hit the upgrade wall yet, so from a distance the ecosystem still looks healthy.
That gap is worth sitting with. When the people who’ve actually shipped and maintained Next.js in production start leaving, and the ones replacing them are mostly newer developers drawn in by the hype, that’s a signal worth listening to - not brushing off.
And yet, recruiters are still hunting for Next.js developers, often at a premium. Sound familiar? It’s the same pattern PHP and .NET went through: unloved by the people who know it best, still in high demand because so much of the internet already runs on it.
Is this just hating on Next.js?
Honestly, I don’t think so. I loved this framework. The last time I ran yarn add next was two years ago, and I don’t say that with any satisfaction - I say it because the framework I fell for isn’t quite the one shipping today.
The AI era doesn’t want a monolith
Here’s the part that matters most going forward: how we build websites is changing fast, and AI is a big reason why. The tools and workflows that fit an AI-driven development process favor small, composable, decoupled pieces - not a framework trying to be your router, your database layer, your auth provider, and your deployment target all at once.
Next.js is strolling in the opposite direction, deeper into monolith territory, right as the rest of the ecosystem heads toward smaller, more independent building blocks. That mismatch is exactly why so many experienced developers are quietly - or not so quietly - stepping away.
