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

121–130 of 272 posts

Re: Emerging Rust GUI libraries in a WASM world

#121

Post by cyber_kinetist »

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…

Things are a bit different in certain graphics app domains, where you need to create complex tools for professionals (think of image editing, 3D modeling, video processing, CAD, game engines, etc.) The users demand all kinds of functionality that requires squeezing the CPU and GPU to the fullest extent. And you have to do this while designing a complex UI with numerous complex controls, and it also needs to be butter-smooth. (Also note that the majority of the low-level APIs/drivers you need to use are in C/C++!) In that case, using languages like Go/Java/Javascript creates more problems than it solves (even if you only write the core in C++/Rust and use bindings.)

Re: Emerging Rust GUI libraries in a WASM world

#122

Post by horsawlarway »

rkagerer wrote: post #76
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…

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 disagree pretty hard with this sentiment. Yes, it's harder to programmatically interact with some of the browser features from outside of the browser. Programmatic interaction with basically any application that isn't yours is getting harder across every operating system as security becomes more important.

That doesn't really change that introspection of the source that makes up a displayed site was easy and approachable. I can look at the css/html/js. Further, all of those resources are contained in files intended to be opened and looked at by humans (they're human readable text).

This is my biggest issue with WASM. You're literally back at reading assembly again. And while that's possible, and there is tooling that can help - it's just not the same as being able to right-click on something, alter a couple of attributes in human readable words, hit enter and see that change.

Re: Emerging Rust GUI libraries in a WASM world

#123

Post by berkes »

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…

> Almost everything else is secondary.

For any app more complex than a demo "todolist", handling "business logic" is - by far - the most important. Hundreds of widgets that don't do anything, or do it wrong and buggy, are worthless.

"handling business logic" is difficult and, ironically, perpendicular to many frameworks (as in: frameworks make dev/testing/evolving/refactoring of business-logic harder, not easier). A perfect example was (is? IDK) Visual Basic: tons of widgets, a neat builder, but terrible in managing even simple state and handling business-logic. Or React, which is a perfect framework (and paradigm/architecture) for small, or flat apps, but terrible for complex or convoluted apps.

What I see in Rust, is a focus on the stuff beyond mere "providing lots of stuff that can be drawn to screen": how to manage state, react to changes, manage events etc. Which is, the way I see it, why there also are so many frameworks emerging: what architecture and paradigms work best, very much depends on your use-case.

Re: Emerging Rust GUI libraries in a WASM world

#124

Post by crispinb »

zkldi wrote: post #117
crispinb wrote: post #83

Earlier quoted context omitted.

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

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 numbers of stdlib utility traits whose idiomatic use you have to remember to read almost any real world code. There's hardly a Rust library in common use that isn't a huge sprawling mass of over abstracted generics and macros. Even command line parsing is made to be a vastly complex endeavour. There are admittedly sugary niceties (eg derive attributes) that can make use of many of these libraries tractable for easy cases. But overall any substantial Rust program makes cognitive and memory demands on the programmer far in excess of what most languages require for the equivalent in my experience.

Re: Emerging Rust GUI libraries in a WASM world

#125

Post by amelius »

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…

We could build a "DOM" inspector that runs inside the canvas too ;)

Re: Emerging Rust GUI libraries in a WASM world

#126

Post by alkonaut »

mcluck wrote: post #105
alkonaut wrote: post #81

Earlier quoted context omitted.

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…

Of course you'll always have different ways of building UIs depending on circumstances but eventually some consensus will be reached for a default approach. WinForms used to be the default for Windows, Tk was the default for Linux (or at least that was my impression, I was all in on Windows back then), etc. For many people, using web tech has become the default if you want to build cross platform UIs. You have the op…

OSes that come with a native UI obviously have that as the default. But there will never be a default across OSes I think. Web UIs might be that, but I sure won't want to use html or js anywhere in my UI's if I can help it, even if cross platform.

Java might perhaps be the best example of trying to make a default-for-a-language cross platform UI (Swing and whatever it was called that came before it). But I think it's also an example of why it might not be a great idea to even try.

I think a key realization is that an app like Blender or AutoCad need a different UI paradigm than Spotify or a game overlay does, even on the same platform there are differences there. Apps that can use web based UIs tend to be more like Spotify than Blender...

Re: Emerging Rust GUI libraries in a WASM world

#127

Post by quickthrower2 »

KRAKRISMOTT wrote: post #12
vbezhenar wrote: post #9

Earlier quoted context omitted.

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…

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 remember the buggy adobe svg plugin c.2000! That is an extension you had to install as an .exe to view some subset of svg!

Re: Emerging Rust GUI libraries in a WASM world

#128

Post by [deleted] »

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.

[deleted]

Re: Emerging Rust GUI libraries in a WASM world

#129

Post by tluyben2 »

brabel wrote: post #62
TobyTheDog123 wrote: post #45

Earlier quoted context omitted.

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.

The problem is that although the creator is gifted, he seems to not have much theoretical PL design knowledge. That is an issue for something as complex as this; this automatic memory management without a GC is cutting edge research and we don't know if we can make it work without making sacrifices like Rust did. You have to sacrifice something and that means while you won't have to worry about memory management, the work for the programmer becomes harder. Or just use a GC.

Re: Emerging Rust GUI libraries in a WASM world

#130

Post by CuriouslyC »

coderedart wrote: post #112
moonchrome wrote: post #84

Earlier quoted context omitted.

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

Is a date range picker that hard to implement?

You wouldn't think so, but I've seen a lot of bad ones.
Post reply on HN