Electron 和 NW.js 是兩個成熟的框架，可使用網頁技術打造跨平台桌面應用程式。兩者都結合了 Chromium 和 Node.js，讓開發者能以 HTML、CSS、JavaScript，以及 React、Vue 和 Angular 等熟悉的前端框架建立應用程式。
NW.js 其實是歷史較悠久的框架。這個專案最初名為 node-webkit，於 2011 年開始開發，並在 2012 年前後公開推出。Electron 則於 2013 年問世，最初由 GitHub 為旗下的 Atom 程式碼編輯器開發。儘管起步較晚，Electron 最終成為主流桌面應用程式更廣泛採用的框架。
如今，Visual Studio Code、Slack、Discord、Notion 和 Figma 等主要應用程式都採用 Electron。它也受惠於大型科技公司的參與，並由 OpenJS Foundation 提供治理。在 WebCatalog，我們選擇以 Electron 打造跨平台桌面應用程式。
相較之下，NW.js 在主要生產力與商業應用程式中的能見度要低得多。它的持續使用情況在遊戲產業尤其明顯，包括獨立遊戲及使用 RPG Maker 製作的作品。
那麼，這兩個框架有何差異，開發者又該如何選擇？
Electron 與 NW.js 比較速覽
這兩個框架都讓開發者能使用網頁技術打造桌面應用程式，但它們在應用程式架構、原生整合與安全性方面採取不同做法。
| 功能 | Electron | NW.js |
|---|---|---|
| 首次推出 | 2013 年 | 2011–2012 年 |
| 原始開發者 | GitHub | Intel 開源技術中心 |
| 治理與生態系 | OpenJS Foundation，並有大型企業貢獻者參與 | 由社群維護，源自 Intel |
| 瀏覽器引擎 | Chromium | Chromium |
| JavaScript 執行環境 | Node.js | Node.js |
| 桌面平台 | macOS、Windows、Linux | macOS、Windows、Linux |
| 架構 | 主處理程序與渲染處理程序 | 直接整合 Node.js 的 Chromium 架構 |
| Node.js 存取 | 主處理程序及受控的渲染處理程序整合 | 符合條件的應用程式頁面可直接存取 |
| 應用程式體積 | 相對較大 | 相對較大 |
| 效能 | 視應用程式而定 | 視應用程式而定 |
| 安全性 | 沙箱、情境隔離、IPC | 可設定的 Node 存取權限與框架隔離 |
| 採用情況 | 廣泛用於主流桌面應用程式 | 生態系較小，在遊戲領域有顯著採用 |
| 行動平台支援 | 無官方支援 | 無官方支援 |
最重要的差異並不在效能或應用程式體積。這兩個框架都隨附 Chromium 和 Node.js，因此資源需求大致相近。主要差異反而在於架構、安全性界線、開發工具與生態系支援。
歷史：NW.js 較早問世，但 Electron 更受歡迎
NW.js 是最早證明開發者能將 Node.js 與瀏覽器技術結合，以建立桌面應用程式的專案之一。它最初稱為 node-webkit，源自 Intel 開源技術中心，於 2011 年開始開發，並在 2012 年前後推出公開版本。
它的核心概念很直接：讓在類似瀏覽器環境中執行的 JavaScript 能直接存取 Node.js 模組。如此一來，開發者就能使用熟悉的網頁技術開發桌面應用程式，而不必建立傳統的原生介面。
Electron 於 2013 年以 Atom Shell 之名問世。GitHub 為旗下程式碼編輯器 Atom 開發了它，而 Atom 於 2014 年進入公開測試階段。Electron 的設計目的是提供當時以網頁技術為基礎的桌面框架之外的選擇，包括 node-webkit 和 Chromium Embedded Framework。
雖然這兩個框架都致力於讓網頁開發者更容易投入桌面開發，Electron 卻採用了不同的架構，將應用程式層級的功能與網頁內容分開。隨著開發者開始打造更複雜的應用程式，這種做法也越來越具吸引力。
隨後，Electron 獲得新創公司與大型科技公司採用。GitHub、Slack、Microsoft 和其他組織都對其開發與生態系有所貢獻。2019 年，Electron 加入 OpenJS Foundation，從 GitHub 所有轉移至中立的開源基金會。
如今，Electron 在成熟的治理模式下運作，設有涵蓋安全性、版本發布、API、Chromium 與 Node.js 升級等領域的工作小組。來自 Microsoft 和 Slack 等組織的工程師，都曾參與其維護與治理。
NW.js 同樣具有企業背景，最初由 Intel 建立。不過，它目前的生態系較小，大型桌面軟體公司的公開參與程度，也不及 Electron 廣泛。
這段歷史說明了一項重要差異：率先出現並不保證能長期占據優勢。NW.js 協助確立了使用 Chromium 和 Node.js 打造桌面應用程式的概念，但 Electron 吸引了更廣泛的開發者、維護者與商業採用者，形成更大的生態系。
如需更多背景資訊，請參閱 Electron 十週年回顧、Electron 加入 OpenJS Foundation，以及 node-webkit 專案的歷史。
架構：主處理程序與直接整合 Node.js 的比較
Electron 使用承襲自 Chromium 的多處理程序架構。每個 Electron 應用程式都有一個主處理程序，負責管理視窗、應用程式生命週期事件、作業系統整合，以及需要特殊權限的功能。網頁內容則在獨立的渲染處理程序中執行，並透過處理程序間通訊（IPC）與主處理程序溝通。
這讓應用程式邏輯與使用者介面程式碼有所區隔。渲染處理程序通常就像一般的瀏覽器環境，而主處理程序則負責需要存取 Node.js 或原生 API 的作業。Electron 也提供預先載入指令碼和 contextBridge API，讓開發者能向渲染處理程序開放特定功能，而不必授予不受限制的 Node.js 存取權。
NW.js 採取不同做法。它的設計目的是讓網頁應用程式能直接使用 Node.js 功能。在符合條件的應用程式頁面中，開發者可以透過熟悉的 JavaScript API 存取 Node.js 模組，不必為每個作業另行建立 IPC 介面。
例如，本機封裝的 NW.js 應用程式可以直接在頁面執行的指令碼中使用 Node.js：
const fs = require('node:fs');
const content = fs.readFileSync('notes.txt', 'utf8');
document.body.textContent = content;
這種簡單直接的方式，是 NW.js 最具代表性的優點之一。開發者可以結合瀏覽器 API 與 Node.js 功能，不一定要將程式碼拆分為不同的應用程式層。NW.js 也支援獨立的 JavaScript 情境與混合情境模式，讓瀏覽器與 Node.js 功能之間的互動方式更有彈性。
Electron 通常鼓勵更明確的分工。若要從渲染處理程序讀取檔案，典型的安全 Electron 應用程式會透過預先載入指令碼開放一項受限的操作，並由主處理程序處理檔案系統存取。
這種做法需要額外的程式碼，但也讓具特殊權限的應用程式功能與網頁內容之間的界線更加明確。對複雜的應用程式而言，這種分離能改善可維護性，也讓安全性責任更容易理解。
沒有任何一種架構在所有情況下都比較好。對小型應用程式，或能受惠於直接整合 Node.js 的專案來說，NW.js 可能感覺更直觀。Electron 則提供一套結構，當應用程式越來越複雜時，尤其能發揮作用。
效能、記憶體使用量與應用程式體積
由於 Electron 和 NW.js 都隨附 Chromium 與 Node.js，因此兩者都沒有內在的架構優勢，能帶來像 Electron 與 Tauri 之間那樣的體積差距。
即使是以任一框架建立的簡單應用程式，也需要散布相當大的執行環境。這兩個框架也都可能建立多個 Chromium 處理程序，雖然會增加記憶體用量，但有助於隔離工作負載並改善反應速度。
NW.js 直接整合 Node.js 與瀏覽器環境，因此某些作業不太需要 IPC。視情境設定而定，JavaScript 程式碼可以直接與 Node.js 功能互動，讓某些作業更簡單，也可能減少通訊負擔。
Electron 將需特殊權限的作業與渲染處理程序程式碼分開，因此跨越處理程序界線時會引入 IPC。不過，這並不代表 Electron 本質上比較慢。對一般使用者介面互動來說，這些額外負擔可能微不足道，而且這種分離也有助於避免耗費大量資源的後端工作影響渲染處理程序。
實務上，應用程式效能很大程度取決於開發者如何使用 Chromium、管理背景處理程序、實作渲染，以及處理應用程式狀態。
若要進行有意義的比較，開發者應評估：
- **啟動時間：**應用程式需要多久才能進入可互動狀態。
- **記憶體使用量：**閒置時的用量，以及實際工作負載下的記憶體使用量。
- **CPU 使用率：**渲染與背景作業期間的資源消耗。
- **應用程式體積：**下載大小與安裝後的儲存空間需求。
- **反應速度：**執行資源密集型工作時，介面的表現如何。
在未測量具代表性的應用程式之前，不應斷言任何一個框架比較快。Chromium 版本、建置設定、原生模組和應用程式架構的差異，都可能影響效能測試結果。
對於主要希望縮小應用程式體積的開發者，從 Electron 改用 NW.js，不太可能帶來如同改採系統 WebView 框架那樣顯著的縮減。
安全性：存取原生功能的不同做法
安全性是 Electron 與 NW.js 最重要的差異之一，尤其對需要顯示遠端網站或其他不受信任內容的應用程式而言。
Electron 提供多種安全機制，包括 Chromium 沙箱、情境隔離，以及停用渲染處理程序中 Node.js 整合的能力。新版 Electron 預設啟用重要的防護措施，專案的安全性文件也強烈建議將具特殊權限的原生 API 與遠端內容分開。
NW.js 允許符合條件的應用程式頁面更直接地存取 Node.js，這能簡化開發，但也需要謹慎考量哪些內容可以獲得這些權限。
NW.js 區分一般框架與啟用 Node 的框架。它也支援 node-remote 等設定，用來控制哪些遠端網址可以存取 Node.js 功能。其 webview 元件能在獨立的處理程序中顯示客體內容，而不會自動授予應用程式本身的權限。
| 安全性考量 | Electron | NW.js |
|---|---|---|
| 具特殊權限的 Node.js 存取 | 主要透過主處理程序與受控橋接 | 可在符合條件的應用程式情境中直接使用 |
| 遠端內容隔離 | 沙箱化的渲染處理程序與網頁內容 | 一般框架與隔離的 webview |
| 原生 API 開放方式 | IPC 與 contextBridge | Node 情境與可設定的存取權限 |
| Chromium 沙箱 | 支援，且具備安全的預設值 | 取決於框架類型與設定 |
| 開發者責任 | 驗證 IPC、導覽、權限與開放的 API | 控管具特殊權限的框架、Node 存取權與遠端內容 |
不應直接將 Electron 或 NW.js 視為安全的通用瀏覽器。無論使用哪個框架，顯示任意第三方網站的應用程式都需要額外的安全控管。
對於完全以受信任的本機內容為基礎開發的應用程式，NW.js 的直接整合可能很方便。對於需要嚴格區隔具特殊權限程式碼與不受信任網頁內容的應用程式，Electron 的架構能讓這些界線更清楚。
最終，安全性取決於應用程式設計、設定、相依套件管理，以及開發者套用安全性更新的速度。
採用情況：Electron 主導主流桌面應用程式
Electron 與 NW.js 最顯著的差異之一，就是桌面軟體開發者對它們的採用程度。
儘管專案歷史較短，Electron 已確立自己作為正式環境桌面應用程式主流框架的地位。其採用範圍涵蓋開發工具、通訊平台、生產力軟體、設計應用程式與商務工具。
一些知名範例包括：
| 公司 | Electron 應用程式 |
|---|---|
| Microsoft | Visual Studio Code |
| Salesforce | Slack |
| Discord | Discord |
| Notion | Notion |
| Figma | Figma |
| GitHub | GitHub Desktop |
| Signal | Signal Desktop |
| Postman | Postman |
這些產品證明 Electron 能支援數百萬人使用的複雜桌面應用程式。它的普及也促成了龐大的生態系，涵蓋函式庫、文件、偵錯工具與封裝解決方案。
企業參與是另一項優勢。Electron 最初由 GitHub 開發，後來吸引了大型科技公司工程師的貢獻。透過 OpenJS Foundation 進行治理，為協作、安全性維護、版本管理與長期開發提供了組織架構。
這不代表每一家使用 Electron 的公司都會直接貢獻框架，也不保證 Electron 永遠會得到更好的維護。不過，廣泛使用且有多元商業利害關係人參與的框架，可以受惠於共同的工程投入與實際正式環境經驗。
NW.js 的採用情況則有所不同。雖然它也被用來打造桌面應用程式，但公開表示採用 NW.js 的知名現代生產力或商業應用程式相對較少。過去常在 NW.js 展示案例中提及的許多應用程式都是較早期的專案，因此這些清單對評估目前採用程度的參考價值有限。
這不代表 NW.js 已遭棄置或無人使用。它仍持續發布整合新版 Chromium 和 Node.js 的版本。不過，在主流桌面軟體領域，它的可見生態系確實比 Electron 小得多。
對於正在為新商業應用程式選擇框架的開發者，這項差異很重要。較大的生態系通常更容易找到現成解決方案、招募具有相關經驗的開發者，並解決正式環境中的問題。
Electron 的普及不代表它在每個技術層面都更優越，但其更廣泛的採用程度與企業參與，是不容忽視的實務優勢。
你可以在 Electron 官方應用程式展示中探索更多範例。
NW.js 仍受歡迎的領域：獨立遊戲
雖然 NW.js 在主要現代生產力應用程式中並不常見，但它在遊戲開發領域仍有顯著影響，尤其是在獨立開發者之間。
其中一個原因，是它與 RPG Maker MV 等遊戲開發工具的整合。使用 RPG Maker MV 製作的遊戲，可以採用 NW.js 作為桌面執行環境，讓以 HTML5 與 JavaScript 為基礎的遊戲以獨立應用程式形式執行。
這表示開發者可能是透過遊戲引擎間接使用 NW.js，而不是將它選為通用桌面框架。
也有獨立證據顯示，NW.js 持續出現在新發布的遊戲中。SteamDB 會追蹤使用 NW.js 的遊戲，方法是自動檢查遊戲散布檔案中的技術特徵。其資料庫包含 2025 年和 2026 年發行的遊戲，提供了持續使用的證據，而非完全依賴可能已過時的應用程式展示。
與 NW.js 相關的範例包括：
| 遊戲 | 類型 | Steam 發行時間 |
|---|---|---|
| Look Outside | 恐怖角色扮演 | 2025 年 3 月 |
| OMORI | 角色扮演 | 2020 年 12 月 |
| CrossCode | 動作角色扮演 | 2018 年 9 月 |
| Fear & Hunger | 恐怖角色扮演 | 2018 年 12 月 |
| Ib | 恐怖冒險 | 2022 年 4 月 |
| Saihate Station | 冒險 | 2025 年 3 月 |
| Sheepy: A Short Adventure | 平台跳躍 | 2024 年 2 月 |
SteamDB 會從遊戲檔案自動辨識技術，因此個別偵測結果可能有誤，或只代表遊戲包含了某個相依套件，而非開發者刻意選用的執行環境。偵測到 NW.js，也無法確定遊戲使用哪個框架版本，或開發者是否積極維護它。
儘管如此，這些範例仍顯示 NW.js 依然是現代遊戲開發生態系的一部分。
這讓兩個框架呈現出有趣的差異。Electron 在主流桌面應用程式中能見度很高，尤其是生產力與開發工具。NW.js 在這些類別中的存在感較小，但持續出現在獨立開發的遊戲中。
對於打造商業軟體、通訊工具或複雜生產力應用程式的開發者，Electron 的生態系可能更符合需求。對於使用 RPG Maker，或維護以 NW.js 為基礎的遊戲的開發者，這個歷史較悠久的框架仍是成熟且實用的選擇。
開發體驗、工具與長期維護
這兩個框架都支援現代前端技術和 Node.js 套件，讓熟悉網頁開發的開發者容易上手。不過，Electron 擁有規模大得多、專注於通用桌面軟體的生態系。
NW.js 提供相對直接的開發模式。簡單的應用程式可透過 package.json 資訊清單與 HTML 進入點來定義。開發者可以直接從符合條件的應用程式頁面存取 Node.js 模組，並使用 NW.js API 管理視窗、選單、系統匣與其他桌面功能。
Electron 通常需要建立更多初始結構。開發者必須建立主處理程序進入點、設定應用程式視窗，並管理主處理程序與渲染處理程序之間的通訊。對小型應用程式而言，這可能感覺比較複雜，但也鼓勵開發者將應用程式功能組織成不同層次。
Electron 受惠於 Electron Forge 和 electron-builder 等成熟工具，為應用程式封裝、簽署、散布與更新提供解決方案。其廣泛的採用程度，也意味著開發者能找到更多針對進階桌面開發問題的範例與社群討論。
NW.js 提供 nw-builder 等封裝工具，也支援手動封裝。它也開放衍生自 Chromium 應用程式與擴充功能架構的 API，對已使用這些 API 的專案可能很有吸引力。
這兩個框架都需要開發者處理作業系統差異、程式碼簽署、原生模組相容性與應用程式更新。它們都無法消除散布正式桌面軟體的複雜性。
對長期維護而言，生態系的規模與組成尤其重要。打造商業應用程式的團隊，可能需要程式碼簽署、自動更新、當機回報、無障礙功能、原生整合與平台特定錯誤等方面的解決方案。
Electron 在大型軟體公司之間更廣泛的採用，讓開發者更容易為其中許多需求找到成熟做法與可重複使用的解決方案。NW.js 仍然具備相關能力，但開發者在尋找特殊桌面功能的範例或持續維護的整合方案時，可能會遇到選擇較少的情況。
對於預計維護多年的專案，生態系成熟度與持續投入程度，值得與框架 API 或效能測試結果同等重視。
為什麼 WebCatalog 選擇 Electron
在 WebCatalog，我們選擇 Electron，是因為它的架構非常符合產品需求。WebCatalog 讓使用者能將網站轉為桌面應用程式、獨立管理多個帳號，並在 macOS、Windows 和 Linux 上整理自己的應用程式。
與打造傳統桌面應用程式、能完全掌控前端的開發者不同，我們需要支援數千名不同開發者建立的網站。這些網站可能依賴不同的驗證系統、儲存機制、瀏覽器 API、媒體功能，以及複雜的 JavaScript 應用程式。
Electron 和 NW.js 都使用 Chromium，因此在瀏覽器引擎相容性方面具有類似優勢。對我們而言，差別在於框架對應用程式視窗、瀏覽器工作階段、導覽、權限，以及具特殊權限的應用程式程式碼與遠端內容之間的分離，提供多少控制能力。
Electron 為這些需求提供一套成熟的 API。它的 BrowserWindow、webContents 和 session 介面，讓我們能在相對底層的層級管理瀏覽器行為。持久性工作階段分割區尤其重要，因為它們讓使用者能在同一網站上保持多個帳號登入，而不會共用 Cookie 與其他工作階段資料。
NW.js 也支援內嵌 webview、Cookie 管理與儲存分割區，因此這些功能並非 Electron 獨有。不過，Electron 專用的應用程式處理程序與成熟的瀏覽器管理 API，提供了非常適合我們需求的架構。
安全性也是重要考量。由於 WebCatalog 會顯示我們無法控制的第三方網站，我們必須謹慎將遠端內容與具特殊權限的應用程式功能分開。Electron 的處理程序模型、情境隔離與 IPC 機制有助於維持這種分離，不過我們仍需自行實作並維護適當的安全控管。
最後，Electron 的生態系讓跨平台開發與維護更為可行。我們的應用程式需要在 macOS、Windows 和 Linux 上執行，並支援平台特定功能、封裝、簽署與更新。Electron 的工具、文件與廣泛的實際採用，為這些工作提供了穩固基礎。
我們也重視 Electron 的長期開發生態系。大型科技公司的參與，以及透過 OpenJS Foundation 進行的治理，讓我們更有信心在產品演進過程中，持續取得技術資源、安全性維護與社群支援。
我們了解 Electron 的缺點，尤其是應用程式體積與資源需求。我們並未因此更換框架，而是持續探索降低不必要負擔的方法。例如，我們已實作 APFS 複製功能，以減少產生的 Mac 應用程式所占用的磁碟空間。
我們的決定並非基於 NW.js 無法支援複雜軟體的想法。這兩個框架都提供了我們重視的 Chromium 一致性。對 WebCatalog 而言，Electron 的架構、安全控管、更廣泛的主流採用，以及成熟的工程生態系，使它成為更合適的選擇。
NW.js 仍然適用的情境
雖然 Electron 擁有更大的生態系，NW.js 仍保有一些值得開發者考量的實質優勢。
它最具特色的功能，是能從符合條件的瀏覽器情境直接存取 Node.js。對於將現有網頁應用程式轉換為桌面應用程式的開發者，這提供了一種方便的方式，能加入檔案系統存取、作業系統整合與其他原生功能，而不必設計獨立的通訊層。
在下列情況中，NW.js 可能是不錯的選擇：
- **使用現有的 NW.js 工具鏈打造遊戲。**使用 RPG Maker MV，或維護依賴 NW.js 的專案的開發者，可能沒有太多理由更換框架。
- **希望直接整合 Node.js。**應用程式可以受惠於在受信任的介面中直接存取 Node.js 功能。
- **應用程式相對簡單。**小型專案可能不需要 Electron 對主處理程序與渲染邏輯更明確的分離。
- **專案已使用 NW.js。**如果現有應用程式穩定且維護良好，遷移至 Electron 可能沒有太大好處。
- **特定 Chromium 應用程式 API 很重要。**NW.js 提供對受支援 Chrome API 的存取，可能對特定應用程式有所幫助。
NW.js 也仍在積極維護中。持續更新 Chromium，顯示它仍隨著瀏覽器平台一同演進。
對於維護現有 NW.js 應用程式或遊戲的開發者，改用 Electron 需要評估架構差異、封裝變更與相容性需求。除非有明確的技術或商業效益，否則沿用現有框架可能更務實。
Electron 與 NW.js：你該選哪一個？
這兩個框架都能打造跨平台桌面應用程式。對新專案而言，選擇主要取決於開發者希望如何組織程式碼，以及哪個生態系最能支援需求。
| 你的優先考量 | 較好的起點 | 原因 |
|---|---|---|
| 大型、複雜的桌面應用程式 | Electron | 成熟的架構與生態系 |
| 主流生產力或商業軟體 | Electron | 在這些類別中獲得廣泛得多的採用 |
| 長期生態系與企業參與 | Electron | OpenJS Foundation 與主要業界貢獻者 |
| 使用 RPG Maker MV 製作的遊戲 | NW.js | 成熟的整合與工具鏈 |
| 從應用程式頁面直接存取 Node.js | NW.js | 核心架構特色 |
| 明確分離 UI 與具特殊權限的程式碼 | Electron | 主處理程序／渲染處理程序模型與 IPC |
| 豐富的封裝與散布工具 | Electron | 成熟的工具生態系 |
| 現有的 NW.js 應用程式 | NW.js | 避免不必要的遷移 |
| 桌面平台之間的 Chromium 一致性 | 皆可 | 兩者都隨附 Chromium |
| 最小的應用程式體積 | 兩者皆無明顯優勢 | 兩者都隨附 Chromium 和 Node.js |
| 瀏覽器工作階段與視窗管理 | Electron | 成熟的專用 API |
| 廣泛的社群資源與範例 | Electron | 更高的主流採用程度 |
對大多數準備開發具一定規模新桌面應用程式的團隊來說，Electron 是更有力的預設選擇。其架構、生態系、安全性指引、企業參與，以及廣泛的正式環境採用，使它成為適合長期開發的實用框架。
對於能受惠於直接整合 Node.js 的專案、已依賴 NW.js 的遊戲開發工作流程，或既有的 NW.js 程式碼庫，NW.js 仍值得考慮。它在某些使用情境下可以更簡單，而 Chromium 基礎也提供了廣泛的網頁平台相容性。
開發者也應記得，這兩個框架都不算特別輕量。如果主要考量是縮小應用程式體積與降低基本資源消耗，Tauri 等替代方案或許值得考慮。
結語
Electron 和 NW.js 的共同點多於差異。兩者都結合 Chromium 與 Node.js，讓開發者使用熟悉的網頁技術打造跨平台桌面應用程式。兩者也都支援現代 JavaScript 框架、原生作業系統整合，以及功能豐富的桌面體驗。
NW.js 較早問世，在 Electron 出現之前，就提出了結合 Node.js 與網頁技術的做法。不過，Electron 隨後成為主流桌面應用程式更廣泛採用的框架，受惠於 GitHub 最初的投入、大型科技公司的貢獻，以及 OpenJS Foundation 的治理。
它們的採用模式有明顯差異。Electron 支撐著數百萬人使用的熱門生產力、通訊與開發應用程式。NW.js 在這個市場的能見度較低，但在獨立遊戲領域仍有重要地位，包括以 RPG Maker 製作的作品及近期發行的遊戲。
在 WebCatalog，我們與許多主要桌面軟體開發者選擇了相同的框架。Electron 為我們提供 Chromium 的一致性、瀏覽器管理能力、安全架構與跨平台工具，讓我們能在 macOS、Windows 和 Linux 上支援各式各樣的網頁應用程式。
NW.js 並未過時，它在遊戲開發領域的持續使用證明它仍有價值。不過，對於準備打造全新通用桌面應用程式的開發者，Electron 更廣泛的生態系、成熟工具、企業參與及更大的社群，使它成為更務實的預設選擇。
最終，哪個選擇更好，取決於應用程式的需求、開發團隊的經驗，以及維護軟體的長期成本。
