发布于 2026 年 10 月 3 日，作者 Nolan Lawson，分类：Web、软件工程。

多年来，Web 标准、性能和可访问性的倡导者们一直在恳求 Web 开发者“使用平台”。我自己也常常是这些倡导者之一。

论点很简单：既然浏览器能替你完成，为什么还要用 JavaScript 自己构建呢？无论你构建什么，它的性能和可用性都可能不如浏览器开箱即用的方案。

不过，我认为站在另一方的角度思考是值得的，哪怕只是为了理解那些“平台怀疑论”开发者的出发点。如果“使用平台”如此显而易见，那为什么还有那么多人似乎需要被说服呢？

最显而易见的原因是历史性的：在很长一段时间里，浏览器一直在追赶其上的生态系统。像 jQuery 这样的库填补了关键空白，而浏览器则在实现等效的 API（应用程序编程接口）——即便如此，你可能还得等 IE6 这样的落后者被淘汰后才能实际使用它们。如今，大多数浏览器都是常青的（Safari 有争议，不过每年约 7 次更新也不算差），但直到 2020 年代左右，Web 开发者不得不面对一个明显参差不齐的 Web。在那样的环境中，自己动手是明智的选择。

另一个原因是熟悉度：当你习惯于在 npm 上寻找 React 组件时，无论面对什么问题，你都会倾向于这么做。如果你在 npm 上搜索“粘性定位”，没有任何包会告诉你“直接用 CSS position: sticky 就行了，你这个笨蛋。”

而且，即使有了强大的标准，npm 上的库往往也能在框架的人体工学与底层平台之间填补有用的空白。我一直觉得有趣的是，许多 React 开发者更愿意坚持使用 JSX 和 React 惯用法——原生 DOM API 让人感觉“恶心”——但他们却非常乐意使用那些常见原生 DOM 操作的底层库。例如，一个虚拟列表库可能会为了纯粹的性能而乐于使用原生 DOM API，同时暴露更高级的原语，让新手 React 开发者更容易掌握。从某种意义上说，React 组件的生态系统导致了自然的劳动分工：那些拥有更多专业知识的人将不熟悉的平台 API 打包成更熟悉的形式。

这种效应部分也由文档驱动。许多 npm 包都有精心编写的详细 README 或网站，包含示例、教程和截图。而直到 MDN 成为 Web 文档的首选之地（web.dev 作为 Google 更面向未来的分支），Web 平台的文档还分散在博客、StackOverflow 和 CSS Tricks 等网站上。而且这些网站中有很多只会告诉你使用像 jQuery 或 GreenSock 这样的知名库！

不过，如果这只是关于第三方库与平台 API 的对比，那我认为它无法完全解释对“使用平台”的反感。那些懒惰的开发者（还是说我在重复自己？），那些只想要现成解决方案来应对当前问题的人，不太可能关心解决方案是来自 npm、浏览器，还是从别人随机的 GitHub Gist 上复制来的。他们想解决问题然后继续前进。但我想探讨的是另一种反“使用平台”的来源。

对某一类开发者来说，自己构建东西就是更有趣。而且通常生成的代码更容易推理，尤其是当你对 Web 平台没有百科全书式的了解时。一旦你构建了某个东西，就可能产生一种宜家效应，让你想要维护和折腾自己手工打造的代码。

举个例子，假设你想构建一个模态对话框。你可能从视觉上理解它们应该如何工作：内容出现在屏幕上，但背景仍然可见，尽管被部分遮挡，也许点击对话框外部可以将其关闭。所以你可能会用 position:absolute 和 z-index 来正确定位对话框——啊哈，但背景仍然会滚动，所以你必须在 body 上禁用 overflow……然后如果你了解一些可访问性知识，你会意识到需要处理 Esc 键来关闭，还要构建焦点陷阱，并将焦点返回到启动对话框的元素上，还有……

对许多开发者来说，我刚才描述的东西听起来像是一场噩梦（也是构建半吊子东西的好方法）。但对许多开发者来说，这听起来很有趣！想想你在开始构建这个东西的过程中能学到多少。再想想你可以如何通过添加动画、主题、可选的“关闭”按钮来打上自己的烙印……不知不觉中，你已经构建了一个可以发布到 npm 上的库。这比直接抓来 <dialog> 就完事有趣多了——那多没劲！

