Frontend Principal Engineering — Measured

"When advice is repeated confidently and cheaply, measure it before you design around it." — heuristic earned in Phase 1 of this curriculum

A lab-based curriculum for becoming the frontend subject-matter expert for a large engineering organisation. Every claim in it is measured in a real browser, and every measurement is reproducible with one command.

What makes this different

Most frontend curricula are prose. This one is a measurement harness with prose attached.

Twenty-two experiments drive Chrome for Testing 149 over the Chrome DevTools Protocol — forcing garbage collection, parsing heap snapshots, dumping the real accessibility tree, sampling the renderer's own style and layout accounting, and dispatching trusted keyboard input. Every table in every chapter came out of a script in that module's src/, and npm run all regenerates it.

That constraint produced results that contradict widely-repeated advice:

Common belief	Measured
Chunking work with `await` keeps the page responsive	0 frames rendered over 400 ms; 49 for task-based chunking
Moving work to a Web Worker makes it faster	The naive worker was the worst of seven strategies — worse than doing nothing
A closure only retains what it references	An unused, never-called sibling retained 38 MB vs 0.01 MB
`performance.memory` will show you a leak	Freeing 508 KB of detached DOM moved the JS heap 0.10 MB
Semantic HTML is verbose	Div soup was 1.38× larger — with zero landmarks, headings or controls
Property order is the hidden-class hazard	1.14×. `delete` is 11.9×
Flex and grid are slow; absolute is fast	1.4× across six modes, and absolute was slowest
Large DOM is inherently slow	Identical 261,011-node DOM: 401.9 ms → 7.9 ms with one CSS declaration

Each of those had a real effect somewhere, misremembered as a general rule. Learning to tell the difference is the actual curriculum.

The loop

Every module runs the same sequence, and the order is not negotiable:

Understand → Predict → Implement → Break → Debug → Measure → Compare → Explain

Predict is the load-bearing step. A prediction you get right needs no correction; a prediction you get wrong localises the defect in your model precisely. Every step file opens with a prediction you are asked to commit to in writing before running anything.

Measurement honesty

Three practices are enforced throughout, because performance work fails quietly:

Harness bugs are documented, not fixed silently. Every module hit at least one, and all produced clean, plausible, wrong data — a reused JavaScript realm that voided 39 of 40 trials, INP computed per-event instead of per-interaction, a shared page letting one variant's leak contaminate the next, shared inline-cache state that reported doubles as 4× faster than integers. They live in each module's docs/measured-results.md under "harness failure modes", because the reflex they teach outlasts any individual number.

Unexplained results stay unexplained. One measurement in fe-03 reproduced, had its leading hypothesis tested and rejected, and was then abandoned because the effect is 0.6 nanoseconds. It is recorded as an open question, not dressed up as a finding. Knowing when to stop investigating is the same judgement as knowing when to stop optimising.

Every module states what its numbers do not prove. One machine, one browser version, synthetic content, no network. The ratios transfer; the milliseconds do not.

How to use this book

Read Toolchain Setup — Node 18+ and a Chrome binary is the whole dependency list.
Read the Curriculum Map for the dependency graph and why the ordering is what it is.
Start at fe-01. Each module is self-contained:

fe-NN-<name>/
├── CONCEPTS.md          # the "why" and the mental model — read first
├── references.md        # specifications first; excluded sources named and justified
├── docs/
│   ├── measured-results.md  # every number, with the browser version
│   ├── analysis.md          # trade-offs, decision rules, what breaks at scale
│   ├── execution.md         # tool versions, quick start, method notes
│   ├── verification.md      # pass/fail checkpoints with expected output
│   ├── observation.md       # how to read the evidence, and its limits
│   └── broader-ideas.md     # where the mechanism reappears later
├── steps/               # predict → run → expected output → what just happened
└── src/                 # the experiments. `npm install && npm run all`

Do the Principal Engineer Review at the end of each module in writing. Several questions are about refusing work with arithmetic, which is most of the practical value.

Three tracks

Track	Prefix	Modules	Focus
Frontend Principal Engineering	`fe-NN`	6 built of 51	judgment, architecture, measured trade-offs
Browser Internals	`bi-NN`	17	Chromium, Blink, V8 — source to pixels
Framework Internals	`fw-NN`	12	build a React, signals, bundler, router, query cache

Siblings, not stages. The frontend track develops judgment; the internals tracks remove abstraction boundaries. The measured-evidence discipline described above is fully applied to the fe- track so far; the bi- and fw- tracks share the structure and are at an earlier stage of that treatment.

Source of truth

This book is derived from two specification files, which remain authoritative:

Frontend Principal Engineering — the 46-area curriculum spec
Browser & Framework Internals (sibling project: ../browser-framework-internals/) — the sibling depth track

Where the book and the specifications disagree, the specifications win.