Claude 是一个 Electron 应用，因为我们已经失去了原生
Hacker News 摘要原标题：Claude is an Electron App because we've lost native
这篇文章讨论了为什么 Claude 选择了 Electron 架构，而不是开发原生应用。作者 Niki 针对 Drew Breunig 的观点提出了不同看法。Drew 认为是因为 AI 目前还无法完全替代人工进行细节打磨，导致原生开发的成本依然很高。但作者认为，真正的原因是原生开发已经失去了吸引力。
原生 API 的劣势
作者指出，在 API 层面，原生应用很久以前就输给了 Web 应用。原生 API 非常难用，而且操作系统厂商似乎在竭力阻碍开发者为其平台开发原生应用。这种趋势在 AI 时代之前就已经存在。如果原生开发真的有门槛，AI 本该能解决这个问题，但事实并非如此。
视觉与一致性的丧失
在 20 世纪 90 年代和 21 世纪初，原生应用曾拥有明显的优势。当时的原生界面美观且一致，用户体验极佳。然而，如今的原生界面和 Web 一样糟糕，甚至更差：
• 一致性彻底消失：现在的界面随心所欲，按钮没有边框，缺乏对比度，也没有通用的设计规范。
• 设计全凭感觉：以苹果公司为例，窗口控制按钮的位置和圆角弧度的设置似乎是凭直觉决定的，而不是遵循可衡量的准则。
• 变化过于频繁：今天按照规范打造的应用，到了明年可能就会因为苹果更改了设计风格而显得格格不入。
操作系统集成的困境
理论上，原生应用可以更深入地与操作系统集成，但在实践中，这几乎没有意义：
• 缺乏互操作系统格式：所有数据都被锁定在各个应用内部。
• 服务 Web 化：大多数服务已经迁移到了 Web 端。
• 集成难度：虽然你可以接入操作系统提供的日历，但与 Web 日历集成的难度其实更低，原生开发在这方面并没有提供任何帮助。
性能并非决定性因素
很多人渴望原生应用是因为觉得它们运行更快。作者认为，原生应用可以更快，但不代表它一定快。Web 应用同样可以运行得很快，只是在实践中，几乎没人关心性能。
例如，Slack 加载 80 MiB 的数据仅仅是为了在屏幕上显示 10 个频道名称和 3 条消息。这并不是 Web 技术本身的问题，而是一种“主动选择变差”的结果。如果一家公司不重视质量，即便把应用改用原生开发，结果也不会有任何改变。
核心问题在于缺乏匠心
作者对这种现状感到无奈。他并不觉得 Web 是完美的解决方案，只是怀念那个原生应用表现优异、能为用户带来更好体验的时代。
如果我们自欺欺人地认为软件的唯一问题是使用了 Electron，并觉得只要用 SwiftUI 重写 Slack 就能解决一切问题，那是不切实际的。真正的症结在于开发者对产品缺乏关心，以及对平庸产出（Slop）的容忍。无论使用哪种技术栈，这种心态都会导致劣质软件的诞生。