Six years of Windows Presentation Foundation: What’s changed? (2012) | Hacker News Reader

Six years of Windows Presentation Foundation: What’s changed? (2012)

paulstovell.com

45 pointsnreece50 comments

Used WPF for a while many years ago (so I'm not up to date on the latest), but I was frustrated by so many oddities and gotchas innate to the system. There were some great demos that made me think I had a handle on how it worked, but then I immediately hit a wall trying to implement a real product. If it weren't for Stack Overflow, and all the people asking the same WPF WTF questions I had, I would have never had achieved any success.

Right on. WPF was a good idea but they gave up half ways. With better tooling and syntax cleanup it could be great. The way MS treated WPF also made me sceptical of anything new MS ships. There is a good chance they will abandon it soon.

Visual Studio's UI is almost all WPF-based, as are parts of Windows itself (such as Server Manager since WS2012) so if MS were to abandon WPF it would backfire badly unless they decide to kill-off VS and replace it with VSCode... now that's a scary thought.

Sure. But there is no innovation in WPF. They could simplify the binding syntax or integrate MVVM better for example. Look at what they did with Razor and MVC. Also visual studio is not exactly a showcase for WPF. 2008 (the last without WPF) had macros and the UI was easily customizable. It was also much faster. they are still far away from that functionality.

VS is probably the only reason that WPF is being touched at all.

Eventually, they'll say that VS is dead and VSCode is the new VS, then we'll be off WPF and win32 ties, it'll also put to bed the "Why is VS not 64bit yet?" line of inquiry.

VSCode isn't even remotely near VS. But WPF did get a lot of work once VS decided to use it. Up until then, WPF couldn't even render text without making it blurry - that's how little effort it had.

I'm guessing that with the Longhorn disaster WPF lost whatever resources it was going to get to make it really kick ass.

The WinRT/UWP XAML stack is the return/revenge of the Longhorn XAML stack. It took a while to get here, but it is the present now.

Yeah, but now you can use ReactXP for that, just like the Skype team does. And it runs on UWP, Android, IOS and Web.

ReactXP looks interesting, I will explore it some.

If your goal is to write .NET (C#, F#, VB.NET, what have you), ReactXP doesn't help. UWP XAML is the answer people seem to be looking for but for whatever reason keep missing it as the successor to WPF.

The problem with UWP is that there is no migration path from WPF. They are so different that you have to pretty much rewrite from scratch.

My experience is that there isn't as much to rewrite as most developers think. (But then I've had in the past to maintain Silverlight versions of WPF applications, so I'm biased.)

If you are already using patterns like MVVM, databinding, service models, and keeping business logic separated from UI/UX logic, the transition should be mostly seamless from what I've seen outside of a few XAML tweaks (which are primarily fiddly details like namespace changes).

In the case of more complicated migrations, you can now use the Desktop Bridge: https://docs.microsoft.com/en-us/windows/uwp/porting/desktop...

I tried to rewrite a WPF app when WinRT came up and it was hopeless. I'll admit I haven't looked at it again so maybe things have improved since then.

UWP is not the successor to WPF for a simple reason: it's sandboxed, and comes with a very prescriptive UX platform (no tree-view, hWnd, or FileOpenDialog here, folks!)

For line-of-business apps it's DOA because ADO.NET is not available. Custom widgets (e.g. for industrial control) are much harder to develop because there's no replacement for GDI. The list goes on. UWP is, and was intended to be, only a platform for "apps" which act as a frontend for externally hosted web-services - not "real software".

What we should be campaigning for is for the XAML "Jupiter" platform within UWP to be made fully available in the pure Win32 world, with no special runtime, sandbox, or artificial restrictions.

You seem to be under several misconceptions. Yes, it's sandboxed by default, but that isn't the problem you seem to think it is.

- It wasn't a good idea even in WPF to use an hWnd directly

- There is a full file browser available to UWP apps since Windows 10

- The application design guidelines are much less prescriptive since Windows 10

- There's nothing saying you can't use a tree view, just a warning that most users don't like tree views and tree views are typically not very accessible (to users with disabilities, to users that prefer touch controls, to users that hate navigating useless hierarchies)

- DirectX has been the suggested replacement for GDI since WPF launched, UWP just enforces it; UWP XAML even has more and better ways to composite DirectX and XAML layers together

- That stated, System.Drawing is higher level than just GDI, and is missing today. This is also an issue faced by .NET Core in general. There are open source System.Drawing replacements available today. .NET Core should have one more directly in .NET Standard 2.0/.NET Core 2.0 soon (and UWP once .NET Native pulls that in)

- The "desktop bridge" allows full Win32 processes to bundled with an application

- The full jungle of ADO.NET is an issue, but it's the same issue being faced across all of .NET Core: it's expected to get better with .NET Standard 2.0/.NET Core 2.0 soon and the .NET Native that pulls that in

- Even "real software" needs sandboxes for security and reliability. That was the complaint with UAC in Vista; that's the same complaint here. Exactly like with UAC the UWP sandbox started (back in the "WinRT days" in Windows 8) from a position of strength and is slowly working to strike a balance for "real software" to run but also be secure and easy to install/uninstall

From a lot of the .NET side of complaints, the "artificial restrictions" are primarily the transition to .NET Core. Yes, it's a sometimes painful transition for legacy WPF applications, but it's a lot better than the WPF/Silverlight transition and it's a transition that will continue to get better as .NET Core grows. A lot of the complaints about .NET Core in general are going to go away with .NET Standard 2.0/.NET Core 2.0, which will converge a lot more of the "classic .NET Framework" into/on top of .NET Core.

Seems the best approach is to wait and see how .NET Core 2 shapes up and also to wait until your company actually uses Windows 10. By that time MS will probably have come up with something new anyway :-)

Or use the Desktop Bridge today with your existing WPF app. Add UWP XAML screens and Windows 10 features as you see fit. As you find you are able to do more in UWP directly and grow more Windows 10 users, cut more functionality over to the UWP sections of your app.

With the latest updates of Win Forms (high DPI support, ehnacements), isn't it a viable option again? Especially if one wants to have native (Win32) controls.

WinForms has always been a viable option.

I love WPF and really miss building apps using it with the MVVM pattern. I've even tried to find open source WPF apps to contribute to, but there's very few of them around it seems; everyone wants to build web UIs.

Anyway, here's a product I've come across a few times which might address some of the authors' concerns (was a paid product, but it recently went free): http://www.ammyui.com/

I also came to appreciate MVVM through WPF and was sad to see it go. The thing is, MVVM has really flourished on the web - though under various other names. I'm working with VueJS right now, and it's my favorite iteration of MVVM so far, smoother and friendlier, more component oriented, and less dogmatic than what WPF had. New concepts have been added to the pattern as well, state management and data flow is something that the Microsoft stack has never really addressed, and it's a big win. Throw in Typescript and I'm pretty comfie, though I do miss being "closer to the metal."

Hey,

I didn't see a contact email on your profile but here are a couple projects that could use some help:

https://github.com/ArthurHub/HTML-Renderer (looking for contributors actually)

https://github.com/bricelam/ImageResizer

https://github.com/Tyrrrz/LightBulb

https://github.com/Mikescher/AlephNote

There are also frameworks/toolkits like ReactiveUI, MahApps, etc. that could also use some help, if you want to contribute there.

I'd add the MatDesign XAML toolkit, which is a powerhouse:

https://github.com/ButchersBoy/MaterialDesignInXamlToolkit

Thanks for the suggestions! I'll take a look at those.

>As I look back at WPF, I see a technology that had [...] a lack of investment.

>WPF on the other hand hasn't had a major change since 2006.

WPF (v1 not beta) was released November 2006. I'm sure that at that moment in time, Microsoft did have optimistic visions that WPF would be widely adopted like Winforms and VB6 Forms before. In 2006, WPF was prominent in MS's strategy. But by 2012, it' wasn't.

What changed Microsoft's direction? What did Microsoft not know in 2006? What they didn't know was that 2 months later, Steve Jobs would show the first iPhone. That changed everything.

Before the iPhone in 2007:

- Research In Motion and Google's Android (1st prototype) thought smartphones would be half-screen, half-buttons.

- "fat clients" with rich runtime plugins like Adobe Flash and MS Silverlight would be dominant

- there was no significant application development & distribution platform on mobile phones (yes, Nokia had a SDK, and Microsoft had something for Windows CE but neither gained any significant mindshare)

If we look at the macro trend, the ongoing investment in WPF assumed that desktop apps would be dominant in developer mindshare (either Silverlight or traditional desktop exe files). With the rise of iPhones/Android, it was HTML5 & Javscript that was aggressively enhancing their capabilities. The rising marketshare of Google's Chrome (2008) with the V8 Engine and Mozilla Firefox improving their Javascript performance also contributed to WPF's abandonment. For native apps on smartphones, developers en masse were more interested in Apple Objective-C or Android Java. HTML5+JS+ObjC+Java all gained mindshare at WPF's expense.

Microsoft didn't instantly declare WPF "dead" in 2007 but abandoned it in gradual steps. E.g. the conferences PDC2009, PDC2010 had prominent WPF presentations but the later Build conferences do not. It also didn't help that the first WPF release didn't have masked-edit controls, didn't have a datagrid, and didn't have a good UI designer (Expression Blend purchased separately?). VB6 in 1995 had masked-edit controls but WPF didn't?!? WPF was also very slow even though they touted the underlying DirectX technology. (E.g. Evernote abandoned WPF for C++ WTL.)

If you're a developer that wants to code a brand new WPF application today, that's ok but don't expect MS to release new exciting enhancements for it.

Today, innovation iteration on desktop GUI libraries are happening faster on Qt for C++ and React/Electron for Javascript.

I've only shipped one or two little things with WPF. I think the author makes plenty of good points. And some points which I'm not advanced enough to understand.

But I actually like writing XAML by hand.

The GUI-based GUI designers I've tried were never very good about expressing the subtleties and details that you have to deal with if you hope to make a professional-grade result.

GUIs that are good at specificity and detail also tend to be quirky and difficult (think CAD systems).

The fact that XAML is so closely tied to the actual structures you're creating means you learn the language and its domain together. And you can trivially re-use or re-purpose chunks of XAML by copying, pasting, editing.

> ...writing XAML by hand. > The GUI-based GUI designers I've tried were never very good about expressing the subtleties

I understand you like writing a UI by hand, and it's always good when a UI has a human-editable text form (if XML counts :))

But in general: it's 2017. The fact you're writing about the need to design a UI by text is extraordinary, and so, so far behind other tools.

I'm pretty sure that's what I'm doing on all my HTML/JS UIs...

I'm not so in touch with web UIs, but for the desktop or mobile writing by hand is antiquated, and has been for twenty years.

What is used to create desktop UIs?

There are a few products for React/HTML/JS that let you create web ui's via a gui interface, but they're not really all encompassing.

Delphi (RAD Studio), Lazarus, and Visual Studio all allow you to create desktop UIs using WYSIWYG designers.

That is why I'm reverting back to WinForms until something better comes along. No proper data binding support but I can live with that.

I'm just hoping that Microsoft, or somebody else, will create a cross-platform GUI toolkit.

> I'm just hoping that Microsoft, or somebody else, will create a cross-platform GUI toolkit.

The good news is that it exists. The bad news is that it's HTML/Javascript.

> I'm just hoping that Microsoft, or somebody else, will create a cross-platform GUI toolkit

There is FireMonkey. Windows, iOS, Android and macOS. Native controls on Windows and iOS, and on the roadmap for the others. Themeable, vectorized, GPU-powered, data bindings, and can be used from C++ via C++Builder, or Delphi if you want a more C#-like language.

Here's a random video about the live preview (where you plug in a device and see live as you edit the UI in the IDE what it will look like on that device): https://www.youtube.com/watch?v=bU_J3WxeClI Plenty of other videos online too!

(Note: I am not neutral, I am employed by the company that makes it.)

Eto.Forms is nice for this. It targets WPF, Xamarin.Mac, and GTK, so you get Windows, macOS, and Linux support with a single codebase.

I just started learning WPF by rebuilding an old WinForms project and have been overwhelmed with the all of the "half-baked" and outdated information as the author mentions.

I've been trying to implement MVVM using a 2009 MSDN Magazine article "Patterns - WPF Apps With The Model-View-ViewModel Design Pattern" [1] as a guide.

Are there any decent MVVM frameworks or patterns that are worth investigating?

[1]: https://msdn.microsoft.com/en-us/magazine/dd419663.aspx

Personally, I've grown very fond of ReactiveUI (https://github.com/reactiveui/ReactiveUI) over the time I've been using it. While the learning curve upfront is rather steep, I think it's absolutely worth it.

I've heard good things about Reactive but haven't invested the time in learning it. I have been using Caliburn for MVVM as it simplifies a lot of WPF oddities.

I'm using MVVM Light on a current project. I haven't used any other MVVM tools so I can't tell you how it compares.

http://www.mvvmlight.net/

it seems like for years MS was looking for the WPF killer that would unify web and desktop programming (silverlight for example and later JS+Html based apps). That didn't work well, and WPF was left rudderless. Many devs (including myself) have resorted to WPF because it's still the best solution. The stagnation of WPF is a real issue that I hope gets addressed soon. Of course, maybe MS is working on .net core replacement :)

