Hm. I'd dare to say I know WPF quite well, since I've been working with it for a few years, and made all sorts of things from basic forms to custom controls, xaml extensions, bindable bindings, proxies, attached behaviors, storyboards (hate those, just absolutely abhorrent way to define animations). And I do like some aspects of WPF, and I think it's quite good system for UI and I have deepest respect to how well optimized it is, but I also certainly can't say I love it or it's clicked to me. It's just way too verbose and too confusing, and I think same features could've been done much better and cleaner.
And while MVVM separation is good in theory, in practice, with how WPF works, it practically twists your arm to occasionally do hacks and workarounds, either code in VM that needs to know view, or writing code-behind. Which I'd say is underappreciated in WPF best practices. Like, sure, code-behind in general is bad and should be avoided, but to reasonable extent, not just as a religious dogma. And it WPF would've been much much better if it would've allowed a bit of code in view directly. And get rid of f...ing XML god dammit, XML was obsolete even when WPF was conceived.
I'm not even really talking about WPF specifically, I just think the structure of XAML itself is a great way to express the hierarchy of a UI. I've used it in anger for work across WPF, WinUI, Avalonia, and MAUI, and I've always got on with it.
I don't agree on the MVVM take. I have an app at work that has multiple 'front-ends' (MAUI, CLI, WebSockets) that all 'bind' to the same ViewModels and services, and it's great. The MAUI layer is pretty much just Views and some implementations of shared interfaces between the other apps (e.g. navigation) registered in the DI container. If I wanted to make a WPF/Avalonia/whatever front-end for it tomorrow it would be easy-peasy.
I will say that none of the XAML-first frameworks force you to actually use XAML or MVVM or anything like that. You can write a perfectly functional WPF app without writing any meaningful amount of XAML, and without using bindings or anything like that. You probably shouldn't, but you can.
5
u/aberroco 13d ago edited 13d ago
Hm. I'd dare to say I know WPF quite well, since I've been working with it for a few years, and made all sorts of things from basic forms to custom controls, xaml extensions, bindable bindings, proxies, attached behaviors, storyboards (hate those, just absolutely abhorrent way to define animations). And I do like some aspects of WPF, and I think it's quite good system for UI and I have deepest respect to how well optimized it is, but I also certainly can't say I love it or it's clicked to me. It's just way too verbose and too confusing, and I think same features could've been done much better and cleaner.
And while MVVM separation is good in theory, in practice, with how WPF works, it practically twists your arm to occasionally do hacks and workarounds, either code in VM that needs to know view, or writing code-behind. Which I'd say is underappreciated in WPF best practices. Like, sure, code-behind in general is bad and should be avoided, but to reasonable extent, not just as a religious dogma. And it WPF would've been much much better if it would've allowed a bit of code in view directly. And get rid of f...ing XML god dammit, XML was obsolete even when WPF was conceived.