Comparing native graphical apps to web UIs
Despite the benefits that web-based applications can deliver, every technology choice means making a trade-off in some area, so let's look at a few of the common issues that might influence your decision of whether to build a native app or web-based hybrid.
Development speed versus delivery
One of the main reasons to pick a web technology to build your application is the speed of development. The very nature of developing in this way means that you can live-preview your work in a web browser. The availability of browser-based editors also means that a design team can tweak the user interface without much code experience. Large portions of your web app could also be used in your hybrid application (or the other way round) to provide a high level of reuse and minimal additional work to support desktop and mobile delivery.
The trade-off regarding speed is found at runtime—as the applications require a web view to run the code, there is an impact on how fast the application can be loaded and executed. Each time a hybrid app is loaded, it creates a small version of a web browser inside the window, loading the code like a web page and starting the execution of the bundled JavaScript. To most users, this may not be so slow as to be frustrating, but when compared to natively-compiled applications, there can be a noticeable difference. Depending on the framework chosen, it is also common for this model to require a lot of memory—indeed, Electron has a reputation for requiring a lot of RAM, with the simplest application using nearly 70 MB just to show 'Hello World'.
The actual speed of execution may also be noticeably slower for applications built on web technologies. Due to the layers of abstraction, a web-based app will typically take more time and CPU cycles to perform the same operations than a compiled native application (though technologies such as WebGL and WASM (short for Web Assembly) are attempting to improve this). Therefore, if your application is likely to be CPU-intensive, or have lots of animated graphics, you may wish to benchmark different approaches to determine which platforms are capable of meeting your requirements for app responsiveness.
Another consideration may be automatic updates—would you like your apps to always be running the latest version? Some web-based toolkits offer the functionality to download application updates and dynamically load the new version without the user having to worry. This can be a large benefit, but could also be frustrating if your customers expect the software to work exactly the same every day until they opt to update it. Some people are also concerned about how applications of this nature may appear to phone home—that is, reporting back to a central server about how the apps are being used, and where, as part of the update process.
Visual style
Another main decision point for choosing web technology-based app development may be the power of the presentation layer (CSS). It is possible, using a combination of image assets and style-sheet code, to create almost any visual style desired. For developers (or indeed, the designers on their team) that desire a completely bespoke look to their application, this could be a great fit. It is worth considering how your users will use the application, however, and whether a completely custom look will inhibit the usability in any way.
This benefit of complete customization can become challenging if the application is intended to match the user interface style of the current system. As the rendering is infinitely flexible, developers can of course add tweaks to a style that make it look subtly (or substantially) different when running on certain systems. This type of adjustment can end up taking a surprising amount of additional effort—as each platform can have a different style over time. A GUI that attempts to match the system style but does not quite manage this is far more off-putting than the one that is clearly following its own style guide.
Therefore, it is probably best to avoid hybrid apps if you desire to blend in with the other apps on a system. Web technologies do offer a fast-to-develop, adaptable platform for cross-platform applications, but there are constraints to this approach that should be considered as well.
Technical constraints
Applications built with web technologies, even those built to look like system apps with hybrid frameworks, run in a sandbox. This means that they are limited in certain ways regarding access to devices and system features. The JavaScript APIs that grant access to underlying functionalities are constantly expanding to work around these constraints, but if your application would benefit from non-standard peripherals or integration into specific operating system features, then a web UI may not be the right choice for you.
Access to communications ports, peripheral devices not included in typical web APIs, and process management are some low-level elements of an application that would not be supported by default. Additionally, interacting with a desktop environment's system tray, search features, and some advanced file management may be difficult to access from within the JavaScript code. To attempt to bridge this gap, some hybrid toolkits allow native code to be written and loaded as libraries to access this functionality. Such extensions, however, would need to be written in the platform's own language (usually C or C++) and then compiled for each supported platform. Not only does this increase the complexity of application distribution; it can also detract from the single-codebase app design technique that using web tools offers.
In comparison to this, other approaches to cross-platform development typically provide an abstraction over all supported operating systems so that an app can be built just once, but where support is missing, they provide a way to get direct access to the underlying features. This is often in the form of a language bridge or a way to load system libraries from the higher-level language. This can involve needing to build with different programming languages, as discussed earlier, but with cross-platform technologies outside of the web sandbox, it does not normally increase the distribution complexity as much. Additionally, it is far rarer to find devices not supported by a native cross-platform toolkit in comparison to one that is based in an embedded web browser.
If some of the constraints of web technology cross-platform development mentioned in this section might impact your app, or if you would prefer not to be coding with HTML and JavaScript, then native toolkits are probably the right approach, which we will look at next.