Why don't more developers “use the platform”?

为什么更多开发者不选择“使用平台”？ | 解读趋势

2026年10月3日

为什么更多开发者不选择“使用平台”？

由Nolan Lawson于2026年10月3日发布于Web、软件工程

多年来，倡导网络标准、性能和无障碍访问的开发者一直呼吁同行“使用平台”。我本人也经常是这些倡导者之一。

论点很简单：为什么要在JavaScript中自己构建功能，而让浏览器来完成呢？无论你构建什么，其性能和可用性很可能都比不上浏览器原生提供的功能。

不过，我认为有必要从另一个角度思考，至少是为了理解“平台怀疑论者”开发者的立场。如果“使用平台”如此显而易见，为什么还有这么多人需要被说服？

最明显的原因是历史因素：长期以来，浏览器一直在追赶其生态系统的发展。jQuery等库填补了浏览器实现等效API时的关键空白——即使如此，你可能还要等待IE6等落后浏览器被淘汰后才能真正使用它们。如今大多数浏览器都实现了自动更新（尽管Safari的更新频率存在争议，但每年7次也算不错），但直到2020年代之前，Web开发者都不得不面对一个明显不均衡的网络环境。在那种环境下，自行实现功能是合理的选择。

另一个原因是熟悉度：当你习惯于在npm上搜索React组件时，无论遇到什么问题，你倾向于直接寻找这些组件。如果你在npm上搜索“粘性定位”，不会有包会告诉你“你这个傻瓜，直接使用CSS的position: sticky就行了”。

而且，即使存在完善的网络标准，npm上的库仍然经常在框架易用性和底层平台之间填补有用的空白。我发现很多React开发者更倾向于使用JSX和React惯用法——直接操作DOM API感觉“令人作呕”——但在需要频繁操作DOM的场景中，他们却很乐意使用底层库。例如，一个虚拟列表库可能会为了纯粹的性能使用原生DOM API，同时暴露更高级的原语，让新手React开发者更容易理解。从某种意义上说，React组件生态系统自然地形成了分工：经验更丰富的开发者将不熟悉的平台API封装成更熟悉的形态。

这种现象也部分受到文档的影响。许多npm包都配有详尽的README或网站，包含示例、教程和截图。而直到MDN确立为网络文档的权威来源（Google的web.dev作为其更具前瞻性的分支），网络平台的文档一直分散在博客、StackOverflow和CSS Tricks等网站上。这些网站往往只会建议你使用jQuery或GreenSock等知名库！

Dragula网站与MDN的拖放页面对比。可以说前者仍然更具说服力。

尽管问题仅涉及第三方库与平台API之间的比较，但我认为这并不能完全解释人们对“使用平台”这一建议的抵触情绪。那些懒惰（或者我是不是又在重复自己？）的开发者，他们只是希望快速找到解决当前问题的现成方案，通常不会在意这个方案是来自npm、浏览器，还是从某人的随机GitHub Gist中复制的。他们只想解决问题然后继续前进。但我还想探讨另一种对“使用平台”持反对态度的来源。

对某些类型的开发者来说，自己动手构建东西本身就是一种乐趣。而且，自己构建的代码通常更容易理解，特别是当你对网络平台没有百科全书式的了解时。一旦你构建了某个功能，可能会产生一种宜家效应（IKEA effect）——你更倾向于维护和调整自己亲手写的代码。

举个例子，假设你正在尝试构建一个模态对话框。你可能直观地理解这些对话框应该如何工作：内容出现在屏幕上，但背景仍然可见（尽管部分被遮挡），并且点击对话框外部可能会关闭它。于是你可能会使用position:absolute和z-index来正确定位对话框——但这时你会发现背景仍然可以滚动，因此必须禁用body的overflow属性……如果你了解无障碍相关知识，还会意识到需要处理Esc键关闭对话框，构建焦点陷阱（focus trap），并将焦点返回到触发对话框的元素……

对许多开发者来说，我刚才描述的内容听起来像是噩梦（而且是一种让功能只实现一半的好方法）。但对另一些开发者来说，这听起来却非常有趣！想想看，当你开始构建这个功能时能学到多少东西。再想想，你如何通过添加动画、主题、可选的“关闭”按钮等为它注入自己的创意……不知不觉间，你就构建了一个可以发布到npm的库。这比直接使用<dialog>标签然后草草了事要有趣得多——后者未免太无趣了！

