[ejiblabahaba]

Presumably because, much like the half-dozen other flexible cross-platform frameworks Microsoft and friends have gotten one-third of the way to a viable product before abandoning to chase the next shiny thing, it's riddled with bugs, about ten years behind the documentation of a more usable framework from the 2010s, and has basically zero third party support from the likes of Infragistics and SyncFusion.

UWP left behind a shockingly large number of perfectly serviceable pieces of WPF, at a time when the emergent UI experience on Windows 8 was being written off by almost everyone, Windows Phone was DoA, and people were starting to realize they could just write web pages and run GUIs in the browser instead. It's been a long, bumpy, downhill ride ever since. The fact that Electron.NET and Blazor is a serious UI suggestion from Microsoft these days should tell you everything you need to know.

I'm sure with enough effort it's usable and maybe even nice in some ways. I did some proof-of-concept work with it two years ago and got maybe 50% of the way to where I wanted to be in 8 hours, but got stuck at styling issues for which there was limited documentation. In the end, I'm more confident these days in WPF + Avalonia if I really need cross-platform - even if there's comparable bugs and limited documentation, there's at least some momentum still behind the project. UWP, all three busted half-finished versions of WinUI, MAUI, Blazor + Webview2, Blazor + Electron.NET... even Avalonia, thanks to the weird decision to change styles to behave more like CSS... it all still struggles to be as usable as WPF.

[dtquad]

Why do people always complain about the lack of mature cross platform desktop GUI development options for .Net? Most other programming languages and ecosystems don't even have viable options for desktop GUI development. When was the last time a new version of Elixir, Ruby, Go or Rust was released and top comment was complaining about the state of desktop GUI development options?

The whole industry is unfortunately moving towards web interfaces being the default. That is unfortunate but it is an industry wide trend.

[vunderba]

Elixir, Ruby, Go?? Maybe because the C/C++ and JavaScript/Typescript user bases are about 10000 times larger and we have relatively robust cross platform UI solutions for both in the forms of QT and Electron. C# is a weird outlier for having a very large user base but very few decent cross-platform GUI support.

[miki123211]

Python's user base is pretty large, it's the most popular programming language by some metrics, and yet the situation there still sucks.

You can use tkinter, which doesn't work well with native platform features and forces you to rewrite your app from scratch in something else when you finally need to do accessibility. QT is free for noncommercial use only. WX kinda sorta works, but WX apps on Mac feel like they were on Windows, and the naming conventions are extremely unpythonic. Toga looks like a nice option, but it's still pretty young, I'm not sure how far I'd trust it.

[michaelsbradley]

> QT is free for noncommercial use only.

How so? It’s LGPL.

[actionfromafar]

LGPL is very problematic when distributing for things like iOS, what with the user re-linking requirements. On Windows, Mac and Linux it can be quite easy to solve.

[aryonoco]

There are, and have never been any issues distributing LGPL applications on iOS. You might be confusing it with AGPL?

[Kwpolska]

C#'s user base was historically tied to Windows, and there are many C# GUI frameworks for Windows.

[orphea]

I, being a .NET developer since v1.1, won't touch most of them.

WPF, a framework from 2006, and Avalonia, a 3rd party framework, are the only two worth considering.

[memsom]

Six months ago I would have argued with you, but currently doing a MAUI transition from a Xamarin Forms app, and you are very right.

I wish Avalonia UI's mobile solution had had Navigation sorted a year ago when I proposed that we needed to do something with the XF EOL announcement. I had a POC with it working well enough, but sadly it was "too much work" to migrate the rest of the app. Now with MAUI we have realised that we are probably doing just as much work anyway, and it is seriously half baked as an ecosystem.

[irq-1]

Thank you for this comment. Trying to sort through the mess of GUI frameworks for .NET and other languages is difficult.

[TheCleric]

