Hacker News Reader

Comment by capelio | Hacker News Reader

Even so, Java is now at a place where you can ship self-contained, zero-dependency applications that are comparable in size to other compiled languages (and superior to web-hybrid options like Electron).

For cross-platform desktop GUI apps, I would argue that JavaFX combined with Java 9 modularization is hands-down the best choice available today.

Electron is succeeding in the desktop GUI space because it tears down the barriers to desktop app development. While the author's article is excellent, when it comes to Electron, he (like most engineers) is still missing the point: the choice between Electron and its alternatives doesn't pivot on file size.

View on HN

Well, will see how Electron will pan out in the end. While I dislike default Java Swing GUI (it can be made easily to look native but many devs previously did not do it), JavaFX can be made to look like anything with almost weblike feel to development and animations. Now, more than the looks I dislike the slowness and utterly unacceptable memory Electron apps consume. I ditched Electron and VSCode (it is a little better than Atom) because I don`t want to have my text editor eat 500mb ram to open 1 medium file and crash on large ones. Same for Slack and other Electron apps. And it is not even funny to see dev console when some Atom plugin or whatever crash. I`m interested how many devs also ditched this two editors ONLY because of Electron bloat.

Electron pop culture made me buy Sublime Text.

For me it finally pushed me enough to switch to Vim for web dev work. But I do have Sublime for just in case.

What a breath of fresh air Sublime is.

Probably not many. They are too busy developing instead of over obsessing over small performance gains

It's not a small gain for me, it's basically a necessity for keeping RAM low enough. I have 16GB on my work machine, and that's barely enough.

Your comment ties in so very well with an above exchange concerning resultant binary sizes. RAM was once $100 for a MB, I paid $400 for 4MB of RAM.

Shocking, when I look back at it.

My cursor lagging is not a small concern. It disrupts the flow between code being re/written and the mental model I'm trying to pour out.

Text input lag is an issue every editor has to deal with, and many go to extreme lengths to optimise it. Electron makes it far more difficult than most editors to fix, and every lag issue opened on VS Code seems to get decent attention, (and patches), and comparisons to Sublime Text.

Seems to be something I'm not alone in caring about.

There are probably more people hopping onto VS Code than people jumping off.

I'm using JetBrains IDEs now instead. They're definitely not lightweight, but it's built in functionality is generally a lot more stable than what I get with text editors + a lot of plugins.

Yes, but it's electron.

I've honestly seen only one properly written Electron app and it's VSCode. Everything else electron sucks. VSCode is not great either but it's much better than say, Atom or Slack.

Discord is great

So is gitkraken.

But I assume these apps have spent a considerable amount of time in optimizing electron, which not everyone can do.

While some may find GitKraken visually pleasing, it can't be used for big repos; didn't even manage to open a few of the ones I tried.

I was curious as I've never found a standalone visual git client I liked as much as IntelliJ's integrated one. So I downloaded it, found it was 1/4 of a GB and wouldn't look at a local repo without logging in to a web service. Deleted.

It never used to require logging in but the moment they added that I deleted it.

Some years ago I was evaluating GUI git clients (the landscape has changed since) for rather simple flows and found SmartGitHg simple enough to setup and explain in under an hour and powerful enough not to drop to a shell. No affiliation here.

I still haven't found anything better than IntelliJ's triple column view for resolving merge conflicts. Is there anything similar in a more lightweight editor?

If you don't mind having it separate from your main editor, Meld is great.

Interesting that this is touted as one of the "best" uses of Meld[0]. Will try this out tomorrow.

0: http://meldmerge.org/help/resolving-conflicts.html

Sure, but Discord's web app and their native app are basically equivalent. The native app gives a little more system integration (like global hotkeys and direct access to sound hardware) but fundamentally the Discord app is just a webview.

I don't think anyone doubts that a high-quality website wrapped in a webview won't be at least the same quality. The question is whether "web-native" platforms can do more than just be a branded browser.

Slack?

stutters horrendously very often for my work setup (~800 people). also eats tons and tons of memory and kills my battery

Anecdotal problems

Another anecdote; your comment is the only one I've ever noticed that appears to be defending Slack. From an outsider looking in, I'm not sure why it is so popular.

It's popular because technical superiority isn't why people use software.

For example, Spotify eats 100% CPU if I leave it open for 24 hours yet I don't think I've met someone in the last year that doesn't have Spotify running on their computer.

If it helps, I don't have Spotify.

Slack takes up 1.3 gb of RAM if I don't restart it at least once a week

>tears down the barriers to desktop app development

Yes, then it replaces them with the barriers to web app development.

Sure, but more companies have the story of needing a web app anyway which requires a specific tech stack. So you can either maintain two tech stacks or you can port your webapp to native.

Having a beautiful, easy to develop, and easy to maintain native stack means nothing when you don't have an answer to, "How do we then reuse our code in a browser?".

You don't.

Use the browser for what it was meant for, hyperactive documents.

Everything that matters is on the backend accessed via Web APIs.

Electron sits in the same hybrid space as Cordova/Phonegap, and will suffer the same fate once React Native, or something similar, starts eating its lunch.

There are some ReactNative alternatives calling themselves "native" that are only "native looking css in a webview". The future will probably only get more ambiguous.

I can be, for very small very cheap devices.

It’s really not clear what the electron app even provides over the same app in chrome. Its own icon, sure, but the behavior is just as bad as on the web—just take slack for example.

It offers access to file system and system resources as well as multi platform build support. Developers like all people will whine over anything. For students and indie devs who have little time, support, and resources things like electron are great

Right, but does eg slack actually use any of that? It’s not a great native client by any stretch—it doesn’t use a native UI, it’s not particularly snappy, and it doesn’t do any special integration. So, it seems that electron is mostly a way to distinguish certain sites from others, not that they provide a better experience.

Granted I do like the distinct app icon. But electron should mean more than that to qualify as meaningfully native.

What electron gives Slack is A) local install and B) proper notifications.

So Slack gets an icon on the homescreen and possibly offline notification + notification integration with the OS.

That might be pretty limited from a technical perspective, but it's a massive product thing from a product perspective.

Also, it's possible they may use file access for caching/storage etc..

Not closing and losing your data when your chrome crashes?

Reply on news.ycombinator.com