by Cesare Rocchi

Playing devil's advocate about Electron

tags: electron

Electron is a rampant technology. I am playing with it and I like what I see so far.

During the past weeks there’ve been heated debates about the fact that Electron based apps consume too much battery, CPU, RAM or all of the three combined. Some are even concerned about the size of the apps built with Electron.

An empty Electron app, empty as in it just shows a blank view, is around 100MB on macOS. Electron apps include Node.js and Chromium in the final app bundle.

I am playing devil’s advocate a bit.

If you complain that an Electron app takes too much memory while resting (e.g. not rendering content and not performing background processes) then I expect you to complain also about Dropbox, which consumes roughly 200MB of RAM at least, by default, without doing anything.

Pro tip: pause/quit Dropbox when unzipping a big file (even if it’s not in the Dropbox folder). You’ll notice a speed bump.

If you complain about the size of the apps built with Electron, that consumes precious space on your disk, then I don’t expect you to have the Facebook application on your iPhone. Current version (88.1) is 225MB.

If you complain about too many “Helper processes” that hog the precious RAM of your shiny new laptop then I expect you to have only one browser open, with at most two tabs. I have Safari open here with 15 tabs and each takes approximately 90MB.

Some developers complain that Chromium should be a static library, not bundled in the app. One of the great aspects of “modern” apps is that you download them and they run, no need for external dependencies/SDKs. Unbundling Chromium or Node,js means friction for the final user and trouble for developers.

A foreseeable solution is to include only the relevant parts of Chromium and Node.js in the app. Not an easy task as far as I understand.

Electron is a young technology and there’s still a lot of details to take care of.

Here’s a few:

  • font rendering: a thin eye can easily spot the difference between a purely native and an Electron app, even when using the same font. Maybe it’s just a matter of finding the right combination of values in the CSS, but the difference is pretty evident at the moment.

  • Native feel: for developers, the beauty of Electron apps is to write the core once, tweak the UI to accomodate OS specific issues and run anywhere. I am not sure the tweaking part is easy. Photon looks cool but I didn’t find something similar for Windows.

  • Performance: already discussed above. I am sure there’s great people working on improving the performance of Chromium. Browsers will benefit and so will Electron apps.

Conclusion

We won’t quit writing desktop apps using native toolkits tomorrow. I wouldn’t write a clone of Logic Pro using web technologies. But there’s a growing number of cases in which an Electron based app with a decent performance can make sense:

  • if you are a one man band or a small team and can’t afford maintaining different native apps
  • if you are running a service and you need to repurpose it as a desktop app
  • if you want to test an idea and going native right away is too big of an investment

In an ideal world every app should be native and have a great performance on every major operative system.

Sometimes you have to compromise, use a technology that requires a bit more RAM and CPU cycles but that allows you to build apps in a quicker way on different platforms. Electron seems a good fit in this case.