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.
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".
vintagedave 4 hours ago [-]
Not sure I agree there (re 'advert disguised as a critique'). It's ok to have opinions that lead you to develop something different, and then share data to back up those opinions. The author is very open about zgui.
sho_hn 5 hours ago [-]
> This is an advert for zgui, disguised as a critique piece.
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.
lnenad 5 hours ago [-]
The argument is made in bad faith, what does it mean to scale in the scope of UIs? What is a complex UI? Do 99% of apps ever hit issues related to this?
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.
sho_hn 4 hours ago [-]
IMHO it's up to your own expertize to judge whether it's a good or a bad argument, which is distinct from the motivation of the author in making it. It's again perfectly normal for people overstate the relevance of minor advantages in their thing.
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.
lnenad 4 hours ago [-]
I mean, I don't disagree but hn is a forum, if someones likes to point this out I don't see it as a bad thing. Considering the brainrot from AI and infinite content, reading something like "hey this thing has some whatever agenda behind it" can zap my brain into actual critical thinking instead of content ingestion. But that's just me :)
fatata123 3 hours ago [-]
[dead]
skohan 3 hours ago [-]
> Framework maturity is an unavoidable contributing factor when choosing where to port over your application.
Performance is great, but the zgui examples in the repo look deeply unimpressive.
virtualritz 7 hours ago [-]
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.
amelius 6 hours ago [-]
The "who cares if it doesn't scale" attitude sucks if your users suddenly pass the threshold for whatever reason.
rayiner 40 minutes ago [-]
There’s a low ceiling on how much complexity users can process in a UI. We hit those limits sometime back in the late 1990s. There’s no benefit to having a UI that can handle 4,000 buttons on screen at a time.
skohan 3 hours ago [-]
A well-engineered product shouldn't have possible states that don't perform well.
virtualritz 6 hours ago [-]
With "your users" you mean developers?
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.
amelius 5 hours ago [-]
> And you make an informed choice of which framework you choose based on that.
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.
virtualritz 4 hours ago [-]
How is that outside the scope when the discussion is about a an AI-prompted blog post that is a thinly veiled advertorial for a most likely AI-prompted new GUI crate?
The fact that you can just prompt a UI kit swap should be at the core of the discussion then; wouldn't you concur?
amelius 3 hours ago [-]
At that point you might as well ask the AI for advice, no discussion necessary.
jharsman 10 hours ago [-]
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.
swiftcoder 8 hours ago [-]
> the AI-generated text is very hard to read
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
sashank_1509 8 hours ago [-]
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.
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.
nephyrin 9 hours ago [-]
I got as far as the table labeled
> What a write runs | Who finds the change
Good lord. If you are writing a thoughtful critique of something.. actually write it.
amelius 6 hours ago [-]
And what did you think about the actual piece?
faangguyindia 11 hours ago [-]
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.
hirako2000 9 hours ago [-]
Blender has seriously complex UI needs.
No idea whether they use a reactive architecture but (claimed) raw performance is impressive.
Apart from the main 3D viewport Blender's UI need don't look that complex. Most of its UI are panels with simple layouts and buttons/sliders/checkboxes. And I bet they don't use their UI library for the main 3D viewport.
slopinthebag 9 hours ago [-]
what do you consider to be a complex UI?
SkiFire13 4 hours ago [-]
See the Cards examples for Material Design [1]. There's no single linear layout but multiple ones in different directions and anchors. There can also be images and multi-line text.
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.
I think BUI stands out because of the intricate nesting and relational binding there is between elements and not only a lot of state, but precedents and context.
About intricacies, BUI can render css in its own engine, so if material UI widgets are necessary, it's just html layouts and css.
I think it accomplishes both kind of "intricate UI". I concede I haven't tried to see how material would render with it though, as it claims impressive performance, I doubt everything is GPU optimized, as even css itself doesn't have full coverage GPU optimisations in any of its browser implementations
10 hours ago [-]
slopinthebag 10 hours ago [-]
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 better with more complex ui.
ben-schaaf 10 hours ago [-]
I work on a GUI toolkit professionally. Immediate-mode libraries are cool, but they absolutely in no way shape or form scale better. 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.
slopinthebag 9 hours ago [-]
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...
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.
ben-schaaf 7 hours ago [-]
> you can cache layouts with immediate mode libraries
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.
slopinthebag 7 hours ago [-]
to some extent retained mode is a cache invalidation problem. imgui's sidestep this, except for a constrained set of cases where building the ui requires doing a lot of work, in which case a simple, bespoke cache can be used - to me this is far simpler than trying to wrangle your entire application through a generalized state cache abstraction. especially since doing so generally requires you to deeply adopt the UI framework's abstractions into your application code, regardless if it's a good fit or not - like you said, you can avoid duplication, but the tradeoff is massive coupling.
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.
codedokode 9 hours ago [-]
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.
slopinthebag 9 hours ago [-]
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.
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.
codedokode 8 hours ago [-]
How fast are shaders on CPU? Shaders are garbage. I remember many years ago I tried Ubuntu in a VM and it decided to use llvmpipe for rendering. There was a 30-second lag between clicking on anything and seeing the result. Since then I hate GPU-based GUIs.
kjksf 5 hours ago [-]
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.
arecsu 41 minutes ago [-]
According to the benchmarks posted there, it's like extreme edge cases involving ton of changes in the UI that I'm not sure which app in the real world really does that. And if they do, there are many other optimization techniques you can use in pretty much any of those GUI libraries.
There are two camps to define complexity, as far as I can tell: one involves dynamic updates to plenty of elements in the current "view" (where view is not necessarily what's in the viewport, but what is in the rendering tree of the current process), and the other one has to do with intricate visual eye candy stuff such as stutter-free, orchestrated modern animations and effects that could involve custom shaders. The article is talking about the first one. Personally, what defines a choice of UI library has to do more with the second camp, plus how stable it is, extensible, and if it works as intended in the platforms I want to ship the app.
pnyda 4 hours ago [-]
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.
bluegatty 10 hours ago [-]
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)
kaoD 7 hours ago [-]
> 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.
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.
ADevWithAnIdea 7 hours ago [-]
> 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.
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).
kaoD 7 hours ago [-]
Maybe I can understand better with an actual example? I might just be biased by React's mindset, but I've always considered two-way binding (and any non-unidirectional data flow) a mistake, and it has only brought me pain and sorrow.
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.)
amelius 6 hours ago [-]
In GUI style code you often use closures which have circular dependencies. E.g. button points to the closure (for its event handler), closure points back to the button (e.g. change color of the button upon press).
Obviously you can do this differently, but it makes everything less ergonomic for the programmer.
bluegatty 7 hours ago [-]
- "Tree-based data structures are just the bread and butter of Rust." - they are not - they are the opposite of 'bread and butter'. They create nearly impossible problems for borrow checkers. Literally where the borrow checker caps out and can't fulfill it's obligations.
- "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.
kaoD 7 hours ago [-]
> Parent/child and handler/emitter relations are very common. You can work around it, but unnaturally.
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.
9 hours ago [-]
rayiner 45 minutes ago [-]
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.
rramon 12 hours ago [-]
>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?
YuechenLi 11 hours ago [-]
They actually don't.
Slow, laggy UI is a common source of complaint on the issues.
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.
YuechenLi 10 hours ago [-]
You do realize that saying the PhotoCraft backend is also slow and buggy isn't helping your case, right?
usef- 8 hours ago [-]
Why not? If the raw renderer has an unoptimsied denoise algorithm, what has that got to do with egui?
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.
airesQ 10 hours ago [-]
With vectorcraft loading shape libraries can be slow, but this is a background thread.
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.
rramon 9 hours ago [-]
I see. Not my experience using those apps though. There are bugs but they get fixed.
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.
anthk 8 hours ago [-]
It's November and most of these issues were fixed two weeks ago.
virtualritz 6 hours ago [-]
This has nothing to do with egui and is app architecture and business logic being 'held wrong'. It's a classic when you don't really know what you're doing and ask a clanker to "make me AutoCAD" or "make me Photoshop". Or maybe when you don't care at the beginning.
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.
anonymous908213 11 hours 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.
(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)
airesQ 11 hours ago [-]
This does not match my experience, I use gridcraft (excel), vectorcraft (illustrator) often; they work fine.
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).
1ba9115454 10 hours ago [-]
I've been using filmcraft for video editing and I've had no issues.
codedokode 9 hours ago [-]
Agent does not feel discomfort from laggy UI so your point is moot.
rramon 8 hours ago [-]
They are already usable and get better quickly. Are you working for a competitor?
codedokode 9 hours ago [-]
I ran PhotoCraft in a VM and it runs like a game at 3 fps. Very laggy.
throwup238 11 hours ago [-]
How’s accessibility?
SkiFire13 10 hours ago [-]
egui has been integrated with AccessKit since a few years now
cyberax 11 hours ago [-]
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.
fastball 11 hours ago [-]
Hundreds of visible controls sounds like more complexity than you want.
Elucalidavah 11 hours ago [-]
These controls are largely independent; whereas the complexity being talked about here is interdependent GUI elements.
Something about every complex GUI being a spreadsheet-style calculation.
neutronicus 6 hours ago [-]
Yeah I’m not quite sure how you get to multiple hundreds.
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!
cyberax 5 hours ago [-]
Not really? Toolbars, a couple of tool windows with properties, menus, etc.
I can get to hundreds of elements, but not to thousands.
Some more complex web UIs can get to that level of complexity.
Onavo 12 hours ago [-]
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.
Most of these GUI software are vibe coded so state management essentially becomes somebody else's blackbox problem.
SkiFire13 9 hours ago [-]
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)
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
pona-a 3 hours ago [-]
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.
swiftcoder 8 hours ago [-]
> 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...
Klonoar 2 hours ago [-]
The Rust UI framework space suffers from everyone globbing on to the first project that has an external widget set that looks good, rather than something that uses the language well.
swiftcoder 59 minutes ago [-]
Yeah, at least in part because we have 10x unfinished/abandoned/moonshot UI frameworks for every production-ready one.
GPUI does have the distinct marketing advantage that it is used by an actual shipping app (even if not one that puts a heavy load on its UI framework).
ryeights 12 hours ago [-]
AI critiquing AI’s favorite native UI framework, brilliant.
jbk 10 hours ago [-]
So, is there anything native between Qt and GPUI?
Having a middle ground, in between?
cmoski 5 hours ago [-]
Slint?
11 hours ago [-]
dfish 7 hours ago [-]
Find surprising the author didn't use tauri, but I guess he only compared native frameworks
koolala 11 hours ago [-]
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?
YuechenLi 11 hours ago [-]
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.
And that's why React exists.
rudedogg 10 hours ago [-]
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.)
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.
koolala 10 hours ago [-]
Doesn't that need a whole new framework with other downsides but the first option lets you use it with how it is designed?
WhereIsTheTruth 6 hours ago [-]
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..
simonask 4 hours ago [-]
GPU-allocated memory isn't always kept resident. Depending on the compositor, window surfaces get swapped to main memory when VRAM pressure is high. This obviously slows things down, but at the end of the day, the window contents need to exist somewhere, and the monitor is attached to the GPU, so it needs to at the very least pass through VRAM at one point or another.
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.
adamsvystun 11 hours ago [-]
Is diffing really that expensive even in complex applications?
rtpg 10 hours ago [-]
You have the diffing, but you also just have the various random bits of churn from building up the thing to diff etc.
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
txdv 8 hours ago [-]
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.
slopinthebag 11 hours ago [-]
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
eviks 8 hours ago [-]
do you know of a similarly well-sourced and presented review of those approaches with framework benchmarks? This seems like an unfortunate niche where no human is willing to venture due to the required effort, but then the slop risk is too high to ignore in an assisted article.
creata 7 hours ago [-]
I'm beating a dead horse here, but benchmarks aren't a useful way to compare UI frameworks, because:
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.
cmrx64 10 hours ago [-]
gpui is pretty shite at energy draw too. bitemyapp’s sidestep is way better.
toolbrewlab 9 hours ago [-]
[flagged]
Rendered at 16:24:48 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
Performance is great, but the zgui examples in the repo look deeply unimpressive.
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.
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.
https://github.com/ppmpreetham/BUI
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.
I think BUI stands out because of the intricate nesting and relational binding there is between elements and not only a lot of state, but precedents and context.
About intricacies, BUI can render css in its own engine, so if material UI widgets are necessary, it's just html layouts and css.
I think it accomplishes both kind of "intricate UI". I concede I haven't tried to see how material would render with it though, as it claims impressive performance, I doubt everything is GPU optimized, as even css itself doesn't have full coverage GPU optimisations in any of its browser implementations
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.
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.
There are two camps to define complexity, as far as I can tell: one involves dynamic updates to plenty of elements in the current "view" (where view is not necessarily what's in the viewport, but what is in the rendering tree of the current process), and the other one has to do with intricate visual eye candy stuff such as stutter-free, orchestrated modern animations and effects that could involve custom shaders. The article is talking about the first one. Personally, what defines a choice of UI library has to do more with the second camp, plus how stable it is, extensible, and if it works as intended in the platforms I want to ship the app.
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.)
Obviously you can do this differently, but it makes everything less ergonomic for the programmer.
- "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.
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.
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
https://github.com/storytold/artcraft/issues/2409
https://github.com/storytold/photocraft/issues/9327
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).
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.
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)
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
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.
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...
GPUI does have the distinct marketing advantage that it is used by an actual shipping app (even if not one that puts a heavy load on its UI framework).
Having a middle ground, in between?
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.