Exactly this. Anecdata, but the vast majority of the C# developers I know not only don't use anything but Windows, they are actively HOSTILE to non-Windows systems. Many of them view non-Windows systems as either toys ("MacOS is for graphic designers") or too spartan to be worth their time ("Linux is for sys admins").

As well with the rise of new tech/stacks that has displaced C# in a few places, the people who stay in C# tend to bristle at other OSes as that's what the people who are using the other techs use (and us vs. them type attitude).

So in the grand scheme of things, it's unsurprising that this happens.

[aryonoco]

I think this is an outdated view. I run a dev shop which develops applications in . Net + Angular. We have always given devs freedom to buy whatever laptop they want and put whatever OS they want on it, as long as they can work with everyone else. 5 or 6 years ago, we had 1 person using Ubuntu, another person using Mac, and everyone else used windows. Right now, roughly 40% are on windows, 30% develop on Mac and 30% develop on Linux (Linux has recent grown at the expense of Mac actually).

Our production environment where all applications are run is based on Debian (though we test on Windows Server as well) in a kubernetes cluster, running in Azure.

C# is decent language for writing line of business application logic, and these days .Net is a completely cross platform, open source framework.

I remember using a bunch of C#/Mono applications (F Spot, Banshee, etc, they were all the rage once) on my Linux desktop over 20 years ago.

[neonsunset]

I've worked with a team that used Rider + macOS combo in the past and have friends who had a similar experience. There are those who choose to use Neovim + csharp-ls instead, or any other combination besides the historical Windows + Visual Studio.

Keep in mind that .NET has "inherited" a huge ecosystem and developer community that existed and still exists within the confines of .NET Framework. It roughly splits into two groups - the one that is moving or has moved on to .NET and left the legacy in the past and the one that harms the ecosystem by refusing to do so. Luckily, the former is in the minority compared to the latter especially as the time goes by.

It is also helped by new generations of developers who came into working with the tech after .NET Core and .NET became the mainstay or developers who moved on to .NET from other languages and ecosystems.

[alternatex]

You're correct about that sentiment from .NET developers historically but things have changed. At Skype, a company that's been under MS for a decade, more than half the devs use Macs.

[brungarc]

C# is still my favorite language and I haven't used Windows since 2017. JetBrains Rider is my IDE of choice on a Mac. It was pretty rough during the early releases of it, but for years now it's working well enough. Also .NET Core 1.0, 1.1 and 2.0 was a ride. project.json anyone?

Fastforward to .NET 5, 6, 7, 8.. it's just doing great x-plat life and innovation

[TheCleric]

I'm sure that is true. I just know the C# developers I work with now and recently fall into the camp I mention.

[kcartlidge]

Maybe we have different circles.

I'm one amongst many using Net on other systems (Mac & Linux) as well as Windows. Larger enterprises which use VS on Windows often deploy the results onto Linux servers too (especially with microservices), which is hardly being hostile.

Though to address the issue of GUIs in Net-land, I've given up as nothing since WinForms (and possibly WPF) has lasted. They are 'supported' in many cases, but it always feels half-hearted or half-dead.

[DeathArrow]

> C# is a weird outlier for having a very large user base but very few decent cross-platform GUI support.

MAUI is pretty decent.

[zerkten]

That's not what people say when the daily poster in r/dotnet asks what framework they should use for a GUI app.

[datavirtue]

MAUI is not ready. I started a Greenfield project this year. Having tried a serious project in Xamarin Forms, I reached for WPF. The app is almost ready and the speed at which I was able to get stuff working (and beautifully so) has resulted in our company being able to win new business. WPF has no limits. It just works. Tons of community support.

My hope is that MAUI gets to WPF level soon. Refactoring away from WPF to MAUI should be almost trivial, if desired.

[memsom]

Okay - this is not going to happen. WPF lets you do really complicated binding tricks that XF was just not capable of. Maui is just an evolution of XF, but so far I think iit is a step back from what we had before. We have some stuff working, but it was painful to make it work and some of the WPF tricks we used in XF with binding are broken in Maui so far. I'm sure we will fix most of them, but it feels like we will just refactor a lot of it away to simple properties rather than complicated multitrigger bindings. I echo "Maui is not ready".

