Comparison Among Three Approaches to Convert a Web application into a Desktop application
The choice among the three approaches majorly depends on the skill and requirement of the desktop application. Here’s a viewpoint on when which approach should be used or suits best.
Approach 1: Adding Electron app functionality to your application:
This approach is the most common way to convert a web application to electron application, wherein the main html file(index.html) of the web application inside the build(dist folder) of the application is loaded in the electron window, after installing the required dependencies.
However, using this approach eventually increases the size of the packaged application, since web applications contain a lot of extra code which is not necessarily a part of (/required for) the electron desktop application. The size of the packaged desktop application can be reduced by deleting/removing the unnecessary code from the application code, leaving behind just the relevant directories and dependencies. This requires a working knowledge of each directory and how it affects(directly or indirectly) the root directory of the electron application. To sum up:
Advantages:
- Minimum steps
- All resources are available and functional beforehand
- Time saving
Disadvantages:
- Large package size
- Relative path resolution fails
Approach 2: Using angular electron boilerplate repository from github and embedding your application in it:
This approach is the conventional way to create a desktop application. The boilerplate provides pre-installed dependencies and files required for running, packaging and creating installers for the application, so it lets you focus on the content and business logic. This approach turns out problematic where there is a large number of interconnected modules or a large number of dependencies. It also leads to version compatibility issues if the original project is of an older angular version. Hence, the versions of all dependencies of the boilerplate must be compatible with the versions of all dependencies of the web application. This process is time consuming and requires skill and experience as it usually leads to a multitude of errors. To sum up:
Advantages:
- Pre installed dependencies, setup and boilerplate code for an electron app
- Reduced package size
- Better suited architecture
Disadvantages:
- Copying components from one application is time consuming and leads to a multitude of errors.
- UI features appear broken until the complete dependent modules are added.
- Requires complete knowledge of the web application structure and workflow.
- Not recommended for large sized applications
Approach 3: Using the existing url of the website to load the desktop application:
This approach is the easiest and requires a minimum codebase, since it simply loads the url of the existing web application inside a chromium window. It works flawlessly and exactly the way the deployed web application works with all domain-dependent functionalities and features. One major downside to using this approach is that it stops working completely when the web application server is down or the user machine is not connected to the internet, which is one of the major reasons for creating a desktop application in the first place. To sum up:
Advantages:
- Minimum effort
- Minimum development time
- Minimum code base and package size
- Requires one common codebase and resources for both the web application and desktop application, since the same url address is used for both the applications
- Very less dependencies
- Domain-dependent features are completely functional.
- Flawless UI
Disadvantages:
- Fails completely when not connected to the internet or website server is down
- Customizing and styling the browserWindow can be difficult since there is no file (usually index.html)being rendered.
COMPARISON TABLE