Electron develops cross-platform desktop applications

In the domestic All in Mobile culture, it seems to be a very unconventional behavior to talk about desktop client development. However, as the claw of JavaScript on the desktop, Electron is not only a technical selection for rapid development of cross-platform desktop client, but also has its unique symbolic significance

This paper mainly introduces the application structure, development mode, advantages and disadvantages of Electron. In review Electron development process wrote a copycat Mac version of netease cloud music, this is the demo address

The first time I contacted Electron was 0.3x version, and it has already been 1.6.2. Compared with React Native, which is also developed cross-platform, Electron has completed the step of “from 0 to 1” earlier. In the past 2016, Electron was one of the hottest warehouses on Github.

Without further ado…

What is the Electron

A cross-platform desktop application development framework developed and maintained by Github.

Basically, stripping the Chromium kernel to write desktop applications, most of the UI of the application is the Web page, which is the DOM that we are familiar with in front. The interaction logic is all JS, style or CSS, which is equivalent to giving the user a browser to render the application… See here surely reader master will scold niang (this is not web? Better to write a web page.)

The essence of Electron is to use JS to build cross-platform desktop applications. In my opinion, its application scenarios are mainly those projects that require native function support, need offline use, have fast iteration speed, are not sensitive to download and installation, and lack of desktop developers. Electron is more than just a “browser”. It also encapsulates some native system features for JS developers, such as the ability to easily customize menu bars, application ICONS, taskbars, control the size and location of application Windows, and call native applications using JS. Compared to Web applications, developers are free from the constraints of the browser and can work indirectly with native applications.

At present, the most famous desktop applications based on Electron are Atom editor, VS Code editor, Slack, Postman desktop version, WordPress desktop version and so on, which are mostly used by foreign companies.

Electron is derived from Gihub’s technology selection for Atom development. Cococa’s native development method was used in Atom development. Later, Node-WebKit (abbreviated NW, also developed using browser rendering) was used; Later, due to some technical limitations (such as multi-window support and performance reasons), I decided to develop a development tool, namely Electron. One of the main contributors and current maintainers of Electron is Github’s @ZcBenz, whose love-hate relationship with NW won’t be discussed here…

Principle of Electron

Cut a picture from the shared keynote (download address) :

Electron runs into two processes: the main process and the renderer process. The main process is created when the app is started. It is mainly responsible for how the app calls native, how to create and manage new Windows (pages) and various native related logic. It can be roughly understood as running a node. The renderer process is responsible for drawing all the pages (using the Chromium kernel) and parsing and running the js front end, roughly translated as “front end”. Two processes communicate via IPC (cross-process interaction), and Windows can have dependencies or communicate with each other using messaging mechanisms.

Like Facebook’s React Native, Electron allows developers to connect to Native devices by reading documentation and invoking an interface wrapped in JAVASCRIPT instead of writing Native code.

The temptation of Electron development

Here are a few things that feel great about development and things to watch out for:

The page JS runtime environment in the rendering process is actually a combination of the Node environment and browser environment

You can use node-related apis and third-party libraries, such as require(‘child_process’), require(‘request’);

Note that require(‘electron’) exposes different apis in different processes (main/renderer). For example, BrowserWindow and ipcMain are main process-specific apis

Simple implementation of very “Native” features

A few examples of this recent cloud music knockoff (currently only for MAC)

Chestnut 1. Use`node-notifier`Customizing system reminders

It is also possible to use the HTML5 Notification API directly, but it is relatively customizable and multi-platform compatible with this third-party module.

As for how to customize the icon of popbox, you can see the solution provided by @mbushPilot2b in this issue.

Chestnut 2. Use`Menu`API custom program menu bar and shortcut keys

Chestnut 3. Use`remote`The API defines the right mouse button menu in the rendering process

The right-click menus we write in Web development are definitely DOM emulated, but here we can easily write native menus in JS and have a certain level of hierarchy.

4. Customize Windows

In this example, the main window is reduced to a mini-player and the lyrics window is opened (the lyrics window can be set to live on the top layer and not covered by other application Windows).

A closer look at the screenshot above shows that the Windows use the MAC’s native frosted glass blur effect. And unlike Windows for regular MAC programs, there is no top bar.

In short, read the documentation well, and as the Electron community iterates through the project, a variety of native features (JS) are at your fingertips.

Interprocess interactions can be used`ipc`or`remote`API

The front-end logic can be transmitted to the main process of the APP through inter-process communication, and can do some interaction similar to native applications. As shown in the mini player above, the close button is customized on the DOM, and when the click event is triggered, it is transmitted to the main process through IPC, and the main process controls the current window closing.

Renderers can use remoteAPI to call some of the main process apis such as remote.browserWindow without ipc (again a close button for mini player, another way is to use remote to hide the current window).

Note: it is best to manage IPC uniformly to avoid signal repetition; Complex logic and timing issues need to be considered when IPC listens too much.

There is no cross domain

The cross-domain nature of the front end can be a nightmare for a beginner developer, but thanks to Node, requests can be done in a variety of poses, free of browser constraints.

Compatibility & Write once, run every where

Because the UI itself is produced by the browser, Chromium, which is used by all platforms, does not need to consider compatibility issues, and the browser prefix can only be retained -webkit. Logic written in JS is basically packaged and compiled in a wave that can be installed on Windows/Linux/MAC.

The real concern in development is “cross-platform compatibility”, where different features may be implemented differently or not fully implemented on different platforms. This is where some kind of compromise and concession is needed, or tricky methods are used to keep everyone on the same page. Most problem active communities have solutions

Hot update

This hot update is a hot update of the application, rather than a frantic page refresh during front-end development. The reason why desktop applications are constantly replaced by Web applications is that the update speed is slow and tedious. Web page online is “client update” with very low cost. Users hardly feel the delay caused by file changes (such as CSS/JS/HTML cache failure and reload), which ensures a good experience.

I’m not talking about using a remote URL to render a page in Electron either (although that’s possible), but rather a logical update of the entire application. According to the document, the auto Updater provided by Electron can automatically update the application according to Github release package. But my Atom editor is definitely upgrading without a trace.

Electron’s pack release

Before the whole project is packaged, the main process and the renderer code should be packaged, compressed, and confused, using engineering tools such as WebPack.

And then to actually package into an application you need to incorporate Electron’s core. At present, there are two ways: one is to use the electron packager, directly packaged into a runnable program, basically in 100MB + (the volume is relatively larger than normal native applications, mainly due to the kernel); The other option is to use the electron Builder to make a compressed installation package, which can be made into deb/ MSI/DMG format, basic 40MB +, but the electron Builder documentation is really very bad, it took a long time to configure (even a complete demonstration and configuration item object structure is not specified).

I am currently using both, one packaged and one compressed.

End

I’m not going to post a code tutorial, but the documentation is quite detailed about the API’s functionality, and you can find a lot of introductory examples on Google. It should be noted that some of the features borrowed from third parties in the article may have been supported by Electron, so we recommend using the official practice.

You can download, build, and install a cloud music demo on Github, but it’s still in development.