NetPad icon indicating copy to clipboard operation
NetPad copied to clipboard

[RFC] Swapping out Electron for a Native Shell

Open tareqimbasher opened this issue 6 months ago • 2 comments

This is a discussion I'm looking to solicit feedback on. So all comments and suggestions are welcome!

I've been playing around with swapping out the Electron shell that NetPad currently uses for a native shell that is smaller in size and memory footprint. I reviewed a number of solutions, each with their own drawbacks, and finally decided to give Tauri (v2) a spin. Tauri is a cross-platform desktop framework built on Rust that uses WebView to host the web interface. This means:

  • Smaller package/install size: No bundled Chromium browser. It will utilize WebView that is already installed on a user's machine to render the interface.
  • Less resource intensive: Tauri compiles to a native binary and is much lighter in terms of binary size and memory usage.

Background

NetPad uses Electron as a "shell" only. What I mean by that is Electron is only used as a container to render the web interface and manage the different windows that make up the app. NetPad does not utilize Electron's extensive APIs for its main functionality, a decision I'm happy I made early on. This makes it easier to swap it out for something else. Currently NetPad uses Electron's APIs for the following:

  • Window Management: Open, size and position windows. Window controls like minimize, maximize...etc.
  • Main Menu
  • Native Dialogs: File Save and MessageBox dialogs
  • Desktop Notifications when a script completes while NetPad is not in focus

The usage of these APIs is abstracted to support multiple shells. Currently NetPad supports 2 shells. The first is Electron, which is the one bundled with every release. While I haven't yet provided a release asset for it (or really promoted it beyond mentioning how to run it in the README), NetPad can also be used in a web browser, without Electron. In this case the browser is the "shell." Adding a new shell is relatively straight-forward due to this abstraction.

Tauri

Setting up Tauri and getting a sample app running was simple. Within a couple hours I had NetPad running in a Tauri app. I've never used Rust but thanks to the Tauri documentation and some help from the Rust Community Discord it was all pretty seamless.

I'm still working on the implementations of the API abstractions mentioned above to work with the new Tauri shell but I thought I'd share some early stats that I'm seeing.

Size

Metric Electron (MB) Tauri (MB) % Reduction
Shell Size 1 251 8.4 96.65
.NET App Size 2 192 103 46.35
Installer Size (.deb) 125 43 65.60
Installed Size (.deb) 443 111 74.94

Memory Usage 3

Metric Electron (MB) Tauri (MB) % Reduction
Shell 230 34 85.22
.NET App 110 110 --
OmniSharp 104 104 --
Total 444 248 44.14

Notes:

  • [1]: This is the installed size of the shell only, without the size of the .NET backend or the JavaScript web interface.
  • [2]: Tauri is not directly responsible for this reduction in size. Currently NetPad uses the Electron.NET library and its associated tooling to build and package the app. The tooling is somewhat restrictive. Switching to Tauri gave me the opportunity to reduce the .NET app size by publishing it with --no-self-contained.
  • [3]: These are estimates from my Linux installation's task manager. The readings were taken after just starting the app; no scripts were ran or other user interaction.

Startup times also seem to have improved, although I'll wait on posting those until I have a more apples-to-apples comparison.

Drawbacks

Tauri also some drawbacks:

  1. Tauri depends on an existing installation of WebView. While most users will already have it installed, ones that don't will have to do so. WebView's behavior can be different across different platforms or even versions on the same platform. This opens the door for various user reports about crashes and issues that are environment-specific and hard to diagnose and remedy. Electron is more predictable and works relatively the same way on any platform.
  2. Tauri is relatively new compared to Electron. Electron has a much larger community, better docs, and trusted longevity.
  3. Packaging. Tauri does not currently support cross-platform compilation and bundling of the application. Compiling a Windows binary has to be done on Windows, a Linux binary on Linux...etc. Using GitHub actions to build packages for each platform solves this concern but its also more restrictive than what we've got currently where I can build NetPad for all platforms on my local Linux machine and test with that freely. Also electron-builder is a really neat AIO solution that packages for all platforms and package types really easily. Tauri does not offer an AIO tool that does this and instead will have to rely on package/platform-specific tooling.
  4. Tauri uses Rust. I've actually found it quite enjoyable delving into Rust but its also prohibitive for most .NET users looking to contribute to this project. But since the Rust-dependent shell is only used for very minor functionality (window management..etc) 99% of contributions wouldn't have to deal with that part at all, and would mostly be interested in the main functionality of the app.

Feedback

I'd love to hear any feedback and suggestions.

  • Are you guys interested in the direction here?
  • Do you feel the fact that NetPad is currently Electron-based is stopping you from using it? Whether that be because of resource limitations or purely ideological ones :smile:
  • Do you think the size/memory gains are worth the drawbacks?

If we move forward with this, I don't think we'd have to kill the Electron app, at least not in the beginning. Both Electron and Tauri packages will be provided for all platforms (I hope) for the community to test. If the Tauri app proves to be stable and friendly enough we can talk about retiring the Electron app.

Keep in mind this is not a diss of Electron, I think Electron is great! But I also want to give everyone a voice here and if there's enough interest and Tauri proves to be a reliable improvement... well that's why we build software!

tareqimbasher avatar Jul 29 '24 19:07 tareqimbasher