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.
The Replay is a weekly newsletter for dev and engineering leaders.
Delivered once a week, it's your curated guide to the most important conversations around frontend dev, emerging AI tools, and the state of modern software.
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:
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 toolspages 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”Image component. CSS got bundled properly. You got performance benefits without needing to understand the underlying complexityThe 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.
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:
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
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:
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:
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.
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.
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.
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
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.
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.
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.
Here are Next.js alternatives I would recommend, from one developer to another:
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.
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.
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.
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.
Discover what’s new in The Replay, LogRocket’s newsletter for dev and engineering leaders, in the October 22nd issue.
John Reilly discusses how software development has been changed by the innovations of AI: both the positives and the negatives.
Learn how to effectively debug with Chrome DevTools MCP server, which provides AI agents access to Chrome DevTools directly inside your favorite code editor.
Ever opened a React file and found a graveyard of useState hooks? The problem isn’t React; it’s how we model state. Here’s how to do it smarter.
Would you be interested in joining LogRocket's developer community?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
Learn more →
One Reply to "Is Next.js still developer-friendly?"
As far as React and SSR goes, it seems like we’re all still stuck with Next.JS. SSR/Pre-Rendering is usually my only reason to touch Next.JS. Would be great to have other alternatives.