Hacker News Reader

Comment by skc | Hacker News Reader

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.

View on HN

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.

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.

What evolutions are you looking for that aren't covered in their .NET Core/.NET 5 plan?

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.

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.

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.

Agree. That's why we have this for Avalonia XAML debugging (XAML is compiled to IL) https://www.youtube.com/watch?v=9VtwwEL1SJM

A Windows UI framework that's modern and performant (so not WPF), at least somewhat competitive in flexibility and expressiveness and tooling with HTML/CSS (not WPF or UWP), and does not have a sandbox or mobile-style process lifecycle chained to its ankle (so not UWP).

I'd throw xplat in there, but I think I'm already asking for too much.

Windows UI platform team recently posted their roadmap for the platform https://github.com/microsoft/microsoft-ui-xaml/blob/master/d... and they have a GitHub issue thread requesting comment on the roadmap https://github.com/microsoft/microsoft-ui-xaml/issues/717 , you might want to take a look and post your thoughts

It's hard to trust their roadmaps. They always look good but get abandoned every few years.

From what I have seen, the WinUI story is a complete shitshow[1]. Apparently they realized that tying it directly to Windows releases was a bad idea, and want to packagize it into NuGet assemblies, but kind of can't. They appear to be trying to distance themselves from even calling it UWP anymore, which I suppose makes sense, because it was dead-on-arrival and never gained any momentum.

Windows 8 is still casting a long shadow of half-baked bad ideas.

[1] https://www.sharpgis.net/post/2019/05/14/The-future-UWP

Don't mean to be disrespectful, but that sounds an awful lot like the standard corporate non-reply of "Thank you for your feedback requesting the dead-obvious thing that everyone wants and that we know everyone wants but we are not doing for undisclosed internal reasons. Your feedback is interesting and novel and will be read and carefully considered if you will just put it right here into >/dev/null. Thanks for your time!"

You talked yourself out of trying.

Is it different if you send your comments to /dev/null or if they do? I think it is. In one scenario you at least gave it a try.

Because WPF is .NET based and internal Microsoft teams with C++ codebases (like Windows and Office) didn't want to take a dependency on .NET (or rather they tried with Longhorn and couldn't make it work).

That's a big issue but it doesn't explain why instead of developing WPF they released WinRT and UWP.

The purpose of WinRT was to avoid having to depend on .NET. Developing WPF to fix this would have meant rewriting the whole thing in C++, which is what Silverlight/WinUI sort of was, but I agree they dropped the ball on compatibility and migration

I think it was more a thing of those teams torpedoing Longhorn efforts than actually trying.

To be fair, UWP and WPF aren't that dissimilar (and both are XAML), with differences in the readymade UI elements and a stricter subset of the binding markup.

They are dissimilar enough to make a port of a large app very difficult.

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)

> 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.

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.

Reply on news.ycombinator.com