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

Emerging Rust GUI libraries in a WASM world

monadical.com

Post reply on HN
Print view View original

91–100 of 272 posts

Re: Emerging Rust GUI libraries in a WASM world

#91

Post by LeanderK »

eslaught wrote: post #2

I've been building a profiler UI in egui recently, and have been pretty happy with it. I didn't try out all of the options in this article (there are rather a lot of them), but I did try several, and out of the ones I tried, egui was by far the highest performance. Since my goal is to shove as many rectangles onto the screen as possible, this was the killer feature for me, but it was also nice that it did most of the…

wow, i am genuinely impressed! super snappy. I wonder whether it could be used to tackle a real pain point of mine. I work a lot with data, visualisations with jupiter notebooks. There are essentially two approaches: matplotlib, which outputs pngs/svgs. The notebooks stay fast but they are not interactive. The other is approaches like plotly, js-based, interactive, very useful but it gets slow really fast. I can not handle a lot of data. It can not handle a lot of plots. A simple, interactive plotting library with a focus on speed would be immensely useful! With python bindings. Could be a fun weekend project. I don't know any rust though, anybody up to collaborate? :P

I bet the canvas approach would not slow-down the notebook.

Re: Emerging Rust GUI libraries in a WASM world

#92

Post by belst »

andyp-kw wrote: post #49
Liberonostrud wrote: post #41

What's wrong with TypeScript? Last time I checked all WASM stuff was slower and much heavier than TS/JS.

My understanding that WASM has a heavier load time, however actual benchmarks after the initial load are more impressive.

When you ship javascript, the Browser already has a lot of the bigger libraries built in. When you ship rust/wasm, you need to ship all of the basic types like Strings, Vecs, + a lot of the std

Re: Emerging Rust GUI libraries in a WASM world

#93

Post by Kiro »

echelon wrote: post #25
eslaught wrote: post #2

I've been building a profiler UI in egui recently, and have been pretty happy with it. I didn't try out all of the options in this article (there are rather a lot of them), but I did try several, and out of the ones I tried, egui was by far the highest performance. Since my goal is to shove as many rectangles onto the screen as possible, this was the killer feature for me, but it was also nice that it did most of the…

Obligatory jaw-dropping egui demo: https://www.egui.rs/#demo Egui slaps and is clearly going places.

Are you being sarcastic?

Re: Emerging Rust GUI libraries in a WASM world

#94

Post by birracerveza »

ReleaseCandidat wrote: post #89
eslaught wrote: post #2

I've been building a profiler UI in egui recently, and have been pretty happy with it. I didn't try out all of the options in this article (there are rather a lot of them), but I did try several, and out of the ones I tried, egui was by far the highest performance. Since my goal is to shove as many rectangles onto the screen as possible, this was the killer feature for me, but it was also nice that it did most of the…

I understand that this is a demo, but actually drawing all 8,000 nodes instead of just 3 screenfuls (6 nodes on my screen) and updating them dynamically when scrolling isn't what I would call 'performant', but needless waste of resources. Btw: when clicking any 'task' to get to see the details, I see a repeating pattern of almost vertical stripes in some colors. I guess that's not what it should look like.

If drawing all 8000 nodes consumes less resources than rendering your average homepage, is it really wasteful? I understand it can be optimized, but that optimization often comes at a cost which may end up being even more wasteful.

Re: Emerging Rust GUI libraries in a WASM world

#95

Post by LeanderK »

chrismorgan wrote: post #21
CJefferson wrote: post #6

Searched for “accessibility” — 0 results (I couldn’t see anything skimming down the page). Speaking as a Rust user, everyone in Rust land loves insulting Electron, but they have put some solid work into accessibility. In particular, using WASM to draw text with webgl or canvas, instead of DOM, may in the long term be one of the biggest steps back in accessibility ever.

Since people will bring up AccessKit, assuming it to be a potential panacea (… despite the obvious performance cost of doing absolutely everything twice): The pure canvas approach used by things like egui (and it probably can’t change it) and current iced (it used to have iced_web which rendered to DOM, but that’s been abandoned for now for no obvious reason) is fundamentally and irredeemably unsuitable for general-p…

this take is a little bit too simplistic. There are use-cases where you are bound to a web-based framework but JS solutions are just not fast enough, e.g. data visualisations via jupyter notebooks. So you're stuck with some horribly slow solutions or non-interactive ones giving you pngs. Since you're plotting data, the text is minimal and the needed dialogs etc. are also minimal (clicking on a point and getting a label) or having a few options to rotate/turn on some features/zoom. And pngs with rendered text is as inaccessible as it gets, although data-visualisation may be fundamentally incompatible with accessibility tools since it is all about seeing stuff.

