This looks to be one of the most complete Rust UI creates (in terms of available widgets/components), but unfortunately has almost no usage (yet). I do see their docs are coming along now. Another very complete one is fyrox-ui used by the fyrox game engine: https://crates.io/crates/fyrox-ui. Again, not really used/known outside of fyrox.
The Rust UI scene is maturing, but the most popular options (iced, egui, dioxus, slint, etc.) aren't even the most complete component-wise atm as far as I can tell.
UPDATE: This honestly looks incredible and makes huge strides in the Rust UI landscape. You can run an impressive widget gallery app here showing all their components:
Fyrox is such a blackpill for me (makes me doubt the Rust gamedev scene), because Fyrox appears to be the most mature Rust game engine, but nobody uses it or cares about it. Instead everyone is excited about the Entity-Component-System in Bevy, but once all the rough edges of Bevy are smoothed out, people excited about the ECS are going to realize they don't actually want to make art, or create game mechanics, they were just excited about a neat system (and in fairness, ECS is neat), but they never really wanted to do the things required for a game.
With the right workflow you can work with any language and library, by managing the context carefully and "showing-not-telling". I've worked with Claude Code and Codex on lots with Rust and Clojure, seems to not have any more issues than when I use Python.
That showcase application (other than Zed) looks awesome, but the very fancy-looking home page [1] fails to have a one-liner explanation of, uh, what the application does. Please consider fixing.
I find it sad that a lot of foundational open-source software is created/maintained by trading/crypto/money laundering companies. But OTOH it's great that they at least contribute _something_ to the society!
I don't believe that to be the case. The ecosystems where this is most true would be Rust, which has a lot of crypto use, and maybe ocaml from Jane Street. But for the most part I have to doubt this.
> I find it sad that a lot of foundational open-source software is created/maintained by trading/crypto/money laundering companies. But OTOH it's great that they at least contribute _something_ to the society!
React is unfortunately becoming more foundational than this project, and with it maintained by a company that was involved in the Rohingya genocide in Myanmar, the Cambridge Analytica scandal and so on.
This makes crypto / trading companies look like angels compared to what Facebook has done even though they made and open sourced React.
To that end, I don't see anything morally wrong with the former camp of companies supporting open source, (trading/crypto) since they didn't participate and amplify an actual genocide.
Although its still very vertically scoped for zed, I'm way more hyped about this UI than iced, dioxus ui, gtk-rs, etc. because of how complete it already is in an early stage.
Rust certainly needs more GUI component collections. There are lots of GUI toolkits, but a comparatively small number of prebuilt components you can use with any of them.
This collection looks quite useful, though the component list is mostly indistinguishable from a list of components for a web framework. The webview component is the only one that seems somewhat specific to native applications. So for something like a file-open dialog you would still have to pull in something like rfd [1] and lose styling consistency
Is this native as in "not web" or native as in actually using native text entry and scrolling widgets? There is quite a huge difference as the Java world discovered.
This looks very good from the screenshots. I will try this as quickly as I can. I have been building with egui and have tried Iced, Slint and Makepad.
I built (agentic coded) a stocks viewer app for Indian stock market data: https://github.com/brainless/Indistocks. It was a fantastic experience as to how easily I could build a GUI app.
My main product also uses egui: https://github.com/brainless/nocodo. It used to have a web app frontend and I moved to desktop app after the experiment with Indistocks. The experience has been really good, also coded with agents.
Desktop apps are fun and even on my somewhat old and slow laptop (i5 8th gen, 16 GB RAM, 2GB nvidia dedicated graphics), they are so much faster than web apps on Chrome (on Linux). I want desktop apps to make a big comeback, we could use so many old devices.
This is often a problem with Rust UI frameworks, they may look beautiful, but the moment accesibility becomes a requirement, the whole app needs to be scrapped and rewritten in something more mature.
This UI toolkit is based on GPUI library build by Zed editor team, and while they improve accessibility over time (like, improving contrast and stuff), it's opaque to screen readers.
At the moment if you want to have good accessibility story you should probably look at Slint or Qt (via cxx-qt, for example). And since System 76 picked up Iced for their UI it should receive a11y-related updates, too.
You might want to consider Dioxus if you want better accessibility in a Rust app... though afaik, there's no component library as complete as this one available.
The simplest examples have over a thousand (literally) dependencies. Amongst them, are GTK, GDK, pango, etc. It literally depends on another toolkit, which is the weirdest thing IMHO.
I think this is pretty common on Linux. You would want to GTK (or Qt) I would think to draw the top level window and perhaps system menus, etc. even though the UI itself is drawn using a GPU canvas.
Because of GNOME's insistence on not implementing Server Side Decorations, you can't not depend on libadwaita. This is what I imagine pull in all of the GTK dependencies.
You can very much draw a border on a windows and a "close" button without any libraries.
Usually, I'd understand if you're lazy and can't be bothered and just pull in some dependency to do it for you, but if you're implementing a toolkit, this is the kind of thing that is SHOULD provide.
I'm interested in how's the battery life while running a thing ilke this. Another thing I'm interested in does it support rendering to texture.. usage being used as a texture on an object (monitor let's say) in a game or rendered as a texture with opacity on a quad/triangle over a screen as a UI layer or a HUD
It seems like trading applications tend to be what demands the performance to push R&D like this for Rust GUI. My team at Kraken worked on https://iced.rs/ which powers https://www.kraken.com/desktop, a very similar application. You can definitely feel the difference in a Rust GUI vs. a web view. It can maintain high frame rates doing so much on the screen at once.
Do these "modern" UI toolkits not have visual editors for knocking up the UI anymore?
One of the strengths of Qt based UIs is that the framework has IDE like tools where creating UIs is just a matter of drag and dropping the UI widgets into a layout. No need to write code by hand. Both QtCreator and QtDesigner can support this workflow.
Secondarily this comparison table has several problems when it comes to Qt.
* Their license is dual license LGPL *and* commercial.
* Minimum binary size is definitely not 20MB but less. In general your apps distribution size depends on which features of the toolkit you're using.
* Comparing "Syntax Highlighting" makes no sense... QSyntaxHighligther is an interface by which you can add your own syntax highlighting to any QDocument. You're welcome to use reg exps, parsers (such as tree-sitter) or whatever you want there.
* QRichText supports markdown such as HTML.
This is just meant to show how awesome their toolkit is, without the goal of having fair comparison. They list chart widget, but they do not list 3D chart widget, because then they would need to show that they do not have it, but Qt does. Same for equivalent of QGraphicScene etc.
Truth is Rust doesn't have, and will not have anytime soon anything comparable to Qt or VCL/LCL. No amount of GitHub starts and "made in Rust" disclaimers is going to change that.
58 comments
[ 2.1 ms ] story [ 70.1 ms ] threadThe Rust UI scene is maturing, but the most popular options (iced, egui, dioxus, slint, etc.) aren't even the most complete component-wise atm as far as I can tell.
UPDATE: This honestly looks incredible and makes huge strides in the Rust UI landscape. You can run an impressive widget gallery app here showing all their components:
https://github.com/longbridge/gpui-component/tree/main/crate...
Just "cargo run --release"
gpui itself is spun out of the zed editor, so I'd say it probably has more real-world usage than the majority of rust UI crates
[1]: https://longbridge.com/desktop/
React is unfortunately becoming more foundational than this project, and with it maintained by a company that was involved in the Rohingya genocide in Myanmar, the Cambridge Analytica scandal and so on.
This makes crypto / trading companies look like angels compared to what Facebook has done even though they made and open sourced React.
To that end, I don't see anything morally wrong with the former camp of companies supporting open source, (trading/crypto) since they didn't participate and amplify an actual genocide.
Then again I love zed so I might be biased.
This collection looks quite useful, though the component list is mostly indistinguishable from a list of components for a web framework. The webview component is the only one that seems somewhat specific to native applications. So for something like a file-open dialog you would still have to pull in something like rfd [1] and lose styling consistency
1: https://docs.rs/rfd/latest/rfd/
I built (agentic coded) a stocks viewer app for Indian stock market data: https://github.com/brainless/Indistocks. It was a fantastic experience as to how easily I could build a GUI app.
My main product also uses egui: https://github.com/brainless/nocodo. It used to have a web app frontend and I moved to desktop app after the experiment with Indistocks. The experience has been really good, also coded with agents.
Desktop apps are fun and even on my somewhat old and slow laptop (i5 8th gen, 16 GB RAM, 2GB nvidia dedicated graphics), they are so much faster than web apps on Chrome (on Linux). I want desktop apps to make a big comeback, we could use so many old devices.
Still waiting to see more general use before attempting to port my Svelte UI for a Tauri application but it honestly looks incredible.
Big ups to the guy(s) at Longbridge.
So many UI frameworks don't have these and require building them yourself...
This is often a problem with Rust UI frameworks, they may look beautiful, but the moment accesibility becomes a requirement, the whole app needs to be scrapped and rewritten in something more mature.
This UI toolkit is based on GPUI library build by Zed editor team, and while they improve accessibility over time (like, improving contrast and stuff), it's opaque to screen readers.
At the moment if you want to have good accessibility story you should probably look at Slint or Qt (via cxx-qt, for example). And since System 76 picked up Iced for their UI it should receive a11y-related updates, too.
Usually, I'd understand if you're lazy and can't be bothered and just pull in some dependency to do it for you, but if you're implementing a toolkit, this is the kind of thing that is SHOULD provide.
One of the strengths of Qt based UIs is that the framework has IDE like tools where creating UIs is just a matter of drag and dropping the UI widgets into a layout. No need to write code by hand. Both QtCreator and QtDesigner can support this workflow.
Secondarily this comparison table has several problems when it comes to Qt.
Truth is Rust doesn't have, and will not have anytime soon anything comparable to Qt or VCL/LCL. No amount of GitHub starts and "made in Rust" disclaimers is going to change that.