[dead]
Emerging Rust GUI libraries in a WASM world
261–270 of 272 posts
Re: Emerging Rust GUI libraries in a WASM world
#262[dead]
Re: Emerging Rust GUI libraries in a WASM world
#263[dead]
Re: Emerging Rust GUI libraries in a WASM world
#264[dead]
Re: Emerging Rust GUI libraries in a WASM world
#265[dead]
Re: Emerging Rust GUI libraries in a WASM world
#266[dead]
Re: Emerging Rust GUI libraries in a WASM world
#267Searched 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 it's interesting that we take it for granted that accessibility is primarily the responsibility of GUI toolkit developers. I would think that maybe some amount of blame would fall on OS vendors, who have billions of dollars flowing through their organizations, rather than some random open source projects.
If your app can be described to a screen reader, then there should be an easy cross platform API[0] for GUI toolkit makers to use, provided by the underlying platform in a reasonably simple way.
[0]: I am aware of AccessKit. Where's the OS backing?
Re: Emerging Rust GUI libraries in a WASM world
#268Earlier quoted context omitted.
Should you be changing 3K rectangles of your interface at 30fps? This seems like a very narrow use case that should be restricted to using Canvas with very specific parts of the application. Maybe you have graphs/charts that need that kind of rendering effect. Great, use Canvas for them, they're not accessible anyway. But if something like your main user controls are running into that problem, I feel like something h…
Maybe I'm misunderstanding you, but shouldn't this be the GUI toolkit's job, ie choosing what to render as native HTML vs what needs to rendered to canvas? Can you recommend an alternative to egui that let's you write entirely in Rust and get the performance of egui but still maintain some level of accessibility?
> shouldn't this be the GUI toolkit's job
Ideally yes. This is a failing of the egui toolkit, not necessarily a failing of the people using it. The whole point of a high-level toolkit like this is that you shouldn't have to worry about how things are being rendered.
However, it is still important to counter claims that egui is making if the people using the toolkit are parroting those claims.
> Can you recommend an alternative to egui that let's you write entirely in Rust and get the performance of egui but still maintain some level of accessibility?
I don't think I've ever built a web GUI in Rust so I have no idea what the ecosystem looks like. To my detriment, I tend to build most of my UIs from scratch. I can promise that it is possible to have performant UIs with a lot of embedded charts (like this demo has) using the DOM, but I have no idea what Rust framework devs have been getting up to or publishing.
There's also a little bit of a catch-22 here because yes, any time you introduce the DOM, you are going to lose some performance. That doesn't mean that you're going to lose so much performance that the demo above would be stuttery or wouldn't work. But if you're just measuring "how many quads can I refresh on the screen", that's kind of missing the point that you really shouldn't be refreshing thousands and thousands of quads of information in a UI at 60fps. That's not a thing that most interfaces should be doing in the first place.
And if you are genuinely changing thousands of boxes of information on a screen at the same time, kind of by definition that isn't accessible period. There is no way to present that volume of informational change to a screen reader in a way that will be understandable. But a lot of people when building UIs tend to think they're in the rare cases where they need that level of performance and so they need to sacrifice that accessibility, when in reality what they actually have is a giant list of charts and aside from the actual chart rendering, there's nothing particularly expensive going on.
Re: Emerging Rust GUI libraries in a WASM world
#269Earlier quoted context omitted.
> I think it should be simply considered a different paradigm. I addressed this above and believe it to be an unconvincing explanation of Rust's difficulty. Many polyglot programmers comfortable with, and experienced in, switching (and learning new) paradigms, still find Rust more difficult than other languages they have learned. In my experience most just give up. I haven't, but neither have I become remotely produc…
How come Rust appears at the top of most loved languages in the SO survey so many years in a row? And doesn't even make into the "most dreaded" list at all (when many simpler languages do make into that list)? Also, there aren't any other mainstream languages with borrow checker at the moment. The problem with Rust is that it introduces many novel ideas, not just some old ideas wrapped in a different syntax (e.g. lik…
However often you inform someone that they are wrong about what they found difficult, it will not thusly become true. Your brutish & obdurate insistence is only boring.
The difference between what you and I are claiming isn't in the substantive content, it's that you, Shiny Happy Rust Person-style (exemplifying what many of us find so ugly and bullying about the much-vaunted "Rust community") insist on universalising your personal experience.
I've already told you that novelty is nothing whatsoever to do with why I find Rust difficult. It has few novel concepts, and they are simple enough. Note that I never mentioned the fucking borrow checker. Now fuck off. I've blocked you anyway.
Re: Emerging Rust GUI libraries in a WASM world
#270Earlier quoted context omitted.
I don't think that's quite the point. It's not that you want dozens of different widgets in every app. It's that when picking an ecosystem for apps, a business will want to know that whatever they need (whatever small sample from that multitude), it's available. A large pool of resources is particularly important when you don't know exactly what you'll need up front, which is most of the time. You might only want 8 c…
I used to think like that, but it doesn't match my experience from my years of building (traditional) GUIs. I believe it is almost always better to stick to the couple of standard widgets that are available everywhere and known by everyone. In the very rare cases it's not it is better to build a custom widget that matches your customers requirements exactly. Nothing is worse than a half-baked GUI element idea, badly…
It matches my experience precisely. Every time I've seen a GUI framework/library chosen that didn't have a huge head of steam behind it and very broad availability of off the shelf components and tooling, the project has either failed, or had to be rewritten after a swerve. This is for relatively mainstream software (consumer apps). Niches are another matter.