Litro
Built on web components
One framework
One app serves your pages, your agents, and any MCP host. A
tool returns a real component — rendered per call, from the
code your pages already use. One return ui(), no
second frontend.
pnpm create @beatzball/litro my-app
A tool call comes back as a component.
One return value, two audiences. This is generative UI, rendered on the server: Litro agents run on the same server as your pages, so a tool can render a real component and hand it back. What Litro does not do yet is written down.
export default defineTool({
description: 'Get the weather for a city.',
input: citySchema,
async execute({ city }) {
const data = {
city,
tempC: 21,
summary: 'sunny',
};
return ui(
html`<weather-card
.city=${city}
.tempC=${data.tempC}
.summary=${data.summary}
></weather-card>`,
{ data },
);
},
});{
"city": "Lisbon",
"tempC": 21,
"summary": "sunny"
}
Lisbon
70°F
sunny
The web platform, with a server attached.
Standard custom elements on the front, Nitro on the back, and a build that stays out of the way. Nothing here is a Litro invention you would have to unlearn somewhere else.
Custom Elements, Shadow DOM and slots are W3C specifications native to every major browser — the same layer as video, CSS Grid and Fetch. Pick Lit or FAST on top; the components underneath work anywhere the browser does, and each adapter streams the fastest first paint it can — Declarative Shadow DOM or light-DOM SSR.
The same server engine that powers Nuxt. API routes, middleware and every Nitro deployment target, with no Litro adapter in between — and Vite underneath for the client bundle and hot reload.
Same routing, same data layer, same deployment. Choose the component model and change nothing else.
Faster to build, smaller to ship.
The same minimal site, built in each framework on the same machine. Median of three runs.
- Litro
- 954msbuild 37 KBoutput
- Nuxt
- 1.8sbuild 202 KBoutput
- Next.js
- 2.9sbuild 620 KBoutput
Measured September 24, 2026. Every run, and the ones Litro does not win.
Start from a recipe.
Four starting points. Screenshots of real Litro sites show each shape.
A product landing page in front of a starlight docs site. This page is one. Read the recipe
A documentation site with a sidebar, a table of contents and search. Read the recipe
A server-rendered app with API routes and a client router. Read the recipe
A Markdown blog on the content layer, with tags and feeds. Read the recipe
Deploy anywhere
The server is Nitro, so every target Nitro supports is a target Litro supports — with no adapter of our own in between. Build for one with a single preset, or prerender the whole site and put it on a CDN.
Node and static are the two this project builds and tests on every commit. Everything else is Nitro's own preset, unchanged and untried by us — what Litro does not do yet names them.
Get running
-
Create a project
The scaffolding CLI asks for a recipe, a rendering mode and a framework adapter, then writes the project.
-
Start the dev server
pnpm install, then pnpm dev. The server starts on port 3000 and increments if that port is taken.
-
Build for production
pnpm build writes the Vite client bundle, and either a Nitro server or a fully prerendered static site.
These three commands give you a web app. Wiring an agent is still by hand today — the steps are in the agents guide, and what Litro does not do yet lists the rest.
$ pnpm create @beatzball/litro my-app $ cd my-app && pnpm install $ pnpm dev litro dev http://localhost:3000
Start with one command.
pnpm create @beatzball/litro my-app