Tuesday, July 5, 2011

Why WPF sucks: an overview

I was just reading this article detailing someone's frustrations with WPF, and thought I should add to the chorus.

I agree with Mr. Mitchell, I'm fairly sure I will never like WPF. It has a steep learning curve because it's undiscoverable. WinForms was relatively easy to understand; its most complex feature was data binding. But WPF relies heavily on XAML, a language in which MS somehow expects you to "just know" what to type to get what you want, and when you somehow figure out what to type, half the time it doesn't work and you get a mysterious unhelpful exception (or no exception, but it still doesn't work.)

In WinForms, there was an easy-to-use designer and anything you did was translated to easy-to-understand C# (or VB) code; in fact that was the native representation! XAML, however, can't be translated to anything except BAML, so nobody can easily understand what a piece of XAML does, nor can we step through it in the debugger. To make matters worse, XAML relies heavily on dynamic typing (and even the C# part constantly makes you cast "object"s). This prevents IntelliSense from working very well, thwarts the refactoring tools (ever tried renaming a property that was bound in XAML?), and shifts tons of errors from compile-time to run-time.

In short, WPF programs look pretty, and offer better options for data visualization than WinForms (DataTemplates in ListBoxes are a major improvement), but beyond that they are a huge step in the wrong direction. How could Microsoft think this design was a good idea? If any company but Microsoft or Apple made a GUI architecture that was this difficult to use, no one would want to use it. For my company I started to develop some ideas for a GUI architecture that would have been much leaner and more elegant than WPF, but it looks like I may never write that code. The point is, I have some sense of how a GUI framework should work, and it's not like WPF.

I remember my first WPF app. I had an ItemsControl with a ControlTemplate containing a ScrollViewer with a Grid inside (note the learning curve: you can't use WPF very well without some idea what those terms mean.) I wanted to know: "How do I attach mouse event handlers to an ItemsControl to detect mouse clicks and drags on blank space?" The answer? In order to get mouse events with meaningful mouse coordinates (i.e. coordinates in scrollable space), it was necessary to obtain a reference to the grid using a strange incantation:

Grid grid = (Grid)_itemsControl.Template.FindName("Panel", _itemsControl);

Then I attached event handlers to the grid, and inside the mouse event handlers, get the mouse coordinates w.r.t. the grid using

Point p = e.GetPosition((IInputElement)sender);

Plus, in order to get mouse events on the entire surface, the control (actually the grid) must have a background.

In another case I had to use this incantation:

var r = VisualTreeHelper.HitTest(_panel, new Point(e.X, e.Y));
var hit = r == null ? null : r.VisualHit as FrameworkElement;

In WinForms, pretty much all the methods you need are members of the control class you are using. But this example shows that in WPF, sometimes you have to call a static method of some other class to accomplish what you want. Then consider the minimalist documentation (so that you really need to buy a book to learn WPF)... that's undiscoverability at its finest.

Update: Also, WPF is shockingly inefficient, as you may learn if you need to use a non-virtualized ListBox in order to get MVVM to work and the list has more than about 1000 items. Trivial items (short text strings, no DataTemplate) consume about 8 KB of memory per row, or 80 MB for 10000 items, and ListBox takes 4 seconds to handle a single arrow key pressed in a list with this many items.

53 comments:

Richard Mitchell said...

We had a couple of developers doing a down tools project in WPF who had a similar problem with controls not getting clicks and it was indeed due to it having a transparent background rather than a solid colour. Not something I'd immediately think of.

The other problem I encountered was a rendering problem only on certain graphics cards for certain effects. An example of this can be seen on the MSDN forums.

WPF is a nice idea and the binding allows a much better separation of engine and UI but I would really want much more compile-time checking as the opportunity for run-time breakage is way too high for my old brain.

John Fuex said...

You hit the nail on the head.

Unlike web forms that encourage you to learn the platform incrementally, you will spend the majority of your time in your first WPF project feeling completely helpless and stupid.

Props to you for telling it like it is.

Steve said...

Totally agree with this. I'm on my first WPF project; and while there are some cool aspects to the framework, I've found it *ridiculously* annoying to do the most trivial things. For example -- data binding to a header column of a DataGrid; or adding footers with multiple totals to the bottom of one. I've sent hours trying to do simple things I've done with other frameworks in minutes.

To make matters worse, when you Google "WPF Sucks", this is the first thing that comes up: http://goo.gl/zMon4 -- some poor shmuck trying to learn WPF and being told "no, it doesn't suck," and that it's his fault because he "hasn't grasped some concepts". Well, maybe that's because Microsoft's WPF documentation sucks, too.

Thanks for commiserating with those of us who think WPF is just plain annoying.

Anonymous said...

I started a specialized text-editing app in Winforms, but decided to restart in WPF as it's "The Future", and I should learn it. What better than a simple app to do so? Well, Every Single Thing I tried to do was painful. Everything. I kept saying "it can't POSSIBLY be this hard, all I want to do is..." I'd search for examples of what I could do INTUITIVELY with a couple clicks and a line or two of C# in Winforms, to be invariably hit with "It's simple, you just..." followed by a wall of XAML. Maybe I'm old fashioned, but I want to write the program in the language I'm writing the program in.

I'm new to Windows programming, but I know the basics and can find my way around C#. When I got stuck in Winforms, the problem was usually something simple that I'd remember. But I'm bailing on WPF because I'm sick of using 99% of my time googling to find some arcane XAML incantation to make something simple work. I guess it's great if you're an expert, but experts of any system/language will claim that. It doesn't make it inherently better.

If MS is headed in this direction, then I expect Windows 8 to do everything you'd ever want a GUI to, except it drops you to the command prompt when you need to do simple file operations like copy or delete.

Anonymous said...

Totally Agree. WPF is the worst programming model i have worked with.
It may be a super genius design but if its not practical and usable, its just a waste of time. Microsoft and Adobe (MXML/Flex) just copied each other and both technologies will go down.

I have wasted enough time on WPF. I think i will probably move on to C++/MFC. With Apple Objective C coming up , a bit of C/C++ skill will be good.

Im starting to like Javascript because of XAML :). Atleast I will not be proposing WPF for any new projects in my company. I would rather go with C++/MFC or SVG/HTML5.

