Note trans .: is a translation of the article Six years of WPF; what's changed? written on August 3, 2012. Now WPF is not six, but seven years old, but nothing has changed.

Before joining Octopus Deploy full time, I spent a year writing a risk assessment system for traders at an investment bank at WPF. Before that I worked as a consultant, mostly focusing on WPF. For the past six years I have lived and breathed technology, and in this post I want to share some thoughts about the past and future of WPF and XAML.

Six years ago, I wrote an article about validation in WPF on the Code Project. I also wrote my error provider, which supports IDataErrorInfobecause - you won’t believe it! - WPF 3.0 did not support IDataErrorInfo. Later I worked on several open source WPF projects like Bindable LINQ ( initial reactive programming for WPF, even before the invention of Rx) and Magellan (MVC for WPF a la ASP.NET). I even spent some time in a club dedicated to extolling MVVM and throwing links to the Code Project, known as WPF Disciples (WPF Adherents).

When I look back at WPF, I see technology with an excellent foundation that has been spoiled by poor implementation and, more importantly, a lack of financial investment. I am glad that for me it is in the past.

Here's how back in 2006, the layout of a relatively simple window looked like (the code was taken from a project that I was working on then):

Just look at all the ceremonies! x: Class! XML Namespaces! Why not declare it all in one place, why not include standard namespaces implicitly?

Fortunately, now is 2013, and WPF has come a long way. This is how the code will look today:

See the difference? I don’t see either. Yes, over the past seven years, nobody raised a finger to get rid of code redundancy.

Let's take a look at the code for the ASP.NET page of 2006 (also from the project of those years):

	<%@ Page Language="C#" MasterPageFile="~/TrialBalance.Master" AutoEventWireup="true" EnableViewState="false" CodeBehind="Builds.aspx.cs" Inherits="PaulStovell.TrialBalance.MainWebsite.Builds" Title="Downloads - TrialBalance" %>
	
Download

What does this markup look like today?

	@model BuildsViewModel	
	@section Main {
	  
Download
	}

Initially, I became a WPF developer because I didn't like ASP.NET Web Forms and models like View State. But now, when I look back at the path that ASP.NET has done, I see huge changes. From the Web Forms model to the MVC model, from the ASPX syntax to Razor, ASP.NET really did innovations in the camp.

Here is a partial list of what has been done in ASP.NET and not done in WPF:

1. A new, human-friendly markup language (Razor) has been created. When you write on Razor, you have fun . Writing XAML was never fun. Moreover, before the "Namespace Import" appeared in ReSharper, it was a real nightmare.
2. Design patterns selected . And do not say that WPF has MVVM - yes, WPF supports bindings, but there is not a single feature in the WPF kernel that helps with MVVM in any way. It's all stuck to the side through Blend Behaviors and third-party frameworks. In ASP.NET, the entire stack is built on MVC.
3. Got into the abyss of success . You can actually write a supported application in ASP.NET MVC using a standard project template. And the standard WPF template without third-party frameworks is a way of torment and adversity.
4. Extensibility selected . Almost everything in ASP.NET MVC is based on interfaces and abstract classes, which you can extend, thereby changing the behavior of the framework. I swear, the WPF team has never heard of interfaces, and few abstract classes have internal constructors.
5. Elected open source . ASP.NET includes jQuery and JSON.NET, and it integrates perfectly with countless open source tools. WPF, despite the endless list of MVVM frameworks, and despite the complete impossibility of developing a supported application without one, still does not include them.
6. He became an open source . The source code for ASP.NET MVC was open from the very beginning, but now the whole ASP.NET stack has become open source and accepts corrections from the outside. WPF is not, and frankly, you wouldn’t want to look at the WPF code: it is terrible ( approx. Transl .: you can evaluate VirtualizingStackPanel ).

In addition, the Web itself is changing and developing before our eyes. Don't like CSS? Try Less or SASS. Don't like javascript? Try CoffeeScript or Dart. The Web now has a rich ecosystem of innovation; innovations that have not been in WPF since 2006.

Apples or oranges

I do not oppose ASP.NET and WPF in order to say that ASP.NET is better - it would be foolish to say this because they have different goals. I just want to show how one over the past six years has come a long way, and the other has not changed much. I think the whole thing is the lack of investment.

What is insulting is that WPF at the time started very cheerfully. Such concepts as dependent properties, styles, patterns, focus on bayndingah sounded revolutionary when it was unveiled Avalon ( approx. Perevi .: code name WPF).