Chances are low, the graphics library has problems to be cross platform.

The work on wpf was 'finished'. It's not abandoned, but there is no innovation in it anymore. They will keep supporting it, but are looking for a way to do it crossplatform, which isn't an option yet

Think of how much credit MS would get for making a cross-platform GUI toolkit. End the era of Electron apps without people having to use Qt.

This is why people use Delphi and C++Builder.

There is a need for GUIs on Linux IOT devices running on ARM.

I would love to be able to use Delphi/Firemonkey for that.

There's this, that I just found today:

http://www.fmxlinux.com/

It certainly looks interesting.

Just in case, "WPF vs Sciter": https://sciter.com/sciter/sciter-vs-wpf/

Essentially Sciter is a crossplatform WPF but using HTML/CSS instead of XAML.

As for me (I am an author of Sciter) the biggest disappointment was the way how styles were implemented in WPF/XAML. Even in 2006 it was clear that style cascading (contextual inheritance) is the way to go. It appears as XAML was not designed from the very beginning to be human readable - just trendy ("XML everywhere" in 2006) replacement of VB's .FRM files. .FRM files were even more human readable/editable ( notation was quite close to YAML).

Microsoft built the .NET Core replacement. It's a key part of the Universal Windows Platform: the powerful combination of .NET Native (built on top of .NET Core) and the UWP (nee WinRT) XAML stack.

The UWP XAML stack has been the successor to WPF for a while now.

UWP XAML is fine for targeting Windows 10, but if you consider cross platform to at least include Windows 7 and 8 also, it is a non-starter.

"WinRT" XAML runs great on Windows 8+ and is mostly forward compatible with UWP XAML (especially 8.1+ universal XAML). (Though statistically "everybody" that was on 8 is now on 10. It's 7 that will be the next XP.)

Windows 7 is the outlier, but this isn't that much of a different argument from the complaints that Windows XP had terrible out-of-the-box support for WPF. The same arguments stopping people from using UWP today seem very deja vu to the arguments against WPF even back when in Windows 7.

UWP XAML isn't even that different from WPF XAML. I've got a feeling for some LOB applications maintaining a UWP and WPF build side-by-side is relatively straightforward (and definitely more straightforward than those of us that for various reasons worked on side-by-side XAML builds for WPF and Silverlight).

Risk system in WPF? Come on. These things do need some UI but calling the UI "the" risk system is a stretch.

Anyway WPF is workable - far from perfect, but you can actually get the stuff done with it. It is also quite flexible and performant if done right.

I think the author is talking about a finance line-of-business application that deals with risk, not the technology itself.

Reply on news.ycombinator.com