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

61–70 of 272 posts

Re: Emerging Rust GUI libraries in a WASM world

#61

Post by wiz21c »

klodolph wrote: post #23
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 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…

Funny you mention R. I started a several months work on data analysis/science/you-name-it in python (a good language) and slowly, without noticing it, I migrated all my stuff to R (made by Satan). And exactly for the reason you give: R gets the sh*t done faster (in terms of time spent writing code) than Python... (and you can consider I am a lisper (worse: a schemer)/rust-er at heart !!!)

Re: Emerging Rust GUI libraries in a WASM world

#62

Post by brabel »

TobyTheDog123 wrote: post #45
Liberonostrud wrote: post #40

I am betting on Vlang instead. Rust is too complicated for an average person - like me. It's basically the Haskell of system programming. V is basically Go made right.

I remember looking into V last year, it seems most of the discussion surrounding it was that it was vaporware. Is that not the case? It certainly looks nice, but is it ready for use?

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.

Re: Emerging Rust GUI libraries in a WASM world

#63

Post by brabel »

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.

Exactly, WASM was designed to be very very lightweight... you can put a lot of logic into a very small amount of WASM, but you need a good compiler to do that, or write WASM by hand to really feel the benefit. If you just compile Go to WASM, with its GC, runtime and stdlib included in the binary, yeah it's going to be pretty heavy... Rust doesn't have a runtime but as you said, for some reason, produces relatively large binaries (not the case only in WASM by the way). Probably, the best ways to create small WASM binaries is to compile from C or from a WASM-native language like AssemblySCript (https://www.assemblyscript.org).

Re: Emerging Rust GUI libraries in a WASM world

#64

Post by baq »

setr wrote: post #18
KRAKRISMOTT wrote: post #12

Earlier quoted context omitted.

The browser is successful not because it has a solid foundation but because a ridiculous amount of engineering effort has been put into it. Most of the "beautiful foundation" you see are all post 2012. You young'uns don't remember the days before HTML5 and CSS3. Before npm and PWAs and the "cloud native" nonsense. Adobe Flash anyone? Silverlight? Before WebAssembly/WebGL/WebGPU unity (yes that game engine) even requi…

I can’t figure out if you are for post-2012 web tech or against it

The answer is clearly ‘Yes’.

The problem is we’re in 2011 again, except chrome is the new flash and safari is the ie6.

Re: Emerging Rust GUI libraries in a WASM world

#66

Post by wiz21c »

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 are domains where "end users care about data mutational elegance" because, you know what, they care about reliability in a very strong way (not like: hey the web site is down, let's call the devs; more like: there was a bug, let's call the morgue).

Just to say.

But I agree with you: if your work balance is more oriented towards productivity then rust will not help much. For example, I design lots of stuff in python/jupyter/ecosystem first and then port that to rust for the speed and correctness.

Re: Emerging Rust GUI libraries in a WASM world

#68

Post by mtsr »

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…

Mixed UIs could probably work well here. Using a canvas and specific gpu rendering just for the part requiring high throughput makes sense.

Re: Emerging Rust GUI libraries in a WASM world

#69

Post by baq »

8note wrote: post #32
winstonewert wrote: post #26

Earlier quoted context omitted.

From a Rustacean's perspective: Golang is a no go because it lacks enum types, sensible error handling, generics (I think it has some version of this now), non-nullable types, or macros. Once you've gotten used to using these kinds of features in Rust, it is really annoying to go back and work in a language that lacks them. Basically, golang takes such an opposite design approach to Rust, that if you like Rust you'll…

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.

Re: Emerging Rust GUI libraries in a WASM world

#70

Post by bschwindHN »

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.

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 could be easier than

    if ui.button("Say hello").clicked() {
        println!("Hello!");
    ]
?

But it's quite a pain to style if you're particular about typography and pixel-perfect layouts. Between styling an egui app and styling something with CSS (or some flexbox/grid system), I'll take CSS every time.

Still looking forward to how Xilem turns out, and what people build on top of that.

Post reply on HN