Why don’t more developers “use the platform”?
Short summary
Nolan Lawson explores why developers often build custom solutions instead of using built-in browser and platform capabilities, tracing the reasons from historical browser gaps to the genuine appeal of building things yourself. He argues that understanding this skepticism matters more than simply repeating "use the platform" as advice.
- Developers prefer custom solutions partly from habit and familiarity with npm ecosystems, but also because building things yourself is genuinely more engaging and educational than reaching for a ready-made API.
- Poor documentation and scattered resources historically made it easier to find and use third-party libraries than to discover what the platform could already do, though this has improved with MDN and web.dev.
- Most "avoid the platform" behavior stems from incomplete knowledge of how the underlying system works—developers build custom solutions not out of laziness but because they don't fully understand what the platform offers, a pattern that applies across all development domains, not just the web.
Full summary
Nolan Lawson explores why developers often ignore advice to "use the platform" — building custom solutions in JavaScript instead of relying on native browser APIs. He traces this partly to history: browsers lagged behind JavaScript libraries for years, so developers got used to rolling their own. jQuery filled real gaps while waiting for IE6 to die. Now that browsers are mostly evergreen and APIs have matured, that habit persists. Familiarity compounds the problem — developers reach for npm packages out of reflex, even when CSS or HTML could solve the problem directly. Documentation also played a role: before MDN solidified as the standard reference, scattered tutorials and blogs often just told you to use an existing library like jQuery or GreenSock instead of explaining the platform itself.
But the real tension goes deeper than convenience or ignorance. For many developers, building things from scratch is genuinely more enjoyable and educational. Constructing a modal dialog from scratch teaches you about positioning, z-index, focus management, accessibility — you learn the platform by necessity. Lawson himself built polyfills and libraries for IndexedDB and WebSQL as part of PouchDB work, which eventually gave him enough expertise to contribute to W3C standards. That learning path wouldn't exist if the APIs had been complete from the start. CSS provides another example: developers built JavaScript solutions for problems CSS couldn't elegantly solve (line clamping, textarea resizing) because understanding CSS's internal logic felt harder than just coding imperatively.
Lawson illustrates the broader pattern with a ClickHouse example from his own work. He and a coworker both built custom solutions for storing JSON data — one compressing before storage, the other using a separate key-value store — when ClickHouse already handled compression automatically and would perform better with raw columnar storage. Only after reading the documentation thoroughly and benchmarking did he realize they'd made something slower and clunkier than what the platform provided. The lesson applies everywhere: ignorance of how your underlying platform works leads to reinventing wheels, but that same process of building and learning is often how developers develop real expertise.