[ok123456]

Microsoft had remarkable native frameworks that they just decided to ditch. Many Forms and WPF applications still work and run entire businesses, but because of Microsoft's unnecessary churn, they are stuck with the legacy .Net Framework.

Yes. Many FOSS ecosystems don't even have adequate GUIs, but they never had them. Microsoft had them but then lost them. Every "modern" replacement requires you to import a whole browser in some form or another with all the baggage that comes with it, both in terms of development, runtime and security.

[ClickedUp]

> they are stuck with the legacy .Net Framework.

I develop WinForms applications at work and we use .NET Framework by choice, to aim for long-term stability and not the 'new thing'. We are not stuck we're loose. It's important to understand that MS Windows will never be able to get rid of the ability to run .NET Framework apps. Also, even though the new .NET supports WinForms, it's not a 1 : 1 port yet and we've done extensive testing on this. Not using .NET Framework would mean degrading the performance of the app (~30%). Try it out for yourself with a controls heavy application. I'm talking 100+ controls on a single app with real-time data fed through it. We use 3rd-party WinForms controls that's been in development for over 15 years. The GUI is modern and the performance excellent.

Words like 'legacy', in our case, means better stability and higher performance, and frankly, we neither trust nor care about Microsoft's opinion.

That said, I can understand that the new .NET is useful and an upgrade for those who wants cross-platform support among other things.

[ok123456]

If you were to fire up your IDE and start a new greenfield C# project, would .Net Framework be your first choice?

[ClickedUp]

Absolutely. Main reasons being 1) that we don't need any of the new features modern .NET can offer and 2) we specialize in mission critical, high performance apps

For example, recently a customer wanted a security solution, a filesystem journaling application, powered by a low-level FS kernel driver (C/C++) together with a managed .NET assembly to interop with our unmanaged driver DLL. Running on the highest altitude - on top of the driver stack - means handling, filtering, and intercepting a huge amount of filesystem requests before it reaches other system components. Therefore, performance is key.

In that scenario, using modern .NET we experienced nonstop deadlocks which froze the whole system. .NET Framework had no issues keeping up.

I can also think of other examples e.g. issues working with custom virtual filesystems.

So yes, NET Framework would be my first choice for standard Windows-only desktop applications.

[neonsunset]

In what scenarios can you make .NET Framework perform faster than .NET 8? The expected performance difference is 2 to 10x in favor of the latter. It’s not even a choice. If you can reproduce the issue, please consider submitting it to dotnet/runtime rather than choosing obsolete target.

[neonsunset]

That would be an exceedingly poor choice. Libraries have even started to drop NS2.0 target as it is too limiting or requires if-defs and extra maintenance effort for obsolete targets.

[alternatex]

Both Win Forms and WPF work with .NET 6+ though.

[ok123456]

Lots of asterixes and special cases. It's not just a drop-in replacement.

[ejiblabahaba]

If Microsoft said "Windows-only, good luck with cross platform," I'd accept it and move on. It's their prerogative to spend their resources enhancing their own platform.

Instead, I've been told a half-dozen times that there's a new cross-platfotm GUI option, and had I bought into any such endeavor, I would have been rugpulled by sudden deprecation or loss of focus. I think people who did buy into any cross-platfotm GUI frameworks from Microsoft in the last ten years are justifiably feeling like they've been hung out to dry, sometimes multiple times.

I don't complain about Elixir, Ruby, Go, or Rust GUI development because I don't try to use these languages for GUI development, because their core leadership and marketing doesn't promote this as one of the primary use cases. C#, and the .NET ecosystem at large, are THE premier Windows GUI development tools. When their marketing pivots to cross-platform GUI development, and they rugpull you a half-dozen times in a decade with half-finished and baffling experiments, it kinda smarts.

