Why don’t more developers “use the platform”? | Read the Tea Leaves (index.html) (../../../../favicon.ico) (../../../../favicon.svg) (https://nolanlawson.com/apple-touch-icon.png) (Read the Tea Leaves » Feed) (https://nolanlawson.com/feed/) (Read the Tea Leaves » Atom Feed) (https://nolanlawson.com/feed/atom/) (Read the Tea Leaves » Comments Feed) (https://nolanlawson.com/comments/feed/) (Read the Tea Leaves » Why don’t more developers “use the platform”? Comments Feed) (https://nolanlawson.com/2026/10/03/why-dont-more-developers-use-the-platform/feed/) (https://nolanlawson.com/osd.xml) (Read the Tea Leaves) (https://nolanlawson.com/sitemap-index.xml) (../../../../_astro/Base.BhHFry8c.css) (index.html#main) Skip to content (https://nolanlawson.com/) Read the Tea Leaves Software and other dark arts, by Nolan Lawson (light) (Light theme) (dark) (Dark theme) Search this blog (Search this blog) Search (https://nolanlawson.com/) home (https://nolanlawson.com/apps/) apps (https://nolanlawson.com/code/) code (https://nolanlawson.com/talks/) talks (https://nolanlawson.com/about/) about (https://nolanlawson.com/2026/09/30/goodbye-wordpress/) Previous post: « Goodbye WordPress (October 3, 2026 at 1:49 PM) 3 Oct Why don’t more developers “use the platform”? Posted October 3, 2026 by (https://nolanlawson.com/author/nolanwlawson/) Nolan Lawson in (https://nolanlawson.com/category/web/) Web , (https://nolanlawson.com/category/software-engineering/) software engineering . For years, advocates for web standards, performance, and accessibility have implored web developers to (https://timkadlec.com/remembers/2019-10-21-using-the-platform/) “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. 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 (https://jquery.com/) 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 (https://developer.apple.com/documentation/safari-release-notes) ~7 times per year ain’t bad), but up until the 2020s or so, web developers had to deal with a decidedly (https://paul.kinlan.me/the-lumpy-web/) lumpy web . In that environment, rolling your own is a sensible choice. 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. 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. Some of this effect was also driven by documentation. Many npm packages have lovingly detailed README s or websites with examples, tutorials, and screenshots. Whereas until (https://developer.mozilla.org/en-US/) MDN became cemented as the go-to place for web documentation (with (https://web.dev/) web.dev as Google’s more future-facing arm), documentation for the web platform was scattered across blogs, (https://stackoverflow.com/) StackOverflow , and sites like (https://css-tricks.com/) CSS Tricks . And many of these sites would just tell you to use a well-known library like jQuery or GreenSock! (https://nolanlawson.com/media/2026/10/dragndrop.png) (Screenshot of the Dragula website saying "drag and drop so simple it hurts" with a logo and stylized purple page versus the MDN page for the Drag and Drop API which looks much more subdued in comparison) The (https://bevacqua.github.io/dragula/) Dragula site versus the (https://developer.mozilla.org/en-US/docs/Web/API/HTML_Drag_and_Drop_API) Drag and Drop MDN page . Arguably the former is still more compelling. 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. 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 (https://en.wikipedia.org/wiki/IKEA_effect) IKEA effect where you want to maintain and tinker with your own homemade code. 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 (https://css-tricks.com/a-primer-on-focus-trapping/) focus trap , and return focus to the element that launched the dialog, and… 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