Chapter 11. The Single-Page Application
This chapter audits the single-page application (SPA). In the book’s terms its architecture is the trivial factorization of Chapter 4 (Prop. 4.2), deployed at industry scale. select and present shrink to near-identities; the application is stuffed into one term that computes all of read. Fetching, state management, templating, and styling decisions interleave in one program, delivered as one bundle.
S1. State lives at every level of the program (component state, stores, caches, props), with no factor boundary anywhere. The paradigm’s own architecture diagrams present that flow of state as a feature. ✗
S2. The term is imperative, so its meaning is defined by execution order. The failure is in principle rather than in implementation. Def. 4.3 requires each factor to denote a term in a language with closed semantics; an imperative program’s meaning is the trace of its execution. No discipline within the paradigm can repair this, because the paradigm is the choice of trace over denotation. ✗
S3. No factor can be replaced without rewriting the term as a whole. Substitutability needs a factor boundary to swap across, and S1 showed there is none. State, selection, arrangement, and presentation are one program, so changing any concern means editing that program, not substituting a term of a language. ✗
S4. No intermediate value has a URI. The data behind a rendered view cannot be addressed, cached by intermediaries, indexed, or linked. Chapter 3 showed this on the dashboard: stripping style left only the chrome, because the curves were never in the document — a script drew them as pixels on a canvas. The state never reached the application’s own document. ✗
The one-timeline consequence
Independent evolution (Prop. 4.5) states what the fusion costs. The application is one component with one timeline, so any change (data, layout, theme, query) is a change to the whole term. The term is the unit of delivery, so it is also the unit of invalidation. Four consequences follow, and each one forfeits a property that Fielding’s constraints were chosen to induce:
- caching degrades to bundle-level, which is the corollary to Prop. 4.5 and now an operating cost;
- crawling requires headless browsers, machines simulating humans in order to read what machines produced;
- reuse requires reverse-engineering a private API, the S4 cost, falling on every integrator separately;
- hydration (shipping the document and the program that regenerates it) is the S1 cost: the architecture cannot tell its document from its program, so it ships both.
The R-properties
R1 holds: a program can keep any state in memory. R2 and R3 fail together. Component state has no merge law. State-synchronization libraries are the compensating industry. And references are pointers: machine-local by definition.
The platform’s component model
One objection to the audit is that these failures belong to frameworks and that the platform is the cure, because the platform has since shipped its own component model. Web Components are the test case. A custom element gives the fused term a tag name; shadow DOM gives it a boundary the document’s own selectors cannot cross.
The tag denotes nothing until its class executes, so meaning is still the trace (S2). The element’s state lives in the class, threaded as before (S1). The shadow tree is an interior hidden by design: no URI reaches it, and now no selector either (S4). And no factor boundary appeared, so substitution still means rewriting the class (S3). The standard draws its boundary around the fused program, not through it: shadow DOM encloses the whole term, while properness needs it cut into select, arrange, and present. A component boundary is not a factor boundary. Moving the component model from framework to platform changes no score. Chapter 1 filed the framework as an implementation detail, and this is the confirming experiment.
What shadow DOM does standardize is encapsulation: state hidden behind a boundary on purpose. Chapter 13 audits the paradigm that encapsulation belongs to, and that paradigm is not the web’s.
The corollary: the SPA is the un-web — HTTP reduced to a pipe delivering a program whose interior satisfies none of the properties that define the web. The corollary claims nothing beyond the column. Rejecting it means rejecting one of the scores, and each score names the property an objection would have to argue against. A prediction follows: the paradigm caps structurally at Web 2.0, because Web 3.0 means machine-consumable state (the definition Chapter 21 makes exact), and the paradigm is defined by hiding state behind read. Chapter 14 measures the industry’s own retreat from the paradigm; Chapter 23 records the machine consumers that appeared in the meantime.
SPA/JS
| SPA/JS | |
|---|---|
| R1 | ✓ — any state, in memory |
| R2 | ✗ — no merge; synchronization is bespoke |
| R3 | ✗ — references are machine-local pointers |
| S1 | ✗ — state threaded through one term |
| S2 | ✗ — meaning is execution order, in principle |
| S3 | ✗ — substituting a factor means rewriting the term |
| S4 | ✗ — no intermediate value has a URI |
The column restates the corollary, cell by cell.