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

151–160 of 272 posts

Re: Emerging Rust GUI libraries in a WASM world

#151

Post by bmikaili »

jeroenhd wrote: post #72
baq wrote: post #69

Earlier quoted context omitted.

I love typescript, but hate the JavaScript parts of it.

With a good linter config set super strictly, you can make Typescript feel like you're barely writing Javascript at all. Any Javascript devs will probably hate working like that because now they're forced to write types for absolutely every single thing, but to me it felt like Javascript was finally fixed. Just banning things like "any" and enforcing proper nullability makes up for a lot of Javascript problems.

This is the worst part of JS. To make it workable u have to:

- setup linting (which is awful and annoying) - formatting - use typescript

and then maybe u have a usable work environment. Rust just does that out of the box.

Re: Emerging Rust GUI libraries in a WASM world

#152

Post by TobyTheDog123 »

jeroenhd wrote: post #72
baq wrote: post #69

Earlier quoted context omitted.

I love typescript, but hate the JavaScript parts of it.

With a good linter config set super strictly, you can make Typescript feel like you're barely writing Javascript at all. Any Javascript devs will probably hate working like that because now they're forced to write types for absolutely every single thing, but to me it felt like Javascript was finally fixed. Just banning things like "any" and enforcing proper nullability makes up for a lot of Javascript problems.

I disagree - Javascript's issues are not just its lack of type safety.

Even with Typescript you're dealing with the disastrous state of NPM/configuration/linters/formatters/libraries -- all of which are firmly Javascript-esque plagues (though not exclusively Javascript plagues).

Re: Emerging Rust GUI libraries in a WASM world

#153

Post by revelio »

alkonaut wrote: post #126
mcluck wrote: post #105

Earlier quoted context omitted.

Of course you'll always have different ways of building UIs depending on circumstances but eventually some consensus will be reached for a default approach. WinForms used to be the default for Windows, Tk was the default for Linux (or at least that was my impression, I was all in on Windows back then), etc. For many people, using web tech has become the default if you want to build cross platform UIs. You have the op…

OSes that come with a native UI obviously have that as the default. But there will never be a default across OSes I think. Web UIs might be that, but I sure won't want to use html or js anywhere in my UI's if I can help it, even if cross platform. Java might perhaps be the best example of trying to make a default-for-a-language cross platform UI (Swing and whatever it was called that came before it). But I think it's…

Swing is pretty nice UX these days actually. Try the very latest IntelliJ in "new ui" mode, it looks modern and has an incredibly productive UI with tons of keyboard shortcuts, specialized widgets, etc.

The API is a bit old now, but you could easily put a reactive layer on top.

Re: Emerging Rust GUI libraries in a WASM world

#154

Post by galangalalgol »

josephg wrote: post #141
galangalalgol wrote: post #99

Earlier quoted context omitted.

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.

Its certainly controversial. Using canvas based rendering like this is essentially reverse-electron. Electron builds native software by embedding a web browser and using the browser's layout engine and DOM. Canvas based rendering like this is the inverse. Here the application discards the browser's layout engine and DOM, and instead embeds its own layout engine. - Despite the browser being right there and available.…

I'm curious to see if they took every effort to strip that demo down or not. I think eframe doesn't get a ton smaller than 2mb no matter what you do, so maybe they did.

Re: Emerging Rust GUI libraries in a WASM world

#155

Post by danShumway »

eslaught wrote: post #39
josephg wrote: post #22

Earlier quoted context omitted.

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…

I have no beef with deferred mode GUIs except that I have yet to see one with the performance characteristics I need. For what it's worth, egui does have an accessibility layer. I haven't gone to any particular effort to wire it up yet (besides what you get by default): https://github.com/emilk/egui/issues/167

This is what I don't get: if you have an accessibility layer that is fully usable, that means you have the capability to describe your user interface using only speech/text.

So what are you doing that couldn't be performant in the DOM? Because any kind of fast updates that you're doing with a lot of triangle that are too fast to render into an XML tree are also going to be happening too fast to describe with a screen reader.

The DOM is asking you to be able to describe your interface -- performantly -- in entirely pure text. If you can't do that, then there's no way you can be fully accessible, because the screen reader needs to be able to describe your interface -- performantly -- in entirely pure text.

Re: Emerging Rust GUI libraries in a WASM world

#156

Post by danShumway »

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…

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 has probably gone wrong with your user interface.

In the demo you linked, it makes a lot of sense to render to Canvas for the individual charts, flame charts, breakdowns. It does not make sense to me to render to Canvas for the sidebar. It doesn't make sense to me that the list element itself holding the charts is going through Canvas. That's something in your UI that honestly shouldn't be updating at the speed you're talking about.

Re: Emerging Rust GUI libraries in a WASM world

#157

Post by danShumway »

flohofwoe wrote: post #97
josephg wrote: post #22

Earlier quoted context omitted.

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

> Accessibility could be fixed easily if there would be a web accessibility API

It does have one. The DOM is the web accessibility API. A really big point of the DOM is that you don't get to make multiple interfaces, you have to make one interface that works for everyone, which forces you to provide some degree of feature parity between those interfaces.

The web accessibility API is "you have to describe your interface to us in pure text, because that format is more likely to be accessible."

Re: Emerging Rust GUI libraries in a WASM world

#158

Post by eslaught »

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

It sounds like you want BokehJS. It was one of the alternatives I was recommended while I was exploring, but for various reasons my particular use case is not so easy to integrate (plus my backend was already in Rust).

https://github.com/bokeh/bokeh

I did do a basic test, and the raw rects-on-screen performance is roughly comparable to my final solution.

Re: Emerging Rust GUI libraries in a WASM world

#159

Post by eslaught »

danShumway wrote: post #156
eslaught wrote: post #44

Earlier quoted context omitted.

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…

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…

I don't know if you noticed, but my test has on the order of 10 billion rectangles. Only about 80k are drawn on the screen at once because I do very aggressive culling.

To be honest, I'm not sure Canvas can handle either part of this: either drawing 80k rectangles at 60 fps or culling so that the other 10 billion don't need to waste CPU cycles. It requires a very tight integration with the UI library to make sure we do this fast.

Yes, it's a very narrow use case. That's why I went with a specialized UI library.

Re: Emerging Rust GUI libraries in a WASM world

#160

Post by SnowProblem »

mwcampbell wrote: post #149
josephg wrote: post #145

Earlier quoted context omitted.

Rust doesn't have to output more code than a C compiler. But it tends to because most rust programs are stuffed full of bounds checks. And bounds checks aren't small. As well as the conditional itself, every bounds check also includes: - A custom panic message (so you know which line of code crashed) - Some monomorphized formatting code to output that message - The infrastructure to generate a stack trace after a pan…

I'd appreciate any more tips or resources you might have about reducing Rust code bloat. I want my library [1] to be acceptable to the most strident anti-bloat curmudgeons, so they'll make their UIs accessible. [1]: https://github.com/AccessKit/accesskit

Great project - this is important! Love your clear motivation statement at the top. I do wish there were some code/data examples within the README, but clearly that's not holding people back from using it.
Post reply on HN