Nolan Lawson on why developers keep bypassing native web platform features

Nolan Lawson, a developer who spent years working on PouchDB and in W3C standards discussions, has published an essay examining why so many web developers ignore the long-standing advice to "use the platform" — that is, to rely on what browsers already provide rather than rebuilding those capabilities in JavaScript. The piece surfaced on the Hacker News front page.

The argument he is pushing back on

Advocates of web standards, performance and accessibility have made a simple case for years, Lawson writes: whatever you build yourself will probably run slower and be less usable than an equivalent browser feature. Lawson counts himself among those advocates, but argues that the persistence of the skeptics deserves a genuine explanation rather than dismissal.

History made hand-rolling rational

The most obvious reason, according to Lawson, is historical. For long stretches, browsers lagged behind the ecosystem layered on top of them, and libraries like jQuery filled real gaps. Even once browsers implemented a standard API, developers often had to wait for stragglers such as IE6 to fade before they could rely on it. He characterises the web up until roughly the 2020s as uneven, and says building your own solution was a sensible default in that environment. Most browsers are now evergreen, he notes, with Safari the debatable case at roughly seven releases a year.

Habit, ergonomics and documentation

Familiarity matters too. Developers accustomed to searching npm for React components will reach for npm whatever the problem is; Lawson observes that a search for sticky positioning on npm returns packages, not a note pointing out that CSS already handles it. He describes a division of labour in which library authors use raw DOM APIs internally for speed while exposing higher-level primitives to framework developers who find direct DOM work off-putting.

Documentation amplified the effect. npm packages ship with polished READMEs and example sites, whereas platform documentation was scattered across blogs, Stack Overflow and sites like CSS-Tricks until MDN — with web.dev as Google's more forward-looking arm — became the default reference. Comparing the Dragula library's site with MDN's drag-and-drop page, Lawson suggests the library's marketing remains the more convincing of the two.

Building it yourself is how people learn

Lawson's sharpest point is that laziness cannot explain the resistance. Developers who just want a ready-made answer do not care whether it comes from npm, the browser or a random gist. Instead, he argues, a certain kind of developer finds building things more fun, finds the resulting code easier to reason about, and grows attached — an IKEA effect — to something assembled by hand. He walks through constructing a modal dialog with position: absolute, z-index, scroll locking, Escape-key handling, focus trapping and focus restoration: a chore for some, an enjoyable education for others, and one that might end in a publishable library rather than a one-line use of the native dialog element.

That path, he says, is precisely how platform expertise forms. Many of today's use-the-platform advocates began as authors of polyfills, shims and libraries. Lawson traces his own work on IndexedDB and WebSQL tooling within PouchDB to the confidence to sit in W3C standards meetings and to open issues and pull requests against the IndexedDB specification. Without a gap in the platform to fill, he doubts he would have reached that level of expertise.

When it goes wrong, on the web and off it

He does not romanticise the instinct. Sometimes bypassing the platform is plain ignorance, as with the many JavaScript solutions to problems CSS handles better — driven partly by developers never learning CSS's model, and partly by CSS historically lacking straightforward answers for patterns like line clamping. The pattern also extends beyond the web: at his workplace, Lawson and a colleague independently built competing workarounds for storing large JSON blobs in ClickHouse, one pre-compressing the data and the other offloading it to a separate key-value store. Both turned out to be wrong. After reading the documentation and running a benchmark, Lawson found that ClickHouse's own compression and columnar storage outperformed both hand-rolled designs.

Why it matters

The essay reframes a long-running culture-war argument as a systems and incentives problem. If developers bypass native capabilities, the remedy is not louder exhortation but better discoverability and documentation, plus recognition that hand-rolling is how many people come to understand the platform at all. For engineering teams, the ClickHouse anecdote carries a practical lesson: benchmark what the platform already does before building around it. For browser vendors and standards advocates, it implies that the route to adoption runs through the same polished developer experience that npm packages have offered for years.