This is an advert for zgui, disguised as a critique piece.<p>From the article itself:<p>> 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.<p><a href="https://github.com/zortax/zgui" rel="nofollow">https://github.com/zortax/zgui</a><p>zgui just released version 0.1.0 <i>last month</i>, with a 3 month dev history. And it's their only version.<p><a href="https://github.com/zed-industries/zed/tree/main/crates/gpui" rel="nofollow">https://github.com/zed-industries/zed/tree/main/crates/gpui</a><p><a href="https://crates.io/crates/gpui/versions" rel="nofollow">https://crates.io/crates/gpui/versions</a><p>GPUI's last release was 0.2.2, 1 year ago.<p>Framework maturity is an unavoidable contributing factor when choosing where to port over your application.<p>Should that mean that they can only choose 10-year-old frameworks? No, but also they shouldn't be chasing 1-month-old projects.<p>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.<p>If you thought about this, write it yourself.
> the AI-generated text is very hard to read<p>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 must say, it took me a while to realize it’s AI generated. There were some tics after thousand of words that let me realize.<p>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.
I got as far as the table labeled<p>> What a write runs | Who finds the change<p>Good lord. If you are writing a thoughtful critique of something.. actually write it.
So, which are the most advanced GUI frameworks that have ever existed, and why are they superior to GPUI or egui?<p>Which company in the past needed a GUI more than Microsoft? Maybe they have the answer? Or Apple?<p>I don't think social media apps are GUI heavy enough to have developed something advanced in this field.<p>GUI complexity and application complexity are two different things<p>arguments in the post sound reasonable but conclusion is off.
Blender has seriously complex UI needs.
No idea whether they use a reactive architecture but (claimed) raw performance is impressive.<p><a href="https://github.com/ppmpreetham/BUI" rel="nofollow">https://github.com/ppmpreetham/BUI</a>
all of the alternatives suck. you can complain about egui in particular but immediate-mode libraries have an overwhelming set of advantages and actually scale <i>better</i> with more complex ui.
I work on a GUI toolkit professionally. Immediate-mode libraries are cool, but they absolutely in no way shape or form scale <i>better</i>. Having to evaluate and layout the entire UI for every state change is fundamentally not scalable. Doubly so if you need to do this multiple times to reach a steady-state layout like you do in some cases with egui.
you can cache layouts with immediate mode libraries. in terms of scaling, it really depends - if you have many components updating at once, the benefits of retained mode libraries are diminished if not reversed. when people create demos of 10,000 list elements and updating a single one, it's basically designed as a best case scenario for retained mode. try updating the entire list...<p>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.
They are slow and inefficient especially in a VM where there is no GPU. It doesn't make sense to redraw all screen if only one button has changed.
retained mode frameworks still redraw the whole frame typically, unless they're doing some type of partial rendering - that still has a cost though, and all modern ui frameworks retained or not will suffer without a gpu.<p>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.
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.<p>It does not leverage of Rusts advantages very well at all, and so the extra overhead is hard to justify.<p>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.<p>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.<p>That said, I indeed am not fond of GPUI and egui, but for different reasons.<p>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.<p>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.<p>Why do those complex Adobe clones work so well then?
They actually don't.<p>Slow, laggy UI is a common source of complaint on the issues.<p>Examples:<p><a href="https://github.com/storytold/cadcraft/issues/752" rel="nofollow">https://github.com/storytold/cadcraft/issues/752</a><p><a href="https://github.com/storytold/cadcraft/issues/874" rel="nofollow">https://github.com/storytold/cadcraft/issues/874</a><p><a href="https://github.com/storytold/vectorcraft/issues/2292" rel="nofollow">https://github.com/storytold/vectorcraft/issues/2292</a><p><a href="https://github.com/storytold/artcraft/issues/2409" rel="nofollow">https://github.com/storytold/artcraft/issues/2409</a><p><a href="https://github.com/storytold/photocraft/issues/9327" rel="nofollow">https://github.com/storytold/photocraft/issues/9327</a>
Don't know about the other links you've posted, but for photocraft the vast majority of those issues are from the engine that process the image itself, not about the GUI. In fact, as far as I can tell, none of the artcraft apps are that complex in terms of GUI to be slow down by any choice of GUI framework really. There could be performance differences between them, yes, but not so much.
I see. Not my experience using those apps though. There are bugs but they get fixed.<p>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.
With vectorcraft loading shape libraries can be slow, but this is a background thread.<p>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.
It's November and most of these issues were fixed two weeks ago.
Why are you stating something that is not true as though it were a given, and then using that unearned precondition as the basis for your question? The premise is false. Artcraft is a complete fucking trainwreck, nothing more than scamware that falls apart as soon as you poke beyond the deceptive facade that was used to build hype.<p>(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)
This does not match my experience, I use gridcraft (excel), vectorcraft (illustrator) often; they work fine.<p>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.<p>I'm not a power user, but for my particular use cases artcraft apps are better than the original counterparts (install-size + agent control).
They are already usable and get better quickly. Are you working for a competitor?
I ran PhotoCraft in a VM and it runs like a game at 3 fps. Very laggy.
How’s accessibility?
UI for CAD-style apps is not that complex. You're typically looking at maybe hundreds of visible controls at most. Of course, assuming that the rendering of the picture/parts is handled separately.
Well, primarily users of Adobe software don't have efficiency in mind as their first priority. It's a little different if you are making a desktop widget and it eats a good chunk of your GPU while idle.<p>Most of these GUI software are vibe coded so state management essentially becomes somebody else's blackbox problem.
So, is there anything native between Qt and GPUI?<p>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”.<p>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...
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.
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?
Of course you can, and you can also make it so that if UI changes, instead of having every single entity rerender, only the changed entity would rerender, and you can have a library that manages the changes or "dirty" state of these entities reactively.<p>And that's why React exists.
Almost every GUI toolkit does this, it’s nothing React specific. And with the browser you have to know all sorts of complexities to know what it’s actually doing (is this change going to cause a full layout, full paint, etc.)<p>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.
Doesn't that need a whole new framework with other downsides but the first option lets you use it with how it is designed?
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.<p>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 <i>humans</i>
gpui is pretty shite at energy draw too. bitemyapp’s sidestep is way better.
[flagged]