Say no to Electron: use JavaFX to write a fast, responsive desktop app

Don't say no to Electron just yet. And if you do, jesus, there's better alternatives than JavaFX (use Qt).

You know what Electron has brought us? It's brought the Linux desktop reliable feature parity with other platforms. Fat chance Visual Studio Code (often hailed as "one of the best-optimized electron apps") would have existed on Linux without Electron.

Discord, another fantastic Electron app, is functionally identical on web and desktop (all platforms), feels fantastic on Linux, no issues at all. What are the odds I would have a functional Text/Voice/Video chat Linux desktop client for Discord if Electron didn't exist? How much time would have had to be spent reverse-engineering the protocol then implementing a decent UI for it all?

Obviously you shouldn't use Electron for certain things. If your app is tiny especially, you'll be better served with a leaner framework. But that's nothing new.

Electron has given desktop developers access to the web's fantastic tooling and iteration speed, and web developers access to the desktop market. It's given the ability and incentives to all those developers who might not have touched Linux before to make a Linux release alongside the rest.

If you don't like how Electron performs, your time would be better spent optimizing it than seeking out Java frameworks, which work atrociously bad on anything that isn't the author's platform (if even that).

"you can distribute it to any user on any OS and it will just work."

I had to check the date on this article to see if it was from 2007 or something. Under no circumstances does java "just work", its an insane mess of java shipped with the os, being updated, and people not updating due to oracle trying to force feed crapware as part of their installers/updaters. I, for one, do not live in a world that resembles anything like java jars "just working".

> This is not as much a result of the superiority of the web stack for building applications (far from that, I don't think anyone disagrees that the web is a mess), as a failure of the current desktop UI frameworks. If people are preferring to ship a full web browser with their apps just so they can use great tools such as JavaScript (sarcasm) to build them, something must have gone terribly wrong.

This article so thoroughly misses the point of Electron. Furthermore the author's snark and condescension just serve to antagonize and attack rather than making any semblance of a point.

People choose Electron because it's easy to work with for people who are already comfortable with JavaScript. JS devs get to use tools like React, TypeScript, Webpack, Babel, and other tools they already understand and like. You have the entire wealth of tools of npm at your disposal. And since it's JS, you can share code between Electron, your website, and your Node server.

In addition to that, HTML, CSS, and JavaScript writing UIs is something thousands of us do every day do for a living. Being able to do that for a desktop application unlocked a whole world of development that previously was closed to only those comfortable with Objective C, C++, Java, and the like.

The author does a woefully inadequate job of explaining that choosing Electron is a _tradeoff_. You're trading a larger memory footprint, bigger artifact to distribute, and some extra performance challenges for the ability to write your application like a website in CSS, HTML and JS and have it work on every OS that Electron supports. For many this tradeoff is unacceptable but it's either incompetence or idiocy to not see that this tradeoff works for many of us.

I wrote an IDE using JavaFX: https://sekao.net/nightcode/ My experiences have been mostly great. As the author mentioned, the JDK comes with a nifty tool called javapackager that will generate a dmg, exe, deb, and other formats with the JRE built in. If you really do want to embed web content, it includes a WebView widget which is a fully-functional browser capable of loading local or remote content, and it even lets you communicate between the JVM and JS side using a little bridge object. So you get the benefits of both the JVM and JS ecosystem. This was particularly nice for me because I could write the some of the IDE in Clojure, and some of it in ClojureScript, and they can call each other's functions arbitrarily. Amazing stuff.

> That's a world of difference from an Electron app, which typically needs 200MB just to open.

This is sort of an unfair comparison - the JavaFX one is mainly smaller because it doesn't include the distribution of Java and all the libraries, which is if I recall correctly about 200 MB, while Electron commonly includes all libraries and the renderer. I will give you that the Java distribution can at least be shared by many applications, but you can definitely get into some nasty versioning situations with that.

On the other hand, if you were to compare this with say a Qt application, it'd be about ~20MB all in, ~10MB if UPX'd, no external dependencies needed. Or just the size of your tiny executable if you're working on a Linux distro that ships those deps already.

It's also tough to beat the developer experience that the modern JS ecosystem has brought to app development.

The Chrome dev tools alone are pretty incredible. Getting that much detail in your debug environment, paint cycles, render times, animation effects, and quick style experimentation is a huge deal.

The package ecosystem for JS is also an enormous advantage. Having access to data layer systems like Redux & the Redux dev tools, as well as any module designed to run on Node.js really helps ensure an actively developed ecosystem that abstracts more and more away from the end application developer.

Finally, I argue that performance bottlenecks are rarely an issue of the javascript. V8 is extremely fast and only getting faster. Most bottlenecks come from doing something dumb during rendering, or tying up a process reading from disk. These are issues that happen on all app platforms. The big difference is that Electron gives you to tools to effectively debug and optimize these, plus a HUGE wealth of online resources & tutorials to help new developers jankbust.

As much as I dislike the inherent complexity of Electron, VSCode and Discord are existence proofs that it can be used effectively.

VSCode is far faster than any other IDE I've used, and even beats VIM in terminal in terms of responsiveness (altough I suspect this is not VIM's fault).

