Like many other people, I unexpectedly found myself stuck at home without much to do in early 2020. To stay sane, I set about answering a question I’d had for a while: what’s the deal with native GUI frameworks on Windows these days?

It’s rarely obvious which of Microsoft’s several supported technologies is the best choice for a new project, and Windows doesn’t have the same culture of idiomatic+consistent native GUIs as macOS. After months of obsessive escapism focus I emerged with a decent understanding of the problem space; let’s start with an overview of the technologies in use today:

Win32

This is kind of a catch-all term for the old-school way to build a Windows application using arcane, less-than-ergonomic C APIs. This is unpleasant and your application will look ugly, but one big advantage is that the Win32 APIs will live forever and they underpin all the other UI frameworks.

It’s well worth your time to learn a bit of this (read Charles Petzold’s book ), but it’s rare to see people building pure-Win32 GUIs these days.

Windows Forms (WinForms)

A designer-first GUI framework for .NET applications. It gets a bad rap because the average WinForms UI is pretty ugly, but it remains surprisingly practical. WinForms is a thin layer over the old-school Win32 APIs, which is both a blessing (simplicity) and a curse (mediocre layout+styling options). WinForms is well-supported by the .NET team.

Windows Presentation Foundation (WPF)

A sophisticated GUI framework using a declarative HTML-like language (XAML). It’s pretty good but complex and nearly abandoned; it hasn’t received new features in a decade. Ownership has changed to the Windows team (previously WPF was owned by the .NET team) and they’re doing the absolute bare minimum to support it.

Many people still use WPF to build new applications today, and I can’t blame them. But it doesn’t exactly have a bright future.

Universal Windows Platform (UWP) / WinUI 2

To make a long story short, this is what Microsoft started pushing heavily with Windows 8. It uses XAML just like WPF, but the default styling looks a lot nicer. UWP applications are quite nice to use.

Unfortunately Microsoft saddled UWP developers with incredibly painful sandboxing and packaging requirements, and as a result it never saw much adoption. Microsoft finally pulled the plug about a year ago, and UWP is in maintenance mode; do not start new projects in UWP.

WinUI 3

A small team is trying to salvage what they can from UWP’s UI stack (WinUI). Slow, buggy, and weighed down by a lot of historical baggage. Very few teams at Microsoft are dogfooding WinUI 3, and so I hesitate to recommend it.

WebView2

The Windows team has been going full steam ahead embedding Edge/Chromium in Windows, and WebView2 is the result. WebView2 makes it easy to embed web UI in any native application (here’s a demo), and Microsoft teams are adopting it en masse.

It’s a little sad, but if you’re looking for an actively developed UI technology with a lot of energy+investment behind it… this is it. All the usual complaints about web UI apply, but if you can get past those I have no qualms recommending WebView2.

Wow, what a mess. Why did things end up this way?

It’s all Steven Sinofsky’s fault. Well, it’s complicated.

Win32 has many shortcomings for historical reasons, and Microsoft’s obsession with backwards compatibility means that it can’t be improved.

WinForms made it a lot easier to build a UI, but it’s a thin layer over Win32 and it can only go so far.

WPF was a huge leap forward with a big team behind it. But then it got abandoned because:

The Windows team bet big on UWP. In some ways they did a great job; UWP made it easy to build attractive, fast UIs that work well on multiple devices (computer, tablet, phone). Unfortunately, UWP’s good parts were coupled with an unacceptable bargain: to use UWP technologies, developers had to cede a lot of control over distribution of their application. Most developers decided this was a raw deal, and rejected it.

Microsoft realized their mistakes with UWP a few years ago, and have been trying to make various UWP-related technologies (including the UI framework WinUI) available with fewer restrictions. Unfortunately I suspect these efforts are too little, too late; I believe that if WinUI 3 had a bright future, we’d be seeing Microsoft adopt it internally. By and large, they are not.