Electron: 4 Things to watch out for before you dive in

What is it, its benefits and comparison to node webkit

Electron is a framework created by Github community to build cross platform desktop apps with JavaScript, HTML, and CSS. “Initially developed for GitHub’s Atom editor, Electron has since been used to create applications by companies like Microsoft, Facebook, Slack, and Docker”. From the client names it looks very promising and therefore you would see a lot of traction of people switching to Electron for desktop apps.

Benefits

1. It gives us a lot of benefits using Electron as a framework for creating desktop apps. As the apps are developed using web technologies therefore there is no need to learn any platform native technologies and the same web technologies can be levereaged for which you will find lots of developers and support.
2. If you plan to support your application on web in the future or already have a web application then you will save significantly on the development and maintenance cost.
3. A single source code can support applications on platform like Mac OS, Windows and Linux therefore it is very easy to add support for a platform in future.
4. Electron is very powerful as we can do almost everything which we can do in Node.js. It is supported by a big community so getting answers is easy.

Comparison with nw.js [node-webkit] which is a similar platform

nw.js: (previously known as node-webkit) lets you call all Node.js modules directly from DOM and enables a new way of writing applications with all Web technologies.

Comparison

1. nw.js is simple to setup than Electron for an application and documentation seems better (in my personal opinion as I have faced lot of integration issues lately with some electron modules) but community support for Electron seems better than nw.js.
2. Some extensive features that are available in Electron, such as auto-updater and crash-reporting, don’t comes built-in with nw.js and will require significant effort for implementation.
3. Electron has fallen significantly behind Chromium — Electron 2 beta 2 is currently tracking Chromium 61 while nwjs is on Chromium 65. This means that we have to wait on bug fixes we know are in Chromium that affect us via Electron and there’s really no production-quality solution.
4. nw.js tries to create a programming environment that imitates a normal web environment as much as possible. Platform integration is implemented as minor wrapping on existing web APIs with reasonable defaults chosen. Electron seems to be providing better platform integration features.

Electron Application Architecture

As you can see in the figure above the Electron Architecture is composed of many Render Process and one Main process. Main Process starts the Render Process and the communication between them is through IPC [Inter Process Communication].

So why there are multiple processes in Electron?

This architectural decision comes from Chromium. Chromium runs each tab in a separate process so that if one tab encounters a fatal error, it does not crash entire application. Therefore all the processes in Electron run in their space and communicate via IPC. This architecture brings in resilience and also there are some security reasons. Chromium has explained it’s multi-process architecture here: https://www.chromium.org/developers/design-documents/multi-process-architecture

Main process

The main process is responsible for creating and managing BrowserWindow instances. It is the only process communicating with native UI so can also do things like register global shortcuts, create native menus and dialogs, respond to auto-update events, and more. “The basic rule is: if a module is GUI or low-level system related, then it should be only available in the main process.” (GUI here means Native UI, not HTML based controls being rendered by Chromium).

Renderer process

The render process is responsible for running the user-interface of your app, or in other words, a web page which is an instance of webContents. All DOM APIs, node.js APIs, and a subset of Electron APIs are available in the renderer.

What is IPC and what it uses underneath

IPC is sort of like using postMessage between a web page and an iframe or webWorker. Basically, you send a message with a channel name and some payload information. IPC can be used for communication between renderers and the main process in both directions. IPC is asynchronous by default but also has some synchronous APIs .

Chromium’s IPC documentation states that IPC uses named pipes as the underlying mechanism for communication. Named pipes allow for faster, more secure communication than a networking protocol could provide.

Things to watch out for before you start investing

1. Code Security seems a major concern for the adoption in enterprise scenarios as the code you write can be decompiled easily. There are some options like creating V8 snapshot or to use C++ binaries and using those in your desktop app but they are not easy to implement. Till the time of writing this article Electron has decided “not to work upon source code security as of now”.

2) Package Size of an Electron application is very big as it bundles all the dependencies like node engine with it. For a Hello world application the size can go around 115 MB. There are some projects like Electrino, going on to reduce the size by encapsulating only the necessary dependencies but they are not production ready yet.

3) Integration of non node modules is not that easy. For interfacing with a non node component like a dll you would need a node module like node-ffi. Integrating with Foreign Function using this module may seem easy from documentation but you might see a lot of errors when integrating the dll for which there are open issues with the module.

4) Electron gives the option of packaging the files manually but that is not easy and if you are working in an enterprise scenario you would need more features than supported manually. There is not one packaging option and you have to choose between available options carefully going through the features provided by each one of them.

Summary

Therefore if you see Electron seems a quite decent option to create desktop applications but we still need to see a lot of things from the enterprise perspective to make sure we get best performance and security in our solutions. Before using it for any enterprise application do figure out the concerns related to the above points so that you will not have any surprises when the solution is ready.