Why not to build an Electron App

Prasann Shah
Nov 3, 2018 · 4 min read
Image for post
Image for post
Our App almost crashing the fragile windows machine

Electron seems to be an awesome technology. The amount of apps currently being built using electron is a testament of that. But if you see the most successful electron apps, they are being supported by engineers solely focused on optimising electron and making sure that the app doesn’t end up crashing the customer’s machines.

Imagine a startup just starting their first POC or just getting off the ground. At this point all you want to focus on is the problem you are trying to solve. You absolutely don’t have resources or time to solve challenges which are not the core of your business.

Simply put if you have enough resources to focus completely on optimising the desktop experience, electron might just work out for you. But that isn’t the case for most of the startups I have met. They are majorly front end guys unaware of systems complexity when dealing with high RAM utilisation or minimising inter process communication.

In our case, we took on a challenge of building an enterprise SaaS product using electron with 5 front end ninjas. We had enough knowledge of how to build awesome apps using JS, React, CSS and UX magic. We were completely unaware and unequipped for the challenges we were about to face building an electron app.

In this article I am not going to be listing down the pros of using electron. I will rather be focusing on the cons of electron and any desktop app in general. This is a list of challenges i have listed down from our experiences in building our Enterprise SaaS app in Electron.

Inter-Process Communication (IPC)

Image for post
Image for post
Every data you store locally is communicated back to main process to store on disk

We build our app considering being able to work offline as our primary goal. We used RxDB as our database and all information was synced between our servers and the local database every few minutes. This relied heavily on the users system to be able to write data really fast. But as it turns out a lot of our users have crappy systems where disk read writes are extremely slow ( 5400 rpm hard drives!). This lead to the systems starting to experience performance issues.

Consider a 4GB RAM machine with a dual core processor with chrome, outlook, excel and an electron app open. Needless to say, the systems almost crashed. It became impossible for any user to get work done.

Later we optimised the read/writes, moved the writes to background processes, reduced the requirement on offline with storing only essential data etc. But it took a lot of months of focused optimisation and refactoring which we could have spent concentration on the product and the problem.

RAM Utilisation

Image for post
Image for post
Imagine Chrome open on your machine with 3 other electron apps

Electron runs a chromium process and renders your JS and HTML in the window. Which is like running another chrome instance in a machine which may not be able to give you enough resources.

Chromium hogs memory like crazy.

This was never a secret. Being able to realise that fact we pushed our customers to opt for better machines, but considering the list of frictions we already had in on-boarding enterprises this just increased it more.

Slower Release Cycles

When you are starting up, you need speed. You need to release as quickly as possible and there will also be a lots of production bugs popping up which need to be solved even faster.

But considering the fact that the smallest electron app we could come up with is 100 MB and each bug fix was a release which auto updated by downloading the same again on each users machine, it seriously slowed our release cycle.

We ended up delaying release of bug fixes because users complained on how many times they have to update our app. Plus in some organisations, the end users didn’t have the permissions to install new apps. Which meant they didn’t have permissions for updates too. This meant the IT guys in organisations having to update in every users machine leaving them frustrated.

Desktop Bias

Presenting them with an electron app built with JS and HTML ( which is significantly slower than the counterpart) created a mismatch in expectations.

Performance Testing

There isn’t much available for testing electron apps for performance. The renderer process can be tested using standard frameworks and chrome profiler. But if you wish to test the app with IPC messages and main process memory consumption when interacting with a particular screen, you need to develop something custom.

This sadly also meant debugging performance issues in electron to be a seriously tough task.

We have spent countless number of hours debugging performance issues happening in the system, connecting to remote machines and trying to analyse what exactly is eating this system up…..

Conclusion

Please be aware of the potential problems of desktop and specifically Electron apps pose.

Shipmnts

Reinventing Global Shipping

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store