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

141–150 of 156 posts

Re: The state of building user interfaces in Rust

#141

Post by trueno »

dabinat wrote: post #98

I’m keeping an eye on Blitz from Dioxus. It’s still in early stages, but it’s a lightweight web renderer with only the required pieces - so you can code your UI with web technologies without having to ship an entire web browser just to render it.

been following this for a bit and i do think dioxus is kind of the front runner at least in my head it seems to feel the most production-ready. if blitz works out thats going to be a very interesting new paradigm to tinker with (minimally ship browser pieces).

ive been down this rabbithole with multiple languages, golang, rust, etc what kills me is no one is thinking of making a comprehensive and performant data grid type component. aggrid is my web standard/benchmark for how a table/grid component should look+behave+perform and ive yet to see anything like it in native gui packages. which is odd because we should be able to achieve something like aggrid and make it even more performant from languages like rust/go/etc

Re: The state of building user interfaces in Rust

#142

Post by bschwindHN »

amelius wrote: post #132
bschwindHN wrote: post #127

Earlier quoted context omitted.

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

Don't worry about the specifics, I'm just asking if it can do modern 2D graphics well.

I know that was the general point of your question, but I'm still curious what you expected the end result to look like. I've been doing some 2D graphics work recently with bezier curves and image clipping, so I did actually want to worry about the specifics :)

Re: The state of building user interfaces in Rust

#143

Post by deanishe »

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…

> I can't think of what I'd want a native UI solution for.

Because then your UI will work the way users of the platform expect it to.

Re: The state of building user interfaces in Rust

#144

Post by demorro »

If you make a "Are we X yet?" website, surely the answer must be yes or no, or at least something equally terse. That's the joke right, reducing something complicated to a simple yes/no question?

"The roots aren't deep but the seeds are planted" makes me cringe.

Re: The state of building user interfaces in Rust

#145

Post by tapirl »

thomashabets2 wrote: post #110
tapirl wrote: post #69

Earlier quoted context omitted.

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

I'm not a frontend developer, but seems fast to me. I'm surprised that the UI portion of this example takes so little CPU: https://youtu.be/7k0JNT6itaI 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?

Slow means many: * long program launch times * inconsistent frame rates during runtime * noticeable lag in user interaction

Re: The state of building user interfaces in Rust

#146

Post by jbrownson »

lioeters wrote: post #131
jbrownson wrote: post #124

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…

Incremental lambda calculus is a fascinating concept, I hadn't heard of it before. A theory of changes for higher-order languages: incrementalizing λ-calculi by static differentiation - https://dl.acm.org/doi/10.1145/2594291.2594304 From the abstract, I get the impression it would require very granular atomic-level language transformations, that are only practical for languages that are designed from the ground up to…

Yeah higher kinded types, Mr. Freeman's Purview demonstrates the idea applied to UI: https://github.com/paf31/purescript-purview

I'm not referring to FRP, just a bunch of functions that can render a frame of UI if you pass in all the "internal state" like cursor position/selection/scroll in addition to the typical UI parameters. Xilem and others are doing a good job of making a lot of things modular, but I haven't seen one actually separate how the UI state is stored from the rendering of the UI.

Re: The state of building user interfaces in Rust

#147

Post by mahirsaid »

rendaw wrote: post #123
bschwindHN wrote: post #120

Earlier quoted context omitted.

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

its only going to get better from here. Its a great tool.

Re: The state of building user interfaces in Rust

#149

Post by evereverever »

hazkoulia wrote: post #84

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

It really looks cool, but creating JUST a simple damn button is a nightmare. Tabs, layout, fine, but you just want a button. nope.

Re: The state of building user interfaces in Rust

#150

Post by theusus »

12_throw_away wrote: post #115
theusus wrote: post #85

I tried to find a ELM style framework in Rust. And I couldn't find it in Rust and chose F# Fabulous instead.

Really? Every time I do a search I feel like there are too many TEA frameworks for rust, and I have to figure out which ones to invest time into. afaict iced and xilem are probably the best current options

I missed saying “mature”
Post reply on HN