HN

Comments (74)

• apatheticonion
  I love gpui, I used it to build this https://github.com/alshlabs/quillA 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
• Menu

  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/zguizgui 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/gpuihttps://crates.io/crates/gpui/versionsGPUI'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".
• Menu

  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 onesThat 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.
• Menu

  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.
• kjksf
  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.
• Menu

  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 thingsarguments in the post sound reasonable but conclusion is off.
• Menu

  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)
• Menu

  rramon
  >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?
• Menu

  SkiFire13
  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)
• Menu

  jbk
  So, is there anything native between Qt and GPUI?Having a middle ground, in between?
• dfish
  Find surprising the author didn't use tauri, but I guess he only compared native frameworks
• swiftcoder
  > 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...
• ryeights
  AI critiquing AI’s favorite native UI framework, brilliant.
• txdv
  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.
• anon
  undefined
• WhereIsTheTruth
  They are hiding its cost in the GPU, nobody tracks GPU usage including VRAM usageSo 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 availableThe 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..
• Menu

  koolala
  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?
• Menu

  adamsvystun
  Is diffing really that expensive even in complex applications?
• Menu

  slopinthebag
  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
• cmrx64
  gpui is pretty shite at energy draw too. bitemyapp’s sidestep is way better.
• toolbrewlab
  [flagged]