5 ms·

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 thei

• defraudbah 11mo ago
  [flagged]
• airstrike 11mo ago
  > The Rust UI scene is maturing, but the most popular options (iced, egui, dioxus, slint, etc.) aren't even the most complete component-wise atm as far as I can tell. I think part of the issue is that they're still changing so much as we speak. But there's real momentum here and n=1 but I've been able to build incredibly rich, enterprise-ready UI with Rust today.
  • nu11ptr 11mo ago
    > I've been able to build incredibly rich, enterprise-ready UI with Rust today. Which UI crate did you use? The word "enterprise" caught my eye. So far I haven't found a Rust UI crate that I found rich enough, so I'm curious your experience.
    • galangalalgol 11mo ago
      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.
      • nu11ptr 11mo ago
        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.
        • airstrike 11mo ago
          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'"
          • galangalalgol 11mo ago
            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.
          • andsoitis 11mo ago
            > 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.
            • 11mo ago
    • airstrike 11mo ago
      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.
      • nu11ptr 11mo ago
        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).
        • criticalfault 11mo ago
          Cosmic is built on iced, so you could look what they achieved.
        • chiffaa 11mo ago
          look into Cosmic Desktop and SniffNet as examples, both use Iced and IME are very high quality
        • airstrike 11mo ago
          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
    • Boxxed 11mo ago
      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.
      • airstrike 11mo ago
        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.
  • the__alchemist 11mo ago
    Same! I am building a structural biology CAD-like tool in Rust (EGUI + WGPU), and it's a great experience.
• nicce 11mo ago
  > 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 https://github.com/longbridge/gpui-component/tree/main/crate... > Just "cargo run --release" Very impressive! Only thing I am concerned over is that it uses around 900 dependencies. But I don't know whether it much for GUI applications.
  • nu11ptr 11mo ago
    That did seem excessive to me as well. I do worry about the DX of trying to work on an app with this. After each edit, I would expect a solid compile time to simply try your work.
    • nicoburns 11mo ago
      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/subsecond https://github.com/DioxusLabs/dioxus/tree/main/packages/subs...
      • nu11ptr 11mo ago
        > 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)
        • nicoburns 11mo ago
          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.
• matu3ba 11mo ago
  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 ?
  • wiz21c 11mo ago
    scheduling ??? what's that ? scheduling UI events ? Reversal computing ? What's that ? You meant reversible computing ?
    • matu3ba 11mo ago
      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 https://en.wikipedia.org/wiki/Reversible_computing and https://en.wikipedia.org/wiki/Time_reversibility https://en.wikipedia.org/wiki/Time_reversibility.
      • nathansobo 11mo ago
        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.
        • matu3ba 11mo ago
          Thanks. Sounds like a good developer experience attempt.
• swiftcoder 11mo ago
  > 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
  • rtfeldman 11mo ago
    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-powered-code-editor-built-from-scratch/ https://sequoiacap.com/article/partnering-with-zed-the-ai-po...
    • RMPR 11mo ago
      Iirc Cosmic Desktop uses Iced
      • embedding-shape 11mo ago
        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?
    • zemo 11mo ago
      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.)
  • michaelmior 11mo ago
• Buttons840 11mo ago
  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.
  • HelloNurse 11mo ago
    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?
    • Chris2048 11mo ago
      Perhaps you should read the comment again, your questions don't follow from it.
  • pie_flavor 11mo ago
    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.
  • deleted 11mo ago
    [deleted]
  • echelon 11mo ago
    > 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.
• the__alchemist 11mo ago
  In terms of its state now, how does it compare to EGUI?
• rayiner 11mo ago
  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!
• zaphirplane 11mo ago
  I’m so tempted to find out if Claude and friends can work with it, cause it’s new, rust and and unique
  • embedding-shape 11mo ago
    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.