Architectural Inquiry: Rethinking State Paradigms and Render Boundaries (Why Choose the React Paradigm?)

[yinhx3]

I’ve been closely following the development of Microsoft.UI.Reactor and am very intrigued by its design philosophy, especially with its recent expansion to support multiple languages. The documentation states:

What Reactor does target is a specific gap: developers coming from React, SwiftUI, or Jetpack Compose expect co-located state, declarative composition, and type-safe UI construction.

While I deeply appreciate the ambition to bring elegant pure-code declarative patterns to WinUI, I'd love to spark a friendly architectural discussion regarding how Reactor defines its reactive boundaries.

When we strip away the surface syntax, modern declarative frameworks generally operate on two orthogonal axes: State Lifecycle (In-View vs. External/Independent) and View Update Granularity (Virtual Tree Diffing vs. Fine-grained/Smart Updates). If we categorize the industry's mainstream paradigms based on their actual runtime behavior, we can see that React, SwiftUI, and Jetpack Compose are fundamentally different animals:

1. State Co-located + Virtual Tree Diffing (React / Reactor)

• The Model: State is forced inside the scope of the transient UI rendering function. Changing a state forces the entire component function to re-run from top to bottom, relying on a Virtual Tree Diffing mechanism to patch the UI.
• The Mental Toll: Developers must constantly guard against "stale closures" (especially in async operations) and manually manage memoization (useMemo/useCallback) to prevent handler loss across re-renders.

2. State Externalized + Fine-grained Direct Updates (Jetpack Compose / SolidJS)

• The Model: Jetpack Compose is conceptually closer to SolidJS than React. Both rely on pure, runtime-reactive data structures that exist completely independent of the UI engine (Compose's MVCC Snapshot System vs Solid's Signals).
• The Mechanics: They both aim for localized direct updates. SolidJS bypasses the component re-run via direct template compilation, while Compose uses a compiler plugin to segment functions into tiny "Restart Groups," allowing it to skip irrelevant code paths and even push state reads directly to the Draw phase (skipping function recomposition entirely).

3. State Bound to Properties + Template/Identity Slot Updates (SwiftUI / Lit)

• The Model: SwiftUI is conceptually closer to Lit (LitElement) than React.
• The Mechanics: In Lit, states are externalized into reactive properties, and updates only refresh the specific structural slots within the native template. Similarly, SwiftUI maps externalized states (@Observable / @State nodes) to an underlying AttributeGraph. When data changes, SwiftUI doesn't blindly re-run heavy rendering logic; instead, it uses the structural Identity of lightweight view structs to evaluate graph deltas and surgically push updates to the render server.

My Question

Given this landscape, "co-located state" does not have to mean locking the state's lifecycle inside a transient rendering function loop. Frameworks like Compose, Solid, and Lit have proven that we can achieve beautiful, file-level co-location without inheriting React's closure baggage.

What led to the architectural decision to adopt the specific React-like hook model (forcing state inside the Render() loop via UseState), which inherently forces developers to manage the mental tax of stale closures and manual memoization in a native desktop/app environment?

Did the team consider alternative blueprints—such as externalizing the state to live in a long-lived, independent layer (similar to Compose/Solid) or utilizing property/identity-bound slot updates (similar to SwiftUI/Lit)—which would keep the UI purely declarative while providing a much more stable environment for heavy asynchronous logic?

I would love to hear the team's insights on these reactive design trade-offs. Thank you for your incredible work on pushing the WinUI ecosystem forward!

[Chris Anderson (codemonkeychris)]

This is a great discussion, appreciate the question.

First, the I've built something with fine grained dependency tracking and updates in the past. I found that using a "vanilla" language (C#, C++, etc.) without some type of DSL on top became very problematic - all functions ended up needing to take State instead of T everywhere. it was hard to have ignorant/transparent code, everything kinda needed to know about the data model/dependency system. I think that Compose got away with this with their Composable (@composable) attribute and code rewriting, which is their DSL.

With this, we started with the basis of wanting to use unmodified C# compiler, no code rewriter and exact semantics of the C# language as it exists today.

