10年了，开发人员仍然不明白 Electron 的意义

摘要：在现代开发人员的工具箱中，Electron 是最有名的工具之一。如果你仔细观察，就会发现它是 React Native 的表兄弟，承诺 “一次编写、随处发布”，但构建和发布开销远小于移动开发。它的杀手锏是将 Node.js 和 Chromium 捆绑在一起，为

作者 | Greg Foster

译者 | 平川

策划 | 褚杏娟

本文最初发布于 Greg Foster 的个人博客 Small Diffs。

在现代开发人员的工具箱中，Electron 是最有名的工具之一。如果你仔细观察，就会发现它是 React Native 的表兄弟，承诺 “一次编写、随处发布”，但构建和发布开销远小于移动开发。它的杀手锏是将 Node.js 和 Chromium 捆绑在一起，为 Web 技术创建了一个强大的桌面运行时。Electron 官方博客庆祝了它的 10 周年纪念日，考虑到它对开发文化的渗透之深，这真是太激动人心了。

到 20 世纪 20 年代中期，我们已经达到了这样一个阶段：大多数新软件都是从网站（采用典型的 HTML/JS 堆栈）开始，然后扩展到桌面，为的是可以获得更好的人体工学设计 —— 无论是直接的 dock 图标，更简单的 OS 级集成，还是更集中的工作区。ChatGPT 和 Perplexity 等工具遵循了这一模式，尽管它们并不一定会引入 Electron。不过，对于许多希望快速打包应用的团队来说，Electron 提供了近乎即时的跨平台支持，并且具有令人垂涎的 “ Web 风格 ”，如自动更新和零阻力发布。

当 Graphite 公司的工程团队需要一个轻量级的桌面扩展时，我们也是立刻选择了 Electron——尤其是当我们看到它的自动更新功能时。但我经常在想：对于这样一个具有统治地位的框架，它究竟从何而来？答案出人意料——它是 GitHub 创建的。

前 Electron 时代

Electron 的历史只能追溯到 2013 年，并不算久远。在使用桌面封装器发布 Web 应用程序之前，开发人员通常会为每个平台编写完全独立的本地应用程序。想要支持 Mac？编写 Objective-C 或 Swift ，然后使用 Cocoa。想要 Windows 支持？那就挽起袖子写 C++、C# 或 .NET 。Linux ？那就更有趣了。每个平台都有不同的用户界面范式、代码习惯用法和构建管道，因此，保持一致性是个令人头疼的问题。许多团队最终需要维护两到三个代码库，每个代码库都有自己细微的差别。

一些跨平台工具包，如 Qt 或 JavaFX，提供了部分解决方案，但往往有一个复杂的集成层、 UX 体验不一致，偶尔还会出现性能不佳的情况。与此同时，依赖 JVM 的 Java 虽然功能强大，但对于面向消费者的桌面应用程序来说，它从来都没有提供过特别丝滑的体验。当然，它可以让你 “一次编写，随处运行”，但并不是每个人都想用 Swing 或 JavaFX 来构建现代用户界面。而且，如果你需要将应用程序发布到 Web 上，JVM 也帮不上忙。

因此，如果回到，比如说 2010 年，构建跨平台桌面应用程序的感觉往往就像在两英尺深的雪地里艰难前行。

Electron 是如何出现的？

进入 2013 年：Electron（最初名为 Atom Shell ）由 GitHub 工程师 Cheng Zhao 创建。这并不是什么利他主义的开源礼物 ——相反，它是作为 Atom 编辑器的基础。这是 GitHub 新推出的一个 “可删节的（ hackable ） ”文本编辑器，依赖于 Web 技术（HTML、CSS、JS），但需要在桌面上运行。从一开始，GitHub 就资助并培育了这个框架。因此，Electron 很快就从实际测试、持续的开发反馈和庞大的用户群（即 Atom 社区）中受益了。

具有讽刺意味的是，虽然 Atom 本身已被 Visual Studio Code 的光芒所掩盖，但其底层框架却日益强大，变得更具通用性。几年内，“Atom Shell ”更名为 Electron，并于 2016 年发布了 1.0 版本。当时，Slack 和 GitKraken 等公司已经在使用它。然后发生了一件大事：微软在 Electron 的基础上推出了 VSCode。仅凭这一点，许多企业团队就认可了 Electron。

Electron 的关键技术选择

