Thus better leave WinUI to the Windows team.

When it was announced at PDC, they only talked about WinJS and nothing else, the folks of .NET Rocks have a few shows where they mention they thought .NET was done, and they needed to refocus into something else.

The show where they interview Miguel de Icaza they go into this.

Second, win32 is designed with the ability to change all the default colors and you used to be able to do this by right clicking the desktop and selecting "properties". If dark mode doesn't follow this - just another symptom of Microsoft's siloing incompetence. The team that wrote dark mode may not have been aware that this feature existed because parts of the platform are so disconnected from other parts.

Plus the whole thing is meant to work on ancient Windows versions (like, Vista and WS2008 ancient), so that ultimately defines the minimal common UI denominator.

For years we loaded up libraries and abstractions to minimize boilerplate. These hid the actual underlying mechanisms and often made specific customisations harder to do since you were taken away from the raw functionality.

These days AI is extremely good at writing boilerplate and in my opinion explicitly typed out boilerplate code is much easier to reason about than a library that abstracts things away to a one line annotation or similar.

A good example is that i've recently been leaning back to the raw Android apis for things like recyclerviews etc. It used to be 10+ files to changed to create an efficient scrolling view on Android with various resources and adapters required. So a whole bunch of libraries came out to try to abstract the complexity away. You know what though? I don't care about that anymore. I'm going back to the raw GUI APIs where possible because it's so explicit and clear even if it's 10x more code.

If you want something more custom, subclass NSControl and you’re off to the races.

And if Obj-C isn’t your cup of tea, one can use Swift instead, even in a codebase that had been only Obj-C prior.

    Button(“Click Me”) { buttonWasClicked() }

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.

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)

Once I became experienced enough to have opinions about things like my editor and terminal emulator... suddenly the Visual Studio environment wasn't nearly as appealing. The Unix philosophy of things being just text than you can just edit in the editor you're already using made much more sense to me than digging through nested submenus to change configuration.

I certainly respect the unmatched Win32 backwards/forwards compatibility story. But as a developer in my younger years, particularly pre-WSL, I could get more modern tools that were less coupled to my OS or language choice, more money, and company culture that was more relevant to my in my 20s jumping into Ruby/Rails development than the Windows development ecosystem despite the things it does really well.

Or to say differently: it wasn't the stability of the API that made Windows development seem boring. It was the kind of companies that did it, the rest of the surrounding ecosystem of tools they did it with, and the way they paid for doing it. (But even when I was actually writing code full time some corners of the JS ecosystem seemed to lean too hard into the wild west mentality. Still do, I suspect, just now its Typescript in support of AI).

The biggest problems were DAO (database) and a few COM controls that were not available in x64.

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.

Stable, but many issues. Stay away if you value your sanity and do anything nontrivial.

It's a grave sin to have an app repo without a screenshot in the main README.md.

Note: Yes, I know that electrobun itself has videos on the README.md

Also, they stopped caring about Windows because they want recurring service revenue. Making Windows a subscription service for consumers would outrage the users (even though they kinda already do this for business with Microsoft 365). So the consumer market is just viewed as a billboard for M365 and Copilot. So everything you see there is just lowball effort, even worse than their normal quality.

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?

same expectation as always.

So many “let’s race-to-the-bottom along with the authority” comments on HN lately.

Dude: no! =]

> Native means system libraries only.

Every non-trivial application will eventually use third-party non-system libraries.

I think "Native app development" has at least two meanings:

1. narrow meaning: the program uses a native UI toolkit (Win32, Cocoa)

2. broad meaning: the program targets one or more specific platforms and the UI is not not just a webview

Even with the narrow meaning, WxWidgets would qualify as "native development" (because it uses native UI toolkits under the hood), yet it is still a third-party library.

Since when? To me, anything not webview-based is native, though you have varying degrees of integration into the platform.

I don't think the rapid development cycle argument holds water, when they're shipping a new WebView2 every month.

That’s why they had .NET 5im stead of .net core 5