Drivn vs shadcn/ui — Switch Compared

The Drivn Switch file is short enough to read in one breath. It declares a styles object with two entries — base for the pill track and thumb for the white circle — then renders a <button type="button" role="switch" aria-checked={checked}> whose track colour swaps between bg-primary and bg-border and whose thumb translates between translate-x-[3px] and translate-x-[25px] based on checked. The toggle logic is one line: onClick={() => onChange?.(!checked)}. That is the whole component.

The shadcn/ui Switch is a thin wrapper around @radix-ui/react-switch. The wrapper file is roughly the same length as the Drivn file, but it imports SwitchPrimitive.Root and SwitchPrimitive.Thumb from a separate package that ships its own state machine, its own data attributes (data-state="checked", data-disabled), its own focus management, and its own form integration hooks. You get more behaviour for free, at the cost of a runtime dependency you cannot remove without rewriting the component.

Both libraries expect controlled state from the caller. Drivn names the callback onChange and types it as (checked: boolean) => void — note the Omit<React.ButtonHTMLAttributes<HTMLButtonElement>, 'onChange'> on the props type so the native button onChange does not collide. shadcn/ui (via Radix) names the callback onCheckedChange, which is the Radix convention to disambiguate from native form onChange events. Same idea, different name.

Drivn does not ship an uncontrolled mode — there is no defaultChecked prop, no internal useState. If you want uncontrolled state you wrap the Switch in your own component and own the state there. Radix-backed shadcn/ui supports both controlled (checked + onCheckedChange) and uncontrolled (defaultChecked) out of the box because Radix maintains the internal state machine for you. For most forms this difference is invisible — you reach for react-hook-form or Zod anyway and control the value at the form level. For one-off toggles, uncontrolled mode is a small ergonomic win.

The Drivn Switch renders a native <button> with role="switch" and aria-checked={checked}. That alone covers the WAI-ARIA Switch pattern minimums — screen readers announce "switch, on" or "switch, off", the toggle is reachable via Tab, and Space and Enter flip the state because that is what native buttons do. The element type is a button, so the focus ring, hit target, and keyboard activation come from the browser without any extra wiring.

shadcn/ui inherits the full Radix Switch implementation, which adds explicit Space and Enter handlers, a normalised focus ring via data-state attributes that you can target in Tailwind, and the same role="switch" and aria-checked plumbing. The behavioural surface is wider, the keyboard contract is documented per keystroke, and the WAI-ARIA compliance is exhaustive. For mass-market consumer apps where accessibility is audited every quarter, that exhaustiveness is worth the dependency. For internal tools and product surfaces where role + aria-checked covers your audit, the Drivn approach is fine.

Three situations push you toward the Radix-backed shadcn Switch even though Drivn ships fewer dependencies. The first is a project already wired through @radix-ui/react-form or another Radix form layer — the Switch primitive integrates with that form context cleanly, broadcasts its state via data-state, and participates in the form submission lifecycle without extra glue. Pairing the Drivn Switch with the same form layer means adding a hidden <input type="checkbox"> next to the button and syncing it manually.

The second is a design system mandate of WAI-ARIA exhaustiveness — every component audited against the full pattern, every keystroke documented, every screen reader output specified. Radix is engineered for that bar; the Drivn Switch is engineered to cover the practical 95% with a third of the surface area. The third is an existing shadcn project — switching one component to Drivn means running two registries side by side, two CLIs in the build, and two @/components/ui conventions. Stay on shadcn unless you are migrating the whole surface. For a fresh start where bundle size, registry simplicity, and dot-notation parity with the rest of the Drivn library matter more than Radix-grade accessibility, the Drivn Switch is the cleaner pick.