A Critique of GPUI

>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?

• Onavo · 1 hour 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.

• cyberax · 1 hour 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 · 1 hour ago

    Hundreds of visible controls sounds like more complexity than you want.

    • Elucalidavah · 48 minutes 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.

• YuechenLi · 52 minutes ago

  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

  • arecsu · 43 minutes ago

    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.

  • airesQ · 22 minutes 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.

• anonymous908213 · 49 minutes 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 · 28 minutes 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).

• throwup238 · 45 minutes ago

  How’s accessibility?

AI critiquing AI’s favorite native UI framework, brilliant.

Can't you fix this scaling by chunking the entities? So not making one massive 10,000 thing entity but instead breaking it up into entities that group 500 things?

• YuechenLi · 28 minutes 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 · 4 minutes 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.)

Is diffing really that expensive even in complex applications?

• rtpg · 21 minutes 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

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.

• slopinthebag · 20 minutes 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.

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

gpui is pretty shite at energy draw too. bitemyapp’s sidestep is way better.