Hacker News Reader

Comment by jimbob45 | Hacker News Reader

Why do you feel WinRT/UWP (and probably MAUI) were such failures?

It starts by Microsoft not following the "Developers, Developers, Developers" meme they became famous for.

While, from my point of view, UWP is what .NET 1.0 should have been (see [0]), the way it was introduced, requiring a complete rewrite from Win32/.NET applications, with limited capabilities, already required some adoption love.

Then while trying to achieve feature parity with Win32/.NET, this was done at the expense of breaking compatibilty across WinRT generations (8 => 8.1. => 10 => WinAppSDK), and if that wasn't enough, also breaking the .NET and C++ tooling experience in the process.

I think it was a mix of issues, management naturally, lack of empathy for the Windows developer community, whatever internal KPIs they had/have to meet, and most likely also quite relevant, it appears new employees don't have much experience with Windows development or its culture, were raised in a world without Windows.

People like myself have been PC users since the early days of MS-DOS 3.3, naturally new employees now have other backgrounds.

[0] - https://arstechnica.com/features/2012/10/windows-8-and-winrt...

basically MS has dropped the ball on UI since the time of WPF (I maintain apps stuck in WPF at work). It looks like the crayon electron browser kids are running the ship now adays :-/

I find WPF incredibly unsexy; unfortunately everything they have tried afterwards is even more amateurish. As others have mentioned, they have probably doomed themselves to eternal KPI hell, so with zero management vision, zero management talent, zero management strategy and zero management commitment, they are incapable of delivering anything to rise above Q3 mediocrity (Ie, they cannot deliver on any meaningful multiyear strategy, because they all have their heads up Q4 asses). They are the Intel of UI, at this point.

Not the OP, but as a primarily-Apple-ecosystem dev who had interest in building native Windows apps, the main issue was WinUI missing important desktop widgets (no datagrid, really?) and for the widgets that did exist, it wasn’t unusual to find missing functionality and rough edges. Perhaps most discouragingly there was often no happy path for mimicking patterns seen in first-party Fluent apps.

Figuring out how to piece it all together was a nightmare, too with searches turning up documentation and blog posts for N similar but different C# UI frameworks, which compounded with my unfamiliarity with C# and where its stdlib ends and the UI framework begins. It’s all very confusing for someone coming from other platforms.

It was very frustrating. Even Android with its notoriously bad and idiosyncratic Android Framework was less of a hurdle to pick up and start using.

Even if I tend to bash Google for how the whole Sun thing went down, or how they kind of mishandle Java support, one thing to really appreciate is how despite all the killed projects they are known for, they managed to have a business unit that firmly believed in an OS with managed userspace and pushed it at all costs.

What Longhorn could have been if the .NET and Windows Development teams actually worked together and not against each other.

I wholeheartedly agree. For decades, MS management have treated UI dev strategy as an 'almost forgot' afterthought, and the result means halfassed and soon-orphaned attempts at quickly 'reinventing everythimg' every few years, with too little care and effort. Devs then skip these, having been burned. I still recall the mess of silverlight - ui framework designed and guided by clueless managers.

The common advice nowadays is to not use WinUI directly in .NET land.

Instead, it is usually recommended to use AvaloniaUI or MAUI (which, as I've heard, has improved). There is a variety of SwiftUI-style declarative GUI packages and built-in APIs to absolve you from ever touching XAML if that's your preference.

Really, I don’t need anything trendy like declarative UI, though that can be nice for simpler use cases. Just plain old boring pure-code imperative is perfectly fine, maybe even preferred because it’s been proven to be able to handle complication and nuance more easily than declarative frameworks tend to and is more conducive to VCS than machine-generated XML is.

Honestly, at this point, I'm so done with "blame the tool for failing to look for solutions or fighting with the way it was designed to be used". Because everything is literally there and is a matter of reading documentation and picking a package/framework which suits your needs. It's not perfect but desktop GUIs are more or less a solved problem in .NET. I will stop trying to help because it's clearly not working.

Sorry, didn’t mean to come off as unappreciative. Will definitely keep your advice in mind, I just get a little exasperated with trend-chasing typically getting prioritized over shoring up inadequacies in the UI framework space (even outside of the Microsoft sphere).

To be fair your comment is fairly benign and I shouldn't have overreacted, sorry. Seen one too many of replies sharing this sentiment lately. "Poor performance, runtime errors, lack of support for X or Y (when there is one), etc." - the platform makes it difficult to run into many of these problems. And yet whenever something goes wrong, I find it interesting how teams using other languages seem to blame languages/platforms they use much more rarely.

Reply on news.ycombinator.com