挨骂与流行并存：代价和收益不在同一拨人身上

观点：一个技术被骂和被广泛采用可以同时成立——只要付代价的和拿收益的不是同一拨人。选型争论里”哪个更好”是伪问题，真问题是”谁承担代价、谁拿收益”。

Electron 把这个框架演示得很干净。它把整个 Chromium 内核打进每个应用：一行文字的程序打包七八十至上百兆，每个应用相当于独立开一个浏览器加 Node.js 进程，内存动辄几百兆，冷启动比原生慢一两秒。用户视角全是缺点。但工程视角完全是另一本账：一套前端代码跑 Windows、macOS、Linux 三端，不用养三支原生团队，不用额外招 C++ 或 Swift 工程师，Chromium 和 Node 生态成熟到踩坑基本搜得到解，网页技术做复杂界面和插件扩展比原生灵活得多。两拨人评价的本就不是同一件事，所以骂声和装机量可以长期并存。视频还补了一刀：很多 Electron 应用卡不全是框架的错，VSCode 同样用它却流畅得多——框架给下限，上限靠团队工程优化（拆分进程、懒加载、预加载）。Tauri 复用系统 WebView 把体积压到几兆，代价是跨系统渲染行为有差异、生态成熟度不够。

洞察：代价方和收益方错位时，舆论与采用率会结构性背离，而不是暂时误会。 这意味着两件事：其一，“网上都在骂”不能作为否决一个方案的证据，要先看骂声来自代价方还是收益方；其二，让用户付代价换团队便利的产品，骂声不会因版本优化消失，只会因替代方案（如 Tauri）成熟到抹平收益差而迁移。同理，“框架给下限、团队定上限”适用于一切底座型技术，包括 Agent 框架——同样的底座，体感差距是工程投入拉开的。

启示： 评审任何技术选型时先问一句”代价落在谁身上”。当我们是收益方（开发团队）时，警惕用”开发效率高”合理化”用户体验差”；当我们是代价方（用户）时，骂之前先确认自己是不是恰好不在受益那侧。给别人推荐方案时，把代价和收益的分布说清楚，比争论技术优劣有用得多。

提醒： 视频里的体积、内存数字是经验值不是严谨 benchmark，具体项目要自己测；内容停在科普层，没给”何时该弃 Electron”的决策树；这套分析只适用于”前端人力充足的团队做桌面端”，移动端、嵌入式、高性能场景不成立。

---

📺 程序员楠枝，抖音，2026-09-22 · 原视频 · 库内 2026-09-22-Electron凭什么被骂还很火 · 速览 速览/2026-09-22-Electron挨骂还火