Drivn vs shadcn/ui — Button Component Compared

The two buttons converge on the same usage site: <Button variant="secondary">Click</Button>. Underneath, shadcn's Button uses cva to define variants and asChild to swap the rendered element via Slot. Drivn defines variants as a plain object indexed by variant and size, and renders a native <button> (see the Button docs).

For most buttons this is indistinguishable. The divergence shows up when you want to pass an icon or a loading state — Drivn accepts leftIcon={Plus} and loading={true} as first-class props, whereas shadcn expects you to embed icons and loading spinners as children.

shadcn/ui's Button imports @radix-ui/react-slot (~1.2 kB gzipped) plus class-variance-authority (~0.8 kB) plus clsx (~0.3 kB). Drivn's Button imports nothing beyond React and your cn() utility (which you likely already have). On a page with ten different components, the compounding difference is meaningful — tabs, dialog, and others in Drivn all skip these primitives.

None of this changes what ships in your node_modules. Both libraries copy source into your repo. The difference is what your final bundle pulls in when Next.js tree-shakes — Drivn pulls fewer modules because it imports fewer modules.

shadcn recommends extending variants via cva's cn() merge or by editing the buttonVariants function. Drivn recommends editing the styles object directly — add a key to variants, add a key to sizes, or change a class. Because the types read from keyof typeof styles, autocomplete updates on save.

For teams that prefer the cva pattern, shadcn will feel familiar. For teams that want fewer layers between "render a button" and the final markup, Drivn removes one level of indirection. Neither approach is objectively better — the question is which mental model matches your team.

Drivn is younger and smaller than shadcn/ui. The ecosystem around shadcn — blocks, examples, community themes, third-party integrations — is larger by orders of magnitude. If you need a ready-made admin dashboard or marketing template built on your component library today, shadcn has more starting points.

Drivn also does not support asChild / polymorphic rendering. If your design system relies heavily on rendering the same props as different underlying elements (e.g., a button that is really a link), shadcn's Radix Slot pattern is more ergonomic. In Drivn you render a link and style it like a button, which some teams prefer for clarity.

Rename <Button asChild><Link /></Button> to <Link className={buttonClasses}>. Replace icon children with leftIcon / rightIcon props. Remove cva imports; Drivn does not need them. The surrounding <form>, <Dialog>, or <Tabs> markup stays the same — only the Button changes. See the installation guide for the CLI command.

For teams that use shadcn's buttonVariants() helper to apply button styles to other elements (typically <Link>), the Drivn equivalent is to extract the styles object from the Button source and re-use it via cn(). Since the Button source now lives in your repo, the extraction is a one-time refactor. Most migrations touch 20-50 button call sites and take under an hour per app. Test deep-interaction flows (form submits, confirm dialogs) carefully — the loading prop replacement saves more code than it breaks.