Claude 为何选择 Electron：原生开发的衰落

在《Claude 为什么是 Electron 应用？》一文中，Drew Breunig 提出了一个疑问：

Claude 花了 $20k 用一个 agent swarm（某种程度上）实现了一个 C 编译器，但桌面版 Claude 却是 Electron 应用。

既然代码是免费的，为什么不是所有应用都是原生的呢？

他接着论证，答案是 LLM 还不够强大。它们能完成 90% 的工作，但仍需要大量的手动打磨，因此成本会增加。

但我认为这不是真正的原因。真正的原因是：原生开发已经没有什么优势可言了。

从 API 的角度来看，原生应用早就输给了网络应用。原生 API 使用体验很差，而且操作系统厂商尽一切努力让你不想为他们的平台开发原生应用。这解释了 LLM 时代之前 Electron 的兴起，但这也是 LLM 现在解决的问题：如果那曾是开发原生应用的真实障碍，它现在已经不存在了。

然后是界面外观和一致性。很久以前，可能是在 90 年代末和 2000 年代，原生应用处于领先地位。那时它看起来不错，具有一致性，并且一切都能正常工作：应用使用原生外观和感觉的越多，整个应用生态的用户体验就越好（我们曾经称之为软件程序）。

但现在，原生应用和网络应用一样糟糕，甚至更糟。一致性基本上已经消失无踪。任何东西都可以看起来像任何东西，按钮没有边框，对比度不存在，约定俗成的设计规范也不存在。例如，苹果似乎是凭感觉而不是按照任何可测量的指南来放置窗口控制按钮和圆角的。

外观可能很好，也可能很糟糕，而如果很糟糕，你就被困在了平台一致但整体糟糕的 UI 中（液态玻璃设计，呃）。而且变化太频繁：你今天开发的应用在明年看起来就会显得格格不入，因为苹果又决定改变外观和感受了。再也没有真正的原生外观了。

理论上，原生应用可以与操作系统进行更深层的整合。这听起来不错，但实际上意味着什么呢？几乎没有良好的可互操作文件格式；一切都被锁在各个应用内部，大多数服务都迁移到了网络上，而操作系统在建立良好的共享基线方面失职了。你可以与操作系统提供的日历整合，但对于网络日历你做不到。好吧，当然你可以做到，但在网络上更容易；原生开发对此毫无帮助。

最后，渴望原生应用的人们最后的希望是性能。他们认为原生应用会更快。好吧，它们可能会，但不一定就是这样。网络应用也可以更快，但实际上，没有人在乎。没有任何技术原因能解释为什么 Slack 需要加载 80 MiB 来在屏幕上显示 10 个频道名称和 3 条消息。网络不是问题所在！这是一种选择变差的决定。你凭什么认为一旦公司决定迁移到原生应用，情况就会不同呢？

别误会我：写这篇文章给我带不来快乐。我也不认为网络应用是解决方案。我只是怀念那些美好的时光，那时原生应用的表现超过了平均水平，我们也因此获益，但如今这样的时光已经一去不复返了，这让我感到难过。

我不认为我们自欺欺人地声称软件的唯一问题是 Electron，然后相信一旦用 SwiftUI 重写 Slack 就会变成完美无缺的美好世界——这样的想法没有建设性。真正的问题在于缺乏用心。还有代码质量问题；你用任何技术栈都能做出垃圾。

2026 年 3 月 3 日·在 Hacker News 和 Lobsters 上讨论