Electron is a hulking monstrosity of a WORA framework, and it needs to be replaced.
I’ve done web design and development for six years. I’ve worked on app design for even longer. I use Slack, Atom, and Discord on a daily basis. From all of this, I’ve learned one thing: Electron is an absolute mess.
To get a proper understanding of why Electron is such a mess, we need a short history lesson. In 1995, a company named Sun Microsystems released a programming language called Java. It came with the promise of programs being Write Once, Run Anywhere, or WORA; any Java app could be compiled once and run perfectly on any platform due to the Java Virtual Machine, a VM installed separately by the user that processes all Java programs in a way the main computer can handle. However, this led to an issue: since all Java apps depend on the same singular JVM, and since Java can have huge changes between versions, fragmentation became a major issue with Java apps and users. On top of that, any malicious code from a single Java app could affect the JVM itself, blowing a hole wide open for other apps to take advantage of.
Fast forward to 2014. Java is one of the most widely-used programming languages in the world, but most of its use is on servers. This is half due to Oracle, its new owner, selling the OS for most of those servers. The other half is because Java has been, on desktop, almost completely abandoned due to the major issues the JVM drags along with it. Java’s exploded on mobile, where the sandboxed nature of apps and the moderation of app stores prevents major issues like on desktop. However, that means that there’s room for a new WORA desktop system. Enter Github’s new text editor, Atom. Instead of designing native apps for Mac, Windows, and Linux, GitHub decided to write a framework that would let them write one app in HTML, CSS, and JavaScript, and then export it to run like a native app on any platform. While running webapps in a native shell was not a new concept (the Chromium Embedded Framework, or CEF, that Electron is built on has existed since 2009 and runs everything from Spotify to Second Life), Electron was the first to market itself as a WORA replacement for Java, promoting the sandboxed, separate, and auto-updating nature of Electron instances to avoid the fragmentation and security holes of the JVM.
However, this is where the problems begin. Since Electron apps are sandboxed, they all come with their own dependencies and resources. That means that, for example, if two electron apps both require jQuery, they each have to import and install their own separate version of jQuery. This isn’t a problem for a typical webpage, because all those resources are stored on the server and are only on your computer when you’re either actively on the website or have it in your cache. With electron apps, however, they’re constantly there, bloating your drive with duplicate frameworks that are left as plaintext since JS isn’t compiled into native code. In a browser, not compiling JS isn’t a problem since browsers have shared caches that let you share scripts between websites that need them, but the sandboxing of Electron doesn’t have a shared cache. On top of that, while the separation of Electron instances prevents having a single vector for attacking vulnerabilities, it also removes the single vector for patching vulnerabilities, like the one found recently. Each Electron app needs to update individually, instead of Java’s security patches to all supported JVM versions.
Electron’s last, and biggest, problem is the sheer amount of memory bloat that having separate instances of the same framework running simltaneously causes innately. With a central system for processing all the instances like the JVM, Electron runs the entire Electron framework, V8 JavaScript engine, and CEF for each and every Electron instance running at a time. Programmer Rory is OK wrote an article last August doing a rough analysis of RAM usage of basic WORA stacks using a Hello World app, and out of the eight tested, Electron was the most intensive, using nearly seventy megabytes of RAM to display a single <h1>hello world!</h1> HTML string. Making an actual functioning app on top of that increases the load to levels that make it practically impossible for many people to run more than one Electron app at once.
Electron’s bulk is primarily a symptom of what could be roughly compared to the environmental scenario of the Tragedy of the Commons; a scenario where there’s such an apparent abundance of a commonly-shared resource that people use far more of it than they should, leading the resource to be wiped out. With the progression of technology, drive space and RAM have gotten higher capacity and cheaper to manufacture, but folks in richer areas like Silicon Valley are able to afford much more than folks elsewhere. Many areas in the US and the world at large don’t have the level of storage and memory abundance that the programmers making apps do, so they’re hit much harder by the flaws of Electron than the people creating Electron apps are. The necessity to conserve storage and memory doesn’t exist for devs with terabyte drives and dozens upon dozens of gigabytes of RAM, so they don’t factor in the inefficiency of frameworks when designing apps. Web development is easier to do, so devs default to web development without thinking about what impact the frameworks they’re using will have on the usability of the product.
Ultimately, the fundamental problem with Electron is that it was designed as a WORA framework. WORA systems trade efficiency while running for efficiency while programming, making it easier for devs to make a product to meet harsh deadlines and expectations of investors or shareholders. A native will always outperform a WORA app, especially a web app yanked off the internet and shoved into a WORA app shell. WORA apps aren’t going to go away any time soon, because the ease brought by only having to make and debug one app for web, Mac, PC, and Linux together instead of one for each both lowers many barriers in front of app development and outweighs the cost of inefficiencies in the eyes of developers, but there are better frameworks to use for WORA than Electron.
