But why is it then that so many people oppose it so badly? The problem starts with the apps and the way people use Electron. For many, porting a web application to an Electron means taking your existing code as is and integrating it into an Electron container. Is it a terrible thing to do? Maybe not, but you are not taking full advantage of the power of Electron. You simply change a browser tab to an independent application.
What can we improve? In this article, we’ll explore the basics of Electron and create a sample app to demonstrate some of the Electron methods.
How does Electron work?
Electron is built on 3 main components:
- Chromium: responsible for web content
- NodeJS: to interact with the OS
- Custom APIs: To resolve common operating system issues
Each of these components interacts at a different level on the Electron architecture layer, as shown in the architecture diagram.
Electron works with two types of processes.
- Main process: responsible for managing windows and all interactions with the operating system. This is where it all starts, and it can create and manage multiple rendering processes.
- Rendering process: There can be one or more, each of which hosts an instance of chrome and is responsible for web content.
It is important to note that rendering processes cannot directly access operating system functionality. Instead, they communicate with the Main process via IPC to perform these tasks.
Many typical Electron apps would use the main process to create a render process and load their web app. Today we are going to take a step forward.
Must-see section: Hello World!
Next, we’ll build a “hello world!” application. We will not use any framework or library that is not necessary to stay focused on Electron code.
The first step in creating an app is to create a project and install the electron library, so start by creating the project using NPM:
And configure your app details. As a starting point for the app, I like to use main.js, but you can use any filename you want.
Then install Electron.
Build the screen
For our micro hello world example, we need two files,
main.js is our main process; we will create the first rendering process which will load our
Here is the boot code for
The starter kit will handle the minimal operations to run the application, creating the first renderer with
new BrowserWindow and loading
main.html above. It will also discuss some scenarios for quitting the application and relaunching the main window when needed.
As for our
main.html we will use the following:
It is simply a simple HTML exposing the current versions of node, chrome and Electron used by our application.
Finally, we need to run our application; first of all you need to change the
package.json and add the startup script.
If everything worked out well, you should see a window like this:
Isn’t there an easier way?
The short answer is YES! Though it comes at a cost. Many boilerplates provide a starting point for building Electron applications, some of them using vanilla JS, others directly integrated with some of the most popular frameworks like React and Vue.
I’m not a big fan of these boilerplates as they often come with many libraries and additions I don’t need. But they are a great place to get you started.
Here are some popular ones:
Building smooth applications
We already saw in the architecture of Electron how things work. And if you are like me, you are probably worried about all those instances of Chromium and Node running, and you should be. We all know how Chromium (or Chrome) can devour our memory and affect our performance, so what can we do to avoid our Chromium-based application to do exactly that? How do we keep them performant?
Here are a few tips:
Never, ever, block the main process
The main process is where it all starts. It is the parent process for all the processes of the application. It is the one that primarily communicates with the operating system, handles all the windows and communications between them, and it runs the UI thread.
Blocking this process means that the application will stop responding until the operation finishes. Under no circumstances run code that is CPU intensive here and takes a long time to complete.
Here are some recommendations:
- For CPU intensive operations, delegate those functions to either a worker thread, a renderer process, or even spawn a dedicated process to perform that task (though make sure you know what you are doing for this last one).
- Avoid the use of the
remotemodulate as much as possible. It's far too easy to unknowingly block the UI thread using the
- Avoid using blocking I / O operations on the main thread; if necessary, use the asynchronous equivalents provided by NodeJS.
Is it okay to block the rendering process?
Not really. The consequences might not be as bad as blocking the main process, but blocking renderers comes at a price. Your windows may become slow or unresponsive, and the overall user experience will be terrible.
When we use the web, we're used to some web applications suddenly getting slow, not smooth, and that's fine with us; However, when it comes to desktop apps, our standards are higher. Be aware of this, because user expectations matter.
What can I do to make my apps more responsive? Pretty much the same things we could do on our web applications; after all, on the rendering process we are only talking about Chrome.
- Web workers: the best tool to perform expensive calculations on web browsers by assigning them to a new thread.
You don't need cross-browser compatibility
When developing web, it is very common to use polyfills to support different browsers. When you build Electron apps, you don't need them. If it runs on Chromium, it runs on Electron and there is no need to support another browser. Reduce your batches and speed up while not loading those extra modules.
Gather all your code
In web development, sometimes we load scripts or pages from servers, like CDNs, which are served separately from our application, and that's fine. After all, for the web, we still have to download these resources to run the app.
For desktop applications, it's different. Avoid unnecessary network requests by consolidating all your static assets, scripts, and content into your application. This will allow your application to do two things, work offline and speed up the loading process, since reading the disc is cheaper than going on the internet.
Just know that Electron can be great if used correctly. Keep in mind that while this looks like a website, it is not precisely a website and therefore you will need to take some special considerations to make it work.
This item was originally published on Live code stream through Juan Cruz Martinez (Twitter: @bajcmartinez), founder and publisher of Live Code Stream, entrepreneur, developer, author, speaker and maker of things.
Live code stream is also available as a free weekly newsletter. Sign up to receive updates on all things programming, AI, and general computing.
Enjoy stargazing while you can, SpaceX Starlink is about to ruin it