Shreesh

Why the App Router Confuses People

Most confusion around the Next.js App Router comes from treating it like an upgraded version of the pages/ directory.

It isn’t.

The App Router is better understood as a React Server Component runtime where routing is just the entry point. Once you stop thinking in terms of pages and start thinking in terms of render trees, the architecture becomes far more predictable.

Routing Is Just the Entry Point

In the App Router, routing does not decide what executes. It decides where rendering starts.

Every route is a React Server Component boundary by default.

TXT

app/
 ├─ layout.tsx   ← Server Component
 ├─ page.tsx     ← Server Component
 └─ loading.tsx  ← Streaming boundary

Nothing here runs in the browser unless explicitly marked otherwise. No hydration. No client JavaScript. No accidental leaks.

Server Components Are the Default State

This is the most important mental shift.

TXT
export default function Page() {
  console.log("This never reaches the browser")
  return <h1>Hello</h1>
}

This code executes on the server only. The browser receives rendered output, not logic.

Client Components are not the default — they are intentional opt-ins.

`use client` Is a Boundary, Not a Switch

The "use client" directive does more than enable hooks. It cuts the component tree.

Everything below it becomes client-side. Everything above remains server-only.

TXT
"use client"

export function Counter() {
  const [count, setCount] = useState(0)
  return <button onClick={() => setCount(count + 1)}>{count}</button>
}

This boundary directly affects:

Bundle size
Serialization cost
Performance
Security guarantees

Use it deliberately, not reflexively.

Data Fetching Happens During Render

There is no getServerSideProps in the App Router.

Data fetching happens at render time, as part of the component execution itself.

TXT
const data = await fetch("https://api.example.com/data", {
  cache: "force-cache",
}).then(res => res.json())

This enables:

Automatic request deduplication
Built-in caching
Streaming UI responses
Partial rendering

Fetching is no longer a special lifecycle — it’s just rendering.

Layouts Are Persistent by Design

Layouts do not re-render on navigation unless their data dependencies change.

TXT

Root Layout
 ├─ Dashboard Layout
 │   ├─ Page A
 │   └─ Page B

State, context, and expensive components survive route transitions. This behavior mirrors native applications more than traditional SPAs.

Loading Is a Streaming Boundary

loading.tsx is not just a spinner file. It defines a Suspense boundary.

TXT
export default function Loading() {
  return <Skeleton />
}

The UI streams progressively. Users see content as it becomes ready, not after the entire tree resolves.

This is React concurrency in action, not a Next.js-specific trick.

Error Handling Is Hierarchical

Errors bubble up through the route tree.

TXT

app/
 ├─ error.tsx
 └─ dashboard/
     ├─ error.tsx
     └─ page.tsx

This allows localized recovery and partial failure instead of collapsing the entire application.

Metadata Is Executable Code

Metadata is not configuration — it runs on the server.

TXT
export const metadata = {
  title: "Dashboard",
}

Or dynamically:

TXT
export async function generateMetadata() {
  return {
    title: "Dynamic Page",
  }
}

This enables dynamic SEO without client-side hacks or runtime overhead.

When the Pages Router Still Makes Sense

The Pages Router is still valid when:

Heavy client-side interactivity is unavoidable
Legacy libraries break Server Components
Simplicity matters more than scalability

But for modern, scalable systems, the App Router aligns better with where React is heading.

The Core Insight

The Next.js App Router is not: File-based routing with extra features

It is: React Server Components + Streaming + Caching + Routing

Once you treat it as a rendering system, not just a framework abstraction, the complexity fades.

Final Take

If you fight the App Router, it feels broken.
If you align with it, it feels inevitable.

This is not an experiment — it’s the future of React-based web applications.