Is Next.js still developer-friendly?

The React ecosystem has recently been known for its heated debates on Next.js and, frankly, it’s becoming increasingly hard to ignore the noise. Scroll through developer forums and you’ll find arguments on both sides. Some developers swear by Next.js as their go-to framework, while others are jumping ship faster than you can say “server components.”

In this article, we’ll discuss whether the growing frustration with Next.js is a skill issue or a real issue.

What made Next.js developer-friendly initially?

Before Next.js was a thing, a project could end up with its own custom webpack configuration and SSR hacks. Though not a major problem, you also had to figure out how to handle routing on both client and server

Next.js was like “forget all that” and gave developers something easy-going. We then had:

Zero-config setup that actually worked — Run npx create-next-app and you had SSR, routing, code splitting, and hot reloading without touching a single config file — and in all sincerity, if I want to take on a new personal project, I’d rather spend time writing functional code than setting up different tools
File-based routing that made sense — Create a file in the pages folder and you have a route. No router configuration, no further setup. Next.js’s routing system turned a headache into a forgotten problem. You could literally explain this to a new developer in five minutes: “Make a file in this folder and you’ll have a page”
Easy optimizations — Next.js made optimization feel automatic. Code splitting happened naturally, and images got optimized by using the Image component. CSS got bundled properly. You got performance benefits without needing to understand the underlying complexity
Clear documentation and a gentle learning curve — At first, the docs were straightforward, examples were practical, and the mental model was simple — it was just React, but with some nice extras

The framework felt like it was designed by developers who actually shipped products, not by engineers who wanted to show off how clever they were. It solved real problems without creating new ones.

That was the Next.js that everyone fell in love with. It was simple, powerful, and just worked.

Where Next.js started losing developers

The turning point wasn’t a single moment. If you had to pick when things started going sideways, the frequent changes that came with new versions were the beginning of the end:

Frequent breaking changes between versions — Every major release seemed to bring a new thing. This isn’t unique to Next.js — we see it across frameworks — but it becomes a problem when you’re forced to rewrite a chunk of your application every year
Documentation that requires constant reference — When working with Next.js, the last thing you need far from you is the documentation. The docs went from being a quick reference to something you needed to keep open in a browser tab

These are personal experiences from projects I’ve handled. Looking through community threads, there are many more problems. I had to highlight a few and throw in my takes

Integrating i18n in Next.js

Svelte or Astro wasn’t friendly to me either, so I’ll call this a skill issue. There are other complaints about authentication issues:

I guess this person was using NextAuth. And there was another one that sounded like an AI-generated response:

Routing problems

I doubt this was one of the reasons ChatGPT migrated, but it never really had problems with routing. This particular problem below is an actual pain:

My authentication experience with NextAuth

Last year, I was building an e-commerce platform and chose NextAuth because I sincerely wanted to try it out — I don’t usually use it, but Next.js recommends it. Development went smoothly, users logged in, sessions persisted, and everything worked perfectly

Then I deployed to staging. Sessions started vanishing randomly. Users would be logged in on one page, navigate somewhere else, and suddenly they were back at the login screen. The admin dashboard was particularly annoying — admins would be updating inventory and get kicked out mid-action

After debugging middleware configurations and cookie settings, I realized that NextAuth was the culprit. I ditched it and switched to Clerk, and everything was fine.

A bit of levity

Are developer expectations out of whack?

Here’s the uncomfortable truth: some of the Next.js frustration is a developer expectations problem — but not in the way the “skill issue” crowd thinks.

Framework maturity vs. simplicity trade-offs — Next.js has evolved from a simple React wrapper into a full-stack meta-framework trying to solve every web development problem. That’s not inherently bad — mature frameworks naturally gain complexity. The issue is that Next.js marketed itself as “simple” while simultaneously adding layers of abstraction that require a good understanding to debug
Developer skill gaps in modern React patterns — Many developers jumped into Next.js without understanding server-side rendering, hydration, or client-server boundaries. But here’s the kicker — Next.js’s marketing may have encouraged this. It sold itself as “just React with extras,” not “React with a different mental model that requires understanding distributed systems”
Comparing Next.js complexity to other meta-frameworks — Take SvelteKit as an example — it delivers server-side rendering, routing, and full-stack features without making you feel like you need a PhD to troubleshoot issues. Remix takes a different approach by being upfront about its complexity and sticking close to web platform fundamentals

