Microsoft UI Technology Overview

I feel that this is getting somewhat out of hand. Where we once had a single technology from Microsoft I now have to deal with nearly a dozen different names and options.

Technologies

Let's see what is out there and where to use what.

I sorted the list alphabetically.

ASP.NET

Not really directly a UI technology, but I thought I'll should add it due to Blazor being on the list, too. This category includes Server-Side Blazor.

Using ASP.NET (Core) we can introduce server-side rendering, which makes sense especially for mostly static websites or smaller apps. There are templates that leverage Angular or React, however, in this mode ASP.NET is mostly used as a data delivery agent in form of a web API.

While the roots of ASP.NET Core go back to ASP back in the mid 90s, ASP.NET has seen many faces. Starting with web forms a more Rails-like counterpart ASP.NET MVC was introduced in 2007. Later things like ASP.NET Pages has been added to the list. All the different variations now live in the modern ASP.NET Core.

• https://github.com/dotnet/aspnetcore

Blazor (WASM)

When WebAssembly became more established a lot of ideas and concepts started to be crafted. One of these ideas was the old intention of running .NET in the browser. Originally, not a novel idea (we had Silverlight already) the USP was given by not requiring any browser plugin.

Using Mono as a runtime the main concept is that a .NET runtime is transpiled to WASM. Then MSIL in form of DLLs can just be executed as in the standard CLR. Only difference: The system APIs are now not wired to the OS, but to the browser using JS interop. As an example, HTTP fetching requires using the JS fetch API.

The startup time and bundle size of Blazor is its weak point. With a minimum size of round about 1.5 MB there is no way to beat Angular, React, and others in startup time. All UI changes still need to brokered via WASM to JS using a VDOM model. All in all, Blazor therefore makes most sense for applications that can leverage a lot of existing (or shared) code, fitting in the PWA kind of applications.

• https://github.com/dotnet/aspnetcore/milestone/58
• https://devblogs.microsoft.com/aspnet/blazor-webassembly-3-2-0-now-available/

Blazor (Native)

As with React also Blazor uses a VDOM model that abstracts away the underlying platform. This is great, as the underlying platform thus can (in theory) be easily swapped out. What if you would suddenly not run in the browser, but in a mobile app?

As with React Native the devil is in the detail. Many Blazor components require JS interop and are placed directly in DOM interactions or other browser APIs. Quite often the abstraction model is just not prepared for easily swapping out platforms.

Nevertheless, from the pure Blazor perspective, as well as reuse of existing learnings Blazor Native is an interesting experiment done by the Xamarin team. Right now I would mainly see this as a proof of concept.

• https://github.com/xamarin/MobileBlazorBindings
• https://devblogs.microsoft.com/aspnet/mobile-blazor-bindings-experiment/

MAUI

This is where I actually see the future of .NET desktop app development. Its actually the successor of Xamarin and the production-ready version of Blazor Native.

