Next.js from Zero - React Grows a Server

You know React. Then you open a Next.js project and the rules seem to have changed: components run on a server now, some files are magically routes, useState throws an error in one file and works fine in the next, and pages are somehow stale until you sprinkle the right incantation. None of it is magic - all of it follows from one move: Next.js puts a server in front of your React app, and everything the framework does is about deciding what happens on that server versus in the browser.

This guide builds that model from the request up. By the end, "why is this a server component," "why is this page cached," and "why did hydration fail" all have answers you can reason to, not memorize.

⏭️ New to React itself? Read React from Zero first - this guide assumes components, props, state, and effects are already solid.

How to read this

In a panic right now? Jump to Phase 7: When Next.js Breaks and use the cheat-card at the top.
Want it to finally make sense? Read in order - the server/client split in Phase 3 is the hinge the whole framework turns on.

The phases

What Next.js Actually Is - what a plain React app can't do, and what putting a server in front of it buys you.
Routing with Files - folders become URLs; page, layout, and dynamic segments.
Server and Client Components - the big split: what runs where, and what 'use client' really marks.
Data on the Server - async components, loading.tsx, streaming, and error boundaries.
Mutations: Forms and Server Actions - writing data without hand-building an API layer.
Static, Dynamic, and the Cache - why your page is stale (or slow), and how Next decides at build time.
When Next.js Breaks - hydration mismatches, hook errors, serialization walls, and stale pages, decoded.
Where to Go Next - deployment, metadata, images, and what to ignore.

Deliberately deferred to follow-up guides: authentication patterns, advanced caching internals, parallel/intercepting routes, middleware-heavy architectures, and testing. Core model first.