Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tauri vs. Electron: An Analysis #2

Closed
captainsafia opened this issue Nov 9, 2023 · 4 comments
Closed

Tauri vs. Electron: An Analysis #2

captainsafia opened this issue Nov 9, 2023 · 4 comments

Comments

@captainsafia
Copy link
Member

In our recent conversations about the next iteration of nteract (see #1), @rgbkrk brought up the prospect of using Tauri (https://tauri.app) as an alternative to Electron for our packaging and deployment story. Although he said it mostly with jest, I'm going to take it seriously and compare the two platforms here just so we are building on a solid foundation for this iteration of the project.

My intuition tells me that Electron is the better option here. We have prior history with it, it allows individuals to thing and work in one language throughout our entire codebase, and it's quite popular. That being said, we should still examine Tauri on its own merits.

The elements I'm considering in this comparison are:

  • Ability to configure auto-updates for applications
  • Ability to package applications via CI, particularly for more complicated platform targets like macOS
  • Integration with platform-specific APIs around key mappings, window management, etc

Configuring auto-update for applications
Electron offers a free service (update.electronjs.org) for managing updates and requires leveraging a separate npm package (update-electron-app) to configure auto-updates. To support auto-update, apps must be:

  • Running on either macOS or Windows
  • Have a public GitHub repository
  • Have releases published to GitHub Releases
  • Have builds that are code-signed

Configuring the auto-update requires calling require('update-electron-app')() in the app's main process file.

Tauri provides support for configuring auto-updates as well. Unlike Electron, Tauri requires that you configure the update backend yourself. There's no freely available update service. This is a bit of a bummer because it means there's extra operational and maintenance overhead to maintain the update service ourselves.

IMO: Electron wins for simplicity here.

Ability to package applications via CI, particularly for more complicated platform targets like macOS

One of the things we weren't able to achieve fully with nteract v1.0 is support for continuous deployment of the application. This is easy to do for some platforms (Linux), has medium difficulty for others (Windows), and proved even harder for others (macOS). macOS is a particular pickle here because of the additional requirements they place around signing and notorization for apps distributed on Mac targets and the lack of cross-compilation support for macOS binaries.

Given that the complexities here are primarily dependent on the distribution platforms, it doesn't appear to me like either Tauri or Electron is a standout winner here. I'll give Electron a bit of an edge since there's an existing ecosystem of deployment tools (like this GitHub Action). I wasn't able to find the same ecosystem of tooling for Tauri.

Integration with platform-specific APIs around key mappings, window management, etc

Platform integrations, like interacting with the system tray, are key in building a robust desktop experience. Both platforms seem to offer elegant APIs here, for example to support file-drop in Tauri:

const {listen} = await import('@tauri-apps/api/event')

listen('tauri://file-drop', async event => {})

And file-drop in Electron:

document.addEventListener('drop', (event) => {
    event.preventDefault();
    event.stopPropagation();
 
    for (const f of event.dataTransfer.files) {
        // Using the path attribute to get absolute file path
        console.log('File Path of dragged files: ', f.path)
      }
});

Tauri doesn't have full fidelity for certain APIs. For example, they currently only implement the backend/Rust portions of native context menu support. See this issue for more info.

Here, I'm inclined to give Electron the dub given the completeness of its API set.

There's other factors that make Tauri a formidable alternative to Electron. It's faster and produces smaller binaries, which aligns with our renewed focus on performance for the next iteration of nteract. Also, Tauri provides a robust CLI for running an application with hot reload enabled and the ability to deploy with the CLI. I'm especially interested in this because configuring hot reload for our Electron app requires some Webpack shennagins that would be great to avoid.

IMO, it seems like using Tauri is a perfectly reasonable choice here. It's a newer project and not as established as Electron and we'd have to learn the ropes of a new platform but I believe the wins around perf and developer experience make it a much more compelling option.

TL;DR: Let's do Tauri.

What does everybody think?

@rgbkrk
Copy link
Member

rgbkrk commented Nov 10, 2023

Superb outline. As I read it, it seemed like Electron was the winner. I was totally surprised to see Tauri win out in the end. 😄

I think it's worth experimenting with Tauri given our renewed charter:

Build a solid, stable, performant desktop notebook app with more contributors

@captainsafia
Copy link
Member Author

@rgbkrk Yes, I did pull a bit of a plot twist at the end there.

You've summarized my perspective perfectly. Our renewed focus on perf and developer experience makes Tauri a more compelling option IMO.

@rgbkrk
Copy link
Member

rgbkrk commented Nov 28, 2023

Kernel Sidecar in Rust for us to interact with kernels from Rust: https://github.com/kafonek/kernel-sidecar-rs

@rgbkrk
Copy link
Member

rgbkrk commented Jan 12, 2024

Closing since we're definitely on Tauri now!

@rgbkrk rgbkrk closed this as completed Jan 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants