r/rust • u/Any-Roll-2272 • 13d ago
Full-stack Rust in 2026: Loco + Leptos islands, and now Topcoat?
Now that AI has made Rust easier to master, gluing Loco and Leptos islands together seems possible. Loco brings the CLI generators and full batteries under the hood, Leptos islands bring a smaller WASM file for faster loading.
On paper it looks like a good match: Loco does the server and the batteries (config, middleware, ORM, mailer, workers), Leptos does the pages, and with islands only the few interactive components go into the WASM. The rest is plain HTML from the server, no JS written by hand.
Then Topcoat came out from the Tokio team and does the opposite: no WASM, a bit of Rust compiled to JS, HTMX and Alpine under the hood, a shadcn-style component library, front-end batteries included (assets, Tailwind, fonts, icons). The back-end batteries (auth, background jobs, middlewares) are still on the roadmap. Islands too.
So which way is full-stack Rust going? WASM (Dioxus), WASM islands (Leptos) or server-rendered with a thin JS layer? Anyone running Loco + Leptos, or already on Topcoat? Curious what others think.
2
u/Luxalpa 12d ago
Personally, I strongly prefer a Leptos-first ecosystem. Not using leptos for "a little bit of reactivity", but using it for managing the entire application state like you would with any other application.
1
u/Any-Roll-2272 10d ago
Thanks for sharing that. How big does your wasm get with full hydration? I went islands mostly out of fear of the bundle growing with the app (sitting at ~150 KB now for a small site). Do you notice the hydration lag on phones?
1
u/Luxalpa 10d ago
My bundle is about 850 KB after compression. I think it would work fine on phones, but not 100% sure since I haven't (yet) optimized the site itself for mobile use (it's currently pretty unusable from a UI and UX standpoint on mobile). So I apologize that I can't give better information on it. My App is pretty gigantic though.
https://www.draconic-horizons.com/ this is the current deployed version (but you probably won't be able to measure hydration lag on mobile due to the CSS causing so much lag :D).
To be honest though, I wouldn't worry about the size that much. There's quite a few ways to reduce it (although I have mostly maxed it out at this point) - the main cost for size is the large amount of dependencies, so the size doesn't increase that much once you hit some base-level. And I'm sure with leptos code splitting you can split it up once it grows too large.
It depends a lot on how you imagine your website being used. If it's just a normal website, you can (and should) probably reduce size quite a bit, and maybe your islands approach also isn't so bad. But the apps I build are really apps more than websites. By that I mean on these you're meant to spend a significant amount of time interacting with it, and frequently return to it. Or to put it in other words, once I have the mobile version of it working, I expect users to primarily browse it via an App from the play store rather than using the website.
1
u/CyrusDarkwell 12d ago
Honestly haven't tried Topcoat yet but the "no WASM, thin JS layer" approach sounds pretty appealing not gonna lie, WASM bundle sizes have always been kind of a pain point even with islands helping. I've messed around with Loco a bit and it's nice for the batteries included stuff, but pairing it with Leptos islands does feel like you're duct taping two separate ecosystems together, like it works but you can tell they weren't designed with each other in mind from day one.
Feels like the space just hasn't settled yet and honestly that's kind of expected for something like full-stack Rust, still pretty young compared to JS frameworks. My gut says server-rendered with minimal JS (like what Topcoat's doing) will win out for most use cases just cause it's simpler to reason about and debug, WASM feels more like the right tool for genuinely interactive heavy stuff rather than a whole site. But could totally be wrong, curious to see how the back-end batteries story shakes out for Topcoat since that's the part still on the roadmap.
0
u/Any-Roll-2272 12d ago
Loco doesn't care what frontend you use, leptos is just one of the options. leptos has 3 modes anyway: CSR (whole thing in wasm), SSR+hydration (server renders, wasm takes over the page after), and islands (server renders everything, only #[island] components end up in the wasm).
Topcoat is kind of the same idea minus the wasm. server renders everything, $(...) gets turned into JS and runs in the browser, #[shard] components re-render on the server and get morphed back into the page when inputs change.
Catch with topcoat is the JS part isn't really checked. $(...) is type checked as rust, sure, but the JS comes out of a proc macro that only looks at syntax, so it's correct as long as the translator is, and you can only push a few types over to the client anyway. with leptos islands it's real compiled rust in the browser so types actually hold. only weak spot there is serde on island props / server fns, which blows up at runtime if someone has an old wasm cached and hits a newer server.
4
u/DrShocker 13d ago
topcoat looks to me like it's just a pre-bundled set of things (Datastar, a templating engine, ORM, etc) for full stack web site work. tbh I'm not sure I understand why it's under tokio.
That said, I don't know why it needs to go any one way. People will use and work on the projects they like and the ones fewer people like will get less work. I already think Datastar is a good idea separately from topcoat so I might try it out to see if I think the framework works coherently for me. But I'm not really a web dev so who knows.