Why Don't More Developers Just Use the Web Platform?

What does “use the platform” mean?

The “platform” in this phrase means the web browser itself. Modern browsers come with many built-in tools for common jobs, such as showing dates, playing video, checking forms, or opening dialog boxes.

To “use the platform” means to use those built-in tools instead of writing your own version in JavaScript. JavaScript is the programming language that lets websites do interactive things in the browser.

For years, people who care about web standards, speed, and accessibility have urged developers to take this approach ¹. Web standards are shared rules that help browsers work in the same way. Accessibility means making sites usable for people with disabilities, including people who use screen readers or keyboards.

The idea is simple to state. If the browser already offers a feature, why build it again yourself ¹? A discussion on October 3, 2026, by developer Nolan Lawson revisits this long-running request and asks why it has not convinced everyone ¹.

The word platform can be confusing because it is used in other ways in tech. For example, one open-source project describes itself as a data export platform for sending data to a customer’s warehouse, with examples including Snowflake, BigQuery, and Redshift ². In the phrase “use the platform,” though, the platform is the browser, not that kind of data tool.

Why do supporters say using the browser is better?

The main claim is practical. A feature built into the browser is likely to run faster and work more smoothly than a custom copy made with JavaScript ¹. That matters on slower phones and slower connections, where extra code takes longer to load and run.

Built-in features also tend to handle details that are easy to overlook. That includes keyboard use, touch screens, different screen sizes, and assistive tools. When developers rebuild a feature, they must redo all that work, and it is easy to miss something.

Supporters also point to upkeep over time. A custom tool needs testing and fixes as browsers change. A browser feature gets upkeep from the browser maker itself.

For an ordinary reader, this can show up as pages that load faster, buttons that behave as expected, and forms that are easier to complete. It is not a guarantee, but it is the reason advocates keep repeating the advice ¹.

The advice is often linked to wider goals. Web standards supporters want pages that work across browsers. Performance supporters want pages that load quickly. Accessibility supporters want pages that work for everyone. Using more of what the browser provides is seen as helping all three aims ¹.

Why don't more developers follow this advice?

The most direct answer is history. For a long time, browsers lagged behind what developers needed ¹. Libraries, which are shared collections of ready-made code, filled the gaps while browsers slowly added matching tools.

One well-known example is jQuery. It helped developers do common tasks in a time when browsers did not offer simple, matching methods ¹. Even after browsers added those methods, developers often could not use them right away.

That is because older browsers stayed in use for years. The post points to IE6, an old version of Internet Explorer, as a browser people had to wait to fade away before they could rely on newer features ¹. In that setting, building your own solution was often the sensible choice.

Until around the 2020s, support across browsers was uneven, described as a “lumpy web” ¹. Developers learned to expect differences between browsers and versions. That lesson does not disappear quickly, even when conditions improve.

Another reason is familiarity. Developers tend to reach for tools they already know ¹. If a team already uses a JavaScript method that works, switching to a browser feature takes time to learn, test, and trust. For busy teams, the known path can feel safer, even if the browser path is shorter on paper.

Have browsers caught up now?

In broad terms, yes, compared with the past. As of October 2026, most browsers are described as evergreen ¹. Evergreen means the browser updates itself often in the background, so most users stay on a recent version without having to install updates by hand.

That change matters for developers. It means they can rely on newer features sooner, without waiting years for old versions to disappear. The post notes that Safari is still debated in this group, while noting it updates about seven times per year ¹.

But “caught up” does not mean perfect or identical. Browsers still differ in details, timing, and small bugs. Teams that serve many users may still test widely across phones, computers, and browser versions.

Past gaps also left behind habits, training materials, and starter code that favor custom JavaScript. Even when a browser feature exists today, a team may keep using an older approach because it is already in their codebase and their workflow.

So the present is mixed. The technical case for using built-in features is stronger than it was, but trust takes longer to rebuild than software.

What does this mean for an ordinary reader?

You do not need to choose tools yourself to feel the effects. When sites lean heavily on custom JavaScript, pages may be larger to download and slower on older phones. When sites use more built-in browser features, they may load faster and work better with keyboards and screen readers.

That does not mean all custom code is bad. Some sites need special designs or behavior that browsers do not offer. The question is whether a custom rebuild is needed, or whether the browser already does the job well enough.

If you browse or manage a site, you can ask simple questions. Does the page feel slow? Do forms give clear errors? Can you use it without a mouse? Those are signs of how well the underlying choices fit your needs, whatever tools were used.

If a site has serious access problems, reporting the issue to the site owner is often more helpful than changing your own settings. For learning more, official browser guides and accessibility guides are useful starting points. And as with other tech claims, it helps to remember that one blog discussion reflects one view of a wider debate ¹.