Why don’t more developers "use the platform"?
Why don’t more developers “use the platform”?
为什么更多的开发者不“使用原生平台”？
For years, advocates for web standards, performance, and accessibility have implored web developers to “use the platform”. I’ve often been one of those advocates. The argument is simple: why build something yourself, in JavaScript, when the browser can do it for you? Whatever you build, it’s likely to have poorer performance and worse usability than something the browser could just give you out-of-the-box. 多年来，Web 标准、性能和可访问性的倡导者们一直恳求 Web 开发者“使用原生平台”。我经常也是这些倡导者之一。这个论点很简单：当浏览器可以为你完成工作时，为什么还要用 JavaScript 自己去构建呢？无论你构建什么，其性能和可用性很可能都比不上浏览器开箱即用的功能。
I think it’s worth taking the other side, though, if for no other reason than to understand where the “platform-skeptic” developers are coming from. If “use the platform” is so obvious, then why do so many people seem to need convincing? 不过，我认为有必要站在对立面思考一下，哪怕仅仅是为了理解那些“平台怀疑论”开发者们的想法。如果“使用原生平台”是如此显而易见，为什么还有那么多人似乎需要被说服呢？
The most obvious reason is historical: for the longest time, browsers were playing catch-up with the ecosystem on top of them. Libraries like jQuery filled crucial gaps while browsers implemented equivalent APIs – and even then, you might have to wait for laggards like IE6 to age out before you could actually use them. Today, most browsers are evergreen (Safari is debatable, although ~7 times per year ain’t bad), but up until the 2020s or so, web developers had to deal with a decidedly lumpy web. In that environment, rolling your own is a sensible choice. 最明显的原因是历史因素：在很长一段时间里，浏览器一直在追赶其上层的生态系统。像 jQuery 这样的库填补了关键的空白，而浏览器则在随后实现了相应的 API——即便如此，你可能还得等待像 IE6 这样的“钉子户”被淘汰，才能真正使用这些新特性。如今，大多数浏览器都是常青的（Safari 有争议，但每年更新约 7 次也不算差），但在 2020 年代之前，Web 开发者不得不面对一个极其碎片化的 Web 环境。在那种环境下，自己造轮子是一个明智的选择。
Another reason is familiarity: when you’re used to looking for React components on npm, that’s what you tend to reach for, regardless of the problem at hand. If you search for “sticky positioning” on npm, there’s no package that says “just use CSS position: sticky, you dolt.” And often, even with a robust standard, libraries on npm would fill a useful gap between framework ergonomics and the platform underneath it. 另一个原因是熟悉度：当你习惯于在 npm 上寻找 React 组件时，无论手头遇到什么问题，你往往都会倾向于这样做。如果你在 npm 上搜索“sticky positioning”（粘性定位），没有任何包会告诉你“笨蛋，直接用 CSS 的 position: sticky 就行了”。而且通常情况下，即使有了强大的标准，npm 上的库也能在框架的人机工程学与底层平台之间填补有用的空白。
I always found it intriguing that many React developers preferred to stick to JSX and React idioms – raw DOM APIs felt “icky” – but were perfectly happy to use lower-level libraries where raw DOM manipulations are common. For example, a virtual list library might happily use raw DOM APIs for pure performance, while exposing higher-level primitives that a novice React developer could better grasp. In a sense, the ecosystem of React components led to a natural division of labor where those with more expertise packaged up unfamiliar platform APIs in a more familiar form factor. 我一直觉得很有趣的一点是，许多 React 开发者更喜欢坚持使用 JSX 和 React 的惯用法——他们觉得原生的 DOM API 很“恶心”——但却非常乐意使用那些底层库，而这些库中往往充斥着原生的 DOM 操作。例如，一个虚拟列表库可能会为了纯粹的性能而愉快地使用原生 DOM API，同时向新手 React 开发者暴露他们更容易理解的高级原语。从某种意义上说，React 组件生态系统导致了一种自然的分工，即那些更有经验的人将不熟悉的平台 API 封装成了更熟悉的形式。
Some of this effect was also driven by documentation. Many npm packages have lovingly detailed READMEs or websites with examples, tutorials, and screenshots. Whereas until MDN became cemented as the go-to place for web documentation (with web.dev as Google’s more future-facing arm), documentation for the web platform was scattered across blogs, StackOverflow, and sites like CSS Tricks. And many of these sites would just tell you to use a well-known library like jQuery or GreenSock! The Dragula site versus the Drag and Drop MDN page. Arguably the former is still more compelling. 这种效应的部分原因也源于文档。许多 npm 包都有精心编写的详细 README 或带有示例、教程和截图的网站。而在 MDN 确立其作为 Web 文档首选地位（以及 Google 的 web.dev 作为更具前瞻性的分支）之前，Web 平台的文档散落在博客、StackOverflow 和 CSS Tricks 等网站上。而且这些网站中的许多只会告诉你去使用像 jQuery 或 GreenSock 这样知名的库！对比一下 Dragula 的网站和 MDN 的拖放页面，可以说前者仍然更具吸引力。
If it were just about third-party libraries versus platform APIs, though, then I don’t think it could fully explain the antipathy toward “use the platform.” Developers who are lazy (or do I repeat myself?), and who just want a ready-made solution for whatever problem they’re facing, are unlikely to care whether that solution comes from npm, the browser, or copied off of someone’s random GitHub Gist. They want to solve their problem and move on. 不过，如果仅仅是第三方库与平台 API 的对比，我认为这无法完全解释对“使用原生平台”的抵触情绪。那些懒惰的开发者（或者我是在重复自己？），以及那些只想为手头问题找到现成解决方案的人，不太可能关心这个方案是来自 npm、浏览器，还是从某个人的 GitHub Gist 上复制来的。他们只想解决问题然后继续前进。
But there’s a different source of anti-“use the platform” that I want to explore. For a certain type of developer, building things yourself is just more fun. And often the resulting code is easier to reason about, especially if you don’t have an encyclopedic knowledge of the web platform. And once you’ve built something, there can be a kind of IKEA effect where you want to maintain and tinker with your own homemade code. 但我想要探讨的是另一种反对“使用原生平台”的根源。对于某些类型的开发者来说，自己构建东西更有趣。而且通常情况下，由此产生的代码更容易理解，特别是如果你对 Web 平台没有百科全书式的了解时。一旦你构建了某些东西，就会产生一种“宜家效应”，让你想要维护和折腾自己亲手制作的代码。
As an example, let’s imagine you’re trying to build a modal dialog. You might visually understand how these are supposed to work: content appears on the screen, but the background is still visible although partially occluded, and maybe clicking outside the dialog dismisses it. So you might grab for position:absolute and z-index to position the dialog correctly – aha, but the background still scrolls, so you have to disable overflow on the body… And then if you understand something about accessibility, you realize you need to handle Esc to dismiss, and build a focus trap, and return focus to the element that launched the dialog, and…
举个例子，想象一下你正在尝试构建一个模态对话框。你可能在视觉上理解它们应该如何工作：内容出现在屏幕上，背景虽然被部分遮挡但仍然可见，也许点击对话框外部可以关闭它。所以你可能会使用 position: absolute 和 z-index 来正确放置对话框——啊哈，但背景仍然可以滚动，所以你必须禁用 body 的 overflow……然后，如果你对可访问性有所了解，你会意识到你需要处理 Esc 键关闭、构建焦点陷阱、将焦点返回到启动对话框的元素，等等……
For many developers, what I just described sounds like a nightmare (and a good way to build something that only half-works). But for many developers, this sounds like fun! Think of how much you learn as you start building this thing. And think about how you could start putting your own spin on it by adding animations, themes, an optional “close” button… Before you know it, you’ve built a library that’s ready to go on npm. That’s way more fun than just grabbing