The Rust GUI story has always been complicated. Every year brings new frameworks,旧的继续发展, and the question "which should I use?" gets harder to answer. A new survey from boringcactus puts 10 Rust GUI libraries to a simple test: build a text label that updates when you type in an input field.
The test is intentionally minimal. In React, this is three lines of code. But in Rust, it's a journey through linking errors, missing dependencies, and framework limitations.
The Test Criteria
The survey checks three things:
- Basic functionality — can you build a label + input field?
- Accessibility — can Windows Narrator read the text?
- Internationalization — does Japanese IME input work?
This is more practical than most GUI comparisons, which usually just list features. Let's see what passed.
What Worked
Dioxus — The biggest surprise. It uses WebView2 on Windows (basically Chromium under the hood), and everything just worked. Windows Narrator could read the text, Japanese IME worked perfectly. The author notes some skepticism about the "Diet Electron" approach, but admits "it's probably possible to use Dioxus for real work without constantly being miserable, and that's a new high water mark for this blog series."
egui — The old reliable. Setup is straightforward, Windows Narrator works (though getting into the text field is "a little janky"). This is the immediate choice if you want something that just works.
What Failed
Azul — Linking errors with unresolved external symbols. The last release is alpha, and the API has changed since then.
CXX-Qt — 1058 linker errors. The Qt binding approach requires a full Qt installation and the linker can't find the Qt libraries.
Cushy — The code runs, but Windows Narrator can't read any of the text. Accessibility is a complete failure.
Cacao and Core Foundation — macOS only, not useful for cross-platform work.
Crux — Interesting architecture (shared business logic with native UI shells), but doesn't actually support desktop GUI — only mobile and web.
The Pattern
The survey reveals something important: the "best" Rust GUI library depends on what you prioritize.
- If you want maximum compatibility with existing web skills: Dioxus
- If you want simplicity and reliability: egui
- If you want native look and feel: You're still waiting
The author makes a pointed observation about Windows support: "I think avoiding Windows is avoiding success, and if Windows support is lower on your roadmap than trend chasing AI bullshit, you are not serious." That's worth sitting with.
The Trade-off Nobody Talks About
Most Rust GUI comparisons focus on features: hot reloading, declarative vs imperative, immediate vs retained mode. But this survey exposes the real trade-off:
Web-based frameworks (Dioxus) give you accessibility and i18n for free because they ride on Chromium. But you're shipping a browser engine.
Native frameworks (egui) give you a single binary and no dependencies. But you're building accessibility support from scratch.
There's no free lunch. The question is which lunch you're willing to pay for.
What This Means for You
If you're starting a Rust GUI project today:
- Dioxus if you want the fastest path to a working app and don't mind the WebView2 dependency
- egui if you want something lightweight that compiles to a single binary
- Tauri wasn't tested in this survey, but it's worth considering if you want a mature web-based solution
- Wait if you need native look-and-feel — the ecosystem isn't there yet
The survey is still being updated (the author notes it took them two weeks to test all these libraries). The full conclusion and comparison table should have more data. But the headline is clear: the Rust GUI ecosystem has made real progress, but the trade-offs are still stark.
The dream of "Rust everywhere, native performance" in GUI land is still a dream.
Thanks to boringcactus for doing the hard work of actually testing these libraries. Read the full survey here.