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

171–180 of 272 posts

Re: Emerging Rust GUI libraries in a WASM world

#171

Post by chrismorgan »

danShumway wrote: post #164
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…

The performance point in your linked post is worth highlighting: I see a lot of developers complaining "if the web had an accessibility API for this, then it wouldn't be a problem." The web does have an accessibility API. It's called the DOM. What developers are upset about is that they have to make their apps performant in that accessibility layer. The DOM restricts you from developing a fast app for sighted users a…

The crux of the web’s accessibility performance problem (minor in general, but major once you try to add accessibility to a canvas) is that it requires that everything be materialised at once and ahead of time, regardless of whether it’s being used. By contrast, the browser itself is able to lazily and (on most or all platforms, I believe) partially construct the accessibility tree. (mwcampbell can correct me if I’ve misunderstood how various platforms work.)

Browsers seem to have resisted adding fundamental alternatives of construct-on-query accessibility trees, or some kind of “I need AT stuff” switch so you can skip setting ARIA attributes or materialising other DOM if it’s not going to be used.

The end result is that the web doesn’t properly support accessible virtualised scrolling (where you have a hundred thousand emails in a mailbox, but only render the ones on screen, still providing a meaningful scrollbar) or infinite scrolling. There’s role=feed which improves matters in most screen reader configurations, but it’s still making some compromises. But then, virtualised scrolling is imperfect even for non-AT use—things like browser find-in-page won’t work properly. Still more of the “if you want it to work properly, it has to exist in the DOM all the time” stuff.

Re: Emerging Rust GUI libraries in a WASM world

#172

Post by chrismorgan »

mwcampbell wrote: post #140
waboremo wrote: post #138

Earlier quoted context omitted.

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.

I just wish that the people that make canvas-based web stuff would realise how awful it is and tell people. I’ve interacted with a Flutter web thing once, for something that was only targeting the web. It was very painful. Flutter was completely the wrong tool for the job. But when they advertise their stuff, do they say “look, it kinda supports the web, but if you’re actually trying to target the web, please don’t use this because it’s just not good, and can’t be good unless we rip out the canvas stuff and render to real DOM elements”? Almost never.

Re: Emerging Rust GUI libraries in a WASM world

#173

Post by mwcampbell »

chrismorgan wrote: post #172
mwcampbell wrote: post #140

Earlier quoted context omitted.

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.

I just wish that the people that make canvas-based web stuff would realise how awful it is and tell people. I’ve interacted with a Flutter web thing once, for something that was only targeting the web . It was very painful. Flutter was completely the wrong tool for the job. But when they advertise their stuff, do they say “look, it kinda supports the web, but if you’re actually trying to target the web, please don’t…

When I do work on a web backend for AccessKit, I will be completely forthcoming about the limitations in the documentation.

Re: Emerging Rust GUI libraries in a WASM world

#174

Post by zelphirkalt »

klodolph wrote: post #23
KRAKRISMOTT wrote: post #5

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

I think that you’re right, and broadly speaking, there’s an inverse correlation between how invested someone is in programming and how invested someone is in the problem domain. Could be Berkson’s paradox at play here, but I think that it’s really a question of opportunity cost—the time you spend becoming a better programmer is time you could have spent learning some problem domain that you could solve with programmi…

There is also some correlation between how solid the base is and how long a library/package/project is used, before it is cast aside for a new hip and trendy one.

Re: Emerging Rust GUI libraries in a WASM world

#175

Post by mwcampbell »

chrismorgan wrote: post #171
danShumway wrote: post #164

Earlier quoted context omitted.

The performance point in your linked post is worth highlighting: I see a lot of developers complaining "if the web had an accessibility API for this, then it wouldn't be a problem." The web does have an accessibility API. It's called the DOM. What developers are upset about is that they have to make their apps performant in that accessibility layer. The DOM restricts you from developing a fast app for sighted users a…

