Live data from Hacker News

Windows native app development is a mess

domenic.me

81–90 of 481 posts

Re: Windows native app development is a mess

#82
post #75

Earlier quoted context omitted.

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 c…

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.

But, why? It's been 30 years. You'd think somebody would have figured out how to make a decent GUI toolkit or framework.

Re: Windows native app development is a mess

#83
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…

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 c…

Sorry, but this is simply just misinformation.

If you were doing "classic" Cocoa in the way it was intended, you wouldn't need to subclass anything for a simple button.

You wouldn't even need to write a single line of code, you'd just instantiate said button in Interface Builder, hook it up to a delegate (e.g. a window controller) and off you go. You can create a hello world example with a handful lines of code.

And even if you'd rather create the button programmatically, it's not much more involved.

Sure, if you're coming from Win32 and expect to program Cocoa without learning Cocoa, you're out of luck. But I guess that applies to all frameworks.

Re: Windows native app development is a mess

#84
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…

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 c…

You can now use SwiftUI, which is, as of the latest version, quite stable. They used to change things a lot between releases a few years ago, but nowadays you don't need to refactor your code every year. Only issue with it is that it's iOS first, so you may need to fallback to AppKit (Cocoa) to implement more complex elements.

Re: Windows native app development is a mess

#85
post #37

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

Windows update is how it used to work and it's terrible. An update breaks old apps, or downloads a every single version (not feasible). Who would want to run windows update to install a new app?

It's just a bad idea. Today we just pack in the DLLs and it just works.

Re: Windows native app development is a mess

#86
It's always about the abstractions which try to cover the underlying mechanisms but not always can do it. The same with any programming, like named pipes for example. However I need to tell you that

1. Wow you have great knowledge of windows. Congratulations

2. Boy windows API is a mess.

Re: Windows native app development is a mess

#87
post #75

Earlier quoted context omitted.

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.

But, why? It's been 30 years. You'd think somebody would have figured out how to make a decent GUI toolkit or framework.

We just built layers of shit over the ones we have.

Re: Windows native app development is a mess

#89
post #58
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…

Honestly, your GUIs are too simple to be part of this conversation. Try writing something like Spotify in WinAPI and that's not even a complicated GUI either.

Most apps at the time managed that quite successfully. IIRC Adobe Photoshop was an MFC app. There was no other API but Win32 API.

Re: Windows native app development is a mess

#90
post #12

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?

Speaking from personal experience, Godot has the sneakiest potential. It has all the UI components and flexible layout containers you could ask for, a signaling system that lets you put the methods from less relevant components in the scripts for more relevant ones (making for a more compact project), and you can also manually compile slim template builds for cleaner distribution. There's a future there.

What’s the story for accessibility and non-LTR text boxes?
Post reply on HN