Electron 7 is here

Well, almost :-) As of October 22nd we expect it will be. A lot of open-source projects release whenever suitable (which is perfectly ok) but the Electron development team has stated they intend to release consistently every 12 weeks (so a release every alternate Chromium version). Check out the release timeline. As Electron is a developer platform and has a lot of dependency on Chromium, that makes sense, and that time-frame can be pretty useful. If you were targeting to release an Electron app in early 2020, you can figure that there'd be at least a few minor bugfix versions released yet a few months available for developing on a stable version if you started now.

What is Electron?

In a nutshell, Electron takes the Chromium (ala Chrome) browser framework, adds in Node.js and allows you to use web development libraries (e.g. React) to build a desktop application. So that web thing you've written can be packaged as a desktop app. It's pretty trippy when you write a bit of code and then pull it from a repo and run it on Windows, then Mac and then Linux! But it's not quite that simple. There are subtle differences in each platform - the most obvious being menu differences - Windows has a menu per window, Mac has its omnimenu. So invariably there will be a bit of code for platform checking for menus, toolbars, the dock, tray, etc. Conceivably you could write a no-menu windowed web-app but it probably wouldn't feel very native to the OS. So there is likely time required to determine how to structure, build, and package your application for each OS. Still, as a web developer, it means you can start thinking about all those webby ideas in the context of a desktop app as well.

If you've read the threads at Hacker News, you've probably seen that in the past whenever Electron is mentioned there's a lot of negativity. Most of it directed at Slack's desktop application. But, they've fixed the memory-hungry beast that was their desktop app.

Slack Desktop memory usage comparison

And Visual Studio Code which StackOverFlow reported as the editor used by over 50% of respondents(!) in 2019 is based on Electron. Visual Studio Code is a very capable editor and a great testament to what can be done on the Electron platform.

The Electron Architecture

Electron's architecture is, as you would expect, similar to Chromium. There is essentially the main process and a render process per window. Chromium has a process for each tab. In Electron, it's similar. Each render process runs your usual HTML/CSS/Javascript in its window.

The main process creates each render process (a new BrowserWindow object) and the main environment seems pretty similar to a NodeJS application. It used to be that a render process also had access to the NodeJS API (so you could use ES6 imports and require in the same Javascript!) but by default, that doesn't occur anymore. There seems to have been a general shift to making the render process very UI-explicit and sometimes even keeping state elsewhere - so akin to having a hierarchy of presentation components that simply render UI, passing messages back to the state.

The question of where is the "backend" is probably going to be largely dependent on the application itself. The render process is essentially a browser so you could make REST/GraphQL calls to a backend. You could even run code in the main process. But there's been a bit of commentary on that. James Long (author of Prettier) writes that using the main process to render process IPC (interprocess communication) for app updates is a bad idea. He suggests forking the main process (which gives you a Node server), you run your app code there and use IPC between that and the render process. Check out this writeup. He's put together an associated repository that has a minimum possible implementation of this.

It also seems wise to not just take a server process and put it on the desktop. I've seen a codebase running a Java process with Elasticsearch as an initial trial and it struck me as pretty heavy duty. Maybe your userbase will all have beefy PCs, but probably not. The author of Finda (Electron but Mac-only) has written about getting high performance by implementing in Rust as a Node module.

Developing on Electron 7

Starting with React on Electron isn't quite as simple as initializing a project with Create React App (oh we've been spoilt!). The most-starred Electron-React boilerplate seems now to be unmaintained - it sits at Electron 4. There are a few boilerplates around, mostly with a few hundred stars at best. I've kicked off with https://github.com/alexdevero/electron-react-webpack-boilerplate. In the pre-CRA days, I found boilerplates to be not only a good start but very useful in getting many other eyes on significant version changes like test framework updates or the like.

But what is explicitly different about Electron 7? There will be Chrome 78, V8 v7.8 and NodeJS v12.8.1 of course. The big new feature will be a way to call functions in the main process from the renderer. You'll be able to do something like:

Most of the other changes in version 7 are reworking the Electron API to return Javascript Promises rather than existing callback code. This 'promisification' will likely continue over upcoming releases. Plus there are changes in to cater for MacOS Catalina now that it's been released by Apple. So generally, 7 will be the same but better.

The power of web development

So does it make sense to build an Electron app rather than a native one if you need/want to build a desktop app? The answer has very similar parallels to using React Native vs building native in iOS and Android. But Electron is certainly a viable path for building for the desktop. That understanding is obviously very evident over at Microsoft. They're building out React Native for Windows in a public repository and it's evident they see a future where people are building for the desktop with web development tools.

Disclaimer: I run Uplift, a software consultancy specializing in building quality projects or providing staff augmentation in fin-tech, health-tech and ed-tech. This blog post is for you if you want to delegate work and want the best people for the job. Every startup needs a freelancer. Why? Let's put it