Next.js is the most popular React framework for production, offering built-in optimizations, Server-Side Rendering (SSR), and seamless routing. With the release of Next.js 13 (and refined up through Next.js 15), Vercel introduced a paradigm shift: the App Router.

This new architecture fundamentally changed how developers build Next.js applications, introducing React Server Components (RSC), advanced nested layouts, and new data fetching strategies. However, the legacy Pages Router remains fully supported.

For front-end developers and students, understanding the differences between these two routing paradigms is crucial. In this guide, we break down the App Router vs. Pages Router to help you decide which to use for your next project.

---

Table of Contents

1. Routing and Folder Structure
2. React Server Components (RSC) vs. Client Components
3. Data Fetching: getServerSideProps vs. fetch()
4. Nested Layouts and Templates
5. SEO and Metadata Management
6. Should You Migrate to the App Router?
7. Conclusion

---

1. Routing and Folder Structure

The Pages Router (/pages)

In the Pages Router, every .js or .tsx file inside the pages directory automatically becomes a route.

• pages/index.tsx $\rightarrow$ /
• pages/about.tsx $\rightarrow$ /about
• pages/blog/[slug].tsx $\rightarrow$ /blog/my-post

The App Router (/app)

In the App Router, folders define routes, and the UI is rendered by a special page.tsx file inside those folders.

• app/page.tsx $\rightarrow$ /
• app/about/page.tsx $\rightarrow$ /about
• app/blog/[slug]/page.tsx $\rightarrow$ /blog/my-post

The App Router allows you to co-locate components, styles, and tests alongside your routes. In the Pages Router, putting a Button.tsx inside the pages directory would accidentally expose it as a web page (/Button). In the App Router, only page.tsx is routable.

---

2. React Server Components (RSC) vs. Client Components

The biggest innovation in the App Router is its architecture built around React Server Components (RSC).

App Router (Default: Server Components)

By default, all components inside the app directory are Server Components. They are rendered entirely on the server, and no JavaScript is sent to the client for these components.

• Pros: Smaller client bundle size, faster initial page load, and direct access to backend resources (like databases).
• Cons: Cannot use React hooks (useState, useEffect) or browser APIs (like window).

To use interactive client-side features, you must explicitly mark a component with the "use client" directive at the top of the file:

"use client";
import { useState } from "react";

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

Pages Router (Default: Client Components)

In the Pages Router, components are pre-rendered on the server (SSR/SSG), but they hydrate into full client-side React components in the browser. They ship their JavaScript to the client by default.

---

3. Data Fetching: getServerSideProps vs. fetch()

Pages Router Data Fetching

The Pages Router relies on specific Next.js APIs exported from a page file:

• getServerSideProps: For Server-Side Rendering (fetch on every request).
• getStaticProps: For Static Site Generation (fetch at build time).

// Pages Router
export async function getServerSideProps() {
  const res = await fetch('https://api.example.com/data');
  const data = await res.json();
  return { props: { data } };
}

App Router Data Fetching

The App Router simplifies this by using standard asynchronous JavaScript functions and the extended Web fetch API. You can fetch data directly inside a Server Component:

// App Router
export default async function Page() {
  // Fetches data on the server
  const res = await fetch('https://api.example.com/data', { cache: 'no-store' });
  const data = await res.json();

  return <div>{data.title}</div>;
}

You control caching behavior directly using the fetch options (cache: 'force-cache' for static, cache: 'no-store' for dynamic).

---

4. Nested Layouts and Templates

Pages Router

