【译】为什么硬件速度越来越快，而我们使用的应用程序却越来越慢？

现代硬件快得离谱。我用来写文章的 M1 Max 主频 3.2GHz，也就是每秒 32 亿个时钟周期。可 Microsoft Teams 打开个链接居然要 3 秒，我实在不信这事得花 96 亿个周期。虽然这个估算非常粗糙，但问题很清楚：硬件越做越猛，软件体验却肉眼可见地变差。

“那是因为现在要做的事情多太多了呀。”——典型的后期资本主义信徒会这么说。让我展开聊聊。

电子游戏是现代算力的最好示范。我这个消费级配置就能实时模拟带物理和光追的大型 3D 世界，还能和外州甚至国外的朋友联机，以每秒 1.24 亿像素¹的速率一路推帧。

反过来看，人们已经把 DOOM 跑在各种能算的设备上：计算器、iPod、相机……这些低功耗、几乎一次性的玩意儿都能流畅运行 1993 年的顶级游戏。三十年来的进步就摆在这里。

“Web 很烂”

Web 真挺酷的：往前兼容、跨平台、容易上手，还自带事件驱动的 UI 模型。代价当然是性能——想高效地执行 JavaScript 这种灵活语言本来就难，尤其是拿它和原生应用比的时候，JS 似乎天然就是背锅侠：解释执行、动态类型、内存占得多、跑得慢。

有些场景确实该怪它。比如 webpack，要解析几千个文件、构建 AST，还得做一堆我也讲不清的 CPU 密集操作，所以 esbuild（Go 写的）和 swc（Rust 写的）比 webpack 快得多就一点不奇怪。

但普通 Web 应用真不是这样。你那款披着聊天外衣的 Web IRC 卡到只剩 5 FPS，不是因为“Web 先天劣势”。前阵子 Twitter 在转的 McMaster-Carr 产品目录就是个好例子。靠激进的预加载和服务端渲染，他们用 ASP.NET + jQuery 这种上古堆栈，做出了点击就亮、翻页丝滑的体验，让追新党集体破防。

讨厌 React？那也别把这事当成反对 React 和“现代框架”的证据，这完全²是错的。去看看 NextFaster（代码在这），人家用 Next.js + Vercel 搭出一个一样快、甚至更快的 McMaster 克隆站。

Figma 大概是 Web 技术的天花板。一个完整的设计工具，60 FPS、实时多人协作，想想都逆天。当然它不止是 JS，大块逻辑跑在 WebAssembly 和 WebGL 上。做原生肯定还能再挤点性能，但那意味着丢掉“打开浏览器就能用”的便利。他们选择把优化做到极致，证明浏览器也能飙车。

顺便感谢 V8、SpiderMonkey、JavaScriptCore 的工程师们。正因为你们钻研这些看不见的细节，我们才有机会造东西。

“Electron 很烂”

这里的“Electron”泛指 Electron、CEF、WKWebView、Edge WebView2 以及各种“把 Web 塞进桌面壳子”的方案。

Electron 让大家可以直接把 Web 应用打包成桌面应用，诱惑力确实大：一套技术栈、一次开发，Windows、macOS、Linux 全搞定。

代价？Web 应用最靠谱的运行环境就是浏览器，所以 Electron 索性把浏览器打包进去了。还能出啥错呢？¯\_(ツ)_/¯

事实说明，错挺多的。过去十年里，下载包 500MB 往上已经见怪不怪，动辄占掉一大把内存和 CPU，顺带耗干你的电池。更糟糕的是体验还不咋地：滚动和选择怪怪的、外观和导航处处透着“不原生”，切屏一卡一卡。Discord、Teams 都是这种“套壳网站”的代表——手机端好用顺滑，桌面端却像个二手网页。为什么？

真没必要怪 Electron。它只是在说：“给你个窗口，把你的 Web 应用塞进来就行”。

责任在于做这些应用的团队。想把 Electron 做好完全没问题，Slack、Obsidian、Notion 都能证明。前提是你得真正在乎体验。

说起 Electron，就绕不开 Brackets、Atom，还有最知名的 VS Code。老实讲，VS Code 能在 JS 里支撑起大文件编辑已经够让我佩服，因为“用 JS 编辑大文件”大概等于“先朝自己脚开一枪，再去跑马拉松”：虽然证明了某种可能，但代价巨大。

VS Code 成功的一大原因是插件生态，而这一切都依赖 Web 技术的易用性。最近我给 SWC 写了个（搞笑的）插件，更加确信原生插件开发体验远远比不上 Web 那种飞快的迭代节奏。

“原生很烂”

读到这，你可能以为我只想推原生应用。事实上，大多数原生应用的手感确实好得多（比如 Postico、Zed），我也能用的时候尽量用。

自从几个月前换到 Zed，我就再也不想回 VS Code 了。所有操作——真的是所有——都在瞬间完成。你也许觉得 VS Code 已经够快，但那种差距就像声速和光速，在临界处能觉出巨大不同。Zed 的做法是：自己造一套 GPU 框架，用 Rust 把编辑器写到底。硬件该怎样用就怎样用，速度自然上来。还能怎样？

我还挺想多玩玩桌面版 React Native。它那种类 DOM 的渲染模型很对 Web 开发者的胃口，加上新架构之后，似乎能在开发体验和性能之间找到平衡。现在它不火可能只是缺少官方力气。

当然，原生世界也不是天堂。Adobe 全家桶动不动就崩，Windows 11 的搜索面板糟得好笑，macOS 的活动监视器要 5 秒才把进程列表塞出来。

那我们就认命？

显然，这些问题和语言、系统、行业关系都不大，而是“赶工优先、体验靠边”的共同趋势。

资源滥用

如今的情况更糟，因为现代电脑快到普通人根本用不满。随手在桌面浏览器刷 YouTube Shorts，就能看到内存一路漏到 2GB 再触发限制。要是放到总共才 2GB RAM 的年代，这种产品压根不会上线。如今硬件看似富裕，反倒成了偷懒做烂活的借口。

“这样就好”心理

我个人非常在意操作反馈，但跟很多人聊下来才发现，大多数用户完全无感。等 500ms 才弹出右键菜单？勉勉强强能忍。拉伸窗口卡顿重排？睁一只眼闭一只眼。也许是老派拨号上网留下的回忆，也许是被劣质体验教育了：习惯成自然。可我们明明有能力做得更好。

“先上线再说”文化

快点造东西，这没错。问题在于把性能当技术债、和从头到尾不管性能，是两回事。在现在的许多产品里，感觉他们甚至懒得把性能列进 TODO，只会等硬件再上一代。如果项目真在探索无人区，这么做可以理解；可如果你就是把文本画到屏幕上，就别拿这个当借口了。

表演型性能

看起来我像是在鼓吹“把每条指令都优化到极致”。其实不是。那种级别的打磨只有像 Chris Sawyer 写《过山车大亨》时才说得通。这篇文章想说的只是：现代大型软件普遍不在乎手感和反应速度，因为“反正用户还得用”。我不想看到这样的未来。

如果你是开发者，请带着匠心去做产品，关注每一毫秒，珍惜那些让你开心的工具，并为自己的作品自豪。

别再拿更多资源，去做更少的事情了。