3 ms·
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
by cosmic_cheese 2y ago
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.
- fifticon 2y agoI 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.
- pjmlp 2y agoEven 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.
- neonsunset 2y agoThe 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.
- cosmic_cheese 2y agoReally, 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.
- neonsunset 2y agoHonestly, 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.
- cosmic_cheese 2y agoSorry, 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).
- neonsunset 2y agoTo 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.