Tauri vs. Electron: performance, bundle size, and the real trade-offs

Contents#

• The main differences between Tauri and Electron
• Features comparison
• App benchmark
• Why we chose Tauri for Hopp
• Conclusion

Intro#

At Hopp, we're building a cross-platform remote control application designed for a low-latency remote pair programming experience. Providing the best possible user experience is our top priority.

Early in the development journey, the decision came to use either Tauri or Electron to build the app. Using one of these frameworks offered a promising way to avoid writing native code for each platform (Windows, macOS, Linux). This meant a crucial choice needed consideration.

Both Tauri and Electron offer robust frameworks with fundamental differences. We needed to carefully consider these differences to decide which framework would best serve Hopp long-term.

If you currently weigh Tauri against Electron for your project, this post might help.

What this post covers:

• The core differences between Tauri and Electron under the hood.
• The advantages and limitations associated with each framework.
• A benchmark comparing app size, startup time, and memory usage.
• The reasoning behind choosing Tauri for Hopp.

The main differences between Tauri and Electron#

When developers first research Tauri, they often encounter articles describing it as a "lighter Electron" or emphasizing the need to "learn Rust." While truth exists in these points, they don't capture the full picture. These two leading cross-platform frameworks have architectural differences that impact development and performance.

Let's dive into how Tauri and Electron operate behind the scenes.

Electron's main process#

Electron's main process runs as a NodeJS process. This architecture necessitates shipping a Node.js runtime with your app to ensure it runs correctly on any user's machine.

As a result, your app's event handling relies on the Node.js event loop. For higher performance tasks or deeper OS-level interactions, you typically must spawn a separate process and establish communication via Inter-Process Communication (IPC) or another protocol like Unix Sockets.

Electron's renderer process#

Think of the renderer process as a single browser tab spawned by the main process. In practice, every window you open in an Electron app creates a new renderer process.

This means an app with many windows will run numerous renderer processes concurrently. Developers must account for the cumulative memory and CPU usage of these processes—akin to running mini-Chromium instances in the background.

The Electron team offers a helpful analogy:

Tauri main process#

Tauri leverages Rust for its backend. A key advantage comes from Rust compiling to a native binary, eliminating the need to bundle a runtime (like Node.js) with the app. This contributes to a more lightweight app, though it involves trade-offs discussed later.

Tauri WebView process#

Instead of bundling the entire Chromium engine, Tauri uses the operating system's native WebView component to render the UI. This component generally weighs less than a full browser engine. Currently, Tauri uses:

• WebView2 on Windows (based on Microsoft Edge/Chromium)
• WKWebView on macOS (based on Safari/WebKit)
• WebKitGTK on Linux

By relying on the system's WebView, Tauri creates smaller app bundles, but this comes at a cost.

Developers using Tauri face potential challenges with cross-platform UI consistency. Browser-specific quirks can appear—issues in Safari but not Chrome, or Firefox behaving differently across operating systems. Since Tauri uses different underlying web engines on each OS, these platform variations become factors developers must manage during app development.

Features comparison#

Below is a comparison table highlighting key aspects of Tauri and Electron, with a slight emphasis on factors important to us at Hopp. Following the table, I'll detail a simple benchmark comparing size, startup time, and memory usage.

App benchmark#

To illustrate the practical differences, this benchmark compares two apps using each framework. Their function:

1. Display a main window with a button to open a new window.
2. Open 6 windows simultaneously to observe resource usage.

The following commands scaffolded the apps:

# For Electron
npx create-electron-app@latest electron-demo-app --template=vite-typescript

# For Tauri (selected TypeScript with Vite and React)
yarn create tauri-app

The resulting applications looked like this:

🚧 Disclaimer: This is a basic benchmark performed on my MacBook Pro with a single run (N=1). Take the following numbers with a grain of salt.

Build time#

The initial build time was significantly slower for Tauri, primarily due to the Rust compilation step. Subsequent builds are typically much faster.

# Electron
❯ time yarn make
...[LOGS]...
yarn make  13.23s user 1.55s system 93% cpu 15.818 total

# Tauri
❯ time yarn tauri build
...[LOGS]....
yarn tauri build  380.11s user 28.37s system 504% cpu 1:20.94 total

Bundle size#

As expected from the architectural differences, Tauri produces a smaller app bundle. This occurs because:

• Tauri doesn't bundle a JavaScript runtime (Node.js).
• Tauri uses the system's WebView instead of bundling Chromium.

The difference shows clearly below, from 8.6MiB for Tauri to 244MiB for Electron:

❯ du -h -d 1 .
8.6M    ./tauri-demo-app.app
244M    ./electron-demo-app.app

Memory usage#

This area highlights Tauri's "lighter" reputation. The difference stems from two main areas:

1. Electron's Main Process: The Node.js runtime inherently consumes memory.
2. Renderer Processes: On macOS, Electron's Chromium-based renderer processes consumed roughly double the memory of Tauri's WKWebView processes for the same window.

After opening 6 windows in each app, the approximate memory usage measured:

• Tauri: ~172 MB
• Electron: ~409 MB

Startup time#

Startup time is another common consideration. In this simple benchmark, the difference was negligible. Honestly, basing a framework decision solely on a startup time difference of less than even 1 500 ms is likely overthinking it for most applications.

For more detailed benchmark data across frameworks, check out the Web to Desktop Framework Comparison repository.

Why we chose Tauri for Hopp#

The comparison above presents the trade-offs between Tauri and Electron. For Hopp, the decision tilted towards Tauri for these key reasons:

1. Backend performance#

Hopp relies on a customized version of WebRTC to achieve ultra-low latency screen sharing. The app needs to stream video directly from a backend process, not using the browser's standard screen-sharing Application Programming Interfaces.

Rust's performance suits this intensive task exceptionally well. Implementing this in Electron would require managing a separate process for the video stream, complicating the architecture.

2. Sidecar support#

While Tauri's main process uses Rust, Hopp needs a separate process (a "sidecar") for handling screen streaming and remote control input (clicks, typing). This allows for developing and testing this component separately from the rest of the app.

Tauri's built-in Sidecar concept simplifies managing the lifecycle of this external binary. Achieving the same in Electron would involve manually spawning, monitoring, and communicating with an external process, adding complexity.

Note: Tauri's Sidecar differs conceptually from the Kubernetes pattern but serves a similar purpose of managing a companion process.

We also utilize the sidecar process to draw the controller's cursor. In the future, we could swap to use Tauri egui.

3. Feature availability#

Although Tauri arrived more recently than Electron, it evolves rapidly. Tauri v2, in particular, closes the feature gap, incorporating essential functionalities like a built-in updater as a first-class citizen. The project's momentum and focus on performance and security aligned with Hopp's needs.

Conclusion#

I hope this comparison has been insightful, especially if you're navigating the choice between Tauri and Electron for your next project.

No single "right" answer exists. The best choice depends on your specific use case, team expertise, and project requirements. Both frameworks can build powerful desktop apps, each with distinct strengths and limitations.

For questions or further discussion, reach out on X/Twitter or email directly at costa@gethopp.app.