Drivn vs shadcn/ui — Radio Group Compared

shadcn/ui's Radio Group is a thin layer over @radix-ui/react-radio-group. The component file imports RadioGroupPrimitive from the Radix package and Circle from lucide-react, then re-exports RadioGroupPrimitive.Root as RadioGroup and wraps RadioGroupPrimitive.Item with a RadioGroupPrimitive.Indicator child that renders the filled Circle dot. The Radix package implements the roving-tabindex keyboard model, the controlled-vs-uncontrolled semantics, and the ARIA radiogroup wiring.

Drivn's Radio Group ships one file that imports React and the local cn() utility — no Radix, no icon package. The selected value lives in a React.useState (uncontrolled) or a controlled value prop, shared down through a Ctx provider so each Item knows whether it is the active option. The styles object holds every class the component uses and is reproduced verbatim from the registry below. The file carries a 'use client' directive because it calls useState, the same as the shadcn flavor — the difference is the dependency tree, not the client boundary. The same dependency-shape trade-off appears in Drivn vs shadcn Checkbox and Drivn vs shadcn Badge — Drivn keeps the primitive local, shadcn delegates to Radix.

This is the real divergence. Each Drivn Item renders inside a <label> and contains a genuine native <input type="radio"> marked peer sr-only — visually hidden but still a real form control. The visible circle is a sibling <span> styled by the radio class, and the focus ring is wired through peer-focus-visible:ring-[3px] so it lights up when the hidden input takes focus. Because the inputs are real radios, they participate in plain HTML form submission, they pair with FormData without a hidden mirror field, and the browser supplies the same-name grouping and arrow-key navigation that the platform has shipped for radios since forever.

shadcn/ui's items are Radix buttons, not inputs. Radix implements the WAI-ARIA radiogroup pattern with roving tabindex — only the selected button is in the tab order, and arrow keys move selection within the group. Radix also renders its own hidden input for form posts. The Radix model is the more thorough ARIA contract and handles edge cases (RTL arrow direction, typeahead) that the native flavor leaves to the browser. The trade-off is the same one this comparison keeps returning to: Drivn leans on the platform and ships a smaller file, shadcn leans on Radix and ships a more exhaustive interaction layer. The native-element framing also drives Drivn vs shadcn Checkbox.

Drivn's Item accepts label and description props and renders them itself. Pass label="Email" and the component drops a text-sm font-medium label next to the radio; add description="Get notified by email" and it stacks a text-sm text-muted-foreground line under the label. Because the whole Item is wrapped in a <label> element, clicking either the label or the description toggles the radio without any htmlFor/id plumbing. When the built-in two-line layout is not enough, pass children instead and the component renders your custom content in place of the label block.

shadcn/ui's RadioGroupItem ships the circle only. Labels are a separate concern: you render a shadcn <Label htmlFor={id}> next to each RadioGroupItem and wire the id/htmlFor pair by hand, usually inside a flex row. That is more markup per option but also more layout freedom — the label is a plain element you place anywhere. Drivn's built-in label/description props cover the common settings-list and plan-picker shapes in one line; shadcn's separate-Label approach is the escape hatch Drivn reaches with children. See the Radio Group examples page for the label, description, and custom-children call sites side by side.

Drivn's Radio Group exposes a variant prop with two values, circle (default) and square. The variant is read on the root and shared through the context, so every Item in the group picks it up — there is no per-item variant. Under the hood the variants map swaps the outer radio between rounded-full and rounded-[4px], and the indicators map swaps the inner selected dot between rounded-full and rounded-[2px] so the dot shape matches the frame. A square radio reads as a distinct control from a checkbox while still signalling single-select, which is useful in dense settings panels where round and square shapes carry meaning.

shadcn/ui's Radio Group is circle only. The Radix indicator renders a Circle icon and the wrapper className rounds the button with rounded-full; a square variant means editing the component file to swap both. Drivn also exposes an orientation prop (vertical default, horizontal) that flips the root flex container from a column to a row through the horizontal style key — handy for a compact yes/no or short option row. Both libraries support controlled and uncontrolled use through the same defaultValue / value + onValueChange shape, so the state model is identical even though the styling surface differs.

Drivn uses a dot-notation compound. One import — import { RadioGroup } from "@/components/ui/radio-group" — gives you RadioGroup and RadioGroup.Item. A group reads <RadioGroup defaultValue="email"><RadioGroup.Item value="email" label="Email" />...</RadioGroup>. The root accepts defaultValue, value, onValueChange, orientation, variant, and disabled; disabling the group disables every item, and an individual Item can carry its own disabled to gray out one option. The Item also forwards a ref to the underlying input and spreads any extra InputHTMLAttributes, so name, required, and other native attributes flow straight through.

shadcn/ui uses two named imports — RadioGroup and RadioGroupItem — and the call site interleaves each RadioGroupItem with a <Label>. The state props match Drivn's (defaultValue, value, onValueChange), so migrating the state logic is a no-op; the difference is the per-option markup. For most forms — notification preferences, plan selection, a single-select question — the Drivn call site is shorter because the label lives on the Item. For layouts that need the label decoupled from the control, the shadcn approach (or Drivn's children escape hatch) gives more room. See Radio Group examples for the controlled, react-hook-form, and card-style call sites.

Pick shadcn/ui's Radio Group when the project already standardizes on Radix elsewhere (Dialog, Tooltip, Select) and you want the full WAI-ARIA radiogroup interaction layer without writing any of it — roving tabindex, RTL-aware arrow directions, and the Radix-managed hidden input for form posts. Complex forms, internationalized apps, and teams that prefer one consistent primitive vendor across every control all live in this column. The cost is one more Radix package and the lucide-react icon import in the bundle, which most shadcn projects already pay for elsewhere.

Pick Drivn's Radio Group when the priority is a small dependency tree and a call site that reads top-to-bottom. The native <input type="radio"> underneath means the group works in a plain HTML form, posts with FormData cleanly, and inherits browser radio behaviour for free. The built-in label and description props collapse the common settings-list shape to one line per option, and the circle/square variants plus horizontal orientation cover the layout range without extra markup. Pair the Radio Group with the Drivn Card for plan-picker tiles, the Label for standalone form fields, and react-hook-form plus zod for validation. See the Radio Group examples page for the call-site shapes that fit each scenario.