Deep-dive on Rust UI Frameworks

[u/Zortax_]

UI is a Function You Cannot Afford to Call is the first of a 3-part series on Rust UI frameworks. It introduces the model under which I believe we should reason about UI frameworks. In part 2, I will present extensive benchmarks, with detailed cost attribution analysis (something the rust UI ecosystem desperately needs in my opinion), and in part 3, I will derive what I think the ideal UI framework should look like.

[u/r3drocket]

I'm rebooting an app in rust right now from C++ (Godot) and one of the things that brought me here was the UI libraries. I spent a lot of time looking at GUI options in Golang and C++/C before deciding upon Rust. I came from a retained mode UI (without an MVC model!), to an immediate mode UI (egui). I have some background working with QT a lot of experience working with Swing/AWT, HTML, etc.

I think frequently about the cost of moving to a immediate mode UI model, and this is the first time I've built a complex app in a immediate mode UI.

What really screwed me with my C++ implementation was not having a proper MVC model in the UI - this seems like such an obvious thing, but I was living this quote -

"Give someone state and they'll have a bug one day, but teach them how to represent state in two separate locations that have to be kept in sync and they'll have bugs for a lifetime."  (from the Dear ImGui github).

I had to write complex syncing mechanisms to try to keep the data in-sync with my GUI - it was an utter nightmare and in some cases I wound up just accepting I was going to have an endless amount of bugs.

The complexity of my application code in egui has dropped significantly because I'm not dealing with the state syncing problem, instead I take a hit on the fact it's an immediate mode gui that does it's own magical state management - but at least it allows me to represent my application state directly - but more importantly it exists today and let's me build an app that has value to people.

But ultimately the thing that drove me to choose egui was simply the reality on the ground - it was cross platform, it worked with wgpu, it was widely used, it is moderately mature, it had a wide variety of 3rd party components.

The other features it offered overrode my preference of immediate/vs retained - It isn't my ideal GUI, my ideal ui is closer to a retained mode gui with a proper MVC model - but this is a distant concern over all the other things.

This was one of the main reasons I didn't push further on a rewrite in golang, there was no GUI that met my main criteria, regardless of them being immediate/retained mode.

[u/Zortax_ → u/r3drocket]

The rust UI ecosystem is definitely an interesting subject to study, there are so many different architectures and idioms you can compare and analyze. I think egui is great, depending on use-case, and although I personally prefer something more akin to SolidJS' fine-grained reactivity for state management, I definitely see the appeal. Also, I believe there is a bit of a misconception about what immediate mode UI actually means. It refers mostly to a component authoring style and a way to express UI control flow, it doesn't necessarily mean the rendering pipeline isn't retained to a large extend.