Nick Bedford said...

Never a truer word was spoken.

I love Windows Forms development because it allows me to Get The Job Done. I drag a control in; I double click it; I type a piece of code in; I hit Debug and the program looks like it is in the designer, behaves like the rest of Windows, does exactly what I ask of it and this is all finished within minutes of creating a new Form.

I've tried learning to use WPF a few times and it's a total clusterf@!k, excuse the French. Most of your Windows Forms knowledge is completely thrown out of the window. The designer UI doesn't look like anything in particular, the controls have annoying state fades (buttons take more than a second to fade to a hover state), and there's many missing objects that are in Windows Forms.

I also dislike the change from C# generated UI code to XAML. Why? I can adjust UI code directly in the language I already know which has full Intellisense.

WPF is not the future. It's an entirely separate framework for other people.

Anonymous said...

In all honesty, sometimes I feel WPF is a bad MS joke taken too far, kinda like Windows ME where a group of developers came up with an idea (which was really a prank) on how to write the worst possible piece of software and get someone to use it on April 1st. Unfortunately, due to some mismanagement it got put into MS release cyles and before they knew it the software was packaged and put in front of us dumb folks trying to figure out how to make something totally unworkable work. You can't accuse MS for not having sense of humour, that's for sure.

Anonymous said...

WPF = NO VALUE ENGINEERING

Anonymous said...

I want to build a mid-level app. Had a choice of WPF, old schools windows & Java.

Whoever invented WPF needs to be hired by the NSA - I would never be worried about nation's security with that guy in charge of encrypting everything. In any case it would get him away from real-world problems we all face.

Anonymous said...

I can't agree more. In the Xaml, you never know where to put your hands to make things work.

Anonymous said...

I agree with all of the above and then some. And we're not alone. I've done many applications in Java and Win32, I've done many Web-Based apps. I've done exactly 1 application in WPF and am still struggling with. It was also the last one I'm sure.

Marc W said...

