They’re making poor choices because there was a major shift to incompetence. Using web technologies on the desktop when we as engineers know it was birthed as a whack-a-mole hack job that continues today as a accumulation of human-centric decisions not computing (engineered) 1s.

Applications really don’t need such flexibility to look (ie. dom), they need to function and cohabitate to be resourceful, which clearly they’re not.

And that’s not to say engineers haven’t tried to fix those mistakes but the catalyst was already set.

Design should have never taken precedence over compute, just as much as interpreted/runtime over compiled. They need to be balanced if not swayed back.

We still have the capability to learn the machine and shift the narrative as long as we’re willing to lose the brand for the generic. That’s the biggest obstacle because we sell out to the language, the architecture, etc. by the marketing of efficiencies in time to create rather than compute and each iteration of that deteriorates the experience and the art.

Anything that WinRT touches, after the Project Reunion was announced back in 2020, has been a mess, and they keep pushing it.

Unfortunately some of the newer APIs, like Windows ML, are only available in WinRT components.

Again, this was a hack. They should really be looking at fixing the issues with the startup time and slow performance of explorer, because even on vastly lesser machines, we've had near-to-instant startup times with, effectively, the same application.

This only goes to show how poorly staffed, like in developer skills, the whole Windows team is nowadays.

Just watch the WinUI community calls and the related discussion on the Github projects (WinUI, WinAppSDK, CsWinRT, C+++/WinRT).

In what regards Windows development experience, we really miss the Steve Balmer era.

[1]: https://www.gpsoft.com.au