There is a super-new Rust Web Framework in town, and it's name is Topcoat
Rust is already a solid choice for backend development, especially with frameworks like Axum. But building a complete web application in Rust still means connecting many different libraries yourself. That is the problem Topcoat wants to solve.
Topcoat is a new batteries-included framework created by Carl Lerche and Julien Scholz for building full-stack, reactive web applications entirely in Rust.
Announcement: https://tokio.rs/blog/2026-07-22-announcing-topcoat
GitHub: https://github.com/tokio-rs/topcoat
Prefer a video version? I discussed Topcoat directly with Carl Lerche, the creator of Tokio, and Julien Scholz, the creator of Topcoat.
What is Topcoat?
Topcoat is fully server-rendered.
Your components can be asynchronous, access the database, load application state, and check user permissions directly on the server.
A minimal application looks like this:
#[tokio::main]
async fn main() {
topcoat::start(Router::builder().discover().build())
.await
.unwrap();
}
#[page("/")]
async fn home() -> Result {
view! {
<!DOCTYPE html>
<html>
<head>
<title>"Hello world"</title>
topcoat::dev::script()
</head>
<body>
<h1>"Hello from Topcoat!"</h1>
</body>
</html>
}
}
Reactivity without WebAssembly
Frameworks like Leptos and Dioxus can run Rust in the browser through WebAssembly.
Topcoat takes a different route.
It renders the application on the server and adds client-side reactivity through small reactive instructions. It can also re-render parts of the UI on the server and replace only the section that changed.
The approach is closer to HTMX or Hotwire than to a traditional React-style SPA.
This makes Topcoat especially interesting for:
- Admin panels
- Internal tools
- Blogs and content platforms
- Online stores
- Data-heavy applications
For highly interactive browser applications, a client-heavy framework may still be a better fit.
Is it replacing Axum?
No. Axum is still a great choice for APIs and lower-level HTTP endpoints.
Topcoat works at a higher level and tries to remove the boilerplate between routing, components, HTML rendering, assets, and reactive updates.
A project could easily use both.
Why Topcoat matters
Rust already has many excellent libraries, but it has been missing a more opinionated, integrated experience similar to Rails, Laravel, or Next.js.
Topcoat is moving in that direction with:
- Server-rendered components
- An asset pipeline
- Tailwind-based UI components
- Fonts and icon integrations
- Request-level memoization
- Authentication close to the protected component
- Planned integration with the Toasty ORM
It is still early, and the team is open about the current limitations of its reactivity system.
Still, this feels like an important step for Rust web development.
Topcoat is not here to replace every existing framework. It is trying to make it much easier to build complete, server-rendered applications without leaving Rust.
Would you try it for your next internal tool or dashboard?
Watch the full discussion with Carl Lerche and Julien Scholz:
Top comments (10)
I'm curious to know more about how Topcoat handles server-side rendering and caching, as it seems like a crucial aspect for production-ready web apps. The article mentions it's "already a solid" foundation, but I'd love to hear more about its performance in comparison to Next.js. Are you planning a follow-up post on performance benchmarks?
I'm doing even better, I'm gona test it live and give my honest impressions about it: youtube.com/live/rbMsHf2dzWY
Topcoat looks interesting, but “better than Next.js” feels extremely premature for a framework that was announced yesterday. The article introduces the framework but does not really compare ecosystem maturity, deployment, build performance, developer experience, or production limitations. At the moment, the title promises a verdict that the article does not attempt to provide.
that's why the question mark, it's just to get tihngs interesting for javascript developers. Of course it can be compared to Next.js ina serious way (for now). But it looks very promosing to me
The "authentication close to the protected component" detail is the one I keep turning over. Co-location solves a real class of bugs — in middleware-first stacks, someone adds a route and forgets to attach the guard, and you find out in a pen test rather than a code review. But spreading auth decisions across components also makes it hard to audit the full permission surface in one pass; you lose the single choke point. What I'd want to know is whether they're leaning on Rust's type system to make it structurally impossible to render a protected component without resolving auth first — a trait bound that encodes the invariant rather than just relocating the risk. If Topcoat ships that, it's a genuinely different security story than what most server frameworks offer.
let me know what you thinka about it!
The interesting tension here isn't Rust-vs-Next, it's the server-driven reactivity model itself, and the post glosses over where it actually hurts. When you re-render a section on the server and swap it in over the wire, every interaction that used to be a local state flip is now a round trip. HTMX and LiveView both live with this — the moment your admin panel has a filter dropdown or an optimistic toggle, you feel the latency, and you end up sprinkling in client-side islands anyway. So "reactivity without WebAssembly" isn't free; it's trading bundle size for a network dependency on interactivity.
The part I'd actually pressure-test is the "small reactive instructions" claim, since that's the whole differentiator versus plain HTMX. LiveView's morphdom-style DOM patching is where the real complexity lives — preserving focus, scroll position, and in-flight input state across a server patch is genuinely hard, and it's exactly the kind of thing that looks great in a hello-world and gets gnarly with a real form. The post even admits the team is "open about the current limitations of its reactivity system," which is the honest signal that this is the unsolved part, not the batteries-included routing.
For an internal tool where a 50ms round trip is invisible? Sure, this model is a genuinely good fit. I'd just want to see how it handles a stateful widget mid-typing before betting a dashboard on it.
Rust has always had the performance story, but the missing part was developer flow. If Topcoat can remove the glue work, it makes Rust much more interesting for building real products.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.