Ask HN: Electron haters, help me understand (your hate)

I wouldn’t use the word “hate”. But.

On resource use:

If it’s just one app then ok. But if it’s several (VS Code, Slack, Figma, …) then it adds up.

Plus there are other things I want to use my laptop’s resources for (hello docker).

It’s simply not reasonable for apps to assume they’re the only resource heavy app I have running.

On being accessible / fast / secure:

It may be _possible_ to write electron apps that are these things, but is it easy? Does electron encourage it? Or does the path of least resistance lead to a bloated mess?

(Genuine question. I’ve never written code that uses electron. My point is that _possible_ isn’t good enough, especially when speed of development is such a selling point.)

I think they try to encourage it, they have security and performance guidelines. I don't know how hard they are to follow or how effective they are.

I don't know to what extent the "path of least resistance lead to a bloated mess". Apples to Oranges, but programming languages like Go and Rust that try very hard for you to not shot yourself in the foot, get lots of backslash too, and Go at least can be just as messy because there is just no substitute for simply good craft.

I agree on the "adding up" of multiple running Electron apps.

Does stuff written in Go or Rust really get backlash from end users? From people who would like to hack on it or build it from source and would prefer a more traditional language/toolchain, sure, but end users who are using prebuilt binaries? Really?

Node.js is a security apocalypse. Any language where you compose your app from unsecured and untrusted finegrained pieces spread from across the internet is going to be.

Having n versions of something as complicated as the browser + deps, rotting at different rates, will eventually be a security problem.

Distribution to a browser by https is very natural and can be reasonably lean, we run remote webapps all day without effort. Distribution of megabloat with an install paradigm is noticeably old and inferior. Similarly, update process of remotely managed webapps is (usually) invisible, update process for an installed fleet is agony.

Arguably electron is a transitional, incomplete form of something that wants to be exactly like remote webapps, even if the server part is on 127.0.0.1, it is insane not to use the system web browser already there.

Comparing to web apps was out of scope, but if I understand you right, I disagree with this.

Many apps should not need an active internet connection. You can't do local first / offline first. Users don't own their data, need to give up on privacy, and you require more trust of them. Users are always forced to upgrade, and don't control the upgrade process...

You also incur recurrent server cost that need to be passed down to your users (as a matter of fact, I suspect that some web apps are an excuse for a subscription where a one-time payment would suffice)

You'd have other problems too, like browser compatibility, etc. I don't think "we run remote webapps all day without effort".

> Comparing to web apps was out of scope

"The framework is designed to create desktop applications using web technologies (mainly HTML, CSS and JavaScript, although other technologies such as front-end frameworks and WebAssembly are possible) that are rendered using a version of the Chromium browser engine and a back end using the Node.js runtime environment."

https://en.m.wikipedia.org/wiki/Electron_(software_framework...

You can run the 'wep app' backend locally on 127.0.0.1 and no need to deliver a specific browser; use the system one a la cupsd. This would be better than 'electron' scheme and doesn't restrict you from implementing a CRDT or similar to blur the line between on and offline with the system browser the UI either way.

> I don't think "we run remote webapps all day without effort".

I mean you and I, as users, run other peoples' web apps all day without effort, or installation. Like, eg, hackernews. This has become extremely natural.

ah ok, got it

There are two paths that can be taken: expedience or elegance.

As you point out, Electron is quicker to develop, easier to develop, works for several common platforms, and with a modern device it will perform adequately. It's the expedient choice.

Native applications are potentially slower to develop, harder to develop, and probably won't work on another platform. But they'll integrate better with the system, and be orders of magnitude less demanding of resources. It's the elegant choice.

An argument can be made for both approaches. Neither is "right", nor "wrong". Some people drive a Kia, some drive a BMW.

I prefer elegance in my software. But I don't "hate": I respect your choice to prefer expedience, if that's what you choose.

Thanks for answer.

> I prefer elegance in my software

Do you mean in the software you develop, consume, or both? Do you reject Electron apps only on the basis of being Electron?

Both: develop and consume.

I don't reject Electron apps, but where there's a native equivalent, all other things being equal, I'll almost always prefer it.

It's perfectly possible to write a horrible native app, which demonstrates no elegance whatsoever. It's also possible to write an Electron app with a focus on elegance in UI, UX, and functionality. And of those two choices, I'd almost certainly choose the Electron app.

But trying to do elegance in Electron is handicapping yourself: you're basically fighting against the system to do something that would end up being easier to do with the native toolkit.

Elegance comes with an unexpected benefit: battery life. If we turned all common applications into Electron equivalents, the battery life would become abysmal with no benefits. If we turned all Electron applications into native equivalents the battery life would increase.

This compounds with scale, so it's using some additional electrical power per each user.

Also you can try and analyse it also as related to the number Electron applications per machine.

