Why developers skip built-in browser features: an essay on "use the platform"
A web developer who has often pushed the "use the platform" line writes an essay taking the opposing view. The standard argument, as he puts it, is simple: why build something in JavaScript when the browser can do it for you? Whatever you build is likely to have poorer performance and worse usability than what the browser offers out of the box. He wants to understand where "platform-skeptic" developers come from, since the advice is supposedly obvious yet many people still need convincing.
His first explanation is historical. For a long time browsers were playing catch-up with the ecosystem built on top of them. Libraries like jQuery filled crucial gaps, and developers sometimes had to wait for laggards like IE6 to age out before using new APIs. Today most browsers are evergreen (Safari is debatable, he says, although about 7 releases a year is not bad), but up until the 2020s or so developers faced a "decidedly lumpy web". In that setting, rolling your own was a sensible choice.
Second is familiarity. A developer used to hunting for React components on npm reaches for npm whatever the problem; searching for "sticky positioning" there will not turn up a package saying to just use CSS position: sticky. He adds that npm libraries often filled a useful gap between framework ergonomics and the platform underneath. Many React developers found raw DOM APIs "icky" but happily used lower-level libraries, such as a virtual list library that uses raw DOM calls for speed while exposing friendlier primitives. That created a division of labor in which experts packaged unfamiliar platform APIs in a familiar form.
Third is documentation. Many npm packages have detailed READMEs with examples, tutorials and screenshots. Until MDN became the go-to place for web documentation, with web.dev as Google's more future-facing arm, platform documentation was scattered across blogs, StackOverflow and sites like CSS Tricks, and many of those simply told you to use a well-known library like jQuery or GreenSock.
But he says these points alone do not explain the antipathy. A lazy developer wants a ready-made fix and does not care whether it comes from npm, the browser or a random GitHub Gist. The deeper reason is that for a certain type of developer, building things is more fun. The resulting code can also be easier to reason about if you lack encyclopedic knowledge of the platform, and afterwards there can be an IKEA effect: you want to maintain and tinker with your own homemade code. His example is a modal dialog. You start with position:absolute and z-index, then must stop the background from scrolling, then handle Esc, build a focus trap and return focus to the launching element. To some that sounds like a nightmare; to others it is fun, and it can grow into a library ready for npm. That beats just grabbing
He notes that many "use the platform" advocates were once authors of polyfills, shims and libraries, himself included. He spent years on tooling for IndexedDB, WebSQL and other browser storage APIs as part of his work on PouchDB, which gave him the confidence to sit in W3C standards meetings and open issues and pull requests on the IndexedDB spec. Without a gap in the platform to fill, he is not sure he would have reached that expertise.
Building your own is not always good, though. Sometimes it comes from pure ignorance. Many JavaScript solutions to problems CSS could solve better exist because developers did not take the time to understand CSS, which has historically been hard (the clear fix, floats and the min-width: 0 trick are hardly intuitive). It was often easier to imagine the imperative logic and write it in JavaScript. And for years CSS had no straightforward way to express common patterns such as line clamping, textarea resizing and scrollbar hiding, so developers built them.
The phenomenon, he argues, is not limited to the web. At his work they use ClickHouse for analytics data. He and a coworker disagreed on how to store large JSON data in a column: the coworker built a system to compress it before storage, while the author put the data in a separate key-value store and inserted only the key into ClickHouse. Both were wrong. ClickHouse compresses data automatically, and as a columnar store it gives better compression across rows if you let it handle the data. The separate key-value store was a poor man's version of what a columnar SELECT already does. He only realized this after thoroughly reading the ClickHouse docs and writing a benchmark to prove his hypothesis, and was shocked that they had built something slower and clunkier than what the platform gave them out of the box. He suspects iOS, Android and game-engine developers have similar stories, and ties it to the stereotype of the grizzled senior engineer who replaces a junior's tangled mess with one line.
Finally he turns to AI coding, offering two takes. Optimistic: LLMs know the platform encyclopedically and can pick exactly the right API; since that solution is likely faster and more correct than userland code, the agent will prefer it after rigorous testing and benchmarking; and the IKEA effect fades when developers are not writing the code themselves. Pessimistic: LLMs seem to love duplicating code, for example ignoring existing helper functions to write their own again, so custom, non-platform-idiomatic code will skyrocket; developers will not tell agents to test enough or try enough alternatives and will commit the first draft; and agents will keep iterating on over-engineered solutions. He has seen both in his own AI coding use, would like to think better models and harnesses will push toward the optimistic outcome, but cannot say for sure.
He calls his thoughts "longwinded and somewhat conflicting". He loves "use the platform" as a mantra, but has also been the author of overwrought code and felt the joy of building it, so he thinks it is worth understanding such developers. He is sure the phrase will be heard for as long as there are platforms.
Key facts
- The author, a longtime "use the platform" advocate, argues that history explains much of the resistance: browsers lagged the ecosystem, jQuery filled gaps, and the web was "lumpy" until about the 2020s.
- Other causes he names: reaching for npm out of habit, polished npm READMEs versus platform docs scattered across blogs, StackOverflow and CSS Tricks before MDN, and the fun and IKEA effect of building your own code.
- A ClickHouse anecdote from his own work: he and a coworker each built a workaround for storing large JSON, and both were wrong, because ClickHouse already compresses data automatically and does better across rows if left alone.
- On AI coding he gives an optimistic case (LLMs know platform APIs and the IKEA effect fades) and a pessimistic one (LLMs duplicate code and custom code skyrockets), and says he has seen both but cannot say which wins.
- The essay is opinion and anecdote; it cites no survey or study data.
Why it matters
"Use the platform" is a common refrain from standards, performance and accessibility advocates, and this essay asks why it still needs repeating. The author's answer is that resistance has several roots, not just laziness: a past in which browsers really were behind, habits formed around npm, better-packaged library documentation, and the pleasure of building. Seeing those reasons helps advocates argue better than simply saying the browser already does it. The AI section matters too: whether coding agents lean toward built-in APIs or pile up custom code is an open question the author leaves unresolved.
Who it affects
Front-end and web developers who choose between npm packages and built-in browser features, and the standards, performance and accessibility advocates who try to persuade them. The author says the pattern applies to any developer building on a platform layer they do not fully understand, and names iOS, Android and game engines as likely examples. Developers who use AI coding agents are affected by the closing speculation about what those agents will prefer.
How to use it
The essay is not a tool, but it offers a few practical habits drawn from its examples. Before building something yourself, read the documentation of the platform you are on; the author's ClickHouse fix came from reading the docs and writing a benchmark. Check whether the platform already has a primitive, such as
How solid is it
This is a personal opinion essay. The argument rests on the author's experience (years on PouchDB tooling for IndexedDB and WebSQL, W3C meetings, a ClickHouse episode at work) and not on data. No survey, statistics or study on how many developers avoid platform features are given. The ClickHouse benchmark results are not shown, so how much slower or clunkier the homemade approach was is not quantified. The AI optimistic and pessimistic takes are speculation, with no evidence or named tools cited. The author calls his own thoughts "longwinded and somewhat conflicting" and does not declare a winner.
Risks and caveats
The reasons offered are plausible explanations, not measured causes, and the essay itself says third-party libraries versus platform APIs cannot fully explain the antipathy. The Safari figure of about 7 releases a year is a parenthetical aside with no source or year. The claim that browsers were uneven until about the 2020s is approximate. The author also warns that building your own is not always good and can come from pure ignorance, and that "use the platform" can feel obvious from a position of hard-won expertise. On AI, both scenarios are guesses; treat neither as a forecast.
“I’m sure we’ll be hearing “use the platform” for as long as there are platforms.”
— From the closing paragraph of the essay