For Windows UIs I've been getting into Win32/GDI/DirectDraw/etc.
Tools like CsWin32 and modern C# (ref returns) make working with these APIs a lot more approachable today. It used to be the case that you had to create a nasty C++ project to do any of this. Now you can just list the methods you need access to in your nativemethods.txt file and the codegen takes care of the rest.
Win32 is a lot lower level than other things you'd typically consider to be a "UI framework", but the important tradeoff is that it is also a lot harder for Microsoft to remove or screw with in any meaningful way. I cannot come up with something that has been more stable than these APIs. The web doesn't even come close if we are looking at the same timescales.
You still need C++ in many places, because of the COM rulez attitude within Windows team.
Windows Runtime Components was a lost opportunity to level up the play field for .NET.
As such, if you want to do something like a shell extension, or context menu extension, it is C++ as always, or having your little C++ stub that calls out into a .NET process.
> Win32 is a lot lower level than other things you'd typically consider to be a "UI framework",
From a user's perspective, Win32 is high level. No other Windows toolkit is able to draw buttons or scrollbars properly.
Yeah this entire discussion about these high level framework would be cooler to discuss the lower level APIs. As far as I know, the entirety of Windows rendering stack is built on either GDI or DirectX? With Win32 even being built on GDI?
It would be much cooler to discuss building a ground-up Windows UI stack as close to metal as possible which I guess would necessarily be using DirectX...
I think windows needs a community effort to create an actually good framework for native development on windows. Unfortunately I just dont think such a community is big enough.