The Beginning of the End for Next.js? Between Complexity and “Vercel-centrism”
Table of Contents
Open Table of contents
The “App Router-ization” of Chaos
The biggest breaking point was the transition to the App Router. What was sold as the future with React Server Components (RSC) felt to many like a rule change in the middle of the game.
- Learning Curve: We went from an intuitive file system to a structure plagued with special files (
layout.js,template.js,error.js). - Excessive Abstraction: Default cache handling became so aggressive and complex that diagnosing why data isn’t updating in production has turned into a “black magic” task for many engineers.

Technical Impact: Performance and DX
It’s not all Twitter “gossip”; there are real technical implications, especially when talking about Web Vitals and scalability:
1. The Myth of Speed with RSC
Although Server Components promise to reduce the JavaScript bundle on the client, the reality is that server latency has become the new bottleneck. If your data architecture isn’t perfect, Time to First Byte (TTFB) skyrockets while the server attempts to resolve complex component trees before sending the first byte.
2. The Hydration Labyrinth
Hydration in Next.js remains a challenge. When trying to mix server and client components, it’s common to run into mismatch errors that not only break the development experience (DX) but also penalize Total Blocking Time (TBT), directly affecting SEO and user retention on high-traffic sites.
3. Client-side vs Server-side: The Battle for Resources
In e-commerce projects, where every millisecond counts, the overhead of managing complex global states on top of a Server Components structure can be counterproductive. The performance penalty when trying to “re-hidratar” (re-hydrate) islands of interactivity can negate the benefits of having fast initial HTML.
Open Framework or Vercel Product?
There’s a persistent complaint: Next.js is being optimized to run perfectly exclusively on Vercel. Trying to deploy a modern Next.js application on an independent server (a VPS with Docker or S3) has become an uphill battle. If you’re not on their infrastructure, configuring cache headers and edge functions becomes an unnecessary headache.
The Rise of Competitors
While Next.js becomes more robust but heavy, other players are taking advantage of the oversight:
- Remix: With an approach closer to web standards and more predictable data management.
- Astro: The favorite for those seeking pure speed by eliminating unnecessary JavaScript.
Conclusion: Is it Worth Jumping Ship?
Let’s not kid ourselves: Next.js isn’t going to die tomorrow. It remains the most powerful tool for enterprise projects due to its massive ecosystem. But the “golden age” of blind trust is over.
Today, being a good engineer means questioning whether you truly need all the complexity that Next.js imposes or if a lighter tool would give you better results without so many headaches.