I am not sure what to think of WPF yet. But there is one thing that annoys me: The talk about the flashy GUIDs. I am totally not interested in that. I personally hate a GUI with all kinds of bling bling, and no consistent way of presenting and finding information. That is totally not a motivation for me to learn WPF.

The software architect I work with drools with the tool though. But he is a typical MicroSoft one trick pony, that loves everything if it has the mark MS on it.

Ceddy said...

I had the hardest time figuring out how to use a button in WPF. I am an ASP.net guy and I think WPF is way too complicated, especially if you are using the MVVM approach. So many views, so many view models, so many models, any software engineer would get lost. And yeah the learning curve is very deep, too deep if you ask me. I personally dont like it and I dont think it will be around long. Great post.

Justin said...

I just had to jump on the band wagon here. I've been writing C# since version 1.0 was released and have used winforms extensively.

I've also done C/C++/MFC/QT.

I decided to use WPF since it's THE FUTURE. Talk about a royal PITA. XAML makes layout a bitch and half the controls I could just drop onto a winForm I had to hand craft a shit ton of XAML that often never worked. The learning curve is a cliff. I gave up and will stick to winForms.

XAML and WPF blow.

Qwertie said...

The sad thing is that WinForms really needs a replacement... but WPF and Silverlight don't cut it. I'm really tempted to make my own frickin' modern GUI library... but I haven't used WinRT yet; is it an improvement, or more crappy XAML?

Luis Perez said...

I agree that out of the box WPF can be complicated and tedious. But I do have to give them credit for creating a very extendable framework. I'm surprised more people haven't taken advantage of that to make it simpler. I was able to create a binding syntax that essentially replaces WPF binding syntax, you can find it here: Simpler WPF Binding - I was just scratching the surface, I think a lot more is possible. I have not seen many efforts like this though, maybe the initial learning curve is just too high to gain enough traction.

Elo said...

I completely agree that the learning curve for WPF, particularly the XAML portion, is quite steep. Once surpassed though (to some degree, I still have MUCH to learn) I find it a LOT more enjoyable and productive for me to work in WPF than WinForms. I do all of my prototyping and personal work in WPF and it just feels comfortable now.

It feels like I have much better control over how the layout will look and function. The separation of data formatting from how the data is represented is really great. What's more is I can see all of this from a single view instead of having to go through property page after property page, or have to read the auto-generated code and work backwards.

On the back end using WPF helps guide me towards writing better code. It goes against the grain to 'cheat' and if you're referring to any GUI object by name then you know you're doing something wrong (98% of the time).

The data-binding is beautiful and very powerful/flexible, and may actually be the best feature of WPF as a whole.

Despite all of this, I do recognize the huge community backlash on WPF. There seems to be even more dislike of WinRT, Metro, and Windows 8. With Microsoft trying more and more to bury WinForms I'm struggling to figure out where to focus my efforts for the most ROI. Silverlight appears to be a dead end road as well. ASP.NET MVC seems to be getting good press of late but who knows on that. Maybe it's time to go C++ with QT?

I don't know, I like WPF a lot, but the ship seems adrift and people are catching life rafts left and right. But where are they headed?

John said...

I was a Software Design Engineer with Microsoft while this WPF POS was being designed. The ONLY reason we are stuck with this SNAFU is it was Eric Rudder's brain child. Eric is one of BillG's inner-circle. No doubt Eric is smart, but he is a complete A-Hole with no common sense.

Pray that BillG does not replace SteveB with Eric. If he does, forget about Windows and figure the rest of your life you will be DEV'ing for OS/X.

AJ said...

Instead of WPF, it should have been named WTF (What the F**k). You get the idea. I thin the idea is great but the implementation is overly complicated.

Sandro Magi said...

I was about to start my first WPF for a client. I had heard it was a little difficult to learn, but figured I might as well learn it. You've just convinced me to avoid it. Winforms + Rx.NET it is, thanks!

Anonymous said...

Thank you for the post and all the comments... I'm glad to not be the only one who gets irritated and google's "WPF sucks" every time I attempt to do something seemingly simple with WPF. It seems WPF is one of those instances where everything is changed for the sake of change rather than any real improvement. Yes, I hear WPF makes this better, and that better, but for what I'm trying to do, it's basically change for the sake of change. Wish I started this project in good ol' WinForms as it would take me a lot of time to change now.

