Why don't more developers “use the platform”?
Nolan Lawson examines why web developers frequently bypass native browser features for third-party libraries, highlighting historical lag, ecosystem familiarity, documentation, and the appeal of custom building.
read it A nuanced take on web development philosophy that resonates with anyone building on top of complex software platforms.
summary
Nolan Lawson explores the persistent resistance among web developers toward using native browser APIs, a phenomenon often criticized as ignoring platform standards. He attributes this avoidance not just to historical browser inconsistency and poor native documentation, but also to familiar workflows, UX/design requirements, and the sheer enjoyment of building custom solutions. Drawing parallels to other software stacks like databases, he notes that while leveraging the platform reduces maintenance, understanding why developers reinvent the wheel helps bridge the gap between standards advocates and builders. The discussion expands on this tension, with engineers pointing out genuine gaps in native elements like date pickers and comboboxes.
key points
- Historically, slow-moving or inconsistent browser standards forced developers to rely on third-party libraries like jQuery and polyfills just to get basic functionality.
- Familiarity with npm ecosystems and superior third-party documentation heavily incentivizes developers to reach for frameworks rather than native primitives.
- The IKEA effect and creative satisfaction drive many developers to build custom UI components rather than settling for rigid or limited native elements.
- Real-world UI/UX requirements often outpace what native elements like dialog or datalist can support, necessitating custom implementations.
who should read it
Web developers and software engineers interested in architecture, browser standards, and developer experience.
discussion mixed
consensus
Most commenters agree that native browser elements historically lacked the flexibility, styling control, or feature completeness required for modern UX, making third-party tools a practical necessity rather than mere laziness.
pushback
A minority view pushes back against total reliance on third-party abstractions, arguing that developers often lean on familiar frameworks out of habit rather than actual platform limitations.
Coming from a more general programming view, I find web development extremely odd. In general programming we tend to find a small set of abstractions which we can use in a composable way to cover our problem space.
For example, to interact with the VFS, we have read()/write(). When we add more APIs, it can be to enable a new paradigm, like epoll(), or for performance, like readv()/writev(). For a functionality that can be composed out of existing APIs in a performant way, we do not add it in the platform, but leave it instead to the domain of libraries. This separation has immense values, as …
It draws an insightful parallel between web development and general systems programming, questioning why composing native web building blocks is treated as an anti-pattern.
Generated by an LLM from the article and thread. Check the sources before relying on it.