In one line: the real job of a UI framework is deciding "when one value changes, what runs again?" GPUI's cx.notify() and signal-based components that track reads and "run once" give opposite answers to that question.

Why now

• A blog post published on 2026-11-08, "A Critique of GPUI" (zortax), sparked discussion on Lobsters. Its claim: the state models of GPUI (the Rust UI framework behind the Zed editor), egui (immediate mode), and Iced (the Elm architecture) hit a dead end in complex desktop apps, and the place to end up is signals that track reads plus components that "run once." The post opens by citing a 11-04 post on X by Discord's CTO announcing that the app is being rewritten in GPUI (per the post's footnote; I did not check the X post itself).
• Around the same time, both upstream GPUI and a fork are working on incremental rendering. One is Zed's PR #63800 by Mikayla Maki, "gpui: Incremental view rendering with a view tree" (a draft since September, closed 9/25). The other is Retained Mode in gpui-fast, a fork by Longbridge. Both record the entities a view reads while rendering as dependencies and reuse last frame's output for views that haven't changed. Same direction, very different construction.
• The reactions on Lobsters are split. Besides criticism of the prose ("reads like an LLM"), people pushed back: "GPUI is as fast as Zed needs and no faster," and "the caching facilities exist but go unused because things are fast enough in practice." Others agreed that "for quiescent apps, or very complex ones, read tracking really scales."
• What makes this technically interesting is that native Rust GUIs are now walking the same road the web already walked (zone.js → Angular Signals, Redux → selectors, React re-rendering vs Solid's run-once). Knowledge from the web carries over directly.

The problem

A UI is a function of state, and state changes a little at a time. So every UI framework carries some kind of incremental computation inside it. In his Xilem design post, Raph Levien quotes Ron Minsky: "hidden inside of every UI framework is some kind of incrementalization framework."

The questions to ask come down to two:

1. When you write a value, what runs again? (the unit of re-execution)
2. Who discovers that something changed? (the change detector)

The critique sums this up in one table:

The first three (immediate mode, Elm, views) are popular for good reasons. There's no state to synchronize, state lives in one place, render is plain Rust, and you need no macros or separate compiler. What the post asks is whether that simplicity holds up as the UI grows.

How it works

1. GPUI: notify means "something may have happened"

GPUI's README calls it "a hybrid immediate and retained mode" framework. State lives in an Entity (an Rc-like handle owned by GPUI), and the UI is rebuilt by Render::render each time. When you change state, you call cx.notify() yourself.

self.threads[i].unread = false;
cx.notify();

The key point is that Rust's &mut has no write barrier. The framework can't know which field changed, or whether anything changed at all. All notify carries is the entity id. As a result, every view outside a .cached() boundary gets re-rendered.

The critique compares this to Angular's zone.js. Angular's Signals RFC (Sub-RFC 1, April 2023) says zone.js "is only capable of notifying us when something might have happened in the application, and can give no information about what happened or what has changed," and concludes "This approach has not scaled well." notify is more precise than a zone, since it names an entity, but it makes the same kind of statement.