> Elegance comes with an unexpected benefit: battery life.

I'm not really sure that's particularly unexpected.

The huge binary size doesn't really bother me, but the a CPU usage does. On my laptop I can't run something like vscode because it kicks the fans on and kills the battery. And as a developer, I hate JavaScript. I'd much rather use a compiled language and use Qt/GTK/etc.

Probably the biggest reason is because it's used too much. Seems like the vast majority of these electron/Tauri apps would work just fine as a website/extension. Maybe that's just me, but I remember back when I was a web dev and I tried Electron for the first time. There wasn't any point in doing it, I was just excited to see my site as an exe on my desktop.

At https://www.waiterio.com/downloads we have 5 native apps Android/iOS/macOS/Windows/Linux

The Windows and Linux app currently uses Electron. Android/iOS/macOS are native apps using the OS Webview to load https://app.waiterio.com

We migrated away from electron to a macOS app with WKWebView. The reason was few years ago Apple increased the security/signing standard, the electron packaging/signing were broken for few months. So in the doubt we decided to try a native macOS app with a WebView and it tooks us less then the fixing of the signing.

We will also migrate away from electron to a Windows app with WebView2. The reason is we want to use a native C++ library/driver called Zadig and we believe it would be easier than trying out the NAPI-gyp way with Electron.

I would have still used Electron in the past as the first implementation and I would use it again in a new company with 0 native apps. Thank you Electron! But goodbye for now!

I see. The risk of Apple crippling non native apps is a good argument. Thanks.

It happened also with the Windows Store once, some reviewer wrote me months after publication about how our app made with Electron would not work on Windows 10 S, a special niche version of Windows with hardened security where apps were installable only from the Windows Store (Apple distopia trying to spread).

In the end we got away with writing at the top a warning "IMPORTANT: This app works with Windows 10 Pro and Home but not with Windows 10 S." Which is still there 7 years later:

https://apps.microsoft.com/detail/9N8X83NF9ZR9?hl=en-US&gl=U...

S-mode was far less about combatting Electron apps and more about privilege escalation holes within Win32 itself. They're orthogonal concerns.

Nonetheless, the Microsoft-managed app ecosystem on Windows is sad for so many reasons. Ask me about Hardware Support Applications....

What about 'Hardware Support Applications'? https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

I might have to add USB driver support to a Windows native app with Zadig https://zadig.akeo.ie so I'm interested in your experiences.

They'd be footgunning their own revenue stream; JS performance on iOS has been a priority since day one. PWAs are a crucial part of the Apple ecosystem.

Why I don't like electron or electron-like apps:

1. Slow & memory intensive.

2. The web browser has gotten terrible with memory optimization

3. Can't Detect which `browser` is the bad actor (RAM or CPU)

Slack shouldn't display a blank screen for 5 seconds on startup on my M2. Not when Ripcord loads instantly.

I haven't built anything in Electron, but I've been writing Qt/QML cross-platform (focus on desktop) apps for a few years and I've found it to be a very productive and fast framework. You could easily write the entire app in JavaScript and QML and never touch C++ if you want.

Just my $0.02.

Slack is just as bad in the browser. My internet was slow the other day and Slack took a minute to load. I opened up the network inspector to see what was going on and one of many things I discovered is that their vendor.js file is over 20MB.

But that's pretty much the point, isn't it? Apps on your computer are supposed to feel (a lot) faster than a website.

But QT eats up a businesses profits. Plain and simple, most businesses cannot use QT for this reason.

My own opinion is that software should be crafted and that means being as simple as possible, but electron and the npm ecosystem is against that stance.

> Native is better, yes, but native is also another form of vendor lock-in.

There will always be vendor locking as no one owns the entire hardware/software ecosystem. I'm perfectly fine using the native platform and you can always abstract away the UI dependency and the other frameworks it offer. The thing is that Apple does provide nice SDKs to create beautiful software and replicating the features in other ecosystem is often infeasible.

> ...allows developers to leverage knowledge of open web standards and a vast ecosystem of libraries, thus speeding up development by a good margin (which is good for users)

My current opinion is that the web is only suited for document based workflows with a little bit of interactivity here and there. And NPM made everything worse because nothing is ever done and everyone is trying to reinvent the wheel. It's like the goal is trying to make everything as complex as possible. It's only the development that is fast, everything else is a slug (maintenance, testing, tooling,...)

> This could be an argument thou for people with poor internet connections and old banged up computers.

I barely recommend hardware to people anymore, because if you want to run a browser and popular apps, the baseline is now an XPS, a MBA, or a Surface. And they still run poorly on these. And fast software is better in anyway. Yes, I want something beautiful to look at, but not at the expanse of waiting several seconds for it to launch, or having to buy a computer with at least 16GB of ram.