The crux of the web’s accessibility performance problem (minor in general, but major once you try to add accessibility to a canvas) is that it requires that everything be materialised at once and ahead of time, regardless of whether it’s being used. By contrast, the browser itself is able to lazily and (on most or all platforms, I believe) partially construct the accessibility tree. (mwcampbell can correct me if I’ve…

You're completely right about platform-native accessibility APIs.

To be honest, AccessKit itself doesn't support lazy accessibility trees for virtualized scrolling, at least not yet. It can avoid constructing the accessibility tree completely if the platform accessibility API isn't queried at all, but there isn't yet a way to only partially construct an accessibility tree while indicating that there's more available on demand. So to some extent, I guess AccessKit brings this web performance problem to native.

Re: Emerging Rust GUI libraries in a WASM world

#176

Post by chrismorgan »

LeanderK wrote: post #95
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…

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

I believe you’ve misunderstood my intent. When I speak of the pure canvas approach, I mean throwing away almost all that the browser gives you, and rendering everything in a single canvas, with fake scrolling, fake links, &c.

For individual widgets like data visualisation, go ahead, use canvas if you want; I won’t complain—though make sure if you have any links in it that you have actual links on top of the canvas for the user to interact with. And also consider if you can SVG. Anyway, individual canvases are fine; but don’t put everything in a single canvas.

Things like Google Docs and Figma are often cited as examples of how canvas-based rendering can be not bad, but neither are pure canvas: the user interface of both is full DOM, and it’s only the document area that’s canvas. (Also, I find Google Docs somewhat unpleasant: its rendering latency and throughput while you type is terrible, and keyboard caret navigation doesn’t match my platform’s behaviour in many places.)

See also https://news.ycombinator.com/item?id=33863185 (similar content to this comment).

Re: Emerging Rust GUI libraries in a WASM world

#177

Post by danShumway »

chrismorgan wrote: post #171
danShumway wrote: post #164

Earlier quoted context omitted.

The performance point in your linked post is worth highlighting: I see a lot of developers complaining "if the web had an accessibility API for this, then it wouldn't be a problem." The web does have an accessibility API. It's called the DOM. What developers are upset about is that they have to make their apps performant in that accessibility layer. The DOM restricts you from developing a fast app for sighted users a…

The crux of the web’s accessibility performance problem (minor in general, but major once you try to add accessibility to a canvas) is that it requires that everything be materialised at once and ahead of time, regardless of whether it’s being used. By contrast, the browser itself is able to lazily and (on most or all platforms, I believe) partially construct the accessibility tree. (mwcampbell can correct me if I’ve…

Okay, that is a fair point on virtualized scrolling, and while I can somewhat point to reasons why that's the case they're not strictly related to accessibility. They're more an API/extension concern than an accessibility concern, I guess.

That being said... I have also kind of soured on virtualized scrolling over time as I've spent more time working on UX projects, and I realize that sort of sounds like an excuse (we don't support this well, but you shouldn't be doing it anyway), but... I do kind of feel like infinite scrolling and giant lists of elements to the point where the list needs to be virtualized is bad UX for most apps.

----

And to be clear, I'm not necessarily saying that the DOM is perfect as an accessibility tree, just that it's good enough compared to the kinds of accessibility APIs that most native devs want when they complain about the DOM. In practice, a full-featured accessibility API with the same feature-set as the DOM and the same level of capabilities would likely have performance costs no matter how it was implemented in the browser.

Sure it could be better. But also all of those improvements could just be added to the DOM instead of making a new native web API. The biggest difference between adding those improvements to the DOM vs reconstructing something very similar to the DOM as a separate browser API is that devs could ignore the performance costs of that API and only benchmark their apps with the accessibility API turned off.

And I think it's good for devs not to have that option (or at least, for browsers themselves not to directly provide that option; again I'm not saying that I don't think AccessKit should exist).

Re: Emerging Rust GUI libraries in a WASM world

#178

Post by Aerbil313 »

danShumway wrote: post #169
waboremo wrote: post #138

Earlier quoted context omitted.

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.

It's far better that AccessKit exist than that it not. That being said, yeah, there are people in this very comment section saying that of course egui is accessible, it supports AccessKit. So it's not really theoretical, any attempt to close the gap with AccessKit is going to be used by people as an excuse to build inaccessible applications. That's already happening in this comment section right now. But that doesn't…

I think many people, especially SV devs whose job is finding solutions to problems, forget that there are no solutions to some problems. That only solution to these problems is to not pursue what causes the problem altogether.

Re: Emerging Rust GUI libraries in a WASM world

#179

Post by Conscat »

brabel wrote: post #62
TobyTheDog123 wrote: post #45

Earlier quoted context omitted.

I remember looking into V last year, it seems most of the discussion surrounding it was that it was vaporware. Is that not the case? It certainly looks nice, but is it ready for use?

The main issue was that V promised automatic memory management like Rust, but without the "trouble" caused by the borrow checker, which is something anyone who knows about the problem more deeply would laugh at.... last I checked, they were still at the same stage as a few years ago with that: "it will be working soon". It will almost certainly always stay there.

Have you tried Vale or Lobster though? Research in memory management semantics is a lot more sophisticated than you might think.
Post reply on HN