For years, advocates for web standards and performance have pushed developers to “use the platform”—to leverage native browser capabilities instead of building custom solutions in JavaScript. Yet many developers continue to build their own tools, raising the question: if using platform features is so obviously better, why do developers need convincing?
According to Nolan Lawson, a developer and standards advocate, historical factors partly explain this pattern. Browsers spent decades playing catch-up with the JavaScript ecosystem. Libraries like jQuery filled crucial gaps while browser APIs matured. Developers working through the Internet Explorer era had to wait years before they could safely rely on modern APIs, making custom solutions a practical necessity. Though most browsers are now evergreen, the habit persists.
Familiarity also drives the behavior. Developers accustomed to searching npm for React components tend to do so by default, regardless of whether a platform API already solves the problem. Libraries on npm often bridge the gap between framework ergonomics and raw browser APIs, providing a more comfortable interface for developers uncomfortable with native DOM manipulation.
Documentation played a significant role historically. Before MDN became the standard reference and web.dev launched, platform documentation was scattered across blogs and StackOverflow, often recommending third-party libraries instead. Many npm packages offered superior documentation with detailed READMEs, tutorials, and examples compared to platform API docs.
Beyond convenience, some developers find building custom solutions more engaging. Constructing a modal dialog from scratch—handling positioning, scrolling, accessibility, focus management—teaches valuable lessons about the platform. Developers who authored polyfills and libraries often developed the expertise that led them to advocate for platform adoption, creating a paradox where today’s platform advocates were yesterday’s custom solution builders.
However, building custom solutions sometimes stems from incomplete platform knowledge. CSS, for instance, has been notoriously difficult to understand, leading developers to solve layout problems with JavaScript. Similarly, for years CSS lacked straightforward solutions for common patterns like line clamping or textarea resizing, making custom implementations rational.
Lawson notes this phenomenon extends beyond the web. When developers work on unfamiliar platforms—whether ClickHouse databases, iOS, or game engines—they often build redundant solutions that duplicate platform functionality, learning only after deeper investigation that the platform already handled the problem better. The pattern suggests that platform skepticism often reflects incomplete understanding rather than conscious choice.
Key facts
- Developers historically built custom solutions because browsers lagged the JavaScript ecosystem, a pattern that persists despite modern evergreen browsers
- Familiarity with npm and frameworks like React drives developers to reach for libraries by default rather than evaluating platform APIs
- Before MDN standardized web documentation, platform API guidance was scattered and often recommended third-party libraries instead
- Some developers find building custom solutions more engaging and educational than using platform features, which can build expertise
- Developers sometimes avoid platform features due to incomplete knowledge of how those features work, particularly with CSS