6 ms·

Compared to winforms, WPF has an incredibly steep learning curve. Working with it was always painful to me. The vector graphics architecture they mention makes

Compared to winforms, WPF has an incredibly steep learning curve. Working with it was always painful to me. The vector graphics architecture they mention makes it even harder. While it's rich capabilities enable you to implement everything you can dream of, doesn't the same hold for JS desktop apps? (+ they are cross platform) I don't see the use case anymore...

thrower123 7y ago
I've always thought that I ought to have learned WPF, but the reality is I don't work on significant desktop software, so when I need to build a little desktop UI, it's a quick and dirty internal tool, or at best a configuration dialog. WinForms is incredibly easy to bang out that kind of use case so it just never made any sense to put the investment in. Maybe if Silverlight hadn't been such a deadend.
alkonaut 7y ago
Modern js frameworks makes mvvm/similar quite pleasant. Some of the binding in WPF is quite complex, especially since you don't get proper type safety for all that effort (there is a lot of stringly typed things sticking out). On the other hand, the layout model of WPF is a lot easier than mastering html+css. JS desktop apps still mostly don't work without embedding a browser like electron and that ranges from annoying (e.g. for size/memory reasons) to impossible (for things like a plugin where you have a constrained environment, need to launch instantly etc). The middle ground is desktop js using system browsers, but it's pretty painful to do too.
- m_fayer 7y ago
  WPF never quite made the leap from data-binding and MVVM to a component-based + state-management architecture like React&friends. A consequence of that is a hairy overcomplicated mess of a binding system that's full of footguns. But it was still ahead of its time - that one last step would have made it amazing.
  - maxxxxx 7y ago
    They could easily have done this but instead chose to make several new frameworks that didn’t improve anything. Very sad. Now MS has several mediocre not well maintained frameworks instead of a really good one. The constant churn also killed off a lot of open source efforts
    - DoofusOfDeath 7y ago
      This isn't my area of expertise. What are some of the other MS frameworks or OSS projects you refer to?
      - maxxxxx 7y ago
        WPF started XAML, then came Silverlight, WinRT and UWP. They are superficially similar but under the hood the code is quite different and each has its own set of weird limitations so you can't just reuse code. Also, in the case of WinRT and I think also UWP the new framework had less features than its predecessor so in a sense it was worse and less powerful which is not a good way to convince people to port their code. When WPF came out there were quite a few very cool open source projects that built on top of it because it's really easy to extend WPF and build components for it. But then every two or three years MS announced a new framework so most of these efforts died out. When you look at commercial third party suppliers like Developer Express they have the same component in three or four flavors. this must be a huge and expensive effort to maintain.
        contextfree 7y ago
        "WinRT and UWP" in this context are just two names for the same thing, though
        maxxxxx 7y ago
        Sort of. They were released some years from each other. WinRT was super weak and never took off and then suddenly UWP came up.
- JamesBarney 7y ago
  > Some of the binding in WPF is quite complex, especially since you don't get proper type safety for all that effort (there is a lot of stringly typed things sticking out). You can add a design time view model to get compile time warnings(and autocomplete) about incorrect bindings.
- joelfolksy 7y ago
  > On the other hand, the layout model of WPF is a lot easier than mastering html+css Thank you. I've never been able to figure out if web layout is as terrible as it seems, or if I'm just missing something. Once you spend the 20 minutes to learn the WPF layout algorithm, you can reason about why every element is located where it is, down to the pixel. To get there with HTML/CSS, I feel like I would have to memorize and recall a huge list of ad-hoc rules, and their combinatorial interactions. Usually I just give up and accept the mysterious 3-pixel gaps that seem to crop up randomly, and I don't even attempt complex layouts.
mgoetzke 7y ago
We developed a number of applications on it, but found it to be very verbose, quite brittle and needlessly complex. It is brittle because XAML itself is a compiled language without the ability to step through or debug well, which means runtime errors in the object tree usually causes the entire app to crash with very abstract error messages. it is complex because the language is supposed to be an object tree building mechanism and thus needs to be quite generic. It is verbose because of the underlying abstracted data model. e.g dependency properties etc. Compared to HTML, where the 'evolutionary' pressure to create a workable compromise is much higher. I used to think XAML could be better if architected well, but the missing ecosystem and usage around it made it so, that HTML was and still is massively more productive.
- maxxxxx 7y ago
  The sad thing is that XAML could be great if they just had put a little more work into it.
