Topcoat is pushing the boundary of server applications with Rust
Topcoat v0.9 introduces client signals, streaming server-rendered shards, and Toasty ORM enhancements to bring a Rails-like, batteries-included experience to Rust web development.
summary is enough The post details version 0.9 features, but the comment thread provides crucial debate on Rust's ergonomics and utility for web apps in the AI era.
summary
Topcoat 0.9 adds client-side signals, server-rendered shards, and websocket-based server push to its full-stack Rust web framework. Accompanying updates to the Toasty ORM introduce macro-driven updates, JSON document support, and polymorphic relations. Created by core Tokio contributors, Topcoat aims to deliver Rails-like productivity with Rust performance. Participants debate whether macro-heavy markup and slow compile times make Rust practical for modern web development.
key points
- Topcoat 0.9 introduces client signals and shards, enabling server-side UI components to react to browser state changes without full page reloads.
- New live and emit macros support streaming SSR and long-lived WebSocket server push connections.
- The Toasty ORM adds macro-based updates, Postgres JSONB document filtering, and enum-based polymorphic relations.
who should read it
Rust developers and web engineers interested in high-performance full-stack frameworks.
discussion positive
consensus
Most participants view the project as ambitious and well-crafted, though many question whether writing full-stack UI in macro-heavy Rust remains practical when AI agents handle multi-language stacks easily.
pushback
Critics argue that Rust's slow compile times and complex syntax make it a poor fit for rapid web iteration.
I've found that the guardrails of a strong, expressive type system are amazing for LLMs, especially if you don't use the top-of-the-line models but stick to the cheaper options. Agents need feedback to do their magic, and the type system is great for that.
But on the other hand, the compile time of Rust is really counterproductive. On large, established projects, most prompts I write now spend more time compiling on my machine than they spend outputting tokens. In a way this is great because the tokens are the expensive part, but it does mean that when faster LLMs will come, they will not …
It explains how strong type systems act as vital guardrails for cheaper LLMs, while noting that Rust compile times undermine iteration speed.
Generated by an LLM from the article and thread. Check the sources before relying on it.