Build reactive web-component UIs configured in Python, executed in the browser.
You author a UI as a tree of typed Python components — WebAwesome by default, or any library that ships a Custom Elements Manifest. You attach behavior as declarative data: an action DSL (toggle a prop, send a model edit, call an endpoint) and reactive bindings (a control two-way-bound to a state field, or a prop computed from others). spaday's JavaScript runtime renders the tree to real web components and interprets that behavior client-side — so a toggle or a derived value updates with no round-trip to Python.
That UI state is a transports model, so it syncs over any connection (WebSocket, SSE, Jupyter comm) and any codec; the same tree drops into a web app or a Jupyter notebook unchanged.
Like transports, spaday is a Rust core with thin bindings: the component tree, the diff engine, the CEM parser, the action interpreter, and the reactive engine live in Rust and compile to PyO3 (Python authors the tree) and wasm (the browser runs it). One core, two bindings.
from spaday import Widget
from spaday.components.webawesome import WaCard, WaSwitch
# a switch two-way-bound to a state field, rendered in a Jupyter cell
ui = WaCard().child(WaSwitch().text("Lamp").bind("checked", "on", mode="two-way"))
w = Widget(ui, state={"on": True})
w # flip the switch → w.state["on"] flips in Python; set w.state → the switch followspip install spaday # core: author + serialize component trees
pip install "spaday[widget]" # + the Jupyter / anywidget host- Tutorial — build your first interactive UI, step by step (in a notebook).
- How-to guides — author a component tree, add behavior and reactivity, use it in a notebook, sync to a server over transports, wrap an imperative JS library, generate typed classes from a manifest.
- API reference — the Python surface.
- How spaday works — the architecture and the reasoning behind it.