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.

Add up shadcn/ui's Button imports and you get @radix-ui/react-slot (~1.2 kB gzipped), class-variance-authority (~0.8 kB), and clsx (~0.3 kB) before a single button renders. Drivn's Button imports React and your local cn() helper — nothing else. On a screen with one button the gap is noise; on a real page wired up with tabs, a dialog, and a handful of other primitives, the same skipped dependencies compound because every Drivn component avoids them.

Neither approach changes what sits in your node_modules — both copy source into your repo. What differs is the module graph Next.js walks when it tree-shakes the route. Drivn pulls fewer modules into the final bundle because it imports fewer modules in the first place, and there is no shared primitive that quietly reappears in every chunk.

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.