Electron VS. NW.Js VS. CEF

Comparing Web Integratable Desktop Applications

Comparing Web Integratable Desktop Applications

INTEGU - electron-vs-node-webkit-vs-chromium-embedded-framework

What Is The Purpose Of Web-Desktop-Apps?

Javascript is, at this current point in time, the most popular programming languages, which means that the amount of web developers is higher than ever. A few years ago this might also have been what javascript developers, would be expected to build: web applications. However, with the introduction of Node.js (javascript on the backend), cross-platform mobile application frameworks (e.g. Cordova), and now cross-platform dekstop applications, it has become more relevant to utilize the growing potential of web development tools on other platforms. Potentially, sharing the same web-based source code, would mean less code to maintain and more time to develop new functionalities.

In this article, I am going to dive into the field of web integratable desktop applications. (Yes, I invented that term myself) I will attempt to present the solutions to the best of my abilities and give a step-by-step guide for how to get started.

Which Solutions Are Available?

Generally, three solutions exists on the market: ElectronNW.js (Node Webkit), and CEF (Chromium Embedded Framework). All solutions are based on a combination of Chromium, the open-source version of Chrome, and Node.js.

Electron

Electron is arguably the most popular solution on the market. Based on the amount of well-known products which utilize Electron and the compared search volume on Google, I don’t think that it is wrong to assume that Electron is the marker leader. Additionally, it is maintained and funded by GitHub, which was recently acquired by Microsoft. Both of which are companies which I believe is going to stay major players within the field of software development for at least the next decade.

One of the reasons, why I believe, that we are seeing such a large adoption of the Electron solution (disregarding the fact that it is free and open source), is because it runs on a lite version of the Chromium engine. The project known as libchromiumcontent create the foundation for the Electron project, which according to my sources makes it slightly faster when compared to both CEF and NW.js, which are both based on the original Chromium engine.

INTEGU - electron

Demonstration

To Illustrate How The Electron Project Work And Can Be Setup, I Created This Brief Step-By-Step Guide For How To Start, Manage And Distribute An Electron Project.

Prerequisite: A functional web application with npm installed.

  1. Install Electron: npm install –save electron

     

    1. Create a new main.js file.
      const {app} = require(‘electron’);

      app.on(‘ready’, () => {
              mainWindow = new BrowserWindow({ }); //Browser options can be included here.
              mainWindow.loadFile(`index.html`);
      });
  2. Point the package.json “main” towards the new main.js file.
    If the previous “main” was the index.html, everthing should be setup now.
    However, if you are using webpack, you will need to point towards the index.html from the dist folder. In order to intergrate both the webpack build and the Electron start into the same startup script, I added an additional npm script in the package.json: “start”: “webpack –mode production && electron . ”

     

  3. Run “npm run start” in your terminal and voila! Your web application should now show up as a desktop application.

Additional packing steps:

Now that you got you applicaiton up and running, it would be nice to distribute it. For Electron, this requires one of three possible solutions: Electron-packager, Electron-builder, and Electron-forge. I have only tried electron-builder and electron-packager, and from my perspective, I prefer electron-builder. 

 

  1. To use electron-builder, start by installing it: npm install electron-builder.

     

  2. In the package.json file the two following scripts should be added.
    “scripts”: {
            “pack”: “electron-builder –dir”,
            “dist”: “electron-builder”
    }
  3. Run “npm run dist”. This should provide you with a distributable file (dependent on the OS), which can install/execute the application.
    Note, that if you are using webpack, you will have to declared files from the dist-folder in the package.json’s build brackets.
    “build”:{
            “files”: [
                      “dist/index.html”
            ],
    }

NW.Js (Node Webkit)

NW.js or Node Webkit, as it was known by in the past, is a viable solution, which unfortunately have not seen the same amount of adoption as Electron. It is maintained and funded by Intel, which seems promising, but as for now I have not been able to find any well-known applications utilizing NW.js. 

Getting started with NW.js is actually simpler than Electron, as you will see from the demonstration. This is primarily because of the single context thread in NW.js. This means that both the context of the web application and the browser dialog is handled from within the same thread. This feature differential NW.js from Electron, in which the web applications context has to be handled seperate from the browser dialog’s context. 

In terms of packaging and distributing the desktop application, NW.js is already sealed and ready. As soon as the project is finished, it is possible to distribute it by exporting the folder in which it lies. NW.js is therefore also the only solution presented, which does not require a packaging plugin. 

Finally, NW.js comes with one feature, which the team at Electron has decided not to prioritize: Source code protection. Similar to a normal browser, any user is by default able to inspect the source code of the client. In the perfect world this is okay, since the client should always be made as “thin” as possible (minimal or no business logic). However, what we see today is many new developers and technologies enabling the developers to only write client-side code and utilize BaaS (Backend-as-a-Service) services such as Firebase. This also means that the business logic thereby moves towards the client, which dependent on the technology of choice, might or might not have source code protection.

INTEGU - node-webkit

Demonstration

Prerequisite: A functional web application with npm installed.

  1. Download the “normal” NW.js solution from NW.js homepage and extract the file.

  2. Create or alter the package.json file within the projects “src” folder. Make sure that the application has a “name” and “main” key, which respectivily points towards the applications name and index.html. 

  3. Copy and paste your entire web application’s “src” folder into the NW.js folder.

  4. Click the executable file in the NW.js folder. Done! Executable and distributable. 

CEF (Chromium Embedded Framework)

CEF is also a viable solution on the market. It is backed, funded and utilized by Spotify, and is therefore also likely going to stay on the market for as long as Spotify exists. Unfortunately CEF, does not see any major adoption either and therefore manages to fall in the shadow of Electron. 

When compared with the two solutions above, it is difficult for me to say why you would choose CEF over the others. CEF has made no mention of any source code protection feature, it runs on the full version of Chromium (similar to NW.js), it requires additional tooling to package and distribute, and beside the Spotify product itself, it has not been possible to find other well-known adopters. 

Because of the reasons mentioned above, I did not want to try and implement the solution myself. However, I of cause checked the web for another good tutorial, which I could link to. But after a few minutes stumbling around, I realized that no such tutorial existed. At least the tutorial on the Bitbucket repository is still available, so I guess I will link to that. 

CEF Tutorial: CEF Repository (Good luck 😉)

INTEGU - Chromium-embedded-framework

About

Hi, I'm the Author

My name is Daniel H. Jacobsen and I’m a dedicated and highly motivated software developer with a masters engineering degree within the field of ICT. 

I have through many years of constantly learning and adapting to new challenges, gained a well-rounded understanding of what it takes to stay up to date with new technologies, tools and utilities. 

The purpose of this blog is to share both my learnings and knowledge with other likeminded developers as well as illustrating how these topics can be taught in a different and alternative manner.

If you like the idea of that, I would encourage you to sign up for the newsletter.

Cheers! 🍺

Didn't Find What You Were Looking For?

Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages
Scroll to Top