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. And not just trivial toy apps: the app I wrote was a full blown peer to peer app with an integrated Bitcoin wallet, a Twitter Bootstrap themed UI, file associations, visual effects like animated Gaussian blurs and an integrated auto-update framework.
There's nothing magic about Electron. It's just another desktop app toolkit. There's no good reason to use it except developer familiarity with HTML. It gives you all the disadvantages of desktop distribution (you have to provide your own auto update framework, get users to download the app) but with none of the advantages like great tooling, great languages, UI builders and so on.
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.
Its funny you say this while using java
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.
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.
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.
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.
I joke with my coworkers that I know they’ve fired up IDEA because I can hear it. Whenever it’s on, their fans are dialed up to full blast.
But I've never found it slow in any respect that matters for doing actual work. For everything that matters (opening files, project-wide search/replace, refactoring, typing latency, looking up docs, code navigation etc) it's easily competitive with lightweight editors.
I'm convinced all of the mud slung on Java is due to enterprise programs and other software not motivated by quality (more of a "you have no choice but to use this to interact with our hardware/service and we CBA to make multi platform so you're stuck with our lazy java. Oh, and we come from the school of abstracting things to hell because creating more red tape impresses upper management.")
IntelliJ is I think the first application that showed me that Java is Good, Actually™ by delivering on those mythical promises of compatibility and speed.
I've recently written a decent-size Qt app (QtWidgets, not QML) and the problem is the language. C++ leaves a lot to be desired especially coming from higher level languages. If you look around at language bindings, the only quality one I can find is Python and I want to avoid that too (I don't want to build a large app in a dynamic lang). Couldn't use Go, I needed MSVC to interoperate. Rust bindings had drawbacks or were incomplete. Etc. (I probably need to revisit D's Qt binding)
I just want a full-featured (i.e. not QML) widget framework in Rust, Go, D, or some other high-level non-VM cross-platform language. I'd even take C bindings because we can work from there. And I want the widgets to appear native. C# + WinForms would be great if it worked great on non-Windows and was easy to interoperate with third party C-level widgets. WxWidgets is C++ or dyn lang (though there was a C binding maintained by Haskell devs IIRC), Gtk doesn't look very native, etc.
Widget-based desktop development will continue to lose to these alternatives while there is not a good widget library on a good sans-baggage language.
Edit: Just saw https://github.com/christolliday/limn (https://www.reddit.com/r/rust/comments/73w227/limn_gui_libra...) ...a good start!
what are you missing with QML ?
However, it does let people hit 4 platforms way quicker than even two, which is a huge deal. And while I'm working out the kinks in my Qt app, the Javascript dev has a version anyone with a browser can use on anything right away, even if the desktop version isn't ready yet.
†Pouring one out for HyperCard. I miss that wonderland.
Edit: Damn you auto-markdown.
There must be irony here. The web development plateform is easy to get in, but hard to master: too many languages are involved (html, css, server side, javascript) and most didn’t have some really useful features until very recently (css grid for instance).
Then you have the language creep (Typescript, Dart or anything to paliate JS deficiencies; LESS/SASS), the JS framework creep, the libraries decay, etc.
I failed to see how this is ‘fantastic’ in regards to a language such as C#/F# that allow you to build desktop app very easily. If multiplatform support is not a requirment, the desktop languages and tooling are way ahead in term a ease of use.
That is totally a thing in Java too. Languages: Groovy, Kotlin, Scala. Framework: GWT, Spring, Struts, Vaadin, Grails. Libraries decay: commons, apache, different parsers, different db drivers.
On top of that though, you need to think about your JVM? What dependency manager: Ant, Maven or Gradle. Then figure out which JDK to use, cause that's a thing. Then figure stuff out like facets. Sure this is more IDE field but the fact Java app architecture can be so whack that something like 'facets' needed to be abstracted only proves my point.
> If multiplatform support is not a requirment, the desktop languages and tooling are way ahead in term a ease of use.
Ahead with the size of muddle yes. Web stack is just very good and fast at emulating the amount of it.
I think you are confusing the JVM with Java. However, comparing languages needed for web development to available JVM languages is comparing apples-to-oranges. With web development you have to use different languages in the same app to accomplish anything. In a app you are using the JVM for you can pick one language and stick with it.
> Then figure stuff out like facets.
A "facet" has absolutely nothing to do with Java. The term "facet" is a term used by IntelliJ to configure adding features to your project. IntelliJ configures all of these on its own, I never even have to think about them (it actually took me a bit to even figure out what you meant by "facet").
Is this some kind of joke? VS Code is a glorified text editor that ate your CPU trying to blink the cursor: https://github.com/Microsoft/vscode/issues/22900
Microsoft has a real IDE, and it ain't written in JS.
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).