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…
> 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!
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…
"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.
at least I think egui has worked on that aspect...
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.
Such is sadly increasingly the way with Rust projects.
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
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.
> 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…
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>>> 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.
> 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 "e…
> 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…
> Maybe it's different in MacOS land
It is. Windows has always had consistency issues; macOS hasn't.
> 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 "e…
> 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…
I still want native apps (including proper OS Integration) even though I don't get them.
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…
> 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.
> * 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 stati…
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.