About a decade ago, we had a golden era with pure native desktop applications. However, hybrid applications became popular over native applications due to the easiness of development, beautiful graphical user interfaces, and impressive cross-platform support. Native applications are undoubtedly great from the technical perspective because of their great resource usage, unlike hybrid applications. We all can use hybrid applications without any visible problem because our powerful hardware solves performance issues coming from common hybrid apps.
A few years ago, I tried to use the desktop application of Slack. Thereafter, I found that it was written using the Electron framework which ships a whole browser and a runtime (Node.js) along with each application. This situation popped out a nice question. Why do I need to install a web browser again even if I already have a web browser installed?
Bloatware is bad
If a particular software abnormally uses a lot of the physical resources of the computer over the usability, the specific software is often identified as bloatware. In fact, every software that consumes a lot of resources is not bloatware. For example, if a video editing software takes more resources during the rendering process, we cannot put it into the bloatware bucket. But how about if a normal program takes a lot of space in physical memory?
Nowadays, almost all developers tend to make their desktop applications using the Electron framework mostly due to the easiness of the development and fast delivery. Unfortunately, they don’t care about performance and efficient resource usage because their main goal is to make a fancy desktop application. But in reality, those hybrid apps become bloatware because more resources are needed just to drive hybrid applications than the actual resource usage of the particular application. Hybrid applications are fine since modern computers are powerful enough to render web-based interfaces fast to give the same look and feel as native applications. On the other hand, we need a framework to make non-bloat hybrid apps.
We need a better way
The popular operating systems such as Linux, Windows, and macOS has a web browser component along with an API. Linux has WebKitGTK, Windows has MSHTML/WebView2, and macOS has Cocoa/WebKit. Electron-based hybrid apps are packaged with the Chromium browser mostly to avoid browser compatibility issues. However, Chromium is a large project. Therefore, even if you build a small app that uses just kilobytes of memory and the disk, the actual memory/disk usage will be a lot of megabytes because Chromium consumes a considerable amount of resources. Further, each native window has a separate Chromium instance. In other words, If you open 10 windows of Visual Studio Code, there will be 10 Chromium instances. Indeed, it is possible to replace Chromium with the built-in browser component to reduce the size of modern hybrid apps.
Moreover, Nodejs is also a quite large project because it consists of a whole JavaScript engine (V8). Most hybrid apps are not frequently using native system calls, some apps are not using at all. For example, if you build a hybrid text editor app, it will call the operating system functions when there is a need to read or write a file. Also, if you are building a calculator hybrid app, there is no need to call operating system functions ever. It is possible to replace Node.js with a kind of native bridge to handle operating system calls coming from the web browser component. The native bridge may handle things like reading files, writing files, executing processes, etc.
Neutralinojs
I started the Neutralinojs project around 2 years ago with some colleagues at the university. Our initial idea was to bypass the browser sandbox by exposing several native features via a client library. The first version of Neutralinojs gave a cross-platform software development kit for developers to build web applications with native operating system functions. In other words, we could make a note editor web application that will directly save notes into the disk. Thereafter, I found that another developer who had the same idea wrote a header-only C++ library called webview to make a cross-platform web view component that uses the existing web browser component of each operating system. That situation was like the story GNU/Linux operating system. Richard Stallman completed the last missing piece of his conceptual operating system by integrating the Linux kernel built by Linus Torvalds.
Similarly, I integrated webview to the Neutralinojs server and made it a cross-platform desktop app development framework. Now, the Neutralinojs server handles native operating system calls coming from the hybrid applications. On the other hand, a modified version of the webview library runs the web part of the hybrid application. After it reached the developer community we created several toolings for developers such as an extensible CLI and several starter templates (For example, Reactjs template and TypeScript template).