对我们许多人来说，在像 <dialog> 这样的 API 出现之前，我们就是这样学习 Web 平台的！如今倡导“使用平台”的许多人，自己曾经就是 polyfill、shim 和库的作者。我知道这一点，因为我自己就是其中之一！我花了数年时间为 IndexedDB、WebSQL 和其他浏览器存储 API 开发工具，这是我参与 PouchDB 工作的一部分，最终这让我有足够的信心坐在 W3C 标准会议上，甚至直接在 IndexedDB 规范上提交 issue 和 pull request。如果没有平台中需要填补的空白作为推动力，我不知道自己是否会找到兴趣或动力去达到那种专业水平。

当然，自己动手并不总是一件纯粹的好事。有时它仅仅源于纯粹的无知。特别是在 Web 平台上，我认为 JavaScript 解决方案大量涌现来解决本可以更好地由 CSS 解决的问题，原因之一就是许多开发者没有花时间去深入理解 CSS 的工作原理。

平心而论，CSS 在历史上确实很难理解！这个网站叫“CSS Tricks”是有原因的。clear fix、floats 和 min-width: 0 技巧之类的东西并不直观。与其试图理解 CSS 的内部算法，通常更容易的做法是想象你想要的命令式逻辑，然后用 JavaScript 表达出来。此外，多年来 CSS 没有直接的方式来表达常见模式，比如行截断、textarea 调整大小、滚动条隐藏等。所以开发者当然会用他们已经理解的工具自己构建。

我甚至不认为这种“回避平台”的现象仅限于 Web。它可以适用于任何在不完全理解的平台上工作的开发者。例如，在我的工作中，我们使用 ClickHouse 存储各种分析数据。有一次，我和同事就如何在列中存储大型 JSON 数据产生了分歧：他构建了一个在存储前压缩数据的系统，而我把数据放在单独的键值存储中，只将键插入 ClickHouse。结果我们俩都错了！ClickHouse 会自动压缩数据，而且作为列式数据存储，如果你让 ClickHouse 来处理，实际上跨行压缩效果更好。而单独的键值存储只是列式 SELECT 已经能做到的事情的简陋版本。

我是在真正花时间彻底阅读 ClickHouse 文档，然后编写基准测试来证明我的假设之后才意识到这些的。最终我震惊地发现，我们构建的东西比平台本身开箱即用的东西更慢、更笨重。与 JavaScript 和 Web 平台的相似之处很难忽视。

我相信如果你是 iOS 或 Android 开发者，或者是在游戏引擎之上构建的人，或者真的是任何在某个平台层之上构建的开发者，你可能也有类似的故事。资深工程师的刻板印象是能够把初级工程师巴洛克式纠缠不清的代码替换成一行代码，这是有原因的。你学得越多，就越能运用你对整个系统端到端工作原理的知识，来创造尽可能小的贡献（从而在长期减少维护负担）。

整篇文章我一直在努力不谈 AI（因为过去一年我已经谈得太多了），但当然我忍不住想知道 AI 编程会如何影响这一现象。我实际上既有乐观的看法，也有悲观的看法：

• 乐观：因为 LLM 对你所使用的任何平台都有百科全书式的知识，它们可以准确选择正确的平台 API，来提供提示者用模糊英语所要求的体验。而且由于这种解决方案可能比用户态代码更快、更正确，智能体在经过严格测试和基准测试后会偏好它。此外，当开发者实际上不是自己编写代码时，“宜家效应”就消失了。
• 悲观：因为 LLM 似乎喜欢重复代码——例如，忽略已经存在的辅助函数，而是第无数次编写自己的——自定义的、非平台惯用的代码量将激增。开发者不会指示他们的智能体进行足够的测试或尝试足够的替代方案，而只会提交智能体的初稿。而且因为总是可以添加更多本轮，智能体将继续迭代那些本就不该存在的过度工程化解决方案。

在我自己使用 AI 编程的过程中，我看到了这两种现象的发生。我愿意相信，随着模型和编程工具变得更好，我们会开始更多地偏向乐观的结果，但我不能确定。

无论如何，这些就是我对“使用平台”的冗长且有些矛盾的想法。作为一句口号，我喜欢它，因为它简洁地捕捉到了我查看某堆过度复杂的意大利面条式代码时的感受，并想着如果作者只是更好地理解他们下面的层次，那会好多少、优雅多少。同时，我也曾是那样的作者，我感受过构建如此美丽、混乱的代码的快乐（至少对我来说是美丽的），所以我认为值得理解这些开发者来自哪里。因此，我相信只要还有平台，“使用平台”这句话就会一直被人们提起。

你可以在 fediverse 或 Lobsters 上发表评论。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：Nolan Lawson

原创地址：https://nolanlawson.com/2026/10/03/why-dont-more-developers-use-the-platform/