How
No first-class agent protocol for the UI. Agents work through Tidewave's MCP server (execute Elixir in the running dev app, read logs, query DB), through LiveViewTest in code, or by browser automation of the rendered page.
Phoenix LiveView
Server-rendered stateful UI that pushes minimal diffs over WebSockets.
phoenixframework.org ↗repo ↗docs ↗Change tracking (assigns and HEEx) ↗LiveView 1.0 announcement ↗Dashbit: latency and rendering optimizations in LiveView ↗Tidewave Phoenix (MCP for running Phoenix apps) ↗
- license
- MIT. Tidewave Phoenix MCP server is Apache-2.0 (open-source component of the commercial Tidewave product).
- language
- Elixir (server) + JavaScript client
- backing
- Phoenix core team (Chris McCord, José Valim and others); supported by companies including Dashbit and Fly.io (affiliations not re-verified here)
- stars
- 6,833 (as of 2026-10-09)
- downloads
- Hex: 46.4M all-time, 3.97M recent (90 days), 399,787 last week (hex.pm API, 2026-10-09)
- latest release
- v1.2.12, 2026-09-16
- first release
- 2019-08
borrow
Not a dependency for a Rust TUI, but its change-tracking and streams design is the best prior art for scene's high-frequency granular updates.
Borrow from it: take a specific idea, API or format.
the steelman: the best honest case for it
LiveView is the most battle-tested answer to 'a stateful server process owns the UI and pushes granular updates to a thin client at high frequency', which is precisely thc-scene's runtime shape. Its compile-time change tracking (statics once, dynamics only when their assigns change, comprehension statics once, streams for big lists) is a decade of hard-won engineering on minimizing what crosses the wire, and PubSub lets any producer fan updates into many views without the view polling. LiveViewTest shows that the same model can be driven headlessly and asserted on, and the BEAM process model gives isolation per view. With 400k weekly downloads and a stable 1.x, it is the reference for server-driven UI.
scores
| UI as data | 3 scene 5 | declarative HEEx in a host language; the wire diff format is JSON but derived, not authored |
|---|---|---|
| Agent can drive it | 2 scene 5 | only indirect: Tidewave code eval (dev only), LiveViewTest, browser automation |
| Agent can see it | 3 scene 5 | DOM/HTML readable via tools; assigns readable by code eval |
| Small, targeted edits | 3 scene 5 | fine-grained diffs exist but one-way, server to client |
| Time travel | 0 scene 0 | |
| Live data rate | 3 scene 5 | built for frequent server pushes; no published rates |
| Terminal native | 0 scene 5 | |
| Pixel graphics | 4 scene 4 | browser renders anything (SVG, canvas via hooks) |
| Teaching | 1 scene 3 | |
| Maturity | 5 scene 1 | |
| Openness | 5 scene 4 |
Phoenix LiveView scene now scene planned
how agents use it
Wiring it in
Add the tidewave dep and plug in dev; or write LiveViewTest scripts.
Seeing the result
Via the DOM (browser tools / Tidewave Web), via LiveViewTest render (HTML), or by evaluating code to inspect assigns; no structured UI tree API for agents.
Small edits
The framework itself emits granular, server-originated diffs, but an agent cannot patch the UI; it can only send events or change state/code.
History
None built in; no time travel or replay.
In short
An excellent model for how a server pushes small, frequent UI updates, but not built for agents to drive.
architecture
Each LiveView is a stateful server process holding assigns (state); events from the browser arrive as messages, handle_event/handle_info update assigns, and the HEEx template re-renders. Compile-time change tracking splits templates into static and dynamic parts: statics are sent once, and only changed dynamics are diffed and pushed as a compact JSON structure over a WebSocket; comprehensions send statics once regardless of item count, and streams send only inserted/deleted items. The JS client patches the DOM (morphdom). It is close to Elm in shape (state, messages, render) but state lives in an Erlang process, and the view is Elixir templates, not serializable data.
- Server owns state; client is a thin diff applier
- Static/dynamic split + change tracking = small payloads for high-frequency updates
- Streams and comprehensions keep large collections cheap
- PubSub lets any process push updates into many live views
- Phoenix.LiveViewTest drives a LiveView headlessly (render, element |> render_click, form submit) without a browser
- Agent tooling comes from Tidewave: project_eval in the running app, logs, SQL, docs; LiveView 1.1+ debug HEEx annotations map DOM to source
performance
Payload-minimization mechanisms are documented in detail; no official updates-per-second benchmark was found.
- Static parts are sent once; only changed dynamic parts are re-sent; comprehension statics sent once regardless of item count hexdocs.pm ↗
- Change tracking and rendering optimizations to reduce payload and latency dashbit.co ↗
adoption and upkeep
Adoption
The default UI layer for Phoenix apps and the de facto standard in the Elixir ecosystem; ~400k Hex downloads a week.
Maintainability
Mature, stable (1.0 in Dec 2024) and steadily maintained.
Releases: Every few weeks: v1.2.8 2026-07-27, v1.2.9 2026-08-10, v1.2.10 2026-08-20, v1.2.11 2026-08-27, v1.2.12 2026-09-16 (plus v1.1.33 backport) · Contributors: ~603 (GitHub contributors API with anon, last page index) · Recent: 178 commits since 2026-07-11 · Bus factor: high: core team plus large contributor base
weaknesses
- Browser only; no terminal renderer (raxol bridges a TEA module to LiveView, not the reverse)
- View is Elixir templates, not a serializable value an agent can author or push
- No agent protocol for UI operations; Tidewave covers code eval, logs and DB in development, not UI control
- No time travel or replay
- Every interaction round-trips to the server; offline/latency-sensitive interactions need JS hooks
and thc-scene
Overlap
Server-held state, messages, re-render, and pushing only what changed to the display at high frequency; data producers push into the UI without the view polling.
What scene would be reinventing
Diff minimization: scene's id-keyed patches and stream coalescing are a simpler version of LiveView's static/dynamic change tracking. If scene ever renders to remote clients (web, SSH), LiveView's diff format and streams are the prior art.
The gap it leaves
LiveView has no agent surface, no UI-as-data, no terminal output, no readback API and no time travel; scene is agent-first in the terminal.
What to borrow
- Static/dynamic split for scene templates: precompute static structure once, re-evaluate only bindings whose inputs changed
- Streams semantics (insert/delete/reset by dom id with limits) for large live lists
- PubSub-style topics for data sources so many scene views share one producer
- A LiveViewTest-like headless driver API for scene (render, element(selector) |> click, assert)
sources
- phoenixframework/phoenix_live_view github.com
- Assigns and HEEx templates: change tracking hexdocs.pm
- Phoenix LiveView 1.0.0 is here (2024-12-03) phoenixframework.org
- Dashbit: latency and rendering optimizations in Phoenix LiveView dashbit.co
- Hex package phoenix_live_view hex.pm
- tidewave-ai/tidewave_phoenix README github.com