Let's Be Real About "Desktop Apps"

I've shipped three desktop applications this year. A Markdown editor, a clinic inventory system, and a code translation tool. All three use React on the frontend. All three open in a window you double-click from your desktop. And all three are, at their core, just web pages running inside a native shell.

Say that out loud in some circles and you'll get lectures about "real native development." But here's the thing: I'm a web developer. HTML, CSS, TypeScript, React, that's what I'm fast with. I'm not going to learn Qt or SwiftUI just to ship a tool that renders markdown or tracks medicine inventory. I'd rather spend my time on the actual product than fighting a foreign UI framework.

So yes, my desktop apps are websites with extra steps. And after building three of them: two with Electron, one with Tauri 2.0, I have some opinions. Not expert opinions. Just honest ones from someone who's been in the trenches.

The Two Paths

If you're a web developer who wants to ship a desktop app, you've basically got two choices: Electron (Chromium + Node.js, the veteran) and Tauri (the OS-native WebView + Rust, the newcomer). Both let you write your UI in React/Vue/Svelte. Both give you filesystem access, native dialogs, and system tray integration. The difference is what's under the hood, and how much pain you're willing to trade for what benefit.

I've now used both. Here's what actually happened.

graph TB
    subgraph Tauri ["Tauri 2.0 Architecture"]
        direction TB
        React1["React Frontend (UI)"]
        WV["OS Native WebView (Edge / WebKit)"]
        Rust["Rust Core (Backend)"]
        OS1["Operating System"]
        React1 -->|Renders UI| WV
        React1 -->|IPC Invoke| Rust
        Rust -->|Native System APIs| OS1
    end
    subgraph Electron ["Electron Architecture"]
        direction TB
        React2["React Frontend (UI)"]
        Chromium["Bundled Chromium Engine"]
        NodeJS["Bundled Node.js Runtime"]
        OS2["Operating System"]
        React2 -->|Renders UI| Chromium
        React2 -->|IPC Bridge| NodeJS
        NodeJS -->|File System & C++ Modules| OS2
    end
    User(["User Binary Package"]) -.->|~10 MB Installer| Tauri
    User -.->|~120 MB Installer| Electron

Linen: The Tauri Experiment

Linen is a Markdown editor I built because Notepad++ wasn't cutting it. I wanted something lightweight: no Electron, no 200MB install, no plugin marketplace. Just a text editor that renders Mermaid diagrams and KaTeX math in real time.

Tauri 2.0 was the obvious choice. The pitch is compelling: your app ships as a sub-10MB binary because it uses the operating system's built-in WebView instead of bundling an entire Chromium browser. The backend is Rust, which means fast startup, tiny memory footprint, and no JavaScript on the main thread.

And it works. Linen's binary is under 10MB and cold-starts in under a second. That's genuinely impressive for a feature-rich editor with syntax highlighting across 15+ languages, WYSIWYG toggle via Tiptap, and real-time split preview.

But you pay for that lightness in other ways. Tauri doesn't have a built-in splashscreen API like Electron does, so I had to wire it up manually: Tauri opens a transparent splashscreen window at startup, React hydrates in the background, and once the main window is ready, the frontend calls a Rust command that closes the splashscreen and reveals the real window.

#[tauri::command]
async fn close_splashscreen(window: tauri::Window) {
  // Close splashscreen
  if let Some(splashscreen) = window.get_webview_window("splashscreen") {
    let _ = splashscreen.close();
  }
  // Show main window
  if let Some(main) = window.get_webview_window("main") {
    let _ = main.maximize();
    let _ = main.show();
    let _ = main.set_focus();
  }
}

It's only about 30 lines total, but it's the kind of thing Electron gives you for free. Drag-and-drop file handling was another one, I had to wire up Tauri's drag-drop events manually and handle edge cases like duplicate drops and non-markdown files. The bidirectional scroll sync between CodeMirror and the preview pane was also surprisingly tricky, especially in WYSIWYG mode where content length changes unpredictably.

But the binary size and startup speed make it worth it. If your app doesn't need native C++ modules or deep Node.js integration, Tauri is honestly the better default in 2025.

Simakes Bungo: Electron for a Real Client

Simakes Bungo is an inventory management system for a police clinic in Jambi, Indonesia. Real client, real users, real consequences if it breaks. It tracks medicine batches with FIFO/FEFO expiry tracking, manages patient prescriptions, and exports Excel reports, all offline, backed by a single SQLite file.

This had to be Electron. A clinic with unreliable internet can't depend on a web app. It needs to work offline, double-click from the desktop, no loading spinners, no API errors. Electron gives you a local Node.js runtime with direct filesystem and database access, better-sqlite3 runs synchronous queries from the main process with zero async overhead.

The binary comes out around 100MB, which is about what you'd expect from Electron + Chromium. But nobody at the clinic cares about binary size. They care that the app opens instantly, transactions are atomic (one SQLite transaction inserts the prescription and deducts stock from the correct batch, rolling back if anything fails), and backup/restore is one click.

