Nolan Lawson Examines Why Developers Shun Browser Standards
Developer Nolan Lawson analyzes why browser standards see slow uptake, citing historic delays, npm habits, and documentation gaps.
On October 3, 2026, developer Nolan Lawson published an essay on his blog discussing why “use the platform” has failed to take hold. Coverage of nolanlawson.com by nolan on Lobsters notes his long history of advocating for the use of standard features from the perspectives of web standards, performance, and accessibility.
His argument is straightforward. There is no need to reimplement in JavaScript what browsers already provide natively. Custom implementations are likely to be inferior in terms of performance and usability. Yet, given that many developers still need convincing, he argues for the need to consider the other side’s perspective.
why build something yourself, in JavaScript, when the browser can do it for you?
This question captures the basic stance of standards advocates. The essay is notable for organizing the reasons why that stance, despite seeming self-evident, has not spread, examining history, habits, and documentation.
Delayed Browser Implementations and
Historical Context
The first factor cited for the slow uptake of standard features is the historical delay in browser implementations. For a long time, browsers lagged behind the ecosystem built on top of them. Libraries like jQuery filled critical gaps. Even after browsers implemented equivalent APIs, developers could not rely on standards alone as long as legacy environments like IE6 remained.
In the 2020s, many browsers shifted to evergreen updates. Although debate remains over Safari’s update frequency, it has maintained roughly seven updates per year. Conditions for using standard features are now falling into place. For developers who experienced the fragmented web environment before that, however, building their own implementations was a rational choice.
This history persists as institutional memory. Teams that prioritize guaranteed operation and backward compatibility continue to choose proven implementations. Even as standards mature, the caution born of past struggles does not easily fade. Historical context is not just a thing of the past; it shapes current preferences.
There is a time lag between what platforms provide and what teams adopt. As shown in Windows 11 auto-installs OneDrive Photos with no way to remove it, cases where platform-provided features miss real-world expectations are not uncommon. Likewise, for browser standards, the existence of an implementation and trust in practical use are seen as separate issues.
Convenience of the npm Ecosystem and the
Barrier of Habit
The second factor is the strength of development habits centered on npm. Developers accustomed to searching for React components choose the same approach regardless of the nature of the problem. Searching npm for sticky positioning will not surface a package advising “use CSS position: sticky.” The search-and-install path itself is structured to encourage choosing external dependencies.
There is a usability gap between frameworks and the platform. Even when robust standards exist, packages that tailor usability for frameworks serve as useful bridges. It is only natural that developers choose abstractions they can use in familiar syntax over handling standard APIs directly.
React developers’ behavior underscores this trend. While insisting on JSX and React-style syntax, they tend to avoid raw DOM manipulation. There is resistance to direct DOM APIs. Yet they tolerate performance-focused libraries, such as virtualized lists, using raw DOM manipulation internally.
Surface-level developer experience and underlying implementation are decoupled. If high-level components easy enough for beginners are provided, low-level processing inside is not questioned. The ecosystem has created a division of labor in which experts rewrap platform APIs and distribute them in beginner-friendly form. While efficient, this division also weakens interest in the underlying platform.
Documentation Coverage and the Gap in
Persuasiveness
The third factor lies in documentation. Many npm packages come with polished documentation and official sites. With usage examples, instructions, and screenshots, the path to adoption is clear. Information needed for comparison and adoption decisions is gathered in one place.
By contrast, documentation for the web platform was long fragmented. Information was scattered across personal blogs, StackOverflow, and tutorial sites like CSS Tricks. Consistent guidance was hard to find until MDN became established as the reference and Google’s web.dev took on forward-looking communication.
Explanations from that fragmented era often recommended using external dependencies. Using jQuery or GreenSock was presented as the standard solution. The perception spread that proven external tools were more reliable than the platform’s standard features.
As a concrete example, the essay contrasts the Dragula site with MDN’s drag-and-drop documentation. The former is still rated as more compelling. Apart from technical correctness, quality of presentation sways choices. Documentation quality and experience design determine adoption as much as technical merit.
The Benefits of Division of Labor and Abstraction
The division of labor described in the essay cannot be explained as mere laziness. Framework users gain productivity because platform details are hidden from them. Experts handle areas where performance is critical, such as virtualization and rendering optimization. Ordinary developers consume the results as components. This layering meets the needs of large-scale development.
Abstraction lowers learning costs. Developers can achieve desired behavior without reading raw DOM APIs or specifications. In teams constrained by deadlines and staffing, this shortcut takes priority. Even if direct use of standards is ideal, using components wins on cost-effectiveness in some cases.
Conformity to framework conventions also matters. In teams used to JSX, standard syntax is treated as foreign. For consistency and ease of review, components that follow house style are chosen. Technical correctness and team maintainability are separate criteria.
Under this structure, knowledge of the platform concentrates among a few specialists. Many developers can deliver results without thinking about the platform. The ability to investigate problems and replace components declines. Standards advocates are concerned that trading understanding for efficiency has become normalized.
Distrust of Standard Features and Remaining
Challenges
Developers’ distance from standards is not simply lack of knowledge. It reflects accumulated experience of incomplete standards, fragmented documentation, and gaps in persuasiveness. Developers have rationally chosen external tools. That decision-making pattern persists in the era of evergreen browsers.
The standards side also has challenges. The process from specification to implementation, documentation, and dissemination is long. It lacks the agile improvements and attractive presentation of external packages. That a feature exists and that teams want to use it are different things. Design for the latter is lacking.
The future focus is on discoverability and onboarding for standard features. When developers search, is the standard solution shown first. Do official docs provide immediately usable information with concrete examples. Are bridges for frameworks officially provided. Unless these conditions are met, inertia favoring external dependencies is expected to continue.
The essay does not reject standards advocacy. Rather, it argues advocates need to understand the other side’s circumstances. Sound arguments about performance and usability alone will not change behavior. Facing the realities of history, habits, documentation, and division of labor is the shortcut to wider adoption.
Editorial Opinion
In terms of short-term impact, we expect co-use of standard features and external packages to continue for the next 3-6 months. Teams will not remove proven dependencies. Packages with compelling documentation will keep being chosen. We assess that browser updates alone will not change preferences. Organizations will measure replacement costs and limit themselves to gradual reviews.
From a long-term perspective, we see uneven platform knowledge becoming an issue in 1-3 years. Understanding of standards will not advance behind abstractions. Gaps will emerge in troubleshooting and performance tuning. We assess that whether education and documentation catch up will be the turning point. If official documentation improves in experience, a return to standards could occur.
As a question from the editors, we believe who should provide the bridge is at issue. Should the standards side provide framework-friendly usability. Should it be left to community packages. How should discoverability be ensured in search and documentation. Unless these design philosophies are settled, slogans alone will not drive adoption.
References
- “Why don’t more developers “use the platform”?“, by nolanlawson.com by nolan — Lobsters, 2026-10-03T21:35:28.000Z (ARR)
- Source URL: https://nolanlawson.com/2026/10/03/why-dont-more-developers-use-the-platform/
Frequently Asked Questions
- What is "use the platform"?
- It is the idea of prioritizing features browsers provide natively. It means implementing with standard CSS and DOM APIs what can be achieved with them, without relying on external scripts. It aims to improve performance, usability, and maintainability. This essay discusses strategies for its wider adoption.
- Why are external libraries chosen despite available standards?
- The cited reasons are historical implementation delays, npm-centered habits, and differences in documentation persuasiveness. Experience from the IE6 era left a cautious attitude. External packages with polished documentation tend to be chosen. The division of labor also weakens interest in the platform.
- How should development teams respond going forward?
- Auditing standard features and assessing replacement costs is effective. For new development, make the standard solution the first candidate. For areas where performance is critical, use abstractions built by specialists. Improving official documentation with concrete examples is key to wider adoption.
Comments