Microsoft Teams, Discord, Slack, Visual Studio Code – many of us use these applications every day. What do they all have in common? They are created using a technology called Electron. It is a framework developed by Github. It allows the creation of cross-platform applications with a graphical interface using Node.js and the Chromium engine, technologies that are also used in the development of web applications.
Electron was developed for the Atom text editor, which was intended to be extensible and able to run on multiple operating systems. Back then, the first version of the platform that we know today as Electron was created under the name Atom Shell.
Write once, run everywhere!
The challenge that arises when creating a single application that can run on multiple operating systems is the different set of functionalities or differences in their implementation between systems. The Electron API mentioned above was developed in response to this problem. It is an intermediate layer that implements common functionalities for each system in such a way that they can be used in a consistent manner independent of the current operating system. There are a few exceptions to this rule, such as Touch Bar support on MacBooks, which is only available in macOS. The existence of this intermediate layer unfortunately introduces a performance cost – all operations must be translated from the form available in the application to one that will be understood by a particular operating system.
Some functionalities offered by Electron API are available only from the level of one of the processes – main or rendering one. Operations such as managing the system tray icon, notifications or global keyboard shortcuts can only be used in the main process. However, the rendering process is mainly responsible for user interaction – so what if you want to perform a certain action in the user interface in response to a keyboard shortcut? This is where inter-process communication (IPC) comes in. It can be both synchronous and asynchronous and allows messages and data to be transferred between application processes, clearly defining the extent to which the main and rendering processes can communicate. Another way of communication is provided by a special module that allows all the functionality of the Electron API to be used, independently of the process that executes the code. This module gives unrestricted access to the system, which can be disastrous in the case of untrusted code. For this reason, it is not available by default and must be enabled by configuring the application accordingly.
We've made a new app - what next?
Browser, Electron - the same application?
Web applications and their desktop counterparts often have a similar interface. This is obviously convenient for the user, as they can switch seamlessly between versions while remaining in a familiar environment. This fact brings the advantage of sharing the GUI code between the two applications, as they use the same technologies. The only difference between these versions is the operating system functionality available. A web application using a more versatile and limited layer, which is the browser, has less opportunity to interact with the system, which may translate into a user interface.
Electron is an interesting tool that allows you to create cross-platform applications. However, it does come with some costs, such as lower performance compared to native programs, and a user interface similar to web applications, often deviating from the style of the operating system. The multitude and popularity of solutions created with Electron available on the market shows, however, that software manufacturers are often willing to give up undoubted advantages of native programmes in favour of improvements offered by Electron.