Split View: Tauri 2 — 정말로 Electron을 대체하는가, 아니면 다른 도구인가

Tauri 2 — Does It Actually Replace Electron, or Is It a Different Tool?

Prologue — Why we are talking about desktop frameworks again

"Electron is heavy" has been said so often it became a cliché. Boot Slack and 400MB of RAM is gone. VS Code climbs to 1GB. The Discord installer is 90MB. Every time, the same copy of Chromium occupies the user's disk and memory.

Alternatives have been proposed forever. Write native (double the headcount), Flutter desktop (still awkward), Qt (commercial license), and — Tauri.

Tauri 2.0 went GA in October 2024. In 2026, we are eighteen months past that release. The promises were strong: 10MB bundles, system webview, Rust core, iOS and Android support. On paper, it looked like Electron's replacement.

In practice? Slack is still Electron. VS Code is still Electron. Discord is still Electron. The big apps have reasons not to migrate. At the same time, fresh apps like SilentKeys, Voxly, Watson.ai, and Pake chose Tauri from day one. New projects and existing projects diverge.

This post walks the divide. The real architectural differences, measurable trade-offs (bundle size, memory, startup time), the shadow the system webview casts, how the security model works, the actual state of mobile support, and how to decide whether Tauri fits your team. Neither Electron nor Tauri is the right answer for everyone.

One-line take: Tauri is not "Electron made lighter." It is a different tool with different trade-offs. Know the trade-offs and the decision becomes easy.

1. Architecture — what is actually different

The core difference fits in one sentence: Tauri does not bundle Chromium. It uses the OS's system webview instead.

Anatomy of an Electron app
┌────────────────────────────────────────────────┐
│  Your app                                       │
│  ├─ Main process: Node.js runtime               │
│  ├─ Renderer process: Chromium (V8 + Blink)     │
│  └─ Electron binary (~80-120MB)                 │
│                                                │
│  → N copies of the same Chromium on the OS      │
└────────────────────────────────────────────────┘

Anatomy of a Tauri app
┌────────────────────────────────────────────────┐
│  Your app                                       │
│  ├─ Rust core (~3-5MB)                          │
│  ├─ System webview call:                        │
│  │    macOS  → WKWebView (Safari/WebKit)        │
│  │    Windows → WebView2 (Edge/Chromium)        │
│  │    Linux  → WebKitGTK                        │
│  └─ Web assets (HTML/JS/CSS)                    │
│                                                │
│  → Borrows the webview the OS already ships     │
└────────────────────────────────────────────────┘

Consequences of the difference:

• Bundle size: Electron 80-200MB, Tauri 2-40MB (typically 5-15MB)
• Memory: Electron 200-400MB at idle, Tauri 30-80MB at idle
• Startup time: Electron 1-3 seconds, Tauri 0.2-0.8 seconds
• Rendering consistency: Electron is identical everywhere; Tauri runs a different engine on each OS (this is the central trade-off)

Tauri's backend language is Rust. Backend code — filesystem, network, system APIs — is written in Rust. The frontend (React, Vue, Svelte, Solid, whatever) stays the same. The two talk over IPC. Conceptually identical to Electron's main/renderer split, except "main" is Rust instead of Node.

Summary: Electron ships a whole browser plus Node. Tauri borrows the OS's webview and compiles only the backend to Rust.

2. Bundle size and memory — the measurable difference

Enough abstraction. Numbers, from 2026 public benchmarks and migration reports.

Bundle size (.dmg / .msi / .AppImage)

Memory (idle)

Cold start time (M2 MacBook Pro)

What these numbers mean: bundle, memory, and startup really are different. One migration report cited 95% installer-size reduction and 70% lower memory. The wins are measurable.

But — the numbers don't decide everything. Read the next chapter.

3. The system-webview shadow — "write once, run anywhere" is a lie

Tauri's biggest weakness comes from its biggest strength. System webview makes it light; system webview also means rendering differs by OS.

The same React code, executed on:
  macOS    → WKWebView (Safari)    — inherits Safari bugs and gaps
  Windows  → WebView2 (Edge/Chromium) — most compatible since it is Chromium
  Linux    → WebKitGTK             — most behind; some modern CSS/JS APIs missing

What this means in practice:

• backdrop-filter: fine on macOS/Windows, partial on WebKitGTK
• :has() selector: in 2026 still varies by WebKitGTK version
• OffscreenCanvas: macOS/Windows ok, Linux case-by-case
• WebRTC, MediaRecorder: codecs and behavior differ per platform
• Font rendering: macOS antialiasing looks different from Windows/Linux
• Drag-and-drop, Clipboard API: each webview's quirks show through

