zlacker

Everytime I ponder getting into Windows desktop development I see a portion of this picture, think about doing all this in Java instead, then remember that that is its own UI mess (although overall less storied but worse functionality wise), then think Electron would be better, try to get Typescript and Vue.js to play nice in Electron, run for the hills, briefly consider if building a desktop UI in Unreal or Unity would be the easiest, then just go back to playing video games.

Edit: Thank you for giving such a nice summary of the current landscape of UI dev in Windows native development.

>>mey+(OP)
You know how Electron allows you to spawn a native backend server as a subprocess, to generate the pages that the Electron frontend interacts with? And how this means that you can write 90% of your program in some native language, and just do a thin UI in JS?

I wonder why nobody's created a "XAML projector" to allow you to create Windows UI applications the same way — by writing some platform-neutral app in Java or whatever, that needs no native libs loaded into it, but rather just knows how to generate XAML and, when told it's running on Windows, expects to be connected to over a socket by an also-XAML-speaking client.

Or I could say the same about Qt's QML.

(In fact, at this point I have to wonder: if modern UI frameworks almost always use an intermediary "view definition language" to communicate with the application anyway, then why are they even designed to load as native libraries resident inside the process? Why not just reinvent the X protocol on a higher level — have the UI toolkit be a local (socket-activated) daemon, and then all the things that use it are just clients that speak its protocol? I know, you can't directly draw to the screen from your backend this way. X11 DRI worked, though, and IMHO was a very good idea — SHM buffers are way easier to get working in most language runtimes than an FFI binding of some C++ UI toolkit is. Or maybe we can do one better, these days: just expose WebGL commands addressable to WebGL canvas objects over the toolkit's protocol.)

>>mey+(OP)
If you want to do windows desktop development, just find the oldest technique that still works and use that. I think you can probably still find pre-.net visual studio out there and use it, and it'll work. You'll miss out on some stuff, but oh well? If you get to the point where you have thousands of people hounding you about high dpi support, you've made it.

>>mey+(OP)
Most developers completely ignored everything Microsoft had to offer since Windows 7 and because Microsoft is Microsoft all their technologies continue to work and keep getting updated.

I, for one, never stopped developing in WPF.

>>mey+(OP)
JVM UI isn't so bad. I've written some pretty modern looking UI with it. The sophisticated controls are all there.

Modern JavaFX theme: https://github.com/mkpaz/atlantafx

Modern Swing theme: https://github.com/JFormDesigner/FlatLaf

And these days Compose Multiplatform: https://www.jetbrains.com/lp/compose-multiplatform/

I tend to use Kotlin rather than Java but of course Java is perfectly fine too. You can also use Clojure.

If you use any of those frameworks you can distribute to Win/Mac/Linux in one command with Conveyor. It's free for open source apps and can do self-signing for Windows if you don't want to pay for the certificates or the Store (but the Store is super cheap these days, $19 one off payment for an individual). Also supports Electron and Flutter if you want to use those.

From those frameworks you can then access whatever parts of the Windows API you want. Flutter even has WinRT bindings these days! So it's not quite so bad.

>>mey+(OP)
Thankfully WinForms and WPF are still around and supported in current dev tooling.