多年来，网页标准、性能和无障碍的倡导者一直呼吁开发者“使用平台”，我也常是其中一员。理由很简单：浏览器能做的事，何必用 JavaScript 自己造？不过，质疑平台者的立场也值得一听：若这件事显而易见，为何还需说服这么多人？最明显的原因是历史：浏览器长期在追赶其上的生态。jQuery（jQuery）在浏览器实现同类 API 前填补空缺，即便实现后，也可能要等 IE6 这类浏览器退出。
正文
多年来，Web 标准、性能和无障碍倡导者一直恳请开发者“使用平台”（use the platform），作者也常是其中一员。理由很简单：浏览器能直接给你的东西，何必自己用 JavaScript 造？无论你造什么，性能和易用性都可能不如浏览器开箱即用。
不过，站在反面理解那些“平台怀疑论”开发者也值得一想。如果“用平台”这么显然，为啥还有那么多人需要被说服？
最明显是历史原因：长久以来浏览器都在追赶上层生态。jQuery 等库填补了关键空白，而你甚至要等 IE6 之类的落伍者自然淘汰才能用上等价 API。如今多数浏览器是常青的（Safari 虽有争议，但每年约 7 次更新也不差），但在 2020 年之前，开发者面对的是“崎岖的 Web”（lumpy web），那时自己造是合理选择。
另一原因是熟悉度：习惯在 npm 找 React 组件的人，不分问题直接就抓组件。你在 npm 搜“sticky positioning”，可没有包会跟你说“蠢货，直接用 CSS position: sticky”。
即便有了健壮标准，npm 上的库也常填补框架人体工学与底层平台间的缝隙。许多 React 开发者偏爱 JSX，觉得原生 DOM API“恶心”，却乐意用常做原生操作的底层库。比如虚拟列表库为性能愉快使用原生 DOM，却暴露新手易懂的高级原语。React 组件生态自然形成了分工：专家把陌生的平台 API 包成了熟悉的样子。
文档也推动了这点。许多 npm 包有详尽的 README 或带示例截图的网站。而在 MDN 成为首选文档站（web.dev 作为谷歌更前卫的臂膀）之前，平台文档散落在博客、StackOverflow 和 CSS Tricks 等站，且这些站常直接让你用 jQuery 或 GreenSock！
Dragula 网站对比 MDN 拖放 API 页面，可以说前者至今仍更吸引人。
如果仅关乎第三方库还是平台 API，并不能完全解释对“用平台”的厌恶。懒得解决问题的开发者不在乎方案来自 npm、浏览器还是某个 GitHub Gist，他们只想解决后走人。但还有另一来源。
对某一类开发者，自己造就是更有趣。而且成果代码往往更易推理，尤其当你没百科全书般懂平台时。造完还会有“宜家效应”，想维护和把玩自己的代码。
比如建模态框：你视觉上懂它怎么工作——内容出现，背景半遮，点外面关闭。于是用 position:absolute 和 z-index，但背景还能滚，得禁用 body 的 overflow……若懂点无障碍，还要处理 Esc 关闭、建焦点陷阱、把焦点还给触发元素……对很多开发者这是噩梦（而且容易只做一半），对另一群人却是乐趣！你能学到很多，还能加动画、主题、关闭按钮，不久就发了个 npm 包。这比直接扔个
对许多人，在
当然自己造不总是纯好事，有时纯属无知。Web 上用 JS 解本可 CSS 解的问题之所以泛滥，常因开发者没深究 CSS。
CSS 历来难懂！不然怎会叫“CSS Tricks”。clear fix、float 和 min-width:0 技巧都不直观。与其搞懂 CSS 内部算法，不如用 JS 写命令逻辑。加上多年里 CSS 无法直接表达行截断、textarea 缩放、隐藏滚动条等常见模式，开发者自然用熟悉工具自己造。
这现象不限于 Web。作者工作中用 ClickHouse 存分析数据，曾和同事争论大 JSON 怎么存列：同事先压缩再存，作者存进独立键值库只在 ClickHouse 插 key。结果都错了！ClickHouse 自动压缩，作为列存跨行压缩更好；独立键值库不过是列 SELECT 的穷替身。作者通读文档写基准才恍然，震惊自己造出比平台自带更慢更笨的东西，与 Web 平台如出一辙。
iOS、Android、游戏引擎开发者大概也有类似故事。老手能用一行代码换掉菜鸟缠绕的乱码，正是因为学得越多，越能用端到端系统知识做最小贡献，长期减轻维护负担。
作者努力不谈 AI（过去一年谈腻了），但忍不住想 AI 编码会怎样。他有乐观和悲观两看：
- 乐观： LLM 对平台有百科全书式了解，能精准选对 API 实现模糊需求。经严格测试基准，这方案比用户代码快且准，agent 会偏好之。且开发者不自己写代码，宜家效应消失。
- 悲观： LLM 爱重复代码，忽略已有 helper 自写，导致非平台习语的自定代码飙升。开发者不指示充分测试或试替代，直接提交初稿。因总能加“本轮”（epicycles），agent 会迭代本不该存在的过度工程解。
作者两者都见过，希望模型变好偏向乐观但不确定。
作为信条他喜欢它，因为它精准捕捉了面对过度设计混乱代码时的感受：若作者更懂底层会多优雅。但作者也曾是那样的开发者，体会过写漂亮乱码的乐趣，所以理解他们。只要还有平台，这话就会一直听到。
评论
多数开发者质疑浏览器原生特性（如原生 dialog、Web Components）的易用性与完整性，认为框架和库提供了更灵活优质的体验；少数人指出若平台本身做得足够好且一致，大家自然会用，但历史习惯与社区生态固化加深了分歧。
认为浏览器原生平台难用、不完整且有缺陷，迫使开发者依赖库
- 开发者指出原生组件如 dialog、日期选择器在样式、无障碍、跨浏览器一致性上不足，且常遇到无法修复的限制，浏览器文档枯燥难懂、更新缓慢（较多人） > 平台本身就在教导人们离开平台，因为它总有功能缺口（@usernomdeguerre）
认为 React 等框架提供了更好的抽象和开发体验
- React 的声明式状态管理比直接操作 DOM 更直观，WebComponents 需包装才可用，竞争库因社区和生态产生更优结果（较多人） > React 让浏览器中的即时模式界面成为可能，这正是它成功的原因（@philippta）
认为历史习惯、教育和社区生态固化导致开发者远离平台
- React 世代开发者只学框架不懂 DOM，平台反馈周期长，大厂光环吸引人，流行技术形成庞大的社区支持体系（较多人） > 技术流行后会发展出巩固选择的社区，形成能帮助新手的志愿者大军（@flippingheck）
认为如果平台真正做好做一致，开发者自然会采用
- 有人以 position: sticky 被广泛使用为例，说明平台能力优秀时大家愿意用；原生日期选择器差所以被弃用，问题在于平台质量而非偏好（少数人） > 让平台真正好且一致，人们就会用，原生 API 总是更好的选择（@markbao）
认为 AI 辅助开发降低了对原生代码的需求或要求明确指令
- AI 默认生成含大量框架的臃肿代码，除非明确要求否则不优化；也有人觉得 AI 时代代码无人看，框架无所谓（少数人） > 若坚持页面重量，AI 会避免加 JS 而用原生元素，但你必须懂得提问（@onion2k）
有价值的补充
- Firefox 中原生 dialog 只能做淡入动画难以淡出，体验不完整（@jchw）
- Safari 浏览器更新绑定 macOS，旧设备流通导致需兼容老旧特性与 bug（@YmiYugy）
- 服务端渲染时原生 dialog 无法直接以打开状态渲染，存在功能缺陷（@sebastiangrill）
- 复杂嵌套容器中 CSS sticky 失效，被迫用 Intersection Observer 等 hack（@hollowturtle）
- 原生 Web Components 引入 DOM 属性与框架属性间的边界摩擦，增加抽象成本（@tanepiper）