Hacker News Reader

Comment by pjmlp | Hacker News Reader

Those of us that had a go at XNA, Silverlight, WebForms, Windows Forms, WPF, WinRT, WinRT/UAP, WinRT/UWP, and now WinUI 3.0/WinAppSDK, are a bit burned out with Microsoft GUI frameworks.

View on HN

Really, I still use winforms and WPF.

Winforms especially is going on 20ish years?

How do you feel burned by them.

Try to always move on to the newest one, every couple of projects, instead of using a 20 years old stack.

Sounds like you burned out by choice. As long as it is supported and meets your needs, keep using it even if it is 20 years old.

In consulting we don't have the privilege to use fossilised technologies, unless the customer asks for them.

There is no universal truth in consulting. Consultants still write COBOL.

You missed my unless part of the sentence.

You missed the first sentence of mine.

My second makes your first a tautology.

You're getting burned because you keep moving between technologies, and you're blaming Microsoft? Weird. Have you tried not doing that?

Web Forms and Windows Forms were both relevant for over a decade. For front end tech, that's pretty good.

The Windows GUI tools definitely seem to be struggling. Developing native desktop apps is much rarer these days, so all the attempts to create a single toolkit for multiple form factors makes some sense. But that is actually really hard to do, and Microsoft is starting from behind when it comes to mobile frameworks.

FWIW, the last time I developed a native desktop app was WPF. I tried again recently, but my general takeaway was that you need full Visual Studio still to make it work.

The worst part, is that at least in public like community channels and tickets, they don't seem to get the point that this has burned lots of bridges with the Windows developer community.

To the point that many might still use Windows, but not necessarly Microsoft frameworks.

I am forced to do WPF as part of my day job, but come from 10+ years of Qt and other UI frameworks. I loathe WPF. It feels overengineered and undercooked at the same time. It feels inelegant. It oozes that it was built by people who would never have to use it themselves, with the attitude 'yeah of course I can make one of those, how hard could it be??'. The built-in hbox/vbox are broken, which is inexcusable as those are the bread & butter of any UI. The way margins and borders is handled is horrendous. The way you set up styling/theming/defaults is horrendous. The way the docking layout is designed is ugly - why is the center widget a special case?? The way the grid layout is implemented is demented. The way the default datagrid works is demented. I have two or more tips for anyone who wants to design a UI framework:

(1) Try how a default OK/Cancel WITH LAYOUT can be expressed in your idiom. If it looks ugly and convoluted, fix your design until you don't have that problem. (2) Try how a 'tools on the sides, resizable work area in the middle' works in your idiom. If it sucks, see (1). (3) Check how margins and borders are controlled and defined in your idiom. If it requires repeating '10px' 480 places all over your source, see (1). (4) Check if evenly spacing/sizing a bunch of similar components requires special handling for first or last element, again, see(1). WPF fails all of these, and several more.

Yeah this. It's horrible. We have one which was built ages ago. It falls to bits on high DPI displays suddenly as of Windows 11. No one knows why, even at Microsoft. It's being replaced with some pile of shit in Electron instead.

Why would you even want to write an immediate mode GUI in XNA?

The point being the developer burnout regarding GUI frameworks out of Redmond, if XNA can be used for it or not, is besides the point.

We're not burned out, we're just suspicious and conservative based on our years of experience of having the rug pulled out.

On my book that is relatively the same, as each of them comes with some learning cost, and related ramp on efforts, only to be dropped a couple of years later, without any respect for the developers, see .NET Native and C++/CX deprecation as one example.

I'm strictly speaking of web FE.

Sure, since my list wasn't exaustive.

Those of us that had a go at ASP, ASP.NET, ATLServer, ActiveX, Silverlight, WebForms, AJAX Control Toolkit, WebAPI, WebAPI 2, MVC, Core MVC, Razor Pages.

If you group it like that, then there is a whole graveyard of Node and JS technologies that have died along the way, too. Ember.js, AngularJS, Knockout.js, Backbone.js, etc. Waaaaay more than Microsoft's go at it.

I'm not even sure why you're counting WebAPI in there since it's for writing REST APIs.

I guess because writing Web FE with a .NET backend is something that many .NET developers happen to do, via WebAPI exactly.

The graveyard of Node and JS technologies is orthogonal to the current burnout feeling in many Windows circles regarding Microsoft technologies.

To the point that, as I already mentioned a few times, I happened to do .NET Framework to something else ports, instead of the more rational migration to modern .NET.

You see the same in long time well known Microsoft partners like Sitecore, moving away from .NET.

Feels like moving goalposts here.

Technologies change all the time in every stack; flavors come and go.

By the standard of the web JS ecosystem, .NET has been relatively stable.

My goalposts are still the same, Microsoft FE frameworks since the dawn of time, Web and native, and their continuous replacements, when the team doesn't meet whatever KPIs.

I don't care what others do.

It is like kids on the kindergarten playground, arguing for who behaves better.

Porting MVC to MVC core was not very complicated. ASP.NET Core, MVC Core, Razor Pages are all relevant and in use today. And all of them are using same rendering language (Razor), same language Blazor is using. It's not like your knowledge becomes obsolete when you move from one framework to another.

Same thing with most of Windows GUI frameworks MS built. They all use same rendering language/interface (xaml).

The very fact that some code changes are required, regardless of how little, is a friction point.

Doesn't matter how long they have been supported.

If by "They all use same rendering language/interface (xaml)." you mean a XML based file format to describe the GUI layout, you are right.

If on the other hand you mean a GUI description language that is compatible with zero code changes, then not really.

Reply on news.ycombinator.com