App Router vs. Pages Router
Explore the differences between Next.js App Router and Pages Router to understand how the shift to a server-first model enhances application performance, security, and developer experience. Learn why the App Router is now the default for new projects and how both routing systems can coexist.
We'll cover the following...
If we spend any time looking at older Next.js projects, tutorials, or even some company codebases, we’ll likely see a pages directory. For years, that was the core of every Next.js application. But now, we have the app directory, or the App Router.
It’s tempting to see this as just an “update,” but it’s much more than that.
Think of it like this: The Pages Router was about taking a standard React single-page application (SPA) and giving it server-rendering capabilities. The App Router, on the other hand, asks a different question: “What if we built an application to be server-first from the ground up, using React’s full potential on both the server and the client?”
The head-to-head comparison
Let’s break down the practical differences and see how each one affects us and the performance of our applications.
Feature | Pages Router | App Router | Why It Matters |
Directory | All routes lived in the | All routes now live in the | The name change signals the new paradigm. The |
Component Model | By default, components are Client Components. Every component was a standard React component capable of using state and effects. | Components run on the server unless marked otherwise. | This is the most important change. It means less JavaScript gets sent to the browser by default, leading to faster, lighter initial page loads. |
File Convention | The file itself was the route. For example, | A folder defines the route, and a | This convention is more explicit and organized. It allows the route’s folder to hold all other related files next to the page they are used in, like layouts ( |
Data Fetching | It requires exporting special async functions like | We use the native | This is a huge simplification. Our data fetching logic lives right inside the component that uses it, making the code more intuitive and easier to read. Memorizing special function names is not required. |
Layouts | It is handled with a single, app-wide file. Creating nested layouts (e.g., a dashboard sidebar) was complex and often required third-party libraries. | Layouts are a first-class concept enabled through a new file convention. We can easily nest layouts that persist on navigation, preserving state. | This is a game-changer for UI architecture. We can effortlessly create section-specific layouts that don’t rerender on page changes, leading to faster navigation and a better user experience. |
API Routes | It lived in the | It is handled by | This aligns API endpoints with the same routing structure as our UI, allowing us to organize them logically within our route folders. |
We have now seen that the shift from pages to app is more than a directory rename. It’s a move from a client-centric model to a server-first architecture. Powered by React Server Components, this change brings real-world benefits in performance, security, and developer experience.
This change was not made lightly. It also reflects the latest thinking in full-stack React application development. The App Router is now the default for new projects, and it’s the model we’ll use throughout this course.
That said, many production apps still rely on the Pages Router. Next.js continues to support both routing systems side by side. Gradual migration is common, and both models can even coexist in the same codebase.