Hacker News Reader

Comment by foepys | Hacker News Reader

WinForms and its Visual Studio designer are still broken, WPF is still riddled with bugs and was declared obsolete in ~2017 in favor of UWP, UWP is marked obsolete in favor of WinUI, and WinUI's OSS release was postponed just two days ago because it's not ready.

Microsoft is marketing .NET 6 as the replacement for .NET Framework but you still cannot properly do desktop UI with it. I honestly don't understand why they are pushing more and more features when they cannot complete the ones they started years ago. Not to mention that porting WinForms from .NET Framework to .NET 6 requires a rewrite for anything more complex than a Hello World.

View on HN

Couldn't agree more. Microsoft lost their minds on the UI / desktop app side - which was a core strength (historically).

WinForms was fine / great / amazing. 90% of business / line apps could be handled with it. I have no idea how / why it's taken them so long and they STILL have not gotten their replacement story straight for it and they regressed the designer in .NET.

Did they just lose their minds there? Hire a bunch of idiots caught up in fads instead of folks who've been around for a bit.

It honestly is mind blowing. By now they could have had a cross platform WinForms story or something. The new WinForms designer is so annoying at times. "Oh, we support winforms" - no you don't.

And pretty much the stuff after it has been garbage.

> Microsoft lost their minds on the UI / desktop app side - which was a core strength (historically).

Exactly, was a core strength. They saw the writing on the wall though, SaaS and cloud was where the money was and is at the moment, and that's where .NET now excels.

Easy, they did to .NET the same as IE.

When Sinosfky and his team, brought .NET ideas to COM via WinRT, which was kind of Ext-VOS revival anyway, I bet they fired everyone on Forms and WPF, or moved to other teams.

Otherwise how to justify they had to ramp up Forms and WPF teams again, and we have already seen several PMs take ownership of the projects since Core started.

UI component design is extremely difficult. It's at the intersection between UI design and API design, both difficult disciplines in themselves. It doesn't help that it has traditionally been mired in OO hype sauce.

> UI component design is extremely difficult

I don't see much difference between UIs of today and 20 years ago. Actually, I think UIs are nowadays less complex (more screen space available; and you have to worry less about CPU consumption). One would except that was enough time to figure out component design.

> I don't see much difference between UIs of today and 20 years ago. Actually, I think UIs are nowadays less complex (more screen space available; and you have to worry less about CPU consumption). One would except that was enough time to figure out component design.

Today, UI need to be responsive, because of all the different screen resolutions and formats and form factors. That wasn't really the case 20 years ago.

Yes, UI library design is hard because it a series of trade-offs one has to make when designing the API. Make the API too customizable and it's a horror to use with horrible performances, make the API to rigid and people will complain it's hard to customize. WinForm is far easier to use than WPF... except that WinForm makes creating custom components a pain. WPF is easy to customize... except that it performs worse than WinForm, this isn't even up to debate...

But also, all these moving parts are why a lot of developers chose to go with Web techs for their UI, for better or worse.

> Did they just lose their minds there? Hire a bunch of idiots caught up in fads instead of folks who've been around for a bit.

No, they just took the focus off the Windows UI.

They went cross-platform with .Net Core, which enables it to run in the cloud on Linux boxes. This was the focus.

I hope they come back around to a proper .Net WinForms designer under .Net Core, but for now the full framework can be run and will be supported. There are a massive number of WinForm applications in use. I was recently maintaining a massive 20-year-old .Net WinForms application, it still runs fine.

It is funny how much they have strived for one platform to rule them all when it would have been easier and cheaper just to maintain windows, web and mobile separately and kept the frameworks suited to their particular platform.

I actually think they could have gotten winforms x-platform by now if they'd tried. Or some kind of x-platform story if they wanted.

The endless other crap has just eaten dev time like crazy.

Would agree with you on Winforms, it's a pretty good GUI RAD development environment, and I wish they'd just stop trying to replace it with something 'better'.

WPF I found to be constantly irritating and produces weird looking GUI apps, but maybe others have a better experience.

The UI story on Windows is completely broken but that has been the case forever.

