A Proposal for an asynchronous Rust GUI framework

[Animats]

> Here’s one of this year’s dozen new Rust GUIs.

Right. On the game engine side, there's the comment that Rust has 50 game engines and 5 games. A new GUI framework might not be what's needed.

I'd like to see some of the most used ones get finished. I'm waiting for the six-month WGPU overhaul to finish to unblock the Rend3 overhaul so I can use a newer version of egui. Egui botches layout if there's a line wrap in a scrollable window, for example. Basic stuff like that is broken.

[bsder]

> On the game engine side, there's the comment that Rust has 50 game engines and 5 games.

Bingo.

The problem in the Rust ecosystem is that people are writing libraries instead of applications.

This is backwards. Until you have a couple of applications written, you have zero idea what to abstract.

I'll go further. The Rust GUI ecosystem is fundamentally doomed because they are absolutely insisting that any GUI thing must run on desktop, mobile, and web simultaneously. The abstractions required between those domains are fundamentally incompatible.

Desktop apps want "Give me all your cores. Now." Mobile is all about "Please, sir, can I have some battery?" Web is all about "Back in my day all we had was one damn thread so that's all you get and you'll like it."

I would personally cheer if we had one good Rust GUI framework for each of those cases.

[rcme]

I think a bigger issue is that Rust just isn't a good language to write a game engine or a UI in. I wrote a toy game engine in Rust and quickly learned it basically sucks. The entire reason games and UIs exist is to mutate state in weird, complex, and often circular, ways. Rust's borrow checker doesn't lend itself well to this problem.

[tcfhgj]

Perhaps experimentation is a sensible thing in the early days of the Rust ecosystems

[zaphirplane]

My kind of unscientific impression is Java has a lot of libraries with a relatively few applications.

While c# is a lot of applications with few libraries

[yw3410]

I've just wanted right click menus and second screens on Wayland for ages.

My herd of yaks is only getting higher over time...

[wahern]

A classic use case for coroutines is easily turning a push (callback) interface into a pull (return) interface. I'm sure many people have thought of using coroutines to handle GUI events this way. Certainly I have, and have even written some code along these lines in a macOS app primarily written in Lua (Yue as the GUI toolkit, along with my Lua I/O event library, cqueues, which I used to help tie into some event sources for which Yue lacked support; cqueues was designed to integrate with, rather than displace, other event loops).

However, GUI frameworks are a nightmare of criss-crossing events and state, and in practice callbacks are the least of your worries. In other domains callback interfaces often force you to scatter what would otherwise be highly localized logic, but it's the nature of GUI frameworks that your event logic will tend to be short, chunked, and scattered regardless, which is demonstrated by the toy examples. Yes, the async pattern turned event pushes into event pulls syntactically, but that's it--there was no real payoff.

I'm sure somebody will eventually go the distance with this approach. I won't dispute that the exercise would be a fun ride.

[cropcirclbureau]

I'm very interested in seeing if using the commonly implemented forms of compiler support for async programming can also be well used for GUI programming. One wishawa[0] is also perusing this approach in Rust but I first came upon this idea from the crank-js[1] authors. It wasn't clear to me why that one never went anywhere. Was it failure with the approach or was React just a good solution in the space? I can say this though, there's something strikingly elegant about those initial samples of using JavaScript generators for components.

[0]: https://github.com/wishawa/async_ui

[1]: https://github.com/bikeshaving/crank

[yoz]

Thanks for reminding me about Crank; it was The Hot New Thing for about a week when it launched. I’m guessing the project lead just couldn’t convert that initial interest into useful contribution. Glad to see he’s still working on it, though.

[yidadaa]

I suggest all GUI developers to familiarize themselves with the cutting-edge frameworks in the frontend community before proposing a new framework. This way, they can avoid the hassle of "reinventing x".

Regarding this proposal, it wouldn't hurt to take a look at the implementations of `preact signal` and `vue3 ref`

In addition, the overly strict memory management of Rust is a disaster for GUI programming. GUI states are already complex enough, writing GUI in Rust is like adding an enemy called "compiler" to oneself.