I'm open to any of the options, I think it would be great to explore alternative designs, I am pretty fixed on keeping with C# semantics though, I want to avoid something like a fork of C# to address limitations.

As for how far we explored alternatives - we did some initial exploration, but then relatively quickly settled on a working path and wanted to see how far it could go. Since this was an experiment, we optimized for "time to market" and getting something we can use to gather feedback. Once we started going down the React style path, it was easy to make progress and focus on getting a cohesive story...

I think we have a pretty stable set of bits now, I think getting the AI to do a port to the two different models you propose would be really interesting to compare if these is developer/agent ergonomic wins or performance wins with the other two approaches.

At the moment, the functional style and C# focus seems to be working, and resonating. A next step of getting conviction on the state model and C# shape would be a good next step.

I'm curious, what would you use as the primary evaluation function to determine which of the 3 paths you'd go down? All three have market success and large stable developer bases, so it's not like one of the 3 has proven to be the "winner".

[yinhx3]

Thank you for such a candid and insightful response. It is very helpful to understand the practical trade-offs behind the project’s early phase, particularly the choice to leverage the unmodified C# compiler and optimize for time-to-market.

I would love to address your question regarding the "primary evaluation function" from the perspective of how reactivity models have evolved across web and mobile platforms, and how WinUI might leverage its late-mover advantage.

1. Decoupling "State Tracking" from "Template Construction"

When evaluating these paradigms, it is beneficial to separate how reactive data is tracked from how the UI layout is described.

• The former dictates how developers organize state lifecycle and async logic.
• The latter dictates the syntax ergonomics of building views.

You correctly noted that Jetpack Compose achieves its model via a powerful but heavy DSL and code rewriter. However, we do not necessarily need that level of compiler complexity.

If the vanilla C# language is expressive enough to construct a React-style declarative object tree, it is structurally capable of supporting a SolidJS-style evaluation network. The developer-facing syntax for writing templates remains largely identical; the core difference lies entirely in how reactive dependencies are wired underneath. If we maintain the current JSX-like complexity without adding heavy compiler forks, the template-writing experience will remain unmodified.

2. The Value of Front-End Analogs

The reason I brought up SolidJS and Lit as equivalents to Compose and SwiftUI is that evaluating architectures across entirely different hardware/OS platforms often introduces extraneous variables.

When looking at React, SwiftUI, and Compose in isolation, it is easy to categorize them broadly as "different flavors of MVU." However, by mapping them to their web-equivalent architectures, the underlying differences in state management and render boundaries become much more transparent and easier to compare objectively.

3. Industry Consensus and the Evolution Away from "Indiscriminate Re-runs"

The front-end ecosystem has spent over a decade refining reactive models. Today, the consensus has moved significantly toward Signals and highly localized updates (either bypassing the Virtual DOM entirely or minimizing its footprint).

• Lit is actively integrating Signals.
• Vue 3’s roadmap is steadily transitioning toward a direct-update model without Virtual DOM overhead.

For the developer, whether a framework uses a Virtual DOM or not has a minor impact on daily template composition. However, whether a framework uses a Signal-based model versus a React-style Hook model radically changes developer ergonomics.

Currently, React stands as one of the few major frameworks that still relies on the "indiscriminate function re-run" model. React’s immense success is largely rooted in its first-mover advantage and a highly mature ecosystem, rather than the perfection of its core reactive model. In fact, the React community has had to build numerous state-management abstractions precisely to alleviate the stale-closure issues and unnecessary re-renders inherent in its design.

4. The Evaluation Function: Embracing the Late-Mover Advantage

To answer your question on the primary evaluation function: it should optimize for Developer Ergonomics (lowering mental tax) and predictable runtime behavior.

While comparing React and Jetpack Compose can be complex due to platform differences, comparing React and SolidJS offers a direct architectural benchmark. In terms of developer experience, the Signal model naturally preserves closures and standard local variables because the setup block runs only once. It removes the need for developers to manually manage lifecycle patches like useMemo or useCallback.

For developers who have worked with verbose XAML and manual data-binding for years, any declarative/MVU solution represents a major step forward, which naturally explains the positive early feedback Reactor is receiving.

