Diagrams · for everyone

Diagrams

How a request is answered

The host matches the route against the plan, evaluates the lowered loader as interpreted IR, walks the component tree and writes HTML. No JavaScript engine is started at any point.

BrowserGET /cartRust hostroute matchplan.jsonthe route treeloader IRinterpretedHTMLno JS engine

The two boxes on the right of the host are the same file. plan.json holds both the route tree and the loader bodies; they are drawn apart because they are consulted at different moments.

What a build produces

One TypeScript application, two artifacts and a strict rule about which side reads which.

app/routes, app/srcTypeScript you writeplan.jsonroutes, loader IR, component treesdist/islands, client runtime, vendorread by the Rust hostnever sent to the browserloaded by the browsernever executed on the serverlowerbundle

The plan is data. That is what makes it diffable, hashable, checkable at boot and swappable in a running process. The bundle is code, and it is the browser's alone.

How a site nests inside its shell

A mounted site's whole route subtree is grafted into a clone of the shell's root layout, in the same content slot the shell's own pages use.

shell#documentthe one documentroutes/layout.tsxnavbar, theme, footerthe shell's own pageat /the site's whole subtreedocs:routes/layout.tsx and belowone session, one navigationslot: contentgrafted into a cloneof the same slot

One document, one session, one navigation. The graft is exactly one level deep: only the shell's root layout wraps a site, never a layout deeper in the shell's tree.

The lab

These diagrams are ordinary components under app/src/diagrams/, lowered like any other and rendered by the host. There is no diagramming library in the bundle, and the browser is not asked to draw anything. View the source of this page and the SVG is already there.

Built with SnapFire FSR. Pure Rust runtime, zero Node.js on the server.