Creating persistent layouts (like a Sidebar or Navbar that doesn't re-render on page changes) in the Pages Router required cumbersome workarounds in the _app.tsx file.

App Router

The App Router natively supports nested layouts via layout.tsx files. A layout wraps all pages and sub-folders within its directory and maintains its state across navigations.

// app/dashboard/layout.tsx
export default function DashboardLayout({ children }: { children: React.ReactNode }) {
  return (
    <section>
      <nav>Dashboard Sidebar</nav>
      <main>{children}</main> {/* Renders the page.tsx content */}
    </section>
  );
}

---

5. SEO and Metadata Management

Pages Router

You manage the <head> of your document using the next/head component inside your page render:

import Head from 'next/head';

export default function Page() {
  return (
    <>
      <Head>
        <title>My Page</title>
      </Head>
      <h1>Content</h1>
    </>
  );
}

App Router

The App Router introduces a powerful static and dynamic Metadata API. You export a metadata object or a generateMetadata function from a page.tsx or layout.tsx file, and Next.js handles injecting it into the HTML head.

import { Metadata } from 'next';

export const metadata: Metadata = {
  title: 'My Page',
  description: 'Page description',
};

export default function Page() {
  return <h1>Content</h1>;
}

---

---

5.5. Server Actions: Eliminating the Need for Separate API Routes

One of the most revolutionary additions in the App Router era is Server Actions. In classic web development (and in the Pages Router), if a user submitted a form, you had to write a client-side fetch request, send it to a separate API route (e.g., pages/api/submit.ts), and handle the response.

Server Actions allow you to define server-side functions that can be called directly from your Client or Server Components. Next.js handles the underlying HTTP POST requests under the hood.

Example Server Action Form Submission:

// app/contact/page.tsx
export default function ContactPage() {
  // A function that runs strictly on the server
  async function handleSubmit(formData: FormData) {
    "use server";
    const email = formData.get("email");
    const message = formData.get("message");
    
    // Perform database insertion directly!
    // await db.contacts.create({ email, message });
    console.log(`Saved contact: ${email}`);
  }

  return (
    <form action={handleSubmit} className="flex flex-col gap-4 p-6 max-w-md">
      <input type="email" name="email" placeholder="Your Email" required className="border p-2 rounded" />
      <textarea name="message" placeholder="Message" required className="border p-2 rounded" />
      <button type="submit" className="bg-emerald-500 text-white p-2 rounded hover:bg-emerald-600">
        Submit Form
      </button>
    </form>
  );
}

By utilizing Server Actions, you reduce the boilerplate code of writing API endpoints, validate forms directly on the server, and achieve a seamless, type-safe full-stack developer experience.

---

6. Should You Migrate to the App Router?

• Starting a New Project: Definitely use the App Router. It is the default, standard path for all new Next.js projects, and Vercel will prioritize all future performance optimizations for the /app directory.
• Maintaining an Existing Project: If your Pages Router application works perfectly, there is no urgent need to migrate. Next.js will continue to support the Pages Router for years to come. However, if your application suffers from slow load times, bloated bundle sizes, or complicated state management, an incremental migration is highly recommended.

Incremental Migration Playbook:

Fortunately, Next.js allows the /app and /pages directories to coexist in the same project. You can migrate your application step-by-step:

1. Migrate Leaf Pages First: Start by moving simple, static pages (like /about or /privacy) from pages/about.tsx to app/about/page.tsx.
2. Convert the Layout: Move your main navigational layout (Navbar, Footer, global state contexts) into the root app/layout.tsx.
3. Handle Server-Side Data fetching: Convert getServerSideProps pages into async Server Components using normal fetch() calls.
4. Identify Client Components: Add the "use client" directive to interactive components (such as sliders, forms, or modal triggers) and keep the parent wrapper as a Server Component.

---

7. Conclusion

The Next.js App Router represents a massive leap forward in React development, embracing Server Components to ship less JavaScript and build faster applications. While it requires unlearning some old patterns and mastering the mental model of Server vs. Client boundaries, it provides a superior developer experience and better performance out of the box.

Suggested Images:

• Featured Image: A sleek comparison graphic showing /pages vs /app folder structures with React logos. (Prompt: Next.js App router vs Pages router concept, neon Vercel colors).
• Inline Image: A diagram showing the execution difference between React Server Components and Client Components.

Alt Texts:

• Featured Image: "Next.js 15 App Router vs Pages Router architecture"
• Inline Image: "React Server Components vs Client Components rendering flow"

Internal Linking Suggestions:

• Learn about structuring projects in MERN Stack Best Practices.
• Prepare for technical rounds with our DSA Roadmap.