A topic that comes up frequently at Sonatype is something called the “software supply chain.” The term is based on how supply companies send parts to manufacturers who assemble them into things like cars, laptops, and musical instruments. This “chain” is an important focus because the connected links of a quality, speed, and consistency behind those parts means a competitive edge.
My introduction to this topic was close to home: I use multiple messaging programs to chat with friends and family. I noticed that they all had similar component files.
This is due to a core that all the programs share called “Electron,” an open source tool set for rapid software development. In fact, most programs that use this framework borrow the same or very similar components with only a small percentage of differences. This is indicative of the wider software industry: they take parts from different places, configure them, and distribute or sell the result as part of a service or a program unto itself.
Popular programs include Microsoft Teams, Skype, CrashPlan, Visual Studio Code, Atom, and many more.
Why use Electron?
By including the Chromium interface (used in the Edge and Google Chrome browsers) and Node.js components, the program leverages an already secure environment of web applications, but run on your local machine. By bringing web tools to the desktop, web developers can now function as application developers. People traditionally attached to web graphics and animation? They can assist with developing user interfaces.
The result are familiar and good-looking applications that are easy to distribute across multiple platforms, including Windows, Mac, Linux, and mobile.
Issues with Electron
The decision to use this framework does come with some down sides, but these concerns belong just as much to the broader industry (the software supply chain) than a failure by the developers behind Electron.
Component selection – Similar to how reliable but heavier parts can affect fuel economy in cars, the program includes an entire web browser – one that’s notoriously resource-intensive (Chromium). This means that running multiple Electron-based programs can slow down your computer.
No maintainer, no software – The day that the project maintainer steps away, all of the software included will start to gather Electron vulnerabilities as they’re discovered. Although programs that don’t require an Internet connection like MarkDownEdit may not be affected by these issues, software like Bevel Download Manager (in early Beta) could become a security issue.
As we’re fond of saying, software ages like milk, not wine, and being outdated is a problem.
Introduce problematic components – Although the main project is carefully maintained, it’s possible for component additions to create security issues.
Merging the Components
One answer to the problem of bulky Electron software is to unify all the different programs under one download. This helps reduce the burden on your hard drive and processor by just having one copy of the many software components. It’s a bit like having a single generator supply energy to your entire home.
I’ve had some success with these programs, notably the open source Ferdi, but this unfortunately can’t hope to cover every Electron-based software program on the market. So, at least for now, running multiple programs on this framework could mean a hardware upgrade for more RAM.
Alternatives and Beyond
Electron isn’t the only home for rapid, cross-platform development. A variety of alternative frameworks exist, notably the Open Java Development Kit (OpenJDK) and the Qt framework. These can also enable quality software but all tools should be evaluated based on their merits.
Will the Electron continue to power software on our computers for years to come? Just like most other programs available today, it’s tied to the changes of the broader software supply chain. The component projects that make up the toolset, including Node.js and Chromium, have just as much to do with that future as Electron's owners and maintainers.