多年来，网页标准、性能和无障碍的倡导者一直敦促网页开发者“使用平台”——也就是说，依赖浏览器内置功能，而不是构建自定义解决方案或求助于库。这个论点很简单：为什么要在 JavaScript 中自己造轮子，而浏览器可以开箱即用地提供等效功能，并且性能和易用性更好？然而，许多开发者对这一建议似乎持抵制态度。要理解原因，需要超越表面的解释。历史因素起着重要作用。在网络史上的很长一段时间里，浏览器滞后于开发者的需求，迫使创造者使用诸如 jQuery 之类的库来填补空白。开发者必须等待像 IE6 这样过时的浏览器淘汰后，才能安全地采用标准化 API。这导致了一种环境：自行构建解决方案往往是唯一实际的选择，这种习惯甚至在浏览器变成常更新（evergreen）后仍然延续。对现有生态系统的熟悉也会影响行为。习惯在 npm 上搜索 React 组件的开发者会自然先去寻找那些工具，即使平台解决方案存在。没有一个 npm 包会简单地说“只要使用 CSS position: sticky，你这个笨蛋”——相反，生态系统训练开发者去寻找打包好的解决方案，而不是考虑浏览器已经提供了什么。文档质量的差异进一步强化了这种模式。虽然 npm 包通常附带用心编写的 README、配有示例、教程和截图的网站，但网页平台的文档历史上分散在博客、StackOverflow 和 CSS Tricks 等站点。直到 MDN 成为权威参考（web.dev 作为更面向未来的补充），学习平台特性需要从零散来源拼凑信息，这使得集中文档的库更具吸引力。除了实际考量之外，构建自定义解决方案常常带来内在的乐趣。例如，从零开始创建一个模态对话框需要了解定位、z-index、溢出处理、Esc 键关闭、焦点陷阱以及将焦点返回到发起元素——这一过程虽然复杂，但可能极具吸引力。许多开发者觉得这种问题解决既有趣又有教育意义，从而导致心理学家所说的‘IKEA 效应’：我们更倾向于高估自己亲手制作的东西，而低估现成的替代品。这种乐趣在网页开发史上具有重要意义。今天最强烈倡导‘使用平台’的开发者曾经自己编写过 polyfill、垫片和库。作者指出，通过 PouchDB 等项目在 IndexedDB、WebSQL 和其他浏览器存储 API 上多年的工作，积累了参与 W3C 标准讨论所需的专业知识。如果没有平台空白需要填补，这种深入理解底层系统的动力可能根本不会产生。然而，回避平台并不总是有益的。有时这仅仅源于对 CSS 等技术实际工作方式的无知。历史上，CSS 被认为是不直观的——需要诸如清除浮动、浮动处理以及 min-width: 0 之类不明显的技巧——这导致开发者 semplicemente 用 JavaScript 实现解决方案，因为他们对 imperative（命令式）逻辑比对 declarative（声明式）样式更熟悉。多年来，CSS 缺乏直接表达常见模式的方法，如行裁剪、文本域大小调整或滚动条隐藏，这迫使开发者使用熟悉的工具重新实现这些功能。这一现象不仅限于网页开发。作者描述了在 ClickHouse 上的类似经历：一位同事尝试在存储前压缩 JSON 数据，而作者则采用独立的键值存储方案，结果都显得多余。ClickHouse 会自动压缩数据，并且作为列式存储，当原生处理存储时能提供更好的跨行压缩——这一认识仅在阅读文档并构建基准测试后才得以获得。展望未来，作者考虑了 AI 编码助手可能对这种动态产生的影响。乐观方面，大型语言模型拥有平台的百科全书式知识，能够挑选恰好满足自然语言提示的 API，在测试和基准后可能更倾向于平台解决方案。悲观方面，LLMs 倾向于复制现有代码而非复用辅助函数，如果开发者接受初稿而不充分探索替代方案，或继续在过度设计的解决方案上迭代，可能会增加非平台 idiomatic 的代码。最终，使用平台与构建自定义解决方案之间的张力揭示了关于开发者成长的更深层真理：一个人对整个系统端到端工作方式了解得越多，就越能够做出微小却有价值的贡献。然而，从零开始创造某物的乐趣——对其创作者而言很美，即使在客观上不算优雅——确保了‘为什么更多开发者不使用平台？’这一问题将一直相关，只要平台存在。
Author portrait illustrating the perspective of a developer who has experienced both building custom solutions and advocating for platform use.