加载失败
这条讨论源自一篇批评性文章（标题为“Claude is an Electron App because we've lost native”），争论点在于 Anthropic 的桌面客户端 Claude 采用 Electron 是否反映出“原生开发的衰落”。评论围绕几大维度展开：一是商业/工程权衡（跨平台、快速交付、Web-first 产品线）；二是平台与工具链的碎片化（如微软多次更换 UI 路线、Apple 的 SwiftUI 改写带来的争议）；三是性能与用户体验的实际差异，以及可行的替代方案（Tauri——使用系统 WebView 并以 Rust 为后端、Wails、传统 Qt、TUI 等）。讨论既有具体的实战反馈（如 Tauri 的 e2e 测试限制、Claude 的卡顿与内存问题），也有关于 LLM 未来是否会改变开发范式的宏观推测。
大量评论认为公司选 Electron 主要是务实的商业与工程决定——“它能在所有平台上工作”。有人用 Newcomen 蒸汽机类比：初期效率很差但能工作的方案能推动普及，效率的优化可以留到后面做。Electron 允许共享 Web 代码库、快速试验聊天类交互、降低多平台支持成本，并且能更容易覆盖往往被忽视的 Linux 桌面用户，这些都是产品团队把时间和钱投到功能而非重写原生界面的实际理由。许多评论还以 VS Code 为例说明 Web-first 工程在可维护性和快速交付上的优势。
另一批评论强烈抨击 Electron 是懒惰和低质量的代名词，认为很多团队选择它是“最省事”的路径而非认真权衡工程价值。批评者直言部分开发者技能局限、把 Electron 当默认选项并且缺乏打磨，出现“rabid raccoon”式的随意开发比喻。具体证据包括对 Claude 桌面/网页版的抱怨（启动慢、对话多时渲染崩坏、内存占用高）、用户在高配机上仍遇到卡顿，以及 Electron 应用在低端设备上表现差，评论者把这些归因于选型与执行上的问题而非偶发缺陷。反对者认为这种选择不是合理的权衡而是对用户资源与体验的蔑视。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
很多评论指出操作系统和 UI 框架的碎片化、以及设计/品牌统一性的诉求，导致团队宁可用可控的 Web UI 也不愿做多套原生实现。现代公司更在意跨平台一致的品牌/设计系统，而原生工具链在不同平台（macOS 的 AppKit/SwiftUI/UIKit、Windows 的 WinUI/WPF、Linux 的 GTK/Qt 等）之间存在不兼容和频繁变更，使得维护多套原生 UI 成本大幅上升。另有评论以微软长期更迭的 UI 路线为例说明学习成本与遗留兼容性问题，并提到 Apple 将部分系统应用改写为 SwiftUI 后出现的性能倒退，进一步消解了原生一贯优越的印象。总体上，产品与设计决策常常把“跨平台一致性”和“快速迭代”排在比极致原生体验更靠前的位置。
评论中列出了多种 Electron 的替代或折衷路径，常被提及的是 Tauri（一种用系统 WebView + Rust 后端的轻量跨平台框架）、Wails（Go 方案）、以及传统的 Qt 或基于终端的 TUI（如 ratatui、Turbo Vision）。实际经验显示 Tauri 生成体积小、性能好，但存在边缘问题：无法用 Playwright 直接做 e2e（缺少对 Chrome DevTools Protocol 的暴露）、macOS 的安全域权限处理也还有不足；还有人用 Tauri+Extism/wasm 插件实现多语言插件能力，或直接用 Claude Code 生成 Qt+Rust 的原生客户端作为示例。由此可见并非没有技术可行性——只是不同替代方案存在各自的工程成本与成熟度权衡。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
评论里有关于 LLM/agent 将如何改变开发栈的讨论：有人预测 LLM 驱动的开发可能偏向“更安全/可验证”的语言或新范式，但也有人质疑为 LLM 生成对人类可读的源码是否必要。多条讨论强调可读性与可验证性（legibility）在 AI 时代的重要性，同时指出现有编译器仍然是将高层语义可靠转为机器代码的工具。另有观点认为当前 LLM/agent 还不足以把复杂桌面应用自动化地、稳定地重写为高质量原生实现，因此短期内它们更可能加强 Web-first 的开发流程而非彻底带回原生生态。
许多评论强调某些应用类别对原生不可或缺：如 CAD、3D 编辑器、视频制作、广播软件和复杂仿真等需要极致性能和自定义渲染。还有对比实例：Sublime Text 相较 VSCode 更为流畅、长期运行时内存泄漏更少，这类体验差异被视为原生/精简实现的直接证据。嵌入式设备、工业/车载信息娱乐或低端硬件场景也常被引用为原生工具链更合适的理由，且曾有用 React 替代 Qt 导致性能倒退的实务反馈作为反例。总结来看，尽管 Electron 在多数产品场景成立，但高性能或资源受限的专业软件仍然倾向于原生实现。
Electron: 基于 Chromium + Node 的桌面应用框架：以嵌入浏览器渲染 HTML/CSS/JS 为界面，便于跨平台和重用 Web 代码，但通常体积较大并伴随更高的内存/CPU 开销。
Tauri: 一个轻量级跨平台桌面框架：使用系统提供的 WebView 做前端渲染、以 Rust 作为后端桥接本地 API，产物体积通常小于 Electron，但在 e2e 测试与某些平台权限（如 macOS 的 Security Scoped Resources）上还有边缘限制。
TUI（Text User Interface）: 文本用户界面：基于终端/字符画面的交互界面范式（例如 Turbo Vision、ratatui），资源占用低，适合快速工具或资源受限环境；评论中提到 Claude Code 就有 React 风格的 TUI 实现。
WebView / 浏览器引擎: 嵌入式浏览器组件（例如 Chromium 引擎）：用于在桌面应用中渲染网页内容。由于不同平台/版本的引擎不一致，应用往往会捆绑自己的引擎以确保兼容性，导致体积增大。
SwiftUI: 苹果推出的声明式 UI 框架，用于 iOS/macOS 的原生界面开发。评论中有人指 Apple 把部分系统应用改写为 SwiftUI 后出现性能与响应性的退步。
Rust: 一种关注安全与性能的系统编程语言，常用于编写高性能本地模块或作为 Tauri 的后端；评论提到其强类型可以作为对 LLM 生成代码的约束手段。