The CVE-2025-29927 incident perfectly illustrates this issue. A framework that handles so much internally becomes a problem when things go wrong. Other frameworks with similar capabilities don’t seem to generate the same level of developer frustration.

Framework requirements analysis

Before we get to whether it’s still developer-friendly, let’s break down what developers actually need from a modern React framework and how Next.js delivers:

Requirement	Next.js solution	Complexity level	Pain points
Routing	File-based routing (Pages) + App Router	Medium	Two different systems, migration confusion
SSR/SSG	Built-in with multiple strategies	High	Hydration mismatches, debugging nightmares
Build tooling	Zero-config Webpack/Turbopack	Low	Works great until you need customization
Code splitting	Automatic	Low	Generally solid
API routes	Built-in serverless functions	Medium	Limited scalability, middleware complexity
Authentication	Third-party (NextAuth/Auth.js)	High	Session management issues, random logouts
Data fetching	Multiple patterns (`getServerSideProps`, Server Components, etc.)	Medium	Too many ways to do the same thing
Deployment	Optimized for Vercel	Medium	Self-hosting complications
Developer experience	Hot reloading, TypeScript support	Medium	Slow build times, cryptic error messages
Error handling	Built-in error boundaries	Medium	Debugging leads to framework internals
Performance	Automatic optimizations	Medium	Good results, but opaque process
Styling	CSS Modules, Styled JSX	Low	Flexible but not opinionated

Legend

Low — Works intuitively, minimal learning curve
Medium — Requires some framework-specific knowledge
High — Significant complexity

After working with Next.js across dozens of projects over the past years, here’s my take: yes, Next.js is absolutely developer-friendly. But it’s developer-friendly in the way a sports car is driver-friendly: powerful and capable, but you’d better know what you’re doing.

When to push teams toward Next.js

I love recommending Next.js when teams need that SEO boost. A travel startup I worked with saw its organic traffic improve after we migrated its blog to Next.js. The file-based routing meant the content team could drop markdown files in folders and have new pages live instantly.

The developer experience really shines when you’re building content-heavy applications. I’ve had marketing teams at three different companies learn to manage their own pages just by understanding “file in folder = new page.” That’s genuinely developer-friendly design.

When to look for alternatives

I don’t recommend Next.js for simple SPAs anymore. When a startup wanted to build a basic dashboard with no SSR needs, the framework overhead felt like too much. We went with Vite + React Router and everyone was happier.

I also pause when teams are new to React entirely. Watching developers struggle with server versus client components while also learning React fundamentals is painful. The framework assumes you already understand React deeply.

The hosting conversation matters too. I’ve had clients get shocked when their Vercel bills hit $200/month — a little price to pay for a simple plug-and-play deployment service — for what started as a simple site. If you need predictable costs or must self-host, the developer-friendliness disappears quickly.

Alternatives to consider

Here are Next.js alternatives I would recommend, from one developer to another:

For React lovers — Remix builds on web platform fundamentals and doesn’t hide its architectural decisions from you. For single-page applications without server-rendering needs, stick with Vite paired with React Router
For the SSR crowd — SvelteKit offers similar capabilities. Astro is great for content-heavy sites with minimal JavaScript
For the pragmatists — If you’re not married to React, consider Nuxt.js (Vue) or even going back to server-rendered frameworks like Laravel with Inertia.js

Conclusion

Here’s the truth nobody wants to admit: Next.js solves genuinely hard problems, but it makes you pay for those solutions with a few developer experience sacrifices.

My honest take:

Next.js works brilliantly for teams who know what they’re getting into. The magic is real — until it breaks — and then you need someone who can navigate the framework’s internals without losing their sanity. But when everything clicks, you’ll ship features faster than you thought possible

The question isn’t whether Next.js is good or bad. It’s whether the productivity gains are worth the complexity tax. For some teams, absolutely. For others, there are simpler paths to the same destination.

My bold prediction:

Next.js will either start listening to its users or get replaced by something that does.

Stop accepting “it’s just how Next.js works” as an answer. If your tools make you feel stupid, that’s not a you problem — that’s a tool problem. But this only applies to people who understand the framework — by that I mean people without skill issues.

The post Is Next.js still developer-friendly? appeared first on LogRocket Blog.

This post first appeared on Read More