Live data from Hacker News

Windows native app development is a mess

domenic.me

371–380 of 481 posts

Re: Windows native app development is a mess

#371

Earlier quoted context omitted.

.NET versions are not fully backwards compatible. Would you like every Windows install to ship with over ten versions of the .NET runtime?

> Would you like every Windows install to ship with over ten versions of the .NET runtime? A better approach would be to not break backwards compatibility in the first place.

That's what .NET Framework (the one that ships with Windows) tried to do. It usually worked out but you'll still run into compatibility issues sometimes after bug fixes, behavioral changes, etc. because people accidentally build software which depends on quirks.

Re: Windows native app development is a mess

#372

Earlier quoted context omitted.

Only a very small minority of users actually care about dark mode. It is not a general expectation for software, as loud as those users may be on forums like this one.

And how do you know this? I decided to check myself, looked for dark mode statistics on android, and: >Dark mode is used by 81.9% of 2,500 Android users on their phones, in apps, and in other situations. 9.9% alternate between the light and dark So it's the other way around. Only a very small minority of users actually care about light mode.

Mobile is different from desktop. Dark mode became popular with OLED panels because on those it saves battery, and blacks actually look nice, compared to the average LCD. I use dark mode on mobile but light mode on desktop.

Re: Windows native app development is a mess

#373

I agree with all the comments here saying "stick with Win32" --- this is "a mess" that you can easily avoid. Speaking as a long-time Win32 programmer, the requirements for your app are doable in a few KB (yes, kilobytes --- my vague estimate is less than 8KB) standalone executable. This is how I arrived at that: Enumerating the machine’s displays and their bounds A few API calls. Probably a few hundred bytes. Placing…

A couple of weeks ago, I decided to write a GUI utility to propagate my new PuTTY default settings to existing sessions. I took the Go Walk package, which is Win32, and was done in several hours, most of those spent hunting down an obscure layout bug. So long with memory-unsafe languages.

Here's the source code for those who are interested: https://github.com/sergeax/stamputty

Re: Windows native app development is a mess

#374
post #19

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.

Looks like Tcl is still being developed, with 64 bit version released in 2024 [1]. How big is your software, is it mainly C code wrapped in Tcl for the GUI?

[1] https://en.wikipedia.org/wiki/Tcl_(programming_language)

Re: Windows native app development is a mess

#375
post #42
post #11

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…

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.

[deleted]

Re: Windows native app development is a mess

#376

Earlier quoted context omitted.

I still think that WPF was the peak desktop UI framework. Extremely powerful with lots of small composable primitives, can easily do declarative but drop into more traditional event-driven imperative style where it makes sense.

I live in a bizarro universe where I started my career working on an expansive WPF desktop app on .NET Framework 4.0, and am still working on it now on .NET 10. From my perspective it's been WPF the entire time, and it's been pretty okay.

That's actually pretty close to my own career as well.

Re: Windows native app development is a mess

#377

I agree with all the comments here saying "stick with Win32" --- this is "a mess" that you can easily avoid. Speaking as a long-time Win32 programmer, the requirements for your app are doable in a few KB (yes, kilobytes --- my vague estimate is less than 8KB) standalone executable. This is how I arrived at that: Enumerating the machine’s displays and their bounds A few API calls. Probably a few hundred bytes. Placing…

Using Win32 to write a UI in Windows is like pulling teeth. There are bindings for Rust but even still it's a nightmare. MacOS is slightly better but Apple's anti-competitive practices targeting developers makes it a tough sell. Linux is better still, technically, but due to the fragmented desktop environment landscape and distribution difficulties, it's also a hard sell. I think it's fair to say that the entire stor…

The sane alternative is macOS because there is one thing that Windows lacks; a community. Since 1984, there have been boutique developers who have spent their whole career working on macOS, making it better and living the dream of working on consumer software.

When I look at the apps on Windows, all I see are abandoned projects and MVPs with a borderline malware financial structure.

Re: Windows native app development is a mess

#378

Earlier quoted context omitted.

Just wanted to add a shoutout to WinJS for posterity, with which I built a Windows 8 app that I had published to the Windows Store for a brief period of time. Then they open-sourced the UI part of WinJS and decided it was just a web framework instead of an officially supported method for building Windows apps iirc, which was the end of my foray into the Windows store. https://github.com/winjs/winjs

If you want JS, isn’t react-native-windows an option?

WinJS was a bit different, where your app was genuinely just a bundle of JavaScript and a UWP host process dealt with the rendering. (No Electron-esque to deliver with your app) Made for some tiny, succinct apps.

Re: Windows native app development is a mess

#379

It’s been a long time since I had to touch Windows development. If I had to do it over again, I would use React Native for Windows UI where possible and low-level Win32-React Native module bridges for user space code. The last time I had to do Windows development was about 15 years ago. I used a library called WTL (I think a couple comments here mention it). I couldn’t use any of the newer stuff that Windows 8-10 wer…

You should run away from React Native Desktop screaming. It's built on top of WinUI 3, and inherits all it's problems, while also being dramatically slower. Almost all functionality requires writing C++ code, and communicating between C++ and JS is a huge pain in the ass. Use QT instead.

And if you think using it will let you port your app to other platforms, think again. There's no drop-in compatible equivalent of RNW for Linux, and the version for Mac is even worse than the Windows version.

t. works on a huge app written with React Native Desktop

Re: Windows native app development is a mess

#380

I agree with all the comments here saying "stick with Win32" --- this is "a mess" that you can easily avoid. Speaking as a long-time Win32 programmer, the requirements for your app are doable in a few KB (yes, kilobytes --- my vague estimate is less than 8KB) standalone executable. This is how I arrived at that: Enumerating the machine’s displays and their bounds A few API calls. Probably a few hundred bytes. Placing…

Using Win32 to write a UI in Windows is like pulling teeth. There are bindings for Rust but even still it's a nightmare. MacOS is slightly better but Apple's anti-competitive practices targeting developers makes it a tough sell. Linux is better still, technically, but due to the fragmented desktop environment landscape and distribution difficulties, it's also a hard sell. I think it's fair to say that the entire stor…

Win32 is easy: https://news.ycombinator.com/item?id=21459616

MacOS is not quite so simple: https://news.ycombinator.com/item?id=40085237

Post reply on HN