Most people developing desktop apps are probably okay with switching to web-based options, including potentially running their own standalone rendering executable on top of a web view or chromium instance. But there's a significant minority that are building desktop apps because they want better performance and native visual integration/theming, who don't benefit from browser process isolation and the hairy JS event loop situation, who don't want to serialize every user action in the GUI, who saw what XAML set out to accomplish (GUI style templates that convert to framework code that could equally be hand-written, modified, or extended) and ran marathons with it. Maybe this will get better with WASM improvements in the next few years, but it doesn't change that the approach to GUI design is fundamentally different, and in a lot of ways needlessly harder, when you have to pretend your GUI isn't all running on the same machine.

[wiseowise]

> When was the last time a new version of Elixir, Ruby, Go or Rust was released and top comment was complaining about the state of desktop GUI development options?

Because no one in their right mind would write anything GUI related in those languages.

[celdon25]

That doesn’t really answer the question though.

[pjc50]

.. because there isn't a framework!

[wiseowise]

…and they’re okay with it, because historically GUIs are written in platform native languages.

[ozim]

There are also people complaining that Electron is slow and bloated - but in reality there is no alternative for open cross platform GUI.

[mike_hearn]

Sure there is. You can use JavaFX from any language that runs on the JVM (so that includes Python) and it's been steadily matured over more than a decade. It's maintained by a mix of corporate and community developers, and you can buy support from multiple vendors.

It doesn't get much love on HN but it's there, it works, I've used it to ship real apps.

[obdev]

How does Hydraulic Conveyor improve the distribution of cross-platform JavaFX applications, especially compared to the standard jlink/jpackage workflow?

[mike_hearn]

Our website https://hydraulic.dev/ covers the most important points but compared to jlink/jpackage:

• Delta software updates without code changes. On Windows apps update in the background even when not running.

• It can do web-style synchronous updates on app launch.

• Can build for every platform from any platform. Linux cloud CI workers can be 10x cheaper than Mac workers, so this feature can save you a lot of money!

• Lots of usability work and features around code signing/notarization. It can do signing without MS/Apple tools and it knows how to use cloud signing services, remote HSMs, local HSMs, the Mac keychain (protected from other apps), custom enterprise signing services that can only be accessed via scripts, it can check for many kinds of mistakes (a particular weakness of vendor tools), it will help you buy certificates by generating CSRs for you.

• Generates a download HTML page that detects your user's OS and CPU to give them a big green download button, it can upload all the artifacts to S3 or GitHub Pages/Releases or any other server via SFTP. It renders icons for you, etc.

• Deployment by Windows IT is easy and installation doesn't require users to have admin rights on their system.

• It can publish to the MS Store which lets you avoid needing to buy signing certificates for a one off $19 fee.

• It comes with commercial support. With other tools if you get stuck you're on your own.

----

All the above works for Electron and native apps too. For JVM users specifically:

• It figures out which JDK modules you need using jdeps and bundles a minimized JDK.

• It provides a Gradle plugin that can read config out from your build configuration automatically.

• Easily bundle JCEF if you want an embedded Chromium.

• (soon) It will provide an API that lets you check for updates and trigger them manually. This is done, it just needs to be fully documented and published to Maven Central.

• It has way better support for native code than jpackage. It will dig through your JARs to find native libraries that don't match the target machine and delete them, it will sign them in-place, it can extract them ahead of time and then set up your system properties to make them be loaded from the right places and so on.

• It can bundle custom TLS root certificates into your JVM trust store. That's especially useful for enterprise settings.

That's not even a complete list by any means. Conveyor is packaged with itself and is a JVM app written mostly in Kotlin, so the above features get dogfooded by us.

I wrote this tool partly because I really wanted to close the gap between web and desktop dev, to let developers have more freedom around frameworks and languages than they do today. It's not right for everyone but if you aren't hog-tied to the browser then the pain of distribution is really removed by this thing, and that lets you focus on building your app.

[obdev]

