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.
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.
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.
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)
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.
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
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.