2024-09-02
2954
#rust
Abiodun Solomon
32012
Sep 2, 2024 ⋅ 10 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:

Solving The Node.js Console.Time Is Not A Function Error

Solving the Node.js console.time is not a function error

Explore the two variants of the `console.time is not a function` error, their possible causes, and how to debug.

Joseph Mawa
Nov 1, 2024 ⋅ 6 min read
Why jQuery 4 Is A Good Reminder To Stop Using jQuery

Why jQuery 4 is a good reminder to stop using jQuery

jQuery 4 proves that jQuery’s time is over for web developers. Here are some ways to avoid jQuery and decrease your web bundle size.

Shalitha Suranga
Oct 31, 2024 ⋅ 11 min read
How to Create a Multilevel Dropdown Menu in React

How to create a dropdown menu in React

See how to implement a single and multilevel dropdown menu in your React project to make your nav bars more dynamic and user-friendly.

Ibadehin Mojeed
Oct 30, 2024 ⋅ 12 min read
Purple background with different connections between icons for an article about building Node.js modules with Rust and NAPI-RS.

Building Node.js modules in Rust with NAPI-RS

NAPI-RS is a great module-building tool for image resizing, cryptography, and more. Learn how to use it with Rust and Node.js.

Rahul Padalkar
Oct 30, 2024 ⋅ 7 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