Has MS basically released anything sustainable on the UI side since MFC?

It feels like they’ve constantly provided a new new replacement every few years that replaced the new replacement from a few years ago since then.

That's definitely true but they did a good job supporting their tech once it was released.

My company has been using WinForms on .NET Framework for over 10 years now and it's working really, really well. Microsoft even added HiDPI support to it.

When Microsoft announced they wanted to bring WinForms to .NET Core 3, we were initially very happy as it meant we could switch to .NET Core. But then they did all kinds of shenanigans with it and completely rewrote the designer for .NET Core in Visual Studio, which is now riddled with bugs and crashes constantly. You cannot even load your own custom controls into it. I mean, you can, just get Microsoft to let you sign an NDA to get access to the APIs...

They had to rewrite the designer for .NET Core since the designer runs your own controls' code right during design time (pretty horrifying on one end, but also enables a fairly integrated experience with custom controls). Since Visual Studio is based on .NET Framework the designer had to move out of process, as the only alternative would have been no designer at all.

So that's a twenty-year old codebase, perhaps on both ends (Windows Forms Designer and Visual Studio alike) that now somehow has to be moved to different processes and different runtimes.

Perhaps you have more luck with JetBrains Rider, although from what I've seen they simply host the very same designer in pretty much the same way as Visual Studio and thus are unlikely to fare any better here.

The other option is the still-recommended workaround of keeping the .NET Framework project files around and do designer stuff with those. Also annoying, admittedly, but that's what I've been doing for now (well, for other reasons as well, as we sell a .NET UI component that still has to work in .NET Framework as well).

> My company has been using WinForms on .NET Framework for over 10 years now and it's working really, really well.

Despite WPF being preferred amongst developers, WinForms solves most use-cases well.

I’ve not really kept up with Microsoft UI developments but I’d be interested in seeing any cross-platform UI toolkits they develop now or in the future just as an alternative to gtk/qt

The problem is that many features in Forms like data binding or layouts, have bugs, which happen to be only fixed on WPF, because that was the new boy in town.

So when you move beyond VB6 style of applications, there are several head scratching moments.

Sadly this is their policy across the board. Even though things like dotnet core 3.1 is supposed to be LTS, when you report a bug, you are most likely to get the response, "we will only fix it in .Net 5" as if upgrading everything is a 5 minute exercise.

For a company who turns over an enormous amount of money and employs 10s of 1000s of people, you would have thought they could support these separate frameworks with dedicated teams of 10-20 reasonably high calibre devs.

No they didn't.

Take a look at what happened to silverlight or UWP.

You just happen to be working in the one tech they actually carried on supporting.

UWP is still supported, that is what WinUI is built on.

The problem is that they now seem to somehow carrying that flag forward on top of XAML Islands, with an endless list of bugs.

I had a lot of problems adding HiDPI support to a moderately complex WinForms application. It was a huge time sink.

> Has MS basically released anything sustainable on the UI side since MFC?

MFC is nothing more that a C++ GUI library wrapping the Windows Win32 GUI layer.

The problem with that Win32 GUI is it has not changed for several decades, which is why any application using that Windows GUI layer looks old and outdated on modern Windows.

Since Microsoft is not updating the Win32 GUI layer, it is basically obsolete.

However so many Windows applications still use that GUI layer and that then makes the Windows UI a complete mess.

MFC was kind of a weird beast in general. In some ways it was just a C++ GUI API for Win32, but it did have distinct traits and behaviors that have MFC apps a subtle feel that many found unappealing.

Win32 GUI supports theming, that's what Windows XP's Fisher Price UX was all about. "It looks outdated on modern platforms" is a non-issue and total BS.

WinForms was definitely very fun to code with when I used it around 10 years ago. MFC on the other hand was a real pain. Some strange thing came afterwards which I never understood why, but then I already moved into Backend/HTML/JS.

Is WinForms really something that is outdated? Or is this new thing one just their attempt at unifying OS and Mobile UIs? I think Windows 10 uses this new framework and I absolutely dislike what I see, specially the entire new configuration system Windows has, compared to Windows 7.