Anonymous said...

I feel like WPF is part of a larger misconception that less code is always better. Look, I did this in three lines of code! Look, I did this in zero lines of code! Well, being able to do lots of stuff with little or no code generally means taking advantage of *implicit* behavior. And specifying things in declarative tree structures (XAML) generally means writing *strings* instead of *code* -- strings that are treated as code implicitly, that specify not only layout but functional relationships, but for which you have no intellisense to guide you and remind you of what's possible and how things work. With implicit behavior, sure, you don't have to spell out the little loops and default relationships because they are taken care of for you by the framework. But that assumes you know how the framework is doing everything -- and there is really no way around having to gain this knowledge because as soon as you want to tweak something you need to know what's really going on. In my opinion/experience, it's much better to have to wire things up yourself a bit each time -- to write those little loops and relationships -- than to have to understand all the implicit rules, relationships, and mostly opaque behavior that let you bypass that code.

Anonymous said...

Yes, I think WPF is very gay indeed.

Specifically the following points:

1. XAML is hideous to work with. The designer is awful and buggy. The designer from VB6, over a decade ago was better!!

2. Everybody wants to use MVVM with it! Why? It's a horrible pattern. As soon as you try to use it for real world applications you end up with ten million viewmodels. The very nature of the view model means replicating the same properties from your model/dto or whatever and then adding in lots of other specific properties to do with how text is displayed on your views. Horrible, really really horrible. Reckon everybody will look back and laugh at what a load of crap WPF/MVVM is.

Funniest thing that makes me laugh is when you see newbies talking about how great MVVM is and then detailing 100 lines of complex code they used to close a view from their viewmodel. Great pattern that, if it makes you replace one line of code with 100. Oh, and at the same time they're all spouting on about how MVVM makes your code so much more testable, you couldn't make it up. Knobbers.

Qwertie said...

