Electron 和 Chromium Embedded Framework（CEF）是將 Chromium 導入桌面應用程式的兩項成熟技術。兩者都能讓開發者打造可在 macOS、Windows 和 Linux 上顯示現代網站與網頁介面的軟體。不過，它們的根本用途並不相同。
Electron 是一套完整的桌面應用程式框架，結合了 Chromium、Node.js 和原生作業系統 API。開發者可以使用 JavaScript、TypeScript、HTML 和 CSS 建構完整的應用程式，無須具備豐富的原生程式開發經驗。相較之下，CEF 是一套將 Chromium 嵌入既有或全新應用程式的框架，這些應用程式通常以 C++ 或其他原生語言編寫。
這兩項技術都廣泛用於正式推出的軟體。Visual Studio Code、Slack、Discord 和 Notion 等應用程式採用 Electron，而 Spotify、Steam 和 OBS Studio 等產品則使用 CEF。在 WebCatalog，我們選擇以 Electron 建構跨平台桌面應用程式。
那麼，兩者有什麼差異？又該在什麼情況下選擇其中一種？
Electron 與 CEF 快速比較
雖然 Electron 和 CEF 都使用 Chromium，但它們在架構、開發者體驗和目標應用情境上有顯著差異。
| 特性 | Electron | Chromium Embedded Framework（CEF） |
|---|---|---|
| 首次推出 | 2013 年 | 2008 年 |
| 主要用途 | 建構完整的桌面應用程式 | 將 Chromium 嵌入其他應用程式 |
| 瀏覽器引擎 | Chromium | Chromium |
| 主要語言 | JavaScript、TypeScript | C、C++，亦有第三方語言繫結 |
| 是否內含 Node.js | 是 | 否 |
| 原生整合 | Electron API 和 Node.js 原生模組 | 直接與原生程式碼整合 |
| 應用程式結構 | 主處理程序與轉譯處理程序 | 主應用程式搭配 Chromium 子處理程序 |
| 離屏轉譯 | 可透過自訂解決方案實現 | 內建 API 支援 |
| 應用程式大小 | 通常較大 | 取決於整合方式，但 Chromium 本身就占用相當大的空間 |
| 效能 | 取決於應用程式 | 取決於應用程式與整合方式 |
| 跨平台支援 | macOS、Windows、Linux | macOS、Windows、Linux |
| 封裝生態系統 | Electron Forge、electron-builder | 通常由主應用程式管理 |
| 最適合 | 以 JavaScript 為基礎的桌面應用程式 | 需要嵌入網頁內容的原生應用程式 |
最重要的區別在於，Electron 提供的是應用程式框架，而 CEF 提供的是瀏覽器嵌入框架。由於兩者運作於不同的抽象層級，因此未必能直接互相替代。
架構：完整框架與嵌入式瀏覽器
Electron 將 Chromium 和 Node.js 結合為統一的應用程式執行環境。開發者建立主處理程序來管理應用程式視窗、生命週期事件和原生功能，而轉譯處理程序則負責以網頁技術打造的介面。
這種架構讓開發者能使用熟悉的 JavaScript 和 TypeScript 工具編寫應用程式的大部分內容。Electron 提供的 API 可用於建立視窗、管理瀏覽器工作階段、處理選單、顯示通知、存取系統對話方塊，以及與作業系統整合。
CEF 採取不同的做法。它不提供完整的桌面應用程式框架，而是讓開發者將 Chromium 整合至自行建構並掌控的應用程式中。
例如，正在建構原生 C++ 應用程式的開發者，可以使用 CEF 在既有的應用程式視窗內顯示網頁內容。周邊介面、應用程式生命週期、背景服務和其他原生功能，仍由開發者掌控。
CEF 提供的 API 可用於管理瀏覽器執行個體、導覽、資源載入、JavaScript 執行，以及瀏覽器與原生應用程式之間的通訊。它也採用 Chromium 的多處理程序架構，以獨立處理程序負責轉譯和其他瀏覽器功能。
這項差異會影響開發者如何組織應用程式。使用 Electron 時，應用程式通常圍繞 Chromium 和 Node.js 建構。使用 CEF 時，Chromium 通常只是較大型應用程式中的一個元件。
CEF 也能用於建構以網頁介面為主的應用程式，但開發者必須自行實作更多周邊的應用程式基礎架構。
一個有趣的歷史細節是，早期版本的 Electron 和 NW.js 都曾使用 CEF。Electron 最終改為更直接地整合 Chromium，因為 CEF 的抽象層讓某些功能難以實作，尤其是與 Node.js 的深度整合。
對於希望使用網頁技術建構桌面應用程式，並尋求完整框架的開發者而言，Electron 通常是更直接的起點。對於已經擁有原生應用程式、希望加入網頁功能的開發者而言，CEF 可能是更自然的選擇。
開發者體驗：JavaScript 與原生開發
Electron 最大的優勢之一是容易上手。熟悉現代網頁開發的開發者，可以運用既有技能建構桌面應用程式，而無須學習 C++ 或特定平台的 UI 框架。
Electron 與 Node.js 的整合，讓開發者能使用龐大的套件生態系統，處理檔案系統操作、網路連線、資料庫、背景處理程序等功能。React、Vue、Svelte 和 Angular 等熱門前端技術也能直接使用，無須大幅調整架構。
CEF 主要圍繞 C 和 C++ API 設計。雖然有適用於 C#、Java、Python 和 Delphi 等語言的第三方繫結，開發者仍需了解原生應用程式的架構，以及 CEF 對處理程序、執行緒和生命週期的要求。
對於已在維護原生應用程式的團隊而言，這可能是優點，而非缺點。CEF 讓開發者能導入現代網頁介面，而無須重寫既有的原生程式碼，或採用全新的應用程式框架。
然而，對於以 JavaScript 為主、準備開發全新桌面應用程式的團隊而言，CEF 通常需要更多設定與原生整合工作。
差異也延伸到開發工具。Electron 擁有 Electron Forge 和 electron-builder 等成熟工具，可簡化封裝、程式碼簽署、應用程式發佈與更新。CEF 雖然提供二進位發行套件和範例，但開發者通常必須自行將框架整合到自己的建置與部署系統中。
這並不代表 CEF 的能力較弱，只是反映出它的定位是可嵌入的元件，而不是完整的應用程式開發平台。
效能、記憶體用量與應用程式大小
由於 Electron 和 CEF 都使用 Chromium，因此兩者都不會自動消除執行現代瀏覽器引擎所帶來的資源負擔。
兩項技術都可能使用多個處理程序，分別負責轉譯、GPU 加速、網路連線和其他瀏覽器功能。記憶體用量和 CPU 使用率，很大程度上取決於顯示的內容、作用中的瀏覽器執行個體數量，以及應用程式管理資源的方式。
整合至既有的原生應用程式時，CEF 能提供更大的彈性。開發者可以只在介面中需要網頁技術的部分使用 Chromium，其他功能則直接以原生程式碼實作。
例如，圖形應用程式可以使用 CEF 製作設定面板或嵌入式網頁介面，同時讓轉譯引擎、文件處理和其他對效能敏感的功能維持原生實作。
Electron 應用程式也能透過 Node.js 附加元件、外部處理程序或原生模組執行原生程式碼。不過，Electron 的架構整體上仍以使用網頁技術建構應用程式本身為導向。
CEF 一項特別實用的能力是離屏轉譯。CEF 不必在傳統瀏覽器視窗中顯示網頁內容，而是能將內容轉譯至緩衝區，再由主應用程式自行處理與顯示。這對遊戲引擎、串流軟體和具備自訂轉譯系統的工具等應用程式很有價值。
Electron 可以透過額外整合來支援特殊的轉譯工作流程，但 CEF 已將離屏轉譯作為其嵌入 API 的成熟功能。
開發者評估效能時，最有用的衡量項目包括：
- **啟動時間：**應用程式多快能進入可用狀態。
- **記憶體用量：**顯示具代表性的瀏覽器內容並執行原生功能時的資源消耗。
- **CPU 使用率：**轉譯、導覽和背景作業期間的效能表現。
- **應用程式大小：**下載大小與安裝後的磁碟空間用量。
- **轉譯需求：**應用程式需要一般視窗，還是自訂的離屏轉譯。
此外，也必須區分 CEF 與使用系統 WebView 的框架。CEF 本身包含 Chromium，而不是依賴作業系統所安裝的瀏覽器引擎。因此，從 Electron 改用 CEF，並不會自動讓應用程式大幅縮小。
若開發者最在意的是縮小應用程式套件，可以考慮 Tauri 等使用系統提供之 WebView 的替代方案。
若未針對實際實作進行效能測試，就不應斷言 Electron 或 CEF 一定比較快。
安全性與瀏覽器更新
Electron 和 CEF 都仰賴 Chromium 的瀏覽器架構與安全機制，但開發者仍有責任妥善設定應用程式。
Electron 提供轉譯處理程序沙箱、情境隔離，以及透過 IPC 在具有特殊權限的應用程式功能與網頁內容之間通訊等功能。其安全性文件建議限制 Node.js 存取權限、仔細驗證 IPC 訊息，並將遠端載入的內容視為不受信任。
CEF 也支援 Chromium 的多處理程序架構與安全隔離。不過，由於 CEF 整合於開發者自行掌控的應用程式中，因此主應用程式必須負責決定開放哪些瀏覽器功能、權限與原生能力。
CEF 支援 JavaScript 繫結和原生通訊，讓開發者能將網頁內容與應用程式功能連接起來。這些介面必須審慎設計，尤其是在顯示第三方網站時。
| 安全性考量 | Electron | CEF |
|---|---|---|
| Chromium 沙箱 | 支援 | 支援 |
| 具特殊權限的原生存取 | Node.js 和 Electron API | 主應用程式的原生 API |
| JavaScript 與原生程式碼通訊 | 預載指令碼與 IPC | V8 繫結與處理程序間訊息傳遞 |
| 遠端內容隔離 | 轉譯處理程序沙箱與情境隔離 | Chromium 處理程序隔離與主應用程式控制機制 |
| 瀏覽器安全性更新 | 升級 Electron 版本 | 升級 CEF 版本 |
| 應用程式安全性責任 | 應用程式開發者 | 應用程式開發者 |
另一項重要考量是瀏覽器維護。Electron 和 CEF 通常都會隨附自己的 Chromium 執行環境，因此當安全性修正推出時，開發者必須發佈應用程式更新。
CEF 提供追蹤 Chromium 的發行分支和二進位發行套件，讓這個過程更簡單。Electron 也同樣持續維護整合 Chromium 和 Node.js 更新的版本。
兩種做法都無法完全免除持續維護的需求。使用舊版 Chromium 的應用程式，可能仍暴露於上游已修補的漏洞之中。
對於開發可顯示任意網站之軟體的團隊而言，安全性維護應視為應用程式生命週期中不可或缺的一部分，而非偶爾才處理的工作。
採用情況：使用 Electron 和 CEF 的主要應用程式
Electron 和 CEF 都已廣泛用於正式產品，但使用模式有所不同。
Electron 在主流桌面生產力、通訊和開發者應用程式中特別常見。Microsoft 的 Visual Studio Code 使用 Electron，其他知名的 Electron 產品還包括 Slack、Discord、Notion、Figma、Signal Desktop 和 GitHub Desktop。
CEF 也被大型軟體公司採用，尤其常見於將網頁介面整合至具備既有原生架構的應用程式時。
例如：
| 應用程式 | 技術 | 典型用途 |
|---|---|---|
| Visual Studio Code | Electron | 跨平台程式碼編輯器 |
| Slack | Electron | 團隊通訊 |
| Discord | Electron | 通訊與社群平台 |
| Notion | Electron | 筆記與生產力工具 |
| Figma Desktop | Electron | 設計應用程式 |
| Spotify Desktop | CEF | 桌面用戶端內以網頁技術打造的介面 |
| Steam | CEF | 桌面用戶端內的嵌入式網頁介面 |
| OBS Studio | CEF | 瀏覽器來源、疊加畫面與瀏覽器停駐面板 |
Spotify 是 CEF 採用者中資料記錄特別完整的例子。其官方開源頁面會公布各個 Spotify Desktop 版本所使用的 CEF 和 Chromium 版本。
OBS Studio 則是另一個清楚展現開發者為何選擇 CEF 的例子。它的 obs-browser 整合使用 CEF 提供瀏覽器來源，讓使用者能在串流場景中顯示以網頁技術製作的疊加畫面與其他內容。CEF 是 OBS Studio 的一個元件，而不是建構整個應用程式所使用的框架。
Steam 也在桌面用戶端內使用以 Chromium 為基礎的嵌入式網頁元件，將網頁介面與更廣泛的原生應用程式基礎架構整合。
這些例子說明了兩項技術的差別。Electron 常用於建構完整的桌面應用程式，而 CEF 則經常用於將網頁功能導入已具備大量原生元件的應用程式。
不應將 CEF 視為冷門或過時的替代方案。它於 2008 年創立，比 Electron 更早，且多年來已廣泛用於商業軟體。其悠久歷史與主要產品持續採用的情況，顯示嵌入 Chromium 仍是桌面開發的重要方式。
與此同時，Electron 已圍繞以 JavaScript 為基礎的桌面應用程式建立了格外強大的生態系統。它的廣泛採用、成熟工具和大型科技公司的參與，對於使用網頁技術打造新產品的團隊很有吸引力。
這兩套框架各有優勢，因為它們面向不同的架構需求。
為什麼 WebCatalog 選擇 Electron
在 WebCatalog，我們選擇使用 Electron 作為跨平台桌面應用程式的基礎，因為它非常符合我們的產品需求。
WebCatalog 讓使用者能將網站轉為桌面應用程式、獨立管理多個帳號，並在 macOS、Windows 和 Linux 上整理應用程式。我們的軟體需要支援數千位不同開發者建立的網站，而這些網站使用不同的驗證系統、儲存機制、瀏覽器 API 和 JavaScript 框架。
Electron 和 CEF 都提供一致的 Chromium 執行環境，這對相容性非常重要。與基於系統 WebView 的框架不同，它們讓我們能在支援的各種桌面平台上，使用已知的 Chromium 版本。
不過，WebCatalog 並不是一個主要以原生功能為主、只需要嵌入瀏覽器元件的應用程式。瀏覽器功能是我們產品的核心。我們需要對視窗、工作階段、儲存空間、權限、導覽，以及應用程式生命週期行為擁有廣泛的控制能力。
Electron 為這些需求提供了成熟的 API。它的 BrowserWindow、webContents 和 session 介面，讓我們能使用 JavaScript 和 TypeScript 建構類似瀏覽器的功能。持久性工作階段分區尤其重要，因為它能讓使用者在同一個網站上，為多個帳號維持獨立的登入工作階段。
CEF 也提供用於管理瀏覽器執行個體、請求、儲存空間和原生整合的 API。原則上，許多相同能力都能使用 CEF 實作。不過，這樣做會需要我們自行建構並維護更多原生基礎架構。
Electron 與 Node.js 的整合也符合我們的技術堆疊。我們可以使用 TypeScript 實作大部分的桌面應用程式邏輯、在不同產品之間共用程式碼，並善用 JavaScript 生態系統。
跨平台開發是另一項考量。WebCatalog 支援 macOS、Windows 和 Linux，包含各平台特有的應用程式封裝、整合方式和系統行為。Electron 成熟的 API 與發佈工具，減少了我們需要維護的原生程式碼數量。
我們了解 Electron 會帶來額外負擔。隨附 Chromium 會增加應用程式大小，而以瀏覽器為基礎的應用程式也需要審慎管理資源。我們沒有選擇替換 Electron，而是專注於改善使用方式。
例如，我們導入了 APFS 複製功能，減少所產生之 Mac 應用程式的磁碟空間用量，在保留 Chromium 相容性的同時，減少重複儲存。
我們的決定並不代表 Electron 在所有情況下都優於 CEF。如果 WebCatalog 主要是原生應用程式，只包含少數嵌入式網頁介面，CEF 可能會是絕佳選擇。但由於我們的產品從根本上就是圍繞網頁應用程式和瀏覽器功能建構，Electron 提供了更有效率、更容易維護的基礎。
CEF 的優勢所在
雖然 Electron 是 WebCatalog 的首選，但對於需要更深入整合原生軟體的應用程式而言，CEF 仍具備重要優勢。
當開發者已經有成熟的 C++ 應用程式，並希望在不替換既有架構的前提下導入現代網頁介面時，CEF 特別具有吸引力。
離屏轉譯支援是另一項顯著優勢。串流軟體和遊戲引擎等應用程式，可能需要將網頁內容直接轉譯至自訂的圖形管線，而不是傳統桌面視窗。CEF 為這類使用情境提供成熟的 API。
CEF 也讓開發者能充分掌控瀏覽器整合。他們可以自訂請求處理、導覽、JavaScript 繫結、資源載入，以及瀏覽器執行個體與原生應用程式元件之間的互動方式。
對於具備深厚原生開發專業的團隊而言，這種彈性的價值可能勝過 Electron 的便利性。
在以下情況中，CEF 值得考慮：
- **為既有的原生應用程式加入網頁介面。**開發者可以保留目前的應用程式架構，並在需要的地方嵌入 Chromium。
- **建構具有自訂轉譯需求的軟體。**離屏轉譯可讓網頁內容整合至圖形管線和特殊介面中。
- **與原生 C++ 功能深度整合。**CEF 提供原生 API，並能細部控制瀏覽器行為。
- **維護既有的 CEF 應用程式。**遷移至 Electron 可能需要大幅變更架構，卻沒有實質效益。
- **結合原生與網頁介面。**開發者可以在應用程式的部分區域使用 Chromium，同時在其他區域保留原生 UI 元件。
使用 CEF 確實需要承擔更多應用程式基礎架構方面的責任。開發者可能需要自行實作封裝、更新、視窗管理，以及特定平台的整合。
對於已具備原生應用程式維護能力的團隊而言，這可能完全合理。但對於以網頁技術為主、正在打造全新桌面產品的團隊而言，這可能帶來不必要的複雜性。
Electron 與 CEF：該如何選擇？
這兩項技術都已成熟、持續積極開發，且能支援複雜的桌面軟體。哪一個選擇更好，主要取決於你是要圍繞網頁技術建構新的桌面應用程式，還是將網頁功能嵌入既有的原生應用程式。
| 優先需求 | 較佳起點 | 原因 |
|---|---|---|
| 使用 JavaScript 或 TypeScript 開發新的桌面應用程式 | Electron | 完整的應用程式框架 |
| 既有的原生 C++ 應用程式 | CEF | 可整合至原生架構 |
| 盡量減少原生開發 | Electron | Node.js 和 JavaScript API |
| 在原生視窗中嵌入網頁內容 | CEF | 專為嵌入用途設計 |
| 離屏轉譯與自訂圖形管線 | CEF | 專用轉譯 API |
| 完善的桌面封裝與更新工具 | Electron | 成熟的發佈生態系統 |
| 與原生 C++ 程式碼直接整合 | CEF | 原生 C 和 C++ 介面 |
| 各桌面平台間一致的 Chromium 環境 | 皆可 | 兩者都隨附 Chromium |
| 複雜的瀏覽器工作階段管理 | 皆可 | 兩者都提供瀏覽器管理能力 |
| 小型應用程式套件 | 兩者都沒有先天優勢 | 兩者都會發佈 Chromium |
| 既有的 JavaScript 工程團隊 | Electron | 熟悉的開發技術堆疊 |
| 既有的 CEF 產品 | CEF | 避免不必要的遷移 |
對大多數準備開發全新跨平台桌面應用程式的網頁開發者而言，Electron 通常是更實際的選擇。它提供應用程式架構、原生整合、開發工具與發佈生態系統，讓開發者能打造完整產品，而無須一切從頭開始。
對於已經擁有原生應用程式，或需要特殊瀏覽器嵌入能力的開發者而言，CEF 通常是更好的選擇。其彈性與直接的原生整合，使它特別適合遊戲引擎、串流工具、工業應用程式，以及包含嵌入式網頁介面的複雜原生產品。
兩項技術都不具備天生更快或更安全的優勢。這些特性在很大程度上取決於應用程式、其架構，以及實作品質。
結語
Electron 和 Chromium Embedded Framework 共享相同的底層瀏覽器技術，但解決的是不同問題。
Electron 的設計目標，是讓網頁開發者更容易進行桌面應用程式開發。它將 Chromium、Node.js 和原生桌面 API 結合為一套框架，讓團隊能使用 JavaScript 和 TypeScript 建構功能豐富的應用程式。
CEF 的設計目標，是將 Chromium 嵌入其他應用程式。它提供較低層級的瀏覽器整合控制能力，對於需要網頁介面或特殊轉譯能力的原生應用程式特別有價值。
兩者都已在主要的正式軟體產品中證明其價值。Visual Studio Code、Slack、Discord 和 Notion 等應用程式採用 Electron，而 Spotify、Steam 和 OBS Studio 等產品則使用 CEF。
在 WebCatalog，我們選擇 Electron，是因為我們的產品從根本上就是圍繞瀏覽器功能建構。它一致的 Chromium 執行環境、成熟的瀏覽器管理 API，以及 JavaScript 生態系統，讓我們能有效率地開發與維護跨平台桌面應用程式。
對於開發原生應用程式的開發者而言，CEF 仍然是絕佳選擇，尤其是在需要將 Chromium 嵌入既有架構，而不是以它作為整個產品基礎的情況下。
最終的選擇取決於你要打造什麼。如果你想使用網頁技術建立完整的桌面應用程式，Electron 通常是更好的起點。如果你想為原生應用程式加入 Chromium，CEF 很可能是更合適的工具。
