Electron memory usage compared to other cross-platform frameworks

1411 words , , , , , , , , ,

Electron is everywhere you look these days. As a developer seeking to build cross-platform apps, it’s very appealing. It’s free, easy to use and quick to develop with. It’s a very fast way to get an MVP (minimal viable product) to market. On the other hand, a lot of programmers who are smarter than me have a real issue with it.

Every time Electron is mentioned online, you’ll invariably hear the opinion that Electron apps use 300+ MB of RAM and run like a dog floundering in molasses. “Why can’t people write native apps anymore?” the coding elite cry. Maybe the people who make these comments have a point. Native is surely faster than javascript running in a browser instance. But just how much faster?

I decided it would be fun to compare a few different cross-platform approaches and see how they stack up, memory wise. The results had a few surprises.

I created a simple ‘hello world’ app across the various frameworks, with one slight twist – hello world would be an html string <h1>hello world!</h1>, so any given app would need to be able to render HTML. I based this off the Electron quick start app.

Disclaimers:
I am not a scientist.
I simply used task manager to check the RAM. Your mileage may vary.
HelloWorld is hardly a good real world test, but I don’t have time to write a full app in each framework.
If I removed the HTML requirement and just went with plain-text, the non-javascript frameworks might be leaner, but there are plenty of real-world use-cases for displaying HTML in an app.

Please don’t treat this post as a serious study – it’s just one programmer’s experiment.

 HelloWorld <H1> App
(Ordered from lowest to highest RAM usage)

Tech Processes Total RAM
Xojo 1 12MB
Xamarin.Forms/C# 1 20.3MB
Python/Qt 1 20.8MB
Java 1 24.9MB
NW.js 5 55.3MB
qbrt/HTML 2 59.6MB
ReactNative 1 65.6MB
Electron 5 68.9MB

Xojo – Based on a proprietary version of BASIC, Xojo can target macOS, Microsoft Windows, Linux, iOS, the Web and Raspberry Pi. I’d heard of it a couple of times, but never played around with it until I decided to do this comparison. It’s got the lowest RAM usage of any of the tested frameworks. Unfortunately, it’s not free – it starts at $299 for a licence to build desktop apps (macOS, linux, windows). Every other cross-platform framework on this list is free to use. Also, since installing the framework my phone browsing is now plagued by ads for Xojo. It could be a coincidence, but it seems unlikely.

Xamarin.Forms/C# – Microsoft’s cross-platform framework runs on Windows 10, MacOS, Android, iOS, and Windows Phone. It’s free, and memory usage is great at 20.3MB, although some of that could be hidden behind the UWP processes which are embedded within Windows 10. For this reason it’s difficult to say exactly how much RAM is really being used. That said, I did build the same app out in WPF, and the RAM usage was very similar, so maybe it is reported accurately. If we give it the benefit of the doubt Xamarin.Forms has the lowest RAM usage of any free cross-platform framework. Just bear in mind it can’t be used on older versions of windows.

Python/Qt – often touted as a preferred alternative to Electron, and you can see why. 20.8MB is pretty effective, just a fraction more RAM in this test than Xamarin or Xojo. However, I’ve heard grumblings about Qt licencing.

Java – it’s been years since I wrote any java, but it came back easily enough. A simple JEditorPane inside a JPanel allows me to render our HTML. Java does very well, holding steady at 24.8MB. Java is a very accessible and proven programming language, and being the development language of android apps has given it a massive boost in popularity lately. You don’t have to look far to find resources to learn Java

NW.js – NW.js is pretty much the same thing as Electron. it uses Chromium, but it has one handy feature that the apps can be distributed WITHOUT the runtime, which reduces file size considerably. NW.js used 55.3MB in testing to render our index.html. This is a big jump from Java – more than double the RAM.

qbrt/HTML – This was my first big surprise. I’d never heard of qbrt before researching this post. It’s a little known project by Mozilla engineer Myk Melez. It replaces a previous project, Positron, which was a Mozilla Gecko based Electron alternative, which maintained compatibility with Electron. That project has now been discontinued, and qbrt is the replacement. It’s in the very early stages, not ready for production, but it is worth keeping an eye on. Firefox is enjoying a lot of performance improvements lately, thanks in part to a rewrite in Rust, and these improvements could eventually lead to something which runs leaner than Electron with the same speed of development.

ReactNative (for Windows) – The biggest surprise of my testing was that ReactNative for Windows used only slightly less RAM than Electron to show a simple hello world. 65.5MB was used. ReactNative is often touted as a much better way to write cross-platform apps using JavaScript. Granted, this app included React where the others did not, but React-native requires React. If you were to add React to Electron the RAM would probably go up, but of course you don’t need react in Electron, or any of the other alternatives on here.

Electron – The Electron quick start app is already <h1>hello world!</h1>. All I did was remove the code that checks for version, though I doubt that had any effect. 68.9MB used, across 3 Electron processes and 2 node.exe processes. It’s not exactly a 300MB hog, but it is more than twice the RAM usage of Java and three times that of Python.

Just for fun, here’s the memory usage of that same index.html in all the various browsers I could think of

Browser Processes RAM
IE11 1 20.7MB
Chrome 5 82MB
Microsoft Edge 4 139.5MB
Opera 7 146.3MB
Firefox 1 160MB
Vivaldi 7 244.9MB

I was very surprised to see chrome’s memory usage so low, since it is often called a memory “hog” next to the others. In fact, only IE11 bested it on memory (another surprise). But this is not a test of browsers, I just thought it was an interesting comparison to the above frameworks.

By these tests, Electron is fairly deserving of its reputation as a memory hog. This is no surprise I guess. What may be a surprise is that:
1) ReactNative is not any better and
2) Xamarin.Forms apparently uses less memory than Python/Qt

When Electron gets called out, it is often compared unfavourably to a browser running the same app. The Slack app, it is claimed, uses more RAM than simply running Slack in the browser. However, in my tests, Electron used less RAM to display the hello world HTML than even the leanest Chromium based browser. It’s all academic really – if you fire up a browser to use Slack, it might use more RAM than the dedicated app – but the chances are good that you’ll have other tabs open. If every tab you have open in your browser right now was an Electron app, you’d have no RAM left at all.

The thing about Electron is, there’s a time and a place for it.
VSCode is an excellent use case – a complex cross-platform IDE with a very quick release cycle, a large plugin ecosystem and a requirement for display and processing of a lot of different types of markup. But I’ve also seen a tray notification app built in Electron. An SD-card formatter. A “quick” launcher. These things can and should be built using Xamarin, or Python or Java instead.

This is just a surface comparison of course. Memory isn’t everything. There are so many more reasons why you might choose one framework over another. Ease of use. Familiarity. Toolset / IDE. Licensing. But Electron discussions almost always come down to memory, and that’s why I wanted to write this post in the first place. I’d love to re-visit these frameworks in more depth in a future post, and maybe add a few more to the list.