Err... although WPF sucks, I do like MVVM, and viewmodels are easier for automated testing than views (although so far, not easy enough that I've been willing to take the time to actually do it.) I am even using MVVM with WinForms+UpdateControls, although it is a bit clunkier.

Anonymous said...

Thing is though, have you or anybody ever seen one of these viewmodel tests? Nope. Never seen one. Any who cares anyway! Most of the business logic, the stuff that needs to be tested, is in another layer that's always been testable - and even that stuff only gets tests written for it 50% of the time.

In the real world people don't have time to write many tests so they write them for the important stuff - that's not stuff in viewmodels.

So, the fact that the ability to test viewmodels is one, if not the, most important factor continually mentioned by MVVM enthusiasts, and yet it's so important nobody ever uses this important factor, tells us something very profound; MVVM is crap.

The only place I have seen where I have chosen to use MVVM is for building stuff like TreeViews. These are much easier to use where you bind to and manipulate viewmodels (possibly listviews as well). Everything else, MVVM gets in the way for no benefit.

I lika, to do, da chacha.

Anonymous said...

What amazes me is the popularity it gained. Everybody is talking about WPF and MVVM, while it is really such a pain in the ass. Just look at the staggering number of questions asked in forums such as StackOveflow to gain some understanding as to the complexity of WPF. I mean those people who asked those questions are not dumbs, nevertheless, many of them lost hair due to them so many times banging into the WPF wall. its popularity is definitely beyond of my comprehension.

Anonymous said...

I've been working on a project for 3.5 years now. It's a desktop app with WPF and Winforms, about 600,000 SLOCs. I made the mistake of using WPF to get some of the transparency features, and animation. Hey, some of that stuff looks nice. However, every time I try to do anything beyond simple - I wind up spending hours trying to get it to work. I spent 3 hours yesterday trying to make a datagrid embedded combobox work with a lookup table. Jeez - it was like beating myself in the head with a hammer. MS had better get their stuff together quickly. That is all I know. I'm glad I'm almost at retirement age. I still remember Turbo Pascal. LOL

alexpchung said...

WPF makes me want to cut myself. I hate Microsoft WPF.

Anonymous said...

My project now contains over 42,000,000,000 viewmodels; some of them have unpronounceable names as I ran out of words in the English language.

Who invented MVVM/WPF anyway? What is his name? Is is still alive? Why is he still alive?

Anonymous said...

Hey everybody, I've got a great idea. Why don't we all use a pattern where I have to copy everything I need from my window (view), like say, the index of the selected item in a dropdown, to another class. Instead of then writing code to act directly on that index in the class commonly known as the 'codebehind', I'll copy it to another class via some manky databinding and then manipulate it there. Er, good idea. I'll end up with ten million properties.

Who was actually barking enough to think this was a good pattern and why the hell did then entire IT industry act like a bunch of retarded lemmings and jump in there?

Qwertie said...

I do like MVVM, actually. Not the "perfectionist" flavor in which there has to be a series of properties (Foo1, Foo2, Foo3...) in the viewmodel that are simple wrappers around the existing properties (Foo1, Foo2, Foo3...) in the model; I do not like to waste my time. When I use MVVM, viewmodels are not allowed to access the view and models are not allowed to access viewmodels, but the view can directly access the model if the viewmodel does not add any additional functionality.

Back when I put all my code directly in the view (WinForms), it was a big mess. By using MVVM with Update Controls I get two benefits: (1) code that is more organized, and (2) automatic data propagation from the model to the view. If two views show different representations of the same data, they are automatically synchronized. If the model is modified, whether by the GUI or by code outside the GUI, the GUI is updated.

Note that MVVM is not WPF-specific, it just happens to work fairly well in WPF, most of the time.

Telavian said...

I have been using WPF for a few years now and I am amazingly more productive than I ever was in WinForms. WPF feels much more natural and smooth. I think all the dislike is essentially because it is a new technology with a new way of doing things. WPF is vastly better than WinForms and is far easier than Asp.Net.

Anonymous said...

Have to say that I don't think people dislike is because it's a new technology; it isn't any more, it's been around a long time now. I've been in IT a long time. I've spent years doing WinForms, years doing ASP.NET and years doing WPF. They've all got good and bad points, it's just that WPF has a lot more bad points than the rest.

The only think I like about WPF is how powerful and flexible it is in terms of designing screens to look and behave exactly how you want. Everything else is dreadful. I find it far, far slower to develop in than WinForms and certainly far messier and frustrating.

I think the fact so many people dislike it and find it a pain says something about it.

Anonymous said...

WPF is vastly an incomplete piece of technology.
When you release a "new" paradigm, that is supposed to be "the future", you have AT LEAST to guarantee that *everything* you made with the previuos tech, is doable in a easier manner. Plus, you must add some strong new points for the new tech.
This simply doesn't happen with WPF.

Microsoft completely failed here, and it is failing miserably in all the area of smartphone, tablet, desktop.

Even in the web area, the marketing is completely wrong: everybody can recognize that MVC is "the way to make web app today", but still MS says "it depends". LOOOL
MS even developed a mixed enviroinment called Webmatrix, where you got Razor server syntax BUT a page model (like in classic asp). This is soooo evil. Sooo much confusion for developers!

Steve Jobs clearly teched us that a company CEO must indicate what is past, what is present and what is the future.
Jobs made the funeral to System 9, when he introduced OSX, to clearly state that OS X = future, and System 9 = dead.

MS *never* says "this is dead", and that is a total failure, I'm sorry but this is for real.

MS is a slow bandwagon of geez, always late on technology, completely fail the smarthpone tablet, MS will be irrelevant in the Market with Lumia covering a ridiculous 2% of the market after 3 years.
Win8 is a fail.
What we will have within 6 months? Win8.1?? ahaha still the same crap.
While competitors are miles ahead.

Anonymous said...

I love you guys!!! I have been banging my head against a wall for days now saying "Surely to cr*p it cant be this hard to do a combobox or a listview"....but it is. Is this a joke? Twenty years of programming exp, web, winforms, C++ and yet I am stumped by this dang awful cryptic BS called XAML. MS pull your head out of your a double five (a55) you keep this up and I am no longer an MS primary programmer. I will go PHP Jave anything but XAML.

Anonymous said...

Great comments, personally I cannot stand all this MVVM BS, patterns that over complicate simply are a waste of time I do not care how well you know it. Reusable code phaff thats been the holy grail for decades are we so conceited to believe that what we write today will be relevant never mind five years from now how about 6 months. All apps should be built as quickly and simply as possible to aid in maintenance full stop, they will be in the bin within 3-5 yrs and everyone will mock the technology being used..As someone else said and all the lemmings just jumped on the band wagon...what happened to web services...then what happened to WCF and now windows services...please give me a break. No prosetilising its all BS C++ seems to be the one stable language.

Anonymous said...

Pretty naive comments here from developers who don't know how to use the product.

Native controls are written around the MVVM pattern, what's so hard to get your head around, don't get confused between the pattern and some of the bloated frameworks out there.

MVVM Light will take care of most of your VM wiring leaving you with a testable VM decoupled from your interface which can then be styled in blend.

WPF can be challenging especially as you probably have to use IoC and Prism if you want modularity but the upside, it's also challenging if your thick!

Anonymous said...

" I find it far, far slower to develop in than WinForms and certainly far messier and frustrating."

VS2010 and 2012 are written in WPF btw.

Winforms is dead, it's is easier to develop front ends if you want something basic, invest a little time into learning WPF, you won't get it straight away. Feel free to stick with a toolset that hasn't changed since 2005 though, just don't expect to pick up a decent contract/job in 5 years time.

Ian said...

I first built GUIs with Borland's OWL and Microsoft's MFC. Using either of these to put together a LOB application was so much easier than with WPF. MFC had a wizard that built a basic but working app to start with. WPF gives nothing like that. Also, Microsoft provided many complete sample applications. Life was so much easier then. WPF is a big backward step in terms of usability.

Anonymous said...

Pretty naive comments here from developers who don't know how to use the product.

Native controls are written around the MVVM pattern, what's so hard to get your head around, don't get confused between the pattern and some of the bloated frameworks out there.

MVVM Light will take care of most of your VM wiring leaving you with a testable VM decoupled from your interface which can then be styled in blend.

WPF can be challenging especially as you probably have to use IoC and Prism if you want modularity but the upside, it's also challenging if your thick!


Lol, everybody else is thick. I can assure you that I understand fully how to use WPF, MVVM etc. I also fully understand how to use many other technologies so I can compare and contrast accurately. WPF is sh1t, complete sh1t for all the reasons elaborated above. MVVM adds greatly to the sh1tness for many other reasons.

There's nothing challenging about IoC etc. It's WPF/MVVM that's challenging because they are so painful.

You sound like a junior bod who doesn't really know much about anything and so have nothing to compare to. You are also very arrogant in assuming that many other experienced developers are all thick rather than have valid points.

I put it to you that you are actually the Mr Thicky Junior here and your code would probably make a monkey burst out laughing. Thicky dumbo.

Anonymous said...

I hate WPF too. Shelling out the money for Microsoft products was always ok because their products made things easier. WPF is too hard to learn for guys like me who just want to painlessly create little apps.

Anonymous said...

What's the best part of programming WPF/XAML...when you're done programming WPF/XAML.

Anonymous said...

iv told to my self many times. Go ahead give it a try , give the chance to WPF to win you. every day am fighting with my self and WPF but i always get the WIN :) i don't know why.. m('.')m
There so many difficulties that makes me hitting my head.