Electron does not have this problem by definition. Everywhere you run it, the same Chromium produces the same pixels. Expensive, but you buy consistency.

Real Tauri code learns to look like this:

/* Assume a WebKitGTK fallback on Linux */
.frosted {
  background: rgba(255, 255, 255, 0.85);
}

@supports (backdrop-filter: blur(10px)) {
  .frosted {
    background: rgba(255, 255, 255, 0.5);
    backdrop-filter: blur(10px);
  }
}

If your Linux share is tiny, ignore it. But if you build developer tooling, Linux can be 30-40% of users. Then every new CSS/JS feature needs a fallback. "Works in Chromium, ship it" is no longer enough.

Summary: Tauri is not "write once, run anywhere." It is "write once, test on three OSes." The QA bill is higher than Electron's.

4. The security model — from allowlist to capabilities

A major change in Tauri 2 is the security model. The v1 allowlist was a flat on/off toggle: "enable the fs API or not." It hit its limits, so v2 was redesigned around three concepts: permissions, scopes, capabilities.

Three concepts

• Permissions: on/off toggles for Tauri commands (e.g., fs:allow-read-file)
• Scopes: parameter validation for commands (e.g., "only these path patterns")
• Capabilities: bundles of permissions and scopes attached to specific windows/webviews

You declare them in JSON or TOML. Files dropped into src-tauri/capabilities/ are enabled automatically.

{
  "$schema": "../gen/schemas/desktop-schema.json",
  "identifier": "main-capability",
  "description": "Permissions granted to the main window",
  "windows": ["main"],
  "permissions": [
    "core:default",
    "fs:allow-read-text-file",
    "fs:allow-write-text-file",
    {
      "identifier": "fs:scope",
      "allow": [
        { "path": "$APPDATA/notes/*" },
        { "path": "$DOCUMENT/MyApp/**" }
      ],
      "deny": [
        { "path": "$HOME/.ssh/*" }
      ]
    },
    "shell:allow-open"
  ]
}

What this configuration means:

