
Say no to Electron: use JavaFX to write a fast, responsive desktop app - oblio
https://sites.google.com/a/athaydes.com/renato-athaydes/posts/saynotoelectronusingjavafxtowriteafastresponsivedesktopapplication
======
scrollaway
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).

~~~
rootlocus
> And if you do, jesus, there's better alternatives than JavaFX (use Qt).

Because "god forbid" anyone use technologies associated with java? FUD at its
finest.

> Fat chance Visual Studio Code (often hailed as "one of the best-optimized
> electron apps") would have existed on Linux without Electron.

I just use IntelliJ IDEA. It's ten times faster and ten times more powerful
than Visual Studio Code. And it's written with java swing.

~~~
vvanders
As someone who spends all day in IntelliJ there's no way it's 10x as fast,
hell for me it's flipped the other direction.

VSCode is easily 10x faster than IntelliJ. If I'm writing Java I'll happily
use IntelliJ but anything else it's VSCode or vim.

~~~
13years
I use Eclipse with its native SWT UI and VSCode still blows it away in UI
speed.

Actually, if Mozilla's Servo tech gets integrated into something like
Electron, then we will have some serious performance capabilities surpassing
pretty much anything else comparable.

~~~
chillee
I believe the VSCode team is indeed looking into using webassembly.

------
mixologic
"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".

~~~
mike_hearn
It does just work, at least compared to web apps. I have experience of both
web dev and distributing a somewhat complex JavaFX app to consumers. I bundled
the JRE with my app so the users did not need to have Java installed.

The leaks in the operating system abstraction Java gives you are really quite
small. I wrote my entire app on macOS and tested on Linux/Windows only right
at the end - after about 8 months of full time dev work I spent about a day
addressing platform specific issues. That's pretty good.

Now compare that to the mess that web browsers were and still are. It's better
than it once was, but you're going to have to check every single feature of
HTML5 you use to figure out which browsers implement it, which don't, which
use vendor prefixes still, which only half implement it, which don't but can
be shimmed using big blobs of JavaScript and so on. The web absolutely doesn't
"just work": you will spend more far time working around browser specific
issues than you will spend dealing with OS specific issues in Java.

~~~
kakwa_
> I bundled the JRE with my app so the users did not need to have Java
> installed.

Side note here: do you track security vulnerabilities of the shipped JRE and
provide updates when it happens?

Too often, I've seen java applications shipping obsolete and vulnerable JRE.
And in some cases, I've seen not consistent versions across a product line.

Also wasn't there some unknowns about the right to redistribute the Oracle
JRE?

~~~
mike_hearn
I do track those. I didn't need to update my app at any point for them because
most vulnerabilities in the JRE are to do with sandbox escapes and my app did
not run potentially malicious code.

------
aquilaFiera
> 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.

~~~
woodrowbarlow
But the article demonstrates that with JavaFX, you can have FXML + CSS +
JavaScript. Isn't that close enough that a web developer could be comfortable
pretty quickly? You're just working with a differently flavored DOM, right?

I am not a web developer, so I may be way off base.

------
gw
I wrote an IDE using JavaFX:
[https://sekao.net/nightcode/](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.

~~~
abiox
what kind of memory and performance footprint does the webview imply? is it
similar to using electron, to some extent?

------
rightos
> 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.

~~~
nalllar
Java 9 adds jlink, which lets you create a runtime image containing only the
java modules you're using.

This means you can ship a considerably smaller built in JRE with your app, if
you don't want to depend on a system JRE.

javapackager (uses jlink): [https://docs.oracle.com/javase/9/deploy/self-
contained-appli...](https://docs.oracle.com/javase/9/deploy/self-contained-
application-packaging.htm)

jlink:
[https://docs.oracle.com/javase/9/tools/jlink.htm](https://docs.oracle.com/javase/9/tools/jlink.htm)

~~~
poxu
I was able to create standalone java9 modular application using jlink, but
didn't succeed using javapackager. Which is a pity, because jlink creates a
distribution, which you launch with a _.bat file, instead of_.exe.

------
e0m
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.

~~~
pjmlp
That is nothing new when comparing with something like Delphi or .NET tooling.

------
smaddox
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.

~~~
ch4s3
>But not nearly as bloated as many of the competing Java and C++ applications.

I too like discord and VSCode, but VSCode uses far more resources than
sublime, with the tradeoff being that it's more easily extensible and has a
faster release cycle(which may or may not be related to team size). VIM
locally is obviously also going to be much faster and capable of opening far
larger files than VSCode.

~~~
smaddox
I haven't tried using sublime as a full IDE, so I'm not comparing against
sublime.

~~~
ch4s3
Ahh, that's fair. If you're looking for something quick, and don't need the
bleeding edge stuff like the language server, then sublime is very nice.

------
Eridrus
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.

~~~
icc97
Yeah you get your front end devs creating beautiful UIs which can be directly
ported to desktop.

The other thing of course is that Electron apps start out as web applications.
So they already work perfectly in a browser.

------
diwu1989
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.

------
odammit
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!

------
deedubaya
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!"

~~~
AnIdiotOnTheNet
Or you could just bundle the runtime with the application, you know, like
Electron does.

~~~
boondaburrah
This is one of the many reasons I don't like electron (the apps become
/massive/ and I can't update electron separately from the app), but I
recognise I'm not the target market.

------
Waterluvian
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..."

~~~
BoorishBears
To me, on a sliding scale of complexity, JavaFx is closer to Electron than Qt
and GTK+ (especially since your options are C++, or using bindings that have
varying quality and ease of use).

If I was trying to sell someone who uses Electron on an alternative it'd
definitely be JavaFx, maybe Qt with QML if they knew C++.

~~~
mateuszf
C++ in itself is pretty complex comparing to other languages

~~~
BoorishBears
Yeah, main reason I'd only recommend Qt/QML if they were already comfortable
with C++ (although Qt does a lot to help with memory management)

------
bsclifton
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

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

~~~
rightos
The author touches on app size and performance - both of which are fairly
valid I believe, but they don't go into why JavaFX over other desktop UI
frameworks.

~~~
bpicolo
I don't see any mention of perf

~~~
wieghant
His just complaining and electron eats memory (supposed 200MB on startup).
Find it funny he brings Java as a better alternative to the table.

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

------
CodinM
>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.

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

~~~
djhworld
Why do you think it is worse? I am interested in hearing of your experiences
on this.

~~~
bsclifton
Setting aside subjective reasons... how about the barrier for entry being
lower for web development? Also, more people arguably have web development
skills

Java isn't new or unpopular- if people wanted to use it, they would

~~~
Uristqwerty
The barrier for entry of web development is not necessarily lower, it's more
that most people have already tinkered with web development informally.

Many IDEs have some sort of visual GUI layout tool, but the nature of HTML+CSS
makes it a far leakier abstraction less suited to visual positioning.

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

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

~~~
djhworld
You can package the JRE in with your app very easily using the tooling
provided, customers don't need the JRE installed on their system.

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

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

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

~~~
brabel
Why? Is it just difficult to use or the app you wrote is not as good as your
Electron app?

------
wieghant
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.

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

------
vikingcaffiene
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.

~~~
rootlocus
> JS is weird yes. JS has problems yes. But the author is promoting friggin
> JAVA as the alternative?

As a language, I find java is much better designed than Java Script.

~~~
vikingcaffiene
Thats a totally valid opinion but its just that: an opinion. Personally I find
Java overly verbose and bloated. I'd use it if it was the right too for the
job though. Just depends on what you are doing.

~~~
rootlocus
> Personally I find Java overly verbose and bloated

Not much more verbose than it needs to be explicit.

    
    
      "Explicit is better than implicit."
                           PEP 20, Zen of Python

~~~
vikingcaffiene
I mean, I guess? Again we are talking about preferences here. I think being
explicit has less to do with the language and more to do with the developer
writing it. Poorly or well written code is universal and all offer you the
tools to shoot yourself in the foot or vice versa.

