Nine posts. One request.

This one is short, and it's the one to bookmark. Everything below is the full lifecycle in order, with each step pointing at the post that explains it.

You knew a lot. You have worked with React for several years, deployed several projects, but it is well worth knowing what's happening. Specially now, when AI is writing a lot of code, let's be better engineers!

The lifecycle

You type a URL and hit enter.

The request reaches your server. Nothing in the browser has executed. (One thing on the server has: proxy.ts runs before routing on every request — the single exception to everything below. It's an appendix to the first post.) → What Runs When

Something decides whether to run your code at all.

If the route was prerendered, two files come off disk and no component executes. If it wasn't, everything below happens now, per request. → What Runs When

Your Server Components execute.

In Node. They query databases, read files, hold secrets. They run once and are finished. Their code never enters a browser bundle. → What Runs When

They produce a payload, not HTML.

A text description of a component tree. Where a client component was, there's a hole with an address on it. → What Runs When

The address came from your bundler.

Which resolved your imports, transformed your TypeScript, walked your module graph, split it into chunks, and assigned every module a stable ID. → What Your Bundler Actually Does

And there were two graphs, not one.

A server graph and a client graph, built from one repo, with "use client" as the boundary between them and a manifest as the phone book. → Two Graphs, One Repo

A second renderer turns the payload into HTML.

It resolves each address, loads the real client component, and executes it — on the server. Producing a string. No CSS is evaluated, no layout is computed, nothing is painted. → What Runs When

Parts of the tree aren't ready, so they're sent later.

Suspense boundaries let the response stay open. The shell ships, and missing pieces arrive as more rows on the same connection. → Suspense Is Not a Loading Spinner

The browser paints. Nothing is interactive.

HTML on screen, no React yet. Late-arriving content still fills in, patched by a small inline script that runs before hydration. → Rendering Patterns, Suspense Is Not a Loading Spinner

JavaScript arrives and React wakes up.

It reads the payload, reconstructs the tree, resolves the same addresses against a different manifest, and executes your client components a second time — attaching handlers to DOM that already exists. → What Runs When

Which is reconciliation, doing what it always did.

Elements, keys, diffing, the commit phase. RSC changed where elements come from, not what React does with them. → How React Actually Updates the DOM

The user clicks a link.

Server Components for the new route execute. A payload comes back. No HTML at all. React diffs the new tree against the old one, and layouts that didn't change don't re-render. → What Runs When

The user submits a form.

A POST to a generated endpoint, addressed by an ID the bundler assigned. The function runs on your server. The response is a new tree, not JSON — so the mutation and the refetch are one round trip. → A Mutation, End to End

The user clicks a button.

State changes. React re-renders a subtree and mutates the DOM. Nothing leaves the machine. This is the only moment that is ordinary React. → What Runs When

And that state was smaller than you expected.

Because the data belongs to the server, anything shareable belongs to the URL, and form values belong to the form. What's left is local and ephemeral. → What's Actually Left for the Client

Effects synchronise the rest.

Not lifecycle hooks. Setup and cleanup pairs, keeping something outside React in step with something inside it. → Effects Are Not Lifecycle

Reading order

Start here if you want the shape: What Runs When, and What Comes Out. Everything else is a zoom into one of its steps.

Start here if you want the build: What Your Bundler Actually Does, then Two Graphs, One Repo.

Start here if you're debugging something specific: whichever step above matches your symptom.

Two posts sit outside the numbered lifecycle:

JavaScript Modules is the prerequisite for the bundler chapters — how imports form the graph everything else builds on.

What Redux Was Actually For is a companion to What's Actually Left for the Client — for the applications where the answer genuinely is "a lot of client state," and for untangling what a store was ever solving.

The pattern underneath

One thing worth naming, having got here.

Almost every confusion this series untangled came from a name that implied the wrong thing.

Render suggested pixels; it means calling a function.
"use client" suggested a location; it means a boundary.
Suspense suggested a spinner; it means a transport guarantee.
SSG and Static suggested two strategies; they're one mechanism counted differently.
Server-rendered suggested HTML; most page views never produce any.
Middleware suggested a place to do work; it's a proxy that should mostly get out of the way.

The tools are honest about what they do. The vocabulary isn't — and it was mostly inherited from a version of the framework that no longer exists.

Which is a reasonable definition of what it means to actually know a system: not that you memorised the API, but that you stopped being misled by what things are called.

If this helped, or if I got something wrong — find me on LinkedIn or my site. I read everything.