Rust cross-platform GPUI components
46 comments
·October 27, 2025nu11ptr
airstrike
> 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.
I think part of the issue is that they're still changing so much as we speak. But there's real momentum here and n=1 but I've been able to build incredibly rich, enterprise-ready UI with Rust today.
nu11ptr
> I've been able to build incredibly rich, enterprise-ready UI with Rust today.
Which UI crate did you use? The word "enterprise" caught my eye. So far I haven't found a Rust UI crate that I found rich enough, so I'm curious your experience.
galangalalgol
I think you'll find two definitions of enterprise ready. People who make UIs and are comparing a UI crate to see how it stacks up, and people who write business logic in rust and only care that they were able to make a gui work without switching to some other language. I would put my org in the second situation. Someone bought the thing and didn't complain so good enough I guess. We were using egui.
airstrike
I used `iced` but admittedly I also used a lot of elbow grease. Custom Theme, custom widgets and lots of passion to get it to look Just Right.
matu3ba
Since you think the UI scene is maturing: Where do I find 1. design docs and 2. debugging infra docs (Validation, Testing, Stepping, Logging, Tracing, Recording, Scheduling, Reversal Computing as typical ones) and/or how to apply them ?
nicce
> 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"
Very impressive! Only thing I am concerned over is that it uses around 900 dependencies. But I don't know whether it much for GUI applications.
nu11ptr
That did seem excessive to me as well. I do worry about the DX of trying to work on an app with this. After each edit, I would expect a solid compile time to simply try your work.
nicoburns
I don't think GPUI has it integrated yet, but Dioxus's Subsecond tool [0] implements binary hot-patching for Rust apps which can help alieviate this problem.
The other thing you can do (which is popular in the Bevy community) is to compiile the "core runtime" into dynamic library. Then you don't need to recompile that set of crates for incremental builds.
[0]: https://github.com/DioxusLabs/dioxus/tree/main/packages/subs...
defraudbah
[flagged]
agluszak
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!
bezbac
gpui itself is maintained by the folks at https://zed.dev.
baq
Bitcoin ethos (as in, the original 'banks are broken, let's fix this') is kinda similar to the hacker ethos ('this thing/program is broken, let's fix this'), so maybe this shouldn't be too surprising? Short term pain for long term gain etc.
(disclaimer: I think bitcoin is dumb, but the market disagrees)
nicce
> (disclaimer: I think bitcoin is dumb, but the market disagrees)
I believe that market is quite controversial. Most people know that bitcoin is a bit dump, but they buy it regardless because they believe they profit from it when they do that as part of larger group. A very interesting social experiment with the mix of market manipulation. It is less about stability, independence or usability of the currency, but more about the opportunity of profit.
philipallstar
I doubt that a lot of it is.
h4ch1
GPUI and GPUi components are the two things I'm watching very closely while evaluating truly native GUI development.
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.
kennydude
Looks great for those using Rust - however I do wonder how well this works, if at all, under screen readers and other accessible tech?
jeroenhd
Haven't tried running the code myself, but their API docs mention accessibility at least: https://longbridge.github.io/gpui-component/docs/components/...
Assuming the docs are correct, the UI controls seem ARIA compliant as long as you bother implementing the necessary descriptions and labels.
fidotron
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.
nu11ptr
Pretty sure native as in "not web". AFAIK, everything is drawn using the various GPU APIs (GPUI started with Metal on macOS, for example).
mdhb
Same model as Flutter which is a million times more pleasant to write and mature at this particular use case which I don’t actually think Rust is well suited to generally speaking.
nicoburns
Rust's definitely well-suited to writing the low-level infrastructure pieces (the implementations of the renderer, layout, text, etc). You really want something with fast and predicatable performance there. Whether it pans out for writing actual applications we'll have to see, but a lot of big popular applications are written in C++ which is surely less suitable.
meindnoch
Native as in "not web". No OS integration.
hsn915
I think it's native as in "native executable".
GPUI is not "native OS widgets".
wongarsu
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
berkes
> lose styling consistency
Yes. And that is (almost always¹) a good thing.
Only the designers of an app, product-owners etc. want their app to "look consistent over platforms".
Your users want the file-dialog, window-chrome, menus etc consistent too. But for them consistent means consistent with the 20+ other applications they use on a daily base. So native.
¹ Obviously some software excepted. E.g. categories like "expert software" like Blender, AutoCAD, Photoshop/CS, where dialogs must a) be optimized for their niche workflow and b) remain consistent for that user when they upgrade their OS or move between OSes. But that's an exception. Your TODO-list app or PDF reader almost certainly is not that.
nu11ptr
Even though most UI libraries now draw their own widgets some native integration is almost always used/desired. Those integrations are typically: keyboard short cuts, native system menu (macOS), native file dialogs, and (sometimes) native context menus. I'm sure there are others I'm forgetting, but these minimal integrations are a good thing as they give the user some sense of familiarity.
filleduchaos
Not just a sense of familiarity; you will simply never build the full spectrum of a file explorer's functionality in a custom file dialog, that would be a complete waste of engineering time. And many more users than you'd expect benefit from the fact that native file dialogs are actually full-fledged explorers. For example, I fairly often find myself quick-previewing a file to be sure it's the correct one when I select it.
patwoz
You should always use the native file picker and not shipping your own. That’s a good thing.
ramon156
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.
Then again I love zed so I might be biased.
unwind
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.
nicce
I guess they expect that most people come there from the top level domain. (https://longbridge.com)
h4x0rr
Hola, finally a good rust ui framework that's not dependent on web
SilverSlash
I was expecting something ugly but these actually look beautiful!
brainless
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.
UndyingHorse
Why is the average binary size 10MB? Does it embed ICU data?
nicoburns
I can't speak for GPUI specifically, but in general for Rust UI toolkits I'm seeing about 10-15mb for an O3 build with LTO enabled and when including things like ICU data, a WGPU-based renderer, SVG rendering support, and a "full fat" async HTTP client. More minimal builds with features disabled and/or Os/Oz can bring that down to more like 5mb.
(obviously you can also take things much higher by building more functionality into your application, but that gives you an idea of the kind of "base size" achievable).
berkes
> By default, Rust optimizes for execution speed, compilation speed, and ease of debugging rather than binary size, since for the vast majority of applications this is ideal. But for situations where a developer wants to optimize for binary size instead, Rust provides mechanisms to accomplish this.
https://github.com/johnthagen/min-sized-rust?tab=readme-ov-f...
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:
https://github.com/longbridge/gpui-component/tree/main/crate...
Just "cargo run --release"