However, considering the evolutionary trajectory of both web and mobile architecture, WinUI has a unique opportunity to embrace a late-mover advantage. Rather than defaulting to the React paradigm because it provided the fastest path for an early experiment, the evaluation function should look toward the future. We can adopt a model that sidesteps the inherent closure complexities right as the rest of the industry is actively moving past them.

---

I completely agree that having an AI agent port a cohesive slice of code into a Solid-style Signal model versus the current React Hook model would be an excellent next step. Comparing the developer ergonomics and predictability between these two approaches would be highly valuable for the project's evolution.

Looking forward to seeing where Reactor goes next!

[Chris Anderson (codemonkeychris)]

OK, can't promise I'll get to this real soon (I have vacation for a couple weeks in June)... but, here is the (long) spec of the work to prototype the four options and the various aspects...

https://github.com/microsoft/microsoft-ui-reactor/blob/main/docs/specs/055-reactivity-and-representation-exploration.md

would be great to get feedback on the spec and what we should try before we take the time to do it. Once we run the experiment, I'll publish the results.

[Chris Anderson (codemonkeychris)]

had the robots do a couple prototypes while I was on a plane :)

https://github.com/microsoft/microsoft-ui-reactor/blob/main/docs/specs/055-reactivity-and-representation-exploration.md

Updated with findings. Short summary (§8.1):

• Lit-style: +10% FPS
• Solid-style: +20% FPS

Both changes introduce some noise (lambdas for prop set), which I need to see if that's really required, maybe we can avoid it. And the natural viral nature of using State everywhere instead of T.

I had the AI do a full mapping of all the hooks we have so far, and how they would change with this new model.

I think this is a good basis to decide if it's worth further investigation. I'll talk with the team here about it, but would be curious about the community take.

Is the performance win worth the syntax overhead?

[yinhx3]

Thanks for the incredibly thorough spec and the prototype results — seeing P3 hit 4.6×–9.6× lower per-tick cost than ReactorOptimized is genuinely exciting. It's rare to see an architectural discussion turn into actual measured data this fast.

I wanted to weigh in on the syntax overhead question, since it keeps coming up as the main trade-off.

---

Signal as a first-class primitive — the C# Task analogy

The spec repeatedly calls out the lambda-wrap noise in P3/P4 (() => count.Value) and the write-side inconsistency in P1/P2 (.Value for writes, implicit for reads). My gut reaction is: Signal is to a plain variable what Task<T> is to T.

When you hold a Task<int>, you don't expect it to participate in arithmetic directly — you await it, or consume it in a continuation. That's not syntax noise; it's the type system honestly telling you "there's an extra semantic dimension here" (asynchrony). Nobody argues that Task<T> should implicitly convert to T, because that explicitness is the value of the type.

Signal is the same shape of thing: it carries the semantic dimension of "this value evolves over time." When you write signal.Value, you're saying "give me the snapshot right now." When you write () => signal.Value, you're saying "subscribe me — let me know when it changes." If Signal<T> had an implicit conversion to T, it would be like giving Task<T> one — safe by coincidence in certain contexts, but silently catastrophic the moment you extract code into a helper. The spec's §12 Q-N already diagnoses this trap clearly.

---

"Default-efficient" vs "default-waiting" — two philosophical camps

This reminds me of another comparison I find useful: C# Task's philosophy is "default-efficient, explicitly wait." You pay nothing for asynchrony when writing synchronous code; only the explicit await opts you into the async machinery.

Java's virtual threads and Go's goroutines take the opposite approach — "default-waiting." All code looks synchronous; the runtime suspends and resumes for you. It's elegant, but you lose static visibility into "will this actually block?"

Back to Reactor: React's hook model is "default-re-run." A setState unconditionally re-executes the entire component; you trim the blast radius manually with memo and dep arrays. Solid's signal model is "default-efficient, explicitly bind." The component body runs once; only the places you explicitly lambda-wrap get subscribed and updated.

I think C#'s ecosystem already voted on this with Task — "default-efficient + explicit markers" is the C# way. Reactor going the Solid route is really the same philosophy extended to the UI layer.

