只要在 Hacker News 或 Reddit 上待得夠久，你遲早會看到同樣的批評：Electron 太臃腫、Electron 太耗記憶體，而且真正專業的桌面應用程式就應該採用原生技術。
這些批評並非毫無道理。Electron 應用程式通常有較高的基本資源占用，因為它們隨附 Chromium 和 Node.js。經過精心設計的原生應用程式可以使用更少的記憶體、啟動得更快，並與作業系統更深入地整合。
但這場爭論太過關注電腦，卻不夠關注開發軟體的公司。
對大多數使用者來說，應用程式背後的技術幾乎不重要。他們在意的是軟體能不能正常運作、操作是否流暢、錯誤是否有人修正，以及是否持續推出實用功能。因此，對軟體公司而言，技術堆疊最重要的特性之一，反而是很少出現在效能評測表上的事情：團隊能多快完成開發、推出產品、汲取經驗，並改善產品？
對許多現代桌面應用程式而言，Electron 在這方面格外出色。
稀缺的資源是工程時間
理想中的原生桌面軟體公司，有一支優秀的 macOS 團隊、另一支開發 Windows 應用程式的團隊，或許還有一支支援 Linux 的團隊。每個應用程式都針對所屬平台精心最佳化，每位工程師也都深入了解自己負責的作業系統。
多數公司沒有這種餘裕。
一個桌面產品可能只有五位工程師，也可能只有兩位。這些工程師不僅要開發功能、修正錯誤、改善效能，還要回應客戶、維護基礎設施、因應作業系統的變動，並持續推進產品。
原生開發讓這件事更加困難，因為 macOS、Windows 和 Linux 確實是截然不同的平台。它們有不同的 UI 框架、API、權限系統、生命週期行為、安裝程式、更新機制、通知系統、視窗管理、無障礙 API，以及多年累積的平台特有問題。
Electron 改變了這個局面。它將 Chromium、Node.js 和桌面 API 結合成橫跨 macOS、Windows 與 Linux 的共用應用程式模型。同一位 TypeScript 工程師往往就能從介面到應用程式邏輯，完整開發一項功能，並將它發布到所有桌面平台。真正需要時，仍然可以使用原生程式碼，但原生程式碼成了例外，而不是產品的基礎。Electron 自己也將這點列為核心優勢之一：用同一套 JavaScript 程式碼支援三大桌面平台。
這種差異會隨著時間不斷累積。如果每項重要功能都需要分別為 Mac 和 Windows 實作，公司就得反覆支付這筆「平台稅」：每項功能、每次重新設計、每個實驗、每次錯誤修正、每項無障礙改善，以及每次效能最佳化，都不例外。
使用 Electron，這些工作有很大一部分只需要做一次。
Electron 著重於加快迭代速度
產品很少因為第一次實作就完美無缺而變得出色。它們是透過不斷迭代才變得出色的。
團隊推出某個功能，客戶開始使用，團隊從中學習，再調整功能。更多人開始使用，另一個問題浮現，團隊於是再次改善。
從構想、實作、回饋到改進之間的循環越短，產品進步得就越快。
Electron 格外擅長縮短這個循環，因為它的基礎正是軟體公司早已廣泛使用的技術：JavaScript、TypeScript、HTML、CSS、React、Chromium、Node.js 和 npm。
這代表公司能共用的遠不只是原始碼。網頁與桌面產品之間，還能共用工程師、UI 元件、工具、函式庫、基礎設施、測試方法，以及組織累積的知識。
前端工程師不會因為公司需要支援 Windows 用戶端，就突然派不上用場。桌面工程師可以參與網頁應用程式的開發。全端 TypeScript 工程師則能隨著優先順序變動，在不同產品之間調度。
對中小型公司而言，這種彈性的價值可能遠高於省下 100 MB 的 RAM。
看看實際使用 Electron 的有哪些產品
Electron 有時被形容成一條捷徑，供不願意投資打造「正規」桌面應用程式的公司使用。然而，用它打造的產品，讓這種論點越來越難以成立。
Electron 專案本身列舉了 Slack、Discord、Signal、ChatGPT、Claude、Visual Studio Code、Notion、Docker、Loom 和 Canva 等產品。這些並不是簡單的小工具。其中許多都是全球功能最複雜、使用最廣泛的生產力應用程式。
Visual Studio Code 是一個特別值得參考的例子。Microsoft 幾乎可以使用任何想用的 Windows 技術來打造自家的旗艦程式碼編輯器，但 VS Code 在 Windows、macOS 和 Linux 上都使用 Electron。它包含終端機、偵錯、語言伺服器、Git 整合、遠端開發、筆記本、擴充功能，以及高度客製化的編輯器。
值得探討的問題，不是 Microsoft 能不能透過打造三個獨立的原生版本來節省記憶體。當然可以。
更好的問題是：如果每项主要能力都需要多套獨立實作，VS Code 是否還能演進得如此迅速、在各平台上維持如此一致的體驗，並發展出如此龐大的生態系？
ChatGPT 和 Claude 展現了不同做法的差異
ChatGPT 與 Claude 之間的對比也很有啟發性。
OpenAI 最初為 ChatGPT 打造了專用的原生 macOS 應用程式。相較之下，Anthropic 使用 Electron 開發 Claude Desktop，從一開始就具備跨平台共用的桌面應用程式基礎。
隨著產品擴展，這項差異變得更加重要。Claude Desktop 能持續將 MCP 整合、擴充功能及 Claude Code 等能力加入同一個跨平台應用程式。Anthropic 現在已在桌面使用體驗中直接支援 Claude Code，包括多個本機與遠端工作階段。
OpenAI 後來也將較新的跨平台桌面開發方向轉向 Electron，而 Electron 如今也把 ChatGPT 和 Claude 都列為知名的 Electron 應用程式。
如果宣稱單憑 Electron 就能解釋產品開發速度的差異，那就言過其實了。團隊規模、優先順序、產品策略和內部組織都很重要。但架構上的優勢很明確：共用的跨平台基礎，讓團隊更容易在各個作業系統上推出功能，而不必維護各自獨立的實作。
隨著桌面產品成長，這正是會變得越來越有價值的優勢。
Evernote 體會了維護獨立用戶端的代價
Evernote 是這個問題最鮮明的歷史案例之一。
多年來，Evernote 為 Mac、Windows、行動裝置和網頁維護不同的應用程式。隨著時間推移，這些產品逐漸累積了不同的行為、呈現差異、歷史遺留的設計假設，以及同步問題。
2020 年，Evernote 以共用程式碼為基礎，重新打造 Windows 和 Mac 應用程式。公司表示，新的基礎將讓應用程式更穩定、更快修正錯誤、更頻繁推出功能，並改善跨平台同步。
這次遷移並非毫無痛苦，有些長期使用者也不喜歡初期失去部分平台專屬功能。但比起遷移問題本身，Evernote 為何決定進行如此昂貴的重寫，更值得關注。
一旦產品具備豐富的編輯器功能、離線儲存、搜尋、附件、協作、工作、行事曆和複雜的同步機制，維護多套獨立實作就會變得越來越昂貴。錯誤的表現不同，畫面呈現不同，同步邏輯也會與不同的本機架構互相影響。每項重要的產品變更，都必須落實到多個用戶端。
共用架構不會讓難題消失，但能讓公司將更多問題一次解決。
Linux 可能是 Electron 最被低估的優勢
Linux 讓採用 Electron 的理由更加充分。
妥善支援 Linux 並不容易。與 macOS 或 Windows 不同，「Linux 桌面」不是一個受到嚴格統一控制的平台。開發者必須處理不同的發行版、套件格式、桌面環境、圖形堆疊、系統函式庫和顯示協定。
對許多軟體公司來說，理性的商業決策可能就是乾脆不支援 Linux。
Electron 改變了成本效益的計算。
由於 Electron 在 macOS、Windows 和 Linux 上提供共通的執行環境，加入 Linux 支援可能遠比維護一套獨立的原生 Linux 實作容易。這也是為什麼今天 Linux 使用者能使用許多主要桌面應用程式，而這些產品在過去可能根本不會推出官方 Linux 用戶端。
Visual Studio Code、Slack、Discord、Signal、1Password、Postman、Obsidian 和許多其他工具，都能支援 Linux，而不必維護一套完全獨立的 GTK 或 Qt 應用程式。
Electron 也替應用程式開發者承擔了許多 Linux 特有的複雜性。從 X11 轉向 Wayland 就是很好的例子。Electron 的維護者曾說明，Chromium 轉向 Wayland 的過程，實際上也帶著 Electron 應用程式一起完成轉換，減少了各應用程式團隊必須獨自處理的顯示堆疊工作。
如果沒有 Electron 這類框架，許多公司不會開發原生 Linux 用戶端。他們只會支援 macOS 和 Windows，讓 Linux 使用者只能使用瀏覽器分頁。
Electron 對商業 Linux 桌面軟體的貢獻，很可能比它得到的肯定還要多。
就連 Microsoft 也越來越常選擇網頁技術
要反駁「專業的 Windows 軟體應該一律使用原生 Windows UI 框架」這種觀點，Microsoft 或許就是最有力的反例。
Microsoft 掌控 Windows，也掌控 Win32、.NET、WinUI、WebView2，以及開發者賴以開發的大部分平台技術。如果完全原生的 Windows 開發永遠是顯而易見的答案，Microsoft 理應最有條件在所有地方都採用它。
但它並沒有這麼做。
Visual Studio Code 使用 Electron。即使 Microsoft 將 Electron 換成經過更完善最佳化的 WebView2 宿主，Teams 仍以 React、TypeScript 和 Chromium 為核心。新版 Windows Outlook 也大量依賴網頁技術，而且 Microsoft 明確表示，這種架構能提高敏捷性、加快功能交付，並創造更一致的體驗。
Teams 尤其值得參考。Microsoft 希望改善效能、降低資源消耗，因此改變了架構。但它並沒有把 UI 重寫成傳統的 Windows 原生應用程式。
它保留了網頁技術堆疊，並圍繞這個堆疊進行最佳化。
這個區別很重要。Microsoft 認為，即使要積極改善效能，React、TypeScript 和 Chromium 帶來的組織層面優勢，仍值得保留。
這裡還有另一個啟示。多年來，Microsoft 自己推出了多個世代的 Windows 應用程式技術：Win32、WPF、UWP、WinUI 等等。公司選擇「原生 Windows」，不一定就是選擇一個歷久不衰的平台。它往往是在押注某一代 Microsoft 偏好的框架。
有點諷刺的是，網頁平台反而成了目前較穩定的應用程式開發目標之一。
人才招募也是架構的一部分
框架選擇也決定了你能招募哪些人才。
JavaScript 和 TypeScript 開發者構成了業界最龐大的工程人才庫之一。使用 Electron 開發的公司可以從這個人才庫招募，而不必分別組建由資深 macOS、Windows 和 Linux 專家組成的團隊。
原生技術專家依然很有價值。專業的桌面產品仍然需要深入了解作業系統的工程師。但 Electron 改變了你需要多少這類專家。
你不必要求應用程式的大部分都由平台專家打造，而是可以維護相對少量的原生整合程式碼，讓大多數團隊成員專注於共用產品。
如果公司已經有網頁應用程式，這點就更重要。React 元件有時可以共用，TypeScript 函式庫可以重複使用，產品邏輯可以在網頁和桌面之間移植。工程師也能轉換團隊，而不必學習一個完全不同的生態系。
招募也會變得比較不脆弱。如果唯一深入了解原生 Windows 用戶端的工程師離職，要補上這份專業能力可能很困難。使用 Electron，程式碼中更大的一部分採用的是組織其他成員熟悉的技術。
因此，框架決定的不只是介面如何繪製，也會影響工程組織本身可以如何組成。
原生不會自動等於更好的軟體
開發者常常把「原生」幾乎當成「快速」的同義詞。
但它們並不相等。
原生 API 讓開發者有機會打造效率極高的應用程式。至於最終產品是否真的做到，取決於架構、團隊、預算，以及公司能負擔多少最佳化工作。
原生應用程式仍然可能緩慢、充滿錯誤、消耗大量記憶體、表現不一致，或缺乏妥善維護。
更重要的是，把有限的團隊分散到多套原生實作，代表每套實作能得到的工程工時都會減少。
想像一家公司有六位工程師可以投入桌面產品。一個選項是將他們分配到 Mac 和 Windows，或許就不支援 Linux。另一個選項則是讓幾乎全部六位工程師投入同一個共用的 Electron 應用程式，同時服務三個平台。
哪種做法能讓公司有更多工程量能來改善啟動時間、修正記憶體洩漏、打磨互動體驗、改善無障礙功能、減少當機，並回應使用者？
原生應用程式不見得會帶來更好的產品。
這形成了一個有趣的悖論：一個消耗稍多機器資源的框架，可能讓公司打造出最佳化程度更高的產品，因為它消耗的工程資源少得多。
Electron 提供可控的平台
Electron 還有另一項容易被忽略的優勢：它隨附的 Chromium 執行環境，就是應用程式開發與測試時使用的版本。
這排除了跨平台開發中的一項重大變數。
以作業系統網頁檢視元件為基礎的框架，可以產生體積較小的應用程式，但代價是同一套前端可能在 Windows 上使用 WebView2、在 macOS 上使用 WKWebView，在 Linux 上使用 WebKitGTK。這些引擎有不同的能力、錯誤、發布時程和呈現行為。
Electron 採取另一種取捨：將執行環境一起打包，讓它成為應用程式的一部分。
沒錯，這會占用磁碟空間。
但它也讓開發者在三個截然不同的作業系統上，擁有一致得多的開發目標。
一致性具有極大的工程價值。
Electron 不夠用時，你仍然可以使用原生技術
選擇 Electron 不代表放棄使用原生功能。
Electron 應用程式可以在必要時使用原生模組和平台專屬程式碼。這意味著，架構選擇其實不是：
100% 原生或 100% JavaScript。
對許多產品而言，更好的模式是：
應用程式大部分共用，只有作業系統確實需要的地方，才使用少量原生程式碼。
原生程式碼成為必要時的備援途徑，而不是整個產品的基礎。
對許多公司而言，這是更合理的工程投入分配方式。
使用者在乎的是產品，不是框架
有一小群技術知識豐富的使用者，會打開「活動監視器」，看到好幾個 Chromium 程序，就立刻抱怨某個應用程式使用 Electron。
大多數使用者不會這麼做。
他們不在乎 Slack 使用 Electron，不在乎 VS Code 是用網頁技術打造的，也不知道 Claude 使用什麼框架。他們在意的是軟體能不能幫助自己完成工作。
如果應用程式啟動得夠快、操作流暢、很少當機，而且能解決使用者的問題，那麼實作技術基本上就不會引起注意。
反過來也一樣。原生應用程式不會只因為用了 Swift 或 WinUI，就自動成為好產品。
軟體競爭發生在產品層面，而不是框架層面。
最佳化公司，而不只是二進位檔
Electron 確實有代價。它占用更多磁碟空間，基本記憶體占用通常也高於小型原生應用程式。某些產品的確會因為這些代價，而不適合選擇 Electron。
小小的選單列工具大概不需要 Chromium，裝置驅動程式肯定也不需要。遊戲、專業音訊軟體，以及對延遲極度敏感的應用程式，則有不同的需求。而且，如果你的產品永遠只會在一個作業系統上執行，原生開發就更容易有充分理由。
但現代桌面軟體有很大一部分不屬於這些類別。
它們具有連接雲端服務的複雜介面，需要在 Windows 和 macOS 上執行，而且使用者也越來越期待支援 Linux。它們需要持續演進，與每週都推出變更的產品競爭，而開發它們的公司，通常只有有限數量的工程師。
對這些產品而言，開發者的生產力也是應用程式效能的一部分。
Electron 讓公司能從更龐大的人才庫招募、在網頁與桌面產品之間共用工程師、維護一個主要應用程式而不是多個、重複利用 JavaScript 生態系、更一致地在各作業系統推出功能，以原本往往難以合理負擔的成本支援 Linux，並把更多工程時間用來改善產品，而不是維護多套平行實作。
你很容易用 MB 來衡量 Electron 的成本。
其他選擇的成本則比較難看見。它們會以額外的工程師、重複的實作、更長的發布週期、平台專屬錯誤、招募困難、組織各自為政、得不到支援的 Linux 使用者，以及要多等好幾個月才能讓所有人用到的功能等形式出現。
這些成本不會出現在「活動監視器」裡。
但對開發軟體的公司而言，它們可能大得多。
軟體開發的目標，不是產生最小的二進位檔。
而是打造組織有能力推出、維護，並持續改善的最佳產品。
對範圍廣得令人意外的一大類桌面應用程式而言，Electron 仍是達成這個目標最有效率的方法之一。