How Modern Next.js Actually Works and Interview Guide
I am a javascript developer from Bangladesh. I love to work with javascript modern frameworks and libraries. Although I have a sour and sweet relationship with programming.🥺
Modern App Router + React Server Components + RSC Payload + Bundling + Hydration + Streaming + Prefetching Deep Dive
📘 How To Read These Notes
These notes are structured in:
🧠 Mental models first
⚙️ Internal architecture second
🔄 Step-by-step flows third
🎯 Interview understanding last
Every section contains:
Core concept
Internal flow
Runtime behavior
Mental picture
Interview questions
Goal:
After reading these notes,
you should be able to:
- visualize the full Next.js lifecycle
- explain modern architecture clearly
- answer interview questions confidently
- understand WHY Next.js is fast
🔥 MOST IMPORTANT MODERN NEXT.JS UNDERSTANDING
Server Components
↓
Generate HTML + RSC payload
Client Components
↓
Generate browser JS bundles + hydration
This is the core architecture shift from old React SPA systems.
🚨 COMMON BEGINNER CONFUSIONS
| Confusion | Correct Understanding |
|---|---|
| “use client” means CSR | ❌ Wrong |
| Server Components create browser bundles | ❌ Usually wrong |
| Hydration creates HTML | ❌ Wrong |
| Browser runs Server Components | ❌ Wrong |
| HTML appears after JS download | ❌ Wrong |
✅ CORRECT MODERN FLOW
Server executes Server Components
↓
Generate HTML + RSC payload
↓
Browser paints HTML immediately
↓
Browser downloads Client Component JS
↓
Hydration activates interactivity
Complete Modern Next.js Mental Model & Interview Guide
Table of Contents
What is Next.js Really?
High-Level Architecture
Build Phase Internals
Dependency Graph & Bundling
Route-Based Code Splitting
Tree Shaking
Webpack vs Turbopack
Rendering Strategies (SSR, SSG, ISR, CSR)
Modern Next.js Architecture
Server Components vs Client Components
Hydration
React Server Component (RSC) Payload
Streaming Architecture
Full Request Lifecycle
Prefetching System
End-to-End Browser Navigation Flow
Modern Mental Models
Most Important Interview Questions
1. What is Next.js Really?
Most developers think Next.js is only:
React framework
But internally, modern Next.js is much bigger.
Real Mental Model
Next.js is:
A compiler
+ bundler
+ router
+ rendering engine
+ caching system
+ server framework
+ React orchestration layer
Its job:
1. Analyze your app
2. Split server/client code
3. Create optimized bundles
4. Render HTML efficiently
5. Send minimal JavaScript
6. Hydrate interactivity
7. Cache aggressively
8. Stream UI efficiently
Ultimate Big Picture
Developer writes React app
↓
Next.js analyzes app
↓
Creates dependency graph
↓
Separates server/client code
↓
Creates optimized chunks
↓
Handles requests
↓
Fetches data
↓
Renders React
↓
Generates HTML + RSC payload
↓
Sends minimal JS
↓
Browser hydrates app
↓
Fast interactive website
Interview Questions
Q: What is Next.js internally?
Answer:
Next.js is a full-stack React framework that combines routing, rendering, bundling, server execution, caching, and streaming into a unified architecture.
Q: Why is Next.js faster than plain React SPA?
Answer:
Because it supports:
Server rendering
Static generation
Route-based code splitting
Streaming
Server Components
Smart caching
Prefetching
Optimized bundling
2. High-Level Architecture
Modern Next.js has TWO worlds.
| World | Runs Where | Purpose |
|---|---|---|
| Server World | Node.js / Edge | Data fetching, DB access, rendering |
| Client World | Browser | Interactivity |
Core Understanding
Next.js automatically decides:
What runs on server?
What runs in browser?
What should be bundled?
What should stay private?
Internal Architecture Flow
SERVER SIDE
--------------------------------
Routing
Data Fetching
DB Queries
Server Components
HTML Generation
RSC Payload Generation
Caching
Streaming
CLIENT SIDE
--------------------------------
Render HTML
Download JS bundles
Hydration
Client Navigation
State Updates
Interactive UI
Most Important Understanding
Browser should NOT receive:
database queries
secrets
Prisma code
server utilities
Browser SHOULD receive:
HTML
minimal JS
client component bundles
RSC payload
Interview Questions
Q: What are the two execution environments in Next.js?
Answer:
The server environment handles rendering, data fetching, and secure logic, while the client environment handles browser interactivity and hydration.
Q: Why are Server Components important?
Answer:
Because they:
Reduce browser JavaScript
improve performance
keep secrets secure
allow direct DB access
reduce hydration cost
3. Build Phase Internals
When you run:
npm run build
Next.js starts analyzing your app.
Build Pipeline
Read Files
↓
Analyze Imports
↓
Create Dependency Graph
↓
Detect Routes
↓
Separate Server/Client Code
↓
Create Bundles
↓
Generate Static Pages
↓
Create Server Runtime
STEP 1 — File System Scanning
Next.js scans:
app/
pages/
Example:
app/about/page.tsx
becomes:
/about
STEP 2 — Dependency Analysis
Next.js analyzes imports:
page.tsx
└── Header.tsx
└── Navbar.tsx
Creates graph:
Page
└── Header
└── Navbar
This graph powers:
bundle splitting
tree shaking (Removing unused code from the final bundle)
shared chunks
route optimization
STEP 3 — Server vs Client Separation
Next.js checks:
"use client"
Flow:
All Components
↓
Check "use client"
↓
Server Bucket Client Bucket
STEP 4 — Bundle Generation
Bundler creates optimized chunks.
Example:
home.bundle.js
dashboard.bundle.js
vendor.bundle.js
STEP 5 — Static Optimization
Next.js asks:
Can this page be pre-rendered?
If YES:
Generate static HTML during build
Build Output
Generated inside:
.next/
Contains:
server/
static/
chunks/
cache/
Interview Questions
Q: What happens during Next.js build?
Answer:
Next.js scans routes, analyzes dependencies, separates server/client components, creates optimized bundles, generates static assets, and prepares the server runtime.
Q: What is dependency graph analysis?
Answer:
The bundler builds a graph of module relationships to understand which files depend on each other. This enables code splitting, tree shaking, and shared chunk extraction.
4. Dependency Graph & Bundling
This is one of the MOST important concepts.
Bundlers do NOT think in pages.
They think in:
Dependency Graphs
Routes are entry points into the graph.
Example
Dashboard Page
├── Navbar
├── Chart
└── Table
Another route:
About Page
├── Navbar
└── Team
Bundler detects:
Navbar shared across routes
Shared Chunk Extraction
Instead of duplicating:
Navbar copied everywhere
Bundler creates:
shared-navbar.chunk.js
Final Output
shared.chunk.js
about.chunk.js
dashboard.chunk.js
vendor-react.chunk.js
Why This Matters
Benefits:
smaller downloads
browser cache reuse
faster navigation
less duplication
Browser Request Flow
User visits:
/dashboard
Next.js checks route manifest:
/dashboard requires:
- shared.chunk.js
- dashboard.chunk.js
Only those bundles sent.
Mental Model
Each route gets:
↓
Minimal route-specific JS
↓
Plus shared chunks
↓
Plus dynamic chunks if needed
Interview Questions
Q: Does Next.js bundle per page?
Answer:
Yes. Next.js performs route-based code splitting. Each route gets optimized bundles while shared dependencies are extracted into shared chunks.
Q: Why are shared chunks useful?
Answer:
Shared chunks avoid duplication across routes and allow browsers to reuse cached JavaScript.
5. Route-Based Code Splitting
Modern Next.js automatically performs:
Route-level splitting
+ Component-level splitting
+ Dynamic import splitting
+ RSC payload splitting
Example
app/
├── page.tsx
├── about/page.tsx
└── dashboard/page.tsx
Possible output:
home.bundle.js
about.bundle.js
dashboard.bundle.js
Dynamic Import Splitting
import dynamic from "next/dynamic";
const Chart = dynamic(() => import("./Chart"));
Now:
Chart code loads only when needed
Why Dynamic Splitting Matters
Without splitting:
Download all dashboard code immediately
With dynamic splitting:
Load heavy components lazily
Useful for:
charts
editors
maps
large dashboards
Route Splitting Flow
Route Files
↓
Dependency Analysis
↓
Shared Dependency Detection
↓
Chunk Generation
↓
Manifest Creation
↓
Browser loads required chunks only
Interview Questions
Q: What is code splitting?
Answer:
Code splitting breaks the application into smaller bundles so users only download the JavaScript needed for the current route or feature.
Q: What is dynamic import?
Answer:
Dynamic import lazily loads modules at runtime and creates separate chunks that load only when required.
6. Tree Shaking
Tree shaking removes unused code.
Example
import { add, subtract } from "./math";
If only:
add()
is used:
subtract removed from final bundle
Why Tree Shaking Important
Without it:
Unused code ships to browser
With it:
Smaller bundles
Faster downloads
Better performance
Interview Questions
Q: What is tree shaking?
Answer:
Tree shaking is the process of removing unused exports from the final bundle during build optimization.
7. Webpack vs Turbopack
Both are bundlers.
Their job:
Source Code
↓
Analyze Dependencies
↓
Bundle/Split/Optimize
↓
Generate Browser-Ready Assets
Why Webpack Became Slow
Modern apps contain:
thousands of modules
TypeScript
monorepos
huge dependency graphs
server/client splitting
advanced HMR
Webpack struggles with repeated rebuilds.
Webpack Flow
File Change
↓
Re-analyze graph
↓
Rebuild many modules
↓
Update browser
Turbopack Architecture
Built with:
Rust
incremental computation
fine-grained invalidation
parallel execution
Turbopack Core Idea
Recompute ONLY what changed
Example
Edit:
Chart.tsx
Webpack may rebuild:
Chart
Dashboard
Shared chunks
Dependencies
Turbopack tries:
Only Chart-related graph updates
Major Differences
| Feature | Webpack | Turbopack |
|---|---|---|
| Language | JavaScript | Rust |
| Incremental Engine | Limited | Advanced |
| HMR | Good | Extremely Fast |
| Large Apps | Heavy | Optimized |
| Parallelism | Limited | Better |
| Modern RSC Support | Older Architecture | Native-first |
Development Experience
Webpack
Save file
Wait seconds
Browser updates
Turbopack
Save file
Almost instant update
Production Reality
| Area | Status |
|---|---|
| Development | Turbopack Excellent |
| Production Builds | Webpack still widely stable |
What Should You Use?
Development:
next dev --turbopack
especially for:
large apps
monorepos
TypeScript
Important Understanding
Neither Webpack nor Turbopack runs in browser.
They are:
Build-time and development-time tools
Their output becomes:
Optimized JS/CSS bundles
Interview Questions
Q: Why is Turbopack faster?
Answer:
Turbopack uses incremental computation, fine-grained dependency tracking, Rust-based performance, and smarter invalidation to recompute only the changed parts of the dependency graph.
Q: What is the biggest conceptual shift from Webpack to Turbopack?
Answer:
Webpack is rebuild-oriented while Turbopack is incremental and reactive.
8. Rendering Strategies (SSR, SSG, ISR, CSR)
This is a foundational interview topic.
Important Modern Understanding
Modern Next.js still uses:
SSR
SSG
ISR
CSR
BUT modern architecture is now component-driven.
Rendering Strategy Table
| Strategy | Meaning |
|---|---|
| SSR | Render per request |
| SSG | Build-time render |
| ISR | Regenerated cached render |
| CSR | Browser rendering |
SSR — Server Side Rendering
HTML generated on every request.
Flow:
Request
↓
Server renders React
↓
HTML generated
↓
Browser receives page
Example
export default async function Page() {
const users = await fetch(...)
}
SSR Pros
SEO friendly
fresh data
secure
personalized content
SSR Cons
more server work
slower than static
SSG — Static Site Generation
Generated during build.
Flow:
Build
↓
HTML generated
↓
CDN serves static file
Perfect for:
blogs
docs
landing pages
ISR — Incremental Static Regeneration
Hybrid model.
export const revalidate = 60;
Meaning:
Regenerate every 60 seconds
Flow:
Request
↓
Serve cached HTML
↓
Background regeneration
CSR — Client Side Rendering
Browser downloads JS first.
Flow:
HTML shell
↓
Download JS
↓
React renders in browser
Useful for:
interactive dashboards
charts
highly dynamic UI
Important Modern Mapping
| Modern Behavior | Old Concept |
|---|---|
| Dynamic rendering | SSR |
| Static prerender | SSG |
| Revalidation | ISR |
| Browser rendering | CSR |
Interview Questions
Q: Difference between SSR and CSR?
Answer:
SSR renders HTML on the server before sending it to the browser, while CSR renders the UI inside the browser after JavaScript loads.
Q: When should ISR be used?
Answer:
ISR is ideal for pages that need mostly static performance but require periodic data freshness.
9. Modern Next.js Architecture
Old Mental Model (Pages Router Era)
Focus:
SSR
SSG
ISR
CSR
Using:
getServerSideProps
getStaticProps
Modern Mental Model (App Router Era)
Focus:
Server Components
Client Components
Streaming
RSC Payload
Caching
Biggest Shift
Old Next.js:
Page-level rendering
Modern Next.js:
Component-level architecture
Modern Granular Rendering
Inside same page:
Some parts server-rendered
Some parts client-rendered
Some streamed
Some cached
Example
<Page>
<ServerRenderedProducts />
<ClientCart />
<StreamingReviews />
</Page>
Important Understanding
"use client"
DOES NOT mean:
Entire page rendered in browser
It only means:
This component requires browser JavaScript
Interview Questions
Q: What changed in modern Next.js?
Answer:
Modern Next.js moved from page-level rendering architecture to component-level server/client architecture with streaming and React Server Components.
10. Server Components vs Client Components
This is now the MOST important architectural concept.
Server Components
Default behavior.
Example:
export default async function Page() {}
Characteristics
run on server
not shipped to browser
direct DB access
smaller bundles
secure
Client Components
"use client";
Characteristics:
bundled for browser
interactive
supports useState/useEffect
hydrated in browser
Comparison Table
| Feature | Server Component | Client Component |
|---|---|---|
| Runs on server | YES | NO |
| Runs in browser | NO | YES |
| Access DB | YES | NO |
| useState | NO | YES |
| Browser bundle | Usually no | YES |
Internal Flow
Server Components
↓
Rendered on server
↓
Generate HTML/RSC payload
Client Components
↓
Bundled for browser
↓
Hydrated later
Most Important Modern Understanding
Modern React is becoming:
Server-first architecture
instead of:
Browser-first SPA architecture
Interview Questions
Q: Why are Server Components powerful?
Answer:
They reduce client JavaScript, improve performance, keep sensitive logic secure, and allow direct server-side data access.
Q: What does “use client” actually do?
Answer:
It marks a component as client-side interactive code that must be bundled and hydrated in the browser.
11. Hydration
One of the MOST asked interview topics.
What is Hydration?
Hydration means:
React attaching interactivity to static HTML
Example
Server sends:
<button>Like</button>
Initially:
Visible but non-interactive
After JS loads:
React attaches click handlers
Now interactive.
Hydration Flow
Server HTML
↓
Browser displays immediately
↓
Download JS bundles
↓
React hydrates components
↓
Interactive application
Why Hydration Exists
HTML alone:
cannot manage state
cannot handle events
cannot update dynamically
Hydration connects:
event listeners
React state
browser behavior
Important Understanding
Hydration does NOT generate UI.
The UI already exists from server HTML.
Hydration adds:
Behavior + React runtime connectivity
Interview Questions
Q: What is hydration?
Answer:
Hydration is the process where React attaches JavaScript behavior and event handling to server-rendered HTML.
Q: Why is hydration needed?
Answer:
Because static HTML alone cannot support interactivity, state updates, or React event handling.
12. React Server Component (RSC) Payload
This is the MOST important modern React/Next.js topic.
The Problem RSC Solves
Old SPA architecture:
Download huge JS
↓
Run React entirely in browser
↓
Render UI
Problems:
large bundles
slower initial load
poor scalability
browser-heavy rendering
Core RSC Idea
Some components run ONLY on server
Browser receives:
final HTML
lightweight instructions
instead of full app logic.
Modern Response Structure
Modern Next.js sends:
1. HTML
2. RSC Payload
3. Client JS bundles
What HTML Does
Immediate screen paint
What RSC Payload Does
Helps React:
reconstruct component tree
identify client boundaries
hydrate correctly
handle navigation updates
Think of RSC Payload As
Serialized React component instructions
Example Architecture
<Page>
<ProductList />
<Cart />
</Page>
Suppose:
ProductList = Server Component
Cart = Client Component
Internal Flow
STEP 1 — Request Arrives
/products
STEP 2 — Server Executes Server Components
const products = await db.products.findMany()
Runs safely on server.
STEP 3 — React Builds Tree
Page
├── ProductList (server)
└── Cart (client)
STEP 4 — Generate HTML
Browser can paint immediately.
STEP 5 — Generate RSC Payload
Payload contains:
| Data | Purpose |
|---|---|
| component structure | rebuild tree |
| props | data transfer |
| client markers | hydration boundaries |
| module references | know JS requirements |
STEP 6 — Send Response
HTML
+
RSC payload
+
client bundles
STEP 7 — Browser Reads Payload
React reconstructs component tree.
STEP 8 — Hydration
Client components become interactive.
Full Visual Flow
SERVER
--------------------------------
Run Server Components
↓
Fetch DB/API data
↓
Generate HTML
↓
Generate RSC Payload
↓
Send response
BROWSER
--------------------------------
Render HTML immediately
↓
Read RSC Payload
↓
Rebuild component tree
↓
Hydrate Client Components
↓
Interactive UI
Why RSC Is Powerful
Without RSC:
Huge browser JS
With RSC:
Server does heavy work
Browser receives lightweight instructions
Benefits:
smaller bundles
faster loads
better scalability
secure server logic
less hydration cost
Extremely Important Understanding
HTML:
Shows UI
RSC payload:
Explains how UI was constructed
Navigation Optimization
Modern Next.js often fetches:
ONLY new RSC payload
instead of full page reload.
This enables:
instant transitions
partial rendering
streaming
Interview Questions
Q: What is the RSC payload?
Answer:
The RSC payload is a serialized representation of the React Server Component tree that helps the browser reconstruct the UI hierarchy and hydrate client components efficiently.
Q: Why is RSC architecture important?
Answer:
It significantly reduces browser JavaScript and shifts heavy rendering work back to the server.
13. Streaming Architecture
Streaming allows UI to arrive progressively.
Traditional Rendering
Wait entire page
↓
Send full response
Streaming Rendering
Navbar first
Sidebar second
Content later
Reviews later
UI appears progressively.
Why Streaming Matters
Without streaming:
Slow API blocks entire page
With streaming:
Fast sections appear immediately
Slow sections arrive later
Streaming + Suspense
Streaming heavily works with:
React Suspense
Streaming + RSC
RSC payload itself can stream incrementally.
Example:
Navbar first
Products later
Reviews later
Interview Questions
Q: What is streaming in Next.js?
Answer:
Streaming allows the server to progressively send UI chunks to the browser instead of waiting for the entire page to finish rendering.
14. Full Request Lifecycle
This combines everything together.
Initial Request Lifecycle
User visits page
↓
Request hits server
↓
Next.js matches route
↓
Fetch data
↓
Render React tree
↓
Generate HTML
↓
Generate RSC payload
↓
Send HTML + RSC + JS
↓
Browser paints page
↓
Download JS bundles
↓
Hydration
↓
Interactive app
Runtime Architecture
SERVER SIDE
--------------------------------
Route Match
Fetch Data
Render React
Generate HTML
Generate RSC Payload
Send Response
CLIENT SIDE
--------------------------------
Paint HTML
Download JS
Hydrate React
Interactive UI
Most Important Understanding
Modern Next.js tries to:
Move as much work as possible to the server
while minimizing browser JavaScript.
Interview Questions
Q: Explain the full lifecycle of a Next.js request.
Answer:
A request reaches the Next.js server, the route is matched, data is fetched, React renders the component tree on the server, HTML and the RSC payload are generated, the browser receives them, paints the HTML, downloads client bundles, and hydrates interactive components.
15. Prefetching System
One of the MOST important modern performance features.
The Problem Without Prefetching
Traditional navigation:
Click
↓
Fetch route resources
↓
Render
Delay happens AFTER click.
Core Prefetching Idea
Next.js predicts:
User may click this link soon
So it downloads resources BEFORE click.
Internal Flow
Render page
↓
Observe visible <Link>
↓
Link enters viewport
↓
Schedule prefetch
↓
Download route resources
↓
Store in cache
How Visibility Detected
Using:
Intersection Observer
What Gets Prefetched?
Modern App Router may prefetch:
RSC payload
route metadata
loading boundaries
client JS chunks
Navigation After Prefetch
Click
↓
Read prefetched cache
↓
Update React tree
↓
Instant render
WITHOUT PREFETCH
Click
↓
DNS/TCP wait
↓
Download route JS
↓
Fetch data
↓
Render
WITH PREFETCH
Before click:
Route resources cached
Click:
Immediate route transition
Automatic Prefetch
<Link href="/about" />
Disable Prefetch
<Link href="/about" prefetch={false} />
Useful for:
massive routes
mobile bandwidth
expensive pages
Advanced Mental Model
VISIBLE LINK
↓
Intersection Observer detects visibility
↓
Next.js prefetch scheduler runs
↓
Fetch RSC payload + JS chunks
↓
Store in router cache
↓
User clicks
↓
React merges prefetched server tree
↓
Partial UI update without reload
Why Prefetching Powerful
Benefits:
near-instant navigation
app-like UX
lower perceived latency
smoother transitions
Downsides
bandwidth usage
memory usage
unused downloads
Interview Questions
Q: What is prefetching?
Answer:
Prefetching downloads future route resources before navigation so transitions become much faster.
Q: How does Next.js prefetch routes?
Answer:
Next.js observes visible Link components and automatically fetches route resources in the background using low-priority requests.
Q: What gets prefetched in App Router?
Answer:
App Router may prefetch React Server Component payloads, route metadata, loading boundaries, and required JavaScript chunks.
16. End-to-End Browser Navigation Flow
Initial Page Load
Browser requests route
↓
Next.js server matches route
↓
Fetch server data
↓
Render React tree
↓
Generate HTML + RSC payload
↓
Send minimal JS bundles
↓
Browser paints page
↓
Hydration
↓
Interactive UI
Client Navigation
User clicks <Link>
↓
Check router cache
↓
If prefetched → instant transition
↓
If not → fetch route resources
↓
Fetch new RSC payload
↓
React merges updated tree
↓
Partial UI update
Most Important Modern Understanding
Modern Next.js navigation is NOT:
Traditional full-page reload
It is:
Partial React tree replacement
using:
RSC payloads
router cache
client-side transitions
17. Modern Mental Models
Old React SPA Mental Model
Browser downloads app
↓
Browser runs entire React app
↓
Browser renders UI
Modern Next.js Mental Model
Server renders most UI
↓
Browser receives HTML + instructions
↓
Hydrate only interactive parts
Ultimate Next.js Brain Picture
Developer writes React app
↓
Next.js analyzes dependency graph
↓
Separates server/client components
↓
Creates optimized chunks
↓
Renders on server
↓
Generates HTML + RSC payload
↓
Streams response
↓
Browser hydrates client components
↓
Fast interactive application
Most Important Interview Understanding
Modern Next.js is:
Component-driven server-first architecture
where:
Server/Client Components determine execution environment
SSR/SSG/ISR/CSR determine rendering strategy
RSC payload enables efficient browser updates
Streaming improves perceived performance
Prefetching accelerates navigation
18. Most Important Interview Questions
Architecture
Q: What is the biggest architectural shift in modern Next.js?
The shift from page-level rendering architecture to component-level server/client rendering architecture.
Q: Why are React Server Components important?
They reduce browser JavaScript, improve scalability, keep server logic secure, and enable server-first rendering.
Rendering
Q: Difference between SSR and SSG?
SSR renders per request, while SSG pre-generates HTML during build time.
Q: What is ISR?
ISR combines static performance with periodic regeneration for fresh data.
Bundling
Q: How does route-based code splitting work?
The bundler analyzes the dependency graph for each route, extracts shared dependencies, and generates route-specific chunks loaded on demand.
Q: Why is Turbopack faster?
Because it uses incremental computation and fine-grained dependency invalidation instead of broad rebuilds.
Hydration
Q: What is hydration?
Hydration is React attaching JavaScript interactivity to already-rendered HTML.
RSC Payload
Q: What is the RSC payload?
A serialized representation of the server-rendered React component tree used by the browser to reconstruct and hydrate the UI efficiently.
Prefetching
Q: How does Next.js prefetch routes?
Next.js observes visible links and prefetches route resources in the background before navigation occurs.
Final One-Line Mental Model
Next.js is a server-first React architecture that intelligently splits execution between server and browser, streams HTML and RSC payloads efficiently, minimizes client JavaScript, and enables fast interactive navigation through caching, hydration, and prefetching.
FINAL MODERN NEXT.JS MENTAL MODEL
This is the most important complete mental picture.
OLD REACT SPA MENTAL MODEL
Browser downloads huge JS
↓
React runs entirely in browser
↓
Browser renders UI
↓
Hydration everywhere
Problems:
huge JS bundles
slower initial load
browser-heavy rendering
poor scalability
MODERN NEXT.JS MENTAL MODEL
SERVER
--------------------------------
1. Request comes
↓
2. Server executes Server Components
↓
3. Fetch DB/API data
↓
4. React renders component tree
↓
5. Generate HTML
↓
6. Generate RSC payload
↓
7. Detect Client Components
↓
8. Send:
- HTML
- RSC payload
- Client JS references
BROWSER
--------------------------------
9. Browser receives HTML
↓
10. Browser paints UI immediately
↓
11. Browser reads RSC payload
↓
12. Browser downloads required JS bundles
↓
13. React hydrates Client Components
↓
14. Interactive UI becomes active
MOST IMPORTANT UNDERSTANDING
Server Components
Usually produce:
HTML + RSC payload
Usually DO NOT produce:
Browser JS bundles
Because they:
run only on server
are not hydrated
do not need browser runtime
Client Components
Produce:
Browser JS bundles
+ hydration
+ interactivity
because browser must:
attach event handlers
manage state
run React runtime
HYDRATION MENTAL MODEL
HTML appears first
↓
JS downloads later
↓
Hydration happens later
↓
Interactive behavior activates
WHY MODERN NEXT.JS IS FAST
Because:
Less JavaScript shipped
↓
More work moved to server
↓
HTML visible immediately
↓
Only interactive parts hydrated
MODERN ARCHITECTURE GOAL
Static/server UI
↓
NO browser JS
Interactive UI
↓
Only necessary JS
ULTIMATE BRAIN PICTURE
Developer writes React app
↓
Next.js analyzes dependency graph
↓
Separates Server/Client Components
↓
Creates optimized chunks
↓
Server renders React tree
↓
Generates HTML + RSC payload
↓
Browser paints HTML immediately
↓
Downloads only required client JS
↓
Hydrates interactive components
↓
Fast modern web app
FINAL INTERVIEW UNDERSTANDING
Modern Next.js is:
A server-first, component-driven React architecture
where:
Server Components execute on the server
Client Components execute in the browser
RSC payload connects server and browser React trees
HTML is streamed early for fast paint
Hydration activates interactivity later
Only the necessary JavaScript is shipped to the browser
🔥 COMPLETE END-TO-END FLOW
==================================================
BUILD PHASE
==================================================
Developer writes React app
↓
Next.js scans app/ routes
↓
Analyze imports
↓
Create dependency graph
↓
Detect Server vs Client Components
↓
Create optimized chunks/bundles
↓
Extract shared chunks
↓
Tree shaking removes unused code
↓
Generate static pages if possible
↓
Prepare server runtime
==================================================
REQUEST PHASE
==================================================
Browser requests page
↓
Request reaches Next.js server
↓
Route matched
↓
Server executes Server Components
↓
Fetch DB/API data
↓
React renders component tree
↓
Generate HTML
↓
Generate RSC payload
↓
Detect Client Components
↓
Send:
- HTML
- RSC payload
- Client JS references
==================================================
BROWSER PHASE
==================================================
Browser receives HTML
↓
Browser paints UI IMMEDIATELY
↓
Browser reads RSC payload
↓
Browser downloads required JS bundles
↓
React hydrates Client Components
↓
Interactive UI becomes active
==================================================
NAVIGATION PHASE
==================================================
User clicks <Link>
↓
Check router cache
↓
If prefetched:
instant navigation
Else:
fetch route resources
↓
Fetch new RSC payload
↓
React merges updated tree
↓
Partial UI update
↓
No full page reload
==================================================
PREFETCH FLOW
==================================================
Link enters viewport
↓
Next.js predicts future navigation
↓
Prefetch:
- RSC payload
- route metadata
- JS chunks
↓
Store in router cache
↓
Later click becomes instant
==================================================
HYDRATION FLOW
==================================================
HTML appears FIRST
↓
JS downloads LATER
↓
Hydration happens LATER
↓
Interactive behavior activates
