Microsoft principal software developer engineer Alexandre Chohfi has posted about WinUI Reactor, an experimental framework for building WinUI applications using C# and a reactive pattern. The rationale for Reactor is two-fold:
- The popularity of React for web applications, and other reactive frameworks like SwiftUI and Jetpack Compose, makes using XAML for the user interface a barrier to adoption.
- Writing the user interface in plain C# is “easy for coding agents to read, write and check, so we now design for agents as well as people,” said Chohfi.
Note that Reactor is not a new platform, it is another way to code for WinUI, the existing platform which is supposedly the native UI framework for Windows but which competes with old-style Win32 (targeted by Windows Forms) and the DirectX-based WPF (Windows Presentation Foundation).
The easiest way to get started with Reactor is via the winapp CLI. Install the latest version and type winapp new selecting Reactor MVU App.
The template coincidentally creates a counter app similar to the one in Chohfi’s post. The UI is coded in a Render method and there is no XAML file, everything is done in C#.
Chohfi’s variant, which is also in the docs, is simplified but functionally the same. The template demo app calls UseReducer, whereas the documented demo calls UseState.
This may seem a terrible time to introduce a new (first previewed at Build in May) C# framework for desktop Windows. The niche for Windows desktop apps, mainly business applications, continues to shrink. Developers already face too many choices. Legacy .NET applications generally use Windows Forms or WPF, both of which still work.
It is hard to see many React developers wanting to switch to WinUI, when there are many ways to code desktop applications in JavaScript or TypeScript, including React Native, which seems a more natural choice.
Another issue is that this is not cross-platform. Coding a new application for Windows only seems short-sighted in most scenarios, hopeless for the consumer market, and for business use limited to companies standardised on Windows. That said, there is always an argument for using native frameworks on each platform, if the resources exist to build WinUI for Windows, SwiftUI for Mac and so on.
There is a Rust variant of Reactor and one can see this being of considerable interest, to Microsoft internally as well as for other developers. AI plus Rust is a potent combination.
There are indications that Microsoft is serious about Reactor, particularly in the remarks in Chohfi’s post about new Reactor controls being “candidates to land in WinUI itself,” and that “we’re actively working with the C# team” such that Reactor may influence the C# language.
I was also interested in Chohfi’s remarks about the mental model required to understand application code. For a XAML-based app, he said that “what does this screen look like when Count is 5 is a question you answer by reading three files and mentally running a binding engine. In Reactor, that last question has a very boring answer: read Render().”
I suspect that this is a reason for the continuing appeal of the Windows Forms framework. The mental model seems easy: one places controls on a canvas, sets their properties, and for interactivity one can just double-click a button and write the code that will run. This does not work so well for a complex application, but for something simple it is fine.
The MVVM (model-view-viewmodel) architecture which is common (though not required) for .NET applications has advantages, but even Microsoft architect John Gossman who was an early advocate for the pattern said that “for simple UI MVVM can be overkill” and that large numbers of bindings impact performance.
Reactor is MVU (model-view-update), as is React. In this pattern, the model is the state of the application, the view displays the state to the user, and update sends messages to update the state, triggered by user interaction or server activity.