The whole industry is unfortunately moving towards web interfaces being the default. That is unfortunate but it is an industry wide trend.
The whole industry is unfortunately moving towards web interfaces being the default. That is unfortunate but it is an industry wide trend.
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.
How so? It’s LGPL.
WPF, a framework from 2006, and Avalonia, a 3rd party framework, are the only two worth considering.
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.
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.
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.
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.
Fastforward to .NET 5, 6, 7, 8.. it's just doing great x-plat life and innovation
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.
MAUI is pretty decent.
My hope is that MAUI gets to WPF level soon. Refactoring away from WPF to MAUI should be almost trivial, if desired.
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.
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.
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.
We were told to benchmark the performance on several computers using different hardware. In example 1 we calculated ~30% worse performance (worst case scenario!). In example 2 we had micro stuttering and system wide freeze (requiring reboot).
Again, in example 2, are we supposed to accept our customer computer freezing under load? In a high security, sensitive environment? You must be joking! Instead we delivered a solid product which do not freeze the system and we got great feedback. What's considered 'obsolete' is irrelevant to us. The word means nothing. Our benchmarks are of the highest importance.
Let me try again on monday though, I can reproduce the results then. Your claim piqued my curiosity, but I think you underestimate the specific requirements in which we work. Perhaps they've fixed something since last time we tried. I'm certainly willing to try again.
Like using the apis that fully utilize spans. Also, I have the feeling (but nothing tangible) that old .net and .net core do behave differently wrt async stuff too.
I'm actually curious myself after this discussion. I didn't port it, my coworker did it and I'd have to ask him. I did take part in the benchmark though and watched all the deadlocks happening.
Found this old screenshot of our internal FS driver debugging tool - to give you an idea of what I mean by needing high performance: https://postimg.cc/mc6YQFbC
24,654 filesystem events in C:\Windows\ in just 1 minute and 30 seconds on idle. 814 read operations (36,7MB) + 948 write operations (66,9MB). Now imagine this system-wide (not just the Windows dir) under heavier load. This is where modern .NET could not keep up leading to the aforementioned deadlocks.
Sorry that I can't provide more specific info at this time. I can find out more on Monday.
There can be latency differences in edge cases of interaction between threadpool used by specific version and Overlapped IO on Windows, but that's likely about all there can be.
It's important to note that .NET Core 3.1 -> .NET 5 -> 6 -> 7 -> 8 is a huge difference in compiler and corelib internals (less so in GC, with major steps in 6, 7 and 8 in regards to regions and now DATAS), so an issue that could have existed in one of the previous versions is likely to be fixed by now.
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.
Because no one in their right mind would write anything GUI related in those languages.
It doesn't get much love on HN but it's there, it works, I've used it to ship real apps.
• 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.
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.
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.
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.
- 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.
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.
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.)
FX is not flushed out. Though it does have some data binding, which is all manual in Swing.
- 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.