在 Hacker News 或 Reddit 上待得足够久，你迟早会看到同样的批评：Electron 太臃肿，Electron 占用太多内存，真正严肃的桌面应用就应该采用原生技术。
这些批评并非毫无道理。Electron 应用通常有更大的基础资源占用，因为它们随应用一同打包了 Chromium 和 Node.js。经过精心设计的原生应用可以占用更少的内存、启动更快，并与操作系统实现更深入的集成。
但这场争论过于关注计算机，却没有充分考虑开发软件的公司。
对大多数用户来说，应用背后的技术几乎无关紧要。他们关心的是应用能不能正常工作、响应是否流畅、缺陷能否得到修复，以及是否不断有实用的新功能推出。因此，对软件公司而言，技术栈最重要的特性之一，恰恰是很少出现在性能基准表中的东西：团队能以多快的速度开发、交付、学习并改进产品？
对于许多现代桌面应用，Electron 在这方面表现得格外出色。
稀缺资源是工程时间
理想中的原生桌面软件公司拥有一支优秀的 macOS 团队，另一支团队负责开发 Windows 应用，或许还有一支团队支持 Linux。每个应用都针对各自的平台做了精细优化，每位工程师都深入了解自己所面对的操作系统。
大多数公司没有这样的奢侈条件。
一款桌面产品可能只有五名工程师，也可能只有两名。同样是这些工程师，需要开发功能、修复缺陷、提升性能、回应客户、维护基础设施、应对操作系统变化，并持续推动产品向前发展。
原生开发让这些工作变得更加困难，因为 macOS、Windows 和 Linux 确实是不同的平台。它们拥有不同的 UI 框架、API、权限系统、生命周期行为、安装程序、更新机制、通知系统、窗口管理方式、无障碍 API，以及多年来积累的平台特有问题。
Electron 改变了这笔账。它将 Chromium、Node.js 和桌面 API 结合起来，在 macOS、Windows 和 Linux 上提供统一的应用模型。同一位 TypeScript 工程师往往就能完成一个功能从界面到应用逻辑的开发，并将其发布到所有桌面平台。在真正需要时，仍然可以使用原生代码，但原生代码变成了例外，而不再是产品的基础。Electron 自己也将这一点列为核心优势之一：用一套 JavaScript 代码库覆盖三大桌面平台。
这种差异会随着时间不断累积。如果每个重要功能都需要分别为 Mac 和 Windows 实现，公司就得反复支付这笔“平台税”：每一次功能开发、重新设计、实验、缺陷修复、无障碍改进和性能优化，都不例外。
使用 Electron，这些工作中的很大一部分只需做一次。
Electron 优化的是迭代速度
产品很少因为第一次实现就完美无缺而变得优秀。优秀的产品来自不断迭代。
团队发布一些东西。客户开始使用。团队从中学习。随后调整功能。更多人开始使用。另一个问题浮出水面。团队再次改进。
从想法、实现、反馈到改进的循环越短，产品进步得就越快。
Electron 尤其擅长缩短这个循环，因为它围绕软件公司早已广泛使用的技术构建：JavaScript、TypeScript、HTML、CSS、React、Chromium、Node.js 和 npm。
这意味着公司能够共享的远不止源代码。它们可以在 Web 产品和桌面产品之间共享工程师、UI 组件、工具链、库、基础设施、测试方法，以及组织内部积累的知识。
前端工程师不会因为公司需要有人支援 Windows 客户端，就突然派不上用场。桌面工程师可以参与 Web 应用的开发。全栈 TypeScript 工程师则可以随着优先级的变化，在不同产品之间切换。
对于中小型公司而言，这种灵活性的价值，可能远远超过节省 100 MB 内存。
看看究竟是谁在使用 Electron
Electron 有时被描述为一种捷径，供那些不愿投资开发“像样”桌面应用的公司使用。但用它构建的产品，让这种说法越来越难以成立。
Electron 官方项目重点展示了 Slack、Discord、Signal、ChatGPT、Claude、Visual Studio Code、Notion、Docker、Loom 和 Canva 等产品。这些并不是简单的小工具。其中许多都是世界上功能最复杂、使用最广泛的生产力应用。
Visual Studio Code 是一个尤其值得参考的例子。微软几乎可以用任何它想用的 Windows 技术来构建自己的旗舰代码编辑器，但 VS Code 在 Windows、macOS 和 Linux 上都采用了 Electron。它包含终端、调试、语言服务器、Git 集成、远程开发、笔记本、扩展，以及高度定制化的编辑器。
值得探讨的问题并不是微软能否通过开发三个独立的原生版本来节省内存。当然可以。
更好的问题是：如果每项主要能力都需要分别实现多个版本，VS Code 还能否发展得如此迅速、在各平台间保持如此一致，并形成如此庞大的生态系统？
ChatGPT 和 Claude 展现了不同路线的差异
ChatGPT 和 Claude 之间的对比也很有启发性。
OpenAI 最初为 ChatGPT 构建了一款专门的 macOS 原生应用。相比之下，Anthropic 基于 Electron 构建了 Claude Desktop，从一开始就拥有跨平台共享的桌面应用基础。
随着产品不断扩展，这种差异变得更加重要。Claude Desktop 可以在同一款跨平台应用中，持续加入 MCP 集成、扩展和 Claude Code 等能力。如今，Anthropic 已支持直接在桌面体验中使用 Claude Code，包括多个本地和远程会话。
后来，OpenAI 也将其新的跨平台桌面路线转向了 Electron。如今，Electron 已将 ChatGPT 和 Claude 都列为知名的 Electron 应用。
如果说仅凭 Electron 就能解释产品迭代速度的差异，那就言过其实了。团队规模、优先级、产品策略和内部组织方式都很重要。但架构上的优势很明确：共享的跨平台基础，让团队更容易在不同操作系统上交付功能，而不必维护彼此独立的实现。
这正是一种会随着桌面产品成长而变得更有价值的优势。
Evernote 体会到了维护多个独立客户端的成本
Evernote 是这一问题最鲜明的历史案例之一。
多年来，Evernote 为 Mac、Windows、移动端和 Web 维护着不同的应用。随着时间推移，这些产品逐渐积累了不同的行为、渲染差异、历史遗留的设计假设和同步问题。
2020 年，Evernote 基于共享代码库重新构建了 Windows 和 Mac 应用。该公司表示，新的基础将使应用更加稳定，加快缺陷修复，让功能发布更频繁，并改善跨平台同步。
这次迁移并非一帆风顺，一些老用户也不喜欢最初失去平台特有功能的情况。但比迁移问题本身更值得关注的，是 Evernote 为什么要进行如此昂贵的重写。
当一款产品拥有功能丰富的编辑器、离线存储、搜索、附件、协作、任务、日历和复杂的同步机制时，维护多个独立实现就会变得越来越昂贵。缺陷表现不同，渲染结果不同，同步逻辑还要与不同的本地架构交互。每一次重要的产品变更，都必须落实到多个客户端中。
共享架构不会让难题消失。但它能让公司只需解决一次的问题变得更多。
Linux 可能是 Electron 最被低估的优势
Linux 让采用 Electron 的理由更加充分。
要妥善支持 Linux 并不容易。与 macOS 或 Windows 不同，“Linux 桌面”不是一个受到严格统一控制的平台。开发者必须应对不同的发行版、软件包格式、桌面环境、图形栈、系统库和显示协议。
对于许多软件公司而言，理性的商业决策可能就是不支持 Linux。
Electron 改变了其中的经济账。
由于 Electron 在 macOS、Windows 和 Linux 上提供统一的运行时，添加 Linux 支持可以比维护独立的原生 Linux 实现容易得多。这也是如今 Linux 用户能够使用许多主流桌面应用的原因之一；在过去，这些应用可能根本不会推出官方 Linux 客户端。
Visual Studio Code、Slack、Discord、Signal、1Password、Postman、Obsidian 以及许多其他工具，都可以在不维护完全独立的 GTK 或 Qt 应用的情况下支持 Linux。
Electron 还替应用开发者承担了大量 Linux 特有的复杂性。从 X11 向 Wayland 的迁移就是一个很好的例子。Electron 的维护者曾介绍，Chromium 向 Wayland 的迁移实际上也带动了 Electron 应用一起迁移，减少了每个应用团队需要独立完成的显示栈工作。
没有 Electron 这样的框架，许多公司并不会去开发原生 Linux 客户端。它们只会支持 macOS 和 Windows，让 Linux 用户只能在浏览器标签页里使用产品。
Electron 对商业 Linux 桌面软件的贡献，很可能比人们认可的要大得多。
就连微软也越来越多地选择 Web 技术
对于“严肃的 Windows 软件应当始终采用 Windows 原生 UI 框架”这一观点，微软或许是最有力的反例。
微软掌控 Windows，也掌控 Win32、.NET、WinUI、WebView2，以及开发者所依赖的平台中的很大一部分。如果完全原生的 Windows 开发始终是显而易见的答案，那么微软理应最有条件在所有地方采用它。
但它并没有这样做。
Visual Studio Code 使用 Electron。即便微软用经过更充分优化的 WebView2 宿主替换了 Electron，Teams 仍然围绕 React、TypeScript 和 Chromium 构建。新版 Windows Outlook 也大量依赖 Web 技术，微软明确表示，这种架构可以提升敏捷性、加快功能交付，并创造更加一致的体验。
Teams 尤其值得借鉴。微软希望提升性能、减少资源消耗，因此调整了架构。但它并没有把 UI 重写成传统的 Windows 原生应用。
它保留了 Web 技术栈，并围绕它进行优化。
这个区别很重要。微软认为，即使要大力改进性能，React、TypeScript 和 Chromium 在组织层面带来的优势仍然值得保留。
这里还有另一个启示。多年来，微软自己推出过许多代 Windows 应用技术：Win32、WPF、UWP、WinUI 等等。一家公司选择“Windows 原生开发”，并不一定是在选择一个经久不变的平台。很多时候，它是在押注某一代微软偏好的框架。
颇具讽刺意味的是，Web 平台反而已经成为较为稳定的应用目标平台之一。
招聘也是架构的一部分
框架选择也决定了你能招聘哪些人。
JavaScript 和 TypeScript 开发者构成了行业中规模最大的人才群体之一。采用 Electron 的公司可以从这一人才池中招聘，而不必分别组建经验丰富的 macOS、Windows 和 Linux 专家团队。
原生开发专家依然很有价值。成熟的桌面产品仍然需要深入理解操作系统的工程师。但 Electron 改变了你需要多少这样的专家。
你不必要求应用的大部分代码都由平台专家编写，而是可以保留相对少量的原生集成代码，让团队中的大多数人专注于共享的产品开发。
如果公司已经拥有 Web 应用，这一点就更加重要。React 组件有时可以共享，TypeScript 库可以复用，产品逻辑可以在 Web 端和桌面端之间迁移。工程师也可以在团队之间切换，而不必学习一个完全不同的生态系统。
招聘也会变得不那么脆弱。如果唯一深入了解原生 Windows 客户端的工程师离职，要找到能接替这种专业能力的人可能很困难。采用 Electron 后，代码库中会有更多部分使用组织内其他成员所熟悉的技术。
因此，框架不仅决定界面如何渲染，还会影响工程组织本身的构建方式。
原生并不自动意味着更好的软件
开发者经常把“原生”几乎当作“快速”的同义词。
但事实并非如此。
原生 API 为开发者提供了打造高效应用的机会。最终产品能否真正做到这一点，取决于架构、团队、预算，以及公司能够投入多少优化工作。
原生应用同样可能运行缓慢、缺陷频出、占用大量内存、表现不一致，或者维护不善。
更重要的是，把人数有限的团队分散到多个原生实现上，意味着每个实现分到的工程时间都会减少。
假设一家公司有六名工程师可以投入桌面产品开发。一种选择是将他们分到 Mac 和 Windows 两个方向，或许放弃支持 Linux。另一种选择则是让几乎全部六名工程师，共同开发一款服务于三个平台的 Electron 应用。
哪种方式能让公司拥有更多工程能力，用于缩短启动时间、修复内存泄漏、打磨交互、改善无障碍体验、减少崩溃，以及回应用户需求？
并不能想当然地认为，原生应用最终会带来更好的产品。
这形成了一个有趣的悖论：一个消耗略多机器资源的框架，可能让公司打造出优化得更好的产品，因为它消耗的工程资源少得多。
Electron 提供了一个可控的平台
Electron 还有一个容易被忽视的优势：它会随应用一起提供开发和测试时所使用的 Chromium 运行时。
这消除了跨平台开发中的一个重要变量。
基于操作系统 WebView 的框架可以让应用体积更小，但代价是，同一套前端在 Windows 上可能运行于 WebView2，在 macOS 上运行于 WKWebView，在 Linux 上运行于 WebKitGTK。这些引擎有着不同的能力、缺陷、发布节奏和渲染行为。
Electron 做了另一种取舍：将运行时打包进应用，让它成为应用的一部分。
没错，这会占用磁盘空间。
但它为开发者提供了一个在三种差异很大的操作系统上更加一致的目标环境。
一致性具有巨大的工程价值。
当 Electron 不够用时，你仍然可以采用原生技术
选择 Electron，并不意味着放弃使用原生能力。
Electron 应用可以在必要时使用原生模块和平台专属代码。这意味着，架构选择实际上并不是：
100% 原生或 100% JavaScript。
对许多产品而言，更好的模式是：
应用的大部分代码共享，仅在操作系统确实要求的地方使用少量原生代码。
原生代码成为一种兜底手段，而不是整个产品的基础。
对许多公司来说，这是一种更合理的工程投入分配方式。
用户关心的是产品，而不是框架
有一小部分精通技术的用户会打开“活动监视器”，注意到多个 Chromium 进程，然后立刻抱怨某款应用使用了 Electron。
大多数用户不会这样做。
他们不在意 Slack 使用 Electron，不在意 VS Code 是用 Web 技术构建的，也不知道 Claude 使用什么框架。他们关心的是，软件能否帮助自己完成工作。
如果一款应用启动足够快、响应流畅、很少崩溃，并能解决用户的问题，那么它的实现技术基本上是不可见的。
反过来也一样。原生应用不会因为使用了 Swift 或 WinUI，就自动成为优秀的产品。
软件的竞争发生在产品层面，而不是框架层面。
优化公司，而不只是优化二进制文件
Electron 确实有成本。它占用更多磁盘空间，基础内存占用通常也高于小型原生应用。确实有一些产品，会因为这些成本而不适合选择 Electron。
一个小小的菜单栏工具大概不需要 Chromium，设备驱动程序当然更不需要。游戏、专业音频软件和对延迟极其敏感的应用，有着不同的要求。而如果你的产品永远只在一种操作系统上运行，那么选择原生开发就更容易说得通。
但现代桌面软件中，有很大一部分并不属于这些类别。
它们是连接云服务的复杂界面，需要运行在 Windows 和 macOS 上，而且越来越多的用户也期待 Linux 支持。它们需要持续演进，要与每周都在发布新变化的产品竞争，并且通常由工程师人数有限的公司开发。
对于这些产品，开发者生产力也是应用性能的一部分。
Electron 让公司能够从大得多的人才池中招聘，在 Web 端和桌面端之间共享工程师，维护一个主要应用而不是多个应用，复用 JavaScript 生态系统，更一致地向各个操作系统交付功能，以原本往往难以证明合理的成本支持 Linux，并把更多工程时间用于改进产品，而不是维护多套并行实现。
你很容易用兆字节来衡量 Electron 的成本。
其他方案的成本则更难看见。它们表现为额外的工程师、重复的实现、更长的发布周期、平台特有的缺陷、招聘困难、组织壁垒、无法获得支持的 Linux 用户，以及需要再等数月才能覆盖所有用户的功能。
这些成本不会出现在“活动监视器”里。
但对于开发软件的公司而言，它们可能大得多。
软件开发的目标，不是生成最小的二进制文件。
而是打造你的组织能够交付、维护并持续改进的最佳产品。
对于数量多得令人惊讶的一大类桌面应用，Electron 仍然是实现这一目标最高效的方式之一。