Technologies
Next.js App Router Development
The App Router is the routing and rendering model Next.js has been built around since version 13 — file-based routes, nested layouts that persist across navigations, and server components as the default. It changes how a Next.js app is structured, not just how URLs map to files.
I use the App Router as the default for new Next.js projects, and help teams evaluate whether migrating an existing Pages Router app is worth the effort.
What the App Router Changes
- arrow_rightComponents are server components by default, only becoming client components when explicitly marked
- arrow_rightLayouts nest and persist across navigation instead of re-rendering the whole page shell
- arrow_rightRoute groups let you organize routes without affecting the URL structure
- arrow_rightLoading and error states are handled with dedicated file conventions instead of manual state
- arrow_rightData fetching happens directly in server components with async/await, no separate getServerSideProps function
Where I Use It
Every new Next.js project starts on the App Router — it's the actively developed model and the one with the clearest long-term support. For existing Pages Router apps, the migration decision comes down to whether the app is still actively growing; a stable app with no near-term feature roadmap often isn't worth migrating just for its own sake.
Common Mistakes
- arrow_rightMarking a component 'use client' out of habit when it could stay a server component and ship less JavaScript
- arrow_rightFetching data in a client component with useEffect when it could be fetched directly in a server component
- arrow_rightNot using route groups to separate layout concerns (marketing pages vs authenticated app shell)
- arrow_rightMixing data fetching patterns inconsistently across a codebase, making it hard to reason about what runs where
Frequently Asked Questions
Should I migrate my Pages Router app to the App Router?add
Only if the app is actively being extended and would benefit from server components, streaming, or nested layouts. A stable app that's rarely touched usually isn't worth migrating for its own sake — the Pages Router is still fully supported.
Do I need to convert everything to server components?add
No — the App Router lets server and client components coexist. Interactive pieces (forms, anything using state or browser APIs) stay client components; everything else can default to server rendering.
Is the App Router slower to build with?add
There's a learning curve if you're used to getServerSideProps and the old data-fetching model, but once the server/client component split clicks, it's generally faster to build with — less boilerplate for data fetching, and layouts avoid re-fetching shared data on every navigation.