12 ms·

When I had the chance to use it seriously many years ago, what I found about WPF is that once you got the hang of it, you could literally look at any sufficient

by skc 7y ago

When I had the chance to use it seriously many years ago, what I found about WPF is that once you got the hang of it, you could literally look at any sufficiently complex application UI and know immediately how to build it using WPF in record time. It's that composable.

klodolph 7y ago
Agreed. People are complaining about it in this thread, but I thought it was almost on par with Cocoa, overall. Just like Cocoa, you have to "drink the Kool-aid" a bit and decide to structure your application to match the framework rather than adapt the framework to match your preconceived notion of how your application should be structured. Once you did, You could get a lot of work done. Personally think that these frameworks, like WPF and Cocoa, are still easier than working with Angular/React/Vue, but TBH that might be a reflection of my weaknesses with web development more than anything else. XAML is a bit of a mess but compares favorably to HTML+CSS, and XAML is almost as good as Interface Builder in my mind. The MVVM approach in WPF could be improved but it makes sense.
- sdegutis 7y ago
  After using Cocoa for about 10 years and React for maybe 1-2 years, I'd say that React is way easier for visual customization and hierarchy. Cocoa's hierarchy is more efficient but at a cost of being more verbose and tedious. But Cocoa was never meant to be very easy to visually customize, since part of the Apple Way ™ is that everything looks and works the same, which was probably a reaction to the over-customization of the 90s and early 2000s, but tends to go against the grain in modern UI where every application has its own branded UI that basically requires the composeability and simplicity of HTML + CSS. Edit: also, nobody wants or uses native desktop apps anymore, so that's a big plus for React (either via Electron or just plain web app)
  - pjmlp 7y ago
    > nobody wants or uses native desktop apps anymore, so that's a big plus for React (either via Electron or just plain web app) The customers I served during the last four years beg otherwise. Like them there are plenty of European companies willing to pay for native desktop apps. And I mean green field development, not maintenance. Not everyone has business cases that can stuff into Web or mobile phones.
- maxxxxx 7y ago
  I still don’t understand why instead of evolving WPF MS keeps cranking out similar but incompatible XAML frameworks like Silverlight, WinRT and UWP. If they had stuck to WPF and made the syntax less verbose and easier to understand and fixed some other warts WPF would be a kick ass development tool.
  - acct1771 7y ago
    What evolutions are you looking for that aren't covered in their .NET Core/.NET 5 plan?
    - maxxxxx 7y ago
      Debugging data binding is hard. There could be a tighter coupling and type safety between view model and view. MVVM could be better integrated. The syntax generally could be simplified (MVC did this when they introduced Razor). There is a lot of room for improvement. The foundation is very good but very hard to learn and you need a ton of obscure little tricks. The .NET 5 doesn’t address any of these. They do a lot of good stuff for server side development but the story for desktop development is bad.
      - JamesBarney 7y ago
        I mentioned this elsewhere in the thread but you can get compile time warnings and autocomplete on data binding by adding a design time view model.
        maxxxxx 7y ago
        To some degree yes but it really doesn't work well for complex cases. During runtime they spit out data binding warnings too but these are hard to trap. at least I haven't been able to figure it out.
      - wiso 7y ago
        Agree. That's why we have this for Avalonia XAML debugging (XAML is compiled to IL) https://www.youtube.com/watch?v=9VtwwEL1SJM https://www.youtube.com/watch?v=9VtwwEL1SJM
- polygotdomain 7y ago
  WPF definitely requires "drinking the Kool-aid". For WinForms Devs, it might be tough to swallow, but it's good medicine. The state of WinForms development before was not sustainable and incredibly challenging with large applications. Having tried to develop a WPF app like a WinForms app, it is incredibly tedious because it's not what WPF was designed to do. Drinking the Kool-aid and working within the confines of how WPF was designed to work makes a lot of things significantly easier, but the trade off is having to explicitly set up view models, use data binding, and find alternatives to doing everything in code behind. IMHO, the biggest challenge was dealing with the databinding ecosystem, which is incredibly powerful, but also complex, opaque, verbose, and tedious. There is practically no debugging of databinding, which is incredibly frustrating. It's hard to figure out why it doesn't work or why you don't get what you expect to get in whatever is actually being called. Whether it was old winforms databinding or various js databinding approaches on the front end, its always been fairly straight forward to get what I needed. WPF always seems like it's jumping through hoops for things that should just work. I'm sure there's a lot of logic behind how WPF's databinding actually works for it to be able to support all the various situations that it does, but, for me, it's never been very clear, and I've wasted countless hours trying to find and debug the right databinding syntax only to have it still not work and have to resort to a less elegant/hacky way of achieving the result that I'm looking for.

