跪拜 Guibai
← Back to the summary

Opencode Drops Tauri for Electron, Exposing the Desktop App Size Trap

Hello everyone, I'm Lao Liu

In 2024, Tauri was released to universal acclaim: "Electron killer," "installation package size reduced by 90%," "Rust performance boost." Tech bloggers everywhere (myself included) were talking about this new toy.

So what happened? In April 2026, the Opencode team published an article on dev.to with a very honest title:

Moving OpenCode Desktop to Electron https://dev.to/brendonovich/moving-opencode-desktop-to-electron-4hip

In other words: we tried it, and now we're switching back to Electron.

The official post gave three reasons:

1. WebKit rendering issues Tauri uses WebKit for rendering on macOS/Linux, which performs worse than Chromium and has inconsistent styling across platforms, leading to high maintenance costs.

2. CLI startup bottleneck The bundled CLI affected startup speed and occasionally failed on Windows, degrading the user experience.

3. Bun → Node migration The team planned to migrate from Bun to Node. Electron has a built-in Node process, making server-side code execution simpler and removing one layer of runtime dependency.

These three reasons all seem very specific, so what exactly is the difference between these two development frameworks?

Tauri vs Electron

I already published an article comparing Tauri back in 2024:

flutter, tauri, maui — which one do you favor?

But at that time, the comparison was more from a mobile perspective.

From a desktop perspective, Tauri and Electron are a very typical pair of competitors.

The relationship between them is very similar to that of RN and Flutter on mobile.

RN and Tauri both delegate the rendering part to the system; they only maintain the logical UI tree themselves. Therefore, their package sizes can be very small.

Flutter and Electron, on the other hand, bundle the rendering engine inside the application, so the installation package looks much larger.

This is also a selling point for many projects currently adopting Tauri as their tech stack, claiming their package size is a fraction of the competitor's, with faster startup and higher runtime efficiency.

But this is actually misleading. Software package size has no direct relationship with runtime speed.

Size does not equal performance

Let's break performance down into startup speed and runtime speed.

Startup speed

Tauri's minimum is 2-5MB, while Electron often reaches 50-150MB — a difference of over 20 times. Intuitively, loading 5MB into memory should be much faster than loading 100MB.

But today's computers mostly use SSDs (PCIe 3.0/4.0) with read speeds around 3500-7000 MB/s:

The limit of human visual reaction speed is about 100 milliseconds. This 26-millisecond difference is simply imperceptible. So the "smaller size = faster startup" selling point is basically invalid in the age of widespread SSDs.

Runtime speed

Tauri's UI part is still developed in TS; only the underlying logic can use Rust. This raises a question: which code should be handed to Rust?

The typical scenario is CPU-intensive computational tasks: large-scale log scanning, data encryption/decryption, compression/decompression. If your application has many such tasks, Tauri can indeed leverage its performance advantage.

But if your main job is displaying JSON data with a few dozen fields (whether from local sources or a server API), shoving that processing into Rust adds nothing but code complexity with no obvious benefit.

To put it bluntly, Tauri only has a performance advantage in specific scenarios.

Cross-platform consistency and compatibility

Where does the real reason for Opencode's migration lie? It's the issue many projects most easily overlook during tech selection: cross-platform consistency.

Two architecture diagrams make it clear.

Electron's architecture:

┌──────────────────────────────┐
│      Renderer Process        │  ← Runs Chromium, displays UI
│  (HTML + CSS + JS/TS)        │
└──────────┬───────────────────┘
           │ IPC (Inter-Process Communication)
           ▼
┌──────────────────────────────┐
│         Main Process         │  ← Runs Node.js, manages window lifecycle, system calls
│  (Node.js + Electron API)    │
└──────────────────────────────┘

Electron bundles both Chromium and Node.js into the installation package. The rendering process is completely independent of the operating system. What you see on macOS looks exactly the same on Windows and Linux.

Tauri's architecture:

┌──────────────────────────────┐
│     System Native WebView    │  ← macOS: WKWebView / Linux: WebKitGTK
│  (HTML + CSS + JS/TS)        │     Windows: WebView2 (Edge Chromium)
└──────────┬───────────────────┘
           │ IPC (Inter-Process Communication)
           ▼
