GPUI's notify Is Just zone.js in Rust Clothing
A Critique of GPUI
GPUI and egui are drawing serious attention as native Rust GUI frameworks, but their state models may not scale. Benchmarking a 3,000-row list shows a single label change costs 8.4 ms with caching and 92 ms without, because GPUI's notify can only say an entity might have changed. Making updates precise means hand-building a signal graph from entities and subscriptions, which defeats the plain-function API people chose GPUI for.
Keep the pleasant API and you get view-sized updates. Take the precision and you lose the pleasant API.
- virtualritz
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.
- x-complexity
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".
- jharsman
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.
- faangguyindia
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.
- bluegatty
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)