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 definitely shot themselves in a foot with building multiple renderers while building them on top of each other.
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.
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.
winui3 was abandoned the moment it was conceived.
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.
UWP came along in windows 10.
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.
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
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.
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.
Or a 2 row taskbar?
So I can easily switch between my 40 windows open? What is good for productivity?
BoorishBears•5h ago
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
jiggawatts•3h ago
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"!