The central argument, reiterated countless times through the post is "It does not scale".

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.

The subject is interesting, but the AI-generated text is very hard to read and makes me question if the author actually thought about the problem at all.

If you thought about this, write it yourself.

This is an advert for zgui, disguised as a critique piece.

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".

So, which are the most advanced GUI frameworks that have ever existed, and why are they superior to GPUI or egui?

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.

Looks fun, but Rust is less well suited to UX than other langauges - tree based data structures, a lot of ugly state, event driven, heavily async, and naturally all of the json and other things that come in at that layer don't have 'very nice' libraries.

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)

Wouldn't multi-shot algebraic effects help? Assuming we write a view as a function, what the author wants is for the lower stack frames to know which parts of the application state upper stack frames have read, so that the lower stack frames can selectively redraw the views returned by the upper stack frames when a small part of the application state changes. languages with multi-shot algebraic effects allow this. I agree with what the author is arguing for, but as I checked zgui, it's a developer experience nightmare due to heavy use of Rust macros. I feel like this should be implemented in another language that's better suited for the task.

The "not good enough for complex apps" is bull.

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.

I observe that over the recent years, the term “native GUI” has changed (lost?) its meaning. As in, “native” currently refers to native code (usually non-web based, Rust, whatever), as opposed to using the platform’s native UI toolkit(s).

And that is somewhat sad IMHO. These apps, whether written in Rust or JS, don’t feel native to the platform at all. And while there are valid use cases for specialized software (Blender, for example), a desktop apps should feel native.

I fully understand the motivation against writing fully native desktop apps, which is the same reason Electron exists—different frameworks, different languages, different HIGs, different tools…

Still, sad

>I believe both GPUI’s and egui’s state models are dead ends for complex desktop applications.

Why do those complex Adobe clones work so well then?

In my opinion this comes down to how much data you have on screen and whether you can efficiently skip off-screen data. If you can do that then it doesn't matter how your framework scales, you will be bound by screen space anyway.

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)

The article's topic was compelling. Some sibling comments made it sound like a conflict of interest, but I honestly don't see any issues with a GUI library developer discussing how their project improves on existing SOTA.

Just please, for the love of all holy, forget code, at least learn that it's anathema to use Claude for writing! You're expressing, supposedly, your own thoughts, so please spare the readers from trying to infer whatever original thought is buried in the sea of Claudish. I don't care if it doesn't sound like an SAT essay, I don't care if your native language is Chinese. I'd rather read your broken English then question if the narrator is even sentient.

My main concern with GPUI is that they don't really care about API compatibility and do breaking change with each releases. So I don't think it is viable for anything complex that need to be maintained on the long term

I love gpui, I used it to build this https://github.com/alshlabs/quill

A 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

I don’t understand this fixation on scalability in response to state changes. UIs have a pretty low ceiling on how many widgets can be in the tree. Doing sophisticated diffing to avoid manual updates on a few dozen UI elements hardly seems like a win. In situations where you have large numbers of UI elements, like table or list views, it’s well known how to display only the rows in view.

The new diffing-based toolkits almost all suck. First-party SwiftUI stuff on my M5 Pro is more janky than anything Apple has released since OS X 10.0 running on underpowered G3s. At least that can be blamed on the transition full screen window compositing and anti-aliasing. SwiftUI doesn’t actually do anything that MacOS hasn’t already been doing for 25 years. And if anything modern SwiftUI apps have less complicated layouts than AppKit apps that worked just fine on a 500 MHz G4.

> but the truth is that Zed is a relatively simple app, UI wise. The app’s chrome contains a few buttons, in a simple layout, a sidebar and a text editor, and the text editor is implemented as a custom element, completely bypassing GPUI’s layout and view semantics. By their own account, a window “has tens of nodes and a few thousand elements”.

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...

AI critiquing AI’s favorite native UI framework, brilliant.

So, is there anything native between Qt and GPUI?

Having a middle ground, in between?

Can't you fix this scaling by chunking the entities? So not making one massive 10,000 thing entity but instead breaking it up into entities that group 500 things?

Good article, I will tell my AI agent to read it and fix my UI framework if there any problems and suggestions that could be used.

Find surprising the author didn't use tauri, but I guess he only compared native frameworks

Is diffing really that expensive even in complex applications?

They are hiding its cost in the GPU, nobody tracks GPU usage including VRAM usage

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..

there is so much wrong in this ai generated article. from very poorly constructed egui benchmarks, treating dom performance as comparable, taking the egui creator's quotes out of context, and more.

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

gpui is pretty shite at energy draw too. bitemyapp’s sidestep is way better.