:: electron host · 01

:: tauri host · 02

:: deno-desktop host · 03

Blog · updated 7 Sep 2026 · Electron vs Tauri vs Deno · ES

Three engines, the same contract: why Línea boots on Electron

By Edu Peralta, building Línea.

I wanted a project where I could actually apply what I learned at university and what I've seen in production projects that make good use of DIP and IoC. The first example that comes to mind is VSCode: if we clone the repo and dig through the code we'll find object orientation used well, real IoC, modules that can be swapped, and no end of patterns they've used across more than 10 years of development. That's let them evolve whole modules safely. What they still haven't changed is the desktop engine, Electron.

That kept turning over in my head. If the logic is already decoupled, why not the runtime? The likely answer is cost: migrating modules that already work doesn't pay off. When I started Línea I didn't want to inherit that debt. The goal wasn't "pick the fashionable framework". It was to be able to swap the engine and measure: Deno, Tauri, or Electron. Which one holds up three terminals at once, with Git, worktree, and a React UI?

The contract, not the framework

I defined IRuntime to decouple the app, so it would talk to an interface and each engine would implement the same contract its own way. Implementation examples:

• file search
• repo status and worktree review
• cwd sync
• PTY, processes, filesystem, IPC

Each adapter does it in its world:

• Tauri: native Rust
• Electron: Node background process
• Deno Desktop: TypeScript on Deno's APIs

                    ┌─────────────────────┐
                    │     App / UI        │
                    │   (React + WebGPU)  │
                    └──────────┬──────────┘
                               │
                               │  IRuntime
                               │  findFiles()
                               │  repoStatus()
                               │  syncCwd()
                               │  ...
                               ▼
                    ┌─────────────────────┐
                    │   RuntimeContract   │
                    └──────────┬──────────┘
            ┌──────────────────┼──────────────────┐
            ▼                  ▼                  ▼
   ┌────────────────┐ ┌────────────────┐ ┌────────────────┐
   │ ElectronAdapter│ │  TauriAdapter  │ │  DenoAdapter   │
   │ Node + node-pty│ │ Rust + webview │ │ Deno APIs + TS │
   └────────────────┘ └────────────────┘ └────────────────┘

I know this sounds very academic, not very usable, and I've often seen design patterns that never actually get applied, but in this case, if you apply them well, it works.

Results (with three terminals open)

Tauri arrives with a reputation for being the fastest and lightest: less weight, faster boot, less memory. For packaging and startup, yes, but in this particular benchmark it doesn't come out ahead.

Same UI (React + WebGPU), same load: three terminals.

I'll start with Deno, which, remember, is in an experimental state, but I still wanted to implement it to see the performance. As you can see it's clearly the one that uses the most memory, and it still has a long way to improve. I have hope for the team around Node's creator; I think they're doing good work.

The surprise is Tauri: in this scenario it gets close to Electron on memory because of WebGPU. Without that renderer I suspect Tauri's numbers would have been kinder. On execution speed, Tauri wins: Rust is underneath, and you can tell.

Developing with Tauri (what isn't in the README)

Using the system webview is an excellent idea, because the installer gets much smaller. The price is three real engines, not one.

1. Three implementations, three failures. The one that's hit me most is WebKit + WebGL/WebGPU on the terminals: after running for a while the glitches start. This isn't "a bug in my code and that's that". It's WebKit's engine.
2. The Rust compiler. In a development session it goes to ~5 GB. That's not a small detail if you compile often.
3. Two (or three) languages. Having everything in one —TypeScript end to end— saves context, tooling, and headaches that don't show up in a 10-minute benchmark.

Compared with Electron, which is Chromium, we have a predictable system and a single place to look for the fault.

Choice

The version you install today is Electron. Even though it weighs more and uses a bit more memory, in exchange we get:

• A single engine (Chromium)
• Sessions of days without WebGPU falling over

It isn't the cool answer. It's the one that survives the use Línea asks for: several agents, several panes, the repo in view, without restarting in the middle of the afternoon.

The IRuntime contract is still there. If Deno matures or Tauri stabilizes WebKit on long terminal sessions, the change isn't rewriting the app. It's one more adapter.

Línea is free for macOS, Windows, and Linux. No account, no card.