For years, advocates for web standards, performance, and accessibility have urged web developers to 'use the platform' — meaning to rely on built-in browser capabilities rather than building custom solutions or reaching for libraries. The argument is straightforward: why build something yourself in JavaScript when the browser can provide equivalent functionality out-of-the-box with better performance and usability? Yet many developers seem resistant to this advice. Understanding why requires looking beyond surface-level explanations. Historical factors play a significant role. For much of the web's history, browsers lagged behind developer needs, forcing creators to fill gaps with libraries like jQuery. Developers had to wait for outdated browsers like IE6 to fade before standardized APIs could be safely adopted. This created an environment where rolling your own solutions was often the only practical choice, establishing habits that persisted even as browsers became evergreen. Familiarity with existing ecosystems also shapes behavior. Developers accustomed to searching for React components on npm will naturally reach for those tools first, even when platform solutions exist. There's no npm package that simply says 'just use CSS position: sticky, you dolt' — instead, the ecosystem trains developers to look for packaged solutions rather than considering what the browser already provides. Documentation quality further reinforces this pattern. While npm packages typically feature lovingly detailed READMEs, websites with examples, tutorials, and screenshots, web platform documentation was historically scattered across blogs, StackOverflow, and sites like CSS Tricks. Until MDN became the authoritative reference (with web.dev as a more future-facing complement), learning platform features required piecing together information from disparate sources, making libraries with centralized documentation more appealing. Beyond practical considerations, building custom solutions often provides intrinsic enjoyment. Creating a modal dialog from scratch, for instance, involves understanding positioning, z-index, overflow handling, Escape key dismissal, focus trapping, and returning focus to the originating element — a process that, while complex, can be deeply engaging. Many developers find this kind of problem-solving fun and educational, leading to what psychologists call the 'IKEA effect': valuing what we build ourselves more highly than prefabricated alternatives. This enjoyment has historical significance in web development. Many of today's strongest advocates for 'use the platform' once authored polyfills, shims, and libraries themselves. The author notes that years spent working on IndexedDB, WebSQL, and other browser storage APIs through projects like PouchDB built the expertise needed to participate in W3C standards discussions. Without platform gaps requiring filling, that motivation to deeply understand underlying systems might not have emerged. However, avoiding the platform isn't always beneficial. Sometimes it stems from pure ignorance about how technologies like CSS actually work. Historically, CSS has been perceived as unintuitive — requiring techniques like clear fixes, float handling, and min-width: 0 tricks that aren't obvious — leading developers to implement solutions in JavaScript simply because they understood imperative logic better than declarative styling. For years, CSS lacked straightforward ways to express common patterns like line clamping, textarea resizing, or scrollbar hiding, pushing developers to recreate these features using familiar tools. The phenomenon isn't unique to web development. The author describes a similar experience with ClickHouse, where a colleague's attempt to compress JSON data before storage and the author's alternative approach using a separate key-value store were both unnecessary. ClickHouse automatically compresses data and, as a columnar store, provides better cross-row compression when left to handle storage natively — a realization that came only after reading the documentation and building benchmarks. Looking ahead, the author considers how AI coding assistants might influence this dynamic. Optimistically, large language models possess encyclopedic knowledge of platforms and could select exactly the right API to fulfill natural language prompts, potentially preferring platform solutions after testing and benchmarking. Pessimistically, LLMs tend to duplicate existing code rather than reusing helper functions, possibly increasing non-platform-idiomatic code if developers accept first drafts without sufficient exploration of alternatives or continue iterating on over-engineered solutions. Ultimately, the tension between using platforms and building custom solutions reflects a deeper truth about developer growth: the more one understands how entire systems work end-to-end, the better equipped they are to make minimal, valuable contributions. Yet the joy of creating something from scratch — beautiful to its creator, even if not objectively elegant — ensures that the question of 'why don't more developers use the platform?' will remain relevant as long as platforms exist.
Author portrait illustrating the perspective of a developer who has experienced both building custom solutions and advocating for platform use.