DEV Community

Cover image for Why Some Tech Companies Are Moving Away from Next.js
araf
araf

Posted on

Why Some Tech Companies Are Moving Away from Next.js

#nextjs #ssr #webdev #programming

Why Some Tech Companies Are Moving Away from Next.js

Next.js has been the poster child of React-based frameworks for years. So why are some teams starting to walk away from it?

🚀 The Rise of Next.js

Next.js, developed by Vercel, gave React developers a breath of fresh air. With file-based routing, built-in SSR/SSG, and amazing DX (developer experience), it quickly became the default choice for building modern web apps.

From startups to Fortune 500s, everyone jumped on the Next.js train. But as with any tech, growth brings complexity—and now we’re starting to see a quiet shift.

🧭 Why Teams Are Reevaluating

Here are some common themes behind companies stepping back from Next.js:

1. Overhead & Complexity

Next.js has grown a lot. Features like App Router, Server Actions, Middleware, and Edge Functions are powerful—but also increase the cognitive load.

“We just wanted SSR and routing. Now it feels like we’re learning a whole new meta-framework.”

Teams with simpler needs are finding Next.js too heavy for their use case and moving back to:

  • Vite + React for simplicity and speed.
  • Astro for content-heavy sites.
  • Remix or SvelteKit for more opinionated full-stack flows.

2. Lock-in to Vercel Ecosystem

Even though Next.js is open source, it’s heavily influenced by Vercel's roadmap.

Features like Image Optimization, Middleware, and Edge Functions work best—or only—on Vercel.

This creates concerns about:

  • Vendor lock-in
  • Deployment portability
  • Hidden costs at scale

Some teams prefer frameworks with more neutral ecosystems or simpler deployment pipelines.

3. Performance Bottlenecks

Next.js aims to make performance easy out-of-the-box, but for large apps:

  • The App Router can introduce hydration complexity.
  • Server components are still maturing.
  • Edge rendering isn't always faster—especially with cold starts or global latencies.

As a result, teams with fine-tuned performance requirements are moving to more lightweight alternatives where they have more control.

4. Better Alternatives for Their Use Case

A few examples of stack shifts:

  • Content sites/blogs → Astro (faster, less JS)
  • Full-stack apps → Remix (better data loading model)
  • Dashboard-like SPAs → Vite + React (no SSR needed)

The point? One size no longer fits all.

5. Uncertainty Around React's Direction

React itself is in flux—Server Components, Suspense, and new architectural patterns are still stabilizing.

Next.js is deeply tied to React’s experimental features, so teams looking for stability are hesitating.

📦 It’s Not About “Next.js is Bad”

Next.js is still an excellent framework and a great default for many use cases.

But it’s no longer the only mature option, and as teams refine their needs, they’re choosing tools that are better fits—smaller, faster, and simpler.

🧠 Final Thoughts

The takeaway isn’t to jump ship, but to evaluate tech based on your current needs, not trends or hype.

Next.js did a great job pioneering many web standards—and even if teams move away from it, it helped push the ecosystem forward.

🗣 Over to You

Have you switched away from Next.js? Or are you doubling down on it? What’s your tech stack look like in 2025?

Let me know in the comments 👇

Top comments (0)