A Critique of GPUI

The central claim is that GUI frameworks must answer what runs when a value changes, and that models without precise dependency tracking become costly as interfaces grow. Immediate-mode egui redraws all UI code on the next frame; Elm-style architectures rerun the view and diff the result; GPUI reruns views after explicit notifications. GPUI’s notify identifies an entity but not which field changed or which output depends on it, so uncached views are rebuilt even for sparse updates. In benchmarks with 3,000 rows, changing one label took 8.4 ms with a cached view per row and 92 ms with plain elements; equal-value writes cost nearly as much as real changes. A hand-written equality check reduced one such write to 0.9 microseconds.

Retaining GPUI views helps only when view boundaries match state ownership: it improved a panel-owned-state benchmark by 83%, but made a shared-model case 11% slower, and a 3,000-row update still took 3.4 ms. Making updates more granular requires separate entities, subscriptions, stored values, and manual guards - recreating a signal graph with more cumbersome machinery. Elm’s single-state, message-driven model is explicit but can scatter derived values across update handlers and route local interactions through large message structures; it also does not reveal which view reads a changed field. The proposed alternative is run-once components with signals: the framework tracks reads and reruns only dependent closures, keeping derived values in one place while avoiding whole-tree work.