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

141–150 of 272 posts

Re: Emerging Rust GUI libraries in a WASM world

#141

Post by josephg »

galangalalgol wrote: post #99
Kiro wrote: post #93

Earlier quoted context omitted.

Are you being sarcastic?

I certainly was extremely impressed the first time I saw it. Other than the font book I haven't found anything there that is slow. What makes you think the op might have been sarcastic? Egui was in a thread yesterday and it seems like canvas rendering is a dividing issue between people who value portability and performance most vs people who value consistency of ergonomics and style/look most.

Its certainly controversial. Using canvas based rendering like this is essentially reverse-electron.

Electron builds native software by embedding a web browser and using the browser's layout engine and DOM. Canvas based rendering like this is the inverse. Here the application discards the browser's layout engine and DOM, and instead embeds its own layout engine. - Despite the browser being right there and available.

Hilariously, in a demo like this there's 3 layers of UI controls nested inside each other. First, there's the OS's native UI toolkit. Then there's the browser. The browser discards most of those UI elements, and reimplements its own controls. And then Egui discards all of that and embeds its own, third layout engine all written in wasm. No inertial scrolling. No web inspector. No native controls (especially a problem on iOS or android). No CSS - so I hope Egui's layout engine supports the layout you're after.

Downside: Its a 5mb wasm bundle. But on the plus side, 5mb is positively tiny compared to shipping electron!

Re: Emerging Rust GUI libraries in a WASM world

#142

Post by josephg »

dragonelite wrote: post #132
crispinb wrote: post #46

Earlier quoted context omitted.

Slower - not really now Rust client web frameworks have improved. Don't have refs handy, but Leptos, Dioxus etc are on a par with Solid. Larger bundle sizes - yes that's still true. And not all GUIs are web GUIs, so WASM isn't the whole story.

Yeah played with some Leptos wasm and i believe something simple like their book tutorial was like 335kb or so. Not that shocking and for me personally totally acceptable. I do wish browsers would ship with their std lib for wasm. So wasm is can become more competitive on bundle sizes with Javascript which has its std lib shipped with browsers.

Yeah also note that 335kb of wasm isn't as bad as 335kb of javascript.

Its true that large javascript bundles are bad because big files take longer to download. But the arguably larger problem is that parsing javascript is really slow. This isn't as big an issue with wasm - the browser can parse wasm many times faster than it parses javascript. If I recall correctly, wasm parsing speed is about on par with the speed of parsing pngs.

So having 335kb of wasm is similar to having a 335kb image on your landing page. Its not ideal, but its not a showstopper.

Re: Emerging Rust GUI libraries in a WASM world

#143

Post by 7znwjshsus »

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

I love how simple your cargo toml is. A big turnoff of leptos for me was the incredibly messy cargo toml of the examples. I could barely touch it without bricking the project.

Re: Emerging Rust GUI libraries in a WASM world

#144

Post by virtualritz »

TobyTheDog123 wrote: post #17

This may not be the message of the article but as a side-rant: I really don't understand the use-case for a Rust-based GUI. Rust's syntax, manual memory management, and compile times makes it seem like it's really not meant for this kind of workload, but instead for things like compilers, embedded systems, that kind of thing. I understand that not every UI needs to be a cross-platform blah blah blah written in TypeJa…

> Rust's syntax, manual memory management, and compile times makes it seem like it's really not meant for this kind of workload, but instead for things like compilers, embedded systems, that kind of thing.

What about a vector or image editor, a 3D DCC etc?

These are prime example for desktop apps where existing solutions are 100% written in C++.

That's stuff where Rust would be a better alternative if you started work on an app like this today.

In VFX there is a whole initiative by the ASWF to wrap the stack in Rust for starters and possibly have new additions written in that language instead of C++ in the future.

And compiling to WASM and being able to run in a browser (even if only as a single canvas element with all applying limitations) is a great plus.

Re: Emerging Rust GUI libraries in a WASM world

#145

Post by josephg »

brabel wrote: post #63
SnowProblem wrote: post #55

Earlier quoted context omitted.

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

Rust doesn't have to output more code than a C compiler. But it tends to because most rust programs are stuffed full of bounds checks. And bounds checks aren't small. As well as the conditional itself, every bounds check also includes:

- A custom panic message (so you know which line of code crashed)

