Put your Electron app on a diet with Electrino

Meet the 99.9% weight loss plan for desktop apps built with web technologies

Electron is a popular runtime that lets you build cross-platform desktop apps with web technologies. The appeal is tremendous: a software developer who already knows HTML, JavaScript and CSS can leverage that knowledge and turn their website into a real app that runs on all PC and Mac desktops out there. Some of the most widely used apps made with Electron are Slack’s desktop client, Microsoft’s Visual Studio Code and the Atom editor.

The downside of the Electron approach is that each app comes with a copy of two large software frameworks, Node.js and Chromium. The latter is technically a web browser engine, but as the web platform has expanded, the humble browser has turned into a sprawling software layer large enough to be an operating system of its own. Bret Victor did the math and counted 25 million lines of code in Chromium! (Windows 10 is estimated to have between 27 and 50 million lines of code.)

So, each Electron app essentially carries an operating system with it. The “Hello World” app for Electron weighs 115 MB. This code exists both on disk and in memory: when the Electron app starts, it must load these libraries to RAM. Because Electron apps are separately packaged, each app loads a separate copy of the libraries (even if the libraries are exactly the same version, the operating system doesn’t know that).

This overhead is not really a problem for large apps like Visual Studio Code. It does pose a problem for smaller apps that would like to use the Electron model. Many developers are now using Electron to build desktop utilities and even menubar widgets (those little pop-up menus that live in the top-right corner of the Mac menu bar). A typical desktop user may have a dozen utilities open. If each of these has a copy of the whole Electron stack in memory, it wastes over a gigabyte for essentially nothing. Memory sizes haven’t increased much in recent years (expensive MacBooks still come with 8 GB), so this doesn’t seem like a sustainable direction.

How to lose 99.9% of weight in an afternoon

For small apps, there would be another way. Instead of bundling the web runtime with each app, they could use the system-provided web runtime instead. Both macOS and Windows contain a competent modern browser engine (WebKit on Mac, Edge on Windows). This engine is typically already loaded in memory. By using the system-provided runtime, Electron-style apps could become much slimmer both in terms of on-disk footprint and RAM usage.

I’ve just released the first version of a runtime named Electrino which does exactly this. Its goal is to be API-compatible with Electron (i.e. you can just copy your Electron-using JavaScript app’s files into the Electrino binary, and it will run).

In the screenshot at the top of this page, you can see a comparison of identical “Hello World” apps between Electron and Electrino: the latter is only 167 KB in size. That’s only 0.1% percent of the size of the Electron app (the Electrino app is almost a thousand times smaller!).

Now, this comparison comes with an enormous caveat. Electrino is just a proof-of-concept. It implements exactly the APIs that are needed to run Hello World, and nothing else. (The web browser itself is of course fully functional; the missing APIs are Electron-specific ones that let you tie a web app into the desktop world.)

As new APIs are added, the size of Electrino would inevitably grow… However, I can see a strategy that would keep the size of created apps down to a minimum. Because Electrino is so simple, one could make a build tool that includes only code for those APIs that are actually used by the embedded JavaScript app. (The need for that kind of tool is certainly not immediate — on the medium term, a lot of APIs can be added without ballooning the Electrino binary by more than a few megabytes.)

Next steps

So far Electrino is only good for launching web apps that don’t interface with the rest of the operating system (due to the lack of API implementations). To proceed towards something actually useful, I feel the best way would be to analyze real-world small Electron-based apps and implement just the APIs they need.

So, anyone out there with a small Electron-based Mac app that you’d like to put on an Electrino diet? Ping me, and let’s see if we can make it work!