The slogan skips the hard part.
Nolan Lawson asks why developers still avoid browser features that can replace custom JavaScript. His answer is not contempt. He points to old compatibility gaps, familiar framework habits, better package documentation, and the simple pleasure of building a thing yourself.[1]
That diagnosis matters for coding agents. An agent can produce a polished custom overlay before anyone asks whether <dialog> already handles the job. It can also reach for a native element without checking your browser target or product behavior. Both shortcuts turn "use the platform" into guesswork.
Native-first is a test order. It is not a purity rule.
Start with the job, not the tag.
A modal dialog blocks interaction with the rest of the page. A non-modal dialog does not. MDN says showModal() makes the other page content inert. It also documents Escape as a close route for modal dialogs.[2]
A disclosure has a different job. The <details> element reveals information when its summary is toggled. Its native interaction includes pointer activation and Space when the summary has focus. MDN also documents the name attribute for groups where one disclosure stays open at a time.[3]
Those parts are not interchangeable. A package comparison that begins with screenshots will miss the behavior contract. Write one sentence first: "This control must block the page until the user confirms" or "This section hides optional setup notes." Now there is a job to match.
Support belongs in the decision.
A native feature can fit the job and still miss your supported browsers. Baseline gives web features two broad availability stages and checks them against a core browser set. The project also points to tooling in Lighthouse, Browserslist, ESLint, and Visual Studio Code.[4]
Use that data as one input. Your own browser policy and audience still decide the target. Test the exact feature you plan to ship. A broad label for an element does not prove every related attribute or command is ready for your users.
Wrapping is often the honest answer.
A thin component can keep framework ergonomics while leaving focus, keyboard behavior, and page blocking to the browser. It can add product copy, telemetry, styling, and a stable application API. That is different from rebuilding the browser behavior inside a generic <div>.
Sometimes the native part does not fit. Say why. You may need an interaction the part does not support, a browser outside your target, or a product constraint that changes the job. Keep the exception beside the code so the next maintainer can retest it.
Make the agent show its receipt.
Ask for four lines before accepting a new interface dependency: the user job, the native candidate, the support target, and the behavior test. Add the package only after the gap is visible. This gives review something firmer than "the agent chose it" or "native is always better."
The counter below prepares that review card. It does not inspect your application, browser analytics, dependency tree, or test output. The checked state means the fields were selected for review. Real evidence still belongs in the blanks.
Native behavior still needs a witness. The live dialog check records how focus enters, how the dialog closes, and whether focus returns to the opener. web.dev documents all three behaviors and warns that non-modal dialogs do not close with Escape by default.[6]