Live data from Hacker News

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

sites.google.com

101–110 of 143 posts

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

#101

Earlier quoted context omitted.

As someone who has written desktop JavaFX apps and web apps, I don't think you know what you're talking about. I can tell because you talked about the web's "fantastic tooling and iteration speed". That's a bit of a giveaway - I'm willing to bet you've never written a JavaFX app in your life. JavaFX apps work just fine on Linux. Not even fine, they work well. I know because I've written them and tested them on Linux.…

> but with none of the advantages like great tooling, great languages, UI builders and so on. Its funny you say this while using java

Using the jvm.

So java 9, Kotlin, Scala or kawa (scheme), abcl (common lisp), clojure (nu lisp:), jython, jruby. While there are compile-to-js languages too (including Kotlin, Scala, clojure :) - there is quite a lot more history around jre/jvm languages for production desktop use.

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

#102

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

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.

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

#103
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 . 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.

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

#104

Earlier quoted context omitted.

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

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.

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.

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

#105

Earlier quoted context omitted.

This is surprising, I've never seen anyone say that IDEA is faster than VSC. In my experience it's _vastly_ slower.

I work with a project that contains tens of thousands of classes that span about 3m lines of code. Jump to any symbol responds to a fuzzy search in about one second. Jump to class autocompletes instantly as I type, and a rename takes a few seconds to update all classes in the project, including references from xml files and comments.

In IDEA, right?

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

#106

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 existi…

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

As a language both are insane in parts. Not just architecture but the muddle of tooling also.

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

#108
post #11
post #9

Earlier quoted context omitted.

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.

I don't see any mention of perf

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

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

#109

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

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

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

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

#110

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 iden…

As someone who has written desktop JavaFX apps and web apps, I don't think you know what you're talking about. I can tell because you talked about the web's "fantastic tooling and iteration speed". That's a bit of a giveaway - I'm willing to bet you've never written a JavaFX app in your life. JavaFX apps work just fine on Linux. Not even fine, they work well. I know because I've written them and tested them on Linux.…

It's not about superior tech. Devs don't care. Electron let's developers use all the library and frameworks that they are familiar with, that's what that matters.

I hate Electron apps but I can see why people do it. It's very tempting to be able write desktop apps with the web's best frontend technologies.

Post reply on HN