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

201–210 of 272 posts

Re: Emerging Rust GUI libraries in a WASM world

#201

Post by danShumway »

josephg wrote: post #199
danShumway wrote: post #196

Earlier quoted context omitted.

> just because Canvas layers on top of WebGL/GPU draw calls, doesn't necessarily mean it's performant in the way I need it to be You are using Canvas right now. WebGL uses Canvas to render to the screen. If you open up your demo's DOM inspector right now, you will see a canvas element. It's: It's a little bit hard for me to trust this kind of dismissive talk about the browser adding too many abstraction layers when i…

> You are using Canvas right now. WebGL uses Canvas to render to the screen. Ehhh sort of. Canvas is much older than webgl. When we talked about canvas a few years ago, that always referred to the canvas DOM element and its associated 2D shape based API. (fillRect / moveTo / lineTo / etc). When Webgl appeared, the nomenclature was "using canvas" vs "using webgl", since webgl's API is completely different from the 2d…

Even in that context, it's not really accurate to say that Canvas "layers on top of WebGL"; WebGL targets the canvas element, it's not the other way around. And (correct me if I'm wrong) even when Canvas first came out, the 2D API was optional -- you could always take an array of pixels and render them onto a canvas directly and bypass all of the higher-level APIs. You always had the option to ignore the 2D API if you needed to.

If it's just a context misunderstanding of what specifically "Canvas" is referring to, fine, I don't mind clarifying what I mean by that. And you're right, it's not unreasonable for someone to see the word Canvas and think "2D APIs." But I just want to be very clear that targeting the DOM for UI controls doesn't mean you can't use WebGL or WebGPU and direct graphics programming for charts, or that you can't render a chart in a web worker and then use the pixel buffer with a canvas. And none of that stuff requires you to program in Javascript (except for glue code, which you'd have to write for all of those methods no matter what). In modern web terms when I talk about targeting the Canvas, I just mean rendering pixels onto a canvas element as opposed to manipulating the DOM, regardless of how or where those pixels are calculated.

There is no additional set of abstractions you need to go through to do that, and there's no graphical system for the web that gets rid of the singular abstraction of needing to eventually put the pixels onto a canvas element.

Yes, if you were calling browser 2D APIs, that would have an additional performance cost, definitely. In a context where that's not performant enough, then don't do that? But there seems to be a suggestion in this comment thread that embedding canvases would require working with a higher level more abstracted graphical API when rendering the charts, and that's just not true.

Re: Emerging Rust GUI libraries in a WASM world

#202

Post by anderspitman »

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…

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?

Re: Emerging Rust GUI libraries in a WASM world

#203

Post by brabel »

Conscat wrote: post #179
brabel wrote: post #62

Earlier quoted context omitted.

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.

Everybody is trying to make a more user-friendly Rust. The problem is that it is not clear yet whether that's possible, and if it is, how it may look. I know Vale and have tried it, though it's extremely early to judge anything so far. It does have a much stronger theoretical background than V, but even the theory is not completely clear at this point.

There is also Carp by the way: https://github.com/carp-lang/Carp

Re: Emerging Rust GUI libraries in a WASM world

#204

Post by alpaca128 »

crispinb wrote: post #183
alpaca128 wrote: post #148

Earlier quoted context omitted.

I can agree with that, I don't like overly abstract stuff either. That said in my projects I'm in control of the code and so I tend to avoid traits where they're not really necessary, I find Rust very pleasant to use that way and the compiler messages are simply outstanding. Often lifetime annotations can be replaced with heap allocations, which isn't always that efficient but it's a damn fast language and often you'…

Sure, despite my frustrations with it (and with the often frankly false claims about it tirelessly repeated by people who identify too strongly with it - it's a programming language, not a signed-in-blood manifesto for world peace and ubiquitous sex), I'm actually still quite engaged in using and learning Rust. It's even my main language for my own projects right now (I no longer work in tech/dev). Some of that is ju…

> I doubt I will ever get to the level of fluency where I 'just code' with it, rather than intermittent stripes of coding & fuming.

I know what you mean. I feel much more productive with it nowadays and many things just make sense now, but it took me a long, long time to get to that point. Rust is very much not beginner-friendly, and while I think it was worth it this is why it will never replace certain other languages. I don't mind the compilation speed as much as some people seem to do, but the learning curve definitely is a problem.

Re: Emerging Rust GUI libraries in a WASM world

#205

Post by IshKebab »

int_19h wrote: post #190
IshKebab wrote: post #186

Earlier quoted context omitted.

There definitely are people like that (e.g. the Xylem stuff is an attempt to make something "perfect") but a) I don't think there's anything wrong with some people doing that, and b) that clearly isn't why we don't have a 1st class Rust GUI yet. 1. There are unprincipled Rust GUIs, e.g. Egui. It works great. 2. Making a GUI framework is just bloody hard and a ton of work. I think only a small handful of languages hav…

If we look at, say, Qt 3 (2002), or even Qt 2 (1999), I'd say that the comparison is still not in favor of modern Rust UI-from-scratch toolkits.

Actually I got the dates a bit wrong - according to Wikipedia they started writing Qt in 1991. Also that was a full time commercial project. As far as I know all of the Rust GUIs except Slint are hobby projects.

Finally, modern GUIs are way more complex than they were back then - especially when it comes to graphics APIs and text handling.

