概述

本文是对Drew Breunig提出的"为什么Claude桌面版是Electron应用"这一问题的回应。与Breunig认为"LLM还没有准备好实现完全的原生精致度"的观点不同，作者Niki提出了一个更具争议性的论点：原生应用已经没有什么可提供的了。文章从原生API的糟糕体验、操作系统厂商对开发者的敌意、UI一致性的丧失、深度系统集成的价值下降，以及性能问题的本质等多个角度，论证了Web技术栈取代原生开发的必然性。

详细内容

背景：Drew Breunig的原始问题

Drew Breunig提出了一个观察：

"尽管现在代码很便宜（指AI辅助编程降低了开发成本），为什么Claude桌面版仍然是一个Electron应用？"

他的假设答案是：

"LLM还没有准备好实现完全的原生精致度。"

这意味着，虽然AI可以帮助编写代码，但还不足以处理原生开发所需的精细UI/UX工作。

作者的核心论点：原生已死

Niki对Breunig的回答提出了根本性的反驳：

"原生已经没有什么可提供的了。"

这不是一个关于AI能力的问题，而是关于原生开发本身价值的问题。

论证一：原生API体验糟糕

开发者的痛苦

作者指出，原生API的开发体验长期以来都很糟糕：

文档不完善：苹果和微软的文档常常过时或缺失
API不一致：同一平台的不同版本之间存在破坏性变更
调试困难：原生开发的调试工具远不如Web开发友好
学习曲线陡峭：掌握原生开发需要大量平台特定知识

平台锁定

原生开发意味着被锁定在特定生态系统
skills 的迁移性差，开发者需要为每个平台重新学习
企业需要维护多个代码库，成本倍增

论证二：操作系统厂商对开发者的敌意

苹果的"围墙花园"

审核机制不透明：App Store审核标准随意变化
抽成争议：30%的"苹果税"引发持续争议
功能限制：iOS对应用功能的严格限制（如后台运行、系统级访问）
开发工具限制：对第三方开发工具的限制和打压

微软的摇摆不定

战略频繁变更：从Win32到UWP到WinUI，开发者无所适从
向后兼容性负担：虽然微软以兼容性著称，但也导致技术债务累积
文档和工具问题：Visual Studio虽强大，但臃肿且学习成本高

开发者的反击

作者暗示，Web技术的兴起某种程度上是开发者对平台厂商控制的反抗：

Web是开放的，不受单一厂商控制
Web标准由W3C等组织制定，更加透明
一次开发，跨平台运行

论证三：UI一致性的消亡

"没有原生外观了"

作者提出了一个尖锐的观察：

"没有原生外观了。"

苹果的"凭感觉"设计

作者特别批评了苹果近年来的设计方向：

"苹果把元素放在那里是凭感觉，而不是根据任何可测量的指南。"

具体表现：

macOS和iOS的设计语言越来越不一致
同一应用在不同苹果设备上的体验差异巨大
Human Interface Guidelines（人机界面指南）的权威性下降
设计师更多依赖"感觉"而非明确的规则

"什么都可以看起来像任何东西"

现代UI的现状：

品牌差异化需求：每个应用都想有独特的视觉识别
设计趋势快速变化：扁平化、拟物化、新拟态...趋势来去匆匆
跨平台统一：企业希望各平台体验一致，而非遵循各自平台规范
自定义UI组件：现代框架（如SwiftUI、Jetpack Compose）鼓励自定义

原生一致性的价值消解

当"原生外观"本身变得模糊和多样时，遵循原生规范的优势就消失了：

用户不再期待应用遵循平台规范
用户更熟悉各应用的独特设计
跨平台一致性比平台内一致性更重要

论证四：深度系统集成的价值下降

云服务取代本地服务

"深度系统集成随着服务转向Web而变得不那么有用。"

具体表现：

存储：iCloud、Google Drive、Dropbox取代本地文件系统
通信：Slack、Discord、微信取代系统级通知
身份认证：OAuth、SSO取代系统用户管理
协作：Figma、Notion、Google Docs取代本地办公套件

浏览器作为新的操作系统

现代Web应用可以访问摄像头、麦克风、地理位置
PWA（渐进式Web应用）可以离线运行、推送通知
WebAssembly使Web可以运行高性能代码
浏览器的能力边界不断扩展

