Electron 和 NW.js 是两个成熟的框架，用于利用 Web 技术构建跨平台桌面应用程序。两者都结合了 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 基金会的治理。在 WebCatalog，我们选择了 Electron 来构建跨平台桌面应用程序。
相比之下，NW.js 在主要生产力和商业应用中的可见度要低得多。它的持续应用尤其体现在游戏行业，包括独立游戏以及使用 RPG Maker 构建的游戏。
那么，这两个框架相比如何，开发者又该选择哪一个呢？
Electron 与 NW.js 概览
这两个框架都允许开发者使用 Web 技术构建桌面应用程序，但它们在应用架构、原生集成和安全性方面采取了不同的方法。
| 特性 | Electron | NW.js |
|---|---|---|
| 首次推出 | 2013 年 | 2011–2012 年 |
| 原始开发者 | GitHub | 英特尔开源技术中心 |
| 治理与生态系统 | OpenJS 基金会，有大型企业贡献者参与 | 由社区维护，起源于英特尔 |
| 浏览器引擎 | 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，诞生于英特尔开源技术中心，开发始于 2011 年，并于 2012 年之前后推出公开版本。
它的核心理念很直接：允许在类浏览器环境中运行的 JavaScript 直接访问 Node.js 模块。这使得开发者可以使用熟悉的 Web 技术开发桌面应用，而无需构建传统的原生界面。
Electron 于 2013 年以 Atom Shell 的名称问世。GitHub 开发它是为了构建自己的代码编辑器 Atom，后者于 2014 年进入公开测试阶段。Electron 被设计为当时基于 Web 技术的桌面框架的替代方案，包括 node-webkit 和 Chromium Embedded Framework。
虽然这两个框架的共同目标都是让 Web 开发者更容易进行桌面开发，但 Electron 采用了不同的架构，将应用级功能与 Web 内容分离。随着开发者开始构建更复杂的应用，这种方式变得越来越有吸引力。
随后，Electron 得到了初创公司和大型科技公司的采用。GitHub、Slack、微软等组织为其开发和生态系统作出了贡献。2019 年，Electron 加入 OpenJS 基金会，从 GitHub 所有转为由中立的开源基金会管理。
如今，Electron 在成熟的治理模式下运作，设有涵盖安全、发布、API、Chromium 和 Node.js 升级等领域的工作组。来自微软和 Slack 等组织的工程师参与了它的维护与治理。
NW.js 同样具有企业背景，诞生于英特尔。不过，它目前的生态系统较小，在大型桌面软件公司的公开参与广度方面也不及 Electron。
这段历史说明了一个重要区别：先发并不保证长期占据主导地位。NW.js 帮助确立了利用 Chromium 和 Node.js 构建桌面应用的理念，但 Electron 吸引了更广泛的开发者、维护者和商业采用者生态。
如需了解更多背景，请参阅 Electron 十周年回顾、Electron 加入 OpenJS 基金会，以及 node-webkit 项目的历史。
架构：主进程与直接集成 Node.js
Electron 使用继承自 Chromium 的多进程架构。每个 Electron 应用都有一个主进程，负责管理窗口、应用生命周期事件、操作系统集成和特权功能。Web 内容在独立的渲染进程中运行，并通过进程间通信（IPC）与主进程通信。
这区分了应用逻辑与用户界面代码。渲染进程通常表现为常规浏览器环境，而主进程负责处理需要访问 Node.js 或原生 API 的操作。Electron 还提供预加载脚本和 contextBridge API，允许开发者向渲染进程开放选定的功能，而不授予其不受限制的 Node.js 访问权限。
NW.js 采取了不同的方法。它旨在让 Web 应用能够直接使用 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 应用会通过预加载脚本开放有限的操作，并在主进程中处理文件系统访问。
这种方式需要额外的代码，但能让特权应用功能与 Web 内容之间的边界更加明确。对于复杂应用，这种分离可以提高可维护性，并让安全职责更容易理解。
没有哪种架构在所有情况下都更好。对于小型应用或受益于直接集成 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 等设置，用于控制哪些远程 URL 可以访问 Node.js 功能。其 webview 组件可以在独立进程中显示访客内容，而不会自动授予其应用本身的权限。
| 安全考量 | Electron | NW.js |
|---|---|---|
| 特权 Node.js 访问 | 主要通过主进程和受控桥接 | 在符合条件的应用上下文中可直接使用 |
| 远程内容隔离 | 沙盒化渲染进程和 Web 内容 | 普通框架和隔离的 webview |
| 原生 API 开放方式 | IPC 和 contextBridge | Node 上下文和可配置访问权限 |
| Chromium 沙盒 | 支持，并具有安全的默认设置 | 取决于框架类型和配置 |
| 开发者责任 | 验证 IPC、导航、权限和开放的 API | 控制特权框架、Node 访问和远程内容 |
不应直接将 Electron 或 NW.js 视为安全的通用浏览器。无论使用哪个框架，显示任意第三方网站的应用都需要额外的安全控制。
对于完全围绕可信本地内容开发的应用，NW.js 的直接集成可能很方便。对于需要在特权代码和不可信 Web 内容之间建立强隔离的应用，Electron 的架构可以让这些边界更加明确。
归根结底，安全性取决于应用设计、配置、依赖管理，以及开发者应用安全更新的速度。
采用情况：Electron 在主流桌面应用中占据主导地位
Electron 和 NW.js 最显著的差异之一，是它们在桌面软件开发者中的采用情况。
尽管是较年轻的项目，Electron 已确立了自己作为生产级桌面应用主流框架的地位。其应用涵盖开发工具、通信平台、生产力软件、设计应用和商业实用工具。
一些知名示例包括：
| 公司 | Electron 应用 |
|---|---|
| 微软 | Visual Studio Code |
| Salesforce | Slack |
| Discord | Discord |
| Notion | Notion |
| Figma | Figma |
| GitHub | GitHub Desktop |
| Signal | Signal Desktop |
| Postman | Postman |
这些产品表明，Electron 能够支持供数百万人使用的复杂桌面应用。其广泛采用也促成了庞大的生态系统，涵盖库、文档、调试工具和打包解决方案。
企业参与是另一个优势。Electron 最初由 GitHub 开发，后来吸引了大型科技公司工程师的贡献。OpenJS 基金会对其进行治理，为协作、安全维护、发布管理和长期开发提供了组织架构。
这并不意味着每家使用 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 的持续使用提供了证据，而不是完全依赖可能已经过时的应用展示列表。
与 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 包，因此熟悉 Web 开发的开发者都比较容易上手。不过，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 基金会的治理，让我们对产品不断演进过程中技术资源、安全维护和社区支持的可获得性更有信心。
我们承认 Electron 的不足，尤其是应用体积和资源需求。我们没有更换框架，而是继续探索减少不必要开销的方法。例如，我们已经实现了利用 APFS 克隆减少所生成 Mac 应用的磁盘占用。
我们的决定并非基于 NW.js 无法支持复杂软件的看法。这两个框架都能提供我们所重视的 Chromium 一致性。对于 WebCatalog，Electron 的架构、安全控制、更广泛的主流采用和成熟的工程生态系统使其更加适合。
NW.js 仍然适用的场景
虽然 Electron 的生态系统更大，但 NW.js 仍保留了一些值得开发者考虑的实际优势。
它最鲜明的特性，是能够从符合条件的浏览器上下文中直接访问 Node.js。对于将现有 Web 应用转换为桌面应用的开发者，这可以提供一种便捷方式，在无需设计单独通信层的情况下，引入文件系统访问、操作系统集成和其他原生功能。
在以下情况下，NW.js 可能是不错的选择：
- 使用现有的、基于 NW.js 的工具链构建游戏。 使用 RPG Maker MV 或维护依赖 NW.js 项目的开发者，可能没有多少理由更换框架。
- 希望直接集成 Node.js。 应用可以从在可信界面中直接访问 Node.js 功能这一点获益。
- 应用相对简单。 较小的项目可能不需要 Electron 对主进程逻辑和渲染进程逻辑进行更明确的分离。
- 项目已经使用 NW.js。 如果现有应用稳定且维护良好，迁移至 Electron 可能带来的好处很少。
- 特定 Chromium 应用 API 很重要。 NW.js 提供对受支持 Chrome API 的访问，这些 API 可能对某些应用有用。
NW.js 也仍在积极维护。其持续的 Chromium 更新表明，它仍在随着浏览器平台一起演进。
对于维护现有 NW.js 应用或游戏的开发者，切换到 Electron 需要评估架构差异、打包变化和兼容性要求。除非存在明确的技术或商业收益，否则继续使用现有框架可能更实际。
Electron 与 NW.js：该选择哪一个？
这两个框架都能用于构建跨平台桌面应用。对于新项目，选择主要取决于开发者希望如何组织代码，以及哪个生态系统最能支持其需求。
| 你的优先事项 | 更好的起点 | 原因 |
|---|---|---|
| 大型复杂桌面应用 | Electron | 成熟的架构和生态系统 |
| 主流生产力或商业软件 | Electron | 在这些类别中的采用广泛得多 |
| 长期生态系统和企业参与 | Electron | OpenJS 基金会和主要行业贡献者 |
| 使用 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 仍值得考虑。在某些使用场景下，它可以更简单，而其 Chromium 基础则提供了广泛的 Web 平台兼容性。
开发者也应记住，这两个框架都不算特别轻量。如果小应用体积和低基础资源消耗是主要关注点，那么 Tauri 等替代方案可能值得考虑。
总结
Electron 和 NW.js 的共同点多于不同点。两者都结合了 Chromium 和 Node.js，让开发者能够使用熟悉的 Web 技术构建跨平台桌面应用。两者都支持现代 JavaScript 框架、原生操作系统集成和复杂的桌面体验。
NW.js 先于 Electron 问世，在 Electron 出现之前就提出了将 Node.js 与 Web 技术结合的方式。不过，Electron 随后成为主流桌面应用中采用更广泛的框架，受益于 GitHub 最初的投入、大型科技公司的贡献，以及 OpenJS 基金会的治理。
它们的采用模式有明显不同。Electron 支撑着数百万人使用的热门生产力、通信和开发应用。NW.js 在这一市场中的可见度较低，但在独立游戏领域仍占有一席之地，包括基于 RPG Maker 的作品和近期发布的游戏。
在 WebCatalog，我们作出了与许多大型桌面软件开发商相同的框架选择。Electron 为我们提供了所需的 Chromium 一致性、浏览器管理能力、安全架构和跨平台工具，使我们能够在 macOS、Windows 和 Linux 上支持各式各样的 Web 应用。
NW.js 并未过时，它在游戏开发中的持续使用证明其仍然有用。但对于开始构建新的通用桌面应用的开发者，Electron 更广泛的生态系统、成熟的工具、企业参与和更大的社区，使其成为更实用的默认选择。
最终，更好的选择取决于应用需求、开发团队的经验，以及维护软件的长期成本。
