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...
But for desktop applications it is bloated, a big attack surface.
HTML/CSS is made for online documents, and using it for applications is a bit hack that happen to work, but hides a huge ton of complexity behind frameworks and frameworks of frameworks with leaky abstractions and each their own caveat.
I'm not a frontend developer, but seems fast to me. I'm surprised that the UI portion of this example takes so little CPU: https://youtu.be/7k0JNT6itaI
Now, the rest of the DSP code sure is faster in native.
What are examples where web UI is too slow for you?
Or do you mean large apps written in JS, which is a different topic?
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.
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.
I like your vision for Hypen and I sincerely hope that you can avoid the faith of every project that tried it before you! (all the toolkits that started as declarative, with clear logic/ui separation, eventually and inevitably add scripting and reinvent js/html).
That made me chuckle though:
Accessibility and i18n tooling:
This is in the plan - accessibility should be the easier one, with i18n tooling coming as more "platform calls" support comes online.
In my experience accessibility is far more difficult to get right, but maybe I've just been unlucky. :)
Honestly, in one iteration of Hypen I actually added a `Script` component, but after trying it, it already felt both dirty and confusing, so it's a definitive no for the near future :)
Regarding accessibility - I've also burned myself quite a few times on that bridge and that is why there won't be 1.0 without it being fully solved - I don't want devs to have to retroactively think about it or for it to have a second class implementation.
I believe there is a solution out of the box that should cover at least 80% of the most common needs, and provide primitives for more custom cases. Hopefully this time I can nail it... fingers crossed!
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.
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’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.
Can certainly be a downside. Jaded / grumpy rust programmer perspective: I will take this over the typical rust pattern of OSS libs which have been made without being tested in practical applications!
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.
I made side-by-side comparison with this and egui. Equi win with the less amount of code required for most things. But GPUI must be excellent for bigger projects where you need better architecture for components.
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.
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.
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 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).
Except the Visual Studio tooling comparable to C++/CX never came to be, using C++/WinRT feels to this day like using ATL with Visual C++ 6.0, except
"This isn't meant as a negative statement. cppwinrt has reached all of its goals and is generally considered complete and largely bug-free (1). Whether WinRT/WinUI/WinAppSDK is the future is debatable. My experience has shown me that the Windows operating system is at its best when you embrace the Windows API as a whole, including Win32/COM/WinRT, and not just the latest shiny wave. You can see this in action with the popularity of projects like win32metadata and windows-rs that support both WinRT and non-WinRT APIs seamlessly."
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!
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.
> 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.
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.
In my experience declarative UI frameworks quickly get awkward as UI complexity ramps. That model is workable for things like simpler mobile apps, text editors, terminals, and tiny focused utilities but is cumbersome for anything much more involved.
While imperative retain mode frameworks are technically possible in Rust, my understanding is that there’s a level of unavoidable ceremony and syntax ugliness (unless safety is discarded, which defeats the point of using Rust).
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.
I use Slint and tried a bunch of the other frameworks and nothing worked as well in embedded and also as mac/linux apps. It really accelerated development to have it running as a mac app and then be able to deploy it on real hardware.
#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.
Everyone seems to be converging on React/Elm arch for UI. I saw a paper years ago for incremental lambda calculus (https://inc-lc.github.io) that I feel addresses the fundamental problem here more honestly. It's mostly intended for optimizing repeated computations after small changes to the inputs, but I think it applies nicely to UI. Our data model needs to be a change structure along with our UI model. We write a function from our data model to the UI model just like React, but we also get a function from deltas on the data model to deltas on the UI model. The main thing missing that we would need for UI is since we get a stream of deltas on both the data model and UI model (scrolling, selecting, etc) we need to merge them.
This way we don't have to zipper together each "frame" of the output tree trying to figure out which bit goes to which other bit, we get an explicit delta saying "the 5th thing got deleted". You do probably need a language with HKT for this.
Another thing I'd like to see is a _truly_ immediate mode framework where each widget is a pure function to render it given its state, and it's up to the user to manage the UI state (scroll position, text cursor location, etc), you can mix it in with/ your data model, or whatever. Even egui/etc aren't truly immediate as they need to keep some sort of stable identity for events, UI state and focus. You could of course build a React like thing on top of that, but it would be helpful to have that for experimentation with wildly different state models without having to reinvent the text box and everything yet again. I've started some experimentation w/ this in Haskell and it's going well so far.
From the abstract, I get the impression it would require very granular atomic-level language transformations, that are only practical for languages that are designed from the ground up to support creating and applying such deltas. Rust and JavaScript/React seem overly complex for reducing down to that level of granularity, especially the latter for strictly typed and deterministic changes. Maybe a language like Haskell is more suitable, since I've heard that it (or a subset) can be compiled down to typed combinators as primitives.
> probably need a language with HKT
Ah, that sounds related to the thought above, that the technique may be best implemented at the level of language design. Does "HKT" mean "higher kinded types"? Closest I could find was a library for TypeScript: https://majorlift.github.io/hkt-toolbelt/
> _truly_ immediate mode framework where each widget is a pure function
It sounds like the "functional reactive" paradigm, which I think React is loosely based on and probably UI libraries like Imgui and others in Rust also. But none of them are "pure" like you describe because the languages they're built on are not pure all the way to the bottom. (Maybe Rust is, but it's likely too complex to practically "diff" and "patch" not only the data models but the running code incrementally, though I may be misunderstanding.)
I'm not referring to FRP, just a bunch of functions that can render a frame of UI if you pass in all the "internal state" like cursor position/selection/scroll in addition to the typical UI parameters. Xilem and others are doing a good job of making a lot of things modular, but I haven't seen one actually separate how the UI state is stored from the rendering of the UI.
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.
Slint UI does have bindings in other languages, but tutorials and docs are still lacking. Qt Bridges is a new option on the way for leveraging Qt with Rust and other language bindings.
The answer to the question posed in the site's domain name is "no", unfortunately.
It looks like it just grabbed the intro to each project's self-description, but blurbs like "Zero-cost ultra-high-performance declarative DOM library using FRP signals" would be worth very little even with screenshots.
“No” is a straightforward answer to “areweguiyet” in Rust. Many well intentioned and well-invested projects with no winning GUIs means we’re not there yet.
Saying “almost” or “yes” privileges the
activity and hype around Rust GUI over actual results. Bevy is the ironic example: a game engine that produces more discussion and code than, so far, one notable & good game.
Yes, I think it's trying to be comprehensive (as far as possible) rather than detailed. Given the amount of frameworks listed, including representative screenshots or comparisons for each would be a substantial effort.
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
Is that actually needed? Styling is largely a user decision. They might have defaults yes, but if you looked at a raw HTML page with no CSS styling, you might come to the conclusion that websites have an ugly GUI...
That's why developers have UI/UX and design experts assigned to them. That's why Figma exists. CSS was an attempt to not have to deal with styling. It failed, and landed in the other direction.
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.
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?
If you make a "Are we X yet?" website, surely the answer must be yes or no, or at least something equally terse. That's the joke right, reducing something complicated to a simple yes/no question?
"The roots aren't deep but the seeds are planted" makes me cringe.
I’m keeping an eye on Blitz from Dioxus. It’s still in early stages, but it’s a lightweight web renderer with only the required pieces - so you can code your UI with web technologies without having to ship an entire web browser just to render it.
been following this for a bit and i do think dioxus is kind of the front runner at least in my head it seems to feel the most production-ready. if blitz works out thats going to be a very interesting new paradigm to tinker with (minimally ship browser pieces).
ive been down this rabbithole with multiple languages, golang, rust, etc what kills me is no one is thinking of making a comprehensive and performant data grid type component. aggrid is my web standard/benchmark for how a table/grid component should look+behave+perform and ive yet to see anything like it in native gui packages. which is odd because we should be able to achieve something like aggrid and make it even more performant from languages like rust/go/etc
I have been building on a Pi with a 7 inch touch screen
I started out looking for lightweight X-Windows solutions, for the LLM and me to use. Cutting a long and frustrating story short I settled on SDL2 Rust wrapper
But what a PITA X-Windows is (e.g. need Wayland for some things, but does not work well for others), and my goal is an appliance, not an app.
So in a moment of insight I spent an afternoon getting SDL2 to draw on the Framebuffer and dispensed with X entirely
I highly recommend this approach. Life is so much easier without X-Windows
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.
> 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.
Qt QML is already annoying in C++ since you have to juggle 2 lifetime systems, c++ manual lifetime management and QMLs QML engine (aka gargabe collection).
> egui is the clear winner for making desktop applications
I disagree. It's the easiest to get started with, but it looks pretty terrible (poor font rendering especially), and immediate mode has serious downsides.
The more interesting question is why we're not GUI yet. I have Thoughts on this, which I'll try to briefly summarize here.
* It's a genuinely hard problem
The state of GUI on Windows is a total mess, very disappointing considering the relative importance and resources that Microsoft has. SwiftUI was a success (Apple is uniquely good at this stuff), but the transition from Cocoa is still not complete. A large part of the reason why it's so hard is that the requirements for different apps vary widely; I think we are spoiled by the relative cohesion
* The infrastructure is in disrepair
A UI is built on top of lots of infrastructural pieces, obviously including graphics and compositing, but also text, accessibility, input handling, and many other things. When you look at support for those layers across platforms, it's like picking up a rock and seeing the bugs crawl. Take compositing: Windows and Mac have excellent compositors, Android and Linux much less so. But even there the features don't line up, Mac doesn't support incremental present (they don't really need to, considering how beefy their chips are, but it's really important on low end Android).
So a lot of the challenge is working around the brokenness across the various platforms. But, good news, there is really excellent progress on all these fronts. We now have solid text layout in Rust, a clear winner on accessibility, and even poor winit is making slow, steady progress.
I'd also like to say, by contrast the web has really been investing in infrastructure, and hides much of the lower level pain from developers. I think that's a major reason Electron is winning so much.
* The computer science is not quite done
We're still in an exploratory phase to figure out the best patterns for writing Rust UI. At the core of that is reactivity, which is at heart incremental computation. Most systems are converging on a hybrid of something generally React like (coarser grain reactivity) with fine-grained signals. I'd like to think there is a Right Answer here and that it's possible to find it.
This feels to me a bit like async. The foundations for async Rust were laid 10 years ago, but it still doesn't feel fully baked. I've seen some exciting recent work about improving the confusing Pin mechanism with something more principled. We'll get there, but it takes time.
I make three predictions:
* Rust UI will continue to improve, as the infrastructure is built out, we try more things, and projects mature. But not quickly.
* If we thought we had a lot of Rust UI projects before, wait til we see what AI wreaks. I predict we'll see dozens of vibe coded Rust UI toolkits.
* In the longer term, we're going to have Rust UI anyway, as browsers are increasingly going to be rewritten in Rust, and apps will be built on Web technology. And that's not just Electron, the modular browser approach pioneered by Blitz is also promising.
Insightful point about how the struggle to converge on a well-designed UI paradigm is related to a larger question of how the industry is still experimenting and exploring the problem space, particularly:
> reactivity, which is at heart incremental computation
Another comment that caught my attention up-thread was talking about "incremental lambda calculus", which is the same question in different words. My impression was that ideally it needs a language-level solution to be able to support "diff" and "patch" not only on the data but the running code, perhaps built from primitives like continuations.
> feels to me a bit like async
Maybe part of the difficulty with reactive UI is fundamentally related to how the language "solves" async, for which there's still no real concensus on the best way to solve it.
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.
When you specify the stroke width of 2px and then turn it into a path, are you expecting the outline of the font to expand? Is the 2px stroke centered on the original glyph path, so 1px is "in" in the glyph and 1px is "out"?
I take your question to basically mean "can it expand or shrink a path?" and "can it use a path as a clipping mask?"
Or did I misunderstand and you want to only show the image within the 2px sliver itself?
I know that was the general point of your question, but I'm still curious what you expected the end result to look like. I've been doing some 2D graphics work recently with bezier curves and image clipping, so I did actually want to worry about the specifics :)
As a "batteries included" framework Qt is undoubtably amazing but I used it on a project recently and it struck me as dated compared to Flutter or React Native. Maybe I'm doing it wrong but I had to write a lot of boilerplate C++ even when using QML. The layout engine feels byzantine. The state management is mostly manual. Flutter is a lot more consistent, reactive, and all done in one way (Dart) and it supports hot reload natively. It was a more pleasant experience overall.
Qt has been going strong for 2+ decades and you can bet will do so for at least that many more. Flutter is by Google and it exists when I started writing this comment but we can't say for sure it will when I'm done writing it
And React has that "web development" ecosystem taint... I'd definitely lean towards Flutter in this case. It's neat, tidy and a contained ecosystem. It may not be fully perfect, but for cross platform UI's I think it's the way to go.
My only question is - say if one uses Rust, is flutter_rust_bridge the way to go?
Ah, I love rustdesk. I didn't know it was Flutter based. Only minor complaint about Rustdesk is that when you send the official link to people, they are frightened by a big scary "Scammer" alert[1]. To you and me, we immediately understand its actual purpose, but to non technical folks they hesitate to click it. I've seen this too many times.
I'm a bit out of the loop but I checked out the GitHub repo [0] and while the authors moved onto Slint the crate is still actively maintained. That said I also looked at the latest commits and that threw me down a rabbit hole of finding out that the main maintainer has a blog where he wrote about using Sailfish OS as a daily driver [1] and imagine my surprise when he revealed that he actually co-maintains a Signal client app for SailfishOS too. I looked into the GitLab repo for that app [2] and I gleefully discovered that it's mostly written in Rust, the Cargo.toml contains a dependency to qmetaobject-rs too.
All that is to say that I'm glad there's another way to get Rust on mobile aside from stuff like flutter_rust_bridge.
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.
I'm excited for Dioxus which is making their own HTML and CSS renderer and has its own independent browser called Blitz, so that's good for competition in the space.
Really? Every time I do a search I feel like there are too many TEA frameworks for rust, and I have to figure out which ones to invest time into. afaict iced and xilem are probably the best current options
For the past few years, I’ve been trying to build my ideal visual novel engine, and I’ve come to realize that I’ve largely been implementing a general-purpose 2D GUI solution.
Just like react-canvas back in the day, I combined wgpu and quickjs, and used the latter to run React. Of course, there’s no react-dom involved here; I have a custom renderer built with reconciler that binds to elements like `<sprite>` or `<text>` that I implemented in Rust.
Today this reminded me that maybe I should submit my project to arewegameyet and areweguiyet…
Recently I’ve been trying to add a visual editor to it—you know, similar to the relationship between RPG Maker MV and Pixijs. As a former frontend engineer and current Rust client engineer, I felt I had plenty of options. First, I looked into GPUI, and I have to say it’s a fantastic project, but unfortunately, it lacks the essential components I need to build my application. In the end, I had to go with a traditional solution like Tauri+ShadCN because I want to focus on the project itself.
I believe Rust will never be a major player in GUIs.
As in other areas where business outcomes of a software is more important than efficient memory management. I don't like Electron, but its popularity just makes it obvious that nobody cares about RAM usage in the GUI area.
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)
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 )
Web UI is fine for web applications, obviously.
But for desktop applications it is bloated, a big attack surface.
HTML/CSS is made for online documents, and using it for applications is a bit hack that happen to work, but hides a huge ton of complexity behind frameworks and frameworks of frameworks with leaky abstractions and each their own caveat.
> a big attack surface
Wdym? At least web apps are sandboxed by default in contrast to native.
Depends on which OS we're talking about.
Under which OS would a website not be sandboxed? It's the browser doing the sandboxing, not the OS.
I am talking about native applications.
web UI is slow, this is only reason when I don't it.
I'm not a frontend developer, but seems fast to me. I'm surprised that the UI portion of this example takes so little CPU: https://youtu.be/7k0JNT6itaI
Now, the rest of the DSP code sure is faster in native.
What are examples where web UI is too slow for you?
Or do you mean large apps written in JS, which is a different topic?
Slow means many: * long program launch times * inconsistent frame rates during runtime * noticeable lag in user interaction
That's neither examples nor a clarification if you're talking about JS or WASM.
No specific examples. Just general GUI apps.
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.
I can't think of what I'd want a native UI solution for.
A proper first-party LLM app for ChatGPT/Claude that doesn’t buckle under the weight of large threads.
You can accomplish this with web without much issue.
> I can't think of what I'd want a native UI solution for.
Because then your UI will work the way users of the platform expect it to.
> I can't think of what I'd want a native UI solution for.
So that your software is actually pleasant to use for your users. UIs built on HTML universally suck compared to native UIs.
> wgsl-bindgen
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 wish there were even more checking here still, but I think wgsl-bindgen is a huge improvement. I definitely recommend it!
its only going to get better from here. Its a great tool.
Universal technologies are increasingly becoming more desirable for devs the more I read about them.
> 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.
Sunwet looks like a lot of fun! I've put it on my TODO list to play with. Maybe I can use it to organize my ebooks in an undo-friendly way
saving this comment, this echos my own thinking, html is not great but its better than dealing with all those things you listed.
Second this. Html is just so darn universal now
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.
I like your vision for Hypen and I sincerely hope that you can avoid the faith of every project that tried it before you! (all the toolkits that started as declarative, with clear logic/ui separation, eventually and inevitably add scripting and reinvent js/html).
That made me chuckle though:
In my experience accessibility is far more difficult to get right, but maybe I've just been unlucky. :)Thanks!
Honestly, in one iteration of Hypen I actually added a `Script` component, but after trying it, it already felt both dirty and confusing, so it's a definitive no for the near future :)
Regarding accessibility - I've also burned myself quite a few times on that bridge and that is why there won't be 1.0 without it being fully solved - I don't want devs to have to retroactively think about it or for it to have a second class implementation.
I believe there is a solution out of the box that should cover at least 80% of the most common needs, and provide primitives for more custom cases. Hopefully this time I can nail it... fingers crossed!
Accessibility is also difficult to add retroactively. You should consider it from the start, not simply add it to a plan!
Just make a PR here: https://github.com/areweguiyet/areweguiyet
(I'm not affiliated, but have made PRs there in the past)
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...
Yes, that. And also:
Rust was designed to build core mechanisms of UI, like internals of a browser.
But as a language-behind-ui it is quite suboptimal so I think the most successful UI framework for Rust most likely will use some form of DSL.
But if DSL then inevitably we are getting question: why not HTML/CSS/JS then?
Visual styles, layout, structure, UI logic like "on click here, hide stuff there and expand section over there" is what HTML/CSS/JS was designed for.
"Render therefore unto Cesar the things which are Cesar's;"
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.
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
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’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.
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.
Can certainly be a downside. Jaded / grumpy rust programmer perspective: I will take this over the typical rust pattern of OSS libs which have been made without being tested in practical applications!
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.
GPUI is truly awesome.
Check out: https://github.com/longbridge/gpui-component
I made side-by-side comparison with this and egui. Equi win with the less amount of code required for most things. But GPUI must be excellent for bigger projects where you need better architecture for components.
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.
That looks very nice. How much of the UI is effectively stock gpui-component vs custom components? The charts? I assume you did custom theming?
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.
GPUI doesn't have accessibility support and isn't even targeted for anything but the text editor, so it's a definite "not yet"
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:
Downsides include: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 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).
Easy, that is the beauty of recordings,
You can start by when C++/CX was replaced,
CppCon 2016: “Embracing Standard C++ for the Windows Runtime"
https://www.youtube.com/watch?v=lm4IwfiJ3EU
With the followup talk the year thereafter,
CppCon 2017: “C++/WinRT and the Future of C++ on Windows”
https://www.youtube.com/watch?v=7TdpWB_vRZM
Except the Visual Studio tooling comparable to C++/CX never came to be, using C++/WinRT feels to this day like using ATL with Visual C++ 6.0, except
"This isn't meant as a negative statement. cppwinrt has reached all of its goals and is generally considered complete and largely bug-free (1). Whether WinRT/WinUI/WinAppSDK is the future is debatable. My experience has shown me that the Windows operating system is at its best when you embrace the Windows API as a whole, including Win32/COM/WinRT, and not just the latest shiny wave. You can see this in action with the popularity of projects like win32metadata and windows-rs that support both WinRT and non-WinRT APIs seamlessly."
From https://github.com/microsoft/cppwinrt/issues/1289#issuecomme...
You will notice the open issues are mostly bug fixes.
So who knows what will even happen to windows-rs crate.
Docs: https://github.com/microsoft/windows-rs/blob/master/docs/rea...
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!
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.
> 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.
Wait until you try Device Events on certain newer Linux versions. You might be in for a surprise, of which is no fault of Winit.
le sigh
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.
Rust doesn't play well with traditional frameworks but works fairly well with Elm and immediate mode.
One of the reasons I started messing around with Zig.
What makes you say that exactly?
In my experience declarative UI frameworks quickly get awkward as UI complexity ramps. That model is workable for things like simpler mobile apps, text editors, terminals, and tiny focused utilities but is cumbersome for anything much more involved.
While imperative retain mode frameworks are technically possible in Rust, my understanding is that there’s a level of unavoidable ceremony and syntax ugliness (unless safety is discarded, which defeats the point of using Rust).
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.
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.
It really looks cool, but creating JUST a simple damn button is a nightmare. Tabs, layout, fine, but you just want a button. nope.
I use Slint and tried a bunch of the other frameworks and nothing worked as well in embedded and also as mac/linux apps. It really accelerated development to have it running as a mac app and then be able to deploy it on real hardware.
#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.
To extend this, what's the state of accessibility for user interfaces built in Rust?
The main frameworks with traction like Slint UI, egui, tauri, and Dioxus all have baseline accessibility support
Many libraries now support AccessKit.
egui has native accesskit support
Everyone seems to be converging on React/Elm arch for UI. I saw a paper years ago for incremental lambda calculus (https://inc-lc.github.io) that I feel addresses the fundamental problem here more honestly. It's mostly intended for optimizing repeated computations after small changes to the inputs, but I think it applies nicely to UI. Our data model needs to be a change structure along with our UI model. We write a function from our data model to the UI model just like React, but we also get a function from deltas on the data model to deltas on the UI model. The main thing missing that we would need for UI is since we get a stream of deltas on both the data model and UI model (scrolling, selecting, etc) we need to merge them.
This way we don't have to zipper together each "frame" of the output tree trying to figure out which bit goes to which other bit, we get an explicit delta saying "the 5th thing got deleted". You do probably need a language with HKT for this.
I mentioned this to Phil Freeman years ago and he did a prototype in Purescript, but I haven't seen it anywhere else: https://github.com/paf31/purescript-purview
Another thing I'd like to see is a _truly_ immediate mode framework where each widget is a pure function to render it given its state, and it's up to the user to manage the UI state (scroll position, text cursor location, etc), you can mix it in with/ your data model, or whatever. Even egui/etc aren't truly immediate as they need to keep some sort of stable identity for events, UI state and focus. You could of course build a React like thing on top of that, but it would be helpful to have that for experimentation with wildly different state models without having to reinvent the text box and everything yet again. I've started some experimentation w/ this in Haskell and it's going well so far.
Incremental lambda calculus is a fascinating concept, I hadn't heard of it before.
A theory of changes for higher-order languages: incrementalizing λ-calculi by static differentiation - https://dl.acm.org/doi/10.1145/2594291.2594304
From the abstract, I get the impression it would require very granular atomic-level language transformations, that are only practical for languages that are designed from the ground up to support creating and applying such deltas. Rust and JavaScript/React seem overly complex for reducing down to that level of granularity, especially the latter for strictly typed and deterministic changes. Maybe a language like Haskell is more suitable, since I've heard that it (or a subset) can be compiled down to typed combinators as primitives.
> probably need a language with HKT
Ah, that sounds related to the thought above, that the technique may be best implemented at the level of language design. Does "HKT" mean "higher kinded types"? Closest I could find was a library for TypeScript: https://majorlift.github.io/hkt-toolbelt/
> _truly_ immediate mode framework where each widget is a pure function
It sounds like the "functional reactive" paradigm, which I think React is loosely based on and probably UI libraries like Imgui and others in Rust also. But none of them are "pure" like you describe because the languages they're built on are not pure all the way to the bottom. (Maybe Rust is, but it's likely too complex to practically "diff" and "patch" not only the data models but the running code incrementally, though I may be misunderstanding.)
Yeah higher kinded types, Mr. Freeman's Purview demonstrates the idea applied to UI: https://github.com/paf31/purescript-purview
I'm not referring to FRP, just a bunch of functions that can render a frame of UI if you pass in all the "internal state" like cursor position/selection/scroll in addition to the typical UI parameters. Xilem and others are doing a good job of making a lot of things modular, but I haven't seen one actually separate how the UI state is stored from the rendering of the UI.
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.
Slint UI does have bindings in other languages, but tutorials and docs are still lacking. Qt Bridges is a new option on the way for leveraging Qt with Rust and other language bindings.
Link: https://www.qt.io/development/qt-framework/qt-bridges
Qt already has really good binding, see Pyside6 for instance. GTK similarly through introspection.
Not sure why you want to build desktop GUIs using web tech though.
Which of these has effective accessibility support?
I suspect if such a filter was applied there would be very few. Probably just the bindings to gtk, qt or appkit.
I think this article: https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-... was the most exhaustive review of accessibility that I know of.
Nice! Thank you.
Yes please add accessibility support as a filter.
As the joke goes, there are more GUI frameworks (game engines) for Rust than apps (games) written in them.
Uhhh.. for a page thats about GUIs, this seems awfully sparse for the actual look and feel of said GUIs.
How about some screenshots?
Its very difficult to compare X to Y anywhere on this site. Its just an aggregator, not really an exemplary resource.
The answer to the question posed in the site's domain name is "no", unfortunately.
It looks like it just grabbed the intro to each project's self-description, but blurbs like "Zero-cost ultra-high-performance declarative DOM library using FRP signals" would be worth very little even with screenshots.
"no" is reductive to the point of being misleading.
Cosmic DE is built using iced which is a rust gui library. As far as native, single-platform guis go, I'd say rust is plenty mature.
There's also Bevy, a rust game engine, which, if I'm not mistaken is built on egui(?), and I think supports multiple compile targets.
Between a desktop environment and a game engine, I'd say rust is in a pretty decent place when it comes to gui.
“No” is a straightforward answer to “areweguiyet” in Rust. Many well intentioned and well-invested projects with no winning GUIs means we’re not there yet.
Saying “almost” or “yes” privileges the activity and hype around Rust GUI over actual results. Bevy is the ironic example: a game engine that produces more discussion and code than, so far, one notable & good game.
> There's also Bevy, a rust game engine, which, if I'm not mistaken is built on egui(?)
Not entirely correct, they have bevy_ui as the in-house example but many people use the third party bevy_egui crate
Yes, I think it's trying to be comprehensive (as far as possible) rather than detailed. Given the amount of frameworks listed, including representative screenshots or comparisons for each would be a substantial effort.
The best primer on the current(ish) state of GUI programming in Rust, IMO, is this article from 2025 which is linked on that page: https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-...
Opening that site prompts my browser to download a `Human_fart.wav` file.
Seems like a referrer of HN triggers that. Copy & paste the URL and it works fine. Idiotic.
Seems like it.
> Idiotic.
Yes, seeing how simple it seems to redirect to a page playing the sound, instead. ;)
Almost all the screenshots in this article are “hello world”…
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
Is that actually needed? Styling is largely a user decision. They might have defaults yes, but if you looked at a raw HTML page with no CSS styling, you might come to the conclusion that websites have an ugly GUI...
It absolutely is. Defaults matter, most developers just want a GUI for their app that doesn't look like ass. Almost no one wants to mess with styling.
That's why developers have UI/UX and design experts assigned to them. That's why Figma exists. CSS was an attempt to not have to deal with styling. It failed, and landed in the other direction.
> That's why developers have UI/UX and design experts assigned to them.
Not everybody works in big tech.
This is the mindset that gives you Java-Style GUIs.
I love Java-style GUIs though.
Perhaps it's to show how fragmented the community is.
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.
Looks pretty neat. I'm a little disappointed about a closed beta though.
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?
If you make a "Are we X yet?" website, surely the answer must be yes or no, or at least something equally terse. That's the joke right, reducing something complicated to a simple yes/no question?
"The roots aren't deep but the seeds are planted" makes me cringe.
I’m keeping an eye on Blitz from Dioxus. It’s still in early stages, but it’s a lightweight web renderer with only the required pieces - so you can code your UI with web technologies without having to ship an entire web browser just to render it.
been following this for a bit and i do think dioxus is kind of the front runner at least in my head it seems to feel the most production-ready. if blitz works out thats going to be a very interesting new paradigm to tinker with (minimally ship browser pieces).
ive been down this rabbithole with multiple languages, golang, rust, etc what kills me is no one is thinking of making a comprehensive and performant data grid type component. aggrid is my web standard/benchmark for how a table/grid component should look+behave+perform and ive yet to see anything like it in native gui packages. which is odd because we should be able to achieve something like aggrid and make it even more performant from languages like rust/go/etc
I have been building on a Pi with a 7 inch touch screen
I started out looking for lightweight X-Windows solutions, for the LLM and me to use. Cutting a long and frustrating story short I settled on SDL2 Rust wrapper
But what a PITA X-Windows is (e.g. need Wayland for some things, but does not work well for others), and my goal is an appliance, not an app.
So in a moment of insight I spent an afternoon getting SDL2 to draw on the Framebuffer and dispensed with X entirely
I highly recommend this approach. Life is so much easier without X-Windows
my 2 cents:
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.
No immediate mode GUI framework can be considered a clear winner for desktop applications usage.
egui is, however, one of the most reliable paths in Rust today for building and shipping a desktop app.
> 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.
Qt QML is already annoying in C++ since you have to juggle 2 lifetime systems, c++ manual lifetime management and QMLs QML engine (aka gargabe collection).
> egui is the clear winner for making desktop applications
I disagree. It's the easiest to get started with, but it looks pretty terrible (poor font rendering especially), and immediate mode has serious downsides.
My current favourite is https://github.com/longbridge/gpui-component
egui has recently revamped text rendering, looks much better than it did just a few months ago.
Did immediate mode guis solve (in)accessibility problem they used to be really bad at?
Rust needs good Qt bindings. None of the existing projects will ever reach Qt. Rust. Cargo. Qt. Go did it with https://github.com/mappu/miqt. Zig did it with https://github.com/rcalixte/libqt6zig. When will Rust do it? The time is now.
Slint is an attempt to build a Qt competitor
Although it's built in Rust, it supports a variety of languages + a custom DSL (like QML).
It's more of a QML competitor. I don't think it has anything comparable to QtWidgets.
Qt is already going at it with the new Qt Bridges project
https://www.qt.io/development/qt-framework/qt-bridges
The more interesting question is why we're not GUI yet. I have Thoughts on this, which I'll try to briefly summarize here.
* It's a genuinely hard problem
The state of GUI on Windows is a total mess, very disappointing considering the relative importance and resources that Microsoft has. SwiftUI was a success (Apple is uniquely good at this stuff), but the transition from Cocoa is still not complete. A large part of the reason why it's so hard is that the requirements for different apps vary widely; I think we are spoiled by the relative cohesion
* The infrastructure is in disrepair
A UI is built on top of lots of infrastructural pieces, obviously including graphics and compositing, but also text, accessibility, input handling, and many other things. When you look at support for those layers across platforms, it's like picking up a rock and seeing the bugs crawl. Take compositing: Windows and Mac have excellent compositors, Android and Linux much less so. But even there the features don't line up, Mac doesn't support incremental present (they don't really need to, considering how beefy their chips are, but it's really important on low end Android).
So a lot of the challenge is working around the brokenness across the various platforms. But, good news, there is really excellent progress on all these fronts. We now have solid text layout in Rust, a clear winner on accessibility, and even poor winit is making slow, steady progress.
I'd also like to say, by contrast the web has really been investing in infrastructure, and hides much of the lower level pain from developers. I think that's a major reason Electron is winning so much.
* The computer science is not quite done
We're still in an exploratory phase to figure out the best patterns for writing Rust UI. At the core of that is reactivity, which is at heart incremental computation. Most systems are converging on a hybrid of something generally React like (coarser grain reactivity) with fine-grained signals. I'd like to think there is a Right Answer here and that it's possible to find it.
This feels to me a bit like async. The foundations for async Rust were laid 10 years ago, but it still doesn't feel fully baked. I've seen some exciting recent work about improving the confusing Pin mechanism with something more principled. We'll get there, but it takes time.
I make three predictions:
* Rust UI will continue to improve, as the infrastructure is built out, we try more things, and projects mature. But not quickly.
* If we thought we had a lot of Rust UI projects before, wait til we see what AI wreaks. I predict we'll see dozens of vibe coded Rust UI toolkits.
* In the longer term, we're going to have Rust UI anyway, as browsers are increasingly going to be rewritten in Rust, and apps will be built on Web technology. And that's not just Electron, the modular browser approach pioneered by Blitz is also promising.
This is an excellent comment. Then I realized you're the same person who wrote the article I currently have open in the next tab. Advice for the next dozen Rust GUIs - https://raphlinus.github.io/rust/gui/2022/07/15/next-dozen-g...
Insightful point about how the struggle to converge on a well-designed UI paradigm is related to a larger question of how the industry is still experimenting and exploring the problem space, particularly:
> reactivity, which is at heart incremental computation
Another comment that caught my attention up-thread was talking about "incremental lambda calculus", which is the same question in different words. My impression was that ideally it needs a language-level solution to be able to support "diff" and "patch" not only on the data but the running code, perhaps built from primitives like continuations.
> feels to me a bit like async
Maybe part of the difficulty with reactive UI is fundamentally related to how the language "solves" async, for which there's still no real concensus on the best way to solve it.
The domain AND the title refers to "GUI". Could we fix the HN title that this is limited to just graphical user interfaces?
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.
When you specify the stroke width of 2px and then turn it into a path, are you expecting the outline of the font to expand? Is the 2px stroke centered on the original glyph path, so 1px is "in" in the glyph and 1px is "out"?
I take your question to basically mean "can it expand or shrink a path?" and "can it use a path as a clipping mask?"
Or did I misunderstand and you want to only show the image within the 2px sliver itself?
Don't worry about the specifics, I'm just asking if it can do modern 2D graphics well.
I know that was the general point of your question, but I'm still curious what you expected the end result to look like. I've been doing some 2D graphics work recently with bezier curves and image clipping, so I did actually want to worry about the specifics :)
What components were lacking? Is what you've built accessible somewhere?
I would love to see this @octernion. Im very interested in health care apps.
qmetaobject-rs gives you the best of both worlds: logic in rust, UI in arguably world's best cross platform framework Qt.
As a "batteries included" framework Qt is undoubtably amazing but I used it on a project recently and it struck me as dated compared to Flutter or React Native. Maybe I'm doing it wrong but I had to write a lot of boilerplate C++ even when using QML. The layout engine feels byzantine. The state management is mostly manual. Flutter is a lot more consistent, reactive, and all done in one way (Dart) and it supports hot reload natively. It was a more pleasant experience overall.
Qt has been going strong for 2+ decades and you can bet will do so for at least that many more. Flutter is by Google and it exists when I started writing this comment but we can't say for sure it will when I'm done writing it
And React has that "web development" ecosystem taint... I'd definitely lean towards Flutter in this case. It's neat, tidy and a contained ecosystem. It may not be fully perfect, but for cross platform UI's I think it's the way to go.
My only question is - say if one uses Rust, is flutter_rust_bridge the way to go?
flutter_rust_bridge is what rustdesk uses with pretty good success, it's where I first discovered it.
Ah, I love rustdesk. I didn't know it was Flutter based. Only minor complaint about Rustdesk is that when you send the official link to people, they are frightened by a big scary "Scammer" alert[1]. To you and me, we immediately understand its actual purpose, but to non technical folks they hesitate to click it. I've seen this too many times.
[1] https://github.com/rustdesk/rustdesk/releases
I'm a bit out of the loop but I checked out the GitHub repo [0] and while the authors moved onto Slint the crate is still actively maintained. That said I also looked at the latest commits and that threw me down a rabbit hole of finding out that the main maintainer has a blog where he wrote about using Sailfish OS as a daily driver [1] and imagine my surprise when he revealed that he actually co-maintains a Signal client app for SailfishOS too. I looked into the GitLab repo for that app [2] and I gleefully discovered that it's mostly written in Rust, the Cargo.toml contains a dependency to qmetaobject-rs too.
All that is to say that I'm glad there's another way to get Rust on mobile aside from stuff like flutter_rust_bridge.
[0] https://github.com/woboq/qmetaobject-rs
[1] https://www.rubdos.be/2026/04/17/my-sailfish-os-journey-apps...
[2] https://gitlab.com/whisperfish/whisperfish
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.
We are writing https://terminal.shodan.io using iced and the development aspect has been great. Biggest issues are around distributing on Windows.
I'm excited for Dioxus which is making their own HTML and CSS renderer and has its own independent browser called Blitz, so that's good for competition in the space.
I would give a look to the creators of SpacetimeDB and their game that they've developed. Some of their work utilizing Rust was interesting.
I’ve really enjoyed and leaned into building desktop apps with GPUI in the last months. Vibe engineered my apps but feel snappy and fast
why not stay true to rust thinking and just use a TUI? Binding to a heavy not rust ecosystem requires many runsave calls.
I tried to find a ELM style framework in Rust. And I couldn't find it in Rust and chose F# Fabulous instead.
See: https://book.iced.rs/
Really? Every time I do a search I feel like there are too many TEA frameworks for rust, and I have to figure out which ones to invest time into. afaict iced and xilem are probably the best current options
I missed saying “mature”
Possibly stupid question: if we are OK with using Arc everywhere in the UI (UIKit style), does that help?
Using Arc isn't a sin, it just shouldn't be used in hot loops.
I think I’m in a good position to speak on this!
For the past few years, I’ve been trying to build my ideal visual novel engine, and I’ve come to realize that I’ve largely been implementing a general-purpose 2D GUI solution.
The project README is:
https://github.com/Icemic/moyu/blob/main/README_EN.md
Just like react-canvas back in the day, I combined wgpu and quickjs, and used the latter to run React. Of course, there’s no react-dom involved here; I have a custom renderer built with reconciler that binds to elements like `<sprite>` or `<text>` that I implemented in Rust.
Today this reminded me that maybe I should submit my project to arewegameyet and areweguiyet…
Recently I’ve been trying to add a visual editor to it—you know, similar to the relationship between RPG Maker MV and Pixijs. As a former frontend engineer and current Rust client engineer, I felt I had plenty of options. First, I looked into GPUI, and I have to say it’s a fantastic project, but unfortunately, it lacks the essential components I need to build my application. In the end, I had to go with a traditional solution like Tauri+ShadCN because I want to focus on the project itself.
Interested in Azul Gui, design frontend generate code for different languages !
I believe Rust will never be a major player in GUIs.
As in other areas where business outcomes of a software is more important than efficient memory management. I don't like Electron, but its popularity just makes it obvious that nobody cares about RAM usage in the GUI area.
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)