Concepts — The Frontend Principal Journey

1. What is it

A structured progression from platform fundamentals to Principal/Distinguished-level frontend and web-platform engineering, driven by frontend-principal-engineering.md (the specification). The specification lists 46 subject areas plus failure case studies, capstones, and heuristics. This module converts that list into an executable order: which subjects gate which, what can run in parallel, and what "done" means at each stage.

The unit of work is a numbered module directory (fe-NN-topic/) containing concepts, runnable source, step-by-step labs, verification checkpoints, and analysis. A module is complete when its verification checkpoints pass against measured output, not when its prose has been read.

2. Why it matters

Studied in specification order, the 46 areas look like 46 independent subjects. They are not, and treating them as independent produces three specific, expensive failures:

• Optimising symptoms. Performance engineering (§11) attempted before the execution model (§1) and rendering pipeline (§2) produces work that moves numbers without moving experience. The engineer cannot distinguish input delay from processing from presentation, so one fix gets applied to three different problems.
• Cargo-culted architecture. Microfrontends (§30) attempted before build tooling (§28), monorepos (§29), and design systems (§26) yields a distributed system built to solve a problem the organisation does not have. The specification asks the right question — "is this solving an organizational problem or a technical problem?" — and it is unanswerable without the prerequisites.
• Compliant, unusable accessibility. Accessibility (§12) attempted before semantic HTML (§3) produces ARIA-first interfaces that pass automated checks and fail real users.

The ordering is the deliverable. Anyone can enumerate topics; sequencing them against real dependencies is what makes the curriculum executable.

3. How it works

SPECIFICATION (46 areas, flat list)
  |
  v
+------------------------------------------------------------------+
|  CLUSTERING — 46 areas collapse into 8 groups by dependency       |
|                                                                   |
|   A Platform substrate     §1,2,3,4,10      <- root, gates all    |
|   B Framework mechanics    §5,6,40          <- needs A            |
|   C Architecture & data    §7,8,9,19,31     <- needs A+B          |
|   D Quality attributes     §11,12,13,36-39,41                     |
|   E Quality engineering    §14-18,25        <- needs a real system|
|   F AI-assisted eng.       §20-24           <- SPINE, not a phase |
|   G Platform & delivery    §26-30,32-35     <- needs C+D+E        |
|   H Principal judgment     §42-46           <- needs lived A-G    |
+------------------------------------------------------------------+
  |
  v
+------------------------------------------------------------------+
|  FIVE LOAD-BEARING CHAINS (see docs/curriculum-map.md)            |
|                                                                   |
|   1. Scheduling      event loop -> INP -> concurrent -> streaming |
|   2. Async correctness  promises -> races -> optimistic/rollback  |
|   3. Cache coherence    HTTP -> CDN -> ISR -> query invalidation  |
|   4. Semantics       DOM -> a11y tree -> design-system contract   |
|   5. Org topology    boundaries -> monorepo -> MFE -> governance  |
+------------------------------------------------------------------+
  |
  v
+------------------------------------------------------------------+
|  7 PHASES + CONTINUOUS AI SPINE                                   |
|                                                                   |
|   Phase 1  Platform substrate      fe-01 .. fe-08   Foundation    |
|   Phase 2  Framework mechanics     fe-09 .. fe-14   Senior        |
|   Phase 3  Architecture & data     fe-15 .. fe-21   Senior/Staff  |
|   Phase 4  Quality attributes      fe-22 .. fe-30   Staff         |
|   Phase 5  Quality engineering     fe-31 .. fe-37   Staff         |
|   Phase 6  Platform & delivery     fe-38 .. fe-45   Staff/Princ.  |
|   Phase 7  Principal judgment      fe-46 .. fe-51   Principal+    |
|                                                                   |
|   Each phase boundary = a promotion gate, not a checkbox          |
+------------------------------------------------------------------+
  |
  v
PER-MODULE LOOP (non-negotiable)
  Understand -> Predict -> Implement -> Break -> Debug -> Measure -> Compare -> Explain