It's not easy to write good reflowing UI in WinForms. You have anchors, but they aren't enough for the more complex layouts. And you have actual layouts, but it's a real pain to set up anything non-trivial with them.

However, there's also WPF. Which is also kinda in the same spot in terms of support and future development, but it's a lot more modern and flexible compared to WinForms.

As for MFC, the main reason why it's such a pain is because it's a relatively thin abstraction layer over Win32, and it doesn't even try to hide most of that underlying complexity (or limitations)

Actually not even MFC was that good when it appeared into the scene.

Borland C++ and Delphi/Turbo Pascal frameworks have always been top notch, and Qt follows their way.

MFC was re-created too low level, because the C guys at Redmond wouldn't use it, the Afx prefix comes from that first attempt.

I do like Forms and WPF a lot, so I fail to see what is broken about them, other than the missing love from doubling down on WinRT since Windows 8.

Ironically, MFC is the best framework for doing C++ GUI on Microsoft stack.

With C++/CX they could have had a C++ Builder like experience, instead politics made C++/WinRT replace it, while whoever is in charge doesn't care about Visual Studio tooling.

So using C++/WinRT is akin to being back in Visual C++ 6 alongside ATL, editing IDL files with a Notepad like experience.

Is there a UI story that doesn't suck?

I made a GUI using cljfx - that's a react style wrapper around javafx

It was wonderful and runs an all desktops (and I guess theoretically mobile through Gluon). None of that Electron lag. There is a bit of a learning curve - esp if like me you've never done any react

Very Clojure-y, quite low coupling and very composeable

I'm mostly doing my UIs in Qt and I'm always happy, sure it's not perfect but it consistently allows me to do what I want in a cross-platform way with minimal effort (especially when I compare with the royal empirical pain that is webdev)

For windows what's your hello world workflow / stack. I've wanted to get into QT, but there seem to be a bunch of different flavors out there. I'm more a winforms guy then an HTML/XAML/CSS type person.

On Windows, there are two easy ways to get started: Qt Creator and the Qt Addin for Visual Studio. Qt Creator is easier, I think. Personally, I use Qt Widgets a lot and ignore Qml, because the later has seemingly much less powerful widgets out of the box.

I'll be honest I don't think that doing C++ on windows is a good idea. The language needs to do a lot of file access for includes, and on NTFS those are super slow, my builds on Linux are something like 1/3 of the time on windows (building the same software with the same commit of clang 12 and lld, same computer, same SSD).

But if you don't want to install a Linux partition, then just use aqt to install Qt: https://github.com/miurahr/aqtinstall

You want win64_msvc2019_64 as a platform.