---

Signals are becoming language-level, not just framework-level

This might be slightly beyond Reactor's scope, but I think it's worth surfacing:

On the JavaScript side, TC39 is standardizing Signal as a language primitive (tc39/proposal-signals). The champion group includes authors from Angular, Solid, Vue, Svelte, Preact, Qwik, Ember, MobX, and more. A core motivation is decoupling the reactive model from rendering — Signal isn't "framework internals" anymore, it's a general-purpose primitive, like Promise.

On the Android Compose side, a new library called Transform (merged June 11) introduces a headless Compose runtime — allowing Compose State to be used outside of the UI layer. The commit message says it directly: "allow for use of Composition outside of Compose UI." Even the framework that originally tied state most tightly to UI is now formally acknowledging that reactive state should be UI-independent.

This makes me wonder: could C# eventually have a language-level Signal primitive? C# 13 partial properties, C# 12 interceptors, plus the community's long-running frustration with INotifyPropertyChanged boilerplate — the pieces seem to be there. But C#'s tradition is to let libraries prove the need first (Span<T> proved itself before getting ref struct; ValueTask was a library before getting language support). So Reactor doing rigorous library-level experimentation at this stage is exactly the right move.

---

Is the syntax overhead worth it?

So, circling back to your core question: is the perf win worth the syntax tax?

I'd frame it this way: Signal's .Value / () => isn't really "overhead to optimize away" — it's more like "semantic markers to accept," the same way await is. The variable carries new semantics, so naturally it can't be used like a plain variable.

The For / When / Show replacing .Select / if / switch (§7.3 finding 1) falls into the same bucket. It is a real tax — but think about it: doesn't Task / Promise come with its own toolkit? Task.WhenAll, Task.WhenAny, Task.Delay, ContinueWith, ConfigureAwait… You introduce a new primitive, and a set of combinators grows around it. That's not a design defect — it's what primitives look like when they mature. Signal's For / When / Computed / Effect is that same toolkit. It feels unfamiliar at first, but once you internalize the "reactive control flow" mental model, it fades — just like await Task.WhenAll(...) is second nature after you've written enough async code.

That said, the Phase 1 list port results will be the real test. How much friction does this reactive vocabulary actually introduce in day-to-day composition? In principle, I think the tax is the price of admission — and a fair one.

Looking forward to the follow-up results, and thanks again for putting in the work to move this from armchair architecture to measured reality.

[Lucian (Blazero)]

After read this conversation carefully, I have to admit that this problem is more complicated than I thought. Hadn't expceted so much syntax overhead in user code for Solid style.
But has §7 been thoroughly reviewed? It doesn't mention how the collection was created at all. I'm not sure if it can reflect the real-world use of collections.

[whiskhub]

Without having looked at it in too much detail, personally I think I would also prefer a DOM-less approach with lambdas. I think performance should be prioritized for a native framework from the beginning. Also I feel like it would be easier to migrate from the previous x:Bind paradigm.

Although maybe not as nice to type - that's what AI will do for us going forward...

[Lucian (Blazero)]

Just posted a similar question, then I see this post.
I don't like the virtual DOM paradigm either. I think SolidJS's solution is better.

[Ryan Martin (eqpoqpe)]

https://github.com/dotnet/maui-labs/blob/main/src/Comet/src/Comet/Reactive/Signal.cs I think this is likely what you're looking for

[yinhx3]

Nice pointer — and good to see Comet revived at all (it was archived in dotnet/Comet). The interesting part: the reboot is built on Signal<T> instead of the old State<T>.

Key doc: the state-unification analysis. Short version: old Comet's user-facing state API was just State<T>; the reboot kept that legacy machinery and added a new Signal/ReactiveScope system, then the doc makes the case for consolidating everything onto Signal<T>.

For the record, MauiReactor is the other end of this comparison — React-style State + re-render/diff — so .NET already has both approaches live, not just on paper.

[whiskhub]

Chris Anderson (@codemonkeychris) Do you have new thoughts about this? The more time passes, the harder it gets to change stuff like this...
I feel like the reactivity to community feedback has dropped a bit recently, unfortunately.