- Some monomorphized formatting code to output that message

- The infrastructure to generate a stack trace after a panic

- Logic to free all the allocated objects all the way up the stack

If you compile this 1 line function:

    pub fn read_arr(arr: &[usize], i: usize) -> usize {
        arr[i] // (equivalent to 'return arr[i];')
    }
... You produce 20 hairy lines of assembler: https://rust.godbolt.org/z/dhz34KEvj

In contrast, the equivalent C function is this rust code:

    pub fn read_arr_unchecked(arr: &[usize], i: usize) -> usize {
        unsafe { *arr.get_unchecked(i) }
    }
And predictably, the result is this gem - identical to what the C compiler outputs:

    example::read_arr_unchecked:
        mov     rax, qword ptr [rdi + 8*rdx]
        ret
But nobody writes rust code like that (for good reason). You can get a lot of the way there by leaning heavily using rust's iterator types and such. But its really difficult to learn what patterns will make the rust compiler lose its mind. There's no feedback on this at compile time, at all.

Re: Emerging Rust GUI libraries in a WASM world

#146

Post by calvinmorrison »

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…

That's a great point. If you've had the pleasure of writing anything in GTK/Glib with C, you quickly realize it ain't your mothers C. But like C with a bunch of object oriented casting on top of it .

Re: Emerging Rust GUI libraries in a WASM world

#147

Post by jenadine »

josephg wrote: post #141
galangalalgol wrote: post #99

Earlier quoted context omitted.

I certainly was extremely impressed the first time I saw it. Other than the font book I haven't found anything there that is slow. What makes you think the op might have been sarcastic? Egui was in a thread yesterday and it seems like canvas rendering is a dividing issue between people who value portability and performance most vs people who value consistency of ergonomics and style/look most.

Its certainly controversial. Using canvas based rendering like this is essentially reverse-electron. Electron builds native software by embedding a web browser and using the browser's layout engine and DOM. Canvas based rendering like this is the inverse. Here the application discards the browser's layout engine and DOM, and instead embeds its own layout engine. - Despite the browser being right there and available.…

The idea is that instead of shipping electron, you ship a native binary that use egui without using wasm or the canvas.

Egui only use wasm in situations where you must use the user browser because you have no choice. Eg: showing a demo of the app on the web without having to install anything.

> Its a 5mb wasm bundle. But on the plus side, 5mb is positively tiny compared to shipping electron

This comparison makes no sense. Situation where electron could be used are exactly the kind of situations where a wasm bundle would not be shipped (a native binary would be shipped instead)

Re: Emerging Rust GUI libraries in a WASM world

#148

Post by alpaca128 »

crispinb wrote: post #124
zkldi wrote: post #117

Earlier quoted context omitted.

can i ask what kind of things you specifically found confusing about the syntax?

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're not even going to measure a difference.

> Even command line parsing is made to be a vastly complex endeavour.

Yes, I even wrote a library for that once but then realized it only complicates everything and adds limitations. Nowadays I just do that by hand. For one it's guaranteed to be shorter than any parsing library, but also it's a good opportunity to think about what kind of arguments I need and in which form. And copy-pasting the parser from the previous project and adapting it is quick & easy.

Re: Emerging Rust GUI libraries in a WASM world

#149

Post by mwcampbell »

josephg wrote: post #145
brabel wrote: post #63

Earlier quoted context omitted.

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

Rust doesn't have to output more code than a C compiler. But it tends to because most rust programs are stuffed full of bounds checks. And bounds checks aren't small. As well as the conditional itself, every bounds check also includes: - A custom panic message (so you know which line of code crashed) - Some monomorphized formatting code to output that message - The infrastructure to generate a stack trace after a pan…

I'd appreciate any more tips or resources you might have about reducing Rust code bloat. I want my library [1] to be acceptable to the most strident anti-bloat curmudgeons, so they'll make their UIs accessible.

[1]: https://github.com/AccessKit/accesskit

Re: Emerging Rust GUI libraries in a WASM world

#150

Post by revelio »

horsawlarway wrote: post #122
rkagerer wrote: post #76

Earlier quoted context omitted.

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

> 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. --- I disagr…

Most web apps don't use human readable text. It's all heavily minified and the textual nature is just pure downside: slower and harder to parse than binary, more bloated, harder to implement.
Post reply on HN