Thank you. Your software has indeed a decent feature set. I will definitely try it out as soon as possible. I wish you the best of luck with the business!

[oblio]

Can you use it on Android/iOS?

[mike_hearn]

Actually, yes:

https://gluonhq.com/products/mobile/

Although it's not a mapping over the native UI toolkits so it has the same issues as Flutter etc.

[ozim]

No it is not, it is just like QT, damn shady all over the page Creative Commons where framework code is not even on github but their docs and landing page is.

Electron is just using HTML/CSS/Javascript that are open, Electron alone is MIT licensed and there are no tricks like "2 developers - well you have to buy $900 a year license".

I don't expect everything to be free as in beer but JavaFX looks shady. I would never build my business on their platform, would rather go with QT.

[vips7L]

What are you talking about? It’s GPL v2 with classpath exception.

https://github.com/openjdk/jfx

[ozim]

It is owned by for profit company.

[lelanthran]

> There are also people complaining that Electron is slow and bloated - but in reality there is no alternative for open cross platform GUI.

What's wrong with Qt? There's also Lazarus (https://www.lazarus-ide.org/) with almost transparent interoperability with C.

They may not be perfect, but in light of their existence, it's hard to argue that there is no real open and cross-platform GUI.

If you relax your definition of "open" a little bit, there's still things like flutter.

[ozim]

HTML and CSS are open standards that are governed by W3C and JavaScript by Ecma. Electron is MIT licensed and OpenJs foundation seem like it is not going to do rug pull from under your feet.

- I don't mind GPL or LGPL and I don't believe everything should be free as in beer -

Still QT company pushy marketing is making it hard to just build stuff on their free offering is a huge turn down, to do a build I need to login to an account, crazy (well the same for Apple, but not the case for javascript/html/css).

Last but not least Lazarus/QT - how long will it take and how much will it cost to build a team of 5 developers to build and maintain product on these. When I put an ad for JS dev I am pretty much flooded, for QT/Lazarus I never posted an ad, but my gut feeling is I will be lucky to get any CV in 3 months.

[lelanthran]

> When I put an ad for JS dev I am pretty much flooded, for QT/Lazarus I never posted an ad, but my gut feeling is I will be lucky to get any CV in 3 months.

Things like staffing for specific skills is a different issue.

The comment I responded to did not say "There are simply no other Js+Html+Css browser-based alternative to electron".

If they did I would not have responded, because then they would be correct: there are few browser-based alternatives to Electron.

They said that there are no open alternatives, which is what I did respond to.

Because, to be honest, if you're in a company and a team, you are all probably going to use the most popular tech (whether electron or something else depending on the platform).

For all other types of developers, stack popularity may not be a factor at all. From the question asked, there was no context around the type of development or team.

For example, I'm an independent developer, writing custom software. It's faster for me to deliver a cross-platform desktop GUI in Lazarus than in Electron (the delivery speed of the GUI is not even in the same order of magnitude for the type of projects a solo developer can do).

OTOH, if the client needs the type of fancy CSS animation, theming, etc that only a browser can do, then you have no choice but to use the browser.

[CRConrad]

Show me where the ad is, you'll have my CV in a trice.

[javajosh]

Java still ships and supports Swing/AWT - which is still what most desktop applications use to render a UI, even IntelliJ. I haven't worked with it in a very long time, but there used to be tooling support for alternative platforms like web browsers. Angular feels a bit like a spiritual successor to Swing.

These days I feel like React Native is your best bet for open cross-platform GUI. Its a nifty idea: your app still runs in JavaScript but the rendering layer is replaced with something platform specific. There are some big warts (performance is NOT uniform) but its probably the best way for someone with frontend chops to leverage their skills for other platforms at this point. (Although for desktop Electron might actually be just as good or better, too.)

[vips7L]

I tried to use swing a year or so ago. It wasn’t a great time. I’d probably go with JavaFX or compose multi platform if I did it again.

[hasbot]

Well sure it takes a bit of time and study to learn it but it's a totally viable cross-platform UI toolkit.

[vips7L]

Oh I agree it’s viable! It just wasn’t pleasurable to work in. I’m looking forward to trying JavaFX when the time comes :)

