Thew day ends in a Y, so Microsoft is launching a new way to build Windows applications. Get excited, Windows application developers!
If you caught our session at Microsoft Build 2026 or you’ve been watching the repo, you’ve seen this one taking shape in public for a while now, and a lot has changed since Build. Here’s the longer tour: Microsoft.UI.Reactor, an experimental C# framework that brings the MVU (Model-View-Update) pattern to WinUI desktop apps. No XAML files, no code-behind, no ViewModels.
Two things before the fun part. Reactor is experimental: no support policy, no API guarantees, published this early on purpose because we’d rather hear we got the design wrong now than once people have shipped on it. And it is not a replacement for XAML or MVVM, which we’ll come back to.
↫ Alexandre Zollinger Chohfi at Microsoft’s Dev Blogs
At multiple points in the linked blog post, Microsoft underlines that no, Reactor is not going to replace XAML. I’m sure Windows developers who learned Win32, Silverlight, WinRT XAML, WPF, UWP, WinUI 2 and 3, and all the others, over the past two decades will feel deeply comforted by Microsoft’s insistence that Reactor will not replace XAML.
Microsoft repeats: this won’t replace XAML. They swear.
lol yep.. It’s true, it won’t replace XAML. I’m 100% certain of this, because it’s proven that XAML won’t replace Win32 C calls and WFC for serious applications (and apps are all built in electron, so no worries there either)
> Win32, Silverlight, WinRT XAML, WPF, UWP, WinUI 2 and 3, and all the others
Silverlight, WinRT, WPF, UWP, WinUI2, and WinUI3 all use XAML. UWP and WinUI are both WinRT. They are all abstractions over Win32.
In terms of being an API for creating a GUI, UWP, WinUI2, and WinUI3 are essentially all the same thing. Other than a change in namespace, the XAML could be identical across all three.
Microsoft is a disaster but this list is not nearly as long as it looks and there has not been that much to relearn. A Windows app developer has seen a lot less churn than a web dev over the same period of time.
What Microsoft really sucks at is communication and naming things.
To put this in perspective, compare to the popular Qt framework (used for KDE Plasma).
There are two ways to build a UI in Qt, you can write it out as code. Or you can write it in QML, a declarative mark-up language which compiles down to Qt code.
For WinUI on the Microsoft side, XAML plays the same role as QML above. They are both declarative mark-up languages. UI.Reactor allows you to write the same user interface in code directly, just as you can in Qt above. UI.Reactor and XAML are two different ways of creating the same WinUI GUI.
UI.Reactor and XAML co-exist in the same way that Qt and QML co-exist.
Technically both XAML and Reactor are declarative approaches, and actually if you look at the syntax for Reactor it’s not too far away from the way Qt Quick is written. (Actually credit needs to be given to JavaFX 1.0 here because that was one of the first examples (that I know of) of embedding declarative UI syntax directly into a programming language context, as opposed to using a separate (usually XML-based) markup language. Qt Quick seems to have taken a lot of inspiration from that.)
As for Reactor, the name is not coincidentally similar to React, because that’s what’s the whole Model-View-Update way of doing things was first widely popularized.
Anyway,, Reactor is actually a lot closer to the Qt Quick way of doing things, with declarative UI definition done inline with UI logic, while Vanille C++ Qt uses .ui definition files which are separate from the code and analogous to XAML. So you’re right that the two approaches can and will coexist, but the analogous frameworks are actually opposite of what you said. Qt Quick is closer to Reactor and vanilla C++ Qt is closer to C# + XAML.
You are right. Point taken.
Let us know you don’t know what Xaml is in one single line.
People might still be using MFC or whatever, they might be using raw Win API, but honestly, the jump between frameworks in C# land is not about Xaml, it’s about MVVM vs MVC vs MVU. Declarative vs Xaml vs Razor basically.
I’m guessing you meant to reply to me. Me not outlining the relationship between all these technologies when saying a chronological successor has no market penetration doesn’t mean I don’t know what it is. I also don’t care, because life is short and all those technologies are irrelevant, so you are right to some extent.
Every new UI toolkit, toolkit component, whatever level of specificity you need to understand, since maybe 2007 has been used by hobbyists and 1.5 internal Microsoft products that were mandated to use it, and ignored by everything else useful. It used to seem like software companies were being luddites, but with a few more decades, I now realize they were wisely skipping yet another useless attempt at trending that will be abandoned next year.
People say this but it’s just not true. These frameworks are widely used in industry. I switch between WPF, AvaloniaUI and Maui regularly and the biggest difference is controls, not syntax. If you know MVVM and Xaml, you can switch easily.
Having some experience with Compose… Reactor actually looks quite nice!
It’s interesting nonetheless, going from being de-facto industry standard for building GUIs to now being a bit esoteric option.