Many users are finding wpf much more easier and am trying to understand what they found easy rather than the GUI where you can make it look nice, but after all even that you realized that at the end you spend hours in design to adjust the controls to fill the correct size ,locations ,layouts panels etc.. and all that using XAML not in designer because you realized that the Designer is not really helpful at the end. For someone like me coming From Windows Forms i find it extremely difficult this learning curve.

As someone mentioned, definitely windows forms need improvements but of course this not with WPF.

I wondered how long wpf will be on. and what Microsoft says about all that feedbacks,
I hope to see something new in windowsForms that will really be helpful and stable improvements

Anonymous said...

There is a learning curve, but once you learn it WPF is pretty cool. XAML is a great way to do layout, data binding is flexible, and you can build large, reliable, modular projects with it.

Ian Brian said...

Some criticise those who say WPF is too hard. It's wrong to do that. The fact is that building a GUI app used to be so much easier. Why bring out a new technology that makes it harder to produce a GUI than it was 15 years ago? There is no benefit. .NET has been a huge mistake.

Anonymous said...

I agree with these posts . . . that is why I wrote an open-source code library that allows you to write a WPF app with NO XAML at all. 100% code-behind. This library is very late to the party, but it makes building WPF apps much more fun. Very good for building small WPF tools fast :-)

