The Honeymoon Phase is Over
For years, Next.js was the golden child of the React ecosystem. It took the pain out of setting up a React application, offering server-side rendering, static site generation, and file-based routing right out of the box. It felt like magic. We all jumped on the bandwagon, building everything from simple blogs to complex SaaS platforms with it.
But recently, the conversation has shifted. The “it just works” magic has started to feel more like a “how does this even work?” headache. A growing number of developers, myself included, are finding that the framework’s evolution has brought a level of complexity that often outweighs its benefits for many projects.
The honeymoon phase is officially over.
The Complexity Trap: A Mental Model Overload
The most significant point of friction has been the introduction of the App Router and React Server Components (RSC). While these features promise performance gains by shifting work to the server, they have fundamentally changed the mental model of building a React app.
Suddenly, you’re not just thinking about components and state; you’re constantly juggling:
- Client vs. server boundaries
- Serialization issues
- New rules for data fetching
The line between the frontend and backend has blurred into a confusing grey area. For teams, keeping this complex mental map aligned is a real challenge—often leading to frustrating “why is this breaking on the client?” debugging sessions.
Image: A visual representation of the cognitive load many developers now feel when working with modern Next.js features like the App Router and Server Components.
Performance Blues and Vendor Lock-in Concerns
Beyond the mental overhead, the developer experience has taken a hit:
- Dev server startup times have increased
- Hot Module Replacement feels sluggish in large projects
There’s also growing unease about the tight coupling between Next.js and Vercel. While self-hosting is possible, features like Edge Middleware and ISR are clearly optimized for Vercel’s platform, making other hosting options feel like second-class citizens.
This perceived vendor lock-in is a major red flag for teams that value infrastructure freedom.
Rediscovering Simplicity: The Rise of Alternatives
This frustration has sparked a renewed interest in simpler tools.
For many projects:
- A Vite + React Router SPA is more than enough
- Development is faster
- The mental model is predictable
For content-heavy sites, Astro has surged in popularity by shipping zero JavaScript by default, focusing on performance and web fundamentals.
Developers are rediscovering an important truth:
You don’t need a sledgehammer to crack a nut.
Image: A conceptual fork in the road, illustrating the choice between complex, feature-rich frameworks like Next.js and simpler alternatives such as Vite and Astro.
Conclusion: Choose the Right Tool for the Job
Next.js is still an incredibly powerful framework. For large-scale, server-heavy applications, it may be the perfect choice.
But it’s no longer the default.
The era of “Next.js for everything” is coming to an end.
As engineers, we must ask better questions:
- Do we really need server-side rendering?
- Is the App Router worth the added complexity?
- Would a simpler SPA solve the problem just as well?
This shift isn’t about hating Next.js. It’s about maturity—recognizing that simplicity, predictability, and developer experience matter.
In the end, it’s not about choosing the most hyped tool.
It’s about choosing the right one.
