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

原文 ↗ Hacker News 讨论 ↗

许多 Web 开发者仍然更偏爱 React 风格的框架和自定义控件，而不是原生浏览器功能，因为他们认为“平台”在历史上一直不稳定、在真实 UX 需求面前能力不足，而且直接使用起来很难。像 `<dialog>`、原生日期/时间选择器、`<datalist>` 和 Web Components 这类例子被认为在不同浏览器间存在 bug、缺乏灵活性或可访问性欠佳；同时，设计要求和产品需求往往也超出了内置控件的能力。也有人反驳说，现代 HTML/CSS/JS 已经进步很多，能够替代大量依赖 JavaScript 的工具链，但也承认生态势能、文档和既有抽象让人很难回到浏览器原语。

原生浏览器功能的感知局限

  • 许多原生控件（日期/时间输入、<dialog>、<datalist>、多选、组合框）被认为过于受限或不够灵活，无法满足真实世界需求（例如，禁用任意日期、可搜索列表、仅工作日排程）。
  • 原生拖放以及某些表单控件在不同浏览器和设备上的表现很差或不一致（iOS Safari、Firefox bug，以及时间字段里像“99 minutes”这样的奇怪边缘情况）。
  • 开发者往往发现自己很快就“超出”了原生元素的能力，最后还是不得不用 JS 重新实现它们。

Web Components vs 框架

  • Web Components 常被批评为笨拙、低层次，且难以直接使用（样板代码、属性 vs 属性值、状态管理、Shadow DOM 的痛点、样式/重置）。
  • 许多人觉得你实际上需要一个像 Lit 或 Stencil 这样的封装库；到那一步，感觉就和使用 React 差不多，只是权衡不同。
  • 也有人为 Web Components 辩护，认为它们是高性能的构件，但也承认它们与更广泛的平台集成不顺，以及缺少易用的 API。

开发者体验、历史与生态效应

  • 从历史上看，这个平台一直很弱；从 jQuery 到 React 的各种库填补了巨大空白，并训练开发者去用 npm 而不是规范。
  • React 的成功被认为不只是纯技术上的优越，更归功于出色的文档、教学材料、会议，以及生态势能。
  • 一旦某项技术赢得了心智份额，它的社区（示例、支持、组件）即使替代方案有一些更好的特性，也会继续强化其主导地位。

可访问性、UX 与产品需求

  • 团队经常放弃原生控件，因为它们无法满足 UX/品牌设计或可访问性预期（焦点管理、键盘行为、屏幕阅读器）。
  • 自定义控件在某些设备上往往更糟，但设计师和 PM 仍然要求定制 UI；工程师感觉自己被迫远离平台默认方案。

浏览器不一致与平台信任

  • 不一致或有 bug 的实现（尤其是 Safari 和旧版本）让开发者对依赖“平台”心存顾虑。
  • Polyfill、变通方案以及漫长的标准化周期，都会激励团队在 JS 里解决问题，因为在那里他们拥有完全控制权，并且可以立即发布修复。

AI、抽象与“使用平台”

  • 有些人用 AI 生成大多是原生、JS 很少的网站；也有人指出，你仍然需要深入的平台知识来调试 AI 的错误。
  • 还有人认为 HTML/CSS/DOM 实际上就是一种低级汇编；框架和响应式模式被视为管理状态与复杂性的实用方式。