I find JavaScript and its ecosystem atrocious in many ways, but several browser tabs and Electron/WebView apps running just fine on an early 2010s PC I employ.
I don't see an XAML based C# .NET desktop app performing marginally better than an equivalent well-written Electron app either. In both cases, GPU takes care of the graphics rendering, JIT and GC do what they do, and you might be able to offload the pain points over to C++ through WebAssembly and P/Invoke or COM objects.
> but several browser tabs and Electron/WebView apps running just fine on an early 2010s PC I employ.
"My car runs fine with the five anvils in the trunk" isn't the argument you're looking for.
Performance isn't the only problem with Electron either. Electron apps fail to integrate with native system components both from look and feel and accessibility aspects like incorrect zoom levels on HiDPI displays etc. They are even worse than browser tabs in that manner.
> I don't see an XAML based C# .NET desktop app performing marginally better than an equivalent well-written Electron app either
RAM usage would be at least an order of magnitude different. Nothing to do with how well-written it is either. It's inevitable.
Well, we're in the anvil business. Unless someone pulls the cart himself using C++ and MFC, similar amounts of oat will be consumed to get to our destination. Based on my empirical observations, WinUI 3 with C# eats memory like a horse. I'm willing to stand corrected with more data.
Platform integrity and accessibility are the real concerns with Electron. What is the solution, though? Does anyone still have time and patience for the byproducts of WinDev vs DevDiv power plays, even at Microsoft?
Package size advantage of Wails, Tauri and likes; is it worth giving up Chromium's integrity across platforms, thus dealing with Safari/WKWebView and WebKitGTK anomalies?
Tauri has a big community. Flutter has a big community. Do you believe Tauri can survive without a direct corporate backing, while Flutter can't?
It's not a rhetoric question. I'm in need of a native application toolkit, and I gravitate towards Tauri for technical reasons. However, I'm not sure if the Tauri project has enough cash flow to sustain a durable alternative to Flutter, Qt, Avalonia, JavaFX, Compose Multiplatform, and likes.
JavaFX is a pretty dead project. Especially on mobile where it has zero users. It actually proves parents point, without Google flutter will be too big. Yes, there will be companies who will pick it up and compile it. That's hard, but doable. The problem is that there's a ton of moving parts. Testing alone is a huge task.
Some companies might pick it but then they would only test the use cases they need or a personal fork. It would also sink without the Google brand to back it.
Saw a tweet a few years back about how in China there was a lot of interest in cross-platform solutions. Both Alibaba and Tencent use Flutter in some capacity. It’s possible they might fork it and continue using it. Unfortunately, between that might being an internal-only project, and the seemingly siloed separation between Chinese development communities and the rest of the world, that might not help Flutter’s status, should Google end its patronage.
Yes, although that was quite recent, as Oracle was trying to breath new life into OpenFX, after it was taken outside of the JDK, keeping Swing the best option for those that don't want to deal with OpenFX distribution of native dependencies.
As far as I am aware, Project Mobile doesn't have much uptake, outside companies that are already working with Gluon.
Indeed, Johan Vos of Gluon is the leader of the Project Mobile.
Swing remains a decent GUI toolkit, but it still requires native dependencies for stuff like OS file dialogs and other platform APIs, audio/video codecs, hardware-accelerated graphics.
Swing ships with the JDK, so whatever native dependencies are required, application developers don't need to care about them, unless they are making use of jlink, and to this day many still prefer to push to some JRE being installed, than making use of jlink and jpackage.
Which is why alternative JDK distributions still offer JRE variants, while officially from Oracle's side one should either use plain JDK or jlink/jpackage.
There's Codename One, it's much better than anything available for Python etc. but since it's an independent OSS project from a small company it sadly never got the traction of flutter/react native.
> Do you believe Tauri can survive without a direct corporate backing, while Flutter can't?
Currently, I think tauri can survive yes. But I know much deeper the tauri community than flutter, where I’m just speculating as a bystander.
In fact, Tauri losing money would be much less bad than losing 1-3 of the core workhorses that are volunteers primarily afaik. This in fact is the biggest risk, imo. If any of them stop working it's gonna be really hard to recover, because they’re so autonomous and make sensible decisions.
But mostly flutter seems like a much more ambitious project, because they define UI and rely on Dart. Tauri and electron piggyback on browsers which imo is strategically and technically the only reasonable way to do it long term. They can almost exclusive focus on cross platform issues (which btw is an enormous undertaking on its own).
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!
1 app 1 jar. I beat Maven until I get a JAR-file that boots outside the development repo. Usually this involves unhooking the module system.
What kind of bugs are you encountering? I have some trouble with layouts being weird sometimes but it usually sorts itself out when I make them simpler.
I find JavaScript and its ecosystem atrocious in many ways, but several browser tabs and Electron/WebView apps running just fine on an early 2010s PC I employ.
I don't see an XAML based C# .NET desktop app performing marginally better than an equivalent well-written Electron app either. In both cases, GPU takes care of the graphics rendering, JIT and GC do what they do, and you might be able to offload the pain points over to C++ through WebAssembly and P/Invoke or COM objects.