61–70 of 145 posts
Why the emphasis on "unidirectional data flow"? I happen to think Lazarus (based on Free Pascal) is great, but it's not a functional language at all.
Do you have any examples of apps that use that tech?
Earlier quoted context omitted.
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.
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...
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.
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 br…
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.
> HN has strong opinions against Electron Beware the bias of the loud minority. For every 1 noisy user, there may be 50 quiet users who are fine with the decision to use Electron. Shipping beats not shipping every time, and if Electron is what you need, then do it. I say this as someone who does not like Electron, but also as someone who knows that writing comments on HN is 100x easier than actually shipping producti…
Earlier quoted context omitted.
I usually agree with this sentiment of shipping vs not shipping. But Electron is just really bloated. You cannot install 10 apps and regularly use it. Most systems will just hang or crawl. Systems with 8GB should not be hanging because you are using 10 apps. I have 16GB RAM and even then I feel the hog with Discord, Slack, VS Code, A note app taking up too much memory. Then there is unnecessary security risk of bring…
It is sad. But I'd rather people ship something and refine the Electron version than never ship anything at all. Mostly because I believe more in indie devs than I do in the purity of software.
Earlier quoted context omitted.
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.
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) environm…
Edit: I'm already using Electron, though I've been wishing I could move away from it.
Hate to say it but, this is one of the biggest tragedies of modern CS. Best bet is to use gtk, or qt, and hope the language bindings for your lang of choice aren't horrible (depending on the language you might be in tears)
Earlier quoted context omitted.
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.
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?
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.
Earlier quoted context omitted.
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.
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) environm…