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.
How does Hydraulic Conveyor improve the distribution of cross-platform JavaFX applications, especially compared to the standard jlink/jpackage workflow?
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.
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!
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.
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.
> 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.
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.)
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.
It doesn't get much love on HN but it's there, it works, I've used it to ship real apps.