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

181–190 of 272 posts

Re: Emerging Rust GUI libraries in a WASM world

#181

Post by mwcampbell »

Aerbil313 wrote: post #178
danShumway wrote: post #169

Earlier quoted context omitted.

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.

Yes, it would be better if web applications that use canvas for their whole UI didn't exist. But they do, and I'm sure there will be more of them. I won't be able to persuade developers to stop developing apps this way. So I have to do what I can to help make them accessible, however imperfectly.

Re: Emerging Rust GUI libraries in a WASM world

#182

Post by danShumway »

mwcampbell wrote: post #181
Aerbil313 wrote: post #178

Earlier quoted context omitted.

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.

Yes, it would be better if web applications that use canvas for their whole UI didn't exist. But they do, and I'm sure there will be more of them. I won't be able to persuade developers to stop developing apps this way. So I have to do what I can to help make them accessible, however imperfectly.

Right; to be clear, my issue is not with AccessKit or really any of the work you're doing here. I'm really happy that AccessKit exists, I'm glad that you're working on it.

AccessKit is trying to help fix a problem as best it can. My issue is with the people and frameworks that are causing the problem.

Re: Emerging Rust GUI libraries in a WASM world

#183

Post by crispinb »

alpaca128 wrote: post #148
crispinb wrote: post #124

Earlier quoted context omitted.

I don't have a problem with Rust syntax. Actually I can't imagine any developer with more than a year or two's experience has much trouble with any language syntax (unless it's something truly weird like APL). After a few days use you barely notice surface details anyway - it's just one possible representation of an AST. My problem with using Rust is the way its complexity creeps into everything. There are large numb…

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 just stubbornness (because I find it hard), but some practical (performance, WASMability etc). I do like the way the type system makes it seem like things snick precisely into place when you get things right.

My beef (such as it is) is that I doubt I will ever get to the level of fluency where I 'just code' with it, rather than intermittent stripes of coding & fuming. It takes me probably 4x as long to do anything compared to any other language I've used (and although I'm not a talented programmer, I am a polyglot).

Oddly on the cli parsing thing, I did end up finding a library I like - bpaf. It's kind of abstract but seems more conceptually principled than the near-universal clap. The kind of abstraction where once you have grasped a small set of orthogonal concepts, you can just combine them at will, seems OK to me. As contrasted with the type which has dozens of small rules, and special cases that rely heavily on (human) memory and/or constant doc lookups.

Re: Emerging Rust GUI libraries in a WASM world

#184

Post by klodolph »

zelphirkalt wrote: post #174
klodolph wrote: post #23

Earlier quoted context omitted.

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.

Maybe. My sense is that there’s a finite amount of developer energy you have to allocate between different concerns. If you think of R, the language, as a base, then it’s definitely NOT a solid base (in my estimation). If you see it as a continuation of S, then it’s nearly 50 years of use for something you wouldn’t want to build on.

I’ll say the same thing about R+statistics as I will for Python+machine learning, for C++&game development / OpenCV, or Fortran and scientific computing. Having domain experts actually use your language to solve problems is such a massive advantage that you can almost ignore the benefits and drawbacks of the language itself. Almost.

Re: Emerging Rust GUI libraries in a WASM world

#185

Post by crispinb »

bsaul wrote: post #100
crispinb wrote: post #30

I doubt Rust is going to become used for (the GUI layer of) GUI apps far outside of Rust enthusiast circles. To build a widely attractive ecosystem it needs a dominant framework to which enough of the many widget and theming and distribution libraries and tools necessary for broad adoption attach. Rust's culture in this respect is far more Clojure (bolt together your own from a thousand options) than Elixir (just use…

My guess is Rust is going to experience its first test in the next two years, where the general people will see what it's really good for, and what's it not, because it won't be the "new hot thing" anymore. Only then we will know if it has chance of really becoming widely used as a general purpose PL.

If by 'general purpose PL' you mean one used to write mainstream GUI apps, I nearly agree though I'd bet against Rust on that score.

If however you mean one used across a wide variety of industries, software types, and hardware, I think its future is already assured there. My own guess is that Rust will become quite ubiquitous for the performant and stable core of many software systems, with the interactive levels handled by other languages.

Re: Emerging Rust GUI libraries in a WASM world

#186

Post by IshKebab »

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…

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 have native GUI toolkits. Most just wrap C or HTML.

GTK is 25 years old and Qt is 27 years old. I don't think 5 years is long enough to develop a mature GUI toolkit (unless you have an enormous company backing you maybe).

Re: Emerging Rust GUI libraries in a WASM world

#187

Post by eslaught »

danShumway wrote: post #165
eslaught wrote: post #159

Earlier quoted context omitted.

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…

> I'm not sure Canvas can handle either part of this To be clear, WebGL/WebGPU is still using Canvas. You're not using the 2D api stuff, but that's just a high-level API on top of Canvas. You're still rendering to Canvas. > I don't know if you noticed, but my test has on the order of 10 billion rectangles Why? I've built apps like this before. Your choice is not "abandon the DOM" or "have zero performance." You can h…

If you build an equivalent tech demo in HTML Canvas, I'd be curious to see how it performs. I'm sure you're aware that, 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. There are many ways for performance to degrade across abstraction layers, even if in principle it shouldn't.

I didn't test Canvas specifically in my explorations, but I did test a few JavaScript based frameworks, and the ones I found that were efficient sat on top of WebGL, not Canvas. Ultimately I didn't pick those because they had a bunch of other stuff baked in that I didn't need or want, and were already equally non-native (sitting on top of WebGL). And I frankly didn't want to be writing JavaScript.

Re: Emerging Rust GUI libraries in a WASM world

#188

Post by IX-103 »

eslaught wrote: post #162
josephg wrote: post #139

Earlier quoted context omitted.

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

Like I said in my top comment, it's a profiler. I need to consume logs from distributed applications (on possibly tens of thousands of nodes) and render them in as coherent a fashion as possible. Going to 3d rendering via OpenGL / WebGL was one of the options I considered. But honestly, this is a boatload of complexity. Why do I need to pick up a full 3D rendering library just to draw rectangles on the screen? Plus,…

The reason to pick up a "a full 3D rendering library" is that it is actually a lower level interface to the hardware. Almost all 2D operations are now implemented on top of 3D hardware primitives.

By limiting yourself to a 2D engine you're ensuring there are more layers of abstraction between you and the hardware. While # layers of abstraction doesn't always correlate with overhead, it does place limits on performance.

Re: Emerging Rust GUI libraries in a WASM world

#189

Post by int_19h »

echelon wrote: post #25
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…

Obligatory jaw-dropping egui demo: https://www.egui.rs/#demo Egui slaps and is clearly going places.

The first thing I noticed here is that the textbox doesn't have the usual context menu with commands like "Select all" and various IME features. It's not clear whether RTL and bidirectional capabilities are there, and if so, how to use them.

Next I clicked on the combo box, it opens the dropdown, and I try to use arrow keys to navigate it. That doesn't work. Is that because I opened it using the mouse? Nope, still doesn't work if you tab through the widgets and use Enter to open. Looking up items by typing the first few characters doesn't work, either.

This is all really basic stuff that native widgets offer to any app for free on any platform.

Re: Emerging Rust GUI libraries in a WASM world

#190

Post by int_19h »

IshKebab wrote: post #186
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…

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.
Post reply on HN