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

71–80 of 272 posts

Re: Emerging Rust GUI libraries in a WASM world

#71

Post by jeroenhd »

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.

Rust can be the same size if you put the same code into the binary, sometimes even smaller.

The problem is that it's real easy to just add a bunch of crates to an application, similar to the nodejs/Python approach.

Most people slso don't seem to turn off many parts of the standard library they don't, even for platforms like WASM. Maybe it's useful to have a stack unrolling panic handler during debug but in release you can just abort and save up to megabytes of space.

There's also a lot to be gained by tweaking the compiler optimisers. By default the optimizer is multithreaded, which makes compiles quite a lot faster, but reduce that to a single thread and suddenly a lot of optimizations can happen that wouldn't happen by default.

I wouldn't write code like described here in C, but I imagine Go and C# are better choices here. Maybe even that Java library the name of which I can never remember, or that Kotlin project that compiles Kotlin to Javascript with super easy interaction between frontend and backend.

I love Rust but if you're going to pick a systems programming language for your frontend, just make desktop supplications. Web is a nice fallback but if it's your primary target, there are so many better options out there.

Re: Emerging Rust GUI libraries in a WASM world

#72

Post by jeroenhd »

baq wrote: post #69
8note wrote: post #32

Earlier quoted context omitted.

If you're going to use electron and all the bad that comes with it, why not just use typescript though?

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.

Re: Emerging Rust GUI libraries in a WASM world

#73

Post by rkagerer »

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…

Thanks!

I don't like how those textboxes get bigger when you click into them.

Re: Emerging Rust GUI libraries in a WASM world

#74

Post by osener »

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.

Re: Emerging Rust GUI libraries in a WASM world

#75

Post by iudqnolq »

Klonoar wrote: post #11
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…

>That's because Rust GUI people are like Lispers and functional programmers — too obsessed with doing things correctly "from first principles" and "purity". That's... entirely wrong and not necessary to paint swathes of developers like. Rust has numerous solutions for native GUIs. People ship apps with those stacks. Rust also has things like Tauri for when you don't want to deal with differences across platforms. Jus…

Can you give an example of a real, shipped app where the majority of the GUI is written in Rust?

I'm excluding games because they tend to have trivial GUIs. I'm excluding tauri because the majority of the GUI code in a tauri app isn't Rust.

This is a serious question. I'd love be shown I'm missing something. I read this article hoping to find out that a serious rust GUI library was ready for real use and was quite disappointed.

Re: Emerging Rust GUI libraries in a WASM world

#76

Post by rkagerer »

chrismorgan wrote: post #24
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…

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…

Well, in fairness web-based applications (including Electron ones running locally) break most of the inspectability benefits that came before, at least on the Windows platform.

eg. I used to be able to programmatically grab hWnd's (like Spy++ does), and manipulate the forms of an app. Apps used to show up as one (or two) simple processes with rich instrumentation metrics in tools like Resource Monitor.

Chrome abstracted all that away in an effort to 'displace' the OS.

I think canvas-only technologies could eventually do the same (the endless cycle continues) and look forward to some of the benefits (eg. more deterministic and straightforward positioning and layout). But I strongly agree they need to accommodate most of the features you mentioned and until they do it's two steps backward.

Do appreciate your thoughtful comment and the concise summary of some fundamental limitations that are presently hard barriers.

Re: Emerging Rust GUI libraries in a WASM world

#77

Post by echelon »

bschwindHN wrote: post #70
echelon wrote: post #25

Earlier quoted context omitted.

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

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 WASMDOM 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 to consolidate and reach maturity.

It's already possible to build reactive isomorphic apps in Rust.

If you haven't checked out Actix/Axum, it feels a lot like Python/Flask. The ecosystem is coming along quickly.

Re: Emerging Rust GUI libraries in a WASM world

#78

Post by pkolaczk »

alpaca128 wrote: post #56
0000000000100 wrote: post #31

Earlier quoted context omitted.

Yeah it seems to be a pretty niche use case. The learning curve for Rust is simply too high (my GOD the syntax). You can just get much more done, in less time with a web framework. I looked into Rust for writing games (including the UI frameworks), but found that the power it provides isn't really worth all the mental overhead. Most games don't really need that much power, particularly if you are using non-realistic…

> 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 sources more frequently, that would become a second nature and would not slow me down.

Re: Emerging Rust GUI libraries in a WASM world

#79

Post by Ygg2 »

brabel wrote: post #60
chrismorgan wrote: post #20

Earlier quoted context omitted.

It’s not entirely wrong. Rust GUI has been held up by a significant dose of trying to do things properly , since the language definitely pushes you in that direction. It’s taken so long because Rust insists on correctness and on an ownership model that the popular solutions for GUIs simply didn’t fit into, so it’s taken time to come up with things that do work in those constraints.

Why do you guys think it's taking a lot of time because people are "trying to do it properly"?? See the comments about people trying the egui demo... that thing is as easy to crash as any junior dev React application.

By doing it properly chrismorgan means a native Rust solution that works with borrow checker.

Egui is mostly bindings. And those can suffer from impedance mismatch (e.g. using OOP UI in Rust)

Re: Emerging Rust GUI libraries in a WASM world

#80

Post by ogoffart »

iudqnolq wrote: post #75
Klonoar wrote: post #11

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". That's... entirely wrong and not necessary to paint swathes of developers like. Rust has numerous solutions for native GUIs. People ship apps with those stacks. Rust also has things like Tauri for when you don't want to deal with differences across platforms. Jus…

Can you give an example of a real, shipped app where the majority of the GUI is written in Rust? I'm excluding games because they tend to have trivial GUIs. I'm excluding tauri because the majority of the GUI code in a tauri app isn't Rust. This is a serious question. I'd love be shown I'm missing something. I read this article hoping to find out that a serious rust GUI library was ready for real use and was quite di…

The most complex I know about: https://github.com/gyroflow/gyroflow
Post reply on HN