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:

Legend

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

Is Next.js still developer-friendly?

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.

---

Over 200k developers use LogRocket to create better digital experiences

Learn more →

---

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.

LogRocket: Full visibility into production Next.js apps

Debugging Next applications can be difficult, especially when users experience issues that are difficult to reproduce. If you’re interested in monitoring and tracking state, automatically surfacing JavaScript errors, and tracking slow network requests and component load time, try LogRocket.

LogRocket captures console logs, errors, network requests, and pixel-perfect DOM recordings from user sessions and lets you replay them as users saw it, eliminating guesswork around why bugs happen — compatible with all frameworks.

LogRocket's Galileo AI watches sessions for you, instantly identifying and explaining user struggles with automated monitoring of your entire product experience.

The LogRocket Redux middleware package adds an extra layer of visibility into your user sessions. LogRocket logs all actions and state from your Redux stores.

Modernize how you debug your Next.js apps — start monitoring for free.