為什麼 macOS 原生 App 比 Electron 更適合做檔案工具
macOS 原生 App(如 Tauri + Rust)比 Electron App 在啟動速度、記憶體佔用、電池效率、檔案 I/O 四個維度上有系統性優勢——這在處理大量檔案時的感受尤其明顯,因為這類工作本身就已經是 I/O 密集型操作。
本文不是在說 Electron 不好。它讓 VS Code、Slack、Figma 都能在三個平台上用同一份程式碼運作,這是了不起的成就。問題在於:檔案工具(folder compare、hex viewer、全文搜尋)有特定的效能訴求,Electron 的架構在這幾點上天生吃虧。
先看結論:Electron vs Native(Tauri + Rust)對照表
| 維度 |
Electron |
Tauri + Rust(如 Lode) |
對檔案工具的影響 |
| 渲染引擎 |
捆綁完整 Chromium |
系統 WebView(macOS=WKWebView) |
原生共用 OS 已載入的引擎 |
| 後端語言 |
Node.js(V8) |
Rust(原生機器碼) |
Rust 對 CPU 密集的解析、比對快得多 |
| 冷啟動 |
2–5 秒 |
< 1 秒 |
即開即用,工具型 App 體驗關鍵 |
| 記憶體起點 |
150–300 MB |
~100 MB(實測 idle ≈ 106 MB) |
多工具並開時差距放大到 GB 級 |
| 安裝體積 |
80–150 MB+ |
3–10 MB |
下載快、佔硬碟少 |
| 電池(MacBook) |
基準 +20–40% 耗電 |
接近系統原生 |
行動工作續航差異明顯 |
| 並行模型 |
單執行緒 event loop |
真多執行緒 + async I/O |
大目錄掃描時 UI 不卡 |
| 跨平台一致性 |
✅ 三平台幾乎一致 |
⚠️ 需各平台測試 WebView 差異 |
Electron 在此勝出 |
| npm/外掛生態 |
✅ 非常成熟 |
⚠️ 成長中 |
Electron 在此勝出 |
| 原生 UI 元件 |
同樣靠 Web 渲染 |
同樣靠 Web 渲染(後端才是 Rust) |
平手 |
下面逐項拆解每個維度背後的原因。
啟動速度
Electron 每次啟動都要載入一個完整的 Chromium 引擎(約 80–120 MB)和 Node.js runtime。即使 App 本身只有幾 MB,使用者等到可以操作通常要 2–5 秒。對「臨時想比個資料夾」「快速 hex 看一下檔頭」這種用完即關的工具,每次都等好幾秒是很傷體驗的——因為檔案工具的使用模式本來就是高頻、短時。
Tauri + Rust 的二進位檔只有幾 MB,使用系統 WebView(macOS 的 WKWebView)而不是捆綁 Chromium。WKWebView 的引擎在系統開機後就常駐記憶體、被 Safari 與其他 App 共用,App 啟動時不必再從零載入。Lode 冷啟動不到 1 秒,在 M1 Mac 上幾乎是即開即用。
記憶體佔用
典型 Electron App 的記憶體起點是 150–300 MB,這是 Chromium 的底線成本——它會為主行程、渲染行程、GPU 行程各開一份。
Lode 使用系統 WebView,idle 記憶體實測約 100 MB(M1 Max,主程序 + WebView,2026-06 量測)。在同時開著多個工具的開發環境中,這個差距會放大——每個 App 相對 Electron 省下 50–200 MB,8 個 App 累積起來就接近 1 GB。對檔案工具來說還有一個隱藏成本:比對大目錄時要在記憶體裡持有兩棵檔案樹,Electron 的 baseline 已經吃掉一大塊,留給實際工作的空間就更少。
Rex 的實際觀察:在 Mac Studio M1(32GB RAM)上,開著 Lode + Xcode + Docker + Chrome 沒什麼壓力;如果把 Lode 換成同功能的 Electron 版本,記憶體壓力明顯增加。32GB 夠多,但在 8GB / 16GB MacBook 上,記憶體就是真實的瓶頸——swap 一旦開始,整台機器的反應都會被拖慢。
電池效率
Chromium 的渲染引擎對 GPU 的使用方式並未針對 macOS 最佳化。Electron App 在 MacBook 上的耗電通常比同功能的原生 App 高出 20–40%(Mozilla 2020 的瀏覽器架構研究提供了引擎成本的類似量級,雖非針對 Electron)。原因包含背景輪詢、計時器喚醒、以及多行程架構讓 CPU 較難進入深層睡眠。
Tauri + Rust 後端使用 Rust 的非同步 runtime(Tokio),CPU 閒置時真的閒置,不做多餘的輪詢。WKWebView 是 macOS 原生優化的 WebView,GPU 路徑與 Safari 相同,能吃到 Apple 對自家瀏覽引擎的省電調校。對一整天帶著 MacBook 跑的工程師,這是續航上看得到的差別。
檔案 I/O:Rust 的本質優勢
這是最關鍵的一點。資料夾比對、全文搜尋、Hex 解析,這三種操作都是 I/O 密集 + CPU 密集的組合。
- Node.js(Electron 後端):JavaScript 的非同步是 event loop 模型,單執行緒。雖然檔案讀取本身可以非阻塞,但接下來對內容做的工作——逐行 diff、雜湊比對、語法解析——都跑在同一條 JS 執行緒上,CPU 密集操作容易讓 UI 卡頓。要繞過得開 worker thread 並做序列化傳遞,成本不低。
- Rust(Lode 後端):真正的多執行緒,
async/await 使用作業系統的原生 I/O multiplexing,CPU 密集操作可以放在獨立執行緒的執行緒池(如 Rayon)平行跑,UI 執行緒完全不阻塞。Rust 沒有 GC,不會在掃描到一半時忽然 stop-the-world 暫停。
具體差異:Lode 用 ripgrep(Rust 寫的全文搜尋工具)當搜尋引擎,ripgrep 在各種 benchmark 中都顯著快於 JavaScript 實現的搜尋——它結合了有限狀態自動機的正則引擎、記憶體映射檔案、以及多核心平行走訪目錄。對「在十萬個檔案裡找一個字串」這種需求,引擎層級的差異會直接反映在等待時間上。
安裝體積與散佈
容易被忽略但對工具型 App 很實際:Electron App 因為內嵌整個 Chromium,安裝檔通常 80–150 MB 起跳,更新時往往要重新下載一大包。Tauri App 的安裝檔常在 3–10 MB 之間,下載快、佔硬碟少、自動更新的增量也小。對「想推薦給同事裝來用」的小工具,下載門檻低本身就是優勢。
安全面也值得一提:Electron 內嵌的 Chromium 版本必須由 App 開發者自己跟進安全更新,一旦落後就把已知漏洞帶進使用者機器;Tauri 走系統 WebView,安全性更新跟著 macOS 系統更新走,攻擊面相對小。
那 Tauri 的限制是什麼?
公平評比也要說缺點:
- 跨平台 UI 一致性:WKWebView(macOS)、WebView2(Windows)、WebKitGTK(Linux)在邊緣行為上有差異,CSS、字型 rendering、甚至某些 JS API 都要做平台測試。Electron 因為三平台都是同一份 Chromium,這點輕鬆很多。
- 原生 UI 元件:想用 NSOutlineView 這種 macOS 原生 tree control 不容易,Tauri 通常還是靠 Web 技術渲染 UI。Lode 就是這樣——UI 是 React + CSS,只有後端是 Rust,所以「原生感」其實來自設計與效能,不是用了 AppKit 元件。
- 生態系:Electron 的 npm 生態成熟很多,遇到問題在 Stack Overflow 上幾乎都有人踩過;Tauri 的 plugin 系統還在成長中,有些功能要自己寫 Rust binding。
- 學習曲線:團隊要同時懂前端與 Rust,對純前端背景的開發者門檻較高。
何時該選 Electron
不要因為這篇就一律排斥 Electron。如果你的 App 核心不是 I/O 密集、團隊只有前端背景、而且跨平台像素級一致比啟動速度更重要——例如即時通訊、文件協作、設計工具——Electron 仍然是非常理性的選擇,開發速度的優勢往往蓋過效能上的代價。Slack、Notion、Figma 走 Electron/Web 路線都站得住腳。
關鍵在於 App 的瓶頸在哪。當瓶頸是網路與協作,Electron 的弱項(記憶體、啟動)不痛;當瓶頸是本機檔案的讀取與運算,原生路線的優勢就會被使用者天天感受到。
結論
如果你在開發一個 檔案工具——比對、搜尋、hex 檢視、diff——Rust + Tauri 的組合在效能和資源效率上有明確優勢,而且代價(跨平台一致性的額外測試)對 macOS-first 工具來說幾乎可以忽略。
Electron 的優勢在於開發速度和跨平台一致性,對於工具本身不是 I/O 密集型的 App(Slack、Notion 等)完全合理。選型沒有絕對答案,只有「你的 App 瓶頸在哪」這個問題的答案。
Native macOS apps (Tauri + Rust) have a systematic advantage over Electron apps in startup speed, memory usage, battery efficiency, and file I/O — and this gap is felt most sharply in file tools, where the work itself is already I/O-intensive.
This isn’t an attack on Electron. It enabled VS Code, Slack, and Figma to ship one codebase across three platforms — a genuine achievement. The issue is that file tools (folder compare, hex viewer, full-text search) have specific performance demands where Electron’s architecture is structurally disadvantaged.
The Bottom Line First: Electron vs Native (Tauri + Rust)
| Dimension |
Electron |
Tauri + Rust (e.g. Lode) |
Impact on file tools |
| Rendering engine |
Bundled full Chromium |
System WebView (WKWebView on macOS) |
Native reuses the engine the OS already loaded |
| Backend language |
Node.js (V8) |
Rust (native machine code) |
Rust is far faster at CPU-heavy parsing/comparison |
| Cold start |
2–5 s |
< 1 s |
Instant-on matters most for utility apps |
| Memory baseline |
150–300 MB |
~100 MB (measured idle ≈ 106 MB) |
Gap compounds to GBs across many tools |
| Install size |
80–150 MB+ |
3–10 MB |
Faster download, less disk |
| Battery (MacBook) |
Baseline +20–40% drain |
Near-native |
Noticeable for mobile work |
| Concurrency model |
Single-threaded event loop |
True multi-threading + async I/O |
UI stays responsive on big scans |
| Cross-platform parity |
✅ Near-identical on 3 OSes |
⚠️ Needs per-platform WebView testing |
Electron wins here |
| npm / plugin ecosystem |
✅ Very mature |
⚠️ Growing |
Electron wins here |
| Native UI controls |
Web-rendered |
Web-rendered (Rust is the backend) |
Tie |
The rest of this article unpacks the reasoning behind each row.
Startup Speed
Every Electron app loads a full Chromium engine (~80–120 MB) and a Node.js runtime on launch. Even if the app itself is only a few MB, users typically wait 2–5 seconds before it’s usable. For a “quickly compare two folders” or “peek at a file header in hex” tool you open and close constantly, waiting several seconds each time is painful — file tools are inherently high-frequency, short-duration.
Tauri + Rust binaries are a few MB and use the system WebView (WKWebView on macOS) instead of bundling Chromium. That engine is already resident after boot and shared with Safari and other apps, so launch doesn’t reload it from scratch. Lode cold-starts in under 1 second on Apple Silicon — essentially instant.
Memory Usage
A typical Electron app starts at 150–300 MB — Chromium’s baseline cost, spread across a main process, renderer process, and GPU process.
Lode uses the system WebView, with measured idle memory around 100 MB (M1 Max, main process + WebView, measured June 2026). In a developer environment running multiple tools simultaneously, this gap compounds: each app saves 50–200 MB versus Electron, approaching 1 GB across 8 apps. File tools carry a hidden cost too: comparing large directories means holding two file trees in memory, and Electron’s baseline has already eaten a big chunk before the real work begins.
Rex’s observation: On Mac Studio M1 (32GB RAM), running Lode + Xcode + Docker + Chrome is comfortable. Swap Lode for an equivalent Electron tool and memory pressure increases noticeably. On an 8GB or 16GB MacBook, this is a real constraint — once swap kicks in, the whole machine slows down.
Battery Efficiency
Chromium’s rendering engine isn’t optimized for macOS power management. Electron apps on MacBook typically consume 20–40% more power than equivalent native apps, due to background polling, timer wakeups, and a multi-process architecture that makes deep CPU sleep harder.
Tauri uses Rust’s async runtime (Tokio) — the CPU genuinely idles when it should. WKWebView uses the same GPU path as Safari, benefiting from Apple’s power tuning for its own engine. For an engineer carrying a MacBook all day, that’s a visible difference in runtime.
File I/O: Rust’s Core Advantage
This is the crux. Folder comparison, full-text search, and hex parsing are all I/O-intensive and CPU-intensive.
- Node.js (Electron backend): JavaScript’s async is a single-threaded event loop. File reads can be non-blocking, but the work that follows — line-by-line diff, hash comparison, syntax parsing — runs on the same JS thread, so CPU-heavy operations stall the UI. Working around it means worker threads and serialization overhead.
- Rust (Lode backend): True multi-threading.
async/await uses the OS’s native I/O multiplexing, and CPU-heavy work can run in parallel on a thread pool (e.g. Rayon) without ever blocking the UI thread. With no GC, there’s no stop-the-world pause mid-scan.
Concretely: Lode uses ripgrep (a Rust search tool) as its search engine — consistently fastest in cross-tool benchmarks thanks to a finite-automaton regex engine, memory-mapped files, and multi-core directory traversal. For “find one string across 100,000 files,” that engine-level difference shows up directly as wait time.
Install Size and Distribution
Easy to overlook but very real for utility apps: because Electron embeds all of Chromium, installers usually start at 80–150 MB and often re-download the whole bundle on update. Tauri installers are typically 3–10 MB — fast to download, small on disk, small incremental updates. For a tool you’d recommend a colleague install, a low download barrier is itself an advantage.
Security is worth a mention too: Electron’s embedded Chromium must be security-patched by the app developer, and falling behind ships known vulnerabilities to users. Tauri rides the system WebView, so security updates arrive with macOS itself, and the attack surface is smaller.
Tauri’s Limitations
A fair comparison includes the trade-offs:
- Cross-platform UI consistency: WKWebView (macOS), WebView2 (Windows), and WebKitGTK (Linux) have edge-case differences in CSS, font rendering, and some JS APIs that require per-platform testing. Electron, running one Chromium everywhere, makes this far easier.
- Native UI controls: Using NSOutlineView or other AppKit controls from Tauri requires bridging work. Lode’s UI is React + CSS; only the backend is Rust — so its “native feel” comes from design and performance, not from AppKit widgets.
- Ecosystem maturity: Electron’s npm ecosystem is far more mature; most problems already have a Stack Overflow answer. Tauri’s plugin system is still growing, and some features mean writing your own Rust bindings.
- Learning curve: A team needs both frontend and Rust skills, raising the bar for purely frontend developers.
When You Should Pick Electron
Don’t let this article turn you off Electron categorically. If your app isn’t I/O-bound at its core, your team is frontend-only, and pixel-perfect cross-platform parity matters more than startup speed — messaging, document collaboration, design tools — Electron is still a very rational choice, where development velocity outweighs the performance cost. Slack, Notion, and Figma all make sense on Electron/Web.
The deciding question is where your app’s bottleneck is. When it’s network and collaboration, Electron’s weak spots (memory, startup) don’t hurt. When it’s local file reading and computation, the native route’s advantages get felt every single day.
Conclusion
For a file tool — compare, search, hex view, diff — Rust + Tauri offers measurable performance and resource efficiency advantages. For a macOS-first app, the trade-off (extra cross-platform testing) is nearly irrelevant.
Electron’s strengths are development velocity and cross-platform consistency — completely rational for apps that aren’t I/O-intensive at their core (Slack, Notion, etc.). There’s no universal answer, only the answer to “where is your app’s bottleneck?”
🔨
本文介紹的工具:LodeThe tool featured in this article: Lode
原生 macOS 工作台,整合 Folder Diff、File Diff、Binary Diff、全文搜尋,一個 App 搞定。Native macOS workbench — Folder Diff, File Diff, Binary Diff, and full-text Search in one app.