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.
Generally, three solutions exists on the market: Electron, NW.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 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.
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.
const {app} = require(‘electron’);
app.on(‘ready’, () => {
mainWindow = new BrowserWindow({ }); //Browser options can be included here.
mainWindow.loadFile(`index.html`);
});
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.
“scripts”: {
“pack”: “electron-builder –dir”,
“dist”: “electron-builder”
}
“build”:{
“files”: [
“dist/index.html”
],
}
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.
Prerequisite: A functional web application with npm installed.
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 😉)
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! 🍺
INTEGU uses cookies to personalize your experience and provide traceability for affiliate links. By using the website, you agree to these terms and conditions. To learn more see the privacy policy page.