Topcoat 0.9 adds server push to the Rust full-stack framework

Serguey Asael Shinder26 September 2026, 10:342 min read

Topcoat, the batteries-included web framework being built under the Tokio project, reached version 0.9 on 24 September. The release adds server push: a page can open a WebSocket to the server and subscribe to UI changes over a long-lived connection, so a chat box or a job-status panel re-renders when something happens on the server rather than when the user clicks. It is announced by Carl Lerche, who wrote Tokio and was on the Ruby on Rails core team, and who is building Topcoat with Julien Scholz leading the front-end design.

The release completes a rendering model the project has been assembling for several versions. Topcoat renders on the server by default. Small pieces of interactivity are written as runtime expressions inside the view! macro - a type-checked subset of Rust that is transpiled to JavaScript and runs in the browser, so a counter or a spinner needs no round trip. "Shards" are components the server re-renders whenever their arguments change. Since 0.8 the server can read a signal while rendering and refetch only the fragments that depend on it, morphing the returned HTML so focus and input state survive. The live! and emit! macros stream several updates from one view, which is how Topcoat implements suspense-style loading skeletons and progress indicators; 0.9 extends that from the initial load to a persistent connection.

The companion ORM, Toasty, gets an update! macro that issues a single UPDATE without loading the row first - incrementing a counter becomes one statement - plus first-class document columns mapped to JSONB on PostgreSQL, and polymorphic relations expressed as Rust enums with #[shared(id)] and #[index(id)] annotations.

What it means

Topcoat is converging on the same place as Phoenix LiveView, Hotwire and Laravel Livewire: HTML rendered on the server, a thin client, and a persistent channel for updates. What is different is that the browser-side snippets are checked by the Rust compiler rather than written as strings of JavaScript, which removes a whole class of mismatches between server and client code. The trade-off is the usual one for server-push designs - every open tab is a connection your servers hold, so capacity planning changes from requests per second to concurrent sockets.

It is a 0.x framework, and Lerche says openly that the team is still working out what it should look like. For teams already running Rust services, it is worth watching as a way to put an internal admin UI next to an existing Tokio backend without adding a separate JavaScript stack. The post's own framing - that clear conventions help AI coding tools produce working code with fewer errors - is a claim, not a measurement, and should be read as the author's rationale for building a framework at all.