太多 Mac 应用是用 Electron 构建的

Electron 的用途与取舍

• 许多人认为 Electron 是可以接受的，甚至是必不可少的：它能让跨平台应用和网页版本共享代码，尤其适合初创公司和 VC 资助的公司。
• 常见的说法是三者取二：低价格、功能一致性、性能。对于 Slack、Discord、Spotify、WhatsApp 这类应用，用户和企业大多选择了价格 + 一致性，而不是性能。
• 也有人反驳说，这种“够用就好”的心态会使臃肿和糟糕的 UX 常态化，迫使用户购买越来越快的机器来跟上。

原生开发 vs 跨平台开发

• 原生 Mac 应用被称赞为更快、更轻、更能与系统整合（BBEdit、iTerm、Transmit、Telegram 原生客户端）。
• 但为每个平台分别构建并维护原生应用，被描述为成本极高且组织上很复杂；Apple 上的平台更迭（Toolbox/Carbon/AppKit/SwiftUI，Objective-C/Swift）让问题更严重。
• 还提到了一些替代工具包（Qt、wxWidgets、QML、Avalonia、Flutter、Godot）作为“中间地带”，有人认为它们可以看起来现代且效率很高，也有人说它们依然“只是没那么糟”，但还是不如 Electron。

性能、资源占用与 UX

• 轶事从 WhatsApp 在较新的 Mac 上约 1 秒启动，到同步大型历史记录需要 16 秒或几分钟不等。有人归咎于应用本身，也有人归咎于硬件或配置。
• Electron 因多进程开销以及较高的 RAM/CPU 占用而受到批评；反方指出，有些原生应用同样很重，而且 Electron 本身并不总是瓶颈。
• 例子包括：新版 Teams 被认为极其缓慢；Slack 和 Outlook 被视为尚可；Apple Music 则因卡顿、Bug 多而受到批评，相比之下基于 Electron 的 Spotify 反而更好。

浏览器标签页、PWA，以及“直接用网页就好”

• 有些人更喜欢在浏览器标签页里运行 Slack/WhatsApp 之类的服务，因为可以用扩展、标签式工作流，并避免安装数百 MB 的应用。
• 另一些人则重视桌面应用的 Dock 图标、Cmd-Tab 切换、系统级应用管理、角标和通知。
• PWA 方面意见分裂：概念受到喜欢，但有人认为它削弱了用户可控的浏览器环境，并获取了独占 API。Firefox 放弃 PWA 支持也被带着失望提起。

经济性与商业激励

• 多条评论强调，Electron 应用往往是在与“根本不存在”的东西竞争，尤其是在 macOS 和 Linux 上。
• 协调并行的原生团队、保持功能一致性以及处理平台差异，被描绘成相比单一 Electron/Web 技术栈要高得多的开销。
• 有人建议 Apple 可以通过让 Swift/SwiftUI 更跨平台来缓解这一点，但也怀疑 Apple 不会这么做。

API 与第三方原生客户端

• 一种观点是：服务根本不应该发布原生应用；它们应该提供完整 API，让独立开发者去构建原生客户端。
• 历史例子是 Twitter 的第三方应用生态在公司收紧限制之前曾繁荣发展。
• 反对意见是：这种封装型应用很“无聊”，难以大规模变现，而且当平台更改认证规则或封禁非官方客户端时就可能被击垮。一个停运的轻量 Slack/Discord 客户端被提及为经济性和平台政策双重作用下的牺牲品。

对文章和 Apple 的批评

• 有些人认为这篇文章带有偏见，属于“Mac 原生吹捧”，尤其因为它托管在一个仅面向 Mac 的应用博客上，并且把本地文本编辑器与一个富互联网同步的即时通讯工具作比较。
• 也有人指责 Apple 的机器价格过高、内存偏少，使用户对臃肿异常敏感，并指出 Apple 自己的原生应用（例如 Music、Reminders）往往也显得缓慢或工程质量不佳。
• 尽管如此，仍有一部分人坚持认为原生 UX 确实更好，即使市场力量意味着许多应用永远不会是原生的。