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

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.

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.

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!

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.

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.