Two months ago, I used facial recognition with artificial intelligence to rummage through my digital shoebox of vacation photos on the quest to discover hidden treasures [1]. That made me realize how little I know about the content of my own photo archive. No doubt this unfortunate state of affairs is caused by my laziness, as every time I come home from a trip, all photos from the mobile phone go directly to a folder on the PC. But once they get there, they tend to grow moss, because there is no keyword attached to them to enable finding them later in a search.

Separating Wheat from Chaff

As a first step, I thought about at least taking out the bad photos before archiving the whole batch. It's hard to do this from the command line, because I have to look at the picture to make a decision.

Now there are a number of programs like Eye of Gnome (eog) for viewing and editing photo collections, but I haven't found one that suits my taste yet. I am looking for a lean application that reads images very quickly and, of course, doesn't prompt me to confirm once I've said I want to delete an image  – anything else would be unworthy of an expert. How hard could it be to write something like this myself?

No Exotic Knowledge

Native GUI programming requires exotic expertise – think about the fundamental differences between Gnome, Mac OS, and Windows. A GitHub programmer must have struggled with the same issue to come up with the idea of running local desktop applications in the Chrome browser, which works just the same on all three platforms. And so, GitHub's Electron framework [2] was born.

Electron can bundle GUI programs for all supported target platforms without much additional effort. No comparison to porting a native GUI to other platforms, in which case you might as well start a new project from scratch.

GitHub's Atom editor and Slack – yep, the $5 billion company that develops and ships its chat client for the desktop as an Electron app – prove that Electron is robust enough to drive commercially successful applications.

Historically Documented

Electron was created when main developer Cheng Zhao linked the rendering engine of the Chromium browser to a Node.js process. This links the browser's restrictive sandbox with the offers of the local operating system and filesystem via the Node.js community's extensive range of tools. The main process and renderer always run separately, but somehow have to share a JavaScript context. This is necessary, for example, so that the main process in main.js can dynamically change elements on the displayed page in the browser (Figure 1).

Figure 1: Electron is divided into the main process and the renderer in the Chromium browser code. While the program is running, the two communicate back and forth.

These two processes in Electron are running their own event loops and communicate through Inter-Process Communication (IPC). The Node modules that provide the glue between the two sides are ipcMain and ipcRenderer. For the main process to display in the browser a photo that it has just read from the hard disk, for example, it must first send it to the renderer process, which then refreshes its view of the displayed browser page.