How Bretzel compares

Several Python frameworks build web interfaces without a separate JavaScript application. They differ on one question above all: where the interface's state lives, and how the browser follows it. This page states each choice, taken from each project's own documentation, so you can pick the one that fits. Bretzel is the youngest of them.

At a glance

Framework	Where the interface lives	Browser ↔ server	JavaScript build	Components in the box
Bretzel	Typed state classes on the server; the regions that read a state are re-rendered as HTML when it changes	Plain HTTP for actions; a one-way SSE stream pushes changes to other windows; HTMX + idiomorph swap the fragments	None for the app author (Tailwind v4 is compiled by a standalone binary)	100+ ui.* components, charts included
NiceGUI	A tree of UI element objects kept on the server for each client	WebSocket	None for the user; Vue and Quasar run in the browser	Yes, Quasar-based
Reflex	State classes on the server; the frontend is compiled to a Next.js (React) single-page app	WebSocket, one client token per tab	Yes: Reflex compiles and builds the Next.js frontend for you	50+, many based on Radix UI; React components can be wrapped
FastHTML	Python functions returning HTML (FT components); state is yours to organise	HTTP with HTMX; WebSockets available	None	None built in
Streamlit	The script reruns from top to bottom on each interaction; st.session_state keeps values between reruns	WebSocket, one session per tab	None	Yes, widgets

Which one, when

Bretzel or NiceGUI

Choose NiceGUI when you want a proven toolkit with a large community and component set, and you like manipulating UI element objects directly.

Choose Bretzel when you would rather declare typed state and let the regions that read it re-render, keep a plain-HTTP application with a one-way stream for pushed updates, and have several windows follow the same change.

Bretzel or Reflex

Choose Reflex when you want the React ecosystem: wrapping existing React components and a frontend that runs as a client-side app.

Choose Bretzel when you would rather not build or operate a Next.js frontend, and want the server to render HTML fragments directly from your Python state.

Bretzel or FastHTML

Choose FastHTML when you want to stay close to HTML and HTMX, with little abstraction, and assemble your own pieces.

Choose Bretzel when you want the application model on top: state scopes (page, session, user, app), dependency-driven regions, multi-window broadcast, forms, authentication doors and integrated components.

Bretzel or Streamlit

Choose Streamlit when rerunning a script is the right mental model — data exploration, quick dashboards — and you value its very large ecosystem.

Choose Bretzel when the app outgrows reruns: explicit state lifetimes, targeted updates instead of a full rerun, navigation, several users on the same data, and interactions the server arbitrates.

Where Bretzel is not the right pick today

It is an alpha: APIs can change between alpha releases, and only the latest alpha receives fixes.

It has one maintainer and a young community — fewer answers already written on the web than for the projects above.

No ORM: bring SQLAlchemy, Tortoise or asyncpg.

No WebSocket: actions are HTTP requests and pushed updates use SSE.

Python 3.12 or newer.

See it for yourself

Open the live Kanban in two windows of the same browser: drag a card in one, the other follows — one Python app, no JavaScript written.

Open the live Kanban Start in 5 minutes

Sources, read on 3 October 2026:NiceGUI — configuration & deployment Reflex — introduction Reflex — architecture FastHTML — documentation Streamlit — client-server architecture Streamlit — Session StateSomething wrong or out of date about another project? Open an issue on GitHub and it will be corrected.