原文：http://tangiblejs.com/posts/nw-js-electron-compared
如果你希望基于 Web 技术创建一个本地桌面应用，再开源社区中有两个选择：NW.js（原 node-webkit）和 Electron（原 atom-shell）。这两者如何选择并不显而易见。这就是我创建本文对两者进行细致比较的原因。希望这对你选择合适的工具构建你的新应用有帮助。
本文是基于2016年发布的版本比较的，我鼓励你自己进行进一步的比较而不仅依赖于此文。
现阶段，图表(和本文)还在完善中，并需要来自社区的帮助。由于我使用 NW.js 比 Electron 更多，此文可能会收到我自身的偏好影响。请（恭敬的）留下您的意见、建议和更正以改进此文。除了图表外，我还将编辑一份可能影响用户第一次选择的其他关键差异列表。再次欢迎您的输入。
图表
| NW.js 0.12.3 | Electron 0.34.1 | |
|---|---|---|
| Project inception (项目始于) | 2011 | 2013 |
| Sponsor (发起者) | Intel | GitHub |
| Platform Support （支持平台） | Mac, Linux & Windows | |
| Browser Runtime (浏览器运行时) | Chromium | libchromiumcontent |
| Layout Engine (布局引擎) | Blink / WebKit 537 | WebKit 537 |
| Javascript Engine (Javascript引擎) | io.js v1.2.0 | io.js v? |
| ES6/2015 Support | ||
| (支持 ES6/2015) | Yes (all from V8 v4.1) | Yes (all from V8 v4.4) |
| Chrome-Equivalent version | ||
| (Chrome 等效版本) | 41 | 44 |
| Development Model (发展模式) | Open Source | |
| Licensing | MIT License | |
| Entry Point (入口文件) | HTML or JavaScript | JavaScript |
| Bare Distribution Size | ||
| (裸分配大小) | 75MB - 100MB4 | |
| (30MB - 34MB zipped) | To confirm. | |
| Anybody? | ||
| Chrome Apps Support | ||
| (Chrome 扩展程序支持) | Yes (in beta) | No |
| Support of chrome.* APIs | ||
| (是否支持 chrome.* 接口) | Yes (in beta) | No |
| Mac App Store Support | ||
| (Mac 应用市场支持) | Yes | |
| Windows App Store Support XP | ||
| (Windows 应用市场支持XP) | Yes | No |
| Source Code Protection | ||
| (源码保护) | V8 Snapshort1 | ASAR Archive Support2 |
| Auto-update (自动更新) | Mac/Linux/Win(module) | Mac/Win(thru Squirrel) |
| Kiosk Mode | Partial(Buggy on Mac6) | |
| Windows Installer | Throuth nw-builder | Yes(external moudle) |
| html5test.com Score3 | 515 | 520 |
| BrowserMark 2.1 Score3 | 5294 | 5643 |
| Octane 2.0 Score3 | 27619 | 28346 |
| GitHubTrends | ||
| Open Codecs/Containers | Vorbis, Theora, Opus, VP8, VP9, PCM, Ogg, WebM, WAV | |
| Licensed Codecs: MP3, Mp4, H.264, AAC | Yes（with some effort） | Yes |
- 这导致 30% 的性能受到冲击。尚不清楚 0.13 版是否支持这项建议。
- 这是一个弱保护，它对所有项目文件进行 TAR 存档。
- 在 MacBook Pro Retina 运行 Mac OS X.5.5 (Yosemite) 版本越高越好。
- 解压。取决于平台和架构。请参阅下面 Jared 的评论。
- 这可以通过在 package.json 文件中使用“node-main”指令完成，或通过 Chrome 的 mainfest 文件清单(版本 0.13 及以上)完成。
- Kiosk 模式需由 Chromium 在上游启动。如果你希望 Chromium 团队在 Mac 上引入此模式，请投票支持。
其他比较因素
范式
这有点过于简单，但从广义上讲，NW.js 的范式更接近于浏览器。它基于加载特定的 HTML 页面，该页面可获得 Node.js 的上下文。如果打开多个窗口，那么他们共享 Node.js 上下文。这意味着可以从所有开发窗口的 DOM 直接访问它。
随着 NW.js 0.13版本对 Chrome 应用的支持，将有可能使用 amanifest.json 文件的形式指定 javascript 文件在Chrome 应用文档中描述。
另一方面，Electron 有更多 Node.js 相关方法。它从 Node.js 开始运行，可以打开窗口，然后加载页面。更专业的讲，这意味着 NW.js 团队需要在 Chromium 代码中插入一些钩子，以实现嵌入 Node.js 环境中。虽然这需要 NW.js 的开发人员付出更多的努力，但这意味着浏览器和 Node 环境交互更为无缝。
Electron 的工作方式更为不同。启动主进程，再由主进程发起渲染进程打开窗口。这意味着，windows 之间或主进程与渲染进程之间的通信更加困难。
举个例子，尝试修改一个在窗口（渲染进程）中呈现的菜单（在主进程中创建）代码。实现这点，需要通过 IPC 通信进行数据编组。另一点，Electron 不会像 NW.js 一样在关闭最后一个窗口时自动退出。它需要开发人员监听 window 事件，在需要时退出。我想这可能是有用的，也可能是无用，取决于你的需要。
跟踪记录
Electron 在这个领域是较新的，但是已经有很多应用使用它来创建。NW.js 存在的时间更长，据我所知他被用于更多的项目中。需要注意的是，NW.js 由于集成 Chrome 应用 API 处于一个过渡期，但随着 0.13 版本的发布就会回归正常。
法律问题
在这两个环境中使用许可的编解码器和 demuxers /容器，感觉像一个灰色区域。这种不确定性主要来源于 FFmpeg 的许可条款和 H.264 专利。FFmpeg 是一个开源项目，用于编码/解码各种音频和视频格式。默认情况下，Chromium（与 NW.js 和 Electron 同时使用）包含一个 FFmpeg 的版本，其编译方式使其符合 LGPL 许可证。这意味着它可以用于开源和专用/商业项目。
在 Electron 中，FFmpeg 库是静态链接的。在 NW.js 中不是。这表明 Electron 提供了更广泛的编解码器支持；另外在 NW.js 中，需要手动链接到 FFmpeg。
因此，使用 vanilla Electron 发布，你不用担心许可问题。同样的，如果你将 NW.js 链接到使用默认选项（没有使用 —enable-non-free 或 —enable-gpl 选项）编译的 FFmpeg 版本，那么你也应该安全。
然而，一些编解码器/格式可能需要支付版税。这超出了本文讨论的范围。
其他竞争者
另一个有趣的选择是 Tint2。如果有机会，我会写一篇后续比较文章，包含 Tint2。以下是作者对它的描述：
Tint 允许程序员使用 JavaScript 创建左面应用，利用节点运行时直接访问本地的“Objective-C 对象”和“.NET/COM 对象”，或使用 Tint 内置应用对象模型 和 API来规范不同操作系统的GUI组件。他是一个轻量级的节点运行时，集成了目标操作系统的应用程序循环，并安全地公开了构建应用程序所需的本机 OS 对象。
这看起来很有趣，但是我还未使用过它，在写一些关于它的内容之前，我将尝试使用它并收集用户的反馈意见。如果您是 Tint 2 的用户，你可以在下面的评论区进行反馈。请注意，Tint（包括 Electron 和 NW.js）不支持Linux。
总结
现阶段很难给出最终结论，但目前收到的大多数评论倾向于 NW.js。选择 NW.js 的原因是：更长的追踪记录，整体开发理念，跨平台自动更新和 Windows XP 支持。本模块会随着收到的反馈意见的增多而做调整改进。Electron 的粉丝们在哪里？我知道你们在某个地方……
译者有话说： 从目前的社区环境来看 Electron 会更好些，github 上的 Star / Watch / Fork / Commit 数量都远超 NW.js
若有收获，就点个赞吧
0 人点赞
