SoylentNews

Arthur T Knackerbracket [soylentnews.org] writes:

--- --- --- --- Entire Story Below - Must Be Edited --- --- --- --- --- --- ---

Arthur T Knackerbracket has processed the following story [techplanet.today]:

In the fast-paced world of modern web development, we've witnessed an alarming trend: the systematic over-engineering of the simplest HTML elements. A recent deep dive into the popular Shadcn UI library has revealed a shocking reality – what should be a single line of HTML has ballooned into a complex system requiring multiple dependencies, hundreds of lines of code, and several kilobytes of JavaScript just to render a basic radio button.

<input type="radio" name="beverage" value="coffee" />

Let's start with what should be the end: a functional radio button in HTML.

This single line of code has worked reliably for over 30 years. It's accessible by default, works across all browsers, requires zero JavaScript, and provides exactly the functionality users expect. Yet somehow, the modern web development ecosystem has convinced itself that this isn't good enough.

The Shadcn radio button component imports from @radix-ui/react-radio-group and lucide-react, creating a dependency chain that ultimately results in 215 lines of React code importing 7 additional files. This is for functionality that browsers have provided natively since the early days of the web.

Underneath Shadcn lies Radix UI, described as "a low-level UI component library with a focus on accessibility, customization and developer experience." The irony is palpable – in the name of improving developer experience, they've created a system that's exponentially more complex than the native alternative.

Radix rebuilds radio buttons from scratch using a <button> element with an SVG circle inside, then uses ARIA attributes to tell assistive technologies that this button is actually a radio button. This directly violates the First Rule of ARIA use, which states:

If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

The component also includes a hidden <input type="radio" /> element, but only when used inside a form. This creates an inconsistent behavior that developers must understand and account for.

The primary justification for this complexity is styling flexibility. Proponents argue that native radio buttons are difficult to style consistently across browsers. However, this argument falls apart under scrutiny. Modern CSS provides powerful tools for styling form elements:

A fully custom radio button can be implemented with just a few lines of CSS:

input[type="radio"] {
  appearance: none;
  margin: 0;
  border: 1px solid black;
  background: white;
  border-radius: 50%;
  display: inline-grid;
  place-content: center;

  &::before {
  content: "";
  width: 0.75rem;
  height: 0.75rem;
  border-radius: 50%;
  }

  &:checked::before {
  background: black;
  }
}

This approach requires no JavaScript, no dependencies, and no ARIA workarounds. It's also more performant and accessible than the complex alternative.

The complexity isn't just academic – it has real-world consequences. The Shadcn radio button implementation adds several kilobytes of JavaScript to applications. Users must wait for this JavaScript to load, parse, and execute before they can interact with what should be a basic form element.

In performance testing, adding these components to a basic application resulted in measurable increases in bundle size and initial load time. For users on slower connections or older devices, this represents a genuine barrier to accessing content.

The most troubling aspect of this trend is how it's justified. Developers are told that these complex systems improve "developer experience" by providing consistent, reusable components. In reality, they create the opposite effect:

Perhaps most ironically, these "accessibility-focused" solutions often create accessibility problems. The Shadcn radio button implementation has documented issues:

Meanwhile, native HTML radio buttons work perfectly with all assistive technologies out of the box.

This radio button example represents a broader pattern in modern web development. We've created an ecosystem where:

The discussion around this topic in the developer community has been revealing. Many developers have shared similar frustrations:

However, some developers defend the complexity, arguing that it provides consistency and saves time. This reveals a fundamental misunderstanding of web development principles and the true costs of over-engineering.

The solution isn't to abandon all modern tooling, but to apply it judiciously:

The radio button crisis is a symptom of a larger problem in web development: we've lost sight of the elegance and power of web standards. HTML was designed to be simple, accessible, and performant. When we replace a single line of HTML with hundreds of lines of JavaScript, we're not innovating – we're regressing.

The most radical thing modern web developers can do is embrace simplicity. Use native HTML elements. Write semantic markup. Leverage browser capabilities instead of fighting them. Your users will thank you with faster load times, better accessibility, and more reliable experiences.

As the original article author eloquently concluded: "It's just a radio button." And sometimes, that's exactly what it should be – nothing more, nothing less.

Original Submission