Discord is overall a great application, and quite responsive.

Both are slightly bloated in terms of memory, from what I supect they could be. But not nearly as bloated as many of the competing Java and C++ applications.

This article seems to miss the point. There's a huge pool of web developers who can write HTML/CSS/JavaScript; Electron lets you have those people use their skills to build desktop apps. It also lets all the others not directly working on the product to write plugins using familiar technology.

Suppose a startup has a runway of 6 months and a full stack web dev who can build the backend and web frontend.

Are they going to fragment the code-base with Java to introduce a desktop client? Are they going to hire another enterprise Java dev, who most likely isn't familiar with the rest of the stack?

The rise of Electron is fundamentally driven by the cost effectiveness of the wide availability of developers and community support.

Well short of being tossed into a time portal and popping out in 2007 I wouldn’t build a client app in Java...

But Qt has rust bindings, so that’s good to learn!

Yeah, you just have to have Java installed on whatever system you're running the app on. From a development perspective (or anyone who has done end-user support of a desktop app) this is an absolute non-starter.

"Install this runtime, then you can install this app. Oh and that auto updater that is atrocious? You can thank us for having it. Thanks for being a loyal customer!"

There's not really an acceptable amount of arguments against Qt and Gtk+ to support the headline. It reads like, "I don't really know much about the alternatives other than JavaFX, but this is why I personally like it..."

How did this get upvoted? Author misses the point entirely of Electron. If people wanted to write Java, they already would be doing that. The selling point for Electron is: folks are comfortable with JavaScript/HTML/CSS and can be productive right away. I'll take the neatly packaged (although larger) installer over requiring someone to have the JDK installed any day

I'm a little disappointed that the article doesnt mention the benefits of JavaFX and why exactly I should ditch electron over javafx.

Isn't a main advantage of using the web stack to build desktop apps that you can share code with a web hosted version?

>Hey look at this proprietary software that's so cool and old and established! >The web has only been around for 20 years! >Pfft not even kidding they're trying to make desktop apps with web tech! PFFFFFT

'nuff said.

Author: "Electron is bad so let's use something even worse."

Oracle has caused so much harm to java. javaFX does not work well when display is remote (90% of my use case).

If JavaFX requires my customers to have Java installed on their system then this is some sort of joke.

A question - Does Jython (Python) get compiled to byte code for the JVM? Or does it run interpreted?

I've recently written javafx with kotlin. It was a very pleasant experience.

Having messed around with JavaFX in the last 3 months, I advocate against it.

Look. I agree, that you shouldn't make desktop applications in Electron. The thing is, when you have a fresh grad student that was taught PHP as a web framework for most of the time and maybe Node, what do you think they will gravitate towards? I understand veterans feel like Qt, GTK and JavaFX are intuitive in their architecture and syntax but that is simply not true. Heck even XML can be jarring.

So here's what i've found people trip up with JavaFX mostly.

1) FXML. Why do you need so much information just to view "Hello world". You need to define a scene, then you need to define what's inside the scene (You'll need to go look up a reference guide on JavaFX to find what objects you can attach just to get started), then you need to describe that a text node is connected to the thing inside the scene. For HTML it's always gonna be <html><body></body></html>. Inside the body it doesn't matter what structure you create, you'll be cutting off "sections" with plain html+css. HTML5 got it's canvas if you need more advanced functionality. Why would people who have been taught to use canvas and DOM revert to this?

2) Custom CSS. Fantastic, more syntactic sugar and another reference guide to search through... people get effects/animations with greensock or css nowadays, it's fairly competent stuff and frankly more intuitive. Just a gem from the reference: background: white; -fx-text-fill: ladder(background, white 49%, black 50%);

