Broader Ideas
The perspective method generalises beyond this module
The technique that makes this module useful is not about shapes at all:
Convert the ratio to an absolute per-operation cost. Multiply by the real operation count. Compare against the other items on the same critical path, in the same units.
It applies to every optimisation debate you will arbitrate:
| Claim | Ratio offered | What to ask |
|---|---|---|
| "This library is 3× faster" | 3× | at what absolute cost, for how many calls, versus what else on the path? |
| "Server components cut bundle size 40%" | 40% | how many ms of parse/execute, on which device, at what percentile? |
| "This cache gives 90% hit rate" | 90% | what is the absolute latency saved, and what is the invalidation risk? |
| "Migrating to X reduces re-renders 60%" | 60% | how many ms per interaction, against a 200 ms INP budget? |
A Principal Engineer's leverage here is mostly refusal — killing work that cannot pay for itself, in a way the proposer can verify rather than merely accept. The arithmetic is the artefact that makes the refusal collaborative instead of political.
Where shape stability becomes a real design input
Three places in this curriculum where the findings should actually change a decision:
Virtualized lists (fe-30). A row renderer running over 10M cells multiplies per-element cost by
enough to matter. This is also where element kinds stop being trivia: a numeric column that
acquires one null transitions storage for the whole array, one-way.
Worker boundaries (fe-28). Structured clone cost depends on representation. Shape-stable, homogeneous, transferable-friendly data is the actual optimisation at a worker boundary — fe-01 measured a 376× difference between a naive and a resident worker, which dwarfs anything here, but representation is what makes transferables possible at all.
State-store internals (fe-16). A store allocating a new object per update, read at thousands of sites, is exactly the hot-library-internals case. This is why store implementations care about shapes and application code does not.
Data representation as a two-way-door decision
Array-of-objects vs object-of-arrays is usually framed as ergonomics. It is also a shape decision, and unusually it is a reversible one — which by fe-47's framing means it should be decided fast and cheaply, not deliberated:
// AoS — natural to write, one shape per row, fine at any realistic UI scale
const rows = [{ id, name, value }, ...];
// SoA — homogeneous typed arrays, no per-row objects; only pays at extreme scale
const ids = new Int32Array(n), values = new Float64Array(n);
const names = new Array(n);
Adopt AoS by default. Move to SoA when profiling says the per-row objects are the cost, which for frontend workloads means canvas, WebGL, or 10⁶-scale data. Doing it preemptively costs ergonomics permanently to buy nanoseconds you have not shown you need.
Why this module is short and mostly negative
The specification asks for depth on 46 areas. It does not ask for equal depth. Part of Principal judgment is allocating attention proportionally to leverage, and doing that visibly so others can calibrate too.
This module is the curriculum's worked example of deliberately bounded depth: enough to make correct decisions, enough to refuse incorrect ones, and an explicit statement of where the boundary is and why. A curriculum that treated JIT internals with the same weight as accessibility or rendering architecture would be teaching a distorted model of the job.
The one unexplained result here (PACKED_DOUBLE faster than PACKED_SMI) is left unexplained on
purpose, with the reasoning recorded. Knowing when to stop investigating is the same skill as
knowing when to stop optimising, and it is worth practising somewhere the stakes are 0.6 ns.