Way too often I see everyone clicking on everything in the installer which amounts to a 30gb download, but for the immense majority of Qt apps you just want the core libs for your platform which is like a couple hundred megabytes (and even then in practice you're going to use only a small part of those unless you have uncommon needs such as serial port, modbus or NFC communication, XML parsing, ...)

> and on NTFS those are super slow

Usually it's less to do with NTFS and more to do with Windows Defender Real Time Protection, which murders build times because it synchronously scans files before letting applications open them.

You can disable on a per-folder basis, and it will change your quality of life drastically.

C++ builds are only bad when you use too many templates, which Chrome famously does. If you use MSVC you get some additional speedup as well because it tries to avoid disk IO.

I would say Qt on Windows is probably a worse idea than just using .NET as it ties into the OS. If you need cross platform and normally use Windows it's not a bad idea.

Chromium uses templates very sparingly. Working with this code day to day, most days you don't see a single template. What it does use a lot of is class inheritance, delegates upon delegates, AbstractFryingInterfaces and whatnot.

> C++ builds are only bad when you use too many templates,

if that was the case I would see the same build times when building the exact same project with the exact same compiler on Linux versus on Windows. Yet Linux is really much faster.

No, you're right, NTFS as implemented in the Windows kernel is very slow. But for most work it's decent enough if you have a properly set up build system. The issue for some large projects is the build system is not set up well.

Disable Windows Defender before your next build.

>The language needs to do a lot of file access for includes, and on NTFS those are super slow,

I'm not sure I'd blame NTFS as such - but you can massively improve build times by creating a precompiled header .pch include file in your projects.

I already use PCH but can't put everything in them either otherwise it becomes a negative

I don't think anybody is expecting perfection. Personal I just don't want so much needless churn, especially on the .Net side. WPF in particular seemed to offer so much promise but was abandoned at birth.

I now treat UI stuff from Microsoft the same way I treat services from Google, something to be avoided because it will probably be abandoned within a short period.

There's a major difference though: when Google abandons a service it is gone and you have to look for an alternative. When Microsoft 'abandons' WPF your 15 old application still builds and runs today and receives occasional updates like proper HDPI support.

That would be just about OK if it wasn't half baked in the first place.

I feel like right now flutter is about 1/10th the level of popularity it will eventually reach. It has a great story for UI from multiple angles (cross platform, developer experience, tooling etc).

It’s still very young v2 only came out a couple of months ago so it’s not entirely without issues at the moment but there are a LOT of apps that I think could easily use Flutter in production across all platforms today and that story is only getting better.

I've been using Xojo (https://xojo.com) for about 15 years now to make cross-platform GUI apps. The language is similar to VB6 but it's been constantly updated. No affiliation, just a happy customer.

The command line. (Hey, you said UI, not GUI.)

Or for all its faults on macOS, SwiftUI on the iPhone is pretty good.

And depending on your angle of view, depending on the kinds of UI you're attempting to make, you could argue that the UI story of HTML5 is able to not suck if you have the self-discipline to avoid the sucky things.

> The command line

I can think of no shortage of frustrating CLI experiences.

There is no perfect library that solves for all possible problems. Pros and cons and all that. I'm pleasantly happy with all modern UI frameworks across major OSes and HTML5 options. I have so many things to be thankful for complaining about.

Maybe, if you change your perspective. From buddhist teachings i learned that we react emotionally to the labels (our judgements) we attach to what we perceive, not realitty itself which just is.

MFC was sustainable?

Agree the UI story has been rough. .NET MAUI seems promising, yes?

Outside of JavaScript, what other (good) multi platform UI frameworks are out there? And I’m hesitant to call JS good, with the amount of slow, laggy, resource intensive apps I’ve come across.

FreePascal with Lazarus is fantastic. It is so dead simple to use, and mostly just works (e.g. coding up an app on windows, opening it on Linux and hit the compile button, and Done!)

Compared to most prominent JS platforms, WinForms or WPF are awesome. We just got used to the sheer complexity and dev cycle of HTML, CSS, JS and JS UI frameworks especially.

Not that I would not agree that the Windows UI space is a mess but it is rarely about the tech but the management of it.

Should be possible to write fast Electron apps with Svelte, Solid or maybe Imba no?

.NET MAUI seems promising unless you're a VB developer.

The writing has been on the wall for VB.Net for a long time now.

Only due to mismanagement and apathy by Microsoft. It could and should be as popular as Python is today.

Why not just learn C#? Same framework, tooling, target, libraries etc, just a different syntax.

I know C#, and I've worked in it. I prefer VB. (To be specific, beyond language differences, VB's app platform is inherently faster to work in, a lot of it is just built-in that take a lot of scaffolding to replicate in C#. You'd be surprised how much of VB isn't directly available to C# developers.)

What are you talking about? WPF is still supported and a viable way to implement UI components. Same for WinForms. UWP never replaced them. What they are doing with WinApp SDK and WinUI is to extract features that were packaged with UWP to make them available to any type of Windows application.

Xamarin is also still a thing, MAUI will be a thing in the future, Uno is another option, Avalon too. There is a lot of options for .Net GUI, most of them are mature and maintained.

While true in spirit, the GitHub and developer voice tickets kind of show the actual state of affairs, which kind of saddens me.

It feels like desktop teams are running into all possible solutions to see what sticks, instead of fixing what we had.

I would agree with your last sentence, that's a very Microsoft way to handle things: "Hey, look at all of this! You can implement your application USING YOUR FAVORITE TOOLS! Isn't that great that we give you the opportunity to evaluate 36 different framework to see which one is THE BEST for your UNIQUE situation?!".

It's a complete mess and the whole thing feels direction-less but I cannot agree that no good tool exist to implement GUI.

I'm still confused by their React Native for Windows. Very happy to see development in this area, React Native is a fantastic framework, but I cannot understand if it is a toy or something they actually want to commit too. Blazor Desktop is also really confusing and makes no sense IMHO.

Blazor Desktop makes a lot of sense to me. Basically: Blazor Server is getting pretty good and it’s easy to serve it up to a local webview so why not make that an officially supported use case?

Yes, I want to believe in MAUI but the current state and dev process are very concerning. I don't get a good feeling that theres a clear understanding of how Xamarin "failed" (which it had to at some level for it to be replaced) in order to avoid the same issues. I'm also really concerned how soon the cutover is supposed to be (with only 1 year of Xamarin support after) and the current state of MAUI.

"Azure, Azure, Azure!" is the new "Developers, Developers, Developers!". Microsoft is going to focus where the business growth is, and I'm guessing they don't see improving desktop development as a big money maker for them.

> Not to mention that porting WinForms from .NET Framework to .NET 6 requires a rewrite for anything more complex than a Hello World.

We sell a fairly complex custom control, both for Windows Forms and WPF. There were zero changes necessary for the migration to .NET Core 3 back then. We still build both .NET Framework and .NET Core assemblies from exactly the same source.

Depending on how many 3rd-party dependencies are used and what other weirdnesses one does in code there may well be projects that are impossible or really hard to convert. But overall my experience was that for a lot of applications there are few, if any, changes necessary.

Sign of the times. In the last 5 or so years working as a consultant for large corporates I can't recall ever having to work on new desktop app/features. Everything is moving to the web even for internal uses so I'm not surprised that desktop app dev frameworks are collateral damage somewhat.

Honestly, I don't know why anyone would want to write Windows desktop apps anymore. The browser is the ultimate UI platform and you can do incredible things with it that will work outside of Windows too.

A huge part of .NET's value proposition is that you can do things that aren't possible inside the browser sandbox, and it's nice to be able to build UIs on top of that.

I don't care if my UI ultimately gets rendered by a browser engine, but as things currently stand UIs that were relatively easy to build in WinForms/WPF/UWP are a bit of a pain with Blazor and friends.

(and yes, I'm aware of F# and SAFE but every time I try to get started with F# I run into too many tooling issues)

I'm definitely a fan of SAFE, but also it's not hard to discount just regular 'ole JS/TS talking to a .NET backend. There's an incredible array of ecosystem libraries and tools that are much more mature than Blazor.

Y'know, I've been building up my own "regular 'ole JS/TS talking to a .NET backend" solution lately: https://github.com/rgwood/MinimalWebView

It's nice and lightweight but the friction of .NET-JS interop is constant. Blazor Server (hosted in-proc and served up to WebView2) is the nicest solution I've found so far but I'm very open to other suggestions.

As far as UI in .NET in general goes they seem to be throwing stuff at the wall to see what sticks, and no one project seems to have a lot of resources dedicated to it. I imagine this is because it’s simply not a priority for the .NET team. Maybe it’s undervalued a bit, or maybe it’s making the best with the resources they have.

As I mentioned in another comments, I feel that they disbanded everyone as of Windows 8 and UWP, as many businesses did not follow along, they were forced to reboot Forms and WPF teams.

Then you now have Blazor trying to be everywhere, with Xamarin being redone as MAUI (you are expected to rewrite your Xamarin code).

So not so rosy for the time being.

For what it’s worth, WPF and WinUI are owned by the Windows team not .NET.

I suspect it’s less “not a priority” and more “building a good cross-platform UI framework is a colossal amount of work”.

Windows Forms and WPF both work with .NET 6. They only work on Windows right now though.

It's all about Azure now, which makes for an emphasis on server- side capabilities.

Reply on news.ycombinator.com