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

131–140 of 272 posts

Re: Emerging Rust GUI libraries in a WASM world

#131

Post by sbt567 »

iudqnolq wrote: post #75
Klonoar wrote: post #11

Earlier quoted context omitted.

>That's because Rust GUI people are like Lispers and functional programmers — too obsessed with doing things correctly "from first principles" and "purity". That's... entirely wrong and not necessary to paint swathes of developers like. Rust has numerous solutions for native GUIs. People ship apps with those stacks. Rust also has things like Tauri for when you don't want to deal with differences across platforms. Jus…

Can you give an example of a real, shipped app where the majority of the GUI is written in Rust? I'm excluding games because they tend to have trivial GUIs. I'm excluding tauri because the majority of the GUI code in a tauri app isn't Rust. This is a serious question. I'd love be shown I'm missing something. I read this article hoping to find out that a serious rust GUI library was ready for real use and was quite di…

The author of egui created https://www.rerun.io/ using... egui but the commercial version is still WIP.

Re: Emerging Rust GUI libraries in a WASM world

#132

Post by dragonelite »

crispinb wrote: post #46
Liberonostrud wrote: post #41

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

Slower - not really now Rust client web frameworks have improved. Don't have refs handy, but Leptos, Dioxus etc are on a par with Solid. Larger bundle sizes - yes that's still true. And not all GUIs are web GUIs, so WASM isn't the whole story.

Yeah played with some Leptos wasm and i believe something simple like their book tutorial was like 335kb or so. Not that shocking and for me personally totally acceptable. I do wish browsers would ship with their std lib for wasm. So wasm is can become more competitive on bundle sizes with Javascript which has its std lib shipped with browsers.

Re: Emerging Rust GUI libraries in a WASM world

#133

Post by PoignardAzur »

KRAKRISMOTT wrote: post #5
mcluck wrote: post #4

> GUI in Rust progresses with unprecedented speed – 3 months in Rust GUI-land is like 3 years in the mortal world. areweguiyet.rs was started almost exactly 5 years ago. That means it's been about 60 mortal years and we still don't have a definitive solution to GUIs.

That's because Rust GUI people are like Lispers and functional programmers — too obsessed with doing things correctly "from first principles" and "purity". For GUI programming, there is only one feature that matters: having a fuck ton of well supported widgets for every situation across every platform. Almost everything else is secondary. This is why HTML/CSS, Flutter (and to a lesser extent Qt) are so successful. No…

Speaking as someone working on a Rust GUI framework: how dare you say things about me that are completely accurate.

That said, it feels like it's starting to change. Lower-level components are getting stabilized, SlintUI and iced are picking up speed, etc.

Re: Emerging Rust GUI libraries in a WASM world

#134

Post by stakhanov »

vincnetas wrote: post #48
stakhanov wrote: post #28

Earlier quoted context omitted.

> Browser does not have a fuck ton of well supported widgets [...] And it works. I beg to differ. When the economics of doing UIs shifted away from APIs like Windows Forms, Carbon, JavaFX towards the current trend of doing everything in a browser, it brought with it some serious regression in how powerful and user friendly those GUIs are. With Microsoft-level resources, you can take on a mammoth engineering task like…

I beg your pardon, but why do you consider CRUD 'degenerate'?

A "degenerate special case" of a general concept, in mathematics [1], is a special case that no longer has the complexities that motivated the need for that concept in the first place.

Consider, for example, the evolution of a CRUD app that was first written in, say, the late 80s for OS/400, using an interaction style where it's all full screen forms rendered as text that you fill out with your keyboard, then submit. Say, you rewrote that app in the 00s in Windows Forms but using the same interaction design, and then again in the 20s as a browser-based app. If you look at the evolution of what happened to UI technology through the lens of that app, you won't feel like anything is amiss in 2023, but you're also kind of missing the point of having a GUI in the first place, as opposed to, say, a text terminal.

Whenever I hear "all I need is a textedit and a button" from a web developer, I kind of assume that this is what informs their viewpoint.

If you instead look at the evolution of UI technology through the lens of an app like Photoshop, it will immediately be obvious to you what it is that GUIs uniquely have to offer that, for example, text terminals can't, and why rewriting such a UI in a browser is anything but trivial.

[1] https://en.wikipedia.org/wiki/Degeneracy_(mathematics)

Re: Emerging Rust GUI libraries in a WASM world

#135

Post by [deleted] »

vincnetas wrote: post #48
stakhanov wrote: post #28

Earlier quoted context omitted.

> Browser does not have a fuck ton of well supported widgets [...] And it works. I beg to differ. When the economics of doing UIs shifted away from APIs like Windows Forms, Carbon, JavaFX towards the current trend of doing everything in a browser, it brought with it some serious regression in how powerful and user friendly those GUIs are. With Microsoft-level resources, you can take on a mammoth engineering task like…

I beg your pardon, but why do you consider CRUD 'degenerate'?

[deleted]

Re: Emerging Rust GUI libraries in a WASM world

#136

Post by mwcampbell »

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…