原生集成的边际价值递减

对于许多应用来说：

深度系统集成带来的好处有限
用户更关心功能而非是否"原生"
维护原生集成的成本超过收益

论证五：性能问题的重新定义

"Web应用也可以很快"

作者挑战了Web应用必然慢的观念：

"Web应用也可以很快。"

技术进步的证据

JavaScript引擎优化：V8、SpiderMonkey等引擎性能大幅提升
WebAssembly：提供接近原生的性能
浏览器渲染优化：GPU加速、分层渲染等技术
框架优化：React、Vue等框架的虚拟DOM和优化策略

臃肿的真正原因

作者指出，性能问题的根源不是技术栈：

"真正的问题是缺乏关怀。以及草率；你可以用任何技术栈构建它。"

原生应用的臃肿案例

作者暗示，原生应用同样可以是臃肿的：

Electron应用（如VS Code）可以很快
原生应用（如某些iOS应用）可以很慢
性能取决于开发者的关注和优化，而非技术栈选择

性能迷思

过早优化：许多应用在没有性能问题时就被过度优化
用户感知：用户更关心响应速度而非底层技术
硬件进步：现代硬件使得Web应用的性能差距变得不那么明显

综合论证：为什么选择Electron

基于以上论点，Claude选择Electron的原因变得清晰：

因素	Electron/Web优势	原生劣势
开发效率	一套代码，跨平台	需要为每个平台单独开发
团队技能	Web技术普及，人才易得	原生开发人才稀缺且昂贵
UI灵活性	完全自定义，不受平台限制	受平台规范约束
迭代速度	快速发布，无需审核	应用商店审核流程
系统集成	现代应用不需要深度集成	深度集成的价值下降
性能	足够好，且取决于实现质量	理论上更快，但不一定

更广泛的含义

对开发者的影响

技能投资：Web技术的投资回报更高
职业路径：全栈Web开发比原生开发更有市场
创业成本：Web/MVP优先成为默认选择

对平台厂商的影响

控制力下降：Web削弱了平台厂商的守门人地位
应对策略：苹果推出SwiftUI、微软推进Fluent Design，试图挽回开发者
长期趋势：平台可能变得更加开放，或者失去开发者

对用户的意义

体验一致性：跨平台体验更加统一
功能优先：用户获得功能，而非平台特定的优化
潜在代价：电池寿命、内存使用等可能受影响

观点存疑

是否低估了原生体验的价值？
- 虽然作者认为"没有原生外观了"，但许多用户仍然能够感受到原生应用与Web应用的差异
- 触控响应、动画流畅度、电池效率等方面，原生仍有明显优势
- 专业用户（如设计师、开发者）对原生工具有强烈偏好
对苹果设计的批评是否过于主观？
- "凭感觉放置元素"是一个强烈的指控，但缺乏具体证据
- 苹果的设计仍然有其内在逻辑，可能不是作者所说的完全随意
- 设计指南的灵活性可能是为了适应多样化的应用场景
性能论点是否过于简化？
- 虽然"Web应用也可以很快"在理论上是正确的，但在实践中，Electron应用（如Slack）的内存占用问题确实存在
- "缺乏关怀"作为臃肿的解释可能过于笼统，没有触及技术层面的根本差异
- 在资源受限的设备（如旧手机）上，原生优势仍然明显
忽视了特定应用场景
- 游戏、视频编辑、3D建模等高性能需求场景，原生仍然不可替代
- 文章似乎主要基于生产力工具（如Claude）的经验，可能不适用于所有应用类型
对平台厂商的敌意是否被夸大？
- 虽然App Store政策有争议，但苹果和微软也在持续改进开发者体验
- SwiftUI、WinUI等现代框架表明平台厂商仍在努力
- Web也有其问题（如浏览器兼容、标准制定缓慢）
长期可持续性问题
- 如果所有应用都转向Web，浏览器的复杂性和资源消耗将成为新的瓶颈
- Web标准的演进速度能否跟上应用需求的增长？
- 单一技术栈（Web）的垄断是否健康？

原生应用的衰落——Claude为什么是Electron应用（读书笔记）

概述