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:
As of August 2025, Zed had 150K monthly active users. That was before it supported Windows; the number is much higher now (although not publicly reported).
I'd be very surprised to learn that any other Rust UI crate has more real-world usage than GPUI!
users is a finicky metric. When Palia came out, a game you most likely have never heard of, I wrote a desktop installer for it with Druid, which a few million people downloaded and used to install and run Palia. Only a handful of people worked on this codebase, maybe three or four while I was there, but principally me and one other engineer.
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 don't know that it's all that meaningful to discuss the component library as if it were its own UI framework. None of the other rust UI frameworks have distinct component libraries with distinct usage data either
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.
This is a bit of a microcosm of Rust OSS libs in general; the libraries that get the most PR, articles, popularity are often not the best ones. I see this in the rust embedded and GPGPU areas as well, for example.
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!
> Other people will then be able to use Bevy for actually 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.
> Bevy is just a very good, modern graphics tech demo, not something suitable for developing actual games.
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.
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.
I judge the viability of a game engine/framework based on its commercial success. This may be a bit harsh but the truth is that hobby game jams and games with complex gameplay features are two different kinds of games and the viability of Bevy for one does not automatically make it viable for the other. Bevy may be fun to use for a simple 30 minute platformer for a game jam, but try re-creating any of the big indie hits released in this year and you will quickly realize how much friction Bevy/Rust create. In fact, of all the 619 successful (>500 reviews) games released in 2025 on Steam, can you point out at least one of them made in either Bevy or Fyrox?
> you will quickly realize how much friction Bevy/Rust create
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.
I'm not sure what exactly you're expecting from a game engine that is not even yet six years from its first commit, but nevertheless - while it came out in 2024, not 2025, Tiny Glade[0] is built with Bevy.
I fail to see how that's particularly relevant, considering that this discussion started with the implication that ECS specifically is a neat fad that Bevy users will eventually get bored of.
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.
How is it misleading? Even Unity and Unreal games often have parts of the engine modified or replaced, e.g. swapping built-in audio for fmod/wwise or built-in physics for something in-house. Pounce Light has discussed the fact that it's primarily the renderer that they replaced[0], and they are not the first, nor will they be the last studio to use a custom renderer.
If your criteria for "made with Bevy" is "every single system in the game must be from Bevy", then sure, you won't find a single Bevy game in existence. But you will also find a lot fewer Unity and Unreal games than you think.
Tiny Glade is a great sandbox that must not have been easy to implement, game or not.
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.
There are two primary issues. In game development, for developing game features, iteration speed is the most important factor, you usually want a higher level scripting language in your game engine, so that a developer's workflow looks like this: make a simple change, hit a reload button, issue a few inputs, go back to the editor, make a simple change, repeat. Other popular game engines, more or less, solve this problem by providing a way to make gameplay features in a higher level language (GDScript in Godot, C# in Unity, BluePrints in Unreal Engine, often Lua with custom game engines), with Bevy, you make a change, and you rebuild the code, and often times, making a simple gameplay logic change (for a spell, an item, or some NPC interaction), will also change the ownership rules in case of Rust, because you may want to now access the same item mutably in two places or other things, and that requires you to restructure your simple script to appease the borrow checker, which also brings us to the second issue, in game development, a lot of bad practices, become good practices, take cyclic references for example, which are a common pattern in video games, in other lower level languages, or languages that allow embedding a higher level language, it's not that big of a deal, in Rust you have to do some shenenigans with things like RefCell<Vec<Rc<RefCell<Item>>>> which is simply not very ergonomic and adds a lot of development friction. A lot of people don't realize that game engine and gameplay programming are two vastly different things that have different requirements, and Rust is a poor fit for the latter.
Have you tried using Bevy? I have used it for some pretty non-trivial use-cases (not open source), and I have found that I did not have to use the typical "RefCell<Vec<Rc<RefCell<Item>>>>" stuff you talk about. There are paradigms in place for safe mutable access to the game state without jumping through hoops.
Of course you no longer have to actually try anything and give it a good-faith evaluation before criticising it. If it's different, then it de facto sucks.
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.
> in Rust you have to do some shenenigans with things like RefCell<Vec<Rc<RefCell<Item>>>> which is simply not very ergonomic
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.
What makes Fyrox better than Bevy? I don't think the hundred people commenting under every Bevy point release on HN are thinking of the ECS. It has features and it has tools and it has games.
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.
> 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.
> 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.
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.
The notion of shrink wrapped software dates us I think? But to that end, I have elements of so many different native looks jumbled around in my head all the way back to amiga workbench (deluxe paint was the best), that anything without really obvious flaws like off centered text or unresponsive buttons feels shrinkwrappable to me. By my standard any of these looks is enterprise ready. I remember someone at MS looking at a gui made by a team my friend was on and mocking it for looking like it was out of tron with saturated colors on a black background in high contrast instead of "modern" 3d grey buttons. It looked a lot more like the linked UI than anything MS was producing at the time. So there is the fashion aspect of it. You want to stand out, but not too much. I think that is the aspect I'm unable to judge. If everything is in the first or second place I look, I just won't care.
> I did mean "I can write/maintain a UI rich/polished
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 have built it. It hasn't existed for long enough for me to say I've maintained it for an extended period of time, but then again I did not claim that. Nor did I use the word "certain". There's no certainty in life.
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.
I used the `iced` framework and I can't link to it because it's not available to the general public yet.
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
I've had a lot of success with egui. We've needed to do some weird stuff and I've always been pleasantly surprised to see that the API is expressive enough that we're always able to work within the bounds of the library. Great documentation too.
I have a feeling iced would work similarly well but the documentation situation wasn't as good last I checked.
The issue with the documentation is a lack of guides or tutorials, but the crate is 100% documented and I think the examples cover 100% of what 90% of people need. Looking at other apps helps too.
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.
Cool. Any publicly available source code? If not, any screenshots at least? I'm curious as what Iced is capable of (with extra widgets/themes/etc. like you mentioned).
Unfortunately it's closed source and we're invite-only at this point so I can't share, but hopefully in a few weeks
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
> 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:
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.
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.
> The other thing you can do (which is popular in the Bevy community) is to compile the "core runtime" into dynamic library. Then you don't need to recompile that set of crates for incremental builds.
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)
An actual dynlib (containing the core framework crates that typically dont change between compiles (and which in C world might be installed as precompiled system libraries)).
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.
I did some quick research. I knew Rust ABI was unstable, but I didn't realize you could create Rust ABI dynlib and Rust would automatically dynamically link it. For intra-app it would work just fine. Neat. Link: https://stackoverflow.com/questions/75903098/dynamic-linking...
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.
Are talking about the "hotreloading" or the "hotpatching"? (There are two separate mechanisms) The hotreloading just does RSX and assets, and is very fast, the hotpatching is a recompile (no getting around compiling Rust code), but it should be a faster one, and in many cases it should be able to maintain application state.
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
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 ?
Scheduling means to generate enumerations/combinations of possible ui events. If interleaving events are possible and to what degree, then providing a notion of that and/or at least documentation would be helpful.
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 has a mature scheduling story, letting you “block” the main thread on spawned tasks with async/await. It also comes with a deterministic random test scheduler for driving out timing bugs.
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.
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!
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?
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)
> (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.
> 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.
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.
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.
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.
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.
> 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.
No, you would want to draw for Wayland or X. GTK and Qt themselves don't burden with importing each-other to work, for example.
My guess is that they import GTK only to get a title bar on GNOME, as GNOME forces applications to render their own. They could go custom and cut the dependency but it never looks quite right when apps do that.
No. On Wayland all of that should be in the compositor. Window sizing and positioning can not be done by the apps, so it makes sense that the controls for that are drawn and handled by the WM. But Gnomes gotta gnome...
Browser runs complex untrusted code from the internet. Most desktop programs don't do anything like that. The servo programmers were riding a motorbike. Using Rust for a desktop program would be more like wearing a crash helmet in a car.
No advantage to it. Worse quality code to gain what? A smaller number hiding ultimately the same amount of code? Also, since the unit of compilation is a crate, fewer opportunities for concurrent compiling.
A multitude of tiny dependencies has a multitude of solo maintainers, who eventually walk away, or sometimes get compromised.
A few big dependencies each have a team and a reputation that has earned trust and established release process and standards. If there's a serious problem in a small part of a big dependency, there are a few trusted maintainers of the big dependency who can be reached and can resolve it.
The theory of small dependencies was a good theory, 10 years ago when js devs using NPM started the trend of making them "as small as possible". But it really seems like the emergent pattern is the opposite of what is claimed. These JS and Rust projects end up taking longer to build and resulting in bigger outputs. Instead of a couple of "huge" 200KB dependencies, you end up with _thousands_ of 1KB dependencies including different versions and alternative implementations, you end up with megabytes of "accidental" code you don't really need.
And we can reason about why. In an ecosystem where something has 1 to 3 large deps, well sometimes a dependency pulls in another sub-dependency with code you don't need. But in an ecosystem where something has 10 to 100 deps, this still happens, but 50x more overall. It's a exponential trend: you have 3 big deps that each have 2 big deps that each have 1 big dep, vs you have 20 small deps that each have 15 small deps that each have 10 small deps.
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.
You can make use of Figma integration for something similar to Qt Design Studio.
Too many folks nowadays don't seem to fully understand how powerful GUI designers for native code used to be.
You always get some arguments about pixel perfect positioning, completly ignoring the fact most of them had layout managers available, even VB pre-VB.NET (yes Windows Forms does support layout managers).
The thing that irks me about slint is the use of the more restrictive GPLv3-only which prevents it from being incorporated into a project which is licensed GPLv3-or-later. I don't get why it is done like that.
GPLv4 could be the MIT license. GPLv3-or-later is a statement of arbitrary trust towards the FSF. Corporations serious about licensure, like SixtyFPS, aren't fans of that. (I don't think I've ever seen GPLv3-or-later in the wild from non-GNU/FSF software.)
Qt is LGPL 3. Slint is GPL 3. There is a massive difference there for a “library “
But to be fair to Slint, they do have a free proprietary license which can be used for developing proprietary applications as long as it’s not considers in the “embedded” space.
I think you misread the post you're replying to. GP is complaining about it being incompatible with "GPLv3-or-later" Free Software, not with commercial or permissive OSS.
GPLv3-or-later is currently almost the same as GPLv3-only at the moment given there is no GPLv4.
The reason why it's not possible to include GPLv3-only code in a GPLv3-or-later codebase is that the latter is more permissive, allowing the FSF to release an updated version of the GPL.
They won't make GPLv4 any less copyleft and more permissive than GPLv3, if they ever do make one. At worst, the GPLv4 will cause some commercial user of the code to be even more inconvenienced.
I just checked against Qt5 on ArchLinux. Core, GUI and Widget .so are all about 6mb each.
I concede that it's closer to 20mb after all but at the same time it's not a fair apples to apples comparison because those libraries provide you with so much more functionality than just the UI.
> because those libraries provide you with so much more functionality than just the UI.
Comparing GPUI to Qt based only on what they offer gui-wise is fair, in my opinion. What QtCore provides is sugar over C++: the object model, the signal system, some data types, many helpers. But the thing is, all of those things are in Rust already. They're even in modern C++.
So comparing a Qt hello world that uses QtCore+QtGUI+(QtQML|QtWidget) to a Rust GPUI hello world seems fair to me. It's not like the author also counted QtNetwork, QtSQL, QtSVG, QtHTML, etc.
I would think you could absolutely create something like that with a few steps on top of a relatively complete component library like linked.
You would probably want an xml/markup representation of component hierarchies, similar to other efforts, this can work with Rust with a macro interface that replaces the render hierarchy with the component structure format of this library. From there, you would need an application to hot-mount the same markup "live" as part of an interactive design tool.
In the end it wouldn't be much different than Glade, XAML or QT Designer. That said, you have to build a foundation before you can put solar panels on the roof.
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.
In my experience QT designer was awful to use. It’s probably fine if you are doing super vanilla layouts and widgets but as soon as my team started implementing custom css (or whatever the qt equivalent is called) things went off the rails. We pretty quickly abandoned to the tool completely to write the ui files by hand. They ended up much smaller and cleaner as a result. For some reason the designer seemed to add loads of unnecessary cruft.
So yea I can understand why they aren’t a priority.
That would seem odd.. the QSS is completely orthogonal to the code generated by the UI tool.
I accept that sometimes you need to some tricks with it and sometimes the layout in the preview is not the same you get at runtime which is annoying.
But in my UIs I use hundreds of widgets and I can't even begin to think about the useless effort required to write all the code by hand vs. spending seconds to drag and drop widgets into their place visually in the GUI editor...
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.
macOS is the only OS you can write native applications for. On Linux there are with GTK and QT two different GUI frameworks that could be considered native on some distros.
And on Windows there are so many different frameworks and approaches used by MS for the shell that even a Webview could be considered native
None of which is used by for example the Office team, which maintains their own UI Framework just for Office.
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.
That is marketing gimmicks trying to get additional market share, and the current adoption failure of MAUI customers, as teams leave Xamarin ecosystem after the Xamarin.Forms to MAUI (incompatible) rewrite.
I give zero value to Blazor Hybrid, from my point of view it doesn't exist.
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.
I write both swiftUI and flutter daily. I think SwiftUI is the winner if we're going to put names forward. But arguably, not cross platform. But in terms of language adaptability for UI, Swift is king.
> I think SwiftUI is the winner if we're going to put names forward. But arguably, not cross platform.
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 would say the opposite and it sounds like a personal preference at which point I think lack of cross platform compatibility ceases to anything else other than a major major problem.
I didn't explain myself well. The point I was trying to make is the language of Swift is far more flexible than Dart. And in terms of UI implementation, it then looks a lot more like a DSL.
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.
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.
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.
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
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.
Actually users think functionality is 1000x more important than what it looks like. Since making things look nice takes away dev time from functionality, what it looks like doesn't matter much (above some minimum expectation of course).
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)
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.
> 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.
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.
What you describe is an old and common problem with Microsoft Windows. Hell, even Windows applications built by microsoft itself, even within the same team, are inconsistent often.
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.
macOS doesn't have (many) consistency issues in the OS itself or first-party apps. But when it comes to the third-party apps people use? Totally inconsistent. Most of them are either webapps accessed through the browser (Google Docs), webapps accessed through Electron shells (Discord, Slack, Zoom, 1Password), or non-webapps that nevertheless have their own bespoke UI (Adobe, Microsoft Office, browsers themselves other than Safari). I'm not a fan of the situation, but that's the way it is.
I do fully admit these consistency issues were less bad in the past.
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.
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.
Thankfully on Macos x and Windows, the file picker isn't provided by the UI toolkit (though they usually provide abstract methods of calling it, for convenience).
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!
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.
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.
No mobile support. I get that a desktop UI framework doesn't want to target smartphones, but I think iPads (and bigger Android tablets) can cope well with more traditional desktop paradigms.
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.
Unfortunately, it's a framework. That is, it demands to own the event loop.
It has a type "Application" (This is Rust, don't get to say "it has a class Application, which you subclass", but that's how it works.)
That's fine for a cold start where you do everything their way, but tough
if there's already an event loop. egui, in contrast, is just a library crate which needs to be called on each frame.
This is really interesting. As a new Zed user, I've read about GPUI, but have no insights.
Coming from years of working with Qt, I'm always fascinated by the search for the "holy grail" of GUI libs. It's surprising how elusive a true "write-once-run-everywhere" solution (that's also good) still is.
My main question is about your long-term, cross-platform vision: How are you thinking about the matrix of Desktop, Web, and Embedded systems? Qt (for all its baggage) made a real run at desktop/embedded. Do you see GPUI components eventually covering all three, or is the focus purely on desktop/web for now?
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
A quick check with release build on macOS shows the component demo has a non-zero energy impact in the background (per activity monitor), but the input example has zero energy impact while in the background. This is already better than many new from-scratch UI libraries. The foreground impact is harder to measure.
Azul.rs is making lots of progress now and it'll have decent C / C++ / Python bindings (so it won't be Rust-only). But I guess for now GPUI is more mature.
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.
it happens to be my birthday today and this is one hell of a birthday present right now. been itching to dive into making a desktop app in rust and this looks amazing!
Really interesting, and look forward to playing with it
However I find it bizarre that in the comparison table, Qt’s licensing is described as “Commercial”. Yes Qt is available under a commercial license but it’s also available under LGPL 3.
Yes that means you can even build proprietary applications linking against the LGPL license.
That makes that table misleading and borderline FUD.
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).
> 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.
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"
> but unfortunately has almost no usage
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
As of August 2025, Zed had 150K monthly active users. That was before it supported Windows; the number is much higher now (although not publicly reported).
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...
users is a finicky metric. When Palia came out, a game you most likely have never heard of, I wrote a desktop installer for it with Druid, which a few million people downloaded and used to install and run Palia. Only a handful of people worked on this codebase, maybe three or four while I was there, but principally me and one other engineer.
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.)
Iirc Cosmic Desktop uses Iced
Kraken seems to have a desktop application for trading made in Iced as well.
I wonder if there are more Cosmic Desktop + Kraken desktop users than Zed Editor users?
Oh thats why it looked so familiar.
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.
GPUI yes, but I'm not so sure about GPUI Component which is what I assumed the parent was talking about.
I don't know that it's all that meaningful to discuss the component library as if it were its own UI framework. None of the other rust UI frameworks have distinct component libraries with distinct usage data either
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.
This is a bit of a microcosm of Rust OSS libs in general; the libraries that get the most PR, articles, popularity are often not the best ones. I see this in the rust embedded and GPGPU areas as well, for example.
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!
That's OK though. Other people will then be able to use Bevy for actually making a game.
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.
> Other people will then be able to use Bevy for actually 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.
> Bevy is just a very good, modern graphics tech demo, not something suitable for developing actual games.
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.
> Nobody makes games in Bevy though
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.
I judge the viability of a game engine/framework based on its commercial success. This may be a bit harsh but the truth is that hobby game jams and games with complex gameplay features are two different kinds of games and the viability of Bevy for one does not automatically make it viable for the other. Bevy may be fun to use for a simple 30 minute platformer for a game jam, but try re-creating any of the big indie hits released in this year and you will quickly realize how much friction Bevy/Rust create. In fact, of all the 619 successful (>500 reviews) games released in 2025 on Steam, can you point out at least one of them made in either Bevy or Fyrox?
https://steamdb.info/stats/gameratings/2025/?min_reviews=500...
> you will quickly realize how much friction Bevy/Rust create
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.
I'm not sure what exactly you're expecting from a game engine that is not even yet six years from its first commit, but nevertheless - while it came out in 2024, not 2025, Tiny Glade[0] is built with Bevy.
https://steamdb.info/app/2198150/
Only the ECS.
I fail to see how that's particularly relevant, considering that this discussion started with the implication that ECS specifically is a neat fad that Bevy users will eventually get bored of.
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.
It's relevant because the post I replied to is misleading on its own.
How is it misleading? Even Unity and Unreal games often have parts of the engine modified or replaced, e.g. swapping built-in audio for fmod/wwise or built-in physics for something in-house. Pounce Light has discussed the fact that it's primarily the renderer that they replaced[0], and they are not the first, nor will they be the last studio to use a custom renderer.
If your criteria for "made with Bevy" is "every single system in the game must be from Bevy", then sure, you won't find a single Bevy game in existence. But you will also find a lot fewer Unity and Unreal games than you think.
0. https://80.lv/articles/exclusive-tiny-glade-developers-discu...
Tiny Glade is a great sandbox that must not have been easy to implement, game or not.
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.
Why? What does Bevy lack?
There are two primary issues. In game development, for developing game features, iteration speed is the most important factor, you usually want a higher level scripting language in your game engine, so that a developer's workflow looks like this: make a simple change, hit a reload button, issue a few inputs, go back to the editor, make a simple change, repeat. Other popular game engines, more or less, solve this problem by providing a way to make gameplay features in a higher level language (GDScript in Godot, C# in Unity, BluePrints in Unreal Engine, often Lua with custom game engines), with Bevy, you make a change, and you rebuild the code, and often times, making a simple gameplay logic change (for a spell, an item, or some NPC interaction), will also change the ownership rules in case of Rust, because you may want to now access the same item mutably in two places or other things, and that requires you to restructure your simple script to appease the borrow checker, which also brings us to the second issue, in game development, a lot of bad practices, become good practices, take cyclic references for example, which are a common pattern in video games, in other lower level languages, or languages that allow embedding a higher level language, it's not that big of a deal, in Rust you have to do some shenenigans with things like RefCell<Vec<Rc<RefCell<Item>>>> which is simply not very ergonomic and adds a lot of development friction. A lot of people don't realize that game engine and gameplay programming are two vastly different things that have different requirements, and Rust is a poor fit for the latter.
Have you tried using Bevy? I have used it for some pretty non-trivial use-cases (not open source), and I have found that I did not have to use the typical "RefCell<Vec<Rc<RefCell<Item>>>>" stuff you talk about. There are paradigms in place for safe mutable access to the game state without jumping through hoops.
Of course you no longer have to actually try anything and give it a good-faith evaluation before criticising it. If it's different, then it de facto sucks.
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.
> in Rust you have to do some shenenigans with things like RefCell<Vec<Rc<RefCell<Item>>>> which is simply not very ergonomic
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.
> because Fyrox appears to be the most mature Rust game engine, but nobody uses it or cares about it.
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.
What makes Fyrox better than Bevy? I don't think the hundred people commenting under every Bevy point release on HN are thinking of the ECS. It has features and it has tools and it has games.
ECS hype and the traditional make a game/make an engine dilemma shouldn't be considered reasons to avoid the Fyrox library (or other Rust projects).
Are you trying to tell something more logical? Does the "Rust gamedev scene" affect the technical merits of libraries?
Perhaps you should read the comment again, your questions don't follow from it.
For better or for worse fyrox is not something too novel/new. So people don't really see a reason to use it over godot or other engines.
Doesn't mean bevy is better or anything, just that because it's so different people tend to flock to it.
I mean I get this in theory.
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.
> 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.
> 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.
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.
Ahh, gotcha. Yeah "enterprise" to me meant: "I can write/maintain a UI rich/polished enough to pass as a 'shrink wrapped' app to my end users".
Thanks for the reply.
FWIW that reply was from a different person :D
In my case I did mean "I can write/maintain a UI rich/polished enough to pass as a 'shrink wrapped'"
The notion of shrink wrapped software dates us I think? But to that end, I have elements of so many different native looks jumbled around in my head all the way back to amiga workbench (deluxe paint was the best), that anything without really obvious flaws like off centered text or unresponsive buttons feels shrinkwrappable to me. By my standard any of these looks is enterprise ready. I remember someone at MS looking at a gui made by a team my friend was on and mocking it for looking like it was out of tron with saturated colors on a black background in high contrast instead of "modern" 3d grey buttons. It looked a lot more like the linked UI than anything MS was producing at the time. So there is the fashion aspect of it. You want to stand out, but not too much. I think that is the aspect I'm unable to judge. If everything is in the first or second place I look, I just won't care.
> I did mean "I can write/maintain a UI rich/polished
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 have built it. It hasn't existed for long enough for me to say I've maintained it for an extended period of time, but then again I did not claim that. Nor did I use the word "certain". There's no certainty in life.
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.
Can you provide more details? Links to the implementation of available? Framework you used? Pain points?
I used the `iced` framework and I can't link to it because it's not available to the general public yet.
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've had a lot of success with egui. We've needed to do some weird stuff and I've always been pleasantly surprised to see that the API is expressive enough that we're always able to work within the bounds of the library. Great documentation too.
I have a feeling iced would work similarly well but the documentation situation wasn't as good last I checked.
The issue with the documentation is a lack of guides or tutorials, but the crate is 100% documented and I think the examples cover 100% of what 90% of people need. Looking at other apps helps too.
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.
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.
Cool. Any publicly available source code? If not, any screenshots at least? I'm curious as what Iced is capable of (with extra widgets/themes/etc. like you mentioned).
Unfortunately it's closed source and we're invite-only at this point so I can't share, but hopefully in a few weeks
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
Cosmic is built on iced, so you could look what they achieved.
look into Cosmic Desktop and SniffNet as examples, both use Iced and IME are very high quality
Same! I am building a structural biology CAD-like tool in Rust (EGUI + WGPU), and it's a great experience.
> 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.
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.
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...
> The other thing you can do (which is popular in the Bevy community) is to compile the "core runtime" into dynamic library. Then you don't need to recompile that set of crates for incremental builds.
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)
An actual dynlib (containing the core framework crates that typically dont change between compiles (and which in C world might be installed as precompiled system libraries)).
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.
I did some quick research. I knew Rust ABI was unstable, but I didn't realize you could create Rust ABI dynlib and Rust would automatically dynamically link it. For intra-app it would work just fine. Neat. Link: https://stackoverflow.com/questions/75903098/dynamic-linking...
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 don't see what advantage this gives
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.
Even in Dioxus the usefulness is somewhat limited right now though.
(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.
Are talking about the "hotreloading" or the "hotpatching"? (There are two separate mechanisms) The hotreloading just does RSX and assets, and is very fast, the hotpatching is a recompile (no getting around compiling Rust code), but it should be a faster one, and in many cases it should be able to maintain application state.
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
Ah, thanks for the hint.
I indeed was not enabling it.
I'll give it a try!
Incremental compiles should be fast.
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 ?
scheduling ??? what's that ? scheduling UI events ? Reversal computing ? What's that ? You meant reversible computing ?
Scheduling means to generate enumerations/combinations of possible ui events. If interleaving events are possible and to what degree, then providing a notion of that and/or at least documentation would be helpful.
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 has a mature scheduling story, letting you “block” the main thread on spawned tasks with async/await. It also comes with a deterministic random test scheduler for driving out timing bugs.
Thanks. Sounds like a good developer experience attempt.
I downloaded the Longbride app they made with it. It looks like a real application! Fits in pretty well on Mac. Runs much more smoothly than Electron!
I’m so tempted to find out if Claude and friends can work with it, cause it’s new, rust and and unique
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.
In terms of its state now, how does it compare to EGUI?
[flagged]
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!
gpui itself is maintained by the folks at https://zed.dev.
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/
zed looks nice, but I am going to wait until the American port to use it.
May I ask what you mean by this? For all I know, Zed Industries Inc is incorporated in the US and funded by US venture capital.
BTW, I am not associated with zed in any way.
Its a stupid joke. Americans say Z==Zee, rest of the Anglosphere says Z==Zed
Thanks for the explanation :)
[dead]
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)
> (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.
> 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.
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 doubt that a lot of it is.
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.
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.
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.
> 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.
No, you would want to draw for Wayland or X. GTK and Qt themselves don't burden with importing each-other to work, for example.
My guess is that they import GTK only to get a title bar on GNOME, as GNOME forces applications to render their own. They could go custom and cut the dependency but it never looks quite right when apps do that.
No. On Wayland all of that should be in the compositor. Window sizing and positioning can not be done by the apps, so it makes sense that the controls for that are drawn and handled by the WM. But Gnomes gotta gnome...
Are GTK/Qt memory safe now?
No. What is the likelihood of an attack on a desktop program via memory unsafety?
Really high?
What do you run your browser as?
Browser runs complex untrusted code from the internet. Most desktop programs don't do anything like that. The servo programmers were riding a motorbike. Using Rust for a desktop program would be more like wearing a crash helmet in a car.
>What is the likelihood of an attack on a desktop program via memory unsafety?
Low.
What's the likelihood of someone entering your house if it's unlocked?
Also low, and yet you lock it.
A desktop program is already in a locked house - your desktop - which I can't login to.
[flagged]
Do all desktop programs only ever run in "your house"?
Such is sadly increasingly the way with Rust projects.
Would you rather have 1000 small, composable, auditable dependencies or the same amount of code in a monolithic dump of .hpp files?
How about a few large dependencies and no little ones?
No advantage to it. Worse quality code to gain what? A smaller number hiding ultimately the same amount of code? Also, since the unit of compilation is a crate, fewer opportunities for concurrent compiling.
A multitude of tiny dependencies has a multitude of solo maintainers, who eventually walk away, or sometimes get compromised.
A few big dependencies each have a team and a reputation that has earned trust and established release process and standards. If there's a serious problem in a small part of a big dependency, there are a few trusted maintainers of the big dependency who can be reached and can resolve it.
The theory of small dependencies was a good theory, 10 years ago when js devs using NPM started the trend of making them "as small as possible". But it really seems like the emergent pattern is the opposite of what is claimed. These JS and Rust projects end up taking longer to build and resulting in bigger outputs. Instead of a couple of "huge" 200KB dependencies, you end up with _thousands_ of 1KB dependencies including different versions and alternative implementations, you end up with megabytes of "accidental" code you don't really need.
And we can reason about why. In an ecosystem where something has 1 to 3 large deps, well sometimes a dependency pulls in another sub-dependency with code you don't need. But in an ecosystem where something has 10 to 100 deps, this still happens, but 50x more overall. It's a exponential trend: you have 3 big deps that each have 2 big deps that each have 1 big dep, vs you have 20 small deps that each have 15 small deps that each have 10 small deps.
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.
They do, but you have to look into the right ones, from ex-Qt employees,
https://slint.dev/
You can make use of Figma integration for something similar to Qt Design Studio.
Too many folks nowadays don't seem to fully understand how powerful GUI designers for native code used to be.
You always get some arguments about pixel perfect positioning, completly ignoring the fact most of them had layout managers available, even VB pre-VB.NET (yes Windows Forms does support layout managers).
The thing that irks me about slint is the use of the more restrictive GPLv3-only which prevents it from being incorporated into a project which is licensed GPLv3-or-later. I don't get why it is done like that.
GPLv4 could be the MIT license. GPLv3-or-later is a statement of arbitrary trust towards the FSF. Corporations serious about licensure, like SixtyFPS, aren't fans of that. (I don't think I've ever seen GPLv3-or-later in the wild from non-GNU/FSF software.)
GPLv3-or-later is pretty commonplace in the world of free software even outside of GNU stuff.
Easy, similar to Qt.
Don't want to pay upstream? Also don't get to charge money.
Want to pay up stream? Another license can be arranged where both parties get to earn money.
Qt is LGPL 3. Slint is GPL 3. There is a massive difference there for a “library “
But to be fair to Slint, they do have a free proprietary license which can be used for developing proprietary applications as long as it’s not considers in the “embedded” space.
I think you misread the post you're replying to. GP is complaining about it being incompatible with "GPLv3-or-later" Free Software, not with commercial or permissive OSS.
Yes, and being incompatible with GPLv3-or-later may be done on purpose to push folks into a commercial license.
GPLv3-or-later is currently almost the same as GPLv3-only at the moment given there is no GPLv4.
The reason why it's not possible to include GPLv3-only code in a GPLv3-or-later codebase is that the latter is more permissive, allowing the FSF to release an updated version of the GPL.
They won't make GPLv4 any less copyleft and more permissive than GPLv3, if they ever do make one. At worst, the GPLv4 will cause some commercial user of the code to be even more inconvenienced.
You can freely charge money with either GPLv3-only or GPLv3-or-later.
I am not asking them to remove GPLv3-only and replace it with MIT, I am asking them to use GPLv3-or-later.
> * 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.
In my experience that point is absolutely correct. Qt is good but big. You usually end up with 30-40MB of it.
Core, Gui, QML, Widget are 8MB each. For a Hello World you need 3 of those. Maybe 2.
Yes you could build Qt yourself with various flags, or possibly do a static build with LTO might help. But that's not the typical way Qt is used.
Yes and no.
I just checked against Qt5 on ArchLinux. Core, GUI and Widget .so are all about 6mb each.
I concede that it's closer to 20mb after all but at the same time it's not a fair apples to apples comparison because those libraries provide you with so much more functionality than just the UI.
> because those libraries provide you with so much more functionality than just the UI.
Comparing GPUI to Qt based only on what they offer gui-wise is fair, in my opinion. What QtCore provides is sugar over C++: the object model, the signal system, some data types, many helpers. But the thing is, all of those things are in Rust already. They're even in modern C++.
So comparing a Qt hello world that uses QtCore+QtGUI+(QtQML|QtWidget) to a Rust GPUI hello world seems fair to me. It's not like the author also counted QtNetwork, QtSQL, QtSVG, QtHTML, etc.
I would think you could absolutely create something like that with a few steps on top of a relatively complete component library like linked.
You would probably want an xml/markup representation of component hierarchies, similar to other efforts, this can work with Rust with a macro interface that replaces the render hierarchy with the component structure format of this library. From there, you would need an application to hot-mount the same markup "live" as part of an interactive design tool.
In the end it wouldn't be much different than Glade, XAML or QT Designer. That said, you have to build a foundation before you can put solar panels on the roof.
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.
They also note that Qt6 is not themeable which is completely wrong.
In my experience QT designer was awful to use. It’s probably fine if you are doing super vanilla layouts and widgets but as soon as my team started implementing custom css (or whatever the qt equivalent is called) things went off the rails. We pretty quickly abandoned to the tool completely to write the ui files by hand. They ended up much smaller and cleaner as a result. For some reason the designer seemed to add loads of unnecessary cruft.
So yea I can understand why they aren’t a priority.
That would seem odd.. the QSS is completely orthogonal to the code generated by the UI tool.
I accept that sometimes you need to some tricks with it and sometimes the layout in the preview is not the same you get at runtime which is annoying.
But in my UIs I use hundreds of widgets and I can't even begin to think about the useless effort required to write all the code by hand vs. spending seconds to drag and drop widgets into their place visually in the GUI editor...
WYSIWG and code are almost always if not always not done well together.
Looks great for those using Rust - however I do wonder how well this works, if at all, under screen readers and other accessible tech?
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.
Zed Editor (built on top of GPUI) is opaque to screen readers, so I wouldn't have high hopes.
my #1 question each time I see a new UI framework
"Let's get the volume first, then worry about accessibility"
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.
Accessibility is apart of gpui roadmap.
> Unfortunately, unless you bake it in from day #1 that's not so simple to fix afterwards.
at least I think egui has worked on that aspect...
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.
macOS is the only OS you can write native applications for. On Linux there are with GTK and QT two different GUI frameworks that could be considered native on some distros. And on Windows there are so many different frameworks and approaches used by MS for the shell that even a Webview could be considered native
Win32 is the native way, MFC and Windows Forms build on top Win32, UWP is also native as thin layer above Win32 and COM (with some extras).
WPF is managed, only uses a bit of Win32 and DirectX 9, everything else is rendered by itself.
According to Microsoft WinUi3 and WinUi2 are also native https://learn.microsoft.com/en-us/windows/apps/winui/
Naturally, they build on top of UWP.
There are some details on what that exactly means, but I am on the go for lengthy comments.
None of which is used by for example the Office team, which maintains their own UI Framework just for Office.
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.
Moving goalposts, the point was what are the native APIs.
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.
Blazor is only for web applications, until you run into Blazor Hybrid, which doesn’t produce web applications!
That is marketing gimmicks trying to get additional market share, and the current adoption failure of MAUI customers, as teams leave Xamarin ecosystem after the Xamarin.Forms to MAUI (incompatible) rewrite.
I give zero value to Blazor Hybrid, from my point of view it doesn't exist.
On macOS you now have to account for SwiftUI, which sometimes uses AppKit views and sometimes uses its own renderer. Kind of similar to UWP.
iOS and Android definitely have native toolkits too.
Pretty sure native as in "not web". AFAIK, everything is drawn using the various GPU APIs (GPUI started with Metal on macOS, for example).
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.
I write both swiftUI and flutter daily. I think SwiftUI is the winner if we're going to put names forward. But arguably, not cross platform. But in terms of language adaptability for UI, Swift is king.
> I think SwiftUI is the winner if we're going to put names forward. But arguably, not cross platform.
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 would say the opposite and it sounds like a personal preference at which point I think lack of cross platform compatibility ceases to anything else other than a major major problem.
I didn't explain myself well. The point I was trying to make is the language of Swift is far more flexible than Dart. And in terms of UI implementation, it then looks a lot more like a DSL.
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.
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.
Yeah but sometimes you don't want to write connectors between high performance code and convenient to use UI code.
I welcome this, I want to write cross platform lightweight UI applications without going to C or C++.
I think it's native as in "native executable".
GPUI is not "native OS widgets".
Native as in "not web". No OS integration.
Does this implement accessibility at all?
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.
Not really.
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.
System76 runs their own fork of Iced and commits things back to Iced, but in practice this hasn’t been as much as people seem to think.
Accessibility falls under this: to my knowledge Cosmic has it, Iced does not.
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.
Yes
Virtualized lists and tables are amazing!
So many UI frameworks don't have these and require building them yourself...
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
1: https://docs.rs/rfd/latest/rfd/
> 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.
Emacs, which still uses CUI-incompatible keybindings and even key names from a keyboard that hasn't been made since the 01980s.
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.
> E.g. categories like "expert software"
As pointed out.
Actually users think functionality is 1000x more important than what it looks like. Since making things look nice takes away dev time from functionality, what it looks like doesn't matter much (above some minimum expectation of course).
Not entirely.
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)
> But for them consistent means consistent with the 20+ other applications they use on a daily base. So native.
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.
I still want native apps (including proper OS Integration) even though I don't get them.
Indeed.
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.
> On their desktop they’re using apps like Spotify, Slack, and Microsoft Office or Google Docs
I don’t know anyone who doesn’t hate these apps.
> 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.
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.
What you describe is an old and common problem with Microsoft Windows. Hell, even Windows applications built by microsoft itself, even within the same team, are inconsistent often.
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.
> Maybe it's different in MacOS land
It is. Windows has always had consistency issues; macOS hasn't.
macOS doesn't have (many) consistency issues in the OS itself or first-party apps. But when it comes to the third-party apps people use? Totally inconsistent. Most of them are either webapps accessed through the browser (Google Docs), webapps accessed through Electron shells (Discord, Slack, Zoom, 1Password), or non-webapps that nevertheless have their own bespoke UI (Adobe, Microsoft Office, browsers themselves other than Safari). I'm not a fan of the situation, but that's the way it is.
I do fully admit these consistency issues were less bad in the past.
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.
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.
Thankfully on Macos x and Windows, the file picker isn't provided by the UI toolkit (though they usually provide abstract methods of calling it, for convenience).
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!
You should always use the native file picker and not shipping your own. That’s a good thing.
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.
Are any pieces of this open source by chance? (other than iced itself)
Unfortunately not
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.
[1]: https://longbridge.com/desktop/
I guess they expect that most people come there from the top level domain. (https://longbridge.com)
"Multi-platform Support, Professional Market Monitoring" imho is a good explanation
No mobile support. I get that a desktop UI framework doesn't want to target smartphones, but I think iPads (and bigger Android tablets) can cope well with more traditional desktop paradigms.
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.
Unfortunately, it's a framework. That is, it demands to own the event loop. It has a type "Application" (This is Rust, don't get to say "it has a class Application, which you subclass", but that's how it works.) That's fine for a cold start where you do everything their way, but tough if there's already an event loop. egui, in contrast, is just a library crate which needs to be called on each frame.
This is really interesting. As a new Zed user, I've read about GPUI, but have no insights.
Coming from years of working with Qt, I'm always fascinated by the search for the "holy grail" of GUI libs. It's surprising how elusive a true "write-once-run-everywhere" solution (that's also good) still is.
My main question is about your long-term, cross-platform vision: How are you thinking about the matrix of Desktop, Web, and Embedded systems? Qt (for all its baggage) made a real run at desktop/embedded. Do you see GPUI components eventually covering all three, or is the focus purely on desktop/web for now?
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
A quick check with release build on macOS shows the component demo has a non-zero energy impact in the background (per activity monitor), but the input example has zero energy impact while in the background. This is already better than many new from-scratch UI libraries. The foreground impact is harder to measure.
2 hours after it's posted on HN, the repo has its first "readme.md typo fix" commit.
It's interesting to see more people building on top of GPUI. I recently also saw https://github.com/Augani/adabraka-ui which looks fairly similar.
This looks great too! Hopefully one or more of these component libraries catch on and stay well maintained.
Sad to see that the C++ community is sleeping on this. There are no modern GUI components or toolkits, specially under such a permissive license.
Excited about the future of Rust GUI development, this is fantastic.
> Sad to see that the C++ community is sleeping on this. There are no modern GUI components or toolkits, specially under such a permissive license.
I'm not sure what you are talking about (there are plenty of x-platform C++ GUI toolkits with components). Maybe you mean "accelerated toolkits"?
Qt is modern enough, still there are hardly any Rust libraries as feature rich in capabilities and designer related tooling.
It is also the KDE infrastructure, used in plenty of infotaiment, factory dashboards and medical devices.
Azul.rs is making lots of progress now and it'll have decent C / C++ / Python bindings (so it won't be Rust-only). But I guess for now GPUI is more mature.
I was expecting something ugly but these actually look beautiful!
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.
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.
A link to toolkit (GPUI) since I don't see it mentioned... https://www.gpui.rs/
So how would it work on Linux let's say, it would need its own theming to match system look and feel of existing DE?
It does look pretty solid, but whenever I’m building a desktop app with Rust, Tauri is always the first thing that comes to mind.
So how stupid am I for asking how long it is before this is available in the browser and all the DOM behavior is WASM?
Hola, finally a good rust ui framework that's not dependent on web
You mean outside iced, slint, egui, etc. ?
it happens to be my birthday today and this is one hell of a birthday present right now. been itching to dive into making a desktop app in rust and this looks amazing!
Really interesting, and look forward to playing with it
However I find it bizarre that in the comparison table, Qt’s licensing is described as “Commercial”. Yes Qt is available under a commercial license but it’s also available under LGPL 3.
Yes that means you can even build proprietary applications linking against the LGPL license.
That makes that table misleading and borderline FUD.
Why is the average binary size 10MB? Does it embed ICU data?
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).
> 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...
Does it support app development in other languages?
very nice ! what about tauri versus this compoments ?
Tauri uses a WebView to render the UI, GPUI uses (DirectX, Metal, Vulkan) directly to render the UI... Blazingly Fast hehe.
Now that we can do a nice toolbar and components, somebody please make a document canvas control so we can make a decent office suite.
Ah yes, a GUI component landing page with no pictures. Makes it tricky to imagine what the GUI looks like
good job !!!!
[dead]
[flagged]