Why Major Companies Are Using Electron to Build Cross-Platform Apps

Why Electron? When companies develop applications for desktop, they usually need to support three different operating systems: Windows, Mac, and Linux. Correspondingly, each of these operating systems comes with its own requirements and dependencies. As a result, developing the same application for multiple platforms often involves completely separate code bases. In turn, these code bases must be maintained independently. Electron aims to solve this problem.

Electron’s Origins

The Electron project began in 2013, under the name Atom Shell. At first, it was the foundation for GitHub’s code editor, Atom. It would allow Atom to be cross-platform with a single codebase. Later, it got the new name Electron and became open source.

Electron’s key insight was the existing cross-compatibility of web technologies on all platforms. Consequently, Electron leveraged JavaScript and the NodeJS runtime to create its applications. Furthermore, it enabled these applications to exist offline and on any platform by wrapping these NodeJS-based apps in an instance of the Chromium browser.

Significantly, the team at GitHub maintains and improves Electron with help from the open source community. Shortly after it’s release, Electron saw big gains in popularity with major companies. At this time, Electron powers popular desktop applications like Slack, Discord, Basecamp, VS Code, Atom, Skype, WhatsApp, Yammer, and more.

How Electron Works

Building an Electron app is similar in many ways to building a web application. In fact, if you have an existing web application, you can reuse much of the code in your Electron version. Whereas desktop apps used to require different code bases for different platforms, now your application is comprised of HTML, CSS, and JavaScript.

Other projects have attempted cross-platform support by providing bindings to graphical user interface libraries on native platforms. In contrast, Electron uses web pages as its GUI. It combines Chromium browser and NodeJS into a single runtime – the Electron runtime. So, you could think of an Electron app as a minimal Chromium browser with a JavaScript controller.

Outside of initial setup considerations, an Electron app is essentially a NodeJS app for development purposes. Overall, the app’s structure is nearly identical to a NodeJS app. Specifically, the only change for a barebones application is in the package.json file. There, you change the start script from “node .” to “electron .”.

The Good Parts of Electron

Electron has seen popular support and use from major companies for a reason. For one thing, it’s built on the well-engineered and maintained NodeJS and Chromium projects. As a result, it combines the industry best in JavaScript server-side rendering and Chromium’s fast JavaScript engine. This enables a host of other benefits:

1. Native Menus & Notifications

Developers can create native application menus and context menus using Electron’s platform integrations. Then, they render as part of the native application. Of course, menu structures and making the menus “feel” native is still up to you as the developer.

2. Installers & Updates

On the whole, Electron supports installers for all major platforms. In particular, it supports Windows installers so you don’t have to, a major sticking point for many developers. Furthermore, Electron officially supports Squirrel for auto-updates on Mac and Windows.

3. Monitoring

Electron includes built-in support for crash reporting to remote servers and application logging. Additionally, it includes content tracing for performance bottlenecks and slow operations.

4. Low-level Access

One concern about Electron is whether you can get access to devices and other hardware. In fact, developers can get complete access to the all hardware-level APIs via Electron and its plugins.

5. Time-Saving

It’s important to realize that Electron’s biggest benefit is time saved on development. When all versions of your application (Web, Windows, Mac, Linux) share a core code base, you can create and deploy new features much more easily. However, there are caveats.

The Bad Parts of Electron

Electron is not a silver bullet. Indeed, every technology choice has tradeoffs. Electron is no exception. In general, these challenges come from building a native application in JavaScript. Luckily, many of these challenges can be mitigated or overlooked depending on the context of your application.

1. Size

The most commonly heard criticism of Electron is application size. Since Electron uses a version of the Chromium browser, any new application in Electron will need to ship with Chromium and NodeJS. The minimum size for even the most barebones Electron app is ~30MB.

2. Memory Usage

Chromium has a reputation for its demands on the CPU. As a result, Electron apps can also be memory hungry. If you’re targeting memory-limited systems, then Electron might not be a good choice. On the other hand, if your target devices can successfully run Chrome browser, then they can likely run Electron apps. Furthermore, there are steps you can take to limit memory usage.

3. Concurrency

If your application needs true CPU multi-threaded (not I/O bound) concurrency, then Electron isn’t what you’re looking for. Electron uses NodeJS, and Node is single-threaded.

4. Not Truly Native

While Electron does a decent job of creating a native-feeling application, you won’t have access to the widget toolkits of native code.

5. Not Truly Cross-Platform

Out of the box, Electron apps don’t automatically work on all platforms. Specifically, native dependencies can only be built on their own platforms. Therefore, you’ll still probably need different builds per platform, each with its own dependencies and CI pipeline.

6. Delta Updates Support

Each update of your application normally requires downloading, uninstalling, and reinstalling Chromium, Node, and all dependencies. While support has improved for only updating things that have changed (delta updates), providing fast auto-updates has been a challenge for Electron developers. Moreover, the use of Squirrel for updates management has been a sticking point in the community. An alternative project called electron-builder replaces Squirrel with a different approach to updates. That’s outside the scope of this article, but worth looking into.

7. Code Protection

In general, Electron apps ship as asar container files. Thus, seeing the application’s source code is as trivial as: “asar extract app.asar secret_source_code.” For companies who want to protect their code as intellectual property, the lack of encryption is troubling. The Electron team has declined to work on this issue. They say the challenge of implementation and maintenance of a code protection system would be too high.

Explaining Electron’s Rise

Electron simplifies the challenges of cross-platform support. While it’s not a perfect solution, it is a good one that’s well-supported, documented, and maintained. If the negatives listed above aren’t deal breakers for your project, Electron can be a great fit to get a cross-platform native application written and deployed quickly.