A while ago I was about to install another dropdown library. I'd already added one for modals and one for tooltips. Somewhere between npm install and opening the docs, I stopped and asked myself a dumb question: why am I doing this?
The browser already has a dropdown. It already has a modal. It already has an accordion. I was about to spend a weekend — and a few hundred kilobytes of JavaScript — rebuilding things my browser ships for free.
That was the moment I realized I'd been fighting the browser for years without noticing.
What "fighting the browser" looks like
Modern frontend has a reflex: reach for a library for everything. And to make those libraries look custom, you reset all the defaults, override the styles, and reimplement the behavior — keyboard navigation, focus trapping, ARIA roles, form integration.
The problem is that you get that behavior subtly wrong. I'm one developer. I am not going to out-engineer the people who built the browser's <select>. Every time I reimplemented one of these, I quietly reintroduced accessibility bugs the browser had already solved — and shipped more code to do it.
The shift: adapt, don't fight
So I gave myself one rule: the browser owns the behavior, I only own the looks.
- Need a modal?
<dialog>. It already does focus trapping, Esc-to-close, a backdrop, and it renders above everything in the top layer. I just style how it looks. - Need an FAQ or accordion?
<details>+<summary>. Open/close and keyboard support, free. - Need a dropdown?
<select>. Accessible, keyboard-friendly, uses the native picker on mobile, and submits with the form. I would never have built it that well. - Need a slider?
<input type="range">.
The objection I had to get over
You're probably thinking what I thought: "but native elements are ugly and you can't style them."
That was true years ago. It mostly isn't now. Modern CSS lets you style form controls, a dialog's ::backdrop, accent colors, the open/close states — way more than most of us realize. In 2026, "you can't style native elements" is a habit, not a fact.
Native-first does not mean unstyled. I style mine heavily. It means the browser keeps the behavior, and I take the paint.
Where I still go custom
I'm not a purist about it. Some things genuinely have no native equivalent — a filterable combobox, a command palette (Cmd+K), a multi-handle slider. Those I build. But even then I wrap and extend the native pieces instead of starting from zero.
The point isn't "never write JavaScript." It's "don't rebuild what you already have."
Why this mattered so much for me
I built my whole design system solo. Native-first is the only reason that was even possible. Leaning on native elements means:
- less JavaScript to ship and maintain,
- accessibility I get mostly for free instead of bolting it on later and getting it wrong,
- forms and mobile that just work.
My components got thinner. My bugs went down. And the few things I did build custom got the attention they deserved — because I wasn't burning it re-creating a dropdown.
This isn't a thought experiment for me. It's the foundation of a design system I've been building. It's not out yet, but native-first is the principle everything else sits on — and I'll be writing about the rest as I go.
If you take one thing from this: next time you reach for a dropdown library, open the docs for <select> first. Next time you need a modal, try <dialog>. You might delete more code than you write — and that's the good kind of progress.