Lead developer of AccessKit here. I know it won't be a panacea, particularly for the non-screen-reader-related problems you point out. And about the performance problem, there's probably no getting away from the despised "enable accessibility" button. But if these types of applications are going to exist despite our wishes to the contrary, then I have to do what I can to make them accessible. It could be the difference between someone being able to do a job, complete a course, or whatever, and not. I have to do what I can to improve the accessibility of the world as it is, not the world as we wish it was.

Re: Emerging Rust GUI libraries in a WASM world

#137

Post by josephg »

horsawlarway wrote: post #122
rkagerer wrote: post #76

Earlier quoted context omitted.

Well, in fairness web-based applications (including Electron ones running locally) break most of the inspectability benefits that came before, at least on the Windows platform. eg. I used to be able to programmatically grab hWnd's (like Spy++ does), and manipulate the forms of an app. Apps used to show up as one (or two) simple processes with rich instrumentation metrics in tools like Resource Monitor. Chrome abstrac…

> Well, in fairness web-based applications (including Electron ones running locally) break most of the inspectability benefits that came before, at least on the Windows platform. eg. I used to be able to programmatically grab hWnd's (like Spy++ does), and manipulate the forms of an app. Apps used to show up as one (or two) simple processes with rich instrumentation metrics in tools like Resource Monitor. --- I disagr…

> This is my biggest issue with WASM. You're literally back at reading assembly again. And while that's possible, and there is tooling that can help - it's just not the same as being able to right-click on something, alter a couple of attributes in human readable words, hit enter and see that change.

WASM on its own isn't the problem. WASM just lets you use another language to replace javascript. When you right click on something in a browser and alter human-readable attributes, you're usually messing with CSS and HTML. Any half decent web UI framework should pass HTML and CSS to the browser in order to render the UI. Thats just as true with wasm frameworks as it is with javascript frameworks.

The problem in this example is that the wasm code is bundling its own UI library that is trying (badly) to replace the browser's layout engine. All the browser can see is a bunch of drawing calls to an html canvas. Thats not the fault of wasm. Its just this UI library, which isn't really designed for the web.

Re: Emerging Rust GUI libraries in a WASM world

#138

Post by waboremo »

mwcampbell wrote: post #136
chrismorgan wrote: post #21

Earlier quoted context omitted.

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…

Lead developer of AccessKit here. I know it won't be a panacea, particularly for the non-screen-reader-related problems you point out. And about the performance problem, there's probably no getting away from the despised "enable accessibility" button. But if these types of applications are going to exist despite our wishes to the contrary, then I have to do what I can to make them accessible. It could be the differen…

Good intentions, but this leads people to create even more apps that they then proudly proclaim are just as accessible as alternatives because of AccessKit. It's a bit of a catch-22.

Re: Emerging Rust GUI libraries in a WASM world

#139

Post by josephg »

eslaught wrote: post #44
chrismorgan wrote: post #24

Earlier quoted context omitted.

And scrolling is unavoidably all wrong: dragging two fingers from one end of my touchpad to the other should scroll by about four screenfuls, but only manages two thirds of one screenful; a quick swipe should send it dozens of screenfuls, with inertia, but manages even less than that two thirds of a screenful; and these limitations are fundamental due to the web not possessing the right primitives. (Then there are mo…

In my testing, I went through a bunch of Rust frameworks that sit on top of the core OS UI frameworks. My experience with all of those was that they all capped out at about 3k rectangles on a screen at a time at 30 fps (vs the about 80k rectangles that fit at usually 30-60 fps in my demo). I wonder if your experience is different? As best I've been able to tell, right now you have to make a choice between (a) fast an…

What domain are you working in?

Smoothly rendering 3k rectangles isn't a common use case for UI libraries, so I'm not surprised they perform poorly. They generally aren't optimized for that. The normal answer for weird, high performance rendering like that is to just use opengl or something and program against the GPU directly. 3d rendering contexts can render millions of rectangles on modern hardware without breaking a sweat.

This advice is the same on desktop, mobile or the web. I'm not surprised rust UI frameworks have the same limitation. Most UIs don't need thousands of rectangles. But they do need lots of custom widgets, and implementing all of those well is a higher priority job for anyone building a custom UI library.

Re: Emerging Rust GUI libraries in a WASM world

#140

Post by mwcampbell »

waboremo wrote: post #138
mwcampbell wrote: post #136

Earlier quoted context omitted.

Lead developer of AccessKit here. I know it won't be a panacea, particularly for the non-screen-reader-related problems you point out. And about the performance problem, there's probably no getting away from the despised "enable accessibility" button. But if these types of applications are going to exist despite our wishes to the contrary, then I have to do what I can to make them accessible. It could be the differen…

Good intentions, but this leads people to create even more apps that they then proudly proclaim are just as accessible as alternatives because of AccessKit. It's a bit of a catch-22.

I think that's less bad than someone losing their job, or failing to get a particular job, because they can't access a canvas-based app. Edit: The former isn't entirely a hypothetical; I know of a blind person who lost his job in 2006 because use of an inaccessible app (a Java applet running on the Microsoft JVM, IIUC) became a requirement. I try to keep that bigger picture in mind with everything I do in AccessKit.
Post reply on HN