A senior engineer’s take on the “Next.js exodus”—it’s not about the framework, it’s about how you use it. Let’s cut through the noise and talk about real-world architectural decisions that won’t derail your projects.

Framework Panic: Why I’m Not Ditching Next.js (And You Probably Shouldn’t Either)

I remember a Tuesday morning, coffee in hand, when one of my sharpest junior engineers, let’s call him Alex, walked up to my desk looking like he’d just seen a ghost. He held up his phone, pointing to a Reddit thread titled something like ‘The Next.js Apocalypse is Here’. He was genuinely worried. “Darian,” he said, “do we need to migrate the new customer-portal-ui off Next.js? Everyone’s saying it’s dead.” We were two sprints away from a beta launch. That’s the moment this ‘framework panic’ stops being a Twitter debate and starts costing real time and money.

So, What’s Actually Going On?

Let’s be clear: the sky isn’t falling. The source of all this anxiety is the paradigm shift from the well-understood Pages Router to the new, powerful, and admittedly complex App Router. The App Router introduced React Server Components (RSCs) as the default, fundamentally changing how we think about data fetching, state, and client-side interactivity.

This is a huge change, and the learning curve is steep. The documentation is still catching up to the community’s edge cases, and many established libraries are racing to adapt. When developers hit this friction, they get frustrated. And frustrated developers are, shall we say, very vocal online. The problem isn’t that Next.js is “bad” now; it’s that its most powerful new features require a new way of thinking, and the transition hasn’t been seamless for everyone.

A Senior’s Pro-Tip: The loudest voices in these online debates are often those with the least at stake. They aren’t responsible for the PagerDuty alerts when prod-auth-service-02 goes down or for explaining to stakeholders why a deadline was missed over a framework migration that started on Hacker News.

Three Real-World Strategies to End the Panic

Instead of throwing the baby out with the bathwater, let’s talk strategy. Here are three architectural approaches we’re using at TechResolve to navigate this landscape without losing our minds.

1. The Pragmatic Pause: Master the App Router

If you’re already building with the App Router, like we were with our customer-portal-ui, the answer is not to panic and rewrite. It’s to slow down and stabilize. The biggest mistake I see teams making is trying to make everything a Server Component. The escape hatch, 'use client', is not a mark of failure; it’s a critical tool.

If a component needs state, interactivity, or browser-only APIs, make it a Client Component. Full stop. Isolate your data-fetching logic in Server Components and import small, interactive Client Components into them. This is the intended pattern.

For example, don’t fight the framework to create a stateful dark mode toggle in a Server Component. Just do this:

// app/components/ThemeToggle.tsx

'use client';

import { useState, useEffect } from 'react';

export function ThemeToggle() {
  const [theme, setTheme] = useState('light');

  // Logic to handle theme switching...
  const toggleTheme = () => {
    const newTheme = theme === 'light' ? 'dark' : 'light';
    setTheme(newTheme);
    document.documentElement.setAttribute('data-theme', newTheme);
  };

  return <button onClick={toggleTheme}>Switch to {theme === 'light' ? 'Dark' : 'Light'} Mode</button>;
}

Then, you can simply import this into your main server-rendered layout. Simple, clean, and it works. Don’t fight the grain.

2. The Safe Harbor: Stick with the Pages Router

I’m going to say something controversial: for a new project starting today, choosing the Pages Router is a perfectly valid, and often brilliant, architectural decision.

The Pages Router is not deprecated. It’s stable, battle-tested, and has a massive ecosystem of tutorials, libraries, and proven patterns. Last quarter, we kicked off a new internal tool for managing our CI/CD secrets. The requirements were clear: maximum stability, rapid development, and zero surprises. We chose the Pages Router. Why? Because the project didn’t need streaming UIs or complex nested layouts. It needed to be reliable and done on time. Choosing the “boring” technology was the right engineering call.

3. The ‘Nuclear’ Option: Diversify Your Framework Portfolio

This isn’t really a nuclear option, but it’s the one that requires the most architectural discipline. The “fix” for your Next.js problem might be realizing that not every problem needs Next.js.

As a Lead Architect, my job is to pick the right tool for the job. The “everyone is leaving Next.js” narrative is flawed because it assumes you can only use one framework. That’s absurd.

• Marketing Site with a Blog? We just launched one using Astro. It’s incredibly fast for content-heavy sites and the island architecture is a joy to work with.
• Heavy, data-intensive internal dashboard? We’re prototyping one with Remix. Its focus on web standards and form handling is superb for these use cases.
• Our core, customer-facing applications? They’re staying on Next.js, where we can leverage its powerful blend of SSR, SSG, and API routes.

A Quick Comparison

Here’s how I break it down for my team:

Final Thoughts

So, are we “leaving” Next.js at TechResolve? Absolutely not. But we are being more intentional and critical about how and where we use it. Your job as an engineer isn’t to chase the hype cycle. It’s to build stable, maintainable, and effective software that solves a problem. Sometimes that means embracing the cutting edge, and sometimes it means trusting the battle-tested workhorse. The real skill is knowing the difference.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions