How would screenshots help you in accessing a framework? How would you know whether a button supports accessibility and whether you need to declare it as a button in code or in a DSL? Or whether text editing supports mac-specific shortcuts?
At most it could give you an idea about whether some widgets are supported, but even there a list you could filter frameworks by would be worth a thousand screenshots
egui is the clear winner for making desktop applications. I've built a complex application recently (think of it like an AI powered image editor, doing plenty of editor logic and communicating with several python backends for the AI part) and it's been smooth sailing. It would be nice to have a family of components that look native on every platform but nowadays the desktop experience is anyway wildly inconsistent (and web-centric).
Using qt bindings is a good option too, but depending on non rust code means you are more likely to catch some weird crash. My experience with Qt in Rust is years old, so I can't comment on stability.
For frontend development, leptos is really nice and it feels familiar coming from react - but the whole chain is too heavy, your target directory quickly balloons to GBs and that's unacceptable, especially if you have several frontend projects.
I vibe coded a proof of concept leptos (including islands) with a minimal runtime and no dependencies and the size was much more contained. There is margin for improvements but today I would stick with solid.js for frontend development.
The other big hurdle for Rust on the web is the need to compile to wasm. That means that any Rust application will be heavier than a similar app in another JS framework. If we could target js instead of wasm, maybe we could have apps with small bundles.
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.
#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.
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 recently built a very complex healthcare application in dioxus and it's been a tremendous joy to work with. right now it's web-only, but the app does run fine as a desktop app when we need it.
having SSR built in means that the UX is amazing - really complex pages load basically instantly, and it degrades just as easily for folks that haven't loaded the WASM. server functions were also fantastic to work with and easy to reason about. and, the hot reloading they built means that most UX changes are reloaded within a ~few seconds, meaning iterating is fast and (mostly) painless.
the native component library dioxus has (dioxus-primitives) is... sparse so i did have to build out a hundred or so basic components, but i've done that across various stacks 5-6 times now over my career so it's a fun little journey at this point. for the components they do provide, the quality bar is very good.
Does it allow you to do things like: take this font at 20px, outline it with a stroke of 2px, turn that stroke into a path, then use that path as a clipping mask, then render this image using that mask.
The best approach has been to host a tokio server, and then make a traditional os-native user interface like a full-stack chump.
That’s crazy. It’s still better than the UX’s that game engine designers think work. Sure bro, show me your File Open/Save Dialog and tree view. Show me your text editor (nicely done, zed)
Is it common for the toolkits written from scratch in Rust to have bindings for other languages?
I still think the ideal solution for Desktop GUIs would be the Qt company developing first class Qt bindings for Node.js (or some other runtime), and allow people to build UIs using web tech with Qt components.
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.
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 am not much of a GUI user, or programmer, but I have used a lot of GUI tool kits, mostly debugging and/or extending other's work
HTML5 is the sanest for me. I can actually find where code executes, tooling using browsers (Firefox or Chromium) excellent and the declarative layout works well
The hours and hours I spent chasing the executing code in Dart/Flutter and, oh my aching head, in SwiftUI made me hate those with passion
I get that it is unsuitable for desktop programmes, for many good reasons, but it is so much better to modify.
Oh I didn't know about this, it looks great! If it works as well as it seems to, that would be a huge ergonomic boost to using wgpu. Currently all my wgpu code has those fragile feeling pipeline layout definitions scattered around and changing the data layout is always a pain.
> 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
Not everything is yet another shitty b2c "app".
There are whole industries where cross-platform support is irrelevant, as paying customers just keep using Windows.
This isn’t Rust-specific, but I’m always slightly surprised I don’t see more people talk about Pangui (https://www.pangui.io/) (it not being out yet is a pretty good reason I guess). If the demos on the site aren’t vaporware, it seems to me like a really promising addition to the current options for desktop gui dev.
I personally think we'd have more success with a purely functional way of approaching GUIs. Our machines are fast enough now and we can use C++/Rust for the "inner loop" performance.
Tons of great options, for sure, but community efforts and corporate sponsorship ends up fragmented if there isn’t a clear winner.
For desktop app development, if I don’t care about native controls (and what does that mean in Linux or even post-Win32, anyway?) and don’t want to deal with Electron, why not use something a bit more established like Avalonia or Flutter?
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!
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.
Makes sense, Microsoft doesn't have the best track record in supporting frameworks.
I myself have never worked with C++/CX or C++/WinRT. My Rust journey has been exclusively on POSIX systems, so seeing windows-reactor and getting a UI in a couple of lines is pretty cool.
I would never (at least not in its current state) recommend it for production though, as the crate containing reactor isn't even on crates.io.
Could you share some of the promises made that were abandoned? (I just realized that question sounds like AI... I promise you it's not).
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
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
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.
When I was a student I had to make quite a few Qt application with C++ (for Linux). However, I bring the food on the table doing web (recently only the backend). During that time, the languages for web were something like Python - concise, convenient in terms of ecosystem and distribution, but bloated in terms of memory consumption. "Hello World in Java almost doesn't hang" he-he. Anyway, my first thought when I found Rust I dreamed to make a GUI application.
Unfortunately, I had the expectation that it should be as simple as making an HTML page. My failure to find a library or a framework to make GUI application made me learn a lot about how GUI works. I realized that making GUI for browser and for desktop are quite different problems. Browser makes easy what's difficult having a desktop oriented GUI framework - text rendering. However, the situation is fair the other around. GUI framework makes easy what's difficult in a browser - drawing arbitrary shapes. As a result, a web-frontend programmer struggles to figure out how to write some text having something like Qt, a GUI programmer tries to find the API to the bitmap in a browser.
It's fair noticed in the previous comments that a GUI framework brings a lot. That's because the problem is complex:
1. Create a window
2. Communicate with the window compositor (you do in WinAPI too btw). How to access the system tray and the child window.
3. Communicate with the operating system.
4. Handle the user input. Callback vs event streams. The user has 4 keyboards for some reason.
5. Rendering. Subpixels, shapes, different DPI. The user has 6 monitors.
6. Text rendering.
7. Widgets. Where probably the most difficult part is to make a textbox, because it involves the solutions of all previous steps.
The steps above touch only the visual part. There's also audio, accessibility, somebody wants the GUI framework to solve the networking.
After all of this research, I picked simply SDL for my project.
1. It's easy to compile.
2. It's small.
3. It relies on the subjectively common dependencies.
4. It's fairly straightforward to upgrade. Given that, you have to create a lot from scratch the part with updating is smaller comparing to a Qt-based solution.
5. It has batteries. My favorite is SDL_ttf which allowed me recently to implement selection of the text which is quite a bit through towards a textbox.
Having a project on SDL requires a lot of knowledge, but not a lot of code.
65 comments
[ 3.2 ms ] story [ 69.8 ms ] threadHow about some screenshots?
Its very difficult to compare X to Y anywhere on this site. Its just an aggregator, not really an exemplary resource.
At most it could give you an idea about whether some widgets are supported, but even there a list you could filter frameworks by would be worth a thousand screenshots
egui is the clear winner for making desktop applications. I've built a complex application recently (think of it like an AI powered image editor, doing plenty of editor logic and communicating with several python backends for the AI part) and it's been smooth sailing. It would be nice to have a family of components that look native on every platform but nowadays the desktop experience is anyway wildly inconsistent (and web-centric).
Using qt bindings is a good option too, but depending on non rust code means you are more likely to catch some weird crash. My experience with Qt in Rust is years old, so I can't comment on stability.
For frontend development, leptos is really nice and it feels familiar coming from react - but the whole chain is too heavy, your target directory quickly balloons to GBs and that's unacceptable, especially if you have several frontend projects.
I vibe coded a proof of concept leptos (including islands) with a minimal runtime and no dependencies and the size was much more contained. There is margin for improvements but today I would stick with solid.js for frontend development.
The other big hurdle for Rust on the web is the need to compile to wasm. That means that any Rust application will be heavier than a similar app in another JS framework. If we could target js instead of wasm, maybe we could have apps with small bundles.
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.
Also shoutout to ratatui because even though it's technically a TUI not GUI, it's superb.
Strengths:
Downsides include:having SSR built in means that the UX is amazing - really complex pages load basically instantly, and it degrades just as easily for folks that haven't loaded the WASM. server functions were also fantastic to work with and easy to reason about. and, the hot reloading they built means that most UX changes are reloaded within a ~few seconds, meaning iterating is fast and (mostly) painless.
the native component library dioxus has (dioxus-primitives) is... sparse so i did have to build out a hundred or so basic components, but i've done that across various stacks 5-6 times now over my career so it's a fun little journey at this point. for the components they do provide, the quality bar is very good.
That’s crazy. It’s still better than the UX’s that game engine designers think work. Sure bro, show me your File Open/Save Dialog and tree view. Show me your text editor (nicely done, zed)
I still think the ideal solution for Desktop GUIs would be the Qt company developing first class Qt bindings for Node.js (or some other runtime), and allow people to build UIs using web tech with Qt components.
I wish there were more memory safe compiled languages that focused on ergonomics for cases like this.
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 )
HTML5 is the sanest for me. I can actually find where code executes, tooling using browsers (Firefox or Chromium) excellent and the declarative layout works well
The hours and hours I spent chasing the executing code in Dart/Flutter and, oh my aching head, in SwiftUI made me hate those with passion
I get that it is unsuitable for desktop programmes, for many good reasons, but it is so much better to modify.
So that your software is actually pleasant to use for your users. UIs built on HTML universally suck compared to native UIs.
A proper first-party LLM app for ChatGPT/Claude that doesn’t buckle under the weight of large threads.
Oh I didn't know about this, it looks great! If it works as well as it seems to, that would be a huge ergonomic boost to using wgpu. Currently all my wgpu code has those fragile feeling pipeline layout definitions scattered around and changing the data layout is always a pain.
Not everything is yet another shitty b2c "app".
There are whole industries where cross-platform support is irrelevant, as paying customers just keep using Windows.
Because then your UI will work the way users of the platform expect it to.
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...
For desktop app development, if I don’t care about native controls (and what does that mean in Linux or even post-Win32, anyway?) and don’t want to deal with Electron, why not use something a bit more established like Avalonia or Flutter?
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!
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.
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.
I myself have never worked with C++/CX or C++/WinRT. My Rust journey has been exclusively on POSIX systems, so seeing windows-reactor and getting a UI in a couple of lines is pretty cool.
I would never (at least not in its current state) recommend it for production though, as the crate containing reactor isn't even on crates.io.
Could you share some of the promises made that were abandoned? (I just realized that question sounds like AI... I promise you it's not).
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
I suspect if such a filter was applied there would be very few. Probably just the bindings to gtk, qt or appkit.
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.
Unfortunately, I had the expectation that it should be as simple as making an HTML page. My failure to find a library or a framework to make GUI application made me learn a lot about how GUI works. I realized that making GUI for browser and for desktop are quite different problems. Browser makes easy what's difficult having a desktop oriented GUI framework - text rendering. However, the situation is fair the other around. GUI framework makes easy what's difficult in a browser - drawing arbitrary shapes. As a result, a web-frontend programmer struggles to figure out how to write some text having something like Qt, a GUI programmer tries to find the API to the bitmap in a browser.
It's fair noticed in the previous comments that a GUI framework brings a lot. That's because the problem is complex:
1. Create a window
2. Communicate with the window compositor (you do in WinAPI too btw). How to access the system tray and the child window.
3. Communicate with the operating system.
4. Handle the user input. Callback vs event streams. The user has 4 keyboards for some reason.
5. Rendering. Subpixels, shapes, different DPI. The user has 6 monitors.
6. Text rendering.
7. Widgets. Where probably the most difficult part is to make a textbox, because it involves the solutions of all previous steps.
The steps above touch only the visual part. There's also audio, accessibility, somebody wants the GUI framework to solve the networking.
After all of this research, I picked simply SDL for my project.
1. It's easy to compile.
2. It's small.
3. It relies on the subjectively common dependencies.
4. It's fairly straightforward to upgrade. Given that, you have to create a lot from scratch the part with updating is smaller comparing to a Qt-based solution.
5. It has batteries. My favorite is SDL_ttf which allowed me recently to implement selection of the text which is quite a bit through towards a textbox.
Having a project on SDL requires a lot of knowledge, but not a lot of code.