Add support for Desktop application using Electron

[devleejb]

What would you like to be added: Currently, the project only supports web applications. It would be beneficial to add support for Desktop applications as well. Utilizing framework like Electron could enable the project to expand its compatibility to desktop platforms.

Why is this needed: Adding support for Desktop applications would enhance the versatility and reach of the project, providing users with more options to interact with the application beyond just web browsers.

Additional Information:

[minai621]

@devleejb I Interested in this issue, Can I try it?

If I proceed with the issue, I wonder if I can use cross platform framework like tauri in addition to electron.

[devleejb]

@minai621 Sure, I'll assign this to you.

However, I'm not familiar with desktop applications. Could you share the pros and cons of the different solutions you're considering?

I believe it would be good to discuss this before proceeding with the implementation.

[minai621]

@devleejb It seems like Tauri and Electron are the most popular libraries for building native desktop applications. After comparing the two.

Tauri

• Pros Lightweight: Small app size (a few MB) by using the system's native webview. Low Memory Usage: Doesn't bundle Chromium, so it uses fewer system resources. Secure: Strong security model by isolating frontend and backend. Native Access via Rust: Access to system features (file system, OS APIs) with high performance and safety through Rust.
• Cons Rust Complexity: Requires knowledge of Rust, which has a steep learning curve. Smaller Ecosystem: Fewer third-party tools and plugins compared to Electron.

Electron

• Pros Familiar JavaScript/Node.js Environment: Easy access to native features using JavaScript. Large Ecosystem: Many libraries and tools available. Cross-Platform Compatibility: Well-supported across multiple platforms. Native Access via Node.js: Direct interaction with native system features using Node.js.
• Cons Heavy and Resource Intensive: Large file size and higher memory usage due to bundling Chromium. Security Concerns: Allows full Node.js access in the renderer process by default, which may create security risks.

Additionally, there’s NW.js, but it has a less mature ecosystem compared to Tauri and Electron, though it offers a simpler, unified JavaScript environment for accessing native features.

[devleejb]

It would be good to use JavaScript, just like in other projects.

There seem to be many things to discuss regarding the project setup, so let's discuss them together here.

[minai621]

It would be good to use JavaScript, just like in other projects.

In Tauri, Rust is primarily used for interacting with native system features such as the file system, OS APIs, or hardware. However, the complexity of Rust is mostly abstracted, so unless there is a need to implement specific native system functionality, the majority of the code can be written in JavaScript/TypeScript.

Focus on converting an already developed website into a native application, Tauri might be the better choice due to its lightweight nature and lower resource consumption.

[minai621]

@devleejb After considering the deploy for current work, I think Tauri might be a better option than Electron, mainly due to the smaller packaging size. Once we move forward with distribution, we’ll need to set up a proper process for it.

compares the two framework: https://www.levminer.com/blog/tauri-vs-electron

[devleejb]

@minai621 I understand that Tauri has advantages in terms of resource usage. However, considering the open-source projects, I believe Electron is easier to manage due to its larger ecosystem. What are your thoughts on this?

Both frameworks seem to have their pros and cons. @hackerwins May I ask for your opinion?

[hackerwins]

@devleejb @minai621

Thank you both for your valuable input. After careful consideration:

I hope we proceed with Electron, primarily because:

• It's easier for the sub-project owner(@devleejb) to maintain, which is crucial for long-term sustainability.
• Its larger ecosystem offers better support and resources.

However, we'll keep our options open:

• We'll structure our code to be as framework-independent as possible.
• We'll optimize for performance to mitigate Electron's resource intensity.
• We'll keep Tauri in mind for potential future migration.

This approach leverages our current team's strengths while allowing flexibility for future developments. I hope we start with a small prototype in Electron and reassess as we progress.

Your continued input is welcome as we move forward.

[minai621]

@devleejb

I’ve encountered platform-specific limitations when building with Electron. To build a macOS app, it must be done on a macOS environment, and the same goes for Windows builds—they need to be built in a Windows or Wine environment.

We need to discuss two issues

• How to handle platform-specific builds macOS builds must be performed in a macOS environment, and Windows builds can be done using Docker with Wine, though this has some limitations.
• Pipeline considerations After the builds, we need to create an environment where the resulting packages can be downloaded for codepair testing.

[minai621]

@devleejb

I’ve encountered platform-specific limitations when building with Electron. To build a macOS app, it must be done on a macOS environment, and the same goes for Windows builds—they need to be built in a Windows or Wine environment.

We need to discuss two issues

• How to handle platform-specific builds macOS builds must be performed in a macOS environment, and Windows builds can be done using Docker with Wine, though this has some limitations.
• Pipeline considerations After the builds, we need to create an environment where the resulting packages can be downloaded for codepair testing.

Additionally, could we resolve the issue by making our app a PWA instead of an Electron app?

[devleejb]

1. Handling platform-specific builds We can use Electron Builder Action, which supports multiple environments.
2. Deployment considerations For now, I believe uploading GitHub release artifacts is sufficient.
3. PWA While PWA is also a good option, its support varies depending on the user’s OS and browser (e.g., Safari). Additionally, for installable applications, registering on the App Store in the future could provide more opportunities for users to discover CodePair.