Discussion

intrasight: "So when I went to work on my app, I was astonished to find that twenty years after the release of WPF, the boilerplate had barely changed."Such is the benefit and the curse, I guess, of having the Windows API being locked in the distant past for backwards compatibility.I've always been surprised that Microsoft didn't do a full operating system refactor and provide a compatibility layer for running old binaries. Perhaps they figure it would be better to just transition everything to software as a service using web tech? But I just don't see how that strategy is gonna work long-term.

wolvoleo: > And from what I can tell, neither are most developers. The Hacker News commentariat loves to bemoan the death of native apps. But given what a mess the Windows app platform is, I’ll pick the web stack any day, with Electron or Tauri to bridge down to the relevant Win32 APIs for OS integration.Well yes as a user I prefer native apps for their performance. It's clearly a mess to develop native apps as the article shows. But as a user I don't see that problem. I do see ever worsening apps though. Like the total mess that is new outlook and teams.

ashwinnair99: It has been a mess for 15 years and Microsoft keeps making it worse by adding new frameworks without retiring the old ones. Win32, WPF, WinUI, MAUI. Nobody knows which one to pick.

Smalltalker-80: Yes, and the hubris sting-of-death was UWP. They tried to make Windows into a mobile OS, severely restricting the alowed actions of programs, including strict certification to be able to run them (elsewhere). Of course nobody went for this and UWP died a quiet death. Recently there are signs that MS is trying to go back to making products that users actualle want (Win11 reverts). We'll see...

pdpi: > (Win11 reverts).I must've missed that one. What did they revert?

ozim: That is why everyone even Microsoft themselves does Electron.Running with html/css/js has benefits it really is open and free development based on international standards and not locked into any single big tech.

ToucanLoucan: Clown shit. “We’re made our own OS a nightmare to build on so we’re gonna use JavaScript powered pseudo-VMs and make everything take 2 gigs of ram minimum”

bentt: I wonder if Unity (the game engine) actually has a sneaky potential here. It’s cross platform, fast, and maybe just maybe less bloated than carrying around an entire browser like Electron?

pier25: Flutter is probably better suited for apps

cv5005: I'm an embedded programmer who occassionally needs to write various windows programs to interface with embedded devices (usually via serial port or usb), and I find it a breeze to write native gui programs in pure win32 and c++.Recently had to add a new feature to and old program that was last updated in the XP era and two things to note:1. The program did not need to be updated to run on Vista, 7, 10 and 11, shit just kept working throughout the years.2. I loaded the project into Visual Studio 2022, it converted from VC6 and compiled without problems, added the feature, shipped a new .exe to the customer, and it just worked.What other platform has that backwards and forwards compatibility success story?

lucianbr: How does it look? I mean, what do the widgets look like?

anthk: Given the size of some Electron software, bundling TCL/Tk with IronTCL and TCLLib+TKLib weights 58MB and you can develop your own software with it, and that with the source of everything included.And if you set a native theme for TTK in your code (literal two lines), your software will stop looking Motif-Industrial, the widgets will have the classic Win32 themes. It will look native from XP and up.

LAC-Tech: Winforms?lol at them still bekng the best option. so much wasted effort trying to replace them

pjc50: Winforms is great until you try to make windows dynamically sized, or deal with DPI nicely. In every other regard it's still fine, and for accessibility actually _better_ than many subsequent frameworks. And produces nice small fast executables.

jordand: The one big challenge I've had with big legacy Win32/C++ codebases is migrating it fully from 32bit to 64bit. Loads of know-how and docs for complex GUI controls and structs are lost to time, or really fragmented. Other than that, yeah it really does all just work once you're past that.

lpcvoid: Lazarus is crazy good, as is Delphi, if you can afford it. wxWidgets is also nice, without the licensing weirdness that is Qt.

v9v: [delayed]

lpcvoid: It doesn't matter - what Microslop says and what they do are traditionally very distinct things.But in case you want to read yourself: https://blogs.windows.com/windows-insider/2026/03/20/our-com...

samiv: To me this kind of "no need to change anything" implies stability but there's a younger cohort of developers who are used to everything changing every week and who think that something that is older than week is "unmaintained" and thus buggy and broken.

delduca: Best framework for this is Qt.

jordand: Yeah for my work, legacy Win32/WinForms/WPF codebases tools are kept maintained as-is, but new tools are usually written in PySide6 (QtWidgets or QtQuick) and it's worked out really well (other than bundling/distribution being tricky for big apps)

mschuster91: Doesn't WINE have pretty decent documentation by now from all the reverse engineering?

sourcegrift: Wine cannot even install office 2014. It's not really as food as some claim sadly.

fsloth: [delayed]

samiv: Seems to me that really the simplest solution to authors problem is to write C++ safely. I mean...this is a trivial utility app. If you can't get that right in modern C++ you should probably just not even pretend to be a C++ programmer.

sylens: Author raises several good points. Why isn't the latest .NET runtime pulled down into Windows 11 devices via Windows Update? Why isn't there a better path forward for deployment?It's another example of how they have completely abandoned any attempt at providing a good user experience across their products

