If you want to create a button from scratch, you must first create the universe
Recreating something as simple as a button from scratch on the modern web exposes how much behavior, accessibility, and cross-device nuance native HTML controls already provide — and how easy it is to get those details wrong. Commenters debate why richer native widgets (like a true combobox) have stagnated for decades, pointing to browser politics, awkward standards such as Web Components, and the tension between “document” HTML and app-like interfaces. Accessibility emerges as both a genuine technical and ethical concern and a legal minefield, with some arguing AI and smarter tooling will soon handle much of this complexity while others warn that outsourcing it to opaque agents could worsen usability, privacy, and reliability.
Satire, buttons, and accessibility complexity
- Many see the piece as accurate despite being framed satirically: reimplementing a proper button is surprisingly hard.
- Some readers found it educational, having relied on frameworks and not known about many accessibility concerns.
- Others note the example code still has bugs (e.g., incorrect pointer/mouse-up logic), which reinforces the point that doing this “right” is tricky.
Native HTML vs custom components and missing widgets
- Several argue that complex widgets (e.g., comboboxes with server-side filtering) are hard or impossible to do purely with native HTML, pushing developers to custom implementations.
<input>+<datalist>is cited as a partial combobox solution, but dynamic/efficient updating and richer behavior remain gaps.- There is frustration that HTML still lacks many higher-level widgets that native toolkits had decades ago.
Browser vendors, standards, and stagnation
- Some blame all major browsers for slow progress on HTML-native, JavaScript-free components.
- Others push back on claims that Apple uniquely blocks progress, noting standards like Open UI and differing philosophies about speed vs safety.
- Safari’s refusal to support extending built-ins (e.g.,
class MyButton extends HTMLButtonElement) is discussed; critics say this forces full re‑implementation instead of light customization.
Web vs “semantic web” and application needs
- Commenters distinguish between document-centric “semantic web” and highly interactive web applications.
- Business and UX requirements often diverge from what native form controls offer; meeting those expectations with pure native elements is seen as impractical or too costly.
AI’s impact on UI and accessibility
- One side claims AI now makes it trivial to generate complex, accessible components and tests from scratch, weakening the “don’t reinvent the button” argument.
- Others counter that AI repeats common mistakes (e.g., misusing buttons for navigation), doesn’t automatically cover all edge cases, and can encourage code bloat.
- Some report good experiences asking LLMs to retrofit accessibility into existing apps; others worry that models trained on “shitty code” will propagate bad patterns.
Accessibility compliance, lawsuits, and “racket” concerns
- A story is shared about an accessibility lawsuit leading to expensive, largely superficial changes and ongoing “compliance” subscriptions.
- There is debate over whether future AI screen readers/agents will make strict technical compliance less relevant, versus laws and incentives keeping the current system in place.