Brust serves compiled pages with zero JavaScript by default — and gives server templates, React islands, and native interactions one shared store the moment you add it.
Brust is built like unified memory: a single state substrate every kind of component addresses directly — no bridges, no event buses, no syncing two worlds. This demo is real. The left panel is hydrated React; the right panel ships zero React. Click either side and both move, through the chip in the middle.
useStoreA hydrated React component, subscribed through useStore.
docs.unifiedzero ReactA compiled template with a small signal behavior — no React in its bundle.
0
One defineStore('docs.unified') — both sides write it, all three read it.
Everything a content site or an app shell needs ships with the framework — each piece reading the same store, typed end to end.
Pages compile ahead of time and are served as plain HTML — no hydration pass, no framework runtime in the response. JavaScript ships only where you place an island or a behavior.
84,119 requests/sec
One compiled page under load, versus 28,938 for the same page rendered through a JavaScript pipeline — about 2.9× (bench/RESULTS.md: oha, 120 connections, darwin/arm64).
Hydrate one component, not the page. React mounts only inside the island hosts you place.
Counters, toggles, live text — small signal-driven behaviors that ship no React at all.
Server functions with end-to-end types; the treaty client calls them like local code.
Drop .md files in a folder for routed pages with nav — and a fully static build. This site is one.
defineStore resolves to a single instance, so islands and native components share state with no bridge code.
Actions double as MCP tools and loaders as resources, served at /_brust/mcp.
What landed in the latest alpha — changes, fixes, and upgrade notes, straight from the repository.
Read the release notes →
Under the hood, Brust renders compiled templates in a Rust core on the Bun runtime — a detail you mostly never have to think about.