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

61–70 of 156 posts

Re: The state of building user interfaces in Rust

#61

Post by chews »

sgt wrote: post #34
rjh29 wrote: post #11

Earlier quoted context omitted.

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…

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.

Re: The state of building user interfaces in Rust

#62

Post by swiftcoder »

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…

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

Re: The state of building user interfaces in Rust

#63

Post by the__alchemist »

swiftcoder wrote: post #62
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…

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

Re: The state of building user interfaces in Rust

#64

Post by nicce »

victor106 wrote: post #53
segphault wrote: post #14

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

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.

Re: The state of building user interfaces in Rust

#66

Post by swiftcoder »

the__alchemist wrote: post #63
swiftcoder wrote: post #62

Earlier quoted context omitted.

> 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

Re: The state of building user interfaces in Rust

#67

Post by jenadine »

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.

Re: The state of building user interfaces in Rust

#68

Post by nu11ptr »

ktukey wrote: post #26
segphault wrote: post #14

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

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?

Re: The state of building user interfaces in Rust

#69

Post by tapirl »

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.

web UI is slow, this is only reason when I don't it.
Post reply on HN