To which my reply is: "Who cares, the vast majority of apps do not have complex UIs".
And if they do you can come up with a workaround like e.g. rerun did for egui (outlined in the article).
Case in point: my biggest spare time "prompted" project is a now 500k LOC hybrid 3D modeling app. It uses egui.
I'd say modeling functionality-wise it's somewhere between Grasshopper/Houdini, close to 200 nodes out of the box + any number of custom ones
That gives you an idea about UI: node graph, parameter editing, widget overlays, gizmos. A lot of nodes have custom widgets, ramp or curve editors etc.
It's not a simple UI at all.
But I didn't spent a second on worrying about the performance of egui's approach. And while UI shows up on my per-frame statistics it's negligible.
From the article itself:
> Disclosure: I ported GPUI’s current Linux renderer to wgpu2, I built the benchmark harness used below, and I work on zgui, a signal-based Rust framework that appears in the charts.
https://github.com/zortax/zgui
zgui just released version 0.1.0 last month, with a 3 month dev history. And it's their only version.
https://github.com/zed-industries/zed/tree/main/crates/gpui
https://crates.io/crates/gpui/versions
GPUI's last release was 0.2.2, 1 year ago.
Framework maturity is an unavoidable contributing factor when choosing where to port over your application.
Should that mean that they can only choose 10-year-old frameworks? No, but also they shouldn't be chasing 1-month-old projects.
There are minimums & maximums, and the minimum sits at "definitely not 1 month old projects with only 1 public release".
If you thought about this, write it yourself.
You know, he's done a pretty good job of editing/prompting. It's far less "Claude voice" than other AI-written articles that keep getting posted here
I should have realized sooner though, because I had no idea what that table was trying to say, and that should have been a signal already.
> What a write runs | Who finds the change
Good lord. If you are writing a thoughtful critique of something.. actually write it.
Which company in the past needed a GUI more than Microsoft? Maybe they have the answer? Or Apple?
I don't think social media apps are GUI heavy enough to have developed something advanced in this field.
GUI complexity and application complexity are two different things
arguments in the post sound reasonable but conclusion is off.
but i can make strong claims about the benefits of not needing to duplicate your state inside of your ui framework. that alone removes an entire category of work, and i would argue scales better from a conceptual/dev standpoint.
There's all sorts of caching you can do with immediate mode; like you said, caching the layout in a large list. The end result is the same as retained mode, with all the same complexities. Might as well skip reinventing the thing.
> try updating the entire list...
If you're comparing like-for-like, whether you're doing layout for the entire UI in immediate mode or retained mode shouldn't make a big difference. You're doing the same calculations after all.
> but i can make strong claims about the benefits of not needing to duplicate your state inside of your ui framework
I've found it's often not necessary to duplicate state in the UI framework; you can frequently make UI controls the owner of the state.
i think a glaring red flag with retained mode ui's is how slow they are. there is a reason they put so much effort into granular reactive updates - they're just way too slow otherwise. resize retained mode ui windows and the fps drops to like 2. meanwhile in an imgui, it doesn't matter if you're rendering 1000 buttons and then need to render 1000 dropdowns, the work is roughly identical. this means big problems for a retained mode system. this seems like a massive issue to me - the system is so slow, it's only considered "faster" than imgui (debatable) when it doesn't actually do much. but we want ui's to scale with interactions, not depend on minimal changes in order to recover acceptable performance.
in practice rendering a frame of imgui or whatever is so fast and efficient that it's not an issue. we're talking a few thousand triangles and typically a small handful of shaders & draw calls.
It does not leverage of Rusts advantages very well at all, and so the extra overhead is hard to justify.
I think there are definitely some key libs that would work well with rust (wgpu is nice!), but the the core language itself would ideally not be Rust.
Obviously - it can be done - and I'm sure it's a lot of fun for some devs - but I think this is fitting the circle into the square hole. (Edit - it's funny saying that because 'fitting the circle into the square hole' is literally like saying 'walkies?' or to a dog, aka 'arise - a problem to be solved!' but I think that is what I'm getting at, like what wags the tail isn't necessarily the best option)
Can you elaborate? I don't see anything there that is hard for Rust per se:
- Tree-based data structures are just the bread and butter of Rust as long as they are not cyclic, but arguably you shouldn't be declaring your UI with cycles at all.
- Ugly state is exactly what Rust was made for. It forces you to tame the ugly state instead of hacking at it and hoping it works.
- Event driven and heavily async are neither a Rust strength nor a weakness (some would say it's actually a strength but IMO there are tradeoffs). Actors and message passing are one of the many patterns that Rust is fantastic at.
- And I don't see how JSON is relevant to UI, but JSON is not only "solved" in Rust but the best ser/de libraries I've ever used are in Rust.
Rust gets cumbersome with hyper-connected or hyper-shared ownership (think e.g. inodes in a filesystem) where you have to sidestep the borrow checker... but UIs are inherently hierarchical.
Yes, Rust doesn't fit the traditional OOP cycle-connected "widget" model where a textbox "knows" about its sibling button, and the button "knows" about its sibling textbox. Turns out that that model sucks, and that's why everyone fled to React and other saner models even without Rust's constraints.
Maybe I'm just biased by the React mindset (unidirectional data flow), but I've never been happy with any other UI paradigm so I consider that an advantage.
I'm not an expert on GUIs, but my understanding of them is that the ugly state is sort of inherent to GUI applications and you can't tame it. Ie, everything interconnects with everything else and there's not much you can do about that. This sort of inherently pushes you to a big runtime that manages a lot of stuff for you, which is in line with GUIs being rather expensive generally (ultimately you have to render everything to the screen).
In other words: the patterns I use outside of Rust are also Rust's happy paths (on paper, maybe I'm just missing something?)
(For clarity: I'm talking of userland here. I assume that's what OP meant by "UX" -- I agree with your "big runtime" point, but that's why my RAM is filled by Electron apps.)
- "shouldn't be declaring your UI with cycles at all." - they are inherently cyclical. Parent/child and handler/emitter relations are very common. You can work around it, but unnaturally.
"Ugly state is exactly what Rust was made for. " - No. Rust forces you into constraints, which have certain paramters.
--> this is the biggest conceit of Rust - that somehow, the 'borrow checker is correct'. It is not. It is a constraint. Having to meet that constraint is in some cases beneficial, but it's mostly just limiting.
The limitation of that constraint and implications is so strong, that it keeps Rust from being mainstream.
- "Event driven and heavily async are neither a Rust strength nor a weakness"
Async in Rust is objectively hard, it's another dimensional of complexity that does not have the same impact in other languages. Asyc does create issues everywhere but not as much as in Rust. Again, another big layer of trickery for not advantage.
- " but JSON is not only "solved" in Rust but the best ser/de libraries I've ever used are in Rust." - then maybe you have never programmed in any other language?
Because the 'best' language for JSON is obviously Javascript/Typescript - and it suites most OO languages extremely well.
The question underlying all of these statements, is why anyone would ever choose Rust in the first place?
Rust brings much greater complexity for no advantage in most cases.
By any objective measure, Rust is just a 'bad choice' for all but a narrow set of things.
I think you have to add both 'developer interest', 'integration with specific libraries' and maybe 'other strategic considerations' in order for Rust to be a rational choice in a lot of cases.
I think this is where we disagree.
If your UI data flow is not unidirectional, that's a problem you brought yourself into, Rust or not.
For reference: I don't do my UIs in Rust, but the language is not the reason why, and I still use unidirectional data flow even on GC'd languages.
> Because the 'best' language for JSON is obviously Javascript/Typescript
As a TypeScript fan (it's my main language)... ser/de sucks in TS and IO boundaries are most of my pain points with it. My top 2 things that I miss from Rust are: (1) serde/rkyv (2) affine types. Zod has been great but it's still miles behind a proper ser/de library.
And yet I still can't see how JSON is relevant for UIs.
Why do those complex Adobe clones work so well then?
Slow, laggy UI is a common source of complaint on the issues.
Examples:
https://github.com/storytold/cadcraft/issues/752
https://github.com/storytold/cadcraft/issues/874
https://github.com/storytold/vectorcraft/issues/2292
They seem to be edge cases of building extremely complicated renderers (that handle varied user files/scenes) in a very short time. The projects are weeks old. The original app's renderers were built and optimised over decades against user files. I would also assume the central renderer is a 3d surface, not egui.
Generally to the contrary, I was surprised how snappy their UIs feel in normal usage compared to the apps they're replacing.
egui was a great choice given the results; also egui's wasm support is very good, which means artcraft supports wasm; i.e. they can run on a browser.
You can use the UI to figure out your ideal design process manually and then hand it off to a gent next time. The cool thing about those apps is that everything in the UI works headless as well.
(That said, on the scale of blame for it being bad, I would say the GUI framework accounts for 0% of that and the programming methodology accounts for 100% of that)
It's ~100MiB each, installs in seconds; I can point my agent at the github repo and it will be able to run it and control the apps; e.g. look at how excel spreadsheets actually render and adjust the layout.
I'm not a power user, but for my particular use cases artcraft apps are better than the original counterparts (install-size + agent control).
Something about every complex GUI being a spreadsheet-style calculation.
Most of these GUI software are vibe coded so state management essentially becomes somebody else's blackbox problem.
That said, I indeed am not fond of GPUI and egui, but for different reasons.
In GPUI having to manually mark the state as changed is IMO a footgun and any decent UI framework should not require something like that.
In egui I found the "immediate mutation" pattern (e.g. the classic `if button.pressed() { mutate }`) to produce glitches in the UI, because it will cause half the UI to draw the old state and half the new state. You almost always want to anticipate interactions, or to delay mutations. But performance is not a problem IMO unless you're writing a complex vector graphics viewport (in which case retained UI won't help you either)
I'm glad we're all finally coming round to this view. I've bene repeatedly annoyed at folks treating really basic UIs as evidence that their pet UI framework is suitable for complex UIs...
And that's why React exists.
Personally I think most of the abstractions we’ve tried around GUIs don’t work, and old school frameworks like AppKit are better. They just need some DX love since programming has evolved so much.
Say what you will about "plain" COM models they don't cause a bunch of random memory allocations when you drag-n-drop an element in a list down two spots
but i'm not going to spend time critiquing an ai-generated slop article. if anyone has specific questions about what is wrong feel free to ask me. i want to ideally spend my time interacting with humans
1. The benchmarks aren't always going to be fair - e.g., in this article they talk about rendering 3,000 rows, but that's an unrealistic benchmark (you'd want to use list virtualization in any framework at that point) that is obviously more favorable to some frameworks over others.
2. Most frameworks are fast enough for most tasks. The performance of a framework is rarely the main issue, but benchmark scores are quantitative and sound objective, so people cling to it.