If you have been using React for a few years, the release of Next.js 13+ and the App Router likely felt like a shock to the system. Suddenly, useEffect doesn't work by default, and you see errors about "hydrating" everywhere.

The shift from the "Pages Router" to the "App Router" isn't just a syntax change; it's a fundamental shift in how we build the web. It introduces React Server Components (RSC).

Here is the simple mental model I use to decide when to use which component, and why this architecture is superior for performance.

The Old Way: Client-Side Waterfalls

In the traditional "Create React App" era, your browser would download a massive JavaScript bundle, execute it, and only then start fetching data.

Imagine a dashboard:

1. Browser loads the page skeleton.
2. useEffect runs -> fetches User Data.
3. User Data arrives -> useEffect runs again -> fetches Recent Orders.
4. Recent Orders arrive.

This is the "Waterfall Problem." The user stares at loading spinners for seconds.

The New Way: Server First

With the App Router, components are Server Components by default.

This means your component runs entirely on the server before any HTML is sent to the browser. It connects directly to the database, renders the HTML, and sends the finished result to the user.

The benefits are massive:

• Zero Bundle Size: The code for formatting dates or processing data stays on the server. It is never sent to the user's phone.
• Instant Data: No more waterfalls. The page arrives with the data already inside it.
• Security: You can keep API keys inside your component code because the client never sees it.

The "Use Client" Rule

So, when do you use the old way?

You opt-in to "Client Components" only when you need interactivity. If a user needs to click, scroll, type, or toggle something, that needs to happen in the browser.

My Rule of Thumb:

1. Default to Server: Always start writing a standard component. Fetch your data async/await right in the function body.
2. Add use client only if:
3. • You need useState or useEffect.
   • You need onClick or onChange listeners.
   • You are using browser APIs (like window or localStorage).

Structuring Your App

The best pattern is to keep your "Leaf" components (buttons, inputs) as Client Components, while keeping your "Page" layouts as Server Components.

You fetch the data high up in the Server Component and pass it down as props to the interactive Client Components. This gives you the best of both worlds: the speed of HTML and the interactivity of React.

Conclusion

The learning curve for the App Router is steep, but the payoff in site speed and SEO is undeniable. Once you stop fighting the "Server First" mentality and embrace it, you realize how much unnecessary code you used to write just to manage loading states.

We recently migrated several high-traffic dashboards to this architecture at ApexByte, and the reduction in "Time to Interactive" was immediate. If you're starting a new project today, skip the Pages router—RSC is the future.