Tauri vs. Electron vs. Deno Desktop vs. Electrobun: A Practical Comparison
Electron has been the default choice for cross-platform desktop apps built with web technologies for over a decade. The tradeoffs, large bundles, high memory usage, and the overhead of shipping Chromium with every app, have been well documented. A new set of frameworks has emerged to address them: Tauri, which uses a Rust backend and the OS's native webview; Electrobun, from the team behind the Bun runtime; and Deno Desktop, which shipped as an official feature in Deno 2.9.0 in June 2026.
To get beyond marketing claims, we built the same application with all four frameworks: a functional screen recorder with video editing and export capabilities. We then measured bundle size, startup time, memory usage, and runtime performance, and evaluated the developer experience on each.
The test application
A screen recorder is a useful benchmark because it exercises everything that matters: it requires OS-level native API access for capturing screen data, system audio, and microphone input; it demands real-time data processing; it needs a complex UI with a video player and interactive timeline; and it continuously transfers video chunks between the frontend and backend, which stresses the inter-process communication layer of each framework.
The application flow was identical across all four: source selection, recording, stopping via a system menu bar icon, editing via a clip timeline with split and delete, and export to MP4.
Bundle size
After building for macOS distribution:
| Framework | Bundle size |
|---|---|
| Tauri | 57 MB |
| Deno Desktop | 111 MB |
| Electron | 323 MB |
| Electrobun | 418 MB |
Tauri's 57 MB result is the most striking. To understand why the numbers land where they do, it helps to look at what each framework bundles.
Electron ships a complete Chromium instance with every application. That's the primary contributor to its 323 MB size. The newer frameworks try to avoid this by using the OS's built-in webview (WebKit on macOS) instead.
Electrobun defaults to the system webview but our screen recorder needed navigator.mediaDevices.getDisplayMedia(), the standard browser API for requesting screen capture. Electrobun's system webview doesn't support it, which forced us to configure Electrobun to bundle Chromium instead. That single decision added roughly 200 MB and explains why it came in larger than Electron.
Tauri's approach is fundamentally different. Recording is handled entirely in the Rust backend using macOS's native ScreenCaptureKit framework, the same API QuickTime Player uses. The webview never touches the video data.
This has cascading benefits: no video data crosses the JS-to-backend bridge, the webview stays minimal, and ScreenCaptureKit handles audio mixing and MP4 creation natively. We included FFmpeg for feature parity with the other apps, but a Tauri app that only needs MP4 output could come in under 15 MB.
Startup time
Median of 10 measured launches, from command to first window:
| Framework | Startup time |
|---|---|
| Deno Desktop | 242 ms |
| Electron | 273 ms |
| Tauri | 311 ms |
| Electrobun | 773 ms |
Deno Desktop leading here was unexpected. Tauri being slower than Electron was also a surprise: despite a fast Rust backend, the application still waits for the OS webview to initialize, which adds latency. Electrobun's 773 ms results from a multi-step startup chain: a native launcher starts the Bun runtime, which starts the bundled Chromium runtime. That sequential initialization is the bottleneck.
Memory usage at idle
| Framework | Memory at idle |
|---|---|
| Deno Desktop | 98 MB |
| Tauri | 109 MB |
| Electron | 128 MB |
| Electrobun | 208 MB |
Deno and Tauri both use less memory than Electron at rest. Electrobun's higher figure again reflects the bundled Chromium instance.
One note on measuring Tauri: the process monitor shows a deceptively small main process (~36 MB) because the OS spawns separate helper processes for networking, graphics, and media when using the system webview. The 109 MB figure above is the sum of the main process and all associated webview processes.
Runtime performance during recording
During actual screen recording, Tauri was noticeably more stable and responsive, particularly at higher resolutions. In the JavaScript-based frameworks, video frames are captured in the renderer process and must be continuously streamed across a bridge to the backend for saving. At high frame rates, that bridge becomes a bottleneck. Tauri doesn't have this problem because recording happens entirely at the OS level with no bridge involved.
Developer experience
Electron provides the most mature experience. APIs are stable, documentation is exhaustive, the community is large, and you're unlikely to hit unexplained behavior in normal usage.
Tauri was surprisingly smooth despite requiring a Rust toolchain. The documentation is good, the CLI handles project scaffolding and builds cleanly, and the separation between the Rust backend and the webview frontend is logical. The main adjustment is writing backend logic in Rust rather than Node.js.
Deno Desktop showed real promise but we hit a repeatable bug: starting a recording and then hiding the application window caused an immediate crash. The apparent cause is that Deno's runtime exits when no windows are visible. The workaround was to move the window off-screen (to coordinates like -10000, -10000) rather than hiding it. That kind of necessary hack is a sign of a platform that's still finding its edges. Deno Desktop shipped as part of Deno 2.9.0 in June 2026 and is still early.
Electrobun was the most difficult to work with. Beyond the Chromium bundling issue, inspecting the project's dependencies revealed it pulling in Three.js and Babylon.js, neither of which our application used. Those unnecessary dependencies contribute to the bundle size and raise questions about what the framework is actually doing internally.
Summary
| Bundle size | Startup | Memory | DX | |
|---|---|---|---|---|
| Tauri | 57 MB | 311 ms | 109 MB | ✔ Smooth |
| Deno Desktop | 111 MB | ✔ 242 ms | ✔ 98 MB | Promising, some bugs |
| Electron | 323 MB | 273 ms | 128 MB | ✔ Most mature |
| Electrobun | ✘ 418 MB | ✘ 773 ms | ✘ 208 MB | Difficult |
Tauri wins on bundle size and runtime performance, and offers a good development experience if you're willing to write some Rust. For applications that need deep OS integration or high-fidelity performance-sensitive tasks, it's the strongest option in the current field.
Electron is still the safest choice if your team wants the most mature, predictable platform and a pure TypeScript/JavaScript development experience. The efficiency tradeoffs are real, but the ecosystem depth and stability are genuine advantages.
Deno Desktop has the fastest startup and lowest memory usage, and the framework auto-detection feature (which supports Next.js, Astro, SvelteKit, and others with no code changes) is genuinely useful. It's worth watching closely as it matures, but it's not ready for complex production applications yet.
Electrobun underperformed on every metric in this test. It may be a better fit for applications that don't require screen recording or other APIs that the system webview doesn't support, but its current state makes it difficult to recommend for a demanding real-world project.