[PaulHoule]

Personally I like JavaFX.

I made something pretty complicated with tkinter and Python. It's not that hard to do but the result looks awful, it doesn't support many features people expect in 2022, and the documentation for using tk in Python is poor. You probably need to refer to the tcl/tk documentation and translate it in your head to apply to Python.

As much as people hate Electron, the rendering engine in a web browser is head and shoulders better than any other cross-platform system and I think it's a sane model for programming. The main trouble w/ Electron is that you have 30MB of runtime for any application, even if it something that could be coded in a 25k .EXE file based on Win32.

[invalidname]

JavaFX is terrible and I'm a Java fanboy. It isn't native looking so it doesn't satisfy the requirements outlined above. You can get a facsimile of "native" but at a lot of effort and for specific cases.

But the problem is the deployment story. It requires native libraries so you need to package it somehow. Ideally, one day GraalVM will support JavaFX. That day isn't here. So you need JavaPackager which is one of the more awful ways to deploy anything at scale.

It pains me to say it as a Java fan, but most people will be better off with Electron.

[kaba0]

There is no such thing as native, windows doesn’t even have a singular native look.

And as far as I know jpackage and the like should be able to package a javafx program just fine.

[invalidname]

There sure is "native look" for Windows and Mac. Did you actually try shipping an app built on such a packager?

I shipped multiple. JDeploy solves some of those things but it's not as refined as native packaging.

[Atomskun]

What's the problem with jpackage for, say, shipping Windows binaries?

I just let it package a "portable" (no need to install) directory of all dependencies and that's it. Users just download a ZIP and can use my programs.

[invalidname]

They don't have FX installed. No one does.

The whole idea of using Java is to support something other than Windows. I use a Mac and all companies I worked with had all common OS's on desktops. The edge cases are the problem. This isn't a product for other engineers. At least not engineers who have experience with JVM conflict issues.

For end users and to get a smooth installer experience there's a huge distance. Customizing the installer in the packager is a nightmarish problem... Or at least it was the last time I did it.

[Atomskun]

I can't use jpackage on Windows to build Mac binaries, but not having FX installed is what kind of problem? Just use jpackage to create an .app for Mac, an installer or portable build for Windows, and a .deb or executable binary for Linux. It bundles all dependencies and users can just click and run it.

[thiht]

I used JavaFX a while ago and hated it. It was insanely slow, fonts were awful and the lib of components was non existent.

It really felt like something created by someone but never used in the real world. Is it even used anywhere?

[frou_dh]

Agreed, JavaFX's font rendering on MacOS was like this for years: https://user-images.githubusercontent.com/1413266/82507544-6... (Note not only the inconsistency between letters - all the specific colour values used are the wrong ones to get a working subpixel effect in the first place).

Possibly still is like that. But that gets around to your question... is anyone still around to notice?

[cbm-vic-20]

That's an homage to the Apple II color text rendering.

https://en.wikipedia.org/wiki/Composite_artifact_colors#Appl...

[codeptualize]

I haven't used it myself (yet), but https://tauri.app/ looks very promising as Electron alternative.

It uses the OS's browser so it doesn't have the bundle size issue you describe.

[api]

I've tried it. It's a very strong effort but if you want to support Windows then welcome to hell.

You'll need to ship Microsoft's new Edge runtime thing, which is a separate package. You'll either have to include that giant package in your package or download it on demand, and the latter is very brittle and will fail if MS changes their URLs or you're installing inside a very heavily firewalled (whitelisted) environment. If your product runs in enterprise settings you will get complaints from IT people about how your single installer installs a "hidden" second installer that they don't want, especially since the Edge runtime runs some kind of system service (why?) all the time. You'll have to basically take over maintaining up to date Edge runtimes in your bundles and handling edge cases because Microsoft can't ship software for their own OS. People will complain that if they uninstall your app it does not fully uninstall because it leaves the Edge runtime.

Tauri just works everywhere else but the headaches on Windows defeat the purpose to some extent.

Of course I guess shipping anything for Windows is "welcome to hell." The only way to have a package that installs and runs reliably is to bundle Every. Single. DLL. And. Dependency... or statically link it.

[OvermindDL1]

I don't think this is accurate as Windows 10 and Windows 11 have edge built in, as WebView2, which is used for some internal Microsoft programs now as well, and older windows systems are not supported in any way by Microsoft themselves anymore, so it seems safe to ignore them now. I've had no issues with Tauri on Windows however, and I even compile it from Linux.

[mwcampbell]

As another Windows application developer targeting enterprise users, thanks for the warning. Electron it is, I guess. Either that, or using the IE engine for web views, or no web views at all.

Edit: I'm already using Electron, though I've been wishing I could move away from it.

[ramones13]

You should verify the original commenters statements hold true in your target environment(s). Office has started heavily relying on WebView2, any enterprise using Office should have WebView2 updating working properly. Ditto for Windows 11.

Not sure what time period the original commenter is referring to, this story has developed quite a bit over the past year, even into last month - https://blogs.windows.com/msedgedev/2022/06/27/delivering-th...

Edit: and if your alternative is Electron, WV2’s fixed runtime is the same concept as Electron in a static Chromium version - https://docs.microsoft.com/en-us/microsoft-edge/webview2/con...

[api]

If you are shipping software for Windows just make sure your insurance has good mental health coverage.

[mwcampbell]

Heh, I've been shipping software for Windows one way or another for about 20 years. I just hadn't used Edge's WebView2 in anger yet, and now I probably won't.

Edit: And I've generally followed the "bundle every dependency" approach. As far as I can recall, the only dependency in a shipping product that I ever delegated to an external installer was the .NET Framework (before the .NET Core reboot). And IIRC, that did trip up a few users; thankfully, that was only a consumer app.

