2025-05-28
3301
#rust
Abiodun Solomon
32012
May 28, 2025 ⋅ 11 min read

Exploring the top Rust web frameworks

Abiodun Solomon I’m a software developer that is curious about modern technologies. I love contributing to the growth of knowledge for the betterment of humanity.

Recent posts:

Wasm 3 Before GTA 6 LogRocket Article

We got Wasm 3.0 before GTA 6: Meet the web’s new engine

Discover how WebAssembly 3.0’s garbage collector, exception handling, and Memory64 transform Wasm into a true mainstream web platform.

Ikeh Akinyemi
Oct 3, 2025 ⋅ 2 min read

How to use AI to build accurate ShadCN components

AI agents often break shadcn/ui components with outdated docs or made-up props. The MCP server fixes this by giving live access to registries. In this tutorial, we’ll set it up and build a Kanban board to show it in action.

Chizaram Ken
Oct 3, 2025 ⋅ 5 min read
Rust Project for Web Services LogRocket Article

The best way to structure Rust web services

Learn how to structure Rust web services with clean architecture, Cargo workspaces, and modular crates for scalable, maintainable backends.

Jude Miracle
Oct 2, 2025 ⋅ 2 min read
andrew evans headshot

A spec-first workflow for building with agentic AI

Andrew Evans gives his take on agentic AI and walks through a step-by-step method to build a spec-first workflow using Claude Code.

Andrew Evans
Oct 1, 2025 ⋅ 18 min read
View all posts

14 Replies to "Exploring the top Rust web frameworks"

  1. Yeah, you’re missing Warp, it’s the Tokio equivalent to Tide. Warp and Tide are both quite good, it just depends on whether you favor async-std or tokio.

    Also, I think Iced deserves a mention here, since it can compile to WebAssembly and WebGPU, in addition to platform-native Metal, Vulkan, and OpenGL. Also, people are even experimenting pairing Iced with cargo-mobile, which is also exciting!

  2. How can you say Rocket is production-ready when it can’t even compile with stable Rust? In my environment, I will have to wait until there’s a release that can run on stable Rust. Hopefully it’s coming soon with Rocket v0.5.

  3. > Rocket is a popular, mature web framework
    Latest Release: 0.5.0

    As long as it hasn’t reached 1.0, you can’t really call it mature, now can you? It’s an admission from the developers themselves that they have not implemented everything on the roadmap yet.

  4. Sauron isn’t outdated. It is still being actively developed. Seed is effectively dead, and Yew’s syntax and performance are vastly inferior to it. By far the best frontend web framework at the moment.

  5. Why do you say that? By Github stats, both Sauron and Seed went on life support six months ago, like Stdweb and Percy did a year ago. Only Yew is maintaining its velocity and only Smithy looks dead.

  6. Hi, it appears you’ve updated the article, and yet you list warp and axum as being not “production-ready”. You never explain your criteria for this subjective determination, but you also list warp as not supporting either concurrency or async-await, and axum as not supporting async-await, and yet, I’m literally doing that here:
    https://github.com/diba-io/carbonado-node/blob/cb134b57c260d48a405fbd2199c3201468e1259e/src/frontend/http.rs
    So, these specific claims are objectively false.

    As for the “production-readiness” of frontend frameworks, Iced is used by System76 for their new desktop software on Pop!_OS, which is a very popular operating system that they ship on millions of dollars worth of hardware. See:
    https://www.phoronix.com/news/COSMIC-Desktop-Iced-Toolkit

    Dioxus and Tauri are also making leaps and bounds of progress, and there’s a big effort towards the modernization of Yew as well. If anyone wants my recommendation, well, it depends on the use-case, but I’d recommend looking into Dioxus, Axum, and Tauri. Iced is also a very capable UI library, but I don’t think it’s as good in web contexts anymore. Rust is actually a very flexible language, and WebAssembly support has come a long way.

    Really, this article just isn’t going to age well. You should probably remove it, or add a big huge giant disclaimer, “These are just my opinions and I don’t actually know very much about what I’m writing about at all lololol”. Otherwise you’re just providing disinformation on what’s likely a prominent search engine query, and will continue to do so as the ecosystem matures.

    1. I appreciate the feedback and I can understand why you may feel that way.

      Regarding the production readiness of certain Rust frameworks, I must clarify that it is not my intention to discredit any framework or library in the Rust ecosystem.

      However, it is important to note that the criteria for production readiness can be subjective and depend on a variety of factors, such as community support, stability, performance, and security. In the article, I may have overlooked certain factors or not provided enough context for why I came to the conclusion that a particular framework may not be production ready.

      I would update the article by buttressing more on the criteria to which the frameworks are ready for production and as well add some of the companies that use each one of them.

      Once again, I appreciate your feedback and will use it to improve the quality of my content going forward.

      1. I do agree with the poster that I was confused by the parts regarding Axum not having async support when Axum is an async framework built on top of Tokio, the rust async runtime, as mentioned in the article.

Leave a Reply