对许多开发者来说，在<dialog>等API出现之前，正是通过这种动手实践的方式，我们才真正理解了网络平台！如今倡导“使用平台”的许多人，过去也曾是polyfill、shim和库的作者。我自己就是其中之一！我曾花费多年时间在PouchDB项目中开发IndexedDB、WebSQL等浏览器存储API的工具，这最终让我有足够的信心参加W3C标准会议，甚至在IndexedDB规范本身上提交问题和拉取请求。如果没有平台功能缺失带来的这种“强制性需求”，我不确定自己是否能获得足够的兴趣和动力达到这种专业水平。

当然，自己动手并不总是好事。有时这种做法纯粹源于无知。在网页平台领域，我认为其中一个导致大量JavaScript解决方案泛滥的原因（而这些问题本可以通过CSS更好地解决）是，许多开发者根本没有花时间深入理解CSS的工作原理。

而且，公平地说，CSS 本身历来就难以理解！这就是为什么这个网站叫“CSS Tricks”的原因。像清除浮动、浮动布局以及 min-width: 0 技巧这些概念，几乎没有直观性。与其试图理解 CSS 的内部算法，不如直接想象你想要的指令逻辑，然后用 JavaScript 表达出来。此外，多年来 CSS 缺乏一种直接表达常见模式（如行高限制、文本框大小调整、隐藏滚动条等）的方式。因此，开发者自然会使用他们已理解的工具自己实现这些功能。

我认为这种“避开平台”的现象并不仅限于 Web 领域。任何开发者在使用自己不完全理解的平台时都可能遇到类似情况。例如，在我工作中，我们使用 ClickHouse 存储各种分析数据。曾有一段时间，我和同事就如何存储大 JSON 数据在列中产生了分歧：他构建了一个在存储前压缩数据的系统，而我则将数据存入单独的键值存储，并只将键插入 ClickHouse。结果我们两人都错了！ClickHouse 会自动压缩数据，而且作为列式存储，如果你让 ClickHouse 自己处理，实际上能获得更好的行间压缩效果。而单独的键值存储只是对列式 SELECT 功能的一种低效复现。

我只有在真正花时间彻底阅读 ClickHouse 文档并编写基准测试验证我的假设后，才意识到这些事情。最终我震惊地发现，我们自己构建的方案竟然比平台本身提供的开箱即用方案更慢、更笨拙。这与 JavaScript 和 Web 平台之间的类比令人难以忽视。

我相信，如果你是 iOS 或 Android 开发者，或者正在使用游戏引擎开发，或者任何在平台层之上构建的开发者，你很可能也有类似的故事。老练的高级工程师之所以被刻板印象认为能将初级工程师写的一团乱麻的代码替换为一行代码，正是这个原因。你掌握的知识越多，就越能利用对整个系统端到端的理解，以最小的贡献实现目标（从而长期减少维护负担）。

我一直在努力避免在这篇文章中谈论 AI（因为我过去一年已经对此话题讨论得太多了），但当然，我无法不思考 AI 编码会对这一现象产生怎样的影响。我对此有两种观点：

• 乐观：由于大语言模型对所使用的平台有百科全书式的知识，它们可以精准选择最合适的平台 API 来实现用户用模糊英文描述的需求。由于这种解决方案可能比用户空间代码更快且更正确，经过严格测试和基准验证后，代理会更倾向于使用它。此外，当开发者不再亲自编写代码时，“宜家效应”（即自己动手带来的成就感）也会消失。

• 悲观观点：由于LLMs似乎热衷于重复编写代码（例如，忽视已有的辅助函数，而是反复地重新编写自己的版本），自定义且不符合平台习惯的代码量将呈指数级增长。开发者不会要求代理进行充分的测试或尝试多种替代方案，而是直接提交代理生成的初稿。而且由于始终可以添加更多不必要的复杂层，代理将继续迭代那些本就不该存在的过度设计的解决方案。

在我使用AI编码的过程中，这两种现象都曾真实发生过。我希望随着模型和编码工具的不断进步，我们终将朝着更乐观的结果发展，但这一点我无法确定。

无论如何，这些是我对“使用平台”这一口号的冗长且略显矛盾的思考。作为一条箴言，我非常喜欢它，因为它精准地表达了当我看到一团乱麻般的代码时的感受——如果作者能稍微理解底层结构，这些代码本可以更加优雅和简洁。但同时，我也曾是那个作者，也曾享受过编写如此美丽而混乱的代码（对我来说是美丽的）的乐趣，因此我认为理解这类开发者的出发点同样重要。正因如此，我相信只要还存在平台，“使用平台”这一口号将会持续被反复提及。

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