WPF is a mess. An absolute mess.

The idea was good - inspired even! Separate the logic and data, keep the UI as a view only layer, and allow absolute flexibility in the way it can be used.

Frankly, that as an idea is exceptional.

The reality is utter drivel. XAML is a clusterfuck - take XML which is already an abstract mess and make it more of a mess. Great!

The intention was to have a set of design tools which generate the XAML, but they were so clunky that now, writing it from scratch has become the norm.

WPF and XAML can make very complex things incredibly easy, like handling a tree component, but then things which should be straightforward like handling dragging on a canvas become so awkward to manage that you end up utterly baffled by it.

It's felt like a half finished framework for the past 6 years, and doesn't look like it's improved since I started working with it.

When we started a project which required a .NET based UI, we were going to work in WinForms, yet we found a number of posts by Microsoft engineers on MSDN stating that support for WinForms was ending.

Now, some 6 years down the line, it's still going strong as WPF is just not the total replacement it was intended to become.

This is another about-face from Microsoft when they realised that a product is not up to scratch. They don't fix it, they just backtrack and try to erase the evidence of the announcement in the first place.

And now, it's nearly 11pm and I'm sat up at the end of a 14 hour working day trying to work out why the fuck clicking on a component on my canvas sends it flying out of the side of the window to fuck knows where.

.NET - It lulls you into thinking it's all really simple to use, then creeps up behind you, covers your eyes, pushes you face down into the dirt, then kicks you in the shins when you try to get up.

Fuck you .NET.

At least I don't need to use the fucking dispatcher for this.

  • 6
    I would like to play devils advocate and say .Net core and working with it as a web framework is really nice, definitely can't deign to defend the mess of XAML however, that shit's a joke.
  • 4
    I'll have to disagree, and agree. I disagree in that I love WPF and continue to be very successful with it (and am incredibly more productive with it than winforms). I somewhat agree with you on tooling. Somethings are good, others not. I do a lot simply by editing the XAML directly. I agree wrt to MS. They seem to have mostly punted on all things desktop and so WPF related stuff has screeched to a halt because they are now simply web bandwagon lemmings.
  • 3
    @monkeyboy So long as you want to use WPF in the way the intend (ie, MVVM), you're laughing. It's pretty slick.

    That said, I don't see the point in having a ViewModel and a Model as separate entities when you need to duplicate properties in the ViewModel if you want to expose properties in the Model for binding in some way.

    The amount of boilerplate that you have to write if you don't want to use a framework is staggering, and it just seems like Microsoft got half way through the design then wandered off and did something else.

    It's like they did with COM so many years ago.

    The amount of potential in MVVM using WPF is amazing, but when you need to do something slightly out of the ordinary, it becomes so much more difficult than it would in WinForms.

    I had very high hopes for WPF, and in some areas, it's a vast improvement whereas in others I find using it less enjoyable than root canal surgery (and I'm really not using hyperbole there).
  • 5
    Well that's Microsoft for ya I guess :') taking common standards and morphing them in such a way that only their system would be compatible with it. Kind of like Apple's Xcode but even worse. It applies pretty much everywhere that involves Microsoft even in the slightest, and I hate them for that... Microsoft Windows may be the go-to OS for home systems and.. well, users. But Windows sure ain't the only system out there, and in my own workflow it's the single worst system that I've ever dealt with.. it's pretty much Microsoft vs common standards, i.e. Microsoft vs every other (usually at least somewhat POSIX-compliant) OS vendor out there. You likely won't see me developing for it :)
  • 2
    Console UI is where it's at.
  • 0
    Have to agree, WPF dev here, XAML is the worst thing ever invented. Bunch of nonsense tags, all over, and namespace collisions, shit life
  • 2
    That’s why I DO NOT do GUI applications in C#. I write badass services, tho.
  • 1
    ... don't blame .NET! it's good and has been good long before some crazyperson started building tge wpf sandcastle on top of it!
  • 0
    @Midnigh-shcode It's ok, I wouldn't call it good. It's got a weird threading model and memory management in .NET is somewhat less than straightforward.

    If you're using C++ in .NET, it's more controllable, but it's not a true .NET language.

    .NET as an idea is basically the JVM repackaged with a series of libraries tagged on top.

    I you develop Java on the JVM using SWT for the UI, the stack looks virtually identical.

    I've been working in .NET in some form since it first came out. We evaluated it for a project and decided against it as it offered no advantage at all over Java or C++ at that time.
  • 0

    "I you develop Java on the JVM using SWT for the UI, the stack looks virtually identical.

    I've been working in .NET in some form since it first came out. We evaluated it for a project and decided against it as it offered no advantage at all over Java"

    ...having a main language (C#) that actually makes sense (as opposed to Java) and isn't pain in the ass to use (as opposed to C++), and standard library structure that, also, makes sense (as opposed to Java's) is "no advantage at all"?

    ...okay. we disagree on what the word "advantage" means, then.
  • 2
    At that stage, .NET had only just been released. We tried it out, it wasn’t a mature platform and had teething difficulties which java didn’t.

    Java at that stage was at version 1.4 and was already a well established platform.
    We had the option to work with applets, which was a help as we needed a browser based client tool (this was in 2002).

    Keep in mind that there were no lambda expressions, generics, iterators or partial types.

    The framework was unproven outside of beta versions and the syntax of c# offered nothing that java didn’t. You still had to write get/set methods at that stage.

    We switched to c# some 7 years ago, as at that point the merits of using it over java were apparent. C# improved and evolved, java really just got more frameworks.

    In fact, IMHO it wasn’t until .NET 4.0 that it actually really became a much better solution than java. Up until then, syntax and structure wise the languages were both pretty similar.

    When you say standard library structure, do you mean the arrangement of the standard packages? Because they don’t make much sense in C#. One package spread across dozens of different extension libraries in the same namespace and terrible documentation for which one contains which classes.

    That was exactly the same as it was with java at the time, so really there was nothing to push us toward .NET at that point.
Your Job Suck?
Get a Better Job
Add Comment