The state of building user interfaces in Rust
101–110 of 156 posts
Re: The state of building user interfaces in Rust
#102I 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.
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.
Re: The state of building user interfaces in Rust
#103Throwing 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…
Re: The state of building user interfaces in Rust
#104Throwing 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…
Re: The state of building user interfaces in Rust
#105Possibly stupid question: if we are OK with using Arc everywhere in the UI (UIKit style), does that help?
Re: The state of building user interfaces in Rust
#106Re: The state of building user interfaces in Rust
#107Building 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...
Re: The state of building user interfaces in Rust
#108* 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.
Re: The state of building user interfaces in Rust
#109i'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…
Re: The state of building user interfaces in Rust
#110Earlier quoted context omitted.
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.
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?