A Critique of GPUI

ByteAtATime 48 points 19 comments November 09, 2026
blog.zortax.de · View on Hacker News

Discussion Highlights (7 comments)

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?

ryeights

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

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?

adamsvystun

Is diffing really that expensive even in complex applications?

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.

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.

creata

But how would the author's example `unread` counter issue with the Elm architecture (which doesn't seem especially unique to the Elm architecture) be any better with signals, their preferred appproach?

Semantic search powered by Rivestack pgvector
12,324 stories · 116,709 chunks indexed