6 ms·
Why do people always complain about the lack of mature cross platform desktop GUI development options for .Net? Most other programming languages and ecosystems
by dtquad 2y ago
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 2y agoElixir, 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.
- Kwpolska 2y agoC#'s user base was historically tied to Windows, and there are many C# GUI frameworks for Windows.
- orphea 2y agoI, 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.
- irq-1 2y agoThank you for this comment. Trying to sort through the mess of GUI frameworks for .NET and other languages is difficult.
- memsom 2y agoSix 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.
- TheCleric 2y agoExactly 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.
- alternatex 2y agoYou'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.
- TheCleric 2y agoI'm sure that is true. I just know the C# developers I work with now and recently fall into the camp I mention.
- brungarc 2y agoC# 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
- kcartlidge 2y agoMaybe 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.
- miki123211 2y agoPython'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 2y ago> QT is free for noncommercial use only. How so? It’s LGPL.
- actionfromafar 2y agoLGPL 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 2y agoThere are, and have never been any issues distributing LGPL applications on iOS. You might be confusing it with AGPL?
- actionfromafar 2y agoNo
- DeathArrow 2y ago> 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 2y agoThat's not what people say when the daily poster in r/dotnet asks what framework they should use for a GUI app.
- datavirtue 2y agoMAUI 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 2y agoOkay - 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".
- ozim 2y agoThere are also people complaining that Electron is slow and bloated - but in reality there is no alternative for open cross platform GUI.
- lelanthran 2y ago> 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/ 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 2y agoHTML 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.
- CRConrad 2y agoShow me where the ad is, you'll have my CV in a trice.
- lelanthran 2y ago> 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.
- wiseowise 2y ago> 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.
- ok123456 2y agoMicrosoft 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.
- alternatex 2y agoBoth Win Forms and WPF work with .NET 6+ though.
- ok123456 2y agoLots of asterixes and special cases. It's not just a drop-in replacement.
- ClickedUp 2y ago> 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 2y ago
- ejiblabahaba 2y agoIf 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.