by skc 7y ago

klodolph 7y ago

Agreed. People are complaining about it in this thread, but I thought it was almost on par with Cocoa, overall. Just like Cocoa, you have to "drink the Kool-aid" a bit and decide to structure your application to match the framework rather than adapt the framework to match your preconceived notion of how your application should be structured. Once you did, You could get a lot of work done. Personally think that these frameworks, like WPF and Cocoa, are still easier than working with Angular/React/Vue, but TBH that might be a reflection of my weaknesses with web development more than anything else. XAML is a bit of a mess but compares favorably to HTML+CSS, and XAML is almost as good as Interface Builder in my mind. The MVVM approach in WPF could be improved but it makes sense.

sdegutis 7y ago
After using Cocoa for about 10 years and React for maybe 1-2 years, I'd say that React is way easier for visual customization and hierarchy. Cocoa's hierarchy is more efficient but at a cost of being more verbose and tedious. But Cocoa was never meant to be very easy to visually customize, since part of the Apple Way ™ is that everything looks and works the same, which was probably a reaction to the over-customization of the 90s and early 2000s, but tends to go against the grain in modern UI where every application has its own branded UI that basically requires the composeability and simplicity of HTML + CSS. Edit: also, nobody wants or uses native desktop apps anymore, so that's a big plus for React (either via Electron or just plain web app)
- pjmlp 7y ago
  > nobody wants or uses native desktop apps anymore, so that's a big plus for React (either via Electron or just plain web app) The customers I served during the last four years beg otherwise. Like them there are plenty of European companies willing to pay for native desktop apps. And I mean green field development, not maintenance. Not everyone has business cases that can stuff into Web or mobile phones.
maxxxxx 7y ago
I still don’t understand why instead of evolving WPF MS keeps cranking out similar but incompatible XAML frameworks like Silverlight, WinRT and UWP. If they had stuck to WPF and made the syntax less verbose and easier to understand and fixed some other warts WPF would be a kick ass development tool.
- acct1771 7y ago
  What evolutions are you looking for that aren't covered in their .NET Core/.NET 5 plan?
  - maxxxxx 7y ago
    Debugging data binding is hard. There could be a tighter coupling and type safety between view model and view. MVVM could be better integrated. The syntax generally could be simplified (MVC did this when they introduced Razor). There is a lot of room for improvement. The foundation is very good but very hard to learn and you need a ton of obscure little tricks. The .NET 5 doesn’t address any of these. They do a lot of good stuff for server side development but the story for desktop development is bad.
    - JamesBarney 7y ago
      I mentioned this elsewhere in the thread but you can get compile time warnings and autocomplete on data binding by adding a design time view model.
      - maxxxxx 7y ago
        To some degree yes but it really doesn't work well for complex cases. During runtime they spit out data binding warnings too but these are hard to trap. at least I haven't been able to figure it out.
    - wiso 7y ago
      Agree. That's why we have this for Avalonia XAML debugging (XAML is compiled to IL) https://www.youtube.com/watch?v=9VtwwEL1SJM https://www.youtube.com/watch?v=9VtwwEL1SJM
polygotdomain 7y ago
WPF definitely requires "drinking the Kool-aid". For WinForms Devs, it might be tough to swallow, but it's good medicine. The state of WinForms development before was not sustainable and incredibly challenging with large applications. Having tried to develop a WPF app like a WinForms app, it is incredibly tedious because it's not what WPF was designed to do. Drinking the Kool-aid and working within the confines of how WPF was designed to work makes a lot of things significantly easier, but the trade off is having to explicitly set up view models, use data binding, and find alternatives to doing everything in code behind. IMHO, the biggest challenge was dealing with the databinding ecosystem, which is incredibly powerful, but also complex, opaque, verbose, and tedious. There is practically no debugging of databinding, which is incredibly frustrating. It's hard to figure out why it doesn't work or why you don't get what you expect to get in whatever is actually being called. Whether it was old winforms databinding or various js databinding approaches on the front end, its always been fairly straight forward to get what I needed. WPF always seems like it's jumping through hoops for things that should just work. I'm sure there's a lot of logic behind how WPF's databinding actually works for it to be able to support all the various situations that it does, but, for me, it's never been very clear, and I've wasted countless hours trying to find and debug the right databinding syntax only to have it still not work and have to resort to a less elegant/hacky way of achieving the result that I'm looking for.