So I still think it's too early to say Rust has failed when it comes to GUIs.

Re: Emerging Rust GUI libraries in a WASM world

#206

Post by pkolaczk »

alpaca128 wrote: post #204
crispinb wrote: post #183

Earlier quoted context omitted.

Sure, despite my frustrations with it (and with the often frankly false claims about it tirelessly repeated by people who identify too strongly with it - it's a programming language, not a signed-in-blood manifesto for world peace and ubiquitous sex), I'm actually still quite engaged in using and learning Rust. It's even my main language for my own projects right now (I no longer work in tech/dev). Some of that is ju…

> I doubt I will ever get to the level of fluency where I 'just code' with it, rather than intermittent stripes of coding & fuming. I know what you mean. I feel much more productive with it nowadays and many things just make sense now, but it took me a long, long time to get to that point. Rust is very much not beginner-friendly, and while I think it was worth it this is why it will never replace certain other langua…

Prior experience and preferred style of programming can affect severely the difficulty of learning Rust. For me it was mostly 1 week of struggling a bit with the borrow-checker and even that only in places where I really wanted to avoid copies / allocations at all cost - achieving something I wouldn't be able to do at all in other languages. Later I realized that if you are ok with an occasional clone here and there, the borrow checker almost never stands in the way. And realizing I can move owned stuff around cheaply instead of copying/referencing was also another huge enabler.

However I can imagine when Rust borrowing rules can be a huge pain. This happens when you expect to continue using the same style of programming that relies on big piles of (often cyclic) object graphs built with references/pointers, shared mutability, heavy (runtime) indirection and inheritance. A style that is so prevalent in OOP projects written in Java, JS, Python. I don't like this style at all, and always tried to avoid it even when coding in those languages, because I believe it causes more harm than good. Rust will simply force you to unlearn it. And some people won't need to unlearn much, and some will have to unlearn a lot. Changing habits is always pain.

I think it should be simply considered a different paradigm.

Re: Emerging Rust GUI libraries in a WASM world

#207

Post by ocornut »

osener wrote: post #74
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…

What makes egui so fast? I thought immediate mode GUIs have a convenient API at the expense of unnecessary redraws and lower performance. Would it be faster than iced or Slint at rendering scrollable list with thousands of rows with images and text? For the sort of use case you’d use a “virtualized list” implementation for React for example.

Also try mouse-wheeling in Tracy web version (using Dear ImGui) and opening different panels: https://tracy.nereid.pl/ I think you'll find it to be more reactive and snappier than most traditional toolkits.

Re: Emerging Rust GUI libraries in a WASM world

#208

Post by crispinb »

pkolaczk wrote: post #206
alpaca128 wrote: post #204

Earlier quoted context omitted.

> I doubt I will ever get to the level of fluency where I 'just code' with it, rather than intermittent stripes of coding & fuming. I know what you mean. I feel much more productive with it nowadays and many things just make sense now, but it took me a long, long time to get to that point. Rust is very much not beginner-friendly, and while I think it was worth it this is why it will never replace certain other langua…

Prior experience and preferred style of programming can affect severely the difficulty of learning Rust. For me it was mostly 1 week of struggling a bit with the borrow-checker and even that only in places where I really wanted to avoid copies / allocations at all cost - achieving something I wouldn't be able to do at all in other languages. Later I realized that if you are ok with an occasional clone here and there,…

> 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 productive in the language.

Of course my experience is just one person's sample. There isn't much else to go one. But the Rust Foundation clearly agrees with me, given its 2024 roadmap. In our view, Rust is hard to learn and use, more than most languages, and problematically so for many.

Re: Emerging Rust GUI libraries in a WASM world

#209

Post by weinzierl »

crispinb wrote: post #42
weinzierl wrote: post #38

Earlier quoted context omitted.

Maybe you are right but it sounds a bit like: "For GUI design there is only one feature that matters: having a fuck ton of well supported colors for every situation across every platform." Replace colors with fonts or animated GIFs and you and up in late 90s web design.

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 implemented and sloppily maintained that matches like 85% of your customers requirements - and that's what most non-standard widgets are.

Quality and consistency trump quantity in my opinion.

Re: Emerging Rust GUI libraries in a WASM world

#210

Post by ljsb »

davidatbu wrote: post #197
ljsb wrote: post #108

I hope it's OK to add a shameless plug for my Rust WASM framework, Silkenweb [0]. It's similar to Leptos and Sycamore in that it's signals based, but I've put a lot of effort into making it ergonomic without resorting to a macro DSL. It supports all the usual things like SSR and hydration, along with a few nice extras like scoped CSS. [0] https://github.com/silkenweb/silkenweb

While I'm usually a no-macros kinda guy, but (I believe) leptos and dioxus provide tooling to hot-reload markup-only changes without (incremental) recompilation. Do you think that would be possible withour macros?

I can't think of any practical way to do that without macros, unfortunately. I've found incremental compilation to be pretty speedy for small markup changes so far though. I do tend to put the presentation code in it's own crate for larger projects, which might make a difference. Maybe as my projects get bigger I'll start to run into problems.

Some other ideas:

- Temporarily stopping the rust-analyser server to avoid lock contention on the build dir.

- Using cranelift codegen backend (not sure of it's current status).

Post reply on HN