http://wpfcomposites.codeplex.com/

Enjoy,
Bryan

Anonymous said...

Hmmmm... I was in love with WPF once. That was until I had to bind a group of radio buttons to an enum. Sure it's possible, but if I have to write extra 40 lines of code to find out which radio button was checked then I know there is something seriously wrong with framework.

Anonymous said...

I think WPF is a great framework for bling bling prototype and projects that user-experience is rated much higher than development/maintenance cost. This is 2014, and in terms of user-experience per dollar, winform still wins hands down.

Anonymous said...

WPF is stupidly difficult. It used to be the case that simple GUI's could be produced with very little thought and they were much much faster than anything you can do with .NET let alone WPF. C# is a pain the ass. When I delete a C++ object it's gone and the destructor is called immediately. .NET is a lumbering giant and WPF is a product of warped mind. C++ with ATL/MFC was fast and sleek.

Anonymous said...

well, the only think I can say for WPF is that I want to scratch my face front of the screen, then sit back smoke a cigarette and then go back to windowsForms
:asda grrrrr!!!

Anonymous said...

I read all the comments and I could not notice that there are some people who are still trying to explain how good WPF is (although they are obviously at the wrong place, I mean WPF sucks gathers people that hate WPF...).

Those people compare it to WinForms and say "well, it is clearly better than WinForms; why don't you invest some time and learn this "new" technology...". Sure, it is better. Especially since WinForms is dead. I mean a living dog is better than a dead one.

But that is not the main problem with WPF. The main problem with WPF is that it is not simple. And here should be made a clear distinction between easy and simple. Easy means well known or similar, close to the existing knowledge. Easy is relative. One thing may be easy for you, while incredibly hard for others (say Chinese). Simple at the other hand means obvious. It means decoupled. Simplicity hepls you reason about your programs. (Some things are decoupled in WPF, say UI and logic, but not all. Furthermore things in WPF are not obvious.)

It is easy to speak German if you are German. The same thing goes for WPF. It is easy to take advantage of all the goodies provided once you grasp the "whole concept".

In WPF MVVM is not the problem. Nor is the pages cluttered with code. Neither is the hard debugging. The problem is that WPF is a ridicoulously complex framework for what it does.

And I am telling you this not as some random guy. I am telling you this after years of writing PHP, Pascal, Java, SQL, C/C++, C#, VBScript, JavaScript, HTML, CSS, XAML (yes, XAML, for both WPF and Silverlight, 3+ years of experience), Python, Clojure. I am not even going to list technologies such as Swing, WebForms, WinForms, MVC (as ASP.NET MVC) etc. There exist far better options in other frameworks and languages simply because they are SIMPLER. And by the way Swing and WebForms are not much simpler.

Frameworks should be simple. WPF is not. Complexity is not a challenge that the developer has to tackle. Complexity is something that the creators of a framework should consider and prevent. Everything should be made as simple as possible, but not simpler of course. After all Einstein said it: "Any intelligent fool can make things bigger, more COMPLEX, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."

Anonymous said...

WPF is the greatest tool for creating complex UI if you are experienced enough. I had to learn a lot when i started 3 years ago and now i am still on the road of getting it.
Complex UI is complex in nature so if you seek for simple programming, go doing foxpro, excel macros building or at least Turbo Pascal on old mainframes is for you.
WPF is tough to learn but i repeat it's because the nature of the problem it solves.
Try to apply your WinForms in the project where non standart design required and you'll find it's implementation more difficult and time consuming than learning WPF + solving the problem.

Anonymous said...

Oh what a pity... Schoolsters and lazy stupid students complaining here about they've sucked cock in doing real programming. Be man that's having balls not a fcking sissy creating wordpress sites and calling himself 'hacker'.

With regards, B. Obama.