为什么没有更多的开发者“使用平台”？

多年来，网络标准、性能和可访问性的倡导者一直恳求网络开发人员“使用该平台”。我经常是这些倡导者之一。争论很简单：当浏览器可以为你做的时候，为什么要自己用 JavaScript 构建一些东西呢？无论您构建什么，它的性能和可用性都可能比浏览器为您提供的开箱即用的产品更差。不过，我认为站在另一边是值得的，如果没有其他原因，只是为了了解“平台怀疑论者”的开发者来自哪里。如果“使用平台”如此明显，那么为什么这么多人似乎需要说服呢？最明显的原因是历史性的：在很长一段时间内，浏览器一直在追赶其之上的生态系统。像 jQuery 这样的库填补了关键的空白，而浏览器则实现了等效的 API，即便如此，您可能也必须等待像 IE6 这样的落后者过时才能真正使用它们。如今，大多数浏览器都是常青的（Safari 是有争议的，尽管每年大约 7 次也不错），但直到 2020 年代左右，Web 开发人员不得不处理一个明显不稳定的网络。在这种环境下，自行推出是一个明智的选择。另一个原因是熟悉度：当你习惯在 npm 上寻找 React 组件时，无论手头有什么问题，你都会倾向于寻找这些组件。如果你在 npm 上搜索“粘性定位”，没有任何包说“只需使用 CSS 位置：粘性，你就不会了。”通常，即使有一个强大的标准，npm 上的库也可以填补框架人体工程学与其底层平台之间的有用空白。我总是发现有趣的是，许多 React 开发人员更喜欢坚持 JSX 和 React 习惯用法——原始 DOM API 感觉“令人讨厌”——但非常乐意使用原始 DOM 操作常见的较低级别库。例如，虚拟列表库可能会很乐意使用原始 DOM API 来实现纯粹的性能，同时公开 React 新手可以更好地掌握的更高级别的原语。从某种意义上说，React 组件的生态系统导致了一种自然的分工，那些拥有更多专业知识的人以更熟悉的形式打包不熟悉的平台 API。其中一些影响也是由文档驱动的。许多 npm 包都有非常详细的自述文件或网站，其中包含示例、教程和屏幕截图。然而，在 MDN 成为 Web 文档的首选之地之前（web.dev 是 Google 更面向未来的部门），Web 平台的文档分散在博客、StackOverflow 和 CSS Tricks 等网站中。其中许多网站只会告诉您使用 jQuery 或 GreenSock 等知名库！ Dragula 站点与 Drag and Drop MDN 页面。可以说，前者仍然更具说服力。不过，如果只是关于第三方库与平台 API 的比较，那么我认为这不能完全解释对“使用平台”的反感。懒惰的开发人员（或者我重复一遍？），并且只想要一个现成的解决方案来解决他们面临的任何问题，他们不太可能关心该解决方案是来自 npm、浏览器，还是从某人随机的 GitHub Gist 中复制而来。他们想解决问题并继续前进。但我想探讨的是反“使用平台”的不同来源。对于某种类型的开发人员来说，自己构建东西更有趣。通常，生成的代码更容易推理，特别是如果您对 Web 平台没有百科全书式的了解。一旦你构建了一些东西，就会有一种宜家效应，你想要维护和修改你自己的自制代码。举个例子，假设您正在尝试构建一个模式对话框。您可能会直观地理解它们应该如何工作：内容显示在屏幕上，但背景尽管部分被遮挡但仍然可见，并且可能在对话框外部单击会将其关闭。所以你可能会抓住position:absolute和z-index来正确定位对话框——啊哈，但背景仍然滚动，所以你必须禁用主体上的溢出…然后，如果你了解有关可访问性的一些知识，你就会意识到你需要处理Esc来关闭，并构建一个焦点陷阱，并将焦点返回到启动对话框的元素，并且…对于许多开发人员来说，我刚才描述的听起来像是一场噩梦（也是构建只起到一半作用的东西的好方法）。但对于许多开发人员来说，这听起来很有趣！想想当你开始构建这个东西时你学到了多少东西。想想如何通过添加动画、主题、可选的“关闭”按钮来开始添加自己的风格……在不知不觉中，您已经构建了一个可以在 npm 上运行的库。这比仅仅抓住

并收工要有趣得多 - 多么令人沮丧！对于我们许多人来说，在像

这样的 API 存在之前，这就是我们学习 Web 平台的方式！现在提倡“利用平台”的很多人都曾经是