For some time, I've been hearing things about the Electron framework. It always sounded interesting, but the moment I heard that Visual Studio Code is actually an Electron application, it really took my attention. So, it speaks for itself that I wanted to try it out!
One of the core concepts in Electron is the principle of the main and the renderer processes. The main process is the process that runs a script which display GUI's (where each GUI renders a web page). There can only be one main process! Each web page then runs in a separate process, called renderer processes. This means that if you have multiple web pages concurrently running in your Electron app, multiple renderer processes are running as well.
There is a significant difference between the main & renderer processes. The renderer process only manages the web page it displays and is fully isolated. The main process however manages the renderer processes.
Electron also provides IPC (inter process communication) so the main process can communicate with renderer processes and vice versa by sending messages. This opens many doors, especially since it is inherently unsafe to call native GUI’s from web pages. You can use the IPC to send the message from the web page (running a renderer process) to the main process, which can call native GUI’s.
As Electron runs on Node.js, it also provides full access to the Node.js API, meaning you can use all your npm packages! And the breath-taking thing here is that the full Node.js API is exposed to both the main as renderer processes. This means that you can for example create or delete files, read them or write to them directly from your web page!
Electron does not provide one way to build, create or package your Electron apps. Instead it uses a rather modularized approach: different tools & cli’s do different tasks and it is up to the developer to pick the preferred ones and combine them into a pipeline that fits his or her needs. Electron’s documentation also lists recommended cli’s for different tasks.
On the other hand, it is also possible to use a boilerplate. This is a prefabricated, clean project where everything is already setup and ready to use. Most of the time they are repositories where you clone or copy the code. Since a boilerplate is a ready-to-use project, developers can freely remove or add things (frameworks, tools, …) from or to the project. For example, if a boilerplate uses a certain framework they don’t like, they can just remove it. Boilerplates are rather a starting point for a project and are very great for developers that require certain features (hot reloading, …) in their dev environment and they don’t want to waste time setting those up. Electron provides also a list of different recommended boilerplates.
For the moment, my only concern is the performance especially compared to a compiled application. I didn’t see any issues nor did I have experienced some in my current Electron apps, but I do think that there will be for apps that do require a (very) high performance. But since performance is a very important topic, the documentation of Electron dedicated a full page to fixing performance if you would have any issues.
At the time of writing I do think that there is a big future in Electron as it opens many doors to write apps on different platforms really, really fast! But I'm a bit reserved with the performance, but this should not be an issue with the gross of the applications. What are your thoughts?