Electron 真正的突破性在于同时嵌入了 Node.js 和 Chromium。这样，JavaScript 就能直接与本地操作系统的功能进行通信，同时呈现基于浏览器的用户界面 —— 对于许多 Web 开发人员来说，这是个不可抗拒的组合。多进程架构大致以 Chromium 为蓝本：

主进程：处理应用程序级问题，如创建窗口、连接 OS 级 API 以及管理整个生命周期。实际上，它是 Electron 的 “大脑”。

渲染器进程：每个窗口或“视图”都在自己的进程中运行，渲染 HTML、CSS 和 JavaScript。渲染器崩溃不一定会导致整个应用程序瘫痪，因此，这种隔离增强了稳定性。

自动更新器：Electron 内置的自动更新模块。人们很容易忘记，在原生软件中，自动更新历来也都不是一件容易的事。有了 Electron，你可以轻而易举地获得自动更新功能，对频繁发布补丁或增量的新功能来说，这可是一个重大利好。

这种结构意味着，以前端开发为主的团队可以轻松地推出桌面版 Web 应用程序。这也正是许多初创公司倚重 Electron 的原因：上市时间通常比内存占用更重要。

开发者抱怨：

Electron 臃肿而冗余

Electron 一直饱受批评，尤其是在臃肿方面。每个 Electron 应用程序都绑定了自己的 Chromium 实例。因此，如果你同时打开了 Slack、VSCode 和 Discord，就相当于并行运行了三个 Chrome 浏览器。这会导致大量的内存占用以及应用程序二进制文件过大。在 Electron 中，一个微不足道的“ Hello, world ”就可能超过 100MB 。在一些纯粹主义者看来，这简直是骇人听闻。

在早期，Electron 也有一些稳定性方面的小问题。如果渲染器崩溃，用户偶尔会遇到 “白屏死机”的情况。最终，社区解决了这些问题，现在的 Electron 已经变得更加强大。尽管如此，对于优先考虑性能和资源占用的团队来说，Electron 的开销还是会让他们望而却步。

从安全角度来看，Electron 应用程序通常不会像现代浏览器标签页那样被置于沙盒中。一个不道德的依赖关系或一个不安全加载的脚本，都可能让攻击者更深入地访问操作系统。因此，对待 Electron 开发，必须持和对待本地应用程序安全一样的严谨态度：启用上下文隔离、限制远程代码执行、谨慎使用软件包等等。这并非无法克服，只需要严守纪律。

有趣的是，一些有雄厚资金支持的应用明确避开了 Electron。ChatGPT 就是最近最好的例子：鉴于 OpenAI 拥有足够的工程带宽，他们为 Windows、macOS、iOS 等平台开发了原生客户端。有人猜测，他们想要的是深度集成的体验或更好的性能（实事求是地说，如果你的应用名称中包含 “ AI ”，你很可能会想着不要浪费周期）。不过，对一个小团队来说，这个要求很高。我们中的大多数人都没有足够的资源来构建和维护多个原生实现。因此，Electron 仍然很受欢迎。

Tauri 与未来

多年来，Electron 从根本上降低了开发桌面软件的门槛。突然之间，曾经局限于 Web 技术的开发人员可以将他们的工作打包成一个原生感十足的应用程序了，而且不需要单独的代码库。这种方法激发了新的思路和快速原型，为桌面软件带来了新的声音，并引发了一波工具浪潮，如 Atom、Slack 和 VSCode 。如果要在三个平台上构建这些工具的原生版本，那么成本可能太高。在我看来，Electron 的真正成功在于，它将 “让我们做一个桌面客户端 ”从一个可怕的、专业的工作变成了一个可行的周末项目。

当然，并不是每个人都能接受为每个应用程序提供一个完整的 Chromium 实例所带来的内存开销或成本。为此，Tauri 等框架应运而生，解决了这些痛点。例如，Tauri 依赖于操作系统的原生 webview，而不是捆绑自己的浏览器引擎。在某些情况下，仅这一点就能将一个基本应用的大小从 100 MB 以上缩小到 1 MB 以下。它的后端是用 Rust 编写的，这样既能提高性能，又能保证内存安全，而且还能对应用程序可以访问的 OS 级功能施加更明确的限制。对于重视安全性或无法忍受内存占用过大的团队，这很有吸引力。Tauri 还不是很成熟，但它预示着一个引人入胜的未来：“桌面 Web 技术 ”的便利性与更小的二进制文件和更高效的资源利用可以兼得。