What it is: server-first web app architecture with HTML rendered on the server, realtime updates over SSE, and multiplayer behavior through CQRS patterns. The goal is to keep things simple, performant, and Pythonic.
Backstory: I kept running into the same issue in internal tools. Basic HTTP screens were easy, but once realtime collaboration was needed, projects often pulled in websocket protocol handling, client-side state sync, and more frontend framework complexity than the product needed.
Stario started as an exploration of Datastar and a question: what would a Pythonic framework look like if it fully embraced that philosophy? The result was a narrower approach: keep truth on the server, stream updates over SSE, and use one handler model for the most common endpoint behaviors.
What is different in practice:
- A Go-like shape with a Pythonic twist: `async def handler(c: Context, w: Writer) -> None`
- One handler model for three common types:
- single response (`w.html`, `w.json`, etc.)
- streaming over time (`w.alive(...)` + `w.patch(...)`)
- work that continues after response (`w.empty(204)`, then continue server-side)
- Realtime without requiring WebSocket protocol code for most use cases
Try it locally (no signup, interactive setup):
``` uvx stario@latest init # interactive prompts guide project/template setup ```
Links:
- Docs: https://stario.dev
- Source: https://github.com/bobowski/stario
- Tiles walkthrough: https://stario.dev/tutorials/tiles-walkthrough