多年来，网络标准、性能及可访问性倡导者一直呼吁开发人员“使用平台”。这一主张的核心逻辑在于：既然浏览器原生功能足以替代 JavaScript 自行构建的功能，且后者往往在性能和可用性上不及前者，为何还要重复造轮子？然而，尽管这一观点看似显而易见，仍有大量开发者持怀疑态度。探究这种抵触情绪的来源，有助于理解为何“使用平台”的推广面临阻力。
历史遗留问题是首要因素。长期以来，浏览器生态系统的演进滞后于开发需求，jQuery 等库填补了关键的技术空白。虽然如今大多数浏览器已实现标准化 API（Safari 虽有争议，但每年约 7 次的更新频率尚可接受），但在 2020 年代之前，依赖第三方库往往是更明智的选择。
其次是熟悉度与文档体验的差异。当开发者习惯于在 npm 搜索组件时，若输入“粘性定位”，很难直接得到指向 CSS position: sticky 的结果。即便标准完善，npm 库仍充当着框架与底层平台之间的适配层。许多 React 开发者偏好 JSX 语法，认为原始 DOM API 操作繁琐，而通过虚拟列表等低级库封装后，既保留了性能优势，又提供了更易上手的接口。这种分工使得具备专业知识的人将不熟悉的平台 API 包装成熟悉的形式。
文档质量也影响了选择。主流 npm 包通常配备详细的 README、教程和截图，而 Web 平台文档曾散落于博客、StackOverflow 及 CSS Tricks 等平台。MDN 成为首选文档平台之前，开发者更容易被引导至 jQuery 或 GreenSock 等知名库。例如，Dragula 网站以醒目的视觉设计和“简单到令人震惊”的标语吸引用户，相比之下，MDN 关于拖放 API 的页面显得更为朴素。
除惰性外，“自制乐趣”也是重要动因。对于部分开发者而言，亲手构建功能比调用现成 API 更具成就感。以模态对话框为例，从理解视觉原理到处理背景滚动、禁用溢出以及无障碍关闭逻辑，这一过程虽复杂，但对于热衷探索的开发者而言充满趣味。通过添加动画、主题及自定义按钮，开发者可能在无意中构建出一个准备发布至 npm 的库。这种“宜家效应”促使开发者更愿意维护和修改自己编写的代码。
值得注意的是，当前许多倡导“使用平台”的人士，早年正是 polyfill、模拟器和库的作者。在 IndexedDB、WebSQL 等浏览器存储 API 尚未成熟时，PouchDB 等项目通过填补平台空白积累了深厚的专业知识。若无当时的技术缺口，这些开发者或许缺乏深入钻研的动力。
当然，偏离平台并非总是出于积极动机，有时源于对特定技术的无知。JavaScript 解决方案的普及导致部分开发者忽视了对 CSS 深层机制的理解。历史上，CSS 的清除浮动、最小宽度技巧等概念难以直观掌握，相比理解内部算法，用 JavaScript 表达命令逻辑往往被视为更简单的路径。随着时间推移，开发者倾向于使用已知工具自行构建常见模式。
这种现象不限于 Web 领域。在基于 ClickHouse 存储分析数据时，曾有团队就大型 JSON 数据的存储方式产生分歧：一方建立压缩系统，另一方采用独立键值存储。最终基准测试显示，两者均不如让 ClickHouse 原生处理高效。独立键值存储仅相当于一个性能较差的 SELECT 查询。仔细阅读文档并编写基准测试后，才发现自制方案比平台原生能力更慢且更笨拙。这与 Web 开发中 JavaScript 滥用 CSS 功能的困境如出一辙。
资深工程师的价值往往体现在能以一行代码替换初级开发者复杂的“巴洛克式”代码。对系统端到端运作越了解，贡献的代码就越精简，从而降低长期维护负担。无论是 iOS、Android 还是游戏引擎开发，这一原则同样适用。
人工智能编码工具的兴起为这一议题带来了新的变数。一方面，LLM 拥有百科全书式的平台知识，能根据模糊的自然语言提示选择正确的 API，经过严格测试后，代理可能更倾向于原生解决方案；同时，由于代码非人工手写，“宜家效应”随之消失。另一方面，LLM 存在重复代码倾向，可能忽略现有辅助函数，或因过度设计而导致解决方案臃肿。目前这两种现象在实际使用中均有体现，随着模型和工具的改进，结果尚难定论。
面对过度编程的意大利面代码，人们常感叹其复杂性，但作者本人亦享受构建这种“杂乱之美”的乐趣。只要平台存在，“使用平台”的呼声就不会停止。
