Electron 和 Flutter 是兩款廣受歡迎的跨平台桌面應用程式開發框架。兩者都支援 macOS、Windows 和 Linux，但它們的背景不同，採取的桌面開發方式也有根本上的差異。
Electron 專為桌面應用程式而設計。它由 GitHub 於 2013 年推出，結合 Chromium 與 Node.js，讓開發人員能使用 JavaScript、TypeScript、HTML 和 CSS 建置桌面軟體。由 Google 開發的 Flutter 則最初是用於 Android 和 iOS 的行動 UI 框架，幾年後才擴展至桌面平台。
這兩款框架都有強大的業界支持，也已廣泛用於正式產品。Electron 支撐了 Visual Studio Code、Slack、Discord、Notion 和 Figma 等應用程式，以及 Anthropic 和 OpenAI 的 AI 應用程式。Flutter 在行動開發領域尤其受歡迎，但也用於 AppFlowy、RustDesk 和 Ubuntu 系統工具等桌面軟體。
在 WebCatalog，我們選擇以 Electron 打造跨平台桌面應用程式。雖然 Flutter 在應用程式大小、自訂 UI 算繪，以及桌面與行動裝置之間的程式碼共用方面具有優勢，但 Electron 以桌面為優先的架構和成熟的瀏覽器功能更符合我們的需求。
Electron 速度緩慢或耗用大量資源的名聲，也值得重新檢視。在仰賴它的龐大貢獻者與企業生態系支持下，這款框架已歷經多年的最佳化。近期版本在啟動時間、JavaScript 執行、記憶體管理和執行階段效率方面都有大幅改善。
那麼，如今這兩款框架的表現如何？開發人員又該如何選擇？
Electron 與 Flutter 概覽
雖然這兩款框架都支援桌面開發，但不同的起源塑造了它們各自的架構、API、工具和生態系。
| 功能 | Electron | Flutter |
|---|---|---|
| 首次推出 | 2013 年 | 2017 年預覽版、2018 年穩定版 |
| 最初開發者 | GitHub | |
| 最初重點 | 桌面應用程式 | 行動應用程式 |
| 目前重點 | 桌面應用程式 | 行動、桌面、網頁、嵌入式 |
| 主要語言 | JavaScript、TypeScript | Dart |
| UI 技術 | HTML、CSS、Chromium | Flutter 小工具 |
| 算繪引擎 | Chromium | Flutter 算繪引擎 |
| 桌面平台 | macOS、Windows、Linux | macOS、Windows、Linux |
| 桌面成熟度 | 自誕生以來便專注於桌面 | 自 2022 年起提供穩定的桌面支援 |
| 行動平台支援 | 無官方支援 | Android、iOS |
| 應用程式大小 | 通常較大 | 通常較小 |
| 基礎記憶體用量 | 通常較高 | 往往較低 |
| 多視窗支援 | 成熟的內建 API | 2026 年提供實驗性核心 API；另有外掛替代方案 |
| 重用現有網頁應用程式 | 極佳 | 通常需要重寫 UI |
| 最適合 | 以網頁技術為基礎的桌面應用程式 | 自訂跨平台介面 |
最重要的差異，並不只是 Electron 使用 Chromium，而 Flutter 使用自己的算繪引擎。Electron 是為了解決桌面開發問題而建立的；Flutter 最初則是解決行動開發問題，之後才調整架構以支援桌面環境。
這項差異持續影響著開發人員體驗和平台功能。
發展歷史：Electron 為桌面而生，Flutter 為行動而生
Electron 於 2013 年以 Atom Shell 之名起步，是 GitHub 為支援 Atom 程式碼編輯器而開發的框架。從一開始，它的目標就是運用網頁技術建置功能完善的桌面應用程式，同時整合作業系統功能。
因此，應用程式視窗、選單、鍵盤快速鍵、系統匣、通知、檔案對話方塊和原生整合等桌面概念，在 Electron 的整個發展過程中一直都是其架構的核心。
Electron 隨後獲得打造生產力軟體、通訊平台、開發工具和其他桌面產品的企業採用。如今，它由 OpenJS Foundation 管理，並受惠於與大型科技公司相關的貢獻。
Flutter 走的是另一條路。Google 最初將它開發為用於建置行動應用程式的框架，著重於高度客製化且效能優異的介面。Flutter 1.0 於 2018 年 12 月發布，支援 Android 和 iOS。
這款框架原本的架構反映了智慧型手機的需求：觸控互動、行動導覽模式、應用程式生命週期管理，以及占滿單一螢幕的介面。
隨著時間推移，Google 將 Flutter 擴展至其他平台，包括網頁和桌面作業系統。Windows 於 2022 年 2 月獲得穩定支援，macOS 和 Linux 則隨著 Flutter 3 於 2022 年 5 月獲得穩定支援。
Google 在 Flutter 3 發布公告中表示，這個版本完成了 Flutter 從以行動為中心的框架轉型為多平台框架的過程。
這段歷史並不代表 Flutter 不適合桌面應用程式。它的桌面功能已大幅改善，現在可以為三大主要桌面作業系統建置並發行應用程式。
不過，這有助於解釋，為什麼某些桌面專屬功能在 Flutter 中的成熟速度比 Electron 慢。
桌面功能：Electron 搶得先機
桌面應用程式與行動應用程式有很大的差異。桌面使用者期待能調整視窗大小、使用多個獨立視窗、透過鍵盤和滑鼠互動，以及使用快顯功能表、系統匣、拖放、檔案關聯，並與作業系統緊密整合。
Electron 正是圍繞這些需求而建構。它的 BrowserWindow 和 BaseWindow API 讓開發人員可以建立及管理多個視窗，其他 API 則提供選單、全域快速鍵、桌面通知、系統對話方塊、通訊協定處理常式等功能。
Flutter 支援其中許多功能，但有些需要額外套件、平台專屬實作，或較新的框架 API。
多視窗支援是特別能說明差異的例子。在行動裝置上，應用程式通常只占用單一視窗，對話方塊與彈出式視窗則以覆蓋層的方式呈現。桌面應用程式往往需要多個獨立視窗，讓使用者能在不同螢幕間移動、調整大小、最小化，並分別管理。
多年來，開發多視窗 Flutter 桌面應用程式的人員，一直仰賴第三方套件或自訂原生整合。
2026 年 8 月，Flutter 團隊推出了新的桌面視窗 API，由 Google 和 Canonical 合作開發。這套 API 支援獨立視窗、對話方塊、彈出式視窗、工具提示，以及其他桌面視窗類型。
值得注意的是，它是以 Flutter 主要開發通道中的實驗性功能推出，而不是已成熟的穩定功能。
| 桌面功能 | Electron | Flutter |
|---|---|---|
| 多個獨立視窗 | 成熟的內建支援 | 實驗性核心 API；另有第三方替代方案 |
| 視窗生命週期管理 | 成熟的內建 API | 核心支援仍持續發展 |
| 系統匣 | 內建 API | 外掛與原生整合 |
| 應用程式選單 | 內建 API | 外掛與平台整合 |
| 全域鍵盤快速鍵 | 內建 API | 外掛或原生整合 |
| 自訂標題列 | 成熟的 API | 平台專屬解決方案 |
| 檔案關聯與深層連結 | 成熟的桌面整合 | 平台整合與外掛 |
| 瀏覽器工作階段與 Cookie | 豐富的內建 API | 取決於 WebView 實作 |
這並不是說 Flutter 無法打造功能完善的桌面應用程式。AppFlowy 和 RustDesk 等產品已證明它做得到。但對於開發桌面優先軟體的團隊而言，Electron 更成熟的 API 能減少所需的自訂平台整合工作。
效能：Flutter 輕量，但 Electron 也已大幅改善
效能常被視為 Flutter 相較於 Electron 的最大優勢之一。Flutter 會將 Dart 編譯為原生機器碼，並使用自己的算繪引擎，不必為了顯示介面而將 Chromium 一併打包。
相較之下，Electron 包含 Chromium 和 Node.js，因此會增加應用程式大小和基礎記憶體用量。過去，這也讓 Electron 有了打造笨重桌面應用程式的名聲。
不過，這樣的名聲並未完全反映現代 Electron 的實際情況。
十多年來，Electron 持續受惠於 Chromium、V8、Node.js 及自身應用程式執行階段的改善。如今，許多大型軟體公司都使用這款框架，而它們的產品必須在數百萬個安裝實例中，提供反應迅速的介面、高效率的背景處理和可靠的效能。
重要的是，效能最佳化會在多個層級進行。Electron 納入新版 Chromium 和 V8 時，便會自動受惠於它們的改善；同時，Electron 維護者也會最佳化其自身的處理程序初始化、IPC、原生整合和資源管理。
Electron 近期的效能改善
Electron 的 2026 年版本資訊提供了具體範例，顯示這款框架如何持續提升效率。
| 版本 | 最佳化項目 | 效益 |
|---|---|---|
| Electron 43，2026 年 7 月 | 內嵌 Node.js 啟動快照 | 降低應用程式初始化負擔 |
| Electron 43 | 已編譯 V8 位元組碼快取 | 避免重複編譯框架套件和預載指令碼 |
| Electron 43 | 改善沙箱化算繪處理程序的初始化 | 減少網頁內容呈現前的阻塞作業 |
| Electron 43 | 針對 V8 內建功能的設定檔導向最佳化 | 改善陣列、字串和規則運算式等 JavaScript 操作 |
| Electron 43 | Windows 和 Linux 上的 ThinLTO | 改善經過最佳化的原生發行版建置 |
| Electron 44，2026 年 8 月 | 減少閒置時 Node.js 計時器的喚醒次數 | 減少不必要的 CPU 活動 |
| Electron 44 | 更快的 Linux 工具組初始化 | 改善應用程式啟動速度 |
| Electron 44 | 更早啟動沙箱化算繪處理程序 | 降低開啟第一個視窗時的延遲 |
| Electron 44 | 更小的 Linux 發行套件 | 在發行的執行階段中節省約 37 MB |
資料來源：Electron 43 版本資訊和 Electron 44 版本資訊。Electron 44 中記載的部分改善也已回移植至較早的版本分支。
其中一項特別值得關注的改善涉及 Electron 的預載指令碼。過去，沙箱化算繪處理程序在呈現頁面前，可能會執行阻塞式 IPC 操作以取得啟動資料。
2026 年，Electron 維護者以更有效率的方式取代這項機制：在導覽前預先傳送啟動資料，並快取已編譯的預載程式碼。
在一項公開的工程效能測試中，這項變更讓模擬冷啟動工作負載下的首次內容繪製時間，從約 244 毫秒降至 140 毫秒。這表示在該特定測試中縮短了約 43%，並不代表每個 Electron 應用程式現在都能加快 43% 啟動。
隨著時間推移，這款框架在記憶體方面也有所改善。Electron 在 Electron 14 採用了 V8 指標壓縮，維護者指出，這項底層技術有望讓 V8 堆積大小最多減少 40%，並讓 CPU 和記憶體回收效能改善約 5–10%。
這些數字具體指的是 V8 的記憶體和執行特性，而不是應用程式的總記憶體用量。儘管如此，它們仍說明了 JavaScript 引擎層級的改善如何讓 Electron 應用程式受惠，而不必由每位應用程式開發人員各自實作相同的最佳化。
如需更多背景資訊，請參閱 Electron 與 V8 記憶體籠。
為什麼企業投入很重要
Electron 的效能改善，與其生態系的規模和成熟度密切相關。
大型軟體公司有強烈的動機確保 Electron 維持高效率。Microsoft 將 Electron 用於 Visual Studio Code，Salesforce 將它用於 Slack，Anthropic 將它用於 Claude Desktop，OpenAI 則將它用於 ChatGPT Desktop。其他採用者包括 Discord、Notion、Figma 和 GitHub。
這些產品擁有龐大的使用者群，效能問題會直接影響客戶滿意度、電池續航力和生產力。
Electron 由來自多個組織的貢獻者維護，包括 Microsoft、Slack／Salesforce、Notion 等。這讓專案能獲得在正式產品中仰賴這款框架的企業所提供的工程專業。
Electron 官方文件明確將效能、穩定性和安全性列為持續優先關注的事項，並說明使用 Electron 的組織如何參與維護。
也有個別公司出資改善的案例。2025 年 12 月，Electron 團隊發布了一篇工程案例研究，說明他們如何修正 Chromium 中 Windows 視窗調整大小的問題，並將變更回移植至 Electron。這項工作由使用 Electron 建置的 3D 建模應用程式 Plasticity 出資。
這展現了成熟開源生態系的一項重要優勢：為某個應用程式出資或實作的改善，最終可能讓許多其他應用程式一同受惠。
當然，使用 Electron 並不代表每家公司都直接參與其開發，而大型企業採用者的存在，也不保證效能一定更好。但廣泛的業界參與，確實為持續最佳化提供了有意義的基礎。
這表示 Electron 比 Flutter 更快嗎？
不一定。
對許多應用程式而言，Flutter 在基礎執行階段負擔方面，仍具有架構上的優勢，因為它不需要隨附 Chromium 來呈現自己的介面。輕量的 Flutter 應用程式可能使用更少的記憶體、啟動更快，而且需要的磁碟空間更少。
不過，執行階段負擔只是效能的一個面向。Chromium 是高度最佳化的瀏覽器引擎，受惠於算繪、JavaScript 執行、GPU 加速、網路和媒體處理等方面的大量投入。
當應用程式原本就仰賴這些功能時，Electron 尤其有優勢。在 Flutter 中重新實作同等功能，或嵌入獨立的瀏覽器元件，可能會抵銷 Flutter 原本的部分資源優勢。
| 效能因素 | Electron | Flutter |
|---|---|---|
| 應用程式大小 | 因包含 Chromium 而較大 | 通常較小 |
| 基礎記憶體用量 | 通常較高 | 往往較低 |
| 啟動時間 | 已大幅最佳化，但 Chromium 仍增加負擔 | 輕量應用程式往往較快 |
| UI 算繪 | 經過最佳化的 Chromium 管線 | Flutter 算繪引擎 |
| JavaScript 執行 | 成熟且經過最佳化的 V8 執行階段 | Flutter 的 Dart UI 不需要 |
| 自訂圖形 | Chromium 算繪 API | 專用的 Flutter 算繪管線 |
| 現有網站呈現 | Chromium 直接支援 | 需要整合 WebView |
| 執行階段最佳化 | Chromium、V8、Node.js、Electron 貢獻者 | Flutter 引擎和 Dart 貢獻者 |
| 長期效能投入 | 廣泛的業界與開源生態系 | Google 和 Flutter 的開源生態系 |
因此，兩者的差異比「Flutter 很快、Electron 很慢」這種說法複雜得多。
對於具有自訂介面、且瀏覽器需求有限的應用程式，Flutter 可能更有效率。Electron 則提供高度最佳化的網頁執行階段，並透過 Chromium、V8、Node.js 和 Electron 本身的開發工作持續改善。
開發人員應針對具代表性的正式環境工作負載進行效能測試，而不是只根據框架過去的名聲來比較。
開發人員體驗：JavaScript 和 TypeScript 與 Dart 的比較
Electron 對已經熟悉 JavaScript 和 TypeScript 的團隊特別有吸引力。開發人員可以使用 React、Vue、Svelte 和其他網頁框架，重用現有前端元件，並仰賴 Node.js 套件提供後端功能。
Flutter 需要開發人員學習 Dart 及其以小工具為基礎的介面系統。開發人員不是撰寫 HTML 和 CSS，而是透過 Dart 小工具建構介面，並以程式碼表達版面配置、樣式、導覽和互動。
Flutter 提供出色的工具，包括熱重新載入、小工具檢查、偵錯工具和效能分析。Electron 開發人員則受惠於 Chromium DevTools、Node.js 生態系，以及 Electron Forge 和 electron-builder 等成熟的桌面封裝工具。
過去，選擇熟悉的程式語言，可能對開發成本產生重大影響。以 JavaScript 為主的團隊可能偏好 Electron，因為採用 Dart 需要學習新語言並重寫現有元件。
這項考量仍然重要，尤其是對已有程式碼庫的專案而言。不過，AI 輔助開發正在改變這個局面。
AI 程式開發工具如何改變框架決策
Claude Code、Codex 和 Google Antigravity 等工具，讓開發人員更容易使用現有專業領域之外的程式語言和框架。
現代 AI 程式開發助理可以探索不熟悉的程式碼庫、解釋框架特定慣例、實作功能、重構程式碼、撰寫測試，並協助偵錯。開發人員不再需要手動撰寫每一行程式碼，也不必先記住每個框架 API 才能有效工作。
這對選擇 Electron 或 Flutter 尤其重要。
多年來使用 TypeScript 的開發人員，一開始可能會覺得 Dart 和 Flutter 比較陌生。但在 AI 協助下，學習語法、建立小工具、實作狀態管理，或整合原生 API 所涉及的許多重複性工作，都能加速完成。
Flutter 也提供適用於 AI 程式開發助理的官方 Dart 和 Flutter 整合。這些整合可以為代理程式提供框架專屬指引、分析器診斷資訊，以及開發工具的存取能力。
同樣的趨勢也不限於 Dart。Rust 和 C++ 等語言，過去往往需要更多專業知識，尤其是在記憶體管理、所有權和原生整合方面。AI 工具可以減少理解及維護這些語言程式碼所需的心力。
Rust 並不是 Flutter 的主要程式語言，Dart 才是；但更廣泛的原則相同：開發人員愈來愈能根據架構優勢來選擇技術，而不只是依據對語言的熟悉程度。
這仍然有其限制。AI 產生的程式碼可能包含細微錯誤、誤解平台 API，或引入效能和安全性問題。開發人員仍須對架構、程式碼審查、效能分析、測試，以及應用程式的長期維護負責。
AI 輔助也無法消除框架的根本限制。它或許能協助開發人員實作缺少的桌面整合，但開發人員仍然需要跨作業系統建置、測試及維護該功能。
儘管如此，採用不熟悉程式語言的成本，已不再像過去那麼難以承擔。
對於特別重視效能、啟動時間、記憶體用量或原生整合的新應用程式，開發人員不應只因為較熟悉 TypeScript，就自動選擇 Electron。
即使一開始覺得 Dart 沒那麼方便，Flutter 仍可能值得投入。同樣地，若 Rust、C++ 或原生平台框架更能滿足需求，開發人員也可能發現，在 AI 輔助開發下，這些做法變得愈來愈可行。
選擇應主要由應用程式的架構和需求決定，而不只是由開發團隊已經熟悉哪種語言來決定。
Flutter 的桌面生態系仍在追趕
Electron 和 Flutter 都有龐大的開發人員社群，但它們的生態系組成有所不同。
Electron 的生態系已圍繞桌面應用程式發展了十多年。對於程式碼簽署、自動更新、視窗管理、系統整合、通知和應用程式發行等常見桌面需求，開發人員都能找到成熟的函式庫、範例和工具。
Flutter 透過 pub.dev 擁有豐富的套件生態系，但許多套件最初是為行動應用程式開發的。並非每個 Flutter 外掛都支援 Windows、macOS 和 Linux，而且這三個桌面平台的支援程度可能各不相同。
當開發人員需要嵌入式瀏覽器檢視、作業系統自動化、全域快速鍵、媒體裝置存取或原生視窗管理等專門功能時，這一點就特別重要。
例如，Flutter 官方的 webview_flutter 套件支援 Android、iOS 和 macOS，但沒有提供官方的 Windows 或 Linux 實作。以這些平台為目標的開發人員，需要額外套件或自訂整合。
相較之下，Electron 將 Chromium 納入其應用程式執行階段，並透過自身 API 直接提供瀏覽器相關功能。
對於採用一般自訂介面和標準平台需求的應用程式，這項差異影響較小。但當應用程式需要在多個作業系統上提供進階桌面功能或類似瀏覽器的行為時，差異就變得更加重要。
Flutter 2026 年開發人員調查透露了什麼
Flutter 自身的調查結果，為行動與桌面開發之間的成熟度差異提供了有用的證據。
2026 年 8 月，Flutter 團隊發布了一份收到超過 3,500 份回覆的調查結果。開發人員對 Android 開發的滿意度，明顯高於 Windows 或 Linux。
| Flutter 開發領域 | 正面滿意度 |
|---|---|
| Dart 語言 | 92% |
| Android 應用程式開發 | 91% |
| Flutter 核心框架 | 90% |
| Windows 開發 | 74% |
| Linux 開發 | 73% |
| 網頁開發 | 72% |
資料來源：Flutter 2026 年第 2 季開發人員調查。這些數字代表受訪者的滿意度，而不是框架使用率或市場占有率。
這些數字顯示，Flutter 開發人員整體上仍相當滿意，尤其是對核心框架和 Android 開發。不過，Windows 和 Linux 開發的評分明顯較低。
Flutter 團隊明確指出，桌面多視窗支援是持續投入的領域之一。
這些結果支持一個較為細緻的結論：Flutter 是成熟的跨平台框架，但其桌面開發人員體驗仍在演進，而這種演進也反映了它以行動為優先的起源。
這些結果中並沒有可直接比較的 Electron 調查，因此不應將這些數字解讀為 Electron 開發人員普遍更滿意的證據。
採用情況：桌面領域的 Electron，行動領域的 Flutter
這兩款框架都受到大型科技組織支持，並用於正式應用程式。不過，它們的採用模式反映了各自不同的起源。
Electron 在主流桌面生產力軟體、通訊平台、開發工具，以及日益增加的 AI 應用程式中尤其常見。Flutter 在行動應用程式中的採用則廣泛得多，知名桌面產品的數量雖然持續增加，但仍相對較少。
| 應用程式 | 框架 | 類別 |
|---|---|---|
| Visual Studio Code | Electron | 程式碼編輯器 |
| Slack | Electron | 通訊 |
| Discord | Electron | 通訊 |
| Notion | Electron | 生產力 |
| Figma Desktop | Electron | 設計 |
| GitHub Desktop | Electron | 開發工具 |
| Claude Desktop | Electron | AI 助理 |
| ChatGPT Desktop | Electron | AI 助理 |
| AppFlowy | Flutter | 生產力 |
| RustDesk | Flutter | 遠端桌面 |
| Ubuntu Desktop Installer | Flutter | 系統工具 |
| Ubuntu App Center | Flutter | 應用程式管理 |
| Google Gemini for Mac | 原生 Swift | AI 助理 |
Microsoft、Salesforce、Anthropic 和 OpenAI 等大型公司，都選擇以 Electron 開發桌面應用程式。這些例子展現了這款框架在開發、通訊、生產力和 AI 軟體上的多樣用途。
Electron 也受惠於 OpenJS Foundation 之下成熟的開源治理架構，以及來自大型科技公司相關工程師的貢獻。
Google 是 Flutter 的最初開發者和主要支持者，而 Canonical 也對 Flutter 的 Linux 和桌面功能投入了大量資源。
不過，即使是 Google，也不是每個桌面應用程式都使用 Flutter。
Google 為 Mac 版 Gemini 選擇了原生 Swift
一個有趣的例子，是 Google 於 2026 年 4 月推出的 macOS 官方 Gemini 應用程式。
Google 團隊沒有使用 Flutter，而是以原生 Swift 建置這款應用程式。Google 的 Gemini 負責人 Josh Woodward 公開表示，這是一款原生 Swift 應用程式，並提到一個小型團隊在不到 100 天內實作了超過 100 項功能。
Google 也表示，AI 輔助開發協助團隊快速從最初構想到原生 Swift 實作。
這說明，即使是開發大型跨平台框架的公司，當其他技術更符合產品需求時，也可能選擇不同的技術。
Gemini macOS 應用程式強調與 Apple 作業系統的緊密整合，包括全域鍵盤快速鍵、選單列功能和其他桌面互動。
選擇原生 Swift，並不能證明 Flutter 或 Electron 不適合。Google 並未公布其所考慮替代方案的完整比較。
儘管如此，這仍顯示，當平台整合很重要時，原生開發依然具有吸引力，而 AI 輔助工程也能降低使用平台專屬語言的部分成本。
另一方面，Flutter 已證明自己能支援專業級桌面軟體。AppFlowy 使用 Flutter 和 Rust 提供跨平台生產力應用程式，RustDesk 則將 Flutter 與以 Rust 為基礎的遠端桌面功能結合。Canonical 也在重要的 Ubuntu 元件中採用了 Flutter。
過去，Flutter 最知名的商業成功案例主要集中於行動開發，包括 BMW、Nubank 和 ByteDance 等公司的應用程式。
對於專門以桌面平台為目標的開發人員而言，Electron 擁有更長的歷史，以及更成熟的主流桌面應用程式陣容。Flutter 是可行的替代方案，但桌面開發是它原有生態系的延伸，而不是歷來的核心。
為什麼 WebCatalog 選擇 Electron
在 WebCatalog，我們選擇 Electron，是因為我們的產品從根本上就是圍繞網頁應用程式和瀏覽器功能而建構。
WebCatalog 讓使用者能將網站轉換為桌面應用程式、獨立管理多個帳號，並在 macOS、Windows 和 Linux 上整理自己的應用程式。
我們與建置傳統應用程式、能完全掌控前端的開發人員不同；我們需要支援由數千名不同開發人員建立的網站。這些網站可能仰賴複雜的驗證系統、瀏覽器 API、儲存機制、媒體功能和 JavaScript 框架。
對於這項需求，Electron 隨附的 Chromium 執行階段特別有價值。它讓我們能在所有支援的桌面平台上提供一致的瀏覽器環境。
Flutter 的 UI 架構並未包含通用的 Chromium 執行階段。若要顯示網站，Flutter 應用程式必須整合 WebView 或其他瀏覽器元件。在不同作業系統上，這些元件可能採用不同的算繪引擎，功能也不盡相同。
對 WebCatalog 這類產品而言，這會增加相容性和維護上的挑戰。
Electron 也提供成熟的 API，可管理瀏覽器工作階段、Cookie、儲存空間、權限、導覽和應用程式視窗。它的持久性工作階段分區尤其重要，因為這能讓使用者為同一個網站維持多個獨立的登入工作階段。
Flutter 或許能透過外掛和原生瀏覽器整合支援類似功能，但若要在 macOS、Windows 和 Linux 上一致地實作並維護相同行為，就需要大量額外的工程工作。
我們的技術堆疊也是考量因素之一。WebCatalog 主要使用 JavaScript 和 TypeScript 開發，因此 Electron 自然符合我們團隊的專長和現有程式碼庫。
不過，熟悉 TypeScript 並不是我們選擇 Electron 的主要原因。有了現代 AI 程式開發工具，採用 Dart 或其他語言，比幾年前容易得多。
如果 Flutter 能為我們的需求提供明顯更好的架構，即使語言不同，我們也有充分理由考慮採用。
效能對我們同樣重要，但更換框架不一定是改善效能的最佳方式。
Electron 持續的效能改善很有價值，因為這讓我們受惠於更廣泛的 Chromium 和 Electron 生態系中的最佳化工作。我們不必維護完全獨立的瀏覽器整合，而能持續以獲得大量工程投入的執行階段為基礎進行開發。
我們也致力於降低應用程式本身特有的額外負擔。例如，我們導入了 APFS 複製，以減少所產生 Mac 應用程式的磁碟用量。
這種做法讓我們能解決實際的資源耗用問題，同時不犧牲產品核心所需的 Chromium 相容性和瀏覽器管理功能。
歸根究柢，對 WebCatalog 而言，Electron 以瀏覽器為導向的架構、跨平台一致性、成熟的桌面 API，以及持續的效能改善，比 Flutter 可能帶來的基礎資源節省更有價值。
Flutter 的優勢所在
雖然 WebCatalog 偏好 Electron，但對許多類型的應用程式而言，Flutter 都可能是絕佳選擇。
它最強大的優勢，是能在桌面和行動平台之間共用應用程式邏輯和介面程式碼。已經使用 Flutter 開發 Android 和 iOS 應用程式的公司，通常可以將現有程式碼庫延伸至桌面，而不必引入完全獨立的前端框架。
Flutter 也很適合需要高度客製化介面、精緻動畫，以及相對較低執行階段負擔的應用程式。
以下情況中，Flutter 可能是更好的選擇：
- 同時建置桌面和行動應用程式。 Flutter 使用同一款框架支援 Android、iOS、macOS、Windows 和 Linux。
- 擴充現有的 Flutter 行動應用程式。 開發人員可以重用大量程式碼和專業知識。
- 建立高度客製化的介面。 Flutter 對算繪、版面配置和動畫提供廣泛的控制能力。
- 盡可能縮小應用程式大小和基礎記憶體用量。 Flutter 不需要隨附 Chromium 執行階段來呈現自己的介面。
- 開發不高度仰賴瀏覽器功能的產品。 Flutter 提供專用的 UI 框架，不需要 HTML、CSS 或 JavaScript。
- 將執行階段效率置於語言熟悉度之上。 AI 程式開發助理可以降低採用 Dart 的阻力，讓 Flutter 對目前主要使用 JavaScript 的團隊更有吸引力。
開發人員不應將 Flutter 視為僅適用於行動平台的框架。它是一套功能完整的多平台工具組，已有正式投入使用的桌面應用程式，儘管其行動開發生態系仍更為成熟。
Electron 與 Flutter：你該選哪一個？
這兩款框架都能用來建置功能完善的桌面應用程式，但它們的架構和生態系各自適合不同需求。
| 你的優先考量 | 較好的起點 | 原因 |
|---|---|---|
| 桌面優先應用程式 | Electron | 成熟且以桌面為導向的 API |
| 現有網頁應用程式 | Electron | 重用 HTML、CSS 和 JavaScript |
| 現有 Flutter 行動應用程式 | Flutter | 共用程式碼和工具 |
| 桌面與行動開發 | Flutter | 官方同時支援兩者 |
| 小型應用程式套件 | Flutter | 不需為 UI 隨附 Chromium |
| 低基礎記憶體用量 | Flutter | 在同類輕量應用程式中，執行階段負擔較低 |
| 自訂動畫和介面 | Flutter | 專用算繪引擎 |
| 多個應用程式視窗 | Electron | 成熟的內建 API |
| 顯示第三方網站 | Electron | 內建 Chromium |
| 複雜的瀏覽器工作階段管理 | Electron | 成熟的工作階段 API |
| 廣泛的 Node.js 整合 | Electron | 內建 Node.js 執行階段 |
| 以桌面為導向的生態系 | Electron | 更長的桌面開發歷史 |
| 持續獲得以 Chromium 為基礎的效能改善 | Electron | 受惠於 Chromium、V8 和 Electron 的最佳化 |
| 自訂 UI 的執行階段效率 | Flutter | 原生編譯和專用算繪器 |
| Linux 桌面開發 | 兩者皆可 | 兩者都正式支援 Linux |
| 現有的 Dart 和 Flutter 專業能力 | Flutter | 重用既有工程投入 |
對於運用現有網頁技術建置桌面應用程式的開發人員，Electron 通常是較務實的選擇。它能直接使用 Chromium，提供豐富的桌面整合 API，以及成熟的 JavaScript 生態系。
對於跨桌面和行動平台打造自訂介面的團隊，Flutter 則能提供更統一的架構，以及更低的基礎執行階段負擔。
AI 程式開發助理愈來愈普及，也意味著開發人員應在不熟悉的技術能帶來實質優勢時，將它們納入考量。當技術效益超過維護另一套技術堆疊的成本時，選擇 Flutter、Dart、Rust 或原生平台語言，都可能是合理的。
想保留 HTML、CSS 和 JavaScript，同時縮小應用程式大小的開發人員，也可以考慮 Tauri。它使用系統 WebView，而不是 Flutter 的自訂算繪引擎。
結語
Electron 和 Flutter 都是功能強大的跨平台框架，而它們不同的發展歷史，有助於解釋各自的優勢。
Electron 從一開始就是為桌面應用程式而設計。十多年來，它已建立起成熟的生態系，涵蓋桌面 API、封裝工具、原生整合和瀏覽器管理功能。
Microsoft、Salesforce、Anthropic、OpenAI 和 GitHub 等公司的採用也很重要。這些公司使用 Electron，反映了它支援高要求正式應用程式的能力；而更廣泛的工程生態系，也促進了這款框架持續開發與最佳化。
Electron 的效能隨時間大幅改善，近期版本也顯示，降低啟動延遲、記憶體負擔、CPU 活動和應用程式大小，仍是持續積極推進的優先事項。
Flutter 最初是行動框架，之後才擴展至桌面開發。它在自訂介面、原生編譯和跨平台程式碼共用方面的優勢，對於打造行動優先、同時也需要桌面版本產品的開發人員尤其有吸引力。
Flutter 的桌面支援已可用於正式產品，但某些桌面專屬功能，以及部分外掛生態系仍在持續成熟。它在多視窗支援上的持續投入，說明這款框架如何不斷調整，以滿足原本並非其行動架構核心的需求。
同時，AI 輔助開發也讓程式語言熟悉度不再那麼具有決定性。開發人員愈來愈能有效運用 Dart、Rust、Swift 和其他技術，而不必具備過去可能需要的同等程度專業經驗。
在 WebCatalog，我們選擇 Electron，是因為我們的產品高度仰賴瀏覽器功能、網頁相容性，以及成熟的桌面 API。它持續的效能改善和成熟的生態系，進一步鞏固了這項決策。
對於開發行動優先應用程式或高度客製化介面的開發人員，Flutter 可能是更好的選擇。對於運用網頁技術打造桌面優先軟體的開發人員，Electron 仍是最成熟、最實用的選項之一。
最終，開發人員應優先選擇最能支援產品效能、功能和長期維護需求的架構，而不是根據對資源用量的過時假設，或對程式語言的熟悉程度來選擇框架。
