Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • EGUI slaps. I'm interested in comparing it with GPUI too: That one gets immediate cred for being demonstrated in a responsive program that demonstrates the range of its complexity.

    EGUI bonus: Good integration with WGPU, so you can show 3D things as part of your UI.

    Complaining time: Historically, syncing winit, EGUI, WGPU, the binder between GPU and EGUI, and EGUI libs like for file dialogs has been a pain. It gives me anxiety thinking about upgrading versions. That said... the teams are sometimes shockingly fast about syncing their UIs. It is when winnit or WGPU etc make big breaking changes (Often from accumulation over time) where things get hairy!

  • While part of the Windows crate, I think windows-reactor deserves explicit mention.

    https://github.com/microsoft/windows-rs/tree/master/crates/s...

    It's a react-style API for WinUI3 apps, meaning it's not trying to mimic the Windows LAF. It's merely a binding.

  • I am heavily invested in Iced. I feel it's a good framework. On a number of occasions it forced me to rethink how to structure my program to match Iced's model. I find the framework very performant and the resulting program easy to prototype and expand upon. I don't do any web development at all, but if I had to, I'd check out Elm, knowing that Iced is inspired by it.

    Strengths:

      - Message passing model with separate Model and View paths
      - Async / Sync landscape (sync on the GUI thread, tasks / subscriptions for async stuff with messages returned to the GUI thread)
      - Writing custom Widgets is quite easy! In 0.14 stateful widgets got a revamp and they are quite nice
      - Performance is great
      - Despite being very capable, the framework is not that large. Learning it is not a daunting task
      - Documentation might be sparse, but due to how it's written, I was able to just read the code and understand how it works without issue
    
    Downsides include:

      - Lots of changes between releases (still pre 1.0)
      - Theming. Despite being (somewhat) recently reworked, it's still overcomplicated imo
      - The layouting engine is tricky to use and I fight with it much more than I should. Quite often widgets do not show up at all or take too much space because I didn't use the right combination of `Length` variants for `width` and `height` of the widget (and/or its children)
      - Some interfaces seem a bit weird (I am specifically thinking about overlays)
      - There is some confusion regarding what should go in the application state and what should be held in Widget's state. The interfaces are clearly defined here, but what can be / should be done is often found out in practice (perhaps I lack experience here)
  • I’ve been really impressed with GPUI, particularly with Longbridge’s open source component library which provides a bunch of shadcdn-alike widgets that are really well implemented and come with a bunch of tailwind-like helper functions that make layout easy.

    The downside is that the dependency stack you need to do gui programming with rust is massive and the compile times are brutal. You can’t beat the application performance, though. It’s crazy how nice it feels compared to bloated electron apps.

    The question of “are we gui yet” is definitely yes, at least on the desktop. The problem is that developers are too lazy to build apps with anything other than web frameworks.

  • I realize it's not a pure-Rust UI, but building with Tauri has been a joy. I recently built a GUI for one of my side projects and being able to use standard Typescript client-side development approaches, with a locked-down IPC, was surprisingly smooth. Love the "Wails-style" approach to a smaller release size than Electron as well.

    It's nice to be able to use existing design systems and components, and to be able to validate in a web browser in quicker build loops before doing the full Tauri builds. I still manually QA across platforms pretty aggressively but Tauri's "cross-platform from day one" really isn't much of a stretch. The project if curious: https://github.com/zecrocks/zkv

  • Building a GUI framework in Rust comes with certain challenges.

    Ralph Levien, author of druid and xilem made some good posts about it. I'll link one here.

    https://raphlinus.github.io/rust/gui/2022/07/15/next-dozen-g...

  • I also have a horse in this race, would love to have it included!

    I'm building Hypen (https://hypen.space), a UI framework with a DSL that works in in Rust, TS, Go, Kotlin, Swift, and all over the place, as long as you can use WASM or binaries.

    Some cool things about it:

    - Renders natively on Desktop, Web (DOM and Canvas), Android and iOS.

    - Streaming-first (SSR), so you can stream native apps from the server

    - Custom tailwind parser so it supports your favorite shorthands

    - Support for streaming apps from CF workers with 5 lines of JS/TS

    - You can embed any Hypen app into another Hypen app like its an iframe, with just 1 line of code

    - Has a custom "browser" for Hypen apps, both on desktop and on mobile, so you can easily check how your app looks anywhere

    - Coming soon - stdlib and WASI interface to enable full WASM portability across platforms

    Note: Desktop support is still a bit early and needs more crossplatform testing

    I started building this years ago, first manually, now accelerating it with LLM's which are incredible for mindnumbing tasks like writing frameworks like these requires. Its still in an "early alpha" but it's getting closer to maturity and a "stable beta" by the day, hopefully fully stable 1.0 by end of the year.

  • Throwing in my vote... I've been doing everything with wasm-bindgen/web-sys, i.e. just doing my UIs in html, and for 99% that's what I'd want anyways. Web UIs are portable, remotely accessible, and don't require installation on each client.

    For the small percent that's left where speed is critical, I've just been using wgpu and wgsl-bindgen directly.

    I can't think of what I'd want a native UI solution for. And then having to deal with porting it to iOS, Android, Windows, Mac etc, dealing with app stores (3+?) submissions, developer fees, rejections... vs just using HTML which works on all platforms. I don't think I'd use a native UI even if there was one. Not that HTML is great by any stretch...

    (I made Sunwet, this is what my stuff looks like: https://github.com/andrewbaxter/sunwet )

Explore Birbla archives