When the Tokio team announced Topcoat on July 22, 2026, they weren't just adding another entry to the crowded list of web frameworks. They were making an argument. The argument is that Rust, a language most people still associate with systems programming, operating systems, and the kind of software where a memory bug can cost real money, is ready to become a genuinely pleasant place to build ordinary web applications. Topcoat, created by Carl Lerche and Julien Scholz, is the framework meant to prove it.
That claim deserves some scrutiny, because for most of Rust's life it would have sounded absurd. Web applications are rarely bottlenecked by the speed of the language they're written in. What matters far more is how quickly a team can ship a feature, fix a bug, or onboard a new hire. This is precisely whoy the richest web ecosystems grew up around languages built for developer velocity rather than raw performance: JavaScript, Ruby, and PHP. If you had pitched a serious Rust web framework a few years ago, the fair response would have been to ask why anyone would trade all that productivity for speed they didn't need.
Topcoat's answer, and the reason its authors think the timing is finally right, has less to do with Rust and more to do with how software gets written now. AI coding assistants have flattened much of the learning curve that used to separate languages. When a capable model can help you navigate an unfamiliar borrow checker or scaffold a component you've never written before, the practical cost of "not already knowing the language" drops sharply. What starts to matter instead is whether the language has the libraries you need. The bottleneck moves from expertise to ecosystem. And for organizations that already run Rust in production for the parts that genuinely require its speed and reliability, the pull to keep the rest of their stack in the same language, using the same build tooling, the same libraries, and the same review processes, becomes hard to resist. Consolidating on one language is itself a productivity win.
So the real project isn't convincing anyone that Rust is fast. It's filling in the missing pieces that make Rust a viable choice for higher-level work. Topcoat is one of those pieces, and it follows an earlier one: Toasty, an async ORM the team shipped in the spring of 2026. An ORM is arguably the hardest and least glamorous foundation to get right, which is why they built it first. With data access handled, a web framework is the natural next layer.
## The interesting bet: reactivity without WebAssembly
The most interesting technical decision in Topcoat is what it chooses not to do. Frameworks like Leptos and Dioxus deliver rich interactivity by compiling your Rust to WebAssembly and running it in the browser, which is powerful but comes with real costs: you have to think about bundle sizes, code splitting, and serializing data back and forth across the client-server boundary. Topcoat takes the opposite bet. Everything is rendered on the server. Because components run on the server, they can be async, talk directly to the database, and check a user's permissions inline, with none of the ceremony that a client-side runtime demands.
Interactivity doesn't disappear, though; it's layered back in more ch eaply. Rather than shipping a WebAssembly runtime, Topcoat uses a macro that cross-compiles a type-checked subset of Rust directly into JavaScript. That means you can write a click handler or toggle some UI state in ordinary Rust syntax, and the framework turns it into the small piece of browser code that actually runs. For anything more elaborate, Topcoat can re-render a slice of the page on the server whenever client state changes and swap only that fragment into the DOM, an approach that will feel familiar to anyone who has used HTMX. In fact, HTMX and Alpine.js integrations ship in the box for cases the built-in reactivity system, still young and admittedly limited, doesn't yet cover.
## Tooling and design philosophy
A framework that only rendered HTML wouldn't be much help, and Topcoat clearly knows it. Real interfaces need fonts, icons, images, and stylesheets, all served efficiently, so it includes a full asset pipeline. Assets are collected or downloaded at build time and served with content hashes so browsers can cache them aggressively. Fonts and icons come from the Fontsource and Iconify libraries with a single line of setup each. Perhaps the most opinionated choice here is the component library, which borrows its philosophy from shadcn/ui: instead of importing a black-box dependency you can never quite bend to your design, Topcoat copies ready-made components, built on Tailwind, straight into your source tree. They're now your code, to reshape however your design demands.
Running underneath all of this is a design principle the authors return to repeatedly: **locality of behavior**. The idea is that a piece of code is easiest to understand when everything it depends on lives close by, and they argue this is true for both human developers and the AI tools increasingly working alongside them. In practice it means Topcoat encourages components to fetch their own data rather than receiving it through a long chain of arguments passed down from parents. To keep that from turning into redundant database calls, it provides request-level memoization, so a given piece of data is loaded only once per request mno matter how many components ask for it. The same principle extends to security: instead of trusting middleware defined in some distant corner of the codebase to protect a route, a component can require authentication directly, guarding its own data and refusing to render for a logged-out user. Because these functions simply pass the request context around, they compose cleanly, giving you something like React hooks without the awkward rules that govern them.
### Topcoat - Hello World Example
```rust
use topcoat::{
Result,
router::{Router, RouterBuilderDiscoverExt, page},
view::{component, view},
};
#[tokio::main]
async fn main() {
topcoat::start(Router::builder().discover().build()).await.unwrap();
}
#[page("/")]
async fn home() -> Result {
view! {
"Hello world"
topcoat::dev::script()
hello(name: "World")
}
}
#[component]
async fn hello(name: &str) -> Result {
view! {
"Hello, " (name) "!"
}
}
```
## How Topcoat compares to Suprnova
It's worth situating Topcoat next to Suprnova, the framework powering this very site, because the two aim at the same broad goal — making Rust a comfortable place to build full-stack web apps — while taking almost opposite routes to get there.
The clearest difference is the mental model each one borrows from. Topcoat is its own thing: a server-rendered, HTMX-flavored approach where reactivity is sprinkled ain by cross-compiling small snippets of Rust to JavaScript, and the whole UI lives inside Rust `view!` macros. Suprnova, by contrast, is unapologetically **Laravel-inspired**. If you've written PHP against Laravel, its surface will feel like home, only typed: `Auth::login`, `Cache::remember`, `Mail::to`, `Event::dispatch`, Eloquent-style models, and an `#[handler]` macro all sit on top of a hyper / SeaORM / async-trait stack.
That difference cascades into how each treats the frontend. Topcoat keeps you in Rust end to end and avoids WebAssembly *and*, for the most part, a separate JavaScript build. Suprnova embraces the JavaScript ecosystem directly through an Inertia 3 bridge, shipping starter kits for Svelte 5, React 19, and Vue 3.5, with TypeScript prop types generated from your Rust structs so the two sides stay in sync. If your team already lives in a modern component framework and wants that full interactivity, Suprnova meets them there; if you'd rather never touch a `node_modules` folder, Topcoat's server-first model is the leaner path.
Scope is the other axis. Topcoat is a focused first release centered on rendering and reactivity, leaning on companion libraries like Toasty for data. Suprnova is closer to a batteries-included plkatform: its feature surface spans an Eloquent-style ORM with eleven relation kinds, an auth system with 2FA and policies, queues and jobs, an events bus, mail across half a dozen transports, broadcasting and WebSockets, caching, filesystem abstractions over local and S3-compatible storage, a vector-store layer, payment adapters for Stripe and Paddle, scheduling, durable workflows, and an `artisan`-style console — much of what a production app needs, in the box.
Neither approach is strictly better; they suit different temperaments. Topcoat is the appealing choice if you value a small, Rust-native surface, server-rendered simplicity, and freedom from a JavaScript toolchain. Suprnova is the natural fit if you want Laravel's ergonomics and breadth with Rust's type system underneath, and you're happy to pair a typed backend with a real JS frontend. That both exist, and that a comparison this substantive is even possible, is itself a sign of how quickly Rust's web story is maturing.
### Suprnova - Hello World Example
**`src/controllers/hello.rs`**
```rust
use suprnova::{InertiaProps, Request, Response, handler, inertia_response};
use crate::controllers::inertia_config_titled;
#[derive(InertiaProps)]
pub struct HelloProps {
pub name: String,
}
#[handler]
pub async fn index(req: Request) -> Response {
inertia_response!(
&req,
"Hello",
HelloProps {
name: "world".to_string(),
},
inertia_config_titled("Hello")
)
}
```
**`src/controllers/mod.rs`** — add:
```rust
pub mod hello;
```
**`src/routes.rs`** — add:
```rust
get!("/hello", controllers::hello::index),
```
**`frontend/src/pages/Hello.vue`**
```vue
Hello, {{ name }}!
```
Then run:
```bash
suprnova generate-types
```
to emit `HelloProps` into `frontend/src/types/inertia-props.ts`.
## What Topcoat is not, and what's next
It's worth being clear aboute one boundary the announcement draws in particular. Axum, another Tokio project, is a lower-level HTTP router built for exposing API endpoints, and Topcoat is not meant to replace it. The two solve different problems and will often live in the same codebase, with Topcoat handling the reactive, user-facing application and Axum handling the raw HTTP endpoints underneath. If all you want is a lean API, Axum is still the right tool; Topcoat exists to spare you the boilerplate when you're building a full interface.
This is a first release, and the team is candid that plenty remains ahead, including tighter integration with Toasty and support for common needs like validation and email. But the framework is usable today, and the pitch is refreshingly concrete: try it, pair it with Toasty if you need a database, and bring your questions to the `#topcoat` channel on the Tokio Discord. Whether or not Rust ends up being a top choice for green-field web development, as Lerche has predicted, Topcoat is a serious attempt to make that future plausible rather than merely aspirational.