Rust cross-platform GPUI components
201–210 of 225 posts
Re: Rust cross-platform GPUI components
#202very nice ! what about tauri versus this compoments ?
Re: Rust cross-platform GPUI components
#203Earlier quoted context omitted.
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 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.
Re: Rust cross-platform GPUI components
#204Earlier quoted context omitted.
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 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.
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.
Re: Rust cross-platform GPUI components
#205Earlier quoted context omitted.
> 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...
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.)
Re: Rust cross-platform GPUI components
#206This 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
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.
Re: Rust cross-platform GPUI components
#207Re: Rust cross-platform GPUI components
#208Earlier quoted context omitted.
> 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 don’t know anyone who doesn’t hate these apps.
Re: Rust cross-platform GPUI components
#209Re: Rust cross-platform GPUI components
#210Earlier quoted context omitted.
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 U…
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.