The loop matters more than the content. A module read without the Predict and Break steps produces recognition, not capability — you will recognise the concept in a code review and be unable to derive its consequences under pressure.

4. Core terminology

5. Mental models

A dependency graph, not a syllabus. A syllabus is ordered by convenience; a dependency graph is ordered by necessity. When tempted to reorder, the test is not "does this interest me now" but "can I make an honest claim in this module without the prerequisite?" Microfrontends before build tooling fails that test; TypeScript alongside almost anything passes it.

Depth is earned per phase, not per topic. Every phase touches performance, accessibility, and testing — at the depth that phase can support. Accessibility in Phase 1 is semantic HTML; accessibility in Phase 4 is an engineering discipline with automation limits; accessibility in Phase 6 is a design-system contract with a CI gate. Same subject, three different competences.

The curriculum is a strangler migration of your own mental model. You already have working models for most of these subjects. The programme's job is incremental replacement — find where the existing model produces a wrong prediction, replace that piece, keep the rest running. This is why every module opens with prediction: a prediction you get right needs no replacement, and a prediction you get wrong localises the defect precisely.

Tutorial density falls as phases rise. The specification requires this explicitly: later phases must "increasingly resemble actual Principal Engineer work." Phase 1 has expected output blocks; Phase 7 has ambiguous situations, competing stakeholders, and no answer key.

6. Common misconceptions

1. "Finishing the modules completes a phase." False. Phases end at promotion gates, which are capabilities demonstrated on unfamiliar input. Completing every Phase-1 module while still unable to predict execution order of code you have not seen means Phase 1 is not complete.

2. "The AI content is a phase to get to." False, and this is the most common structural error. §20–24 are a spine applied from Phase 1. Deferring them means practising the workflows only after your judgment is good enough to not need practice.

3. "Parallel means simultaneous." Parallel-safe modules have no dependency edge between them; it does not follow that studying six at once is effective. Parallelism exists to remove false ordering constraints, not to license context-switching.

4. "The internals track must come first to understand the platform." False. The two tracks are siblings, not stages. Cross into browser-framework-internals.md when a frontend topic stalls without it — the hooks are enumerated in docs/curriculum-map.md §2 — and not on principle.

5. "Measured numbers are the point." False, and dangerous. Numbers are evidence for a claim; the claim is the deliverable. A module that produces a benchmark table without a stated conclusion, an explicit limit of what the numbers prove, and a decision that changed as a result, has produced decoration.

7. Interview talking points

• "I sequence frontend curricula by dependency, not by topic popularity. Performance engineering before the execution model produces engineers who can move a metric but can't tell input delay from presentation delay — that's three different fixes behind one number."
• "The question I ask about microfrontends is the specification's: is this an organisational problem or a technical one? If teams can't deploy independently for organisational reasons, Module Federation won't fix it and will add a distributed system to the list of things that can break."
• "I treat AI-assisted engineering as a cross-cutting practice, not a topic. The rule I hold is that an agent may produce anything whose failure modes I can enumerate myself — otherwise I'm outsourcing judgment, not leverage."
• "Promotion gates in my teams are capability demonstrations on unfamiliar input, not checklists — the difference between recognising a concept and deriving its consequences under pressure is exactly the Senior/Staff boundary."

8. Connections to other modules

• fe-01-execution-model-scheduling — the root of the scheduling chain; gates fe-11 (perf), fe-12 (concurrent rendering), fe-16/17 (server state and races), fe-21 (rendering architectures).
• browser-framework-internals.md — the sibling track. Cross-track hooks are enumerated in docs/curriculum-map.md §2. That track's own tracker is the repository-root PROGRESS.md; the two never claim progress on each other.
• docs/curriculum-map.md — the full map: dependency graph, all seven phases, parallelisation table, hard prerequisites, failure case-study schedule, and promotion gates.
• docs/progress.md — live status across all 51 modules and 12 case studies.
• docs/learning-log.md — continuity: struggles, open questions, source readings, verification log, and the heuristics-under-test table the specification requires.