Rust Cross-Platform Gpui Components
Posted2 months agoActive2 months ago
github.comTechstoryHigh profile
excitedpositive
Debate
40/100
RustGUICross-Platform Development
Key topics
Rust
GUI
Cross-Platform Development
The GPUI component library for Rust has been released, sparking discussion about its features, limitations, and potential applications, with many users expressing excitement and interest in exploring its capabilities.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
47m
Peak period
140
0-12h
Avg / period
32
Comment distribution160 data points
Loading chart...
Based on 160 loaded comments
Key moments
- 01Story posted
Oct 27, 2025 at 5:44 AM EDT
2 months ago
Step 01 - 02First comment
Oct 27, 2025 at 6:31 AM EDT
47m after posting
Step 02 - 03Peak activity
140 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 2, 2025 at 9:35 AM EST
2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45719004Type: storyLast synced: 11/20/2025, 8:23:06 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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"
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.
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.
Thanks for the reply.
In my case I did mean "I can write/maintain a UI rich/polished enough to pass as a 'shrink wrapped'"
FWIW, you wrote that you actually HAVE done so, not just that you think you could:
"but I've been able to build incredibly rich, enterprise-ready UI with Rust today."
Unless one has actually done so, and maintained/extended over a period of time, and not solo but with others, I don't know that one can be certain that a UI toolkit is good enough; certainly, it would be hard to know what surprising edges and ergonomics there are to consider in one's evaluation.
I hear your point, but it's important to note I'm not making those claims and I don't think all of that needs to be true for it to be some value of "enterprise-ready". You and I may disagree on the meaning of that term, and that's fine.
Pain points were learning to think in The Elm Architecture early on and creating very complex custom widgets of my own (think a spreadsheet editor, for example)
I made some tiny apps available on my github as I was learning Rust and the library. None really meet the enterprise grade hurdle but show some of what's possible with little code. If you spend a little while longer you can make them much more polished, obviously. I kept them "unpolished" so they would be even easier for beginners to follow
https://github.com/airstrike/iced_receipts
https://github.com/airstrike/pathfinder
I do share screenshots and screen recordings every now and then in the iced Discord but I've so far refrained from posting about it on HN which is a much bigger audience
I suppose the best description of the UI is a mashup of VSCode and Figma
I have a feeling iced would work similarly well but the documentation situation wasn't as good last I checked.
And if you're on Discord, the community is 10/10. I'm there all the time and always helping newcomers, and so are many others.
> 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.
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...
I'm curious as to what this means exactly. Are you saying keep the UI stuff in a separate crate from rest of app or ???. And just a separate or an actual dynlib? (wouldn't that imply C ABI? would make it a pain to interface with it)
It doesn't necessarily require C ABI. Rust doesn't make any guarantees about stability of the Rust ABI. But if you compile the app and the dynlib with the same compiler version then it works in practice (and IIRC there are enough things relying on this that this is unlikely to break in future).
That does mean you need to recompile the dynlib when you upgrade the compiler, but that is probably infrequent enough not to be a huge issue. Certainly if your aim is fast-recompiles in response to e.g. ui style changes then it ought to work.
--
A note on the sort of Rust compile times I see for a TodoMVC app using my Rust UI framework (412 dependencies):
- A clean release build (-O3) is 1m 01s
- An incremental (-03) rebuild is 1.7s
- A clean debug build (-O0) is 35s
- An incremental debug build (-O0) is 1s
That's on a 2021 MacBook M1 Pro which is fairly fast, but I hear the M4 machines are ~twice as fast. And that's also without any fancy tricks.
However, I don't see what advantage this gives. You are going to specify that dependency in your Cargo.toml just like any statically linked crate. Anything that would invalidate the cache for a static crate would invalidate it for a dynamic linked crate. Iow, it seems like separate crates are the magic here, not the linking type. What am I missing?
Thanks for the build stats. Those are helpful. I have an M1 Max currently.
UPDATE: Good points below. As a dynlib it would create a boundary for sure (no LTO, etc.). Worth playing with, thx.
I believe it may "just" be faster link times. Which may seem minor, but link times can often dominate incremental compile times because it's a slow and (at least historically) serial step which is O(total code size) even if the actual compilation is incremental.
See mold's linking benchmarks: https://github.com/rui314/mold. It can be the difference between multiple 10s of seconds with traditional linkers vs <2s with newers ones.
There are few strategies for dealing with this:
1. Is just to use a faster multi-threaded linker. On Linux, lld, mold, and wild on Linux are all much faster than the traditional ld/gold (and the latter two another step above lld). On macOS, the new built-in ld64 is pretty good. Not sure what the state is on Windows: possibly lld is best?
2. Is dynamic linking as above. This seems to be faster even though the dynamic links need to resolved at runtime. I presume because at least the links wholly within the dynlib don't need to be resolved.
3. Is tools like Subsecond (https://github.com/DioxusLabs/dioxus/tree/main/packages/subs...) which effectively implement incremental linking by diffing the symbols in object files.
(dioxus-7-rc.3)
It usually only works when reordering elements, or changing static values (styles, attributes, etc).
Which, to be fair, does speed things up a lot when tinkering with small details.
But 70%+ or so of my changes still result in recompiles.
I've been able to get the hotpatching to work for use cases like "extract some UI code" into a new component that didn't exist before.
Note that the hotpatching is not enabled by default, you have to specify --hotpatch when running dx
I indeed was not enabling it.
I'll give it a try!
Yeah, although I would define "reversible computing" as how to deterministically undo some computation(s)/effect(s) etc without recording the control-flow and I do not like the notation of "time-reversibility", because distinguishing between "reversible computing with known timings" and "reversible computing with unknown timings" becomes very confusing. So I'd phrase it somewhat differently, but did not come up with better naming yet. Context: https://en.wikipedia.org/wiki/Reversible_computing and https://en.wikipedia.org/wiki/Time_reversibility.
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
I'd be very surprised to learn that any other Rust UI crate has more real-world usage than GPUI!
Source:
https://sequoiacap.com/article/partnering-with-zed-the-ai-po...
I wonder if there are more Cosmic Desktop + Kraken desktop users than Zed Editor users?
The more salient metrics would be things like how many people know how to use the framework, the variety of use-cases its good for solving, how easy it is to hire or get help with it, etc. As for Druid, Druid is already officially unmaintained, its core developer having moved on to work on Xilem instead. (my experience, for the record, was positive, I very much enjoyed working with Druid.)
I actually tried to create a UI kit using zed's code for a personal project, but gave up.
nice to see I was not the only one with the idea and it can get some usage now. The example app looks awesome.
Are you trying to tell something more logical? Does the "Rust gamedev scene" affect the technical merits of libraries?
And to be fair, not every great engineer is a great writer, artist, composer, or any other role one might like to have on board for making a game.
Nobody makes games in Bevy though, Bevy is just a very good, modern graphics tech demo, not something suitable for developing actual games. Even the biggest title out there, Tiny Glade, is just a level editor with precisely zero gameplay features. Bevy's "popularity" (on social media, not among game developers) is entirely hype-driven by people that do not actually make games at all.
This stance is not necessarily wrong - life is short, after all, and not every cup of tea has to be drunk from - but it does make finding useful criticism in a haystack of generic talking points rather difficult.
The entire raison d'être of Bevy and the reason it is built how it is is that the ECS eliminates that. If your Bevy code contains something that looks like that, you are using it very wrong. You put the data in the ECS, and any gameplay code goes into some system that uses the queries to pull the data it needs out of it. If you need something like a backreference, you don't add one in an unholy tower of refcells, you just use a different query.
If you wanted to argue that a soup of mutually referencing objects is easier to deal with than having to use a query system, I'd disagree, but you'd have a valid argument. What you posted above just highlights that you don't know much about bevy.
Obviously not true, latest Bevy Jam has ~100 submissions! They might not be the games you were thinking about, but they're games nonetheless.
Beyond the game jams there are definitively people making games with Bevy too, but I don't think anyone of them gone mainstream (yet?) but it's a bit harsh to say no one is making games with Bevy when that's clearly not true.
It takes a long time for a game engine to be ready to create the kind of experiences you're probably thinking about, and even if everything goes great with Bevy in the future, it's still probably years rather than months until any big studio will think of start using it for something important.
With that said, people are for sure making games in Bevy even if the experience is non-optimal. Search on GitHub for "bevy" and sort by latest update and you get a snapshot of the projects that are on GitHub, then imagine there is a magnitude more people working privately.
https://steamdb.info/stats/gameratings/2025/?min_reviews=500...
https://steamdb.info/app/2198150/
And again, I am not sure what exactly people are expecting of a game engine that started development in 2019. Development of Tiny Glade itself started less than three years after Bevy's first commit, which was an obvious factor in Pounce Light building a custom renderer.
For me the experience is completely the opposite. ECS as a pattern lets me build way larger games with more complicated and interesting gameplay than I could build before without ECS. It's something about about easy it makes to create de-coupled functions and being able to easily put things under automatic testing that makes the whole process so much smoother. Before moving to Bevy I mostly used Unreal Engine and on two projects Unity, FWIW.
> I judge the viability of a game engine/framework based on its commercial success. This may be a bit harsh
I don't think it's harsh at all, I'd do the same if I was trying to build mainstream games, and I think many other peoples do so to.
But that's also very different than "Nobody makes games in Bevy though" which is what you said at first, which is a lot less charitable than what you wrote in your comment now. I understand it's an exaggeration, but it reads as you're sour about it, rather than being interested in a conversation about it.
However, it doesn't even use Bevy's renderer, but their own: the devs mostly just care about its ECS. So it definitely isn't the showcase Bevy is looking for.
I would agree with you that bevy is not fit for making a commercial game. but not because its not capable. Its just NEW. we are only now starting to see commercial games come out with godot and thats 11 years old. bevy came out what, late 2021? give it some time. It still needs more workflow tools, a level editor stable documentation and a bunch of other things.
It will get there. it just takes time.
But the lineup of high-quality games in production with Bevy just never stops to impress me. I'm always surprised by the new cool stuff they're making every time I take a peek at their community. Yes, most of them are not finished yet, but the engine is still young so that's understandable (gamedev can take years).
On the other hand, I'm still not really seeing any games being made in Fyrox despite it being a few months older than Bevy. Huge respect to the dev though, he's making great stuff.
But if I ever need to pick a pure Rust game engine at all, it's def going to be Bevy.
Bevy gets all the hype, but Fyrox has more maturity in a lot of surface area.
Bevy is led by a large team, and the leadership is ex-Google.
Fyrox is one solo Russian developer with 10x engineering output.
Bevy is ECS, Fyrox isn't.
Bevy does a great job marketing itself, it has a foundation and a large community, and people are excited to try and use ECS.
Doesn't mean bevy is better or anything, just that because it's so different people tend to flock to it.
The smell for me is if the library is designed based on a plan, or attempting to be X ecosystem in Rust instead of built around one or more practical piece of software, and evolving to meet the needs of these softwares.
With that in mind: I adore EGUI. I hadn't heared of GPGUI before, but because of its origin as being purpose built for the Zed editor, this immediately gives it credibility, and I'm excited about it!
[1]: https://longbridge.com/desktop/
That's the typical answer to these questions. Unfortunately, unless you bake it in from day #1 that's not so simple to fix afterwards.
Assuming the docs are correct, the UI controls seem ARIA compliant as long as you bother implementing the necessary descriptions and labels.
(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.
Also, Longbridge, who seem to be using this GPUI component library for their Longbridge Pro [1] app, look to me like a regular online brokerage company. What is your issue with that?
1: https://longbridge.com/desktop/
BTW, I am not associated with zed in any way.
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.
(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).
https://github.com/johnthagen/min-sized-rust?tab=readme-ov-f...
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/
Linux is now working towards that goal as well, in the form of XDG Desktop Portal. It puts the Desktop Environment (or third party provider) in charge of providing services like the file dialog/picker/chooser for better integration/coherence. It's not been fully adopted yet, but I'm very excited about it because GTK's file chooser is just awful and I want to provide my own to those apps!
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.
Videogames.
Excel still supports MS-DOS Lotus 1-2-3 "/" commands, although it certainly doesn't look like Lotus for MS-DOS.
Basically any software people care about is an exception to your rule.
As pointed out.
I don't think what you posit is true at all, at least not in 2025. Windows itself has abandoned consistency between its native applications, with more custom and modern styling that looks nothing like what you get out of the box with Windows UI frameworks. Almost every piece of software currently running on my computer has custom chrome: the web browser, my VPN, VSCode, Discord, Steam, mouse driver, keyboard driver, laptop fan driver. The only one that doesn't is qbittorent, and it looks like a complete eyesore. It is quite literally the odd one out, so much for "consistent with 20+ other applications".
Maybe it's different in MacOS land, but from my perspective you're 20 years behind if your application is trying to blend in with the OS in any regard other than the corner in which the X button is located. That way of thinking went out of fashion decades ago, and good riddance to it because things look much better now. What I mentioned above is a pretty good representative sample of my daily use, and the more I think about other software I occasionally use, the more I am grateful that nobody else still thinks like this. LiveSplit and Asesprite come to mind as two applications that strongly benefit from having bespoke chrome and wouldn't be nearly as nice to use if they looked anything like a native Windows application. Of course, my own software uses custom chrome as well, because looking nice makes it more pleasant to use, wouldn't you know it.
It is. Windows has always had consistency issues; macOS hasn't.
I do fully admit these consistency issues were less bad in the past.
This is a problem. One that end-users may not recognize, but the cognitive load and learning curve this brings is real and costly.
It is one of the many reasons people like Mac. It's also one of the reasons people feel awkward on e.g. Ubuntu (or just linux). Because eventhough GTK is highly consistent, the apps that don't follow this consistency (Libre office, Gimp, Firefox, Thunderbird, etc) are more common than the ones that do.
This was probably true 20 years ago but is not true today.
The majority of apps your average (non-HN) user uses is actually on their phone and not using the native UI widgets.
On their desktop they’re using apps like Spotify, Slack, and Microsoft Office or Google Docs.
The average user of today is not using a lot of native apps.
Users don't want the slack they get. They'd much rather have a slack client that integrates in their OS.
The main reason I get this Slack client that's the same across OSX, Ubuntu and Windows, is because the company doesn't want to spend time building three native apps. And that's understandable and perfectly fine.
But if it cost slack more time and effort to build a single app that runs on four platforms than it would cost them to build 4 that integrate into the platform, we'd get a native client within weeks.
I don’t know anyone who doesn’t hate these apps.
I care a lot if an app on my android suddenly opens an IOS date picker.
Because I don't care about date pickers. I don't care about how it looks. All I care about is picking a date and doing that fast.
But now I have to learn a -to me- unfamiliar interface, spend cognitive load on something unrelated to what I was trying to do (e.g. schedule a date with a friend)
Because () are optional and a function call can look like this Button { stuff }. Meanwhile in dart, it's lines, and lines and indentation of 2 because it becomes a massive manuscript. I hope that makes more sense.
I must have a very different understanding of the word "arguably" than you. To me, it's arguable whether Swift itself is a viable cross-platform language today. SwiftUI, on the other hand, supports literally zero devices not manufactured by Apple.
Is it really arguable that when people say "cross plaform" when referring to a GUI framework, they aren't counting "both macOS and iOS, but not any of Windows, Android, Linux, web"? It might be accurate from an pedantic standpoint, but I have trouble imagining a context where someone would bother using that phrase as a qualifier if they understood it that broadly.
I welcome this, I want to write cross platform lightweight UI applications without going to C or C++.
WPF is managed, only uses a bit of Win32 and DirectX 9, everything else is rendered by itself.
There are some details on what that exactly means, but I am on the go for lengthy comments.
Which itself is not used by Teams, which uses electron/WebView2, even though Teams is part of Office.
And let’s not forget about MAUI, which has its own components and UI library, which as far as I know is not used by anyone at Microsoft.
And I’ve heard from people at Microsoft that the future story of .NET UI framework is “Blazor WASM”. Is that considered native? Probably not. But I’d argue it should be considered “first party”.
Let’s be honest, Microsoft’s UI framework landscape is a mess.
Office framework would not exist without Win32, and usually it is made available on Win32, e.g. ribbon as common control.
Xamarin was never used at Microsoft, how to expect the rewrite to go any better. This acquisition was a mess, almost everything from Xamarin is gone.
Again, not a native API.
Blazor only matters for Web applications and PWAs, unless Windows turns into ChromeOS there is nothing native about it.
I give zero value to Blazor Hybrid, from my point of view it doesn't exist.
GPUI is not "native OS widgets".
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.
Accessibility falls under this: to my knowledge Cosmic has it, Iced does not.
What do you run your browser as?
Low.
What's the likelihood of someone entering your house if it's unlocked?
Also low, and yet you lock it.
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.
Then again I love zed so I might be biased.
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...
57 more comments available on Hacker News