- osd 7y ago
  > which means runtime errors in the object tree usually causes the entire app to crash with very abstract error messages. This is absolutely untrue. Xaml errors can be caught like any other error, and most errors get swallowed rather than crash the application (which can cause some debugging headaches when things aren't rendering as you expect). > I used to think XAML could be better if architected well, but the missing ecosystem and usage around it made it so, that HTML was and still is massively more productive. I don't think html is massively more productive. I'm not even saying that WPF is so much better, but start debugging any reasonably large react application and you're just as likely to get into an unproductive quagmire.
glonq 7y ago
Agreed. I actually "retired" from programming when WPF was released and got into management. Framework fatigue was definitely a factor in my decision -- having to toss out a bunch of knowledge and then learn something new that provides marginal benefits.

thrower123 7y ago

I've always thought that I ought to have learned WPF, but the reality is I don't work on significant desktop software, so when I need to build a little desktop UI, it's a quick and dirty internal tool, or at best a configuration dialog. WinForms is incredibly easy to bang out that kind of use case so it just never made any sense to put the investment in. Maybe if Silverlight hadn't been such a deadend.

alkonaut 7y ago

Modern js frameworks makes mvvm/similar quite pleasant. Some of the binding in WPF is quite complex, especially since you don't get proper type safety for all that effort (there is a lot of stringly typed things sticking out). On the other hand, the layout model of WPF is a lot easier than mastering html+css. JS desktop apps still mostly don't work without embedding a browser like electron and that ranges from annoying (e.g. for size/memory reasons) to impossible (for things like a plugin where you have a constrained environment, need to launch instantly etc). The middle ground is desktop js using system browsers, but it's pretty painful to do too.

m_fayer 7y ago
WPF never quite made the leap from data-binding and MVVM to a component-based + state-management architecture like React&friends. A consequence of that is a hairy overcomplicated mess of a binding system that's full of footguns. But it was still ahead of its time - that one last step would have made it amazing.
- maxxxxx 7y ago
  They could easily have done this but instead chose to make several new frameworks that didn’t improve anything. Very sad. Now MS has several mediocre not well maintained frameworks instead of a really good one. The constant churn also killed off a lot of open source efforts
  - DoofusOfDeath 7y ago
    This isn't my area of expertise. What are some of the other MS frameworks or OSS projects you refer to?
    - maxxxxx 7y ago
      WPF started XAML, then came Silverlight, WinRT and UWP. They are superficially similar but under the hood the code is quite different and each has its own set of weird limitations so you can't just reuse code. Also, in the case of WinRT and I think also UWP the new framework had less features than its predecessor so in a sense it was worse and less powerful which is not a good way to convince people to port their code. When WPF came out there were quite a few very cool open source projects that built on top of it because it's really easy to extend WPF and build components for it. But then every two or three years MS announced a new framework so most of these efforts died out. When you look at commercial third party suppliers like Developer Express they have the same component in three or four flavors. this must be a huge and expensive effort to maintain.
      - contextfree 7y ago
        "WinRT and UWP" in this context are just two names for the same thing, though
        maxxxxx 7y ago
        Sort of. They were released some years from each other. WinRT was super weak and never took off and then suddenly UWP came up.
JamesBarney 7y ago
> Some of the binding in WPF is quite complex, especially since you don't get proper type safety for all that effort (there is a lot of stringly typed things sticking out). You can add a design time view model to get compile time warnings(and autocomplete) about incorrect bindings.
joelfolksy 7y ago
> On the other hand, the layout model of WPF is a lot easier than mastering html+css Thank you. I've never been able to figure out if web layout is as terrible as it seems, or if I'm just missing something. Once you spend the 20 minutes to learn the WPF layout algorithm, you can reason about why every element is located where it is, down to the pixel. To get there with HTML/CSS, I feel like I would have to memorize and recall a huge list of ad-hoc rules, and their combinatorial interactions. Usually I just give up and accept the mysterious 3-pixel gaps that seem to crop up randomly, and I don't even attempt complex layouts.

mgoetzke 7y ago

We developed a number of applications on it, but found it to be very verbose, quite brittle and needlessly complex. It is brittle because XAML itself is a compiled language without the ability to step through or debug well, which means runtime errors in the object tree usually causes the entire app to crash with very abstract error messages. it is complex because the language is supposed to be an object tree building mechanism and thus needs to be quite generic. It is verbose because of the underlying abstracted data model. e.g dependency properties etc. Compared to HTML, where the 'evolutionary' pressure to create a workable compromise is much higher. I used to think XAML could be better if architected well, but the missing ecosystem and usage around it made it so, that HTML was and still is massively more productive.

maxxxxx 7y ago
The sad thing is that XAML could be great if they just had put a little more work into it.
osd 7y ago
> which means runtime errors in the object tree usually causes the entire app to crash with very abstract error messages. This is absolutely untrue. Xaml errors can be caught like any other error, and most errors get swallowed rather than crash the application (which can cause some debugging headaches when things aren't rendering as you expect). > I used to think XAML could be better if architected well, but the missing ecosystem and usage around it made it so, that HTML was and still is massively more productive. I don't think html is massively more productive. I'm not even saying that WPF is so much better, but start debugging any reasonably large react application and you're just as likely to get into an unproductive quagmire.

glonq 7y ago

Agreed. I actually "retired" from programming when WPF was released and got into management. Framework fatigue was definitely a factor in my decision -- having to toss out a bunch of knowledge and then learn something new that provides marginal benefits.