Next.js from Zero - React Grows a Server

What Next.js adds to React and why - file routing, server components, data fetching, caching - explained from the request up, so the framework stops feeling like magic conventions.

1. What Next.js Actually Is Next.js is a server wrapped around React: it renders your components to HTML before the browser sees them, which is what buys you fast first paint, SEO, and server-side data access.
2. Routing with Files In the app directory, folders are URL segments: page.tsx makes a route public, layout.tsx wraps children persistently, [param] folders capture dynamic segments, and Link navigates without reloads.
3. Server and Client Components Components are server-only by default - they run at the server render and ship no JS; 'use client' marks the subtree that also runs in the browser, which is what hooks and event handlers require.
4. Data on the Server Server components fetch with plain async/await - no useEffect, no loading flags in state; loading.tsx and Suspense stream the slow parts, and error.tsx catches what throws.
5. Mutations: Forms and Server Actions A server action is a function marked 'use server' that the framework turns into an endpoint - forms call it directly, revalidatePath refreshes what it changed, and route handlers remain for real HTTP APIs.
6. Static, Dynamic, and the Cache Next prerenders every route it can at build time; reading cookies, headers, or searchParams makes a route dynamic, and revalidate turns static pages into ones that refresh themselves.
7. When Next.js Breaks Hydration mismatches, 'use client' demands, serialization walls, window is not defined, and stale pages - the five Next.js failures everyone hits, decoded back to the server/client split.
8. Where to Go Next Deployment options weighed plainly, the built-in metadata/image/font optimizations worth switching on, and which parts of the Next ecosystem to defer until a real need shows up.