Part 9 · 2 chapters · ~15 min
The Libraries They Wrote and Why
React, Relay, Flow, Jest, Recoil, Hermes, Fresco and Lexical read as answers to problems at scale, with dates, costs and what became of each, and the course in one table: the machine, the human process it replaced, the signal you need it, and the idea that transfers at any scale.
19
The libraries, by the problem each answered
read them as answers
- React (2013): UI code whose state transitions nobody could reason about. The answer: UI as a function of state, re-render on change, a reconciler computes the DOM update (the React course). The cost: a model to learn and a decade of making re-render-everything fast (fiber, concurrent rendering, the compiler).
- Relay and GraphQL (2015): data fetching that could not be composed across thousands of components on one graph. The answer: fragments, a compiler, a masked normalised store (part 3). The cost: a schema team and a discipline; GraphQL travelled widely, Relay less, because the discipline is the hard part.
- Flow (2014) and TypeScript (2012): a JavaScript codebase too large to refactor safely. Flow: gradual, inference-heavy, a server for millions of lines in one monorepo. TypeScript: a language extension and tooling for everyone. TypeScript won the ecosystem; Flow remains right for the codebase it was built for. A tool built for one scale can lose to one built for all scales and still be correct at home.
- Jest (2014): a suite too slow, with tests interfering through shared module state. The answer: parallel workers with per-file module isolation, snapshots, module-graph mocking, affected-only watch. Vitest later reused the API on a faster engine: the usual fate of a successful answer.
- Recoil (2020): state that re-rendered whole trees and recomputed derived values. The answer: atoms and selectors with per-atom subscriptions (the React course part 7's state kinds as a library). Archived; Jotai and Zustand carry the ideas; the React compiler is the team's own answer. The problem outlived the library.
- Hermes (2019), Fresco (2015), Lexical (2022): a JavaScript engine that started too slowly on low-end phones (ahead-of-time bytecode, a small heap, no JIT: the JS course's engine trade-offs made for phones); Android image loading that exhausted the Java heap (decode into native memory, a pipeline with caches: the FSD course M3's decode budget as a library); a rich-text editor that had become unmaintainable (an immutable editor state, plugins, accessibility first: the FSD course M5's editor model). Platform-specific answers to scale-specific pain.
THE LIBRARIES, BY THE PROBLEM EACH ANSWERED
a timeline of what broke at scale and what was built in response
swipe the figure sideways, or tap expand for full screen
1/6
React
2013, React: the problem was UI code whose state transitions nobody could reason about; two-way binding and manual DOM updates produced bugs that depended on the order things happened. The answer: describe the UI as a function of state, re-render on every change, and let a reconciler compute the DOM update (the React course part 1). The cost: a rendering model everyone had to learn, and a decade of performance work (fiber, concurrent rendering) to make re-render-everything fast enough.
20
The course, in one table
| the machine | the human process it replaced | the signal you need it | the transferable idea | part |
|---|---|---|---|---|
| Four team kinds with ratios | Everyone does everything | Three date pickers; slow builds for all | Someone owns the platform; someone owns the build | 0 |
| Hermetic builds, merge queue | Dependencies by convention; a trunk fixed by hand | Passes here, fails there; a red trunk for hours | Declared deps; affected-only CI; a queue | 1 |
| An internal framework | Patterns enforced by review | Three routers, four fetch patterns | One way per concern, enforced by lint | 2 |
| Relay, data masking | Over-fetching caught by reviewers | Fields nobody dares remove | Colocated data needs; generated types; no arbitrary queries | 3 |
| Codemods and bots | Upgrades by request | A rename takes a year | Compatibility, a codemod, a count, a date | 4 |
| The experiment platform, holdouts | A spreadsheet of experiments | Collisions; metrics chosen after | Pre-register, check SRM, declare guardrails, someone else decides | 5 |
| Budgets in CI, release trains | Performance by attention; deploy when ready | Gradual growth; every deploy a release | A budget with a ratchet; a cadence with gates and switches | 6 |
| OWNERS, readability, lint as policy | Review by whoever is around | Latency climbing; style debated per PR | Small changes; a written bar; repeated comments become rules | 7 |
| Versioned client alerts, runbooks | Users report breakage | Detection by user report; unactionable pages | Version on every metric; levers with reach; blameless reviews | 8 |
| The libraries | (each a problem at scale) | The same problem, measured | Read a library as an answer; adopt the idea, weigh the machinery | 9 |
what to keep
- Machinery is a fossil of a process that stopped scaling. Measure the process before buying the machine.
- The ideas transfer at any scale; the machinery transfers only past the point. A team of thirty can run most of this course with ordinary tools and the discipline.
- Ownership is the thread: OWNERS decides who approves, who is paged, who the bots ask, and whose budget it is. Write it down.
- The libraries are answers; ask what question yours is asking before adopting one.
the exercise, for the course
Fill in the table for your organisation: for each row, is the human process failing measurably, and what would the signal be? The rows where it is failing are the machinery to build or adopt, in order of the signal's severity; the rows where it is not are the fossils to avoid.