Without reading the reference I'm thinking it's filling the color. What does ladder and it's arguments mean I would have no idea. What does is this: "Use the following if you want the text color to be black or white depending upon the brightness of the background." – right, cool but there's filters and stuff made for this very thing in plain old CSS.

3) JVM hot code reload. The entire section is confusing to people using Node that learned to implement a watcher in Tutorial 1 of setting up package.json. Good luck explaining intricacies of JVM to grads that struggled to get bare bones Java application running in Eclipse. "I find it hard to believe that anyone would prefer the webstack to working with a sane environment like the JVM." – I profusely disagree. The fact you need to have a virtual machine for your code to execute is a lot for people outside the bubble to comprehend. The fact you have two types of dependencies, runtime and compile, already confuse new people coming into the field. Gradle which is supposed to make lives easier is still way more confusing than fiddling with package.json. It's perhaps not Gradle's fault, I think the blame is more with veteran developers that like to be 'clever' and manage to obfuscate something as simple as launching an application.

4) SceneBuilder. "It can be integrated into all Java IDEs, making it easy to create new views.". What the author has forgotten to mention, is that it can be a pain to use and integrate (Haven't tried this in IntelliJ and i'm sure it's better there but it's still more hassle than opening your flavor of browser inspection). You'll most likely end up ditching the GUI and do everything programmatically, at which point you'll ask yourself why are you doing css and js in Java. The example in the article is a simple "Hello World". Anything more complex and you'll find people falling into the habit of doing everything inside of Java.

5) ScenicView. "To start it with your application, just download the jar and pass the option -javaagent:/path-to/scenicView.jar to the JVM." – that line might as well be written in Chinese if you're a person coming from the Node scene.

6) JavaFX does not automatically refresh stylesheets. You need to build a whole seperate function and implementation just to refresh a stylesheet. "This works in Mac, Windows and Linux Mint. But this was one of the only two problems I had related to differences in OS's (the other one was the icon in the system tray on Mac does not work, but there is an ugly workaround for that). JavaFX abstracts that away pretty well, most of the time!". Well that's reassuring there is an iffy solution to a problem that shouldn't be there to begin with.

I also feel the author is quick to throw anyone using electron under the hipster title and then proceeds to call the webstack a mess yet ignoring the mess that Java is. Need I remind you why Node stuff was so popular? Because people required entire days to figure out how to get a simple ToDo Spring application working. And Spring is supposed to be easy. Think about that. You need to spend dev time on something as obscure as 'JVM tuning' at one point or another. Or fixing some bizarre leak/overflow because hurr-durr imperative programming. And the 20 years of patterns and best practices wasn't good enough. We have shit like JPerf to figure out why all those stern-toned articles still lead to shitty code and JRebel to sweep the problem under a rug.

"We've been writing desktop apps for decades. The web, on the other hand, only really got started less than 20 years ago, and most of that time it was only used for serving documents and animated gifs, not creating full-fledged applications, or even simple ones! To think that the web stack would be used to create desktop applications 10 years ago would be unthinkable." – And here we are with Java still remaining the clusterfuck that it is.

"If people are preferring to ship a full web browser with their apps just so they can use great tools such as JavaScript (sarcasm) to build them, something must have gone terribly wrong." – yeah, that something was the JVM. Kinda funny we now have all this compile-to-js stuff when there's still uppity aura revolving around JS. Heck I remember having trouble with just the JRE back when I hadn't learned any programming.

Please just write native apps, and quit trying to cut corners. Geez.

Ugh this just reads like an old Java developer pissed off at people not using his tool of choice. His snide remark about JavaScript just tells me that he has an outdated view of the language. JS is weird yes. JS has problems yes. But the author is promoting friggin JAVA as the alternative?? Phfft!

There are reasons to pick your tools. Sometimes speed of development and being able to use your pool of developers existing skill sets effectively is one of them. If you have a bunch of web developers and need a desktop app then electron is something you might want to seriously consider. ESPECIALLY if you don't have unlimited time to get the product out to market. Electron is not a one size fits all choice and conversely neither are the frameworks the author is proposing. Decide what you need and make your choice based upon those needs.

I am building an electron app as we speak. Its not without its challenges and there is no doubt that native approaches would trump it in some respects but it literally does everything I need it to do. Better yet, I can hand this off to my team who all have a development background and any one of them can jump in and be able to contribute in a meaningful manner within a day or two of groking the codebase.

I guess my point is, lets stop bagging on technologies for the sake of it. Every single one of them involves trade offs. Effective developers weigh those against the problem they are trying to solve and pull the trigger on the one that gets the job done best.