Birbla

Join the discussion

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

Sign in
  • Hacker News
  • To extend this, what's the state of accessibility for user interfaces built in Rust?
    by DASD
  • egui has native accesskit support
    by generalenvelope
  • Many libraries now support AccessKit.
    by Levitating
  • The main frameworks with traction like Slint UI, egui, tauri, and Dioxus all have baseline accessibility support
    by jordand
  • #1 thing helping me with GUI Rust is sccache for crate compilation caching. and #2 is building independent-compilable subcrates. This improves build times by 10x.

    Also shoutout to ratatui because even though it's technically a TUI not GUI, it's superb.

    by jph
  • I also wanted to shout out https://ratatui.rs/.

    Most of the time, I just want some UI. And TUI's are easier / more portable than GUI's.

    by hazkoulia
  • It really looks cool, but creating JUST a simple damn button is a nightmare. Tabs, layout, fine, but you just want a button. nope.
    by evereverever
  • It's great!

    But even though the title of this HN post is wrong, everything else is titled/domained to say that it's about GUIs.

    TUIs are great! You can run them on a server, inside a tmux/screen, they don't require a browser or a virtual desktop.

    Some things are obviously better as a graphical web app. With WASM I'm less sure that a GUI that is not just a browser app is worth it.

    But I'm not a frontend developer, really.

    I have a project that requires a GUI. I made it in WASM to run in the browser, and it can decode data packets over radio in real time, while showing fancy visualizations: https://youtu.be/7k0JNT6itaI. 99% of that runs in the browser. Only the RTL-SDR streaming is native.

    For my purposes it seems WASM is not performant enough, though, and I'll have to shift more DSP to the server side of the streaming, leaving the UI with just the UI parts.

    But I also have some TUI UI code. So much simpler to run remotely, then. No TLS certificates, webserver, etc. Just SSH in and attach to the tmux and see spectrums and graphs with "good enough" dot resolution.

    by thomashabets2
  • I’m not well-versed in Rust, but as far as I’m aware there’s a somewhat low hard cap on how ergonomic a fully Rust “old style” imperative OO UI framework (like AppKit/UIKit) can be, which is unfortunate as I find that style easiest to work with for complex desktop apps.

    I wish there were more memory safe compiled languages that focused on ergonomics for cases like this.

    by cosmic_cheese
  • What makes you say that exactly?
    by nixpulvis
  • One of the reasons I started messing around with Zig.
    by TheMagicHorsey
  • Rust doesn't play well with traditional frameworks but works fairly well with Elm and immediate mode.
    by Levitating
  • 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!

    by the__alchemist
  • > It is when winnit or WGPU etc make big breaking changes (Often from accumulation over time) where things get hairy!

    Winit has had so much churn over time, I hope they settle down at some point.

    I can pretty much guarantee that if I try to build a project from 3+ years ago, the old version of winit will not compile on my Mac, and the new version of winit will have a completely different API surface.

    by swiftcoder
  • The wgpu/winit/egui churn is a headache. It's worse if you're doing 3D work. Too many crates want to own the event loop. "We're a framework now!"

    I'm dreading the "upgrade" from wgpu 24 to wgpu 29. I stayed with wgpu 24 for a year so I could get work done. Now I have to fix three programs and all their tests and examples.

    by Animats
  • 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.

    by OptionOfT
  • Docs: https://github.com/microsoft/windows-rs/blob/master/docs/rea...
    by fbilhaut
  • I would approach anything windows-rs with care, the team is the one responsible for killing C++/CX in name of C++/WinRT, and then leaving it half baked to go play with Rust and windows-rs.

    Nothing they said on stage at CppCon 2017 came to fruition.

    You're better off doing the UI in WPF and calling into Rust DLLs.

    by pjmlp
  • 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)
    by neonstatic
  • 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.

    by segphault
  • GPUI doesn't have accessibility support and isn't even targeted for anything but the text editor, so it's a definite "not yet"
    by eviks
  • This is great. In recent years the Rust has been talked about so much in regards to the web . It us getting better and more technologies are being developed tk further this. I am very impressed in what im seeing now. There are some amazing techniques.
    by mahirsaid
  • I’ve been using GPUI in a side project of mine (TukeySheets.com) and can attest that it is quite nice and it works well on all platforms, at least in my experience. So I would say, definitely “we are gui” in rust.

    The component library by long bridge is also well done and reasonably well documented.

    by ktukey
  • GPUI is truly awesome.

    Check out: https://github.com/longbridge/gpui-component

    by victor106
  • For me it's not so much laziness, as more of a lack of desire to rely on a framework that Zed core team still feels to be not ready for a general release. Electron just happens to be the least worst way to make an aesthetically pleasing cross-platform desktop app, but the performance trade-off is a major pain point.

    GPUI getting the public release greenlight will no doubt be a turning point for desktop GUI development. All it took is a small team of gifted developers to dogfood their own GUI toolkit and get some much-needed VC backing. The future looks very bright.

    by vovavili
  • GPUI is developed alongside Zed and thus features that aren't useful for Zed are sometimes left behind.

    I think there was a community fork recently that tried to tend to these concerns.

    It's not a bad thing per se, but its worth mentioning.

    by Levitating
  • 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

    by buildbuildbuild
  • The issue with tauri is handling big blobs, you either have to serialize them between processes or serve them to the webview via tcp. Albeit dangerous if done wrong, Electron can be configured with direct access to the file system. AFAIK tauri does not have this escape hatch
    by pilgrim0
  • 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...

    by Levitating
  • Thanks for that link. I just like the idea of creating things with Rust. Having the ability to build things for the web with Rust is a plus
    by mahirsaid