Why Electron apps are fine

It is not difficult to find some incredibly shitty takes on Electron, and every time it boils down to: It’s slow. Downloads are huge, and it uses a lot of memory. Electron apps are just websites. Developers that are using Electron are taking the lazy or easy approach to cross-platform development. Native apps are just better in every single way. 

And somehow, these arguments often come from Apple fans when they discover one of their apps isn’t “native” or when a macOS favourite is considering moving to Electron. How dare they!

And on the surface, I agree with pretty much everything that people say about Electron. And at the same time, I don’t care at all. And neither should you.

Let’s take a look at some of these arguments:

It is slow

At its core, an Electron app is a browser but without the user interface of a browser. It is just the renderer, and just like a web app in a regular browser, it uses HTML, CSS and JavaScript to build an interface and provide functionality. Those are a lot of extra layers. And because of this additional abstraction, it can be slower than a finely tuned native app. Sure. But slower is not slow.

There are plenty of fast Electron apps available. There are also plenty of slow native apps. In the real world, Electron apps do not stand out because they are so incredibly slow.

But it uses lots of memory

True. That extra abstraction might mean the app uses more memory than a native app. But memory is there to be used. You paid for it. Why don’t you want apps to use it? 

Of course, you don’t want a tiny utility to take 90% of your memory. But that is not what we’re talking about. And if an Electron app does that, that is because of a memory leak. A bug. And those bugs can happen just as well with a native app. 

And besides, how much memory an app uses is relative; even a single Safari tab can use hundreds of megabytes of memory. Why worry when an app uses the same amount of memory. 

If that Electron app is valuable to you and you have enough memory, why worry about it?

Downloads are huge

Granted. Every Electron application contains a copy of both Chromium and Node, and as a result, it can be pretty big. Something like 400 MB is not out of the question, especially on the Mac, where you’ll have a universal binary for both Intel and Apple Silicon architecture. 

That is huge. That means I can only place 2500 copies of that app on my 1 TB hard drive. The shame! Yeah, hard drives are large enough to not care about this. 

But it is not just about storage. What about the network? 400 MB is a lot to download, right? Or is it? As I write this, my three-year-old son is streaming Paw Patrol on Netflix. I am streaming music to the Sonos in my office. At the same time, my MacBook is downloading a 2.2 GB system software update. All the while, my four security camera’s are constantly uploading full HD footage to the cloud.

Not everybody is as fortunate and has access to always-on, unmetered, lightning-fast internet. And distributing a copy of Chromium with every app is inefficient. 

However, you don’t hear the same people who complain about Electron, also complaining about the size of native apps. But for the sake of comparison, let us look at some: Pages is 651 MB, and Microsoft Word is 2.23 GB. Adobe Photoshop is 3,72 GB. Final Cut Pro is 3,86 GB. And even the native, non-Electron version of 1Password is still 222 MB.

Apps are big. Period. Maybe they shouldn’t be. But using it as an argument against Electron does not make sense.

They are just websites

Yes, you can make an Electron app by wrapping it around an existing website or web app. Electron is a browser, after all. 

But you can also do that with a native app. Just let your native app open a WebView and load that website. There are plenty of native apps that use WebViews for part of their UI. Even some native apps from Apple do precisely that.

But most proper Electron apps do not simply wrap a website. Electron also contains Node and offers lots of functionality not available to web apps, including extensive integration with the operating system. Electron apps can even run native code when it is appropriate. 

Electron apps do not necessarily depend on the network or the cloud. They can be fully standalone, offline apps, just like native apps. They use the same technologies like websites, but they are not the same.

Electron developers are lazy

One of the most insulting arguments against Electron is that people building Electron apps are lazy or taking the easy route. Or they are not proper developers at all. 

First of all, the choices developers make are based mainly on the economic realities of the market. And secondly, an app that is released – no matter the technology used – is much more useful than an app that has never been made.

Let’s look at an example: I make software for hair salons. Our main product is based on Electron and runs in many hair salons in The Netherlands. Over 95% of our users have PC’s that run Windows. So, we have a choice: Use Electron to support both macOS and Windows. Or don’t support macOS at all. 

Building a native app just for macOS is not feasible. Not even if we double the prices. Not even if we triple or quadruple the prices. So the choice is not between an Electron app and a native macOS app. The choice is between an Electron app or no macOS app.

But even if we would start over completely and not support platforms other than Windows, we would probably still use Electron instead of building a native Windows app. Not because I am a lazy developer, but because I know where my strengths lie. Not because I don’t know how to build a native app, but because I like web technologies better. To each his own.

Native apps are better

I’ve never gotten the feedback during the last ten years: “It’s a nice app, but it would be better if it were a native app”. Not once. 

Users don’t care. If you made a great app that is valuable to your users, they wouldn’t care about the underlying technologies. The only requirements are: “Does it do what I want? Does it solve my problem?”. 

Users only care that it works, not how it works.