GPUI Hits Performance Limits in Complex Apps

GPUI and egui have gained traction as native Rust alternatives to Electron, with Discord planning a GPUI-based rewrite. The author challenges this trend, arguing that both frameworks’ state models hit fundamental scalability limits in complex applications. The core problem: they cannot precisely track which UI components depend on which state changes, forcing developers to either accept degraded performance or manually build the fine-grained reactivity they chose a high-level framework to avoid.

GPUI’s “notify” mechanism exemplifies the issue. When state changes, the framework only knows something might have happened at a specific entity—not what changed or which views depend on it. This forces re-renders across entire view trees. Benchmarks show the cost: updating a single label in a 3,000-row interface takes 8.4 milliseconds with per-row caching, or 92 milliseconds without. Fixes that improve performance by retaining state between frames work partially but require developers to manually create separate entities, subscriptions, and guards for each dependency—converting GPUI’s appeal as plain Rust code into a complex, hand-managed signal graph.

The author argues signal-based UI architectures solve this tradeoff by making fine-grained reactivity the default. Redux and MobX already discovered this necessity, recommending developers split UIs into many observer components. GPUI works in Zed partly because the application is relatively simple and uses custom code that bypasses GPUI’s layout system entirely. Most applications won’t have that option, making signal-based approaches more practical for complex UIs.