The state of building user interfaces in Rust

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 )

why not stay true to rust thinking and just use a TUI? Binding to a heavy not rust ecosystem requires many runsave calls.

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...

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’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.

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.

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?

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.

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.

To extend this, what's the state of accessibility for user interfaces built in Rust?

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.

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.

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)

Interested in Azul Gui, design frontend generate code for different languages !

As the joke goes, there are more GUI frameworks (game engines) for Rust than apps (games) written in them.

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

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)

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.

qmetaobject-rs gives you the best of both worlds: logic in rust, UI in arguably world's best cross platform framework Qt.

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.

Looks pretty neat. I'm a little disappointed about a closed beta though.

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;"

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

why not stay true to rust thinking and just use a TUI? Binding to a heavy not rust ecosystem requires many runsave calls.

Tons of great options, for sure, but community efforts and corporate sponsorship ends up fragmented if there isn’t a clear winner.

#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.

Interested in Azul Gui, design frontend generate code for different languages !

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.

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.

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.

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.

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 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.

GPUI is truly awesome.

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

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.

To extend this, what's the state of accessibility for user interfaces built in Rust?

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

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

Is it common for the toolkits written from scratch in Rust to have bindings for other languages?

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'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.

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

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)

As the joke goes, there are more GUI frameworks (game engines) for Rust than apps (games) written in them.

Looks pretty neat. I'm a little disappointed about a closed beta though.

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;"

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

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

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.

saving this comment, this echos my own thinking, html is not great but its better than dealing with all those things you listed.

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.

I would love to see this @octernion. Im very interested in health care apps.

What components were lacking? Is what you've built accessible somewhere?

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?

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)

my 2 cents:

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).

Did immediate mode guis solve (in)accessibility problem they used to be really bad at?

> 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

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.

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-...

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...

Perhaps it's to show how fragmented the community is.

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.

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

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.

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.

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

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.

GPUI is truly awesome.

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

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.

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).

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.

Did immediate mode guis solve (in)accessibility problem they used to be really bad at?

Perhaps it's to show how fragmented the community is.

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

egui has native accesskit support

Many libraries now support AccessKit.

The main frameworks with traction like Slint UI, egui, tauri, and Dioxus all have baseline accessibility support

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.

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?

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!

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.

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).

> 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.

The answer to the question posed in the site's domain name is "no", unfortunately.

"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.

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.

This is the mindset that gives you Java-Style GUIs.

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.

Almost all the screenshots in this article are “hello world”…

Web UI is fine for web applications, obviously.

But for desktop applications it is bloated, a big attack surface.

saving this comment, this echos my own thinking, html is not great but its better than dealing with all those things you listed.

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?

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

> a big attack surface

Wdym? At least web apps are sandboxed by default in contrast to native.

web UI is slow, this is only reason when I don't it.

Second this. Html is just so darn universal now

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?

egui has recently revamped text rendering, looks much better than it did just a few months ago.

Almost all the screenshots in this article are “hello world”…

"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

This is the mindset that gives you Java-Style GUIs.

I love Java-style GUIs though.

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.

Opening that site prompts my browser to download a `Human_fart.wav` file.

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.

Seems like a referrer of HN triggers that. Copy & paste the URL and it works fine. Idiotic.

> a big attack surface

Wdym? At least web apps are sandboxed by default in contrast to native.

web UI is slow, this is only reason when I don't it.

Second this. Html is just so darn universal now

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.

I would love to see this @octernion. Im very interested in health care apps.

What components were lacking? Is what you've built accessible somewhere?

“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.

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.

> 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

I love Java-style GUIs though.

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.

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. ;)

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

> That's why developers have UI/UX and design experts assigned to them.

Not everybody works in big tech.

Seems like it.

> Idiotic.

Yes, seeing how simple it seems to redirect to a page playing the sound, instead. ;)

[1] https://github.com/rustdesk/rustdesk/releases

The roots aren't deep but the seeds are planted.

As a low level language, Rust is perfectly suitable for making user interfaces the old fashioned way, with native APIs. However, competing in today's world typically means supporting many platforms, and that makes using native APIs an unattractive option for many.

Rust's expressiveness and high level abstractions make it ideal for building intricate and complex user interfaces. Unfortunately, there is little consensus on what the best abstractions are.

There are a number of bindings available today to existing frameworks, but those looking for a mature, easy to use, and completely Rust-based solution will most likely find themselves out of luck.

Current approaches to building GUIs in Rust include interfacing with Electron and building GUIs with HTML (or a framework on top of it), while others have taken to using graphics APIs and various wrappers to emulate classical widgets. The cross platform parallel rendering engine Webrender, built for Servo and usable in Firefox Nightly, takes this latter approach and is multi-platform, but is more of a base for a GUI framework than one in itself.

Stay in the loop.

Below are recent community links submitted to the site. If you're working on or writing about GUIs in Rust, please contribute! Each news entry can be a link back to your blog, Reddit thread, etc. See the README for details.

Hacker Times

Hacker Times

The state of building user interfaces in Rust

Discussion

Discussion

The roots aren't deep but the seeds are planted.

Stay in the loop.

Azul

blinc

cacao

core-foundation

Crux

Cushy

CXX-Qt

Dioxus

Dominator

egui

Floem

fltk

flutter_rust_bridge

Freya

fui

GPUI

GTK 3

Iced

imgui

Kas

kittest

Leptos

lvgl

Makepad

masonry

Pane UI

Pax

Ply

qmetaobject

relm

Relm4

Ribir

Rinf

Rosin

SDL3

Slint

Tauri

Tessera

tinyfiledialogs

undoredo

WebRender

WinSafe

wxDragon

Xilem

Yew