The Stario way
This page is a set of recommendations and rules of thumb for using Stario—not hard laws. It is the direction Stario wants to push you in, and it is influenced by The Tao of Datastar, because Datastar shaped a lot of how Stario thinks about UI, state, and realtime.
If you're not learning, it's the wrong way
Stario is about making you a better developer, not better at Stario trivia.
It is thin on purpose. It tries to arm you with durable ideas such as HTTP request handling, routing, telemetry, shared clients from bootstrap (how-to), compression, and Relay-style command/query coordination—not textbook CQRS with separate read models unless your product needs that.
The goal is not to trap you inside Stario. The goal is to help you understand the shape of the work well enough to build with Stario today, choose something else when it fits better, or even know when to ditch Python altogether.
If an abstraction stops you learning what is happening, it is probably the wrong abstraction.
Lean on the browser
The browser is already a jet engine. It is up to you whether you use it well or fight it.
Lean on the tools that already exist or are amazingly cheap: DOM morphing, signals, compression, links, browser history.
The fastest JavaScript is no JavaScript. Use Datastar to keep the client layer thin. Do not rebuild things the browser already does well, especially navigation and history.
Think multi-page application
Borrowing from Datastar's Tao:
build an MPA
each page is a resource
keep a stream open on the current state of that resource
ship, measure, repeat
In Stario terms: handlers return full documents where that fits, open SSE (or other streams) for live updates, and keep authoritative state on the server; signals hold UI-facing mirrors only. You do not need to read the Tao link first—those pieces are all documented here and in The go-to architecture.
The inefficiency of this approach is mostly in your head. Compression and CSS view transitions can make navigation feel responsive for many users, while staying simpler to scale and maintain than a full client-rendered SPA—your mileage depends on page weight and browser support. Where an MPA is a poor fit (heavy client-only interaction, offline-first), measure and choose a different shape deliberately.
State lives on the backend
Most state should live on the backend.
The frontend is exposed to the user, so the backend should be the source of truth.
Signals are useful, but they are not your system of record. Use them for UI state, request payloads, and light reactive behavior. Keep real application state on the backend.
Where next
Handlers, context, and the writer —
Context,Writer, and the request path.The go-to architecture — SSE, Datastar, and Relay in one loop.
Realtime tiles — end-to-end tutorial.
Telemetry — spans and tracers.