有篇文章提出了一个问题：既然现代浏览器已经内置了大量能力，为什么开发者还是习惯自己造轮子？这个讨论在 Hacker News 上引发了大量回应，多数人的观点是原生控件和 API 太受限或太难用。
争论的核心
「用平台」指的是优先使用浏览器原生提供的能力：表单控件、日期选择、对话框、验证、存储、导航，而不是引入第三方库重新实现。
支持方的理由很实在：原生意味着零依赖、零体积、无障碍支持通常更好、行为跟操作系统一致、长期维护由浏览器厂商负责。
反对方的理由也很实在：原生控件样式定制能力有限、跨浏览器行为不一致（虽然比以前好很多）、某些 API 的设计 awkward、以及需求稍复杂就不够用。
哪些是真的限制
样式定制是最常被提到的。原生下拉框、日期选择器、文件上传的样式控制一直受限。虽然这几年有了一些新能力在推进，但覆盖度不够。
一致性问题已经比十年前好很多，但细节差异仍在。特定控件在特定浏览器上的行为偏差，足以让团队决定全部自研。
哪些是错觉
一部分「不够用」其实是没查文档。有些能力已经存在多年，但因为早期体验差留下了坏印象，导致没人再试。
无障碍是一个典型：自己造的控件往往无障碍支持远差于原生，而这一点在开发阶段不容易被发现。
一个务实的判断框架
先看需求是否落在原生的能力范围内。能直接用就直接用。
如果需要定制，先看能不能在原生基础上增强——比如渐进增强，而不是完全替换。
只有确认原生确实无法覆盖时才自研，并且自研时要补上原生本来免费给你的那些东西：键盘导航、屏幕阅读器支持、高对比度模式。
为什么要重新讨论这件事
前端的依赖数量在过去十年膨胀得很厉害。一个普通项目的 node_modules 动辄几百 MB。每个依赖都是维护负担、安全风险和体积成本。
在这个背景下，「能不能不加这个依赖」重新变成了一个值得问的问题。
建议做法
在新项目启动时加一条规则：引入任何 UI 依赖之前，先写一段说明，讲清楚为什么原生方案不行。这条规则能拦掉相当一部分不必要的依赖。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。