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.
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.
Technically true, but while they might not be onscreen, sometimes you have a thousands of rows that the user can scroll through, and each row might have multiple input widgets. A UI framework should have a good way to handle large scrolling lists.
There are also photo apps where you can scroll through decades of photos.
Also, text editors should be able to handle large files, and filesystem widgets should handle large directories.
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.
> 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.
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?
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.
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.
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.
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.
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.
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 :)
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.
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
both of these examples look fairly trivial. they can easily be implemented in almost any ui toolkit.
to me, the complexity of a UI comes from the state management. imagine if the data for those cards is sourced from multiple places, with various rules, and can also be updated from multiple places. how do you keep it all in sync?
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.
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.
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.
> 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.
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.
> resize retained mode ui windows and the fps drops to like 2
This just isn't true? Every desktop application I use uses a retained mode UI and most of them resize smoothly. Most of the ones that don't are electron.
I genuinely don't understand how you can make this claim right after agreeing with me that the only difference is the caching. You can't seriously be claiming that by just adding a layout cache you lose 30x performance?
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.
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.
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)
> 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.
> 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).
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.)
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.
- "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.
> 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.
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.
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.
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.
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…
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.
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.
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.
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.
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)
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).
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.
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!
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.
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 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...
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.
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).
I remain convinced that the only reason people have gone with GPUI is because LongBridge shipped a set of relatively well engineered components that people could reasonably slap together into workable, shipping applications.
There is no other UI framework in the Rust ecosystem that offers this right now. Contrary to popular opinion, most developers absolutely suck at writing UI code - and especially at writing their own widgets.
tl;dr it's not due to Zed, it's due to LongBridge.
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.
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.
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
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..
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.
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
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.
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.
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 "who cares if it doesn't scale" attitude sucks if your users suddenly pass the threshold for whatever reason.
A well-engineered product shouldn't have possible states that don't perform well.
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.
Technically true, but while they might not be onscreen, sometimes you have a thousands of rows that the user can scroll through, and each row might have multiple input widgets. A UI framework should have a good way to handle large scrolling lists.
There are also photo apps where you can scroll through decades of photos.
Also, text editors should be able to handle large files, and filesystem widgets should handle large directories.
AppKit had ways of handling this 30+ years ago. NSTableView can easily handle millions of rows.
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.
> 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.
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?
At that point you might as well ask the AI for advice, no discussion necessary.
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.
> 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
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.
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.
And what did you think about the actual piece?
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".
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.
> 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.
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.
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.
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 :)
> 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.
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.
Blender has seriously complex UI needs. No idea whether they use a reactive architecture but (claimed) raw performance is impressive.
https://github.com/ppmpreetham/BUI
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.
what do you consider to be a complex UI?
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.
It is a matter of how we define complexity.
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
both of these examples look fairly trivial. they can easily be implemented in almost any ui toolkit.
to me, the complexity of a UI comes from the state management. imagine if the data for those cards is sourced from multiple places, with various rules, and can also be updated from multiple places. how do you keep it all in sync?
imgui's eliminate that almost entirely.
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.
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.
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.
> 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.
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.
> resize retained mode ui windows and the fps drops to like 2
This just isn't true? Every desktop application I use uses a retained mode UI and most of them resize smoothly. Most of the ones that don't are electron.
I genuinely don't understand how you can make this claim right after agreeing with me that the only difference is the caching. You can't seriously be claiming that by just adding a layout cache you lose 30x performance?
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.
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.
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.
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)
> 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.
> 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).
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.)
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.
- "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.
> 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.
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.
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.
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?
They actually don't.
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
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.
You do realize that saying the PhotoCraft backend is also slow and buggy isn't helping your case, right?
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.
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.
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.
It's November and most of these issues were fixed two weeks 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.
I ran PhotoCraft in a VM and it runs like a game at 3 fps. Very laggy.
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)
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).
I've been using filmcraft for video editing and I've had no issues.
Agent does not feel discomfort from laggy UI so your point is moot.
They are already usable and get better quickly. Are you working for a competitor?
How’s accessibility?
egui has been integrated with AccessKit since a few years now
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.
Hundreds of visible controls sounds like more complexity than you want.
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.
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!
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.
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.
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...
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.
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).
I remain convinced that the only reason people have gone with GPUI is because LongBridge shipped a set of relatively well engineered components that people could reasonably slap together into workable, shipping applications.
There is no other UI framework in the Rust ecosystem that offers this right now. Contrary to popular opinion, most developers absolutely suck at writing UI code - and especially at writing their own widgets.
tl;dr it's not due to Zed, it's due to LongBridge.
AI critiquing AI’s favorite native UI framework, brilliant.
So, is there anything native between Qt and GPUI?
Having a middle ground, in between?
Slint?
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.
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.)
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?
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?
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
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..
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.
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
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.
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.
gpui is pretty shite at energy draw too. bitemyapp’s sidestep is way better.