Hacker News Reader

Comment by pjmlp | Hacker News Reader

If you watch the Windows UI community talks on YouTube, at least on public channels, whoever is in charge doesn't seem to grasp how much all those rewrites killed the ecosystem, and they keep asking people to invest into WinUI/WinAppSDK, which not only is yet another rewrite, the tooling is a joke versus UWP.

No wonder that Windows developer community decided to ignore whatever is related to WinUI, and focus on the stable technologies from the past.

View on HN

This was exactly why I gave up on .Net ecosystem. I learned c# as my first programming language, then I started playing around with winforms and then making utility apps for windows phone, everything was great except suddenly wp got killed and they released UWP afterwards, and then UWP got killed to make rooms for whatever came after it… all happened within span of 5 years, it’s really exhausting for developers especially knowing that something you spent time learning and working with probably gonna get dropped sometimes soon..

Looking for some advice here. I’d be interested to develop simple GUI’s at work. I don’t have much experience of that. I have a license for VS2015 to maintain legacy VB and C++ but I think an upgrade could be arranged. I’m comfortable doing web dev but the browser remains limiting. In my situation, would learning native gui development be worthwhile or is it much easier to stick to websites and/or Electron?

Much easier to go with Electron. The choice is made for you. With native Windows, it's a dozen different solution and you waste timing playing future teller to imagine which one won't be abandoned in the future. At least with Electron you can reuse your skills with websites and it's pretty established now. Yes, it's not as fast but it's fast enough.

Using WinUI is really easy to do. Whether you're using WinUI 2.8 with UWP or WinUI 3. So native GUI development isn't difficult at all. XAML is similar to HTML in a lot of ways. If you have your mind set on web development and want a native GUI, you could go with React Native for Windows.

Yeah, if one wants to have fun debugging all the issues that are still open since Project Reunion was announced in 2020, with less capable tooling than .NET Native and C++/CX, specially fun having to deal with CsWinRT and C++/WinRT, the latter already in maintenance, stuck in C++17, as the team is now having fun with Rust/WinRT.

At least Native AOT might support WinUI in .NET 9, something to look forward to, for anyone that still cares outside Redmond.

I think the alphabet soup thrown around in this thread alone is indicative for what‘s wrong with Microsoft‘s native user interface story…

I can throw similar alphabet soups from other ecosystems, either one is in and gets them, or not.

Not really. Apple has a much more consistent story on UI frameworks.

Not being around Mac OS long enough?

such as? If I remember correctly (has been a few years), over the last 15-20 years there were

iOS: UIKit -> SwiftUI

MacOS: AppKit -> Catalyst -> SwiftUI

there was definitely some churn within each one of those from version to version, but no complete rewrite needed afaik.

I advise then to pay attention to Apple developer podcasts for rants regarding each of them, and porting issues, you can start with ATP.

I listen to almost every ATP. I know the rants. None of them were along the lines of: Apple forces me to completely rewrite Overcast, or else it won't work on the next iPhone.

I wouldn't even include Catalyst in the list. It is only relevant to a small subset of developers.

My first Mac was an SE/30.

I’ve just created and compiled an empty WinUI3 project, and I got 131 MB of binaries just for the AMD64 architecture. The EXE from that folder crashes on startup with DllNotFoundException “Unable to load DLL 'Microsoft.ui.xaml.dll' or one of its dependencies”

Apparently, Microsoft couldn’t even setup the project template, need to manually edit the project file adding WindowsAppSDKSelfContained setting. After that it launches, but the binaries are now 151MB in 386 files, for a single AMD64 architecture.

By comparison, an empty WPF application compiles into 171 KB of binaries in 5 files, and the binary is CPU-agnostic, it runs on all CPU architectures. It depends on the .NET 7 runtime, but the runtime for my processor only takes 55MB to download. And if you’re unhappy about the runtime, you can instead target the older .NET framework 4.8 which comes preinstalled on Windows 10 and 11.

If on .NET, Windows Forms, WPF, or the community projects from Uno and Avalonia.

For C++, you're better off with Qt, wxWidgets.

You can use Visual Studio Community if the licence still fits your work, or in the case of Qt, Qt Creator alongside a recent VS or MinGW.

>For C++, you're better off with Qt, wxWidgets.

Only if you need cross platform.

You certainly never had the pleasure of using XAML C++, with C++/WinRT and IDL files, after the downgrade of using C++/CX.

On the Microsoft tooling stack even MFC offers better development experience on Visual Studio.

I left it out on purpose, because I doubt the OP would like to use MFC, and I wouldn't even recomend XAML C++ development experience to my enemies.

It's still worthwhile, and it will be for the foreseeable future.

If you want to dabble in desktop with C#, Avalonia is the best way to go nowadays. I'm having a blast with it working on a couple of projects for my assigned client, and in a couple of personal toy projects.

The art of creating your own desktop GUI library is probably already lost, so react/electron will be the best option. In fact you don’t even need electron. Just make it a web service. People prefer web, they used to web.

It can be pretty hard to deploy a web app in a corporate environment. Just getting an instance on a server is an uphill battle. Easier to have people run a local app.

Reply on news.ycombinator.com