Concepts — Capstone: From Component to Pixel

Phase 7 · Spec areas §46 (complexity notebook), §47 (comparison matrix), §48 (design challenges), §50 (capstone), §51 (mastery criteria).

1. The deliverable

Build a real application using your own implementations:

your JSX/template compiler (fw-06)
   -> your component runtime (fw-02/fw-04)
   -> your reactive store (fw-01 or fw-03)
   -> your router (fw-08) + query cache (fw-09)
   -> DOM
   -> Blink -> style -> layout -> paint -> compositor -> GPU -> pixels

Instrument every layer you can observe. Then answer, in full, what happens after:

setCount(count + 1)

covering framework scheduling, state update, reconciliation or reactive effect, DOM operations, Blink invalidation, style, layout if required, paint if required, compositing if required, and frame presentation — and which stages are skipped, and why.

The application should be small and real: a list with filtering, a detail route with async data, and one animation. That is enough surface to exercise every layer and small enough to instrument honestly.

2. The three analytical artefacts

2.1 Complexity notebook (§46)

One entry per confrontation with production complexity, using the template in PROGRESS.md. Required: Fiber · Vue scheduler · HTML parser insertion modes · layout fragmentation · Mojo / multiprocess IPC · browser security boundaries · concurrent rendering · hydration · event delegation · property trees · style invalidation sets.

Each entry must classify the complexity as essential architecture, production hardening, or accretion — and defend the classification with evidence. Guessing is not classification.

2.2 Comparison matrix (§47)

Rows: mini-react · React · mini-vue · Vue · signals · Redux · Blink style invalidation. Columns: change detection · scheduling · memory · consistency · debuggability · incremental work · failure modes · extensibility · compile-time knowledge · runtime knowledge.

Never reduce to "which is faster."

2.3 Design challenges (§48)

For each: constraints, invariants, failure modes.

A. A UI framework with no virtual DOM · B. Dependency analysis at compile time · C. Canvas instead of DOM · D. Asynchronous rendering · E. SSR + hydration · F. Partial hydration · G. Offline-first state

2.5 The patterns this track keeps finding

By the capstone you should be able to name these unprompted. Each appears in both strands, which is the evidence that they are properties of the problem rather than of any one codebase.

1. Author-supplied guarantees unlock impossible optimisations

The runtime cannot derive these facts. Rather than staying conservative forever, the platform adds a way for the author to promise. When you build something that must be conservative, ask what the smallest promise would be.

2. Record cheaply, resolve precisely, once per frame

Style invalidation (bi-07), dirty layout (bi-08), paint invalidation (bi-09), reactive scheduling (fw-03), React batching (fw-04). Every one separates marking from computing.

This is what makes a system incremental, and it is why interleaving a read into a write loop is catastrophic rather than merely slow: the read forces resolution, destroying the batching the whole architecture was built around.

3. Immutability is the enabling condition for caching

Layout results (bi-08), display items and fragments (bi-09), Redux state (fw-01), Fiber's double buffer (fw-04). If a value can change under you, "is this still valid?" is unanswerable.

4. A cache key must capture every input — and incomplete keys fail silently

Constraint spaces (bi-08), paint subsequences (bi-09), computed (fw-03), bundler content hashes (fw-07), query keys (fw-09). The failure is always the same: stale output, no error.

5. Author code must never observe a half-built state

Parser construction site (bi-03), custom element reactions and MutationObserver (bi-04), commit atomicity (fw-04). All three queue or batch for this reason, and all three chose it over a simpler synchronous design that was impossible to make safe.

6. Speculation is safe only when it cannot be observed

Preload and background scanners (bi-03), compositor scrolling before the main thread answers (bi-10), discardable render work (fw-04). Wrong is acceptable; observable is not.

7. Restrictions make circular systems analysable

Container queries require containment (bi-07); percentage heights against auto resolve to auto (bi-08); ResizeObserver has a depth limit (bi-11). Each time, the specification adds a restriction rather than an iteration limit — because restrictions keep the system analysable while limits merely keep it terminating.

8. Some complexity exists because of who owns what

Two GCs, because V8 and Blink are separate projects (bi-04). Two Mojo type namespaces, because Blink uses WTF types and the browser uses STL (bi-06). Generated bindings, partly because consistency across thousands of interfaces cannot rely on humans (bi-05).

Organisational boundaries become architectural boundaries. This is the most Principal-level observation in the track, and the one most worth carrying into your own org design.

2.6 The capstone question, decomposed

"Explain what happens after setCount(count + 1)" is really eight questions. A complete answer addresses each:

1. Which framework work is scheduled, at what priority, and is it batched? (fw-04)
2. Which components re-render, and why those? (fw-02 / fw-05 — and the answer differs by architecture, which is the point)
3. Which DOM operations result? Count them. (fw-02's instrumented DOM)
4. What does that mutation invalidate? Which elements, which stages — cite css_properties.json5 (bi-07)
5. Does layout run? For which boxes, and does anything force it early? (bi-08)
6. Does paint re-record, or is this a property-tree change? (bi-09)
7. Which thread and process does each step run on, and where are the hops? (bi-02, bi-10)
8. When is the frame presented, and what could have made it late? (bi-10, bi-11)

And then the question that demonstrates mastery rather than recall:

Construct two variants of the same visible change — one that reaches the GPU having skipped style, layout and paint entirely, and one that runs every stage. Explain the difference at each of the eight layers.

If you can do that from your own instrumented application, with measurements, you have completed the track's actual objective. Everything else is instrumental to it.

3. Mastery criteria (§51)

The track is complete when you can independently:

• Draw Chromium's processes and explain the trust boundaries
• Given a browser behaviour, locate the likely subsystem and its implementation
• Explain HTML → DOM → style → layout → paint → compositing in implementation terms
• Determine whether a change triggers style, layout, paint, or compositor work
• Trace a Web API from JS through the bindings
• Set native breakpoints and follow meaningful execution
• Locate, run, and modify browser-engine tests
• Connect implementation behaviour to specifications
• Produce at least one upstream-quality Chromium/Blink change
• Have working simplified implementations of: React-like runtime, Vue-like reactive/runtime/compiler system, Redux-like store, router, query cache, signals, virtualized list, bundler/compiler
• Explain not only how these systems work, but why their complexity exists

The last criterion is the actual target. Everything else is instrumental to it.

4. Final review

1. Explain setCount(count + 1) end to end, in ten minutes, to a strong engineer who has never thought below the framework. Then do it again in ninety seconds.

2. Of everything you built, which mini-implementation taught you the most per hour? Which was least worth the time? What does that say about how to teach this to someone else?

3. Name three pieces of production complexity you now believe are not essential. Defend each with evidence, and say what you would do instead.

4. You are given a rendering performance problem in a codebase you have never seen, and two hours. Write the procedure.

5. What is the most important thing you now know that you cannot easily convince another engineer of without them doing this work themselves?