Unfortunately, when practice begins, the implementation is mediocre. Dependent properties are unbearably verbose; language-level support would not hurt them. Styles and templates are also verbose, and much more limited than CSS (when WPF was just released, I expected a myriad of websites offering high-quality WPF themes, as HTML themes are now offered; but they are not, because it is very difficult).

Data bindings (bindings) usually Just Works, except when they do not work. Implementing INotifyPropertyChanged takes too mucha lot of code. Data contexts are a great idea, though it no longer works for items like ContextMenu. The ICommand interface was created for the service to two hosts: the WPF team prefers routed commands, and the Blend command prefers the command pattern; as a result, ICommand is not well suited for either.

Xaml

And this failure is XAML. The XAML language is so redundant that it is hard to imagine what people are invited to write on it. Yes, because it is not supposed! In the world of pink ponies and rainbows, designers use Blend, and developers use the Visual Studio designer, and no one ever sees XAML. However, in the courtyard of 2013, and despite the progress of Blend, most still manually write XAML. Visual Studio 2012 will not change this.

However, the biggest problem with XAML is not bad tools. They just didn’t fix the language to cope with the problems in the toolkit. And unlike HTML, XAML is not semantic. It is not interpreted; it is compiled. This is a serialization format, so there is no separation between markup and implementation.

Here is just a short list of what comes to my mind to improve my XAML experience:

1. Allow you to define imports of namespaces at the project level, and not force them to repeat in each file.
2. Allow to bind events directly to methods, and not through commands.
3. Make the binding syntax shorter and more memorable.
4. Allow using expressions in C # and Boolean logic instead of writing converters for each sneeze.
5. Allow a Boolean value to implicitly convert to three-digit Visibility without a converter.
6. Get rid of prefixes for non-built controls.

The ASP.NET team was able to write a completely new parser (Razor), why can't you make even the simplest changes in WPF?

MVVM

Words can’t convey how tired I am of hearing about this pattern, especially from former WinForms developers who decided that MVVM was the most savory thing because they read Silverlight Unleashed and were amazed by MVVM Light.

Actually on everyThe WPF project that I happened to see was a very smart guy who thought he was smart enough to write his own MVVM framework, which turned out to be crookedly rewritten code from some article on the Code Project. Ultimately, in all WPF projects, the ViewModelBase class appears, packed to capacity with inherited methods for managing threads, progress bars, and INotifyPropertyChanged. Displaying a dialog takes 20 times more code than just writing the code in Button1_Click, and it will be equally well tested as a result - most people using MVVM claim to do this for the sake of better testability, but in reality no one writes unit tests for view models, except for architects who invent MVVM frameworks.

MVVM is heard on every corner, but the lack of support at the platform level means that every WPF developer is doomed to write some bad, poorly supported WPF applications before he understands how to do it right. This is annoying.

Conclusion

As a result, when I look back at six years of working with WPF, I understand that it is based on several good ideas that were not very well implemented. The same can be said about the first versions of ASP.NET (does anyone remember about Web Parts in ASP.NET 2.0?)

But there is one big difference: ASP.NET has evolved. The web stack has evolved. Not only the code has changed, but also the philosophy of the team. WPF has not seen a single major change since 2006.

Most upset is that there is no alternative. In the world of the Web, ASP.NET competes with Ruby and PHP - if you don’t like one, you can choose another. On Windows desktop, I'm essentially chained to WPF.

You can enjoy working with WPF. You may think that XAML is a beautiful, clear, easy-to-use language. I also thought so in 2006, and if the platform is still a joy to you, that's good. She is with us for a long time, because there is no real alternative. But for me, I'm glad that the days of WPF are behind me, and that my work is based on ASP.NET.

Translator's Note

In many ways, I share the author’s point of view, however the desktop still remains closer to me than the Web, and therefore I am faithful to WPF. But sometimes I look at the code, and I want something better ... And when you look at the examples of a competitor in the face of Qt, you realize that soon they will have something in C ++ that we could not even dream about in C #. Why is there a elegant JSON flavored with JavaScript in the native native language, and in the managed language - this monstrous and unreadable XAML with footbags from multi-triggers with multi-bindings and a Setter.Value element?

How do you develop WPF ? Do you have your own MVVM framework? Do you have a ViewModelBase? Do you have a BoolToVisibilityConverter and IsNotNullConverter?

Eh, if only the competitor at WPF appeared. Serious, popular. Then maybe Microsoft would be worried about the development of WPF ...