What you should know before you start using Electron.js? The Beginners Tips

Michal Jurkowski

Hello! This article is for developers who want to make their native desktop application using a popular framework Electron.js. There are a lot of small things that you should know/remember before you start to develop cross-platform desktop apps. I have written this article as a guide and tips that can help you to think about your application and analyst the cases that happened on desktop but doesn’t exist on the web. Enjoy!

My story of Desktop Applications

Desktop Application — the first type of application, that I have ever written. It was many years ago when Pascal and Delphi were very popular languages. After that, I started to develop websites, web application and server and for many years I forgot what was the desktop application development. Hey! The web is cross-platform, everyone has Internet access, HTML and JS is quite easy and cheap to develop. Why we should make the desktop applications? Let think about it, what kind of applications have you on your computer? Probably that one:

  • you want to use independently if you have internet access
  • entertainment and communication like Spotify, Slack
  • tools and working apps ex. IDE, Graphic Apps, Move editors
  • quick access tools ex. calculator
  • and another that can access your machine ex. file working.

But what about business cases? Why does the business want to have desktop apps? Access limitation — many companies prepare their workstations with necessary applications only. And that was the major reason — to allow the use of our services using desktop application that can be installed on each corporate computer.

Welcome to Electron.js and Desktop Apps world!

The short story of Electron — began in 2013 as the desktop app framework used to build the Atom.io, but was open-sourced one year later. Based on Chromium and Node as a single runtime and app packager for Mac, Windows, and Linux. For long-time existed as version 1.X but form 2018 it started to fast growth.

Right now there are a lot of changes and improvements. But the knowledge of how to build the electron app properly is still very poor. And case by case you need to discover this new world.

What’s the major problem? System-specific cases.

When you are planning to build your app you should think what OS you want to support and how good do you understand the user experience? That’s the point of this article. To better understand the cases that you need to fix.

Before you start — documentation

Electron documentation has two parts — Guides and References. Before you start writing any code, you should read

In additional I recommend you to look for some boilerplates of applications:

And some specific boilerplates for frameworks:

Before you start — tools

Applications:

Parallel or VirtualBox — To the better performance of your work is to test your app on multiple platforms. Install these platforms that you want to run your app on.

Npm packages:

electron-builder — create installers

electron-is-dev — check if your electron is running in development

electron-updater — auto-updater mechanism

electron-store — to store app data/state/cache

electron-log — to prepare logs

electron-redux — to sync the state between windows

electron-is — package of simple utils

What’s the between app and BrowserWindow ?

The common question that is if you start to develop is about difference between app and BrowserWindow . You should understand that app is the interface of the electron process, but BrowserWindow is a component of your application. Example — you can have a running application without a window interface.

app the interface allows you to setup the application conditions like app icon, app name, set if the app should be running on system long. But it can tell you about some events that happen with you app ex. some process errors, if all windows are closed or if the user wants to close the app.

BrowserWindow is an instance of Chromium — the browser. You can setup your webview, disable security policy, load some URL(local or external), toggle devtools, prepare own context menu, add the support of shortcuts or communicate with the loaded site. It looks like a browser but without UI like navigation bar or tabs.

During electron development, you should remember that you can have multiple windows in one application. A lot of things you can make as independent browser interfaces like app preferences, custom about window.

**TIP**: Remember that desktop applications have modals that can be moved — avoid to implement you modals in the main browser window but implement it independently.

Frameless and windows dragging

Your application can look like you want! That’s the truth but has some limitation.

What’s the frameless. If you wouldn’t have a default application frame with close, minimize, maximize buttons you can use the frameless feature. It’s quite easy — just put frame: false to your BrowserWindow option. But what about dragging the window? The documentation said that’s easy — put to your HTML element style -webkit-app-region: drag but for the element that should be responsible for dragging but the element’s on that will be disabled to click. To disable element from dragging — add -webkit-app-region: no-drag . Easy.

But there are some cases that it doesn’t work — good practice it to set the whole body with -webkit-app-region: drag but the direct containers with
-webkit-app-region: no-drag.

<body style="-webkit-app-region: drag">    <div class="custom-header"></div>    <div class="model-body" style="-webkit-app-region: no-drag">
</div>
</body>

Communication between processes

Your main process and actions in BrowserWindow works without any communication - that are another process — main and renderer(browser processes). To communicate webapplication and main process you can use IPC(InterProcess Communication) that have two interfaces IPCMain(that listen for messages from renderers) and IPCRenderer(that can send ane listen for messages from main process).

main.js

const { BrowserWindow, ipcMain } = require('electron');const mainWindow = new BrowserWindow(...);const messagePayload =  { myKey: 'myValue' };mainWindow.webContents.send('messageToRenderer', messagePayload);

renderer.js

const { ipcRenderer } = require('electron');const messagePayload =  { myKey: 'myValue' };ipcRenderer.send('messageToMain', messagePayload);ipcRenderer.on('messageToRenderer', (event, payload) => console.log('Message received'));

As you can see, we sent message to renderer using webContents from BrowserWindow, but we receive using IPCMain listener.

Native node modules

Some of packages that you want to use in your project like a spellchecker use native system functions, and needs to be prepared on the target system. As you know — node is built on C++modules.

Wait — do I need each system to build each target? Obviously not — you can prepare only the built packages and replace it during building for some target.

How you can do that?

  1. Recognize which packages have native modules
    find node_modules -type f -name "*.node" 2>/dev/null | grep -v "obj\.target"
  2. Use VirtualBox to build your project.
  3. Copy and zip the build directory from each listed node_module

Then prepare the comman that can unzip your zipped modules to node_modules before building for some target.

System and user experience differences

That topic is very difficult. You should remember that you have to meet your users experience. But OSs have also some differences.

Problem: Closing the window
For windows users: Close the app
For mac users: Hide the window, app is still running

Problem: Gestures
Windows users: not necessary
Mac: good to have

Problem: App icons
Windows: *.ico
Mac: *.png

Problem: What is the executable file?
Windows: *.exe — FILE
Mac: *.app — Application package

Problem: MainMenu
Windows: Is in the window — many windows can have many menus
Mac: Is on the top bar — one app, one menu

Problem: Dock
Windows: no exists
Mac: exists

That’s all of my short information about electron. I hope it helps you to understand some of the problems that can exist during development.

No responses yet

Write a response