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

121–130 of 156 posts

Re: The state of building user interfaces in Rust

#121

Post by icemic »

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

Re: The state of building user interfaces in Rust

#123

Post by rendaw »

bschwindHN wrote: post #120
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…

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

Re: The state of building user interfaces in Rust

#124

Post by jbrownson »

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.

Re: The state of building user interfaces in Rust

#125

Post by eviks »

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 doesn't have accessibility support and isn't even targeted for anything but the text editor, so it's a definite "not yet"

Re: The state of building user interfaces in Rust

#126

Post by eviks »

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.

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

Re: The state of building user interfaces in Rust

#127

Post by bschwindHN »

amelius wrote: post #109
octernion wrote: post #24

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…

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?

Re: The state of building user interfaces in Rust

#128

Post by pjmlp »

ngruhn wrote: post #97
jenadine wrote: post #67

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

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

Re: The state of building user interfaces in Rust

#129

Post by pjmlp »

OptionOfT wrote: post #60

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.

Re: The state of building user interfaces in Rust

#130

Post by pjmlp »

RustSupremacist wrote: post #106

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.

Qt is already going at it with the new Qt Bridges project

https://www.qt.io/development/qt-framework/qt-bridges

Post reply on HN