┌──────────────────────────────┐
│        Tauri Core (Rust)     │  ← Window management, system calls, process management
│  (Rust + Tauri API)          │
└──────────────────────────────┘

To achieve a smaller package size, Tauri delegates rendering to the system's built-in WebView. The installation package is indeed much smaller, but the cost is: three platforms, three WebView implementations.

There are quite a few pitfalls here. I've seen many Tauri projects stumble over these:

This means you write one set of UI code and then need to test and tweak it separately on three platforms. For a small team or solo developer, this maintenance cost is substantial.

This is the pitfall Opencode experienced: "It tests fine on macOS, but the styles render differently on Windows, and animations drop frames on Linux." This is an inherent flaw of frameworks like Tauri that graft onto system rendering.

In contrast, while Electron's installation package is larger, Chromium's rendering consistency is the industry benchmark. Moreover, Chromium's optimization has been continuously improving over the years: the V8 engine gets faster, GPU acceleration becomes more mature, and memory management improves. What you trade for that larger size is deterministic behavior of one codebase across all platforms.

For desktop applications in the AI era, this is critical. What are the core functions of an AI programming tool? Chat interface, code highlighting, Markdown rendering, real-time streaming output. These things demand UI consistency far more than native performance. And the "endless compatibility bugs" brought by WebView fragmentation are precisely what drains development energy the most.

Summary: How to choose a client-side tech stack?

Ultimately, switching from Tauri back to Electron isn't because Tauri is bad, but because it didn't fit their project type.

I'll list a comparison table for you to match against your own situation:

Dimension Tauri Electron
Installation package size 2-5MB 50-150MB
Startup speed Faster by ~26ms (imperceptible) Slower by ~26ms (imperceptible)
UI consistency ❌ Depends on system WebView, three platforms, three behaviors ✅ Chromium rendering, consistent across all platforms
Native performance ✅ Rust side suitable for CPU-intensive tasks ❌ But most UI applications don't need it
Web API compatibility ❌ WebKit version fragmentation ✅ Consistent with Chrome
Ecosystem maturity Rapidly developing, some features incomplete ✅ Extremely mature, solutions for almost every scenario
Debugging tools Requires cross-language debugging (TS + Rust) ✅ One set of Chrome DevTools handles everything
AI tool friendliness Moderate (Rust AI ecosystem lags behind JS/TS) ✅ TypeScript + Node ecosystem, seamless integration with AI toolchain
Team requirements Needs frontend + Rust dual skills Pure frontend is sufficient

My advice

If your project centers on UI interaction (chat tools, editors, IDEs, admin panels, AI clients), choose Electron. Your size anxiety is worthless in the face of the user's SSD. What's truly valuable is: one codebase running on three platforms, seamless AI ecosystem integration, and community solutions readily at hand.

If your project genuinely focuses on CPU-intensive tasks (video processing tools, big data analysis clients, file format converters) and the UI is relatively simple, you can consider Tauri. Rust's advantage in compute-intensive scenarios is real, and Tauri's lightweight size makes more sense in such cases.

Coming back to myself, why have I always leaned toward Flutter and Electron? Because most of the projects I work on are UI-intensive: state management, interaction design, cross-platform consistency — these are what users actually perceive. Users won't praise you for saving 100MB of hard drive space, but they will curse you if a button doesn't work on Windows.

One final honest word:

For indie developers and small teams in the AI era, the time window is the scarcest resource. Opencode's migration tells us: rather than spending time wrestling with WebView fragmentation, put your energy into the product itself.

If you're building a desktop AI tool today, start directly with Electron. Don't agonize over those few dozen MB of package size. Your MVP's time-to-market matters more than anything else.

The one who reaches the finish line first isn't the one with the lightest burden, but the one who stumbles the least along the way.

🤝 If you've read this far and are interested in client-side or Flutter development, feel free to reach out to Lao Liu. Let's learn from each other.

🎁 DM me for a free copy of the "Flutter Development Handbook" I compiled, covering 90% of application development scenarios. It can serve as a knowledge map for learning Flutter.

💬 : laoliu_dev

📂 I've also organized my historical articles in a GitHub repository for easy reference.

🔗 https://github.com/lzt-code/blog