The SQLite migrations were painful though. You can't drop columns in SQLite, only add them, so I built a PRAGMA-based migration check that runs on every app startup to add missing columns without breaking existing installations. That's the kind of thing you only learn when you ship to actual users who can't just "npm install" a fresh version.

Sutura: Electron's Native Module Hell

Sutura is where Electron shows both its greatest strength and its most infuriating weakness. It's a code translation tool that parses 44 file types through Tree-sitter, extracts Chinese UI strings, sends them to an AI provider (Gemini, Claude, GPT, DeepSeek, or local LLMs), and surgically injects translations back at the byte level.

The native module stack is deep: tree-sitter with 28 language grammars, better-sqlite3 for translation state tracking, and nodejieba (a C++ Chinese tokenizer) for building terminology glossaries. All of these are native C++ addons compiled via node-gyp. All of them need to run inside Electron's bundled Node runtime, not your system Node.

This is where "electron-rebuild" enters the chat. And it's not a friendly entry. Every platform (Windows, macOS, Linux) needs its own compiled bindings. The Electron Node headers often differ from your system Node version. I ended up with a custom rebuild script that patches every Tree-sitter grammar's binding.gyp from C++14 to C++20 (required by newer Node/V8 headers) before rebuilding 28 separate native packages with node-gyp. The postinstall hook chains electron-builder's install-app-deps on top of that.

The binary balloons to about 120MB, Chromium, plus 28 compiled Tree-sitter grammars, plus the JS bundle, plus Monaco Editor. But here's the thing: you cannot build Sutura in Tauri. The whole architecture depends on running native C++ tree-sitter grammars in-process, doing the AST walking in the main thread, and communicating results to the renderer over IPC. Tauri's Rust backend is great, but it doesn't have the equivalent of node-gyp for dropping arbitrary C++ modules into your app.

The byte-offset injection logic was another hard-won lesson. When you're replacing Chinese text inside source files, multi-byte UTF-8 characters shift column positions, what Tree-sitter reports as column 10 might actually be byte 13 in the buffer. I built a search-window fallback that looks for the original text near the expected position, handling drift from CJK characters. One wrong splice and you're writing translated English into the middle of a Java method signature. Ask me how I know.

So Which One Should You Use?

Neither framework is "better." They're just different tradeoffs.

Feature / Metric	Tauri 2.0	Electron
Binary Size	Sub-10 MB (OS WebView)	100 – 120 MB (Chromium + Node.js)
Startup Speed	Near instant (< 1s)	Slightly slower (~1-3s Chromium init)
Native Module Support	Rust Crates & C FFI	Node.js C++ Addons via `node-gyp` (`better-sqlite3`, `tree-sitter`)
Build Complexity	Clean Cargo workflow, manual splashscreen/IPC	`electron-rebuild` & C++ header patch hell
Best Use Case	Lightweight utilities, text editors (Linen), note-taking	Enterprise offline apps (Simakes Bungo), heavy C++ node module tools (Sutura)

Use Tauri when you're building something that feels like it should be small, a text editor, a notes app, a system utility, a lightweight tool. The sub-10MB binary and sub-second cold start are genuinely delightful, and Rust's performance means you're not burning CPU on a background Node process. The tradeoff is that you'll build some things yourself that Electron gives you for free, like splashscreen handling and drag-and-drop support.

Use Electron when you need Node.js native modules. If your app depends on better-sqlite3, tree-sitter, nodejieba, or any C++ addon, Electron is the only game in town. The 100-120MB binary is the price of admission, but in most real-world scenarios, an offline clinic app, an internal enterprise tool, a developer utility, nobody is measuring your download size. The node-gyp rebuild hell is real, but once it's set up, it works.

What they both share is that you're writing the UI in the technologies you already know. React, Tailwind, Zustand, the same stack you'd use for a web app. The "desktop" part is an implementation detail. And for most of us, that's not just fine. It's the whole point.

Key Takeaways

Desktop apps from web devs are valid. The people who tell you to "learn real native development" aren't shipping your projects. Ship in the stack you know.
Tauri wins on binary size, hands down. Linen is under 10MB. My Electron apps are 100-120MB. That gap is the cost of bundling Chromium.
Electron wins when you need native Node.js modules. If your app depends on C++ addons compiled via node-gyp, Tauri can't help you. Electron's Node.js runtime is the entire reason to choose it.
Both frameworks have hidden costs. Tauri's is manual wiring (splashscreens, drag-and-drop, some IPC). Electron's is node-gyp rebuild hell and the binary size tax.
Stop overthinking it. Pick based on whether you need native C++ modules (Electron) or tiny binaries (Tauri). Everything else is optimization you can do later.

Your users don't care what's under the hood. They care that double-clicking the icon opens a working application. Both frameworks deliver that. Pick one and ship.

Desktop Apps Are Just Websites with Extra Steps (and That's Fine)