MAUI wants to deliver on an app creation model that will be based on .NET 6 (right, that's one higher than 5, which is not even there). It is fully based on dotnet and does not look back. Its .NET's vision for the future of app development.

It supports multi app models (incl. the Flux architecture styles known as MVU in the .NET space) and features loosely coupled renderers. As with all new dev technologies from Microsoft it is open-source.

• https://github.com/dotnet/maui
• https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/

MFC

I had to include this one in the list. Released in the beginning of the 90s this one gained adoption so quickly - potentially, also due to the fact that up to this point the Windows API was quite horrible to develop against.

The Microsoft Foundation Class Library (MFC) made it possible to create Windows applications using C++ in no time thanks to object-oriented patterns. It is still supported today and got another update last year in July.

It is still proprietary.

• https://docs.microsoft.com/en-us/cpp/mfc/mfc-desktop-applications?view=vs-2019

Project Reunion

At BUILD 2020 Project Reunion was officially announced. The great thing about Project Reunion is that this will not be a new UI framework, but rather "just" an API compatibility shim. The essential idea is that this layer allows you to use your existing application with whatever API (e.g., a Win32 application using UWP APIs).

Microsoft has already started with exposing these new capabilities in projects like WinUI 3, WebView2 and MSIX-Core, which will allow us to work with all the available APIs.

Potentially, we'll never see this thing become a reality directly, but indirectly in all the other UI technologies I'm covering here.

• https://blogs.windows.com/windowsdeveloper/2020/05/19/developing-for-all-1-billion-windows-10-devices-and-beyond/
• https://github.com/microsoft/ProjectReunion

React Native Windows

React Native delivers a cross-platform way of creating mobile apps for iOS and Android. There are projects that also take the core set of components into other targets such as (back to) the web or Windows. React Native Windows is Microsoft's official project to do the latter.

React Native can be developed with anything that compiles to JavaScript. Usually, plain JavaScript or TypeScript is preferred. The model is to use React's fantastic component model for actually writing UIs for any platform. The runtime level then brokers between the React Native component names and their native counter parts running in another thread.

The result is not a web application, but a native application that also needs to contain a JavaScript runtime.

• https://microsoft.github.io/react-native-windows/
• https://github.com/microsoft/react-native-windows

UWP

The Universal Windows Platform combined the formerly called Windows Store apps and the Windows 8 introduced Metro-style apps into a single model. It is the way of writing Windows 10 applications. The benefit of this model was that even Windows Phone (10) and other systems with a Windows 10 kernel could be targeted without any change.

Under the hood the new Windows 10 API layer is used. This is not Win32 compatible. For declaring the UIs usually XAML is used, which seems very similar to WPF in many areas, however, should be treated differently due to vast differences in the implementation. Partially, we see this with the names and properties of the controls. The namespaces are also completely different.

For some reason UWP never really got the main attention. Partially, the web revolution and the decreased significance for client applications have been part of this. Another reason may be the restrictive Windows 10 status, which may not be the ideal target platform for your product.

• https://docs.microsoft.com/en-us/windows/uwp/get-started/universal-application-platform-guide
• https://github.com/Microsoft/Windows-universal-samples

WinForms

Windows Forms was .NET's first strike and an important strategic part in convincing former Visual Basic developers to switch to (VB).NET. It was mostly a shallow wrapper on top of the Win32 API written in .NET using a lot of PInvokes.

The power of .NET combined with GDI+ allowed the creation of great desktop apps together with advanced features in a lot less time than beforehand. Even today Windows Forms remains one of the most popular choices for writing Windows desktop applications.

Some of the reasons why Windows Forms is so good are the low memory footprint, low system requirements, and the agility of .NET itself.

• https://github.com/dotnet/winforms

WinUI 3

WinUI 3 is a component library that is part of project reunion. It is the next step for writing desktop applications on Windows - using Win32 and UWP APIs.

The components brought by WinUI 3 are designed with the fluent design system. The fluent design styling embraces today's modern devices, hardware, and inputs. By default, applications should be written in XAML again. It can be used in C++ and .NET-based applications.

• https://docs.microsoft.com/en-us/windows/apps/winui/winui3/
• https://microsoft.github.io/microsoft-ui-xaml/
• https://github.com/microsoft/microsoft-ui-xaml

WPF

Originally codenamed Avalon the Windows Presentation Foundation became a milestone for UI development on Windows and in general. The XAML-based notation together with the MVVM pattern made application development a joy. Dependency injection and loose coupling guaranteed great flexibility and testing possibilities.

Unfortunately, after technologies such as Silverlight and later on UWP have been released the development on WPF went down. The last sign of life was the release of WPF as (partially) open-source solution on GitHub.

Right now we can see WPF as a cool technology that provides many of the fundamentals for recent technologies such as UWP or Xamarin Forms.

• https://github.com/dotnet/wpf

Xamarin (Forms)

Starting as MonoTouch the third-party .NET implementation Mono became quite popular really quickly. With MonoDroid an Android counterpart to the iOS Framework was released afterwards. A commercial rebranding into the cross-platform label Xamarin helped to indicate their new direction.

Even though Xamarin remained in the shadow of some other solutions, Microsoft felt that having a unified .NET required their commitment, too. When Xamarin became part of Microsoft different things happened, among it the rebranding of Xamarin Studio to Visual Studio for Mac.

The most popular derivative of Xamarin is Xamarin.Forms. It features a XAML layer that picks the right native controls automatically.

• https://dotnet.microsoft.com/apps/xamarin/xamarin-forms
• https://github.com/xamarin/Xamarin.Forms

Comparison

The following table may be helpful to see what's inside.

All browser-based options (incl. ASP.NET) may be run inside an Electron (or similar) shell.

Conclusion

There are plenty of UI technologies out there - and Microsoft does not make it easier for developers to choose the right one. I kind of feel lost what to choose where. Sometimes, the target system can be fully known upfront, but quite often we want to have the flexibility to start with one platform (e.g., Windows Desktop) and easily have a web app later.

I hope that some of these technologies emerge together and that the outdated column will be almost fully populated.