Why “Use the Platform” Is Harder Than It Sounds

You’re halfway through a dashboard when a small request lands: open a panel, keep the page behind it from scrolling, close it with Escape, and return keyboard focus to the button that opened it. A search for “modal component” produces hundreds of polished packages. The web platform—the HTML elements, CSS rules, and JavaScript interfaces built into the browser—offers an answer too, but it is hidden behind a few unfamiliar names. Reaching for a library feels less like rejecting standards and more like choosing a well-lit path.

That is why “use the platform” is good advice but poor sociology. Developers choose tools based on history, documentation, team habits, and the pleasure of making something work—not only on whether a browser feature exists.

The browser used to be the unreliable dependency

For a long time, the browser was the dependency you distrusted. Features arrived unevenly, old versions lingered in production, and two browsers could interpret the same CSS or JavaScript differently. A library could smooth over those cracks and give a team one interface to learn.

That history still shapes modern development. Even when browsers are more consistent, old habits remain in codebases, tutorials, interview advice, and team conventions. A group with a component library, a design system—a shared set of visual and interaction rules—and years of tested code has a practical reason to keep using it.

“Use the platform” also sounds different depending on when you learned the web. Someone who began with jQuery learned to hide browser differences. Someone who began with a modern component framework learned to compose reusable components. Neither instinct is irrational. Each one reflects the problems that were visible at the time.

The real barrier is discoverability

A package registry such as npm is a catalog organized around tasks. Search for a date picker, sortable list, or modal and you will find names that describe the thing you want. The package README usually includes a copyable example, a screenshot, and an explanation aimed at getting you moving before lunch.

Browser features are not always named that way. The solution to a sticky header is position: sticky. The solution to a modal’s focus and background behavior is often <dialog>. The solution to a lightweight floating surface may be the Popover API. You need to know the platform vocabulary before you can search for it.

This is a documentation problem as much as a technical one. A standard describes exact behavior across many situations; a library README tries to show one successful path. Precision matters, but it can feel like friction when all you want is a button that opens a panel.

The question that sends many developers to a package registry is: should this be a library or native HTML? Often, the answer depends on which API gives the team the clearest mental model.

A native dialog removes invisible work

Consider a confirmation window. A hand-built version might use a div, absolute positioning, a backdrop, a z-index, and JavaScript to prevent the page from scrolling. Then come the less visible requirements: move focus into the window, keep keyboard focus inside it, close on Escape, make the background inert—meaning unavailable to interaction—and restore focus when the window closes.

The native <dialog> element does not provide your product’s colors or layout, but it takes responsibility for much of that generic behavior:

<button id='open-dialog' type='button'>Delete note</button>

<dialog id='delete-dialog' aria-labelledby='delete-title'>
 <form method='dialog'>
 <h2 id='delete-title'>Delete this note?</h2>
 <p>This action cannot be undone.</p>
 <button value='cancel'>Cancel</button>
 <button value='delete'>Delete</button>
 </form>
</dialog>

<script>
 const openButton = document.querySelector('#open-dialog');
 const dialog = document.querySelector('#delete-dialog');

 openButton.addEventListener('click', => dialog.showModal);

 dialog.addEventListener('close', => {
 if (dialog.returnValue === 'delete') {
 deleteNote;
 }
 });
</script>

The showModal call opens the dialog as a modal surface. The form’s method='dialog' lets its buttons close the dialog, while the button value becomes the dialog’s result. You can style the dimmed background with dialog::backdrop and add the application-specific deletion logic yourself.

This still requires judgment. You need a useful title, a sensible initial focus target, and a visible way to cancel. Accessibility—the practice of making software usable with different abilities and input methods—is not automatic in every design decision. Still, a native primitive removes a large section of generic behavior that is easy to get almost right and difficult to get completely right.

Native is a floor, not a component library

The browser is also taking back jobs that once required small JavaScript utilities. CSS can handle sticky positioning, line clamping, and reserved scrollbar space. Newer sizing features can make form controls respond to their content instead of forcing every input into a fixed box.

The Popover API shows both the promise and the boundary of the platform. A small floating surface can be connected to a button without writing a click listener:

<button popovertarget='filters'>Filters</button>

<div id='filters' popover>
 Filter options go here.
</div>

The browser can place the popover in its top layer, a browser-managed plane above ordinary page stacking, and handle light dismissal when the user clicks outside it. But a popover is not automatically a complete menu. Keyboard arrow-key behavior, roles, labels, and the relationship between the control and its content still depend on the component you are building.

That boundary explains why good wrappers continue to exist. The platform supplies mechanics; a local component can supply your application’s vocabulary, styling, state conventions, and tests. A wrapper that uses <dialog> underneath is not betraying the platform. It is making the platform easier for a particular team to use.

Sometimes building it is the lesson

There is another reason developers write their own widgets: it is fun. A custom modal becomes a small laboratory for learning the Document Object Model, or DOM—the browser’s tree of page elements—along with focus, events, layout, and CSS stacking contexts.

That work can create real expertise. You discover why a page scrolls behind an overlay, why a focus trap can strand keyboard users, and why a visual fix may fail when text becomes larger. The code you built yourself also has the IKEA effect: people tend to value and understand things more deeply after assembling them.

The trade-off changes when a prototype becomes production infrastructure. At that point, every missing edge case becomes your team’s maintenance problem across keyboard navigation, touch screens, zoom, screen readers, animations, and browser changes. Learning by building is worthwhile. Shipping a learning exercise forever is a different decision.

A better rule than a slogan

A useful version of “use the platform” is not “never install a package.” It is a sequence of decisions:

• Start with semantic HTML—a real button, form, dialog, select, or details element—before recreating one with generic containers.
• Check CSS before adding JavaScript for layout, scrolling, sizing, or text overflow.
• Wrap a native feature when your team needs a consistent API or visual language.
• Choose a library when it solves a genuine gap, packages difficult interaction behavior, or saves you from supporting environments your project cannot avoid.
• Build from scratch when the platform does not fit and you are prepared to own the testing and accessibility work.

The platform is not a religion, and libraries are not a failure of imagination. Native HTML and CSS are valuable because they can prevent whole classes of bugs before you write them. Libraries are valuable when they package hard-won knowledge into a form people can actually use. The mature habit is knowing which kind of help you need.