I already lost count how many UI frameworks are in windows. It looks like complete chaos and mess.
I really wonder what they expect from open-sourcing it. Just to pretend how open they are? Or is there any real benefit to developers who target windows?
cheschire · 2h ago
WinUI is an evolution of UWP which is an evolution of WinRT. WinUI has been around for years.
MAUI is not exactly a competing product and is more about enabling cross platform UI development. Different intent.
WinUI is actually ok tech. It’s evolved over the years through a few iterations, now on WinUI 3.
Im mostly with you though. Until they rebuild the entire OS in it, including all of the administrative controls and tools, I don’t trust the longevity.
DiabloD3 · 16m ago
They already do, though. The big UI refresh in Win10 is all XAML, and the new Win11 taskbar (the one we all hate) is now a totally normal XAML app.
WinUI 3's big changes (to get a 3.0 version number) is not with the XAML stack itself, but its new ability to be called by unmanaged apps as a normal UI toolkit, so it can finally be used by all apps. No more using Shell UI like we're writing Win 3.1 apps.
And yes, some stuff in Win11 still isn't WinUI, which is kind of annoying, but some of those dialogs hidden away in Windows are at least 20 years old, and probably would need to be entirely rewritten, not merely have their UI's updated.
Also, fun fact: The Win8/10 taskbar's code predates Avalon (the prototype/codename for WPF), and trying to change/fix it at all usually ended up breaking it. It's one of the few binaries on Windows that would not be recompiled to build a new release image in fear of breaking it. Rewriting the taskbar made sense, GETTING RID OF SMALL MODE DID NOT, GODDAMNIT MICROSOFT.
qcnguy · 2h ago
WinRT came out of UWP I think. UWP was their first attempt to move beyond .NET
DiabloD3 · 24m ago
You have that backwards. WinRT is the managed languages runtime for Windows, introduced in Win8. Its sort of the replacement for COM/OLE but also defines the ABI dialect in a way that allows managed languages to call unmanaged code without an FFI penalty.
UWP is built on WinRT, and acts as a fully managed app container, similarly to how phone apps exist on your phone. It allows WinRT apps to be deployed to any Microsoft platform, Windows, XBox, Windows Phone, etc, but also Android and iOS, and also as PWA, and are guaranteed to run identically on any of those platforms. UWP apps must be written a fully managed language that runs on the CLR (ex: C# runs on the CLR, but C++/WinRT does not). UWP also uses the second generation of WinUI-family XAML UIs, which means all UWP apps use completely native UIs, instead of slow non-native Javascript shit in a web canvas.
The WinUI family of XAML UIs started with WPF, and a slightly incompatible version of it also appeared in Silverlight (WPF = WinUI 1.0), then was brought to UWP (= WinUI 2.0), and is now its own stand alone thing that any app can use, managed or not, as 3.0.
WinRT is not an attempt to move beyond .NET, instead it is their way of allowing .NET to natively call code, and make .NET languages first class in Windows.
cheschire · 2h ago
WinRT was windows 8. Remember the ARM-powered Surface RT had the same branding?
UWP came along in windows 10.
crinkly · 1h ago
Still writing win32 stuff like it’s 1995 here. We have bits of ATL/MFC hanging out which are throughly abandoned.
I don’t trust WinUI at all.
I was surprised, when I spoke to a former colleague, to find that an internal tool I wrote 25 years ago is still being maintained. Win32 as well.
ffsm8 · 1h ago
Software that solves an actual problem has the tendency to stick around, no matter how much time elapsed.
Just remember, cobol is still in active use, today
flohofwoe · 3h ago
They probably started something new and shiny (Now with AI!) and want to get rid of the old baggage without causing too much of a user revolt (all dozens of them) ;)
Just go for MFC FTW, it is in feature freeze but I will last probably for the next 20 years yet.
criddell · 26m ago
MFC/Win32 + XAML Islands (through the Windows App SDK) is a pretty nice combination for stability and access to new features.
daemin · 3h ago
Last I evaluated it WinUI3 was a terrible developer experience. The application had to be literally installed on the system to even debug it, which means you end up with a large number of useless start menu entries, not to mention registry entries and such. Another thing was that the example programs crashed when I clicked on a button.
All I want is something simple to work with to make applications for Windows, and so far I'm still using Win32 with WTL.
bloomca · 3h ago
> The application had to be literally installed on the system to even debug it
I think that's because you chose "packaged" application, these apps need to be installed so that capabilities are handled correctly.
To be fair, macOS has the same issue, although they won't show in Launchpad, they still can be indexed by Spotlight.
Springtime · 4h ago
I hope this leads to having a native vertical taskbar, which has been absent in W11 despite being a taskbar feature dating back as early as Windows 98.
Third-party tools have tried to reimplement it but it's either been by bastardizing the native W11 horizontal taskbar to be vertical (eg: Windhawk) or just restoring the old W10 taskbar code (eg: StartAllBack).
wild_pointer · 3h ago
How will making the UI framework open source lead to taskbar changes? For third party contributions in this area, they need to open source the taskbar, not the UI framework.
0points · 3h ago
The taskbar is a feature of explorer.exe.
The news being discussed is not about explorer being open sourced.
Timwi · 3h ago
Nit-pick: Windows 95, actually. The vertical taskbar was an option in its very first version.
flohofwoe · 3h ago
Is the Windows team even using WinUI for the native Win11 desktop UI? ;)
perching_aix · 2h ago
The Start Menu is apparently a React Native app, so I'm going to hazard a guess and just assume WinUI is built on top of React, and that the Start Menu at least is thus indeed built with WinUI. But it's also clear that some other parts aren't, so who knows what's what. I'm sure there are folks who spent time reverse engineering it all though who do.
qcnguy · 2h ago
WinUI is its own thing. The React Native stuff just shows that even Windows developers don't want to use WinUI.
madeofpalk · 2h ago
It's confusing what exactly 'WinUI' is, but does Explorer looks WinUI-ish. Parts of it at least.
e4m2 · 2h ago
Explorer uses XAML Islands. Parts of it are WinUI, while the rest is still Win32.
zerr · 2h ago
Even for Windows-only GUI software, it is much safer and sane to use cross-platform frameworks such as wxWidgets and Qt Widgets.
orphea · 21m ago
And if you're on .NET, something like Avalonia.
feverzsj · 4h ago
So, they gonna abandon it soon?
sirwhinesalot · 3h ago
It was abandoned from birth.
elygre · 3h ago
I won’t benefit from this. At the same time, I cannot see a single bad thing about it, so I’m surprised about all the negative energy.
sirwhinesalot · 3h ago
The "bad thing" is that it's effectively getting abandoned, open sourcing it won't make any difference.
It's not like external contributions will suddenly turn it into something usable, and they'll just have a skeleton crew maintaining it, like they do WinForms and WPF.
People are tired of Microsoft and their ever growing graveyard of ill thought out, half-baked, "native" UI frameworks.
dlachausse · 31m ago
Native UI is effectively dead outside of Apple’s platforms, and even there it’s hanging on for dear life. HTML, CSS and JavaScript won the cross platform toolkit battle.
sirwhinesalot · 17m ago
Sadly yes. And all the platforms are to blame. Microsoft and their 1000 half-working frameworks made writing a wrapper that was any better than wxWidgets impossible.
But also Apple "totally not deprecating" AppKit and pushing everyone to the mess that is SwiftUI, Gnome breaking backwards compatibility as a sport, and Qt messing around with QML, meant "native UI" became quicksand.
Even going HTML, CSS and JavaScript wouldn't be too bad if the browser engines provided by the OSes were any good, but it took Microsoft giving up and switching to rebranded Chromium as a browser for Windows to provide a usable one in WebView 2.
WebKitGTK is also terrible compared to the macOS version of WebKit, which hurts projects like Wails and Tauri. So everyone bundles a freaking copy of Chromium with their applications.
I should have studied mechanical engineering.
bloomca · 4h ago
I really hope they do and the rendering engine is decently decoupled, I'll give a try building a framework on top of it.
I wish all platforms gave access to their rendering engine similar to DOM on the web, imo SwiftUI/WinUI (or WPF, but they are very similar) are not that good.
Haven't built anything native on Linux, though, no idea how good those are.
jamil7 · 4h ago
What do you mean by access? APIs to program against or fully open sourcing the rendering engine? Because you can mix SwiftUI with a few different rendering frameworks at varying abstraction levels that it itself renders to (AppKit, UIKit, Core Graphics, Metal etc.)
bloomca · 3h ago
Basically I want an API available to build my own SwiftUI. Definitely not on the Core Graphics level :)
But good point, I actually think AppKit might be a good abstraction level. I'll play with it a bit and see if I can abstract it behind a good component model.
genter · 4h ago
What's wrong with Skia? Chrome, Firefox, and OpenOffice all use it, and it works on Windows, Linux, MacOS, and Android.
bloomca · 3h ago
Nothing wrong with it, just want something a bit higher level and ideally with at least some native components/styles.
incrudible · 3h ago
It is a ton of C++ for what is essentially something that an OS like Windows/MacOS/Android/iOS or the browser would provide anyway. Apps that use it ship with a substantial minimum amount of bloat, e.g. Flutter for web.
Rochus · 2h ago
How was it implemented? C#? C++?
e4m2 · 2h ago
C++
BoorishBears · 5h ago
Seasons may come and go, but one thing will never change.
Windows and an absolutely baffling array of UI frameworks with various pitfalls, uncertain futures, and no clear winners.
(honorable mention to WinForms though.)
politelemon · 4h ago
And I still give them points for trying, a rarity among the tech giants.
jiggawatts · 3h ago
My analogy is every Microsoft UI framework was almost completed in the sense of someone being almost pregnant.
A framework that has just one show-stopper missing feature or problem is... unusable. You can't embark on a large, complex application development journey if you even suspect that you'll be painted into a corner.
For example, many of WPF-derived frameworks had atrocious performance, with fundamental mistakes in their design that made them incompatible with list virtualization. It wasn't until they had to eat their own dogfood and use WPF for Visual Studio that they started fixing these issues.
Win UI 3 meanwhile dropped all support for HDR, wide-gamut, etc... going backwards to SDR sRGB only in an era where all mobile phone manufacturers were starting to standardise on OLED HDR displays. The logic behind this decision? Microsoft wanted a UI framework that is "mobile compatible"!
hyperbolablabla · 4h ago
I'm sure it'll be really user friendly(!)
bobsmooth · 4h ago
What "UI framework"? Windows is a Frankenstein's monster of different UI elements.
bloomca · 3h ago
Rendering engine + set of native components + APIs to make your own components.
Windows definitely shot themselves in a foot with building multiple renderers while building them on top of each other.
rvba · 2h ago
So will we be able to have more than 11 programs on the taskbar without them being compacted?
Or a 2 row taskbar?
So I can easily switch between my 40 windows open? What is good for productivity?
I really wonder what they expect from open-sourcing it. Just to pretend how open they are? Or is there any real benefit to developers who target windows?
MAUI is not exactly a competing product and is more about enabling cross platform UI development. Different intent.
WinUI is actually ok tech. It’s evolved over the years through a few iterations, now on WinUI 3.
Im mostly with you though. Until they rebuild the entire OS in it, including all of the administrative controls and tools, I don’t trust the longevity.
WinUI 3's big changes (to get a 3.0 version number) is not with the XAML stack itself, but its new ability to be called by unmanaged apps as a normal UI toolkit, so it can finally be used by all apps. No more using Shell UI like we're writing Win 3.1 apps.
And yes, some stuff in Win11 still isn't WinUI, which is kind of annoying, but some of those dialogs hidden away in Windows are at least 20 years old, and probably would need to be entirely rewritten, not merely have their UI's updated.
Also, fun fact: The Win8/10 taskbar's code predates Avalon (the prototype/codename for WPF), and trying to change/fix it at all usually ended up breaking it. It's one of the few binaries on Windows that would not be recompiled to build a new release image in fear of breaking it. Rewriting the taskbar made sense, GETTING RID OF SMALL MODE DID NOT, GODDAMNIT MICROSOFT.
UWP is built on WinRT, and acts as a fully managed app container, similarly to how phone apps exist on your phone. It allows WinRT apps to be deployed to any Microsoft platform, Windows, XBox, Windows Phone, etc, but also Android and iOS, and also as PWA, and are guaranteed to run identically on any of those platforms. UWP apps must be written a fully managed language that runs on the CLR (ex: C# runs on the CLR, but C++/WinRT does not). UWP also uses the second generation of WinUI-family XAML UIs, which means all UWP apps use completely native UIs, instead of slow non-native Javascript shit in a web canvas.
The WinUI family of XAML UIs started with WPF, and a slightly incompatible version of it also appeared in Silverlight (WPF = WinUI 1.0), then was brought to UWP (= WinUI 2.0), and is now its own stand alone thing that any app can use, managed or not, as 3.0.
WinRT is not an attempt to move beyond .NET, instead it is their way of allowing .NET to natively call code, and make .NET languages first class in Windows.
UWP came along in windows 10.
I don’t trust WinUI at all.
I was surprised, when I spoke to a former colleague, to find that an internal tool I wrote 25 years ago is still being maintained. Win32 as well.
Just remember, cobol is still in active use, today
All I want is something simple to work with to make applications for Windows, and so far I'm still using Win32 with WTL.
I think that's because you chose "packaged" application, these apps need to be installed so that capabilities are handled correctly.
To be fair, macOS has the same issue, although they won't show in Launchpad, they still can be indexed by Spotlight.
Third-party tools have tried to reimplement it but it's either been by bastardizing the native W11 horizontal taskbar to be vertical (eg: Windhawk) or just restoring the old W10 taskbar code (eg: StartAllBack).
The news being discussed is not about explorer being open sourced.
It's not like external contributions will suddenly turn it into something usable, and they'll just have a skeleton crew maintaining it, like they do WinForms and WPF.
People are tired of Microsoft and their ever growing graveyard of ill thought out, half-baked, "native" UI frameworks.
But also Apple "totally not deprecating" AppKit and pushing everyone to the mess that is SwiftUI, Gnome breaking backwards compatibility as a sport, and Qt messing around with QML, meant "native UI" became quicksand.
Even going HTML, CSS and JavaScript wouldn't be too bad if the browser engines provided by the OSes were any good, but it took Microsoft giving up and switching to rebranded Chromium as a browser for Windows to provide a usable one in WebView 2.
WebKitGTK is also terrible compared to the macOS version of WebKit, which hurts projects like Wails and Tauri. So everyone bundles a freaking copy of Chromium with their applications.
I should have studied mechanical engineering.
I wish all platforms gave access to their rendering engine similar to DOM on the web, imo SwiftUI/WinUI (or WPF, but they are very similar) are not that good.
Haven't built anything native on Linux, though, no idea how good those are.
But good point, I actually think AppKit might be a good abstraction level. I'll play with it a bit and see if I can abstract it behind a good component model.
Windows and an absolutely baffling array of UI frameworks with various pitfalls, uncertain futures, and no clear winners.
(honorable mention to WinForms though.)
A framework that has just one show-stopper missing feature or problem is... unusable. You can't embark on a large, complex application development journey if you even suspect that you'll be painted into a corner.
For example, many of WPF-derived frameworks had atrocious performance, with fundamental mistakes in their design that made them incompatible with list virtualization. It wasn't until they had to eat their own dogfood and use WPF for Visual Studio that they started fixing these issues.
Win UI 3 meanwhile dropped all support for HDR, wide-gamut, etc... going backwards to SDR sRGB only in an era where all mobile phone manufacturers were starting to standardise on OLED HDR displays. The logic behind this decision? Microsoft wanted a UI framework that is "mobile compatible"!
Windows definitely shot themselves in a foot with building multiple renderers while building them on top of each other.
Or a 2 row taskbar?
So I can easily switch between my 40 windows open? What is good for productivity?
winui3 was abandoned the moment it was conceived.