How a page gets served
Your routes, loaders, actions and pages are read at build time and lowered into a plan. At request time Rust walks that plan: no JavaScript engine, nothing to warm up. A render is roughly 130µs, an island can live entirely in the host, and a bearer token never enters your TypeScript.
An island with no client code
The widget below ships no React to your browser. Every click is a round trip to the Rust host, which answers with a patch.
Rendered in Rust
A page is an IR the host walks, so a render is roughly 130µs and a cold process is as fast as a warm one. There is no engine in the path to warm up.
Many sites, one product
A separate application mounts at a prefix inside another and inherits its layout, session and store. One document, one React, one hydration pass. No iframe and no module federation.
One binary, one directory
A deploy is a Rust binary beside the files it reads. Nothing to install on the box, and no node_modules: third-party libraries are committed vendor trees resolved by a browser import map.
Tokens your code cannot read
Bearer credentials live in the host and are attached to a call as it leaves. Application TypeScript never holds one, so it cannot log one or send it somewhere else.
What the compiler makes of it
Real sources on the left, the IR the lowerer produced on the right, regenerated on every build. The last tab is a body it refuses, and the reason it gives.
import type { Ctx } from "@snapfire/fsr";
export async function load({ session }: Ctx) {
const count = Object.values(session.cart).reduce((n, q) => n + q, 0n);
return { count };
}(let count (reduce (values (session cart)) 0 (fn (n q) (+ n q))))