Electron App Development: How Modern Desktop Frameworks Work
Posts by Alan TaylorMarch 12, 2024
How would a developer feel if he was asked to write a desktop app? He would probably be upset. In the era of browsers and the Internet, a desktop seems to be something backward and unnecessary. But what can we do if our software should work without the internet, on a weak machine and can be installed with a single mouse click?
Using frameworks like WPF is clearly not an option because there is nowhere to use them. And they are not always good at support, especially considering the fact that those who want to do this are not worth a queue. In such cases, Electron can help us. It is a cross-platform JavaScript framework, which any front-end developer can handle with some training.
Electron has a lot of popular programs in its portfolio, such as MS Teams, VS Code, Skype, Spotify, WhatsApp, etc. Electron is developed and supported by GitHub and has a large community.
What Does The Electron Framework Consist Of?
In Electron we can distinguish two main parts.
- Main process. The Main in Electron app development team is responsible for creating browser windows and interacting with the operating system. Physically this is NodeJS.
- Renderer process. Every browser window runs a web page in a renderer process. Several renderers can talk to each other but do not influence each other. This is essentially Chromium. But we see it as an ordinary app window.
- The two parts interact with each other via IPC.
The Flow Diagram In Electron App Development
With so many parts interconnected, Electron app development looks quite unstable, but it is only unstable at first sight. For example, a crash of a renderer won’t affect neighboring renderers and the app will keep on running. Also, as a rule, the latest stable versions of NodeJS and Chromium are used.
Failures are very rare. Everything works stably despite the many layers. It is worth noting that it looks like a “client-server” model, but in fact, the NodeJS (main process) is only needed to communicate with the operating system and can be called from the renderer process.
You can manage the files on disk right in the Angular component. Therefore, it is common practice in Electron app development to use the main process only for windows startup, installing updates and other things which have to be done.
Requirements For The Computer
Cross-platform has never been cheap and you have to pay for everything. With Electron app development, we pay overhead for NodeJS and Chromium (70 mb) hanging in memory. From there the app costs start and if you don’t use much API of the operating system then your app will use an amount of memory and CPU, comparable to normal browser numbers.
To this you should add quite a large installation file (70-80mb) and its unpacked version (300mb), if you compare it with something more or less native, of course. It’s not much for modern computers, considering that after startup overhead the app eats the same as in the stock browser.
What About Performance In Electron App Development?
Everything runs on Chromium with all its advantages and disadvantages. There’s the JS engine, single-threading, and sandboxing which isolates us from the operating system. If you need more than that, you can run a NodeJS child process.
Many vendors do it that way, but VS Code is the most obvious. Visual Studio Code can integrate with the console utilities, connect to the debugger, linter, and all in separate processes. And the ElectronNET library allows you to run a child of the full-fledged .
NET Core, and during Electron app development communicate with it as a regular client-server app. Thus, in one click on the installer we can put a client, a server, and a portable database on the user’s computer. Thus turning, for example, our classic web app into a desktop.
There is another feature of NodeJS we can use – the import of C/C++ libraries (Native Addon), like Skype for example. Skype uses media libraries, codecs and other things that are quite problematic to support outside C/C++.
What About Debugging And Autostability In Electron App Development?
There are 2 main processes: main and renderer. To debug main, just run Electron with an open port for debugging about the same as NodeJS and connect with a debugger, like VS Code.
Debugging renderers is a bit more complicated and variable. Since it’s essentially a browser, we have 2 options – either connect to the open debug port or open DevTools. If you use WebPack, consider the presence of source-map files in the final bundle. Also, WebPack has special targets “Electron-renderer” and “Electron-main”.
At this stage, tests can be divided into two types.
- Infrastructural. In the case of a desktop app, we are responsible not only for the operation of the app, but also for its installation, launch, delivery, update, removal, etc. Here the autotester will have to learn new tricks, but there shouldn’t be much of a problem, except for cross-platform. Or leave these tests manual.
- App tests. Electron is supported by many frameworks and the documentation is replete with examples. There is support for Selenium and WebDriver, Headless CI Systems (Travis, Jenkins). And if that’s not enough for you, you can even use extensions for DevTools. Your tester will likely figure it out quickly and won’t notice much difference with a web app.
Are There Any Pitfalls In Electron App Development?
There are pitfalls in the Electron app development process, as in any project. In the beginning, the project was developing quite slowly and major versions were rarely released. It is hard to keep up with them now. Version 11.0.0 came out 3 months after 10.0.0. Moreover, version 3.0.0 only came out 1 year after 2.0.0.
Many versions including version 1(1.8.8) still get updates. Unfortunately, there’s no migration options like in Angular, and things can break just because one of the default flags becomes false instead of true.
We do all business logic operations in a renderer, i.e. we can call fs and use disk, or we can link to other resources. Often in such cases we plug in auxiliary libraries that may be designed for NodeJS and not the browser. So they may not behave the way we expect them to behave. When adding new libraries there is always a chance that we will need to modify the webpack config.
Electron App Development: What’s The Result?
In the end we have:
- a cross-platform JS framework;
- powerful and extensible, both native modules and sub processes;
- does not require developers expertise; a front-end with good JS knowledge is enough;
- is compatible with TypeScript;
- has a large community and an extensive library of auxiliary packages.
Electron, with its simplicity and low entry threshold, is gradually replacing other solutions in desktop development. Of course the framework has its own nuances, which need to be known, and working with it, as with any other such powerful modern tool, will not be an easy walk.
However, at this point we have almost no alternatives that will provide the same quality and speed of development. And everyone is more comfortable when we have on the website and desktop app the same UI/UX solutions.