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

81–90 of 272 posts

Re: Emerging Rust GUI libraries in a WASM world

#81

Post by alkonaut »

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.

Would there ever be a "definitive" solution to GUIs? Like some canonical "this is how you GUI in Rust"? I mean there are about zero other languages where that has happened, how would Rust be any different? Just for N simple binary choices like immediate/retained, single/cross platform, markup/non-markup, native/non-native controls and so on, you'd quickly end up with 2^N solutions that almost have to coexist because some of those choices are deal breakers for some.

Re: Emerging Rust GUI libraries in a WASM world

#82

Post by bschwindHN »

echelon wrote: post #77
bschwindHN wrote: post #70

Earlier quoted context omitted.

egui is nice for internal tools, and for quickly creating UIs for games and such, but I don't think I'd ever release a consumer-facing app with it. It has too many quirks compared to a more "native" UI that it can be quite awkward to use interfaces made with it. I'm talking about things like inertial scrolling, text selection, window resizing, etc. It's certainly nice to work with from a developer's perspective, what…

For this there's Leptos and a half dozen other "DOM in Rust" frontend frameworks: https://github.com/leptos-rs/leptos These are already orders of magnitude faster than React, and as the WASM DOM bridge improves, they will only get faster. Sycamore: https://github.com/sycamore-rs/sycamore https://sycamore-rs.netlify.app/examples/todomvc/# Dioxus: https://dioxuslabs.com/ In about 3-5 years these frameworks will start t…

Yep, my current favorites are Axum and Dioxus for web things (and some desktop apps too).

Re: Emerging Rust GUI libraries in a WASM world

#83

Post by crispinb »

pkolaczk wrote: post #78
alpaca128 wrote: post #56

Earlier quoted context omitted.

> The learning curve for Rust is simply too high (my GOD the syntax) The syntax isn't even close to being a difficult part of the language, and it's something you get used to very quickly. The Rust syntax just isn't readable for people who don't yet know Rust, just like I find C++ difficult to read. > You can just get much more done, in less time with a web framework. Sure, you can also get it running even quicker in…

This is a matter of familiarity. For example, Golang is claimed to have simple syntax, but I find Golang's syntax much harder to read than Rust. The fact they avoided keywords and symbols like a plague caused that now e.g. function signatures are mostly names, spaces and parentheses, and the meaning of them depends on their relative positions, which is something I'm not used to. I guess if I wrote / read Golang sourc…

> This is a matter of familiarity

No it is not. Or at least not for everyone.

I have learned several languages more unfamiliar to me than Rust (pure functional, logic, stack-oriented,etc), but none has given me the difficulties Rust has. Also (only my sample of course, but there are no reliable stats) no-one I personally know who has gone through the Rust book has continued with Rust. The Rust Foundation hasn't made 'flattening the learning curve' one of its 2024 goals because people don't find Rust harder than other languages. Many just do.

A false universal doesn't become true through brute repetition.

Re: Emerging Rust GUI libraries in a WASM world

#84

Post by moonchrome »

vbezhenar wrote: post #9
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'd argue that the most successful UI platform is a browser. And guess what? Browser does not have a fuck ton of well supported widgets. All it does it some button with outdated UI, few inputs nobody really uses and dropdown select suitable only for the most basic uses. Anything other built on divs with CSS and JS. And it works. So my opinion is that it's definitely solid foundations what matters. Rest will come with…

>Browser does not have a fuck ton of well supported widgets

What are you talking about ? HTML and CSS is full of widget libraries, it's the best cross platform widget library out there.

Ease of deployment + reach is the driving force behind improving the platform, but at the present nothing in Rust can even compare to something like Material UI. And let's not even go into stuff like date range picker components and shit where companies probably spent millions in engineering effort to get them right (eg. AirBnB) .

Re: Emerging Rust GUI libraries in a WASM world

#86

Post by DanielHB »

SnowProblem wrote: post #55
andyp-kw wrote: post #49

Earlier quoted context omitted.

My understanding that WASM has a heavier load time, however actual benchmarks after the initial load are more impressive.

It’s not WASMs fault. Rust produces large binaries for whatever reason and people like to write their WASM in Rust. I’ve ported Rust to equivalent C and it was 25% of the size and similarly for loading times.

it is rather simple, JS tooling cares A LOT about the size of their dependency tree. Statically compiled languages do not (except if they focus on embedded programming). Having a binary be 2mb vs 30mb is not a big deal for a desktop application

Just for reference I was testing this the other day and compiled some simple C++ to WASM and adding:

std::cout to the code increased the binary size by like 5mb. Turns out std:cout pulls ALL currency-formating, date-formating and i18n code in the c++ standard library into your binary

ansi C printf does not meaningfully increase your WASM binary size

If you want your code to be able to be loaded on-the-fly and fast you need bundling tools, just like JS does. Bundling is a really hard problem, game devs struggle a lot with it as well (although their problem is usually bundling assets, not code itself)

Re: Emerging Rust GUI libraries in a WASM world

#87

Post by arethuza »

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.

That looks awesome - are there any accessibility features (e.g. supporting screen-readers)?

Re: Emerging Rust GUI libraries in a WASM world

#88

Post by keyle »

josephg wrote: post #22
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…

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…

That's nothing new with immediate rendering... You can't have great performance and great usability. Not saying I prefer that way, just pointing out the obvious.

Re: Emerging Rust GUI libraries in a WASM world

#89

Post by ReleaseCandidat »

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…

I understand that this is a demo, but actually drawing all 8,000 nodes instead of just 3 screenfuls (6 nodes on my screen) and updating them dynamically when scrolling isn't what I would call 'performant', but needless waste of resources.

Btw: when clicking any 'task' to get to see the details, I see a repeating pattern of almost vertical stripes in some colors. I guess that's not what it should look like.

Re: Emerging Rust GUI libraries in a WASM world

#90

Post by [deleted] »

josephg wrote: post #22
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…

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…

[deleted]
Post reply on HN