A Critique of GPUI
blog.zortax.de
blog.zortax.de
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".
Wait, why is this a problem now? Launching a competing product by making a case for it is fine.
It only matters if the argument is a bad one.
If the title were written in a way to say that their library is built for complex UI interfaces and here's how it compares to gpui then it would be a different story.
What I'm saying is: "Hey, this is shilling for <other thing>!" is not a problem and I find it strange to call that out. "This isn't actually a big deal, don't fall for it" is of course perfectly fine to point out.
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.
When you pick a UI framework you know how your app looks and what 'complexity' means for your UI. And you make an informed choice of which framework you choose based on that.
Or one would hope you do. As that's part of the job of being a software engineer.
If you give that decision to your clanker and it chooses egui a for spreadsheet app: that's still on you. At least for now.
But it's not on egui, either way.
Experience shows that choices made in the beginning of a project are very often reconsidered later when requirements change. In those cases it is nice if you choose for the worst possible outcome, so in this case you choose for a high performance GUI framework which can scale.
Obviously, today you can just write "please rewrite this badly scaling app with that scaling GUI framework" but I think that's outside the scope of the discussion.
The fact that you can just prompt a UI kit swap should be at the core of the discussion then; wouldn't you concur?
If you thought about this, write it yourself.
> What a write runs | Who finds the change
Good lord. If you are writing a thoughtful critique of something.. actually write it.
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.
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 ported GPUI to C++ and I wrote file manager in it.
It's as complex a desktop app as you can get: docking system, tabs, lists, trees, dialogs.
I don't know what the author alludes to as an app that would be too complex for GPUI.
I also know win32 programming and QT and GPUI is more capable and faster than either. I mean win32 is a tragedy but QT is decades of work and doesn't offer anything that GPUI lacks.
Like I said: bull. You can write any desktop app you can imagine in GPUI.
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.
For another example: Adwaita's boxed lists [2] are pretty complex. Blender generally uses a simple label followed by some kind of button, in comparison Adwaita has a wrapping box, separator, special handling for first/last items, subtitles, animated expansion, and a ton of customizability.
I'm not saying these are good examples of UI, but they are surely _more complex_ than Blender. Blender has more menus and controls compared to a normal Material/Adwaita UI for sure, but they are pretty much the same, so it has quantity but not complexity from my point of view.
[1]: https://m2.material.io/components/cards#anatomy
[2]: https://gnome.pages.gitlab.gnome.org/libadwaita/doc/1.4/boxed-lists.htmlA desktop UI for agents to replace Claude/Codex. The UI clones vscode and, if anyone still used them, I might have ported VSCode to GPUI
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.
- "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.
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.)
Obviously you can do this differently, but it makes everything less ergonomic for the programmer.
Why do those complex Adobe clones work so well then?
Most of these GUI software are vibe coded so state management essentially becomes somebody else's blackbox problem.
Something about every complex GUI being a spreadsheet-style calculation.
Just visualizing the application I work on 150 seems like it would be a bit high.
It’s an immensely complicated application but most of the screen is the viewport. You have to start pushing things into palettes / menus / modals just to keep real estate open to actually look at the model!
I can get to hundreds of elements, but not to thousands.
Some more complex web UIs can get to that level of complexity.
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.
Nothing that can't be fixed w/o changing a line of code in egui.
UI needs its own thread, operations in the backend need to be interruptable by the user, yadayadayada.
Try rerun.io or drop me a PM and I send you a link where you can d/l an alpha of my 3D modeling app mentioned in my comment above. 100% egui. Zero lag.
(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).
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)
Having a middle ground, in between?
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.
So you end up with a desktop reserving 20% of your VRAM, if you play a game, devs optimize for 8gb budget for entry level, but in reality most people only have 6.4gb available
The ramifications of people moving away from SW rendered UI toolkits to electron to GPU based UIs is sad to witness, it's getting worse and worse and worse, not to mention how smartphone UX have polluted the desktop industry..
On a desktop system, a software renderer makes no material difference in total memory usage, because the contents need to go onto a compositor surface no matter what you do, and that is backed by memory somewhere.
We can debate whether every application needs triple-buffering of the window surface, but that's configurable.
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 them.