重新审视 Electron：误解与真相

重新审视 Electron：误解与真相

原文链接：Things people get wrong about Electron
作者：Felix Rieseberg
译者：倔强青铜三

前言

大家好，我是倔强青铜三。作为一名热情的软件工程师，我热衷于分享和传播 IT 技术，致力于通过我的知识和技能推动技术交流与创新，欢迎关注我，微信公众号：倔强青铜三。欢迎点赞、收藏、关注，一键三连！！！

Electron：JavaScript 与原生代码的误解

许多人认为 JavaScript 不是构建一切的正确选择，原生代码才是更好的选择，而 Electron 不是原生应用。这种误解可能源于 Electron 维护团队，尤其是我自己的早期演讲。我经常强调 Electron 能够通过 JavaScript 与操作系统交互的能力。然而，Electron 的核心优势在于它可以将 Web 应用与任何原生代码（如 C++、Objective-C 或 Rust）相结合。许多应用（包括我自己的）仅在需要使用原生 UI 组件、处理密集型任务或依赖原生库（如 SQLite）时才会使用原生代码。而像 1Password 这样的应用则几乎完全用 Rust 编写。

Electron 的理念是让开发者自由组合。虽然使用操作系统原生 UI 库编写应用在 XCode 或 Visual Studio 中可能更高效，但 Electron 的强大之处在于可以将 HTML 用于 UI，同时根据需要结合任意原生代码。为了更直观地展示这一点，我创建了一个示例仓库，展示了如何使用 Swift、Objective-C、Objective-C++ 和 C++ 在 SwiftUI、GTK 和 Win32 中实现一个简单的“待办事项”界面。

Web 应用真的不如原生应用吗？

许多人认为所有原生应用都优于 Web 应用，任何 Web 应用如果用原生代码编写会更好。这种观点虽然可以理解，但市场数据并不支持。软件已经改变了世界，而 Web 技术又改变了软件。虽然确实有许多糟糕的 Web 应用，但许多最受欢迎、最畅销、最受用户喜爱的应用正是 Web 应用。

在我看来，Web 技术是当今最成功、最灵活、最强大的 UI 技术栈。NASA 的任务控制中心、金融机构使用的 Bloomberg 终端（每年每个用户收费 25,000 美元）、麦当劳的点餐机以及 SpaceX 的 Dragon 2 舱都使用了 Web 技术。当然，Web 技术并非完美，精心设计的原生应用可以是艺术作品。然而，认为 Web 应用天生劣等，以及认为 Web 开发者只是因为懒得学习原生技术的观点，要么是无知，要么是对开发需求和用户选择的缺乏同理心。

操作系统内置 WebView 的性能优势

许多人认为 macOS、Windows 和大多数 Linux 发行版自带的 WebView 比最新版本的 Chromium 更好。在 Slack 的桌面应用最初版本中，我们尝试使用 macOS 的内置 WebView（通过 MacGap 框架），这听起来很棒（而且确实走在了时代前列）：

这些应用运行在 OS X 的 WebView 中，利用了 WebKit 技术。MacGap 提供了一个用于 OS X 集成的 JavaScript API，例如显示原生通知或写入文件。MacGap 非常轻量级且敏捷；一个空白应用的大小不到 1MB。

所有 UIWebViews 都运行在单个进程中，与 Electron 直接比较时，确实会占用更少的 CPU 和内存。然而，当运行实际的 Slack Web 应用时，用户会报告性能缓慢。无论用户想做什么，Chrome 中的体验总是更快。最终，苹果转向了 Chrome 等浏览器流行的多进程架构，并推出了 WKWebView。这种“追赶”游戏仍在继续——目前，最好的 Web 应用渲染引擎和运行时仍然在我们的顶级浏览器中。操作系统 WebView 最终可能会迎头赶上，但我还没有看到它们领先。

换句话说，我没有看到任何数据证明操作系统自带的 WebView 比 Chromium 性能更好。从直觉上讲，只要浏览器优化的资金投入最大，操作系统自带的渲染器似乎不太可能击败当前最先进的渲染代码。当然，这种情况并非不可能：苹果、微软或其他操作系统提供商最终可能会开发出超越 Chromium 的浏览器堆栈。

操作系统理论上可以在使用 WebView 的所有应用之间共享一些资源。但在实践中，出于安全原因，许多资源仍然严格隔离在各自的应用中。因此，我还没有看到任何基准测试显示，像 Gmail、Notion、Figma、Loom 或 Slack 这样的交互式应用在操作系统自带 WebView 中的性能优于最新版本的 Chromium。

但请注意：你可能会惊讶地发现，性能并不是许多 Electron 开发者选择捆绑引擎的首要原因。首要原因是让开发者能够独立于操作系统自带的 WebView 控制应用的稳定性、安全性和可靠性。操作系统自带的 WebView 与操作系统紧密耦合，因此不受开发者控制。

应用体积真的重要吗？

许多人认为用户更倾向于选择体积为 5MB 的应用，而不是 200MB 的应用。大多数 Electron 应用的体积在 100MB 到 300MB 之间。从基本原理出发，体积小当然是更好的。没有人会认为大体积应用比小体积应用更好。

但：无论是消费者还是企业用户，实际上并不关心应用体积。观看一小时 4K 分辨率的 Netflix 大约需要 7GB 的数据量，而典型的《使命召唤》更新通常超过 300GB。在实践中，我们没有看到终端用户比你的工程团队在其他任何事情上更关心二进制文件的大小。

如何“击败”Electron？

过去，我曾写过 Electron 存在的原因是因为一群热衷于构建桌面应用的人觉得他们需要一个框架来构建他们想要的应用。请注意，最终目标是构建桌面应用，而不是构建一个框架。这一点至今仍然成立。

Electron 并不是为了与任何人竞争。它是一个免费的开源社区项目，填补了一个空白。如果你想“击败”Electron，你也需要填补这个空白，并且要比 Electron 当前做得更好——在那些让我们能够提供良好体验的事情上。许多 Electron 维护者的目标是构建用户喜爱的桌面应用。如果你通过构建一个更好的平台帮助他们完成这个艰巨的任务，他们会微笑着与你握手，并感谢你。

最后感谢阅读！欢迎关注我，微信公众号：倔强青铜三。欢迎点赞、收藏、关注，一键三连！！！