• Only the main window receives these permissions (other windows need their own capability)
• Filesystem read/write is enabled — but only under $APPDATA/notes/ and $DOCUMENT/MyApp/
• $HOME/.ssh/* is explicitly denied
• shell:open is allowed (for opening email and URLs)

Electron has no equivalent declarative model. Security in Electron is a code pattern — contextIsolation: true, nodeIntegration: false, preload scripts, a hand-maintained IPC whitelist. Forget any one of them and you ship an RCE.

Why the Tauri model is safer:

1. Declarative: permissions are config, not code — easy to audit
2. Granular: not "filesystem on or off" but specific paths
3. Default deny: a command without a capability gets a hard "no"
4. Per-window: a main window and an about window can have separate permissions

Electron can match this if you're careful. The difference is — in Tauri it is the default, in Electron it is extra work.

Summary: capabilities force "safe IPC by default." A pattern that becomes RCE in Electron if forgotten just gets rejected in Tauri if no capability is declared.

5. The IPC contract — one command, end to end

Enough abstraction. Walk a real IPC command end to end. Scenario: clicking "Save Note" in the frontend triggers a Rust backend that writes to disk.

Rust side: command definition

src-tauri/src/commands.rs:

use serde::{Deserialize, Serialize};
use std::path::PathBuf;
use tauri::AppHandle;
use tauri_plugin_fs::FsExt;

#[derive(Debug, Serialize, Deserialize)]
pub struct Note {
    pub id: String,
    pub title: String,
    pub body: String,
}

#[derive(Debug, Serialize)]
pub struct SaveResult {
    pub bytes_written: usize,
    pub path: String,
}

#[tauri::command]
pub async fn save_note(
    app: AppHandle,
    note: Note,
) -> Result<SaveResult, String> {
    // 1) Validate input — the IPC boundary is untrusted
    if note.id.is_empty() || note.id.contains('/') || note.id.contains('\\') {
        return Err("invalid note id".into());
    }
    if note.body.len() > 10 * 1024 * 1024 {
        return Err("note too large (>10MB)".into());
    }

    // 2) Only work inside the paths a capability allows
    let app_data = app
        .path()
        .app_data_dir()
        .map_err(|e| format!("no app data dir: {e}"))?;
    let mut path: PathBuf = app_data.join("notes");
    std::fs::create_dir_all(&path).map_err(|e| e.to_string())?;
    path.push(format!("{}.json", note.id));

    // 3) Serialize and write
    let body = serde_json::to_vec_pretty(&note).map_err(|e| e.to_string())?;
    let bytes = body.len();
    std::fs::write(&path, body).map_err(|e| e.to_string())?;

    Ok(SaveResult {
        bytes_written: bytes,
        path: path.display().to_string(),
    })
}

src-tauri/src/lib.rs:

pub fn run() {
    tauri::Builder::default()
        .plugin(tauri_plugin_fs::init())
        .invoke_handler(tauri::generate_handler![
            commands::save_note,
        ])
        .run(tauri::generate_context!())
        .expect("tauri failed to start");
}

TypeScript side: the call

src/lib/notes.ts:

import { invoke } from '@tauri-apps/api/core'

export interface Note {
  id: string
  title: string
  body: string
}

export interface SaveResult {
  bytesWritten: number
  path: string
}

export async function saveNote(note: Note): Promise<SaveResult> {
  // invoke maps 1:1 to a Rust #[tauri::command] by name.
  // Serialization is automatic (serde <-> JSON).
  // Watch out for snake_case vs camelCase mapping rules.
  const raw = await invoke<{ bytes_written: number; path: string }>('save_note', {
    note,
  })
  return { bytesWritten: raw.bytes_written, path: raw.path }
}

In a React component:

import { useState } from 'react'
import { saveNote } from './lib/notes'

export function NoteEditor() {
  const [title, setTitle] = useState('')
  const [body, setBody] = useState('')
  const [status, setStatus] = useState<string | null>(null)

  async function onSave() {
    try {
      const result = await saveNote({
        id: crypto.randomUUID(),
        title,
        body,
      })
      setStatus(`Saved: ${result.path} (${result.bytesWritten} bytes)`)
    } catch (e) {
      setStatus(`Failed: ${String(e)}`)
    }
  }

  return (
    <div>
      <input value={title} onChange={(e) => setTitle(e.target.value)} />
      <textarea value={body} onChange={(e) => setBody(e.target.value)} />
      <button onClick={onSave}>Save</button>
      {status && <p>{status}</p>}
    </div>
  )
}

Why this is safe

1. Explicit capability — only windows whose capability includes save_note can call it
2. Rust input validation — slashes in the id are a directory-traversal attempt, size limits are explicit
3. Path confinement — work happens under app_data_dir() only; no user-controlled path injection
4. Type safety — the Rust compiler checks one side, invoke's generics check the other

Writing the same thing in Electron means assembling preload, contextBridge, IPC handlers, and explicit whitelists yourself. Roughly the same volume of code, but forgetting a piece becomes a security hole.

Summary: Tauri's IPC is enforced by Rust's type system and the capability system together. Security sits next to the code that does the work.

6. Mobile — the headline change in Tauri 2

Tauri 1 was desktop-only. The biggest banner on v2 was iOS and Android support. In 2026, the question is how far that has actually come.

What works

• iOS and Android builds are stable (since the 2.0 GA)
• The same web frontend is shared between desktop and mobile
• Rust backend logic is callable from mobile too; native plugins can be written in Swift/Kotlin/Java
• Many of the core plugins (filesystem, notifications, dialogs) work on mobile

What is still rough

• Desktop plugin set is not equal to mobile plugin set. Some plugins are desktop-only, some are mobile-only
• The Tauri team itself acknowledges the "mobile as a first-class citizen" promise was overstated — they shipped the foundation and are iterating with the community
• iOS sideloading remains constrained by Apple policy; Android is comparatively open
• Tauri does not match Flutter or React Native on native-feeling mobile UX out of the box — being a webview, you still need to invest in mobile look-and-feel

When to choose Tauri mobile

Summary: Tauri mobile is excellent as "the mobile companion to a desktop app." It is not yet as mature as React Native or Flutter as the foundation for a mobile-first product.

7. Electron, Wails, Neutralino, native — the comparison matrix

Each tool in its place.

Each tool in one line

• Tauri 2: lightweight, secure desktop and mobile. Best if you are willing to learn Rust.
• Electron: largest ecosystem, consistent rendering. Pay the weight for fast development.
• Wails: the natural choice for Go teams. Brings Go's simplicity to desktop. Some features (multi-window etc.) still in progress.
• Neutralino: ultra-light. No compilation, Node-like APIs. Lightest, but the least mature.
• Native: one team per platform. Best UX, most expensive.

8. The Rust learning curve — the real cost for a frontend team

The biggest barrier to Tauri is not bundle size, nor the system webview. It is Rust. Honest accounting of the cost when a frontend-heavy team picks it up.

The good news

• Tauri is "frontend as usual + Rust only for the backend." For a simple app with thin backend, the Rust footprint is a few IPC commands and a main file
• The Tauri CLI generates ~90% of the boilerplate — cargo, cross-compile, code-signing wiring are largely abstracted
• AI tooling (Claude, ChatGPT) is good at generating Rust. Simple IPC commands are mostly autocompleted
• A thin backend rarely touches the hard parts of Rust — lifetimes, deep async, unsafe

The bad news

• The moment the backend grows — DB pools, async work, concurrency — the Rust curve gets steep
• Compile times. Initial build 5-15 minutes, incremental 5-30 seconds. Electron has instant reload
• Error messages are friendly but voluminous. A one-line JS error becomes 30 lines of trait-bound explanations in Rust
• If exactly one person on the team can review Rust, that person becomes the bottleneck
• Dependency auditing. cargo audit is fine, but the tooling surface is thinner than the npm world, and some crates lean heavily on unsafe

A practical decision rubric

A useful pattern: many teams compromise with the sidecar pattern. Keep Tauri's main app lean, spawn the heavy backend (e.g., Python ML, a Node service) as a separate process under Tauri's supervision. This minimizes the Rust learning cost while still capturing the bundle and memory wins.

Summary: Rust is a real cost for a frontend team. Bearable when the backend is simple. A different tool may be better when it isn't.

9. Apps actually built with Tauri 2

Notable Tauri 2 apps as of 2026. Names, categories, and a guess at why Tauri.

Patterns you can see:

1. New projects — built on Tauri from scratch, not ports from Electron
2. Small to medium scope — not gargantuan IDEs, but tools with a clear single purpose
3. System integration is central — tray icons, background work, global shortcuts, fine system permissions
4. Memory-sensitive — apps that run continuously in the background (dictation, meeting capture)
5. Developer or power-user audience — non-trivial Linux share

Conversely, why migrations from Electron are rare:

• The Electron codebase is a large existing asset — rewriting the backend in Rust is expensive
• Users are already happy — don't fix what isn't broken
• A low Linux share makes the system-webview gap easier to ignore

Summary: Tauri overwhelmingly wins as a deliberate choice in new projects. Migrations from existing Electron apps need a strong, specific motivation.

10. When to pick what — a decision tree

Start:
│
├─ Is mobile a primary target?
│   ├─ Yes → React Native / Flutter / native
│   └─ No → continue
│
├─ Is Linux a serious target?
│   ├─ Yes, 30%+ Linux users → can you absorb the system-webview gap?
│   │       ├─ Yes → Tauri / Wails
│   │       └─ No, pixel consistency required → Electron
│   └─ No or small → continue
│
├─ Does the team have Rust experience?
│   ├─ Yes or willing to learn → Tauri strongly recommended
│   ├─ Go experience instead → consider Wails
│   └─ JS only, no learning time → Electron
│
├─ Are bundle size and memory truly important?
│   ├─ Yes (background app, low-spec hardware) → Tauri
│   └─ No, users don't care → Electron ships faster
│
├─ Is the backend complex?
│   ├─ Yes — heavy DB, concurrency → Electron, or Tauri with sidecar
│   └─ No, mostly UI → Tauri or Neutralino
│
└─ Tight schedule (3-6 months)?
    ├─ Yes → Electron (everything is paved)
    └─ No, 12+ months → Tauri's learning cost amortizes

Short rules

• New project, simple backend, bundle matters → Tauri
• Existing Electron app, users happy → leave it
• AAA-class desktop UX with Linux as a first-class citizen → Electron
• Desktop + mobile code sharing matters → Tauri or Flutter
• Go team → Wails
• Need to claw back every megabyte → Neutralino (at the cost of maturity)
• Per-OS best UX, unlimited headcount → native

11. Anti-patterns and pitfalls

Patterns that lead to regretting the Tauri choice.

"Write it like Electron"

• Symptom: a single huge Rust file with every IPC command in one place
• Result: compile times explode, every change is expensive, tests are impossible
• Instead: split the Rust into modules (commands/, services/, models/). Keep commands thin (validate + delegate to a service).

"Turn on every capability"

• Symptom: core:default plus every fs/shell/dialog permission with wildcards
• Result: the core value of the security model evaporates. You inherit Electron's risk surface
• Instead: only what is truly needed, with narrow scopes. Per-window capabilities.

"Go deep on Rust async from day one"

• Symptom: simple IPC implemented with tokio::spawn and six channels
• Result: learning curve explodes, deadlocks, a swamp of compile errors
• Instead: start with async fn on Tauri's default runtime. Reach for deeper concurrency only when the problem demands it.

"Ignore the system-webview gap"

• Symptom: develop only on macOS, test on Linux right before release
• Result: half the UI breaks under WebKitGTK
• Instead: CI on three OSes from week one. Visual regression on every critical screen across all targets.

"Use Rust for the frontend too"

• Symptom: Leptos / Yew / Dioxus across the whole stack
• Result: the Rust curve doubles; the ecosystem is one-hundredth of React's
• Instead: stay on your usual framework (React/Vue/Svelte); Rust for the backend only. Tauri is designed for that split.

"Ask an AI agent to build the whole Tauri app"

• Symptom: an agent ships capability configs and IPC patterns that look right but leak permissions
• Result: too-wide permissions, missing input validation, side channels opening
• Instead: a human reviews every capability and IPC command. Tests at the IPC boundary are mandatory, not optional.

12. Migration — when moving from Electron to Tauri

If a migration is justified, here is the sequence.

1. Measure: record current Electron bundle, memory, startup
2. Backend inventory: list every Node dependency — what maps to a Rust crate?
3. Frontend pull-out: can the UI move unchanged (usually yes)?
4. IPC mapping: every ipcMain handler maps to a Tauri command
5. Capability design: list what each IPC touches → capabilities files
6. System integration: tray / notifications / shortcuts via Tauri plugins
7. Cross-OS testing: three-OS CI on day one, visual regression
8. Re-measure: verify the promised numbers actually appear
9. Beta users → gradual rollout

Signals not to migrate

• Many Node dependencies have no Rust equivalent (specific ML libraries, etc.)
• 70% of users on macOS, system-webview gap is moot, memory is fine
• Zero Rust-capable engineers, no six months to learn
• Users are happy, no complaints about bundle size

Signals to migrate

• A 24/7 background app whose memory is an actual user-machine burden
• Installer size affects download conversion (low-spec, low-bandwidth markets)
• A security audit is on the docket and cleaning up Electron's surface costs more
• A mobile expansion is on the roadmap and you want desktop code reuse

Epilogue — checklist, anti-patterns, what's next

Tauri 2 is not "Electron made lighter." It is a different tool with different trade-offs. Accept the system-webview shadow, the Rust curve, the smaller ecosystem — get back bundle, memory, and a stronger default security model. New project, thin backend, bundle matters — Tauri is the rational choice. Existing Electron apps need a real reason before any migration.

Checklist for choosing Tauri

1. Is this a new project or an existing migration? — new project amortizes the cost
2. How complex is the backend? — simpler favors Tauri
3. Mobile plans? — yes makes Tauri 2's mobile support attractive
4. Rust experience on the team? — zero means add learning time to the schedule
5. Linux user share? — high means budget for system-webview QA
6. Do bundle and memory truly matter? — background apps and low-spec hardware win here
7. Schedule pressure? — tight favors Electron; 12+ months favors Tauri
8. Designed capabilities early? — the security model shapes the code layout
9. Sidecar pattern needed? — heavy backends should run as a separate process
10. Three-OS CI from week one? — discovering the gap at release is too late

Anti-patterns

What's next

Next: "Pitfalls of Rust async — async/await, tokio, Send bounds, and where lifetimes meet futures." If this post was about deciding whether to use Tauri, the next is about what you actually meet when the Tauri backend gets complex. Rust async is powerful but full of traps — Send/Sync trait bounds, the interaction between lifetimes and futures, channel choice (mpsc/oneshot/broadcast), select patterns, and how to call sync code from an async context. It applies to a Tauri backend, a backend microservice, anywhere Rust async is taken seriously.

References

• Tauri 2.0 Stable Release announcement
• Tauri official site
• Tauri architecture documentation
• Tauri security model overview
• Tauri Capabilities reference
• Tauri Permissions guide
• Tauri Mobile Alpha announcement
• Tauri GitHub repository
• Awesome Tauri — apps and plugins index
• Made with Tauri — showcase
• Electron official site
• Wails official site
• Wails vs Tauri discussion
• Neutralino.js official
• Tauri 1.3 — early allowlist context
• Roadmap to Tauri 2.0
• Tauri vs Electron — performance and trade-offs (Hopp)
• Tauri isolation pattern
• Evil Martians — Tauri sidecar pattern