Drivn vs shadcn/ui — Input Component Compared

Both components forward every native input attribute through React.InputHTMLAttributes<HTMLInputElement>. Type, placeholder, value, defaultValue, onChange, onBlur, disabled, required, readOnly, autoComplete, min, max, pattern, name, id — every prop you would expect on <input> works on either side without a wrapper type. shadcn's newer recipe takes ref as a prop (React 19's ref-as-prop pattern), while Drivn keeps React.forwardRef for compatibility with older React majors and ref-typed forms in react-hook-form.

The call site looks the same in either library. Drop the component into a form, set type and placeholder, and wire onChange or register from your form library of choice. Where the surfaces diverge is the default class set. shadcn ships file-input styling, an aria-invalid border, and a focus-visible ring out of the box. Drivn ships none of those — they are local edits to styles.base if you want them. See the Input reference for the full Drivn surface.

Both components add zero runtime UI dependencies to your package.json. shadcn's Input imports only cn from its local utils file and the React types. Drivn's Input imports cn from @/utils/cn and React for forwardRef and the input attributes type. There is no Radix dependency, no Floating UI, no popper library, no form-state library underneath either one. Both files compile down to about a dozen lines of useful JSX plus a className string.

The practical difference is the className surface area shipped to your bundle. shadcn's default class string is roughly 380 characters because it covers file inputs, focus rings, aria-invalid, dark-mode backgrounds, and disabled pointer-events. Drivn's default is about 140 characters because it covers the four things every input needs — border, padding, text, disabled — and stops there. Tailwind will tree-shake the unused utilities either way, so the runtime cost difference is negligible. The readability difference at the source level is real: a 140-character constant in a styles object reads at a glance, a 380-character inline string does not.

shadcn ships a visible focus ring out of the box. The recipe applies focus-visible:border-ring, focus-visible:ring-ring/50, and focus-visible:ring-[3px] so keyboard users see a clear three-pixel ring on the active input. It also wires an aria-invalid style: setting aria-invalid={true} on the input flips the border to border-destructive and adds a ring-destructive/20 aura, which means a server-validation error or a react-hook-form field error can flip the visual state without any extra className management on your side.

Drivn's default is focus:outline-none transition-colors — no ring, no border color change. The decision is intentional: most production inputs sit inside a Label+input+helper pattern where the label and helper text are the primary feedback channels, and the error state is styled at the field-wrapper level rather than baked into the input itself. If you want a focus ring on a Drivn Input, add one line to styles.base after install: focus:ring-2 focus:ring-ring focus:ring-offset-2. The file lives in your repo, so the edit stays local.

shadcn's Input bakes in three things Drivn deliberately leaves out. First, file-input styling: the file:text-foreground, file:inline-flex, file:h-7, file:border-0, file:bg-transparent, and file:text-sm file:font-medium utilities style the native file-chooser button on <input type="file">. Drivn applies no file-specific utilities — file inputs render with the browser default chooser button, which is intentional because file uploads in production typically use a custom drop-zone built on top of <input type="file"> and the unstyled native button works fine when hidden behind a Drivn Button.

Second, aria-invalid destructive styling — Drivn delegates error visuals to the field wrapper. Third, shadow-xs and a selection:bg-primary selection color — both cosmetic choices that did not earn their place in the minimum viable input. None of this is hard to add: every one of these patterns is a one-line addition to styles.base after install. The Drivn choice is to ship the floor and let you compose up from there, rather than ship the ceiling and trim down.

Pick shadcn's Input when the defaults match what you would build anyway: a visible three-pixel focus ring, an aria-invalid destructive border that pairs with any form library, file-input styling for the rare native file picker, and the text-base md:text-sm pattern that prevents iOS Safari from zooming on focus. If your form-heavy app needs these patterns on every input and you do not want to maintain them in your own styles object, shadcn ships them as the default.

Pick Drivn's Input when you want a small, readable file with a clear styles.base object you can edit in seconds. The minimal default works for the common case — a form field next to a Label with a helper paragraph underneath — and every richer behavior is one line away. The 40-pixel default height and 10-pixel border radius pair with Drivn's Button and Select for a consistent form rhythm. If you want the shadcn ergonomics on top of Drivn, copy the three lines into your local styles.base after install — the libraries are close enough that the migration is cosmetic.