moron4hire: Unity's 2D UI stuff is very poorly designed, with lots of edge cases where auto-calculated fields can hit a divide-by-zero issue and then become unrecoverable because the value is now NaN which can't be auto-calculated back to a number.

anthk: NPM it's the bigger turd happened ever, slow and bloated. And JS today amounts the biggest enforced propietary loading method of existence in almost every web page.Open? You wish.>and not locked into any single big tech.DRM and propietary cody tells me otherwise.

whobre: Interestingly, no mention of WTL

domenicd: Ahah, I knew I missed one!I originally had ATL in there, but my proofreading squad (Claude and ChatGPT) told me that ATL was a more niche thing for COM, and looking at the Wikipedia article I was convinced they were right.But WTL was what I was thinking of---the step between the MFC and .NET that I forgot.

PaulKeeble: Most of the desktop applications I have wrote over the years have been in other languages like Java and Go as I have wanted them to mostly be cross platform. In these cases I have always used the Software UI, which in Java is Swing and in Go is Fyne. These are usually reasonably fast, don't necessarily look native depending on how its themed but ultimately fit the language better than trying to bridge to Win32 or GTK/QT.

anthk: Lutris can up to 2016.

hliyan: I've recently discovered FLTK: https://www.fltk.org/doc-1.4/intro.htmlHaven't used Qt in a while, but at first glance, seems simpler: https://github.com/fltk/fltk/blob/master/examples/menubar-ad...

rwmj: This is quite timely as we need to write a simple UI for Windows (a few buttons, a status bar, maybe a file menu). The main constraint is it must compile to a single binary (.exe) with no dependencies such as runtimes, DLLs, languages etc. It also needs to run on some older unsupported Windows systems, probably Windows >= 7.My first thought was MFC. Basic, fast, well understood.But then maybe WxWindows so we can cross-compile it (from Linux) and use the same UI on other platforms? It could probably be compiled statically although I've not tested it.Or Mono, but that needs a runtime?

kwanbix: [delayed]

mcswell: Repeat after me: New! Fresh! Clean!

user____name: I feel like I'm the only person in the world who would rather write ugly win32 jank for the rest of my days than ever having to touch an "elegant" or "well structured" Cocoa codebase. In win32 if you want a button you call a function and pass a hande, in the Apple world you first subclass 7 interfaces in some unreadable Smalltalk-wannabe syntax and pray you don't need to access the documentation. And of course they constantly change things because breaking backwards compatibility is Apple's kink.

762236: This is such a wonderfully beneficial comment to the HN community. It should get an award.

fsloth: Sure but different target market.CRUD apps are non-trivial.If Unity were to ship platform native replacement for WPF equivalent (hell or even winforms) it would become a really enticing app development platform.

flohofwoe: > CRUD apps are non-trivial.Aren't these pretty much the most trivial UI apps possible? E.g. compared to other native apps like Photoshop, Blender, Visual Studio or Office, CRUD is mostly just about banging together custom UI frontend for a database.Unity's editor is implemented in its own (old) UI system, same with Godot, so in both engines it's possible to create 'traditional' non-game UI applications.

rwmj: Nice, I didn't know there was a free software version of Delphi nowadays.

ocdtrekkie: I write .NET Framework 4.8 apps. And I will until .NET has an actual support lifetime. 4.8 will still be supported and receiving security updates in ten years, .NET 10 will be gone in 2.Hobby projects should not be built on a platform that is constantly changing underneath.

GeoAtreides: come back home Delphi 7, all is forgiven

dgxyz: After bouncing around GUI toolkits (from win32 to SwiftUI) and web for 30 years I have simply run out of fucks. They all suck. Each in their own unique way. Apple aren't worth singling out - they are just their own special isolated variant of it.

LocalH: WinForms forever :evil:

Dwedit: In 32-bit windows, you used to be able to see if a pointer was valid or not by seeing if it pointed to the last 2GB of address space. If it did, it was pointing to Kernel memory that was not valid for user mode code.But then Large Address Aware (4GB limit) changes everything, and you can't do that anymore. In order for a program to be Large Address Aware, you need to not try to do things like check high bits of pointers, then every single library and DLL you use also needs to do the same.

raw_anon_1111: That sounds like the same ugly hack that caused programs not to be “32 bit clean” back in the day for Macs

aaomidi: When Microsoft themselves use electron to develop apps what expectations can we have on other devs?

Sindisil: To do better?It's demonstrably possible. And further, why does what some portion of Microsoft, a huge, multi-headed beast, does qualify as the bar for what is reasonable for users to expect?

raw_anon_1111: One of the earliest security issues that I remember hitting Windows was that if you had a server running IIS, anyone could easily put a properly string encoding in the browser and run any command by causing IIS to shell out to cmd.https://learn.microsoft.com/en-us/security-updates/securityb...I mentioned in another reply the 12 different ways that you had to define a string depending on which API you had to call.Can you imagine all of the vulnerabilities in Windows caused by the layers and layers of sediment built up over 30 years?It would be as if the modern ARM Macs had emulators for 68K, PPC, 32-bit x86 apps and 64K x86 apps (which they do) and had 64 bit Carbon libraries (just to keep Adobe happy)