the DESIGN SPACE
ALTITUDE 5 — eleven entries placed by where matching happens and who owns navigation, shape marking the source of truth · positions are editorial, argued in the notes
GENERAL NOTES
This altitude forbids the city outright. A diagram's edges assert mechanism, and there is none between TanStack and SvelteKit. The honest form is a positioned chart whose axes are real, contested design decisions — with the positions owned as editorial judgment, not measurement.
Reading the columns: the field has been sliding left for a decade — filesystem routes and typegen move matching toward build time; server components move it toward the server. The client-runtime column is where the platform itself now competes, via the Navigation API. The server-runtime column has a platform floor of its own, drawn as one circle with two names: node:http hands a listener a request whose URL is a bare string, and the fetch handler hands one a Request and wants a Response back; neither matches anything, and Hono, Express and the lineage's connect and fetch adapters all stand on one or the other. URLPattern is the platform's matcher, in browsers and global in Node 24, and it stays off the plot: it matches a string against a pattern and owns neither a request nor navigation, so it is a part routers are built from, not a router.
The squares are the argument. Every circle on this chart treats the URL as the source of truth and derives the view from it. The ui-router lineage inverts that: a named, hierarchical state tree is primary, and the URL is a projection — one of several possible addresses for a state. That inversion is why sheet 1's loop runs through a state registry rather than a path matcher, and why the same tree answers HTTP requests in sheet 2's server lane. It is also why the squares sit alone: the niche is real, small, and — for state-heavy embedded UIs where the address bar is not the whole story — defensible.
One tree, every column — and this atlas is the measurement. The lineage is the one entry drawn in all three columns, and the bracket under its row is the sheet's one edge with a mechanism behind it. ui-router-server compiles the same state declarations into a mount table and gives each path an HTTP verdict — shell, redirect or 404 — at server runtime, in its connect, vite, fetch and hono adapters. lit-ui-router-ssr takes that mount table at build time, drives one router to every path and draws each <ui-view> to a page; its client half adopts the page one view per route match, the per-boundary, provided cell of the hydration models its guide compares. Every page of this atlas, this one included, is a verdict the server router gave and a document the prerenderer wrote at build, adopted by lit-ui-router at client runtime: the three squares are the three times one state tree matched the address you are reading.
KEY
| URL-first router | |
| state-first router (this lineage) — one square per column it matches in | |
| the lineage's span — the sheet's one edge; sheet 2 draws the mechanism | |
| editorial callout | |
| column boundary (soft) |