[jmaker]

Other than the already mentioned JavaFX which now goes by OpenFX due to Oracle’s TM license changes, there’s also

- Swing with FlatLaf look and feel, just exactly like the JetBrains IDEs, there’s a kitchen sink app JAR you can download from FlatLaf, there’s some nice extensions for the layout too, not for mobile though as far as I’m aware

- Vaadin and their 2nd framework whose name I forget, directly integrated with Spring and Quarkus

- Kotlin Multiplatform and Jetpack Compose Multiplatform, a very promising and awesome tech, works fine for my requirements, would be happy for them taking the lead, I love the syntax and their compositional semantics, similar to SwiftUI

- React Native worked great for me, can reuse some React.js stuff

- NativeScript, never tried

- Ionic Capacitor, never tried

I think it might make sense to watch a couple YouTube live coding showcase sessions with the respective developers.

Avalonia also has a kitchen sink app btw. And I really like Uno’s calculator app, though I recall having had a weird bug once in the calculation logic.

And as for Blazor, there’s always been JSF which have long had great UI components. To me Blazor is about replicating JSF.

Yeah, well, I wish there were just 1-2 really good choices to be made, but there’s a myriad of caveats in each framework, more so in some of them. Well, Qt comes closest I think.

[password4321]

https://fyne.io/ for golang (no accessibility yet).

[pjmlp]

As someone that went from a strong advocate of UWP, into a strong critic of UWP.

They really messed up WinRT.

Although not perfect at Windows 8 launch, its evolution until Project Reunion came to be had potential.

It was .NET as it should have been from day one, a proper developer friendly wrapper on top of COM, and Microsoft had finally provided something comparable to C++ Builder for the C++ crowd.

Instead they never delivered feature parity to WPF, killed .NET Native, C++/CX, the designer, and then started from scratch on Win32 side, while expecting everyone jump to put up with them, and follow for the ride.

I consider that an ultimately lack of respect for paying customers.

[zerkten]

C++ Builder fan from my early career. Did they add designer/XAML support for C++ and then kill it? Do you have to do C++ dev with code only now?

[billfruit]

It's become a morass. Did they ever get back to atleast where Xamarin was like 5 years ago? Why exactly is Microsoft doing this, it all sounds very shambolic, the approach they chose and the outcomes.

I think this space needs some stability, and Microsoft seems keen on inducing volatility for some reason.

[chubs]

Here’s the reason: the LPA cycle, unfortunately. https://twitter.com/buccocapital/status/1576909546164928513

[m_fayer]

I think Avalonia is finally emerging as a partial way out of the morass, a qt-for.net. And why? Because it’s from the ground up, and not from Microsoft.

[dgellow]

As someone who seriously tried pretty much all the mentioned tools to develop modern windows applications I feel this comment sums up everything perfectly. WPF is still the most usable solution.

I really wanted to like UWP, then WinUI, but for anything that isn’t a simple demo project you end up spending all your time fighting the framework and facing broken/unpolished parts that make you feel pain and frustration.

Avalonia isn’t perfect and has some rough edges but I would still consider it for cross platform support over anything else.

[neonsunset]

This project is not related to UWP.

Is there actionable feedback you could provide to it?

[ejiblabahaba]

For Uno specifically: I do like the attempt to build out a WASM target, it looks usable. Uno looks to be in a lot better state internally than even two years ago, which is promising - that's one thing I can't get out of either WPF or Avalonia.

Key things that need to improve: - Documentation appears to have gotten better in the last few years, but still many sparse or underdocumented corners. This is my biggest reservation today. - When I last used it (a few years ago), a lot of things weren't fully implemented - maybe this has changed? But it added a lot of friction.

[datavirtue]

WPF is a joy.