This document compares the old architecture of Next.js (before version 13) with the new App Router-based architecture introduced in Next.js 13+. It highlights the key differences in routing, data fetching, layout handling, hydration, and more — in simple terms.

1. Routing System

Old Architecture (pages/)

1. Routing is based on the /pages folder.
2. Each file becomes a route.
3. Example:

New Architecture (app/)

1. Routing is now based on the /app folder.
2. You use page.js inside each route folder.
3. Example:

2. Layouts

Old Architecture

1. One global layout: _app.js and _document.js.
2. Hard to create unique layouts for different routes.

New Architecture

1. Supports nested layouts.
2. Each route can have its own layout.js.
3. Example:

3. Static Site Generation (SSG)

Old Architecture

1. Uses:
2. getStaticProps() → fetch data at build time.
3. getStaticPaths() → generate paths for dynamic routes.

New Architecture

1. Uses:
2. generateStaticParams() → replaces getStaticPaths().
3. fetch() directly in Server Components → replaces getStaticProps().

Example:

4. Server-Side Rendering (SSR)

Old Architecture

1. Uses getServerSideProps() to fetch data on every request.
2. Adds latency for each user request.

New Architecture

1. SSR is automatic using React Server Components.
2. Just use fetch() directly in the component.
3. Pages are cached after the first load.

Revalidation Options:

1. revalidate: 60 → Automatically regenerate every 60 seconds.
2. On-Demand Revalidation → Trigger regeneration manually via API when content updates (great for blogs).

5. Hydration

Old Architecture

1. All pages were fully hydrated on the client.
2. HTML is sent first, then JavaScript is downloaded to make it interactive.
3. Even static parts (like headers) had JavaScript overhead.

New Architecture

1. Only Client Components ("use client") are hydrated.
2. Server Components do not require hydration or JS on the client.
3. Reduces JS bundle size → faster performance.