Yeah, it turns out the popular UI paradigms rely on a lot of mutable state

The most popular language by far used for writing UI is JavaScript, and the go to framework this day (React) doesn't use that though.

From the various experiments that popped up over the years, it's pretty clear that the React way works pretty well for Rust, but it's also too slow to be desirable for Rust (what's the point of using Rust for UI if you're going to have web-like performance).

And then again, making a half decent UI framework is a gigantic task, there's just not a whole lot of languages with a decent UI story at all, no matter what's the paradigm of the programming language. (And if you want a language for cross-platform UI, I'd argue that the only one that ticks the box is JS with React in Electron and React Native, and it's not even truly a single framework).

A UI is by definition a view of some mutable state.

The view part would be fine, the problem is updating the state. In a language which discourages shared mutability, most of the solutions are not terribly ergonomic.

You either end up needing to:

- handle all your state via interior mutability (i.e. Arc<RefCell<_>>)

- use a reducer (i.e. the state blob is immutable during rendering, updates are deferred via events that are delivered between frames)

- or invert the relationship between state and view (i.e. immediate-mode) which comes with it's own implementation challenges (caching immediate mode views is hard)

> - use a reducer (i.e. the state blob is immutable during rendering, updates are deferred via events that are delivered between frames)

This is how I implemented my last Angular project, works fine for non-trivial tasks.

Rust is fine with mutable state, it just strongly encourages that it not be shared. Egui seems fine, we've used it to good effect.