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

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.

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)

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)

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

So, is there anything native between Qt and GPUI?

Having a middle ground, in between?

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

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?

Is diffing really that expensive even in complex applications?

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.