Electron apps: A saviour or a curse?

CHANCES are, you’re using an Electron-based app and don’t even know it. Apps written on the framework include Hyper, Skype For Linux, Postman, Compass, Zeplin, and Slack. Plus there are hundreds of apps available here.

So what is Electron, and why does it matter?

Electron is a framework for creating desktop apps, using simple tools at fingertips of most developers: HTML, CSS, and JavaScript. The advantage of these apps is that they are cross-platform, self-contained, and offer a unified user experience.

Like in the early days of the iOS App Store announcement, the apps are in fact web-based applications, which, when packaged up are full runtime environments with access to installers, automatic application updates, and any native features available to the JavaScript API: menus, dialog boxes, windows and so forth.

Developers working on creating web apps can, with a few extra hours’ work, port their apps to be standalone applications to be distributed to users’ desktops, on whatever platform they happen to prefer: Linux, Mac or Windows.

Electron’s roots are in Atom, which began life as a bare-bones text editor, like Emacs, Vim, or, if you must, NotePad. A cross-platform application shell was developed, and from this, Electron was born.

An Electron app renders its graphical user interface using the Chromium engine, and developers have access to APIs for OS integration, so don’t have to worry about specifics for each version. Shortcuts/aliases, main, and contextual menus are available, as is full window management such as maximize, minimize, roll-up etc.

Wrappers are available for creating installers, and with a little experimentation (a version or two of each target OS running in a test environment is probably a good idea), applications can be rolled out by web development teams in no short order.

So far, so rosy. But developers should be aware of several downsides to the Electron framework:

• Memory use: each Electron app comes bundled with a full web runtime environment, despite the fact that such an environment will, in all likelihood, already exist on a client machine: WebKit or Edge, for example.

So, if the user needs to run several Electron apps (and there’s no particular reason why users would know they were running Electron apps) then the machine starts to slow down as memory is paged to (slower) hard drives.

• Disk space: each app comes with 100MB+ of (theoretically redundant) code in the form of the web runtime. While this is not a problem in terms of download times or traditional HDD space, users of smaller, fast SSD drives may find that they start to run out of space more quickly than expected.

While Electron offers a quick way to produce apps which run on a variety of platforms, it is probably good practice to replace the Electron framework with native code bases should the app require more than simple functionality. While the term ‘simple’ is relative, and the WebKit or Edge allows a greater amount of functionality than could have been dreamed of five years ago, a ten second startup time for an Electron app will soon start to chafe for even the most dedicated user.

Interestingly, the computing paradigm Google posited when the Chromebook range appeared in 2011 is increasingly valid – as Electron apps prove. Namely, that a web-based working environment is eminently practical for the majority of users, and the old habits of local installations may soon be left behind.

---

---

---