> Empirical evidence says it is possible to do accessible, fast, secure apps with Electron.

Going native would be an easier solution.

> No matter what is the domain, the market is saturated, chances of failure are enormous.

I don't think there is an argument against these, although there are a lot of companies that are successful with native products.

I used to hate it when I had too much time on my hands. Once I switched to doing more constructive things, I no longer have the energy to sustain the hate :)

Tried VScode in Macbook M1 and it sound like a vacuum cleaner ever since I launch the app. And I look at the CPU usage graph, it is constantly 200% while doing nothing. Googled why, people said because Electeon underneath VScode but I don't really know if it is true. Simply say, Electron is absolute garbage.

compare: 3 Pycharm instances siting at 10% CPU usage.

Platform-native webviews are the way to go, same as Apple and Microsoft use for macOS / Windows. Let the OS manage the multiplicity of instances and allow the OS vendor to optimize the webview performance.

If you require native speed, there is zero way to get there via Electron without a convoy of wagons.

Electron apps are not fast and are massive in terms of both memory usage and storage usage, it adds up

I switched to VS Code for a few months, but went back to Emacs because VS Code felt relatively "heavy" / unresponsive.

Also, Emacs is a lot easier to modify if one is not a web developer.

Disclaimer: These opinions are my own and may not reflect the thoughts of other people who dislike Electron.

I’ve been making command-line tools for a long time. At one point I had several ideas for non-commercial macOS apps to scratch my own itches. The ideas were simple and self-contained: One was a menubar app, another loaded a specific website and added stuff to it, and so on.

So I started looking into macOS development. I found Apple’s documentation atrocious, and while there are infinite third-party guides on iOS development, macOS apps has less than a handful and they’re all outdated. So I looked into Electron and was sold. The documentation was fantastic and I could build what I wanted. I built my apps and they were good. The file size was enormous but performance and resource consumption was better than any other Electron app I had used. Higher than native for sure, but due to the lack of resources to learn, the alternative would have been for those apps to not exist.

All was well, until time passed. Contrary to what I see people mentioning all the time, it is possible for software to be done. I have done it multiple times. I have several tools that work exactly as I want and no longer need to touch. Not so with Electron and NPM. There are so many dependencies for everything. I avoid third-party dependencies as much as I can, but with Electron and NPM that’s next to impossible. And every dependency depends on a ton of other different crap, their APIs are always changing, and new security holes are popping up all the time. Every time I wanted to make a new Electron app, or make a small feature addition, or even just update packages, I’d have to reread documentation and rewrite parts of my application.

Screw that. I don’t want to spend my life babysitting software. Especially when I know the alternative exists.

Then I started noticing a ton of other problems with the overwhelming majority of Electron apps. They are slow. You open them and there’s a moment when the interface is still loading; the controls never look quite right; they lack support for automation features like AppleScript; they consume more energy; they noticeably bog down the system when you have several of them open. You’re constantly being reminded the app is not native, it’s a bad experience.

Eventually I transitioned from scripting languages to Swift, and while I don’t typically make GUI apps and the experience can be frustrating at times, it is always rewarding when I finish a project and don’t have to touch it again unless I want to. Like any hard and interesting problem in life should be. The other day I was obsessing over how adding a feature to my command made it go from running in 6 milliseconds to 7. Good problem to have.

Look, I don’t like software wars. Use whatever the heck you want for yourself. But I for one avoid Electron because apps are always worse than they could be, and the reason I became a developer in the first place was to have the ability to make computers behave how I want. Thankfully this is a sentiment shared by the best indie developers. I’d rather be in that company.

Point by point:

1) If Electron fails, you are fucked on all platforms: a worse worst case than the fragmented lock-in of multiple native platforms.

2) JavaScript sucks, and as noted in other comments the "vast ecosystem of libraries" is even worse. Overcomplication is part of the problem, not of the solution.

3) Startup times and memory occupation add up, and then the wasteful Electron app causes more problems than it solves.

4) Platforms that appeal to ignorant hipsters tend to be used badly. Not Electron's fault, but Electron is a warning sign, well correlated with all sorts of problems.

5) Electron might be the "only" option if you are an ignorant hipster, chained to JavaScript and behind the times; but there are still plenty of competent people and reasonable projects that can adopt less super risky technology.

Unwelcoming stereotypes and labels were not called for. Arguments were called for, which you give 0.

The "ignorant hipster" comment is uncalled-for. There's nothing wrong with accessible tools.

But I agree with all your points.

With regard to point 4, if I download a desktop app for my Macbook and it's Electron, I see it as a sign of minimal commitment to user experience. They prioritized cost over my experience and I'm probably not going to choose that app unless there are no other options.

I do the same with iOS apps. If it's not native, I'll usually delete right away.