Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The state of building user interfaces in Rust

areweguiyet.com

Post reply on HN
Print view View original

91–100 of 156 posts

Re: The state of building user interfaces in Rust

#91

Post by LoganDark »

tredre3 wrote: post #87
hypendev wrote: post #74

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 - Cus…

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…

Accessibility is also difficult to add retroactively. You should consider it from the start, not simply add it to a plan!

Re: The state of building user interfaces in Rust

#92

Post by yesbabyyes »

IshKebab wrote: post #49
brandnewideas wrote: post #33

Earlier quoted context omitted.

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

Re: The state of building user interfaces in Rust

#93

Post by hitekker »

amarant wrote: post #30
entrope wrote: post #3

Earlier quoted context omitted.

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 com…

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

Re: The state of building user interfaces in Rust

#94

Post by Animats »

the__alchemist wrote: post #56

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…

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.

Re: The state of building user interfaces in Rust

#95

Post by hitekker »

NoboruWataya wrote: post #6
Severian wrote: post #2

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.

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

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

Re: The state of building user interfaces in Rust

#96

Post by sgt »

chews wrote: post #61
sgt wrote: post #34

Earlier quoted context omitted.

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

Re: The state of building user interfaces in Rust

#97

Post by ngruhn »

jenadine wrote: post #67
rendaw wrote: post #31

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 h…

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.

Re: The state of building user interfaces in Rust

#99

Post by hypendev »

tredre3 wrote: post #87
hypendev wrote: post #74

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 - Cus…

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…

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!

Re: The state of building user interfaces in Rust

#100

Post by c-smile »

Levitating wrote: post #40

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

Post reply on HN