DEV Community

Cover image for Electron, the future?
Alex Dhaenens
Alex Dhaenens

Posted on • Updated on

Electron, the future?

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!

What is it?

According to their site, with Electron you can Build cross-platform desktop apps with JavaScript, HTML, and CSS. And that fully summarizes what it does. Electron does this by combining Chromium & node into a single runtime. It also provides extensive documentation on how to start & use their API's.

What Electron does is create a native window that loads a certain HTML page, where you can unleash the full power of HTML, CSS and JavaScript. Because this is actually a web page and the framework uses Chromium, it can display the full blown dev tools (like you are used to in Chrome), and when I say full blown, I mean you can do everything you can do in the normal dev tools. As you can clearly see that is very useful!

The basics

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!

Boilerplates and CLI’s

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.

Concerns

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.

Conclusion

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?

Top comments (6)

Collapse
 
pandazaur profile image
Alexandre Borel

I don't think that Electron is the future, it has some drawbacks. Imagine you are running 15 Electron Apps = 15 Chromium instances + 15 node.js instances.

I think Électron is pretty cool, but due to it's conceptionw it's cool only if you have just a few Électron apps on your desktop. Google provides an alternative called "Carlo" to limit to only 1 instance of Chrome.

I think that the future is more Flutter Desktop

Collapse
 
ymiyugy profile image
YmiYugy

My biggest concerns with electron are not just performance but resource consumption.
Big install size aside it’s always running a chromium instance in the background.
And while performance might be ok for lightweight applications it’s just ok never great.
Startup takes long, resizing is slow, etc.
Just compare VS Code to Sublime

Collapse
 
itsjzt profile image
Saurabh Sharma

Electron has a future till React Native get some traction on desktop market.

Collapse
 
seanmclem profile image
Seanmclem

Things can coexist.

Collapse
 
itsjzt profile image
Saurabh Sharma

Certainly they can

Collapse
 
rubenwap profile image
Ruben Sanchez

I think that for every Visual Studio Code that you find (fast and sleek) you find dozens of Slack or Atom (also Electron) which are slow and painful. The idea behind Electron is very interesting, but the performance is really an obstacle for it to be a killer option.