So I usually produce pngs via matplotlib and only selectively use interactive, js based, visualisations but they are get so unbelievable slow quickly when that your whole tab freezes.

Re: Emerging Rust GUI libraries in a WASM world

#96

Post by galangalalgol »

birracerveza wrote: post #94
ReleaseCandidat wrote: post #89

Earlier quoted context omitted.

I understand that this is a demo, but actually drawing all 8,000 nodes instead of just 3 screenfuls (6 nodes on my screen) and updating them dynamically when scrolling isn't what I would call 'performant', but needless waste of resources. Btw: when clicking any 'task' to get to see the details, I see a repeating pattern of almost vertical stripes in some colors. I guess that's not what it should look like.

If drawing all 8000 nodes consumes less resources than rendering your average homepage, is it really wasteful? I understand it can be optimized, but that optimization often comes at a cost which may end up being even more wasteful.

Yeah, when a gpu is involved it is often cheaper to process everything rather than check what meeds to be processed.

Re: Emerging Rust GUI libraries in a WASM world

#97

Post by flohofwoe »

josephg wrote: post #22
eslaught wrote: post #2

I've been building a profiler UI in egui recently, and have been pretty happy with it. I didn't try out all of the options in this article (there are rather a lot of them), but I did try several, and out of the ones I tried, egui was by far the highest performance. Since my goal is to shove as many rectangles onto the screen as possible, this was the killer feature for me, but it was also nice that it did most of the…

Cool demo, but by the looks of things the whole site is rendered into a canvas element. As a result, the browser's dev tools are useless, it won't work with screen readers, and you can't copy+paste text. And any text rendering and input elements will be non-native. (So, no nice iphone controls. No native / system configurable keyboard shortcuts. And so on.) I sincerely hope the web as a whole doesn't move in this dir…

If the web API zoo wouldn't be so random it would all be easier. Pretty much all problems on the web (including the Javascript framework churn) are caused by the DOM being too high level, too inflexible and generally too 'black-boxy' to do anything interesting.

Accessibility could be fixed easily if there would be a web accessibility API. There's basically an entire 'middle layer' of web APIs missing, current APIs are either too low level (like WebGL/WebGPU) or too high level (like the DOM).

Re: Emerging Rust GUI libraries in a WASM world

#98

Post by rwalle »

low_tech_punk wrote: post #59
CJefferson wrote: post #6

Searched for “accessibility” — 0 results (I couldn’t see anything skimming down the page). Speaking as a Rust user, everyone in Rust land loves insulting Electron, but they have put some solid work into accessibility. In particular, using WASM to draw text with webgl or canvas, instead of DOM, may in the long term be one of the biggest steps back in accessibility ever.

I think Tauri bypassed the a11y challenge by delegating rendering to platform native web engines.

Eh, that's not how it works. Web engines do a great job at providing accessibility for basic stuff, but to make an application and its content fully accessible, you would need to have accessibility as a requirement from the very beginning, make sure every little UI element is accessible (sometimes meaning provide additional fallback content), and constantly test your UI, which is never something that can be automatically added on top of an existing non-accessible UI.

Re: Emerging Rust GUI libraries in a WASM world

#99

Post by galangalalgol »

Kiro wrote: post #93
echelon wrote: post #25

Earlier quoted context omitted.

Obligatory jaw-dropping egui demo: https://www.egui.rs/#demo Egui slaps and is clearly going places.

Are you being sarcastic?

I certainly was extremely impressed the first time I saw it. Other than the font book I haven't found anything there that is slow. What makes you think the op might have been sarcastic? Egui was in a thread yesterday and it seems like canvas rendering is a dividing issue between people who value portability and performance most vs people who value consistency of ergonomics and style/look most.

Re: Emerging Rust GUI libraries in a WASM world

#100

Post by bsaul »

crispinb wrote: post #30

I doubt Rust is going to become used for (the GUI layer of) GUI apps far outside of Rust enthusiast circles. To build a widely attractive ecosystem it needs a dominant framework to which enough of the many widget and theming and distribution libraries and tools necessary for broad adoption attach. Rust's culture in this respect is far more Clojure (bolt together your own from a thousand options) than Elixir (just use…

My guess is Rust is going to experience its first test in the next two years, where the general people will see what it's really good for, and what's it not, because it won't be the "new hot thing" anymore.

Only then we will know if it has chance of really becoming widely used as a general purpose PL.

Post reply on HN