Microsoft has so mismanaged WPF over the years that most developers want nothing to do with it. That means the dot net world lacks any sort of real UI building capability, forcing us int HTML/CSS/JS front ends (at least until Mono goes live with their WebAssembly port of dot net, at which point we can write our front ends in C# again, hopefully not far into 2018)

Not at all!

I will gladly use Win Forms, WPF or UWP over anything resembling Electron.

I'm dealing with slick and pretty consumer apps.

Getting winforms to be pretty is not reasonable. With WPF, you can get the pretty, and then trying to get it to perform reasonably where no browser would break a sweat will drive you to distraction.

And UWP, well don't get me started. Perpetually half-baked, trying hard to push a design system (whatever they're calling metro these days) that isn't popular, isn't thought through, and is so low in information density that I can't even imagine pulling off Spotify with it. And you end up shackled to the Windows Store, the sandbox, and a mobile-style execution lifecycle.

I have been doing mostly WPF/UWP the last four years and hardly got any performance or L&F complaints.

Yes, sometimes the default template is not the best, but with a bit of game development skills it is quite easy to improve it, all the way down to metal.

With the browser one needs to find the magic browser specific CSS properties incantation, with the hope of having a set of divs accelerated by the browser engine, without any control how it actually happens.

Microsoft's attention seems to be elsewhere.

It is in UWP.

10 years ago everyone was resiting Windows 7, any XP was the best OS on Earth.

Now 10 years later, it is the same song with Windows 10 and Windows 7 as protagonists.

It's hard to beat WinForms for cranking out a quick and easy UI on Windows.

Kind of.

VCL is also quite good, in spite of how things went for Delphi and C++ Builder.

Nothing prevents you to use WPF/UWP with visual designer and code-behind, just like Forms.

Where WPF/UWL loose in simplicity is when you want to start customizing L&F or use the standard DataGrid.

VCL was the best back in the days when I used Delphi 5/6, it's kinda sad if it's still true that VCL is still a front runner after a decade of near stagnation by whoever owned it at any given point.

I'll admit though that the only IDE I've used that I like as much as Delphi 6 is Intellij.

WinForms is essentially “inspired” by VCL, through Anders Hejlsberg I guess. As are some parts of C#. WPF otoh is inspired by corporate brain damage.

> WPF otoh is inspired by corporate brain damage.

Not at all, WPF is like having a monoid in the category of endofunctors for UI programming.

Its concepts of UI Lego style building blocks, with templates, commands, mvvm, multi-binding, storyboards..., might be hard to grasp if one is happy with plain code-behind snippets, but once one gets it, it is quite powerful way to write large scale UIs.

I don't know any of that terminology or category theory in general, but I'd like to assure anyone who cares that you really don't have to to get the elegance and power of WPF. It was a steep learning curve sure, but totally worth it. As far as visual control, elegance, and development-pleasure, I think it far surpasses WinForms, the Android UI toolkit, Cocoa, and the web stack. (Though XAML is annoyingly verbose.)

The only reason I stay away is because of the performance issues, and the opaque ways in which performance degrades.

> WPF is like having a monoid in the category of endofunctors for UI programming.

Takeaway: I will start using WPF right after I get a solid grasp on category theory. That will happen "very soon".

It might be powerful, but if something goes wrong it’s impossible to debug. That alone negates all of its advantages to me. I don’t like magic I can’t debug or see source code for.

>the dot net world lacks any sort of real UI building capability

Off the shelf, yes. But third party providers like Devexpress and Telerik have stepped into that gap and now produce some very polished component suites that sit on top of Winforms. At a cost, of course, and more geared towards the enterprise market.

I've used component suites like these in new .Net desktop products and without fail they're received well.

Under no circumstances would I use WinForms for something I have to release to the public in 2017. It was a great API upon release. It's an awful call today, when DPI scaling and similar "this was written with something past Windows XP in mind" concerns are at the forefront.

And, unlike something like Electron.NET (which I wouldn't use either, because I'm not scared of TypeScript, but whatever, I get the reasoning), you're bolted to Windows and Windows alone. Maybe you have no MacOS users, but most folks would like to have those users. If only because they tend to spend more money on software.

Windows forms was the coolest thing I’d ever seen back in 2002, and it’s still my go to for a little window with a couple buttons, but the HTML/CSS ecosystem has so blown past it in the past 15 years that even built on a terrible foundation (CSS when I want Xaml) and a terrible language (JS when I want C#), HTML/CSS still ends up looking like the right choice to me for anything really sophisticated UI/UX wise.

My main product is largely WinForms and the UI was quick and easy to develop.

The two downsides that stop me using it now are poor high dpi support and lack of decent cross platform support.

High DPI support is available on .NET Framework 4.7.

https://docs.microsoft.com/en-us/dotnet/framework/winforms/h...

EDIT: Typo

That’s 4.7, not 7.

Thanks.

What?!?

.NET is one of the technology stacks with better UI designers.

Except for Anvil, there are hardly any Web tools able to compete with what Blend is capable of.

A lot of developers don't want to write the core (and sometimes complex) business logic in Javascript, and thus this allows writing client applications that take advantage of all the .net framework with strict compile time checking that is better than Typescript.

On the other hand of the coin a lot of developers in the frontend and design related space are experienced with HTML, CSS, and some javascript and therefore it gives the same advantage that Blend gave for WPF, it makes it easy for frontend folks make the application look good while the C# folks can make an application function well.

Yeah, I can't see any reason to do this.

Now that I'm not working in the .NET world anymore, the one thing I really miss is WPF, as soon as I'm touching any html/css. Never had any issue with z-index or something not displaying the same way on another browser because whatever is not supported.

WPF/UWP are a dream compared with jungling HTML, CSS and JavaScript, while trying to keep them behaving the same across all required browser versions.

WPF and Winforms are already well suited for Windows UI. If you want snappy UI: Winforms; If you want cute designer UI: WPF.

I agree with you, why would you want to go to the land were CSS is awesome (https://ih0.redbubble.net/image.30416963.4324/sticker,375x36...). The only reason I see is that you are already proficient in CSS quirks and special cases, I am not sure that it is a good reason.

yodon is correct Microsoft has neglected WPF during the last year, and as the same time the javascript commutity was growing fast and hard. So why Neutronium? 1) There is much more javascript/HTML UI components maintened by the community available. Consider for example fantastic library such as D3.js. 2) MVVM is a great pattern but it can be cumbersome to write binding with converters, etc.. With Neutronium, you can use Vue computed for example and reach the result faster. 3) There is much more HTML/CSS designers than WPF designers.

I wrote a .Net assembly analyser/visualizer: https://github.com/NeutroniumCore/CodeDependencyScanner based on Neutronium and D3.js, sincerelly writing a similar software shoudld be an herculean task.