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.