> 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.
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.
The install size on disk is indeed about 200 mb including the Java runtime. However the claim here is that Electron uses 200mb of RAM, which is much more precious than disk
Most of the Java runtime is not actually used by most apps so the new modular Java 9 should produce much smaller installs, but I haven't tried it yet.
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..."
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++.
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.
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.
>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.
One thing that can make vim in a terminal feel slow is related to the escape character doing double duty to signal extra information to terminal applications (e.g. arrow keys or window size) on the same channel as regular input.
To catch a single press of the escape key, vim needs to wait a little bit to make sure it's not the start of an escape sequence. Sometimes that delay is configured too generous and becomes noticeable, especially when chaining applications (like running vim in tmux).
If an Electron app is beating vim in responsiveness on your machine, I suspect there's something wrong with your machine. Vim should react instantly in every case. I have yet to see that from any Electron app I use.
"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".
Correct me if I'm wrong, but I don't think the Java updaters on Windows do bundleware anymore. I know nearly all the free Windows antivirus updaters automatically install Chrome and set it as your default browser unless you pay close attention still.
That "bundleware" (as JohnTHaller calls it) stuff was going on before Oracle. I recall being disappointed that Oracle hadn't stopped it several versions into the Oracle rebranding.
Yeah I haven’t even had java installed in years. Only have a single app that uses it but it’s tucked away in a docker container. It’s basically flash to be, no longer a need.
Once the runtime is bundled in, what does the size of the standalone application come in at? Curious if it is close that of a bare Electron app (around 50-90 MB, depending on the platform).
In my project, the jar file itself is 20MB, and the resulting files generated by javapackager are: 55MB (.exe), 90MB (.dmg), and 67MB (.deb), all of which include the jar file inside them. These are not the total file size after installation, though.
Yes in Java 8 it's comparable. In 9 it should be smaller due to some dead code elimination on module boundaries, but 9 just came out so it's a bit early for people to have experience with it yet.
Note that even in 8 you can do a DCE pass over the code and erase files you know you won't need from the JRE image by hand. I did this and shrank the size of the download by about half. The JavaScript world calls this "tree shaking", you can use ProGuard to do it in Java but it's a bit fiddly to set up.
Generally java desktop software is wrapped together with a bundled jre and behaves like an executable without external dependencies. There are a bunch of ways to do this. For example: https://github.com/libgdx/packr
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.
> you're going to have to check every single feature of HTML5 you use ... you will spend more far time working around browser specific issues than you will spend dealing with OS specific issues in Java.
I'm confused at this comparison in terms of Electron. Do you have to worry about any of that when doing an Electron app? Or were you making a comparison between JavaFX and web dev?
You're right that with Electron that's not an issue as you control the browser. I was comparing the equivalent issue in web dev to the "write once run anywhere" issue in Java. If you pick the users operating system e.g. only support Windows then of course, there are no cross platform issues with Java either
> 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
There's tools for that and i'm pretty sure just writing plain html and css or some compile-to-js would have shaved off significant time from that 8 month full dev time.
It wouldn't have been possible to do as a webapp at all, as the app in question was a peer to peer app that spoke a fairly complex network protocol that doesn't support WebSockets (Bitcoin). But even if that issue hadn't existed, the development time went mostly on logic and p2p/networking issues. HTML wouldn't have helped and JavaFX supports a dialect of CSS2 anyway.
> 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?
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.
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.
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!"
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.
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).
Qt + QML is IMO not just the currently best way, but also some kind of global optimum for me (coming from Swing, SWT and WPF/XAML). The data dependency handling is incredibly well done (it sometimes feels like using a Rx library without all the boilerplate), the handling of visual state is superb (think VisualStateManager without 4 pages of XAML).
I would argue that it doesn't give desktop developers "access to the web's fantastic tooling and iteration speed," as the tooling and iteration speed for the web is crap compared to desktop. "Hot Reload" is kind of a poor substitute, as I still need to edit text that correlates with what I'm seeing instead of interacting with it directly. I can get something working in C++/Qt, PyQt5, WinForms/C#/.Net (windows) way faster†.
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.
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.
Sure vim beats out both of them but I'm constantly having to wait for VSCode to catch up with me or my cursor will start inserting characters at the wrong spot. IntelliJ works as fast as I can think (minus the boot up time).
Same here, in a legacy code base with millions of lines of duplicated code that I unfortunately had to work on, IntelliJ would not even let me type, it just froze up all the time. Atom also sucked, fuzzy finder locked up the UI for 10 minutes. VSCode I can cold boot & start using the fuzzy finder, no issues. Feels like vim, in that it "just works". So performance is more dependent on what the software is doing, not what UI toolkit / runtime it uses. VSCode is faster on this codebase because it seems to not block editing due to a search index, like the others -- which has nothing to do with Electron vs Java.
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.
I mean, Java applications work ludicrously well. They're not slow, and they really do run on anything. I'm straight up double-clicking .jar files on Mac and Windows without any problems (on linux double click is kinda a myth so I just "java -jar" it). There are good Look&Feel jars for swing. I just wish Swing itself didn't feel like enterprise programming. Java requires me to be so verbose it feels like I'm doing WebDev again.
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 think freedesktop made some standard for this, but I'm afraid it's making .desktop files that are just .INIs with the console commands to run. XDG is a weird place.
I'm gonna make such a claim with a straight face. I don't know if it's VSCode's vim emulation or what, but on every platform I've tried it on IntelliJ beats it, while VSCode is busy catching up to where my cursor is still after chaining like 2 vim commands.
IntelliJ is slow to start up (though I've no idea why that would matter for an IDE). And when indexing and building it can be very demanding on machine resources.
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.
+1 for intelliJ, or anything jetbrains. vscode gets a lot of hype but for serious development its still a toy. that said, as far as vscode proving that electron apps can be done very well, i do agree
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. 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.
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.
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.
> Electron has given desktop developers access to the web's fantastic tooling
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.
> Then you have the language creep (Typescript, Dart or anything to paliate JS deficiencies; LESS/SASS), the JS framework creep, the libraries decay, etc.
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").
> there's better alternatives than JavaFX (use Qt).
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.
In my case, I needed to subclass QWidget to get native handles and do native things to embed Chromium (via CEF). There might be more, but it seemed appropriate to use QtWidgets from the start for my use case.
I guess you have your reasons... but why not use the "official" way to embed chromium in Qt (QtWebengine) instead ? This would work both in widgets and qml.
Please don't use Qt if you want to target platforms other than Linux and make your applications accessible to blind users. [1] Electron is OK on Windows, but I've heard it's not currently accessible on Linux. Don't know about Mac.
>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
> 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.
... wow. Yes. I don't understand how the author has missed that the web is good and JS and CSS and HTML are a fantastic set of technologies for building applications. They work.
I don't write frontend / GUIs for a living (I tend to do C and Python). But I have done work with GTK+ and Qt, and I have done work with Angular and other random JS frameworks, and the web is so good.
All the complaining about the web is from people who just want it to be better.
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.
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
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.
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.
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
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.
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.
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.
Agree. Any language that's been around long enough is like that though. PHP is a good example. I've heard it called a hammer with no blunt end and 2 claws. You _can_ turn it on its side and hammer in the nail but... why? Lol. That said projects like Laravel show that you can write easy to use and, dare I say, beautiful code with it. Its just a matter of who is driving.
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.
142 comments
[ 2.5 ms ] story [ 255 ms ] threadThis 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.
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...
jlink: https://docs.oracle.com/javase/9/tools/jlink.htm
Most of the Java runtime is not actually used by most apps so the new modular Java 9 should produce much smaller installs, but I haven't tried it yet.
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++.
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.
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.
To catch a single press of the escape key, vim needs to wait a little bit to make sure it's not the start of an escape sequence. Sometimes that delay is configured too generous and becomes noticeable, especially when chaining applications (like running vim in tmux).
For real?
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".
Sun did that damage.
For details, see "JavaFX support is in upstream OpenJDK 9 but missing in Ubuntu OpenJDK 9" (https://bugs.launchpad.net/ubuntu/+source/openjdk-9/+bug/172...).
Note that even in 8 you can do a DCE pass over the code and erase files you know you won't need from the JRE image by hand. I did this and shrank the size of the download by about half. The JavaScript world calls this "tree shaking", you can use ProGuard to do it in Java but it's a bit fiddly to set up.
https://docs.microsoft.com/en-us/dotnet/core/deploying/deplo...
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.
I'm confused at this comparison in terms of Electron. Do you have to worry about any of that when doing an Electron app? Or were you making a comparison between JavaFX and web dev?
There's tools for that and i'm pretty sure just writing plain html and css or some compile-to-js would have shaved off significant time from that 8 month full dev time.
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?
Nope, Oracle clearly says you can in their FAQ:
https://java.com/en/download/faq/distribution.xml
The other thing of course is that Electron apps start out as web applications. So they already work perfectly in a browser.
"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!"
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).
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.
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'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 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.
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.
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.
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.
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.
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 ?
[1]: https://blind.guru/qta11y.html
'nuff said.
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 don't write frontend / GUIs for a living (I tend to do C and Python). But I have done work with GTK+ and Qt, and I have done work with Angular and other random JS frameworks, and the web is so good.
All the complaining about the web is from people who just want it to be better.
I am not a web developer, so I may be way off base.
Java isn't new or unpopular- if people wanted to use it, they would
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.
But Qt has rust bindings, so that’s good to learn!
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.
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.
As a language, I find java is much better designed than Java Script.
Not much more verbose than it needs to be explicit.
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.