4 ms·
While some of his complaints now have solutions[1], when WPF (previously known as Avalon) is used with care, the resulting XAML is much more diff-able and code-
by MarkSweep 7y ago
While some of his complaints now have solutions[1], when WPF (previously known as Avalon) is used with care, the resulting XAML is much more diff-able and code-review-able. The CodeDOM serialization method is dense and small changes can cause huge code diffs.
On the other hand, WPF is a lot more complex than WinForms. There are a lot of different ways to use, many of which involve data binding that is not evaluated till runtime. There are ways to make some databinding type-checked at compile time, but it is not built in. WinForms data binding is pretty limited, so generally it is easier to track down what piece of code is causing something to display on the screen.
WinForms (and the Win32 resource scripts that can before it) are more limited in what they can easily express. So the resulting UIs tend to be a bit visually and behaviorly similar. This is nice for devs because you have a design already laid out for you. It's also nice for users since the apps are more consistent and predictable. WPF gives you a big blank canvas where it is hard to make something look decent. And enables making your app look completely different than anything else.
So in conclusion, I agree that WPF enables more understandable code to be created by people who care. Unfortunately it is often to used to add a bunch of needless complexity.
[1]: For example, the GenerateMember option in the WinForms design can be used to suppress generating fields for controls.
- tonyedgecombe 7y agoEvery couple of years I take another look at WPF but it always feels like wading through treacle for me. I'm so much more productive in WinForms. Perhaps if I dedicated a year to it I might come out the other side a productive WPF programmer but I have my doubts.
- zubspace 7y agoI'm in the same boat as you. The windows forms designer is such a joy to use. But as soon as you need to add special behavior to some controls it can get quite hairy. I've never encountered a complete roadblock, but we have a ton of code for windows forms controls which look more like workarounds or cheap hacks. But hey, it works. I also like the consistency of windows forms. This is awesome for administrative and business users, who just want to get their work done. There are no UI surprises. But your tool will look like an ugly duck, if it is used in an environment with shiny Web and WPF applications. For this reason alone, we had to make a split between forms and WPF applications. Windows Forms for administrative UI, WPF for end users. (By the way: I recommend outsourcing the design part to another company specialized in WPF design. Designing nice WPF UI is a black art.) There's also the fact that Microsoft calls forms legacy tech, but I'm not yet too concerned. I would be more concerned to rewrite all WPF application with the next shiny framework coming around...
- wayneftw 7y agoHave you ever tried any of the Metro styled WinForms component kits? https://www.google.com/search?hl=en&q=metro+styling+for+winforms https://www.google.com/search?hl=en&q=metro+styling+for+winf... Styling WinForms to look the way you want is certainly possible, but I would agree that it's even more of a black art than designing a WPF UI.
- non-entity 7y agoHoesntly the one thing that's always turned me off of WPF was how had styling was. iirc, doing minor style modifications on a simple Uai involved writing a boatload of markup and overriding stuff I didnt want to have to worry about