[codeptualize]

Thanks. That is good to know!

[jbnorth]

Isn’t the downside to this then that although you’re using the native browser you’re losing the whole point of Electron which is to have a consistent environment regardless of where it’s run?

[codeptualize]

Probably. But I don't think that is very problematic.

Browsers have become a lot more standardized. What also helps a lot is that windows is now Chromium edge instead of IE or old edge. Testing tools have also come a long way.

It's the same as building web-apps.

[moochmooch]

That is a downside. However, it's better to look at Tauri like you might look at React Native. If complete consistency between platforms is required, Tauri still saves you time by letting you write a single codebase and then do a low effort port to each platform. For many applications, Tauri applications will look the same between platforms out of the box.

That's the pitch anyway. People can spend a lot of time on ios vs android in react native applications, so ymmv

[OvermindDL1]

Specifically Tauri uses web views that are based on Chrome or Safari on systems, and only if they don't exist by default will it package it, which somehow still ends up smaller than electron. But on Mac and Windows it is tiny, and on Linux it is still surprisingly much smaller than electron, but it is a consistent environment.

[TrianguloY]

I'm mainly a java developer, but I hate the built-in Swing gui. I tried once JavaFX for a medium project and quite liked it, specially since you can use Kotlin with it and also because you can compile it to a portable executable easily (with a built-in jre, not an exe but at least you don't need to install anything).

[shrubble]

FYI the later versions of TK look much more native across platforms.

I recently found this tutorial: https://tkdocs.com/tutorial/index.html and am going thru ut.

[rr808]

> trouble w/ Electron is that you have 30MB of runtime for any application

JavaFX has the same problem? Or you rely on user's JREs already installed? I'd think 30MB really isn't much any more.

[KMnO4]

The difference is that Electron is bundled with every app.

If you have 200 electron apps, that’s 200x30mb.

With Java, the JRE is reused so the binaries can be smaller.

[sekao]

That is the case with JavaFX as well. It's not part of the JRE anymore. Also there really isn't any such thing as the JRE anymore, only the JDK. If you want to distribute a desktop Java app you must embed the entire runtime via javapackager. They have correctly realized that end users cannot be expected to install and update a language runtime separately...

[whartung]

First, of course, all this depends on the audience.

JavaFX can still be installed in a JRE, so that the application does not need to bundle it. This is fine for internal distributions, or distributing to people willing to put up with the minor headaches of maintaining the JRE separate from the app.

But, consider, for example, NetBeans does not come with its own JRE. It's not a great leap, since it's a first most Java IDE, but if you wanted to use NetBeans for PHP, you'd still need to install a JDK separately just to run NetBeans. NetBeans doesn't use JavaFX, the point simply being that there are still large Java apps out there that require you to separately download the JRE/JDK. How much this is a hinderance to their adoption, I can't say.

The direction is towards all in one JRE/FX/App bundles, but that doesn't mean it's the only way.

If you can just deploy the app jar file, the apps can be quite tiny.

In the middle ground, https://jdeploy.com manages this. They host applications, but as I understand it you can deploy the infrastructure yourself and host it yourself.

You download the app, and their infrastructure will download the appropriate JRE (including JavaFX), and share it among all those apps that do, indeed, share it.

It has "up to date" systems for updating your app. When you download the app, you get an installer that does all the work.

This is great if you have a bunch of small apps you wish to distribute, as they're basically just the jar files. The first install is a kick, of course, and as you move through the JVM versions, they'll all incur an additional hit.

But if you distribute a dozen apps all on JDK 17, then the overall download should be quite small as the JRE is only downloaded once.

I have yet to use it, but it demos nice.

As for Fonts, they seem OK to me. I use macOS, but I've also looked at them casually on a Linux VM. However, there is one sticky bit with the fonts.

At least on macOS, the default font is terrible simply because, of all things, it doesn't support the different font faces. You can't do BOLD with the stock font. It's quite the nut until you figure that out.

So, I ended up embedding a font in my app. And it all worked. It rendered fine on my Mac, and the Linux VM, and it printed to the printer well as well.

I chose Source Sans Pro, which is one of the available Google fonts.

It's annoying that I had to go down that rabbit hole, but it is what it is.

There's some ramp up time with FX to be sure, but the combination of FX with the SceneBuilder to do layout works.

This is a recent screen shot of my app, I'm no UI guy (I majored in "Programmer Art" in college...), but it looks OK to me.

https://capture.dropbox.com/AuXy4deWZTAHGHk7

This is the default theme, there are others. The CSS part of FX is really nice.

I hold FX in high regard. I've certainly had my share of head flattening desk denting events with it, but it's nice, it works.

[icedchai]

Not anymore.

To put things in perspective, my first hard drive, back in 1989, was 30 megabytes. I think it did about 500Kbytes/sec for reads. I also had a 2400 baud modem.

Today, 30 megabytes is a 1 second download on a bad day.

[kaba0]

A browser is much bigger than a runtime with a few packages though.

[awinter-py]

quark / sciter isn't OSS, and I've never used it, but they claim they can bundle something like electron (JS backend, web frontend) into a 5mb binary

[cosmotic]

JavaFX is not native, nor can it be made to look native like Swing can be made.

[kaba0]

Why couldn’t it be native (whatever that even means)? At the end of the day, it does have a canvas you are free to draw anything on, so there is nothing you can’t imitate.

[cosmotic]

Native would be Win32 calls to draw widgets. There's a built-in Swing look-and-feel that uses this API to render widgets in Swing. Yes, you could write your own code to replicate how things look, but it would be fragile and difficult to maintain. With Swing, it's built in and already maintained.