Drivn vs shadcn/ui — Card Component Compared

shadcn/ui exports six named components from one file: Card, CardHeader, CardTitle, CardDescription, CardContent, and CardFooter. Each one is a styled div, and you compose them in the order the layout needs. Drivn exports a single object — Card — with two children mounted on it: Card.Preview and Card.Info. One import line covers the whole component, and the dot access lets a reader see at a glance which div is the visual area and which is the text area.

The trade-off is reach. shadcn's six exports cover blog cards, profile cards, dashboard widgets, settings panels — anything where a header, body, and footer compose differently. Drivn's two slots cover the pattern Drivn cares about: a square showcase tile with an illustration on top and a label on the bottom. If your card has a header bar, body paragraph, and footer button row, shadcn fits better. If your card is a gallery item or component preview, Drivn writes in fewer lines. Pick the one that matches the shape you actually render. The full Card docs cover both slots in detail.

Drivn's Card carries a fixed w-48 aspect-square footprint plus a vertical flex layout where Card.Preview claims flex-1 and Card.Info sits below it with p-5 padding and a horizontal flex split. That makes a Drivn Card a 192px × 192px tile by default, with the preview filling whatever vertical space the info row leaves. shadcn/ui's Card has no width or height — it stretches to fill its parent and stacks children vertically with a gap-6 between them.

When you need a different tile size in Drivn, override the width with a className on the root: <Card className="w-64">…</Card>. The aspect-square stays in effect unless you also override it. shadcn requires no override because it has no defaults to fight, but the cost is more utility classes per usage to lock in a consistent grid. For a gallery of equal-sized tiles, Drivn's defaults save a grid template column dance. For a settings panel, shadcn's flexibility wins. The Card examples page shows the gallery pattern in full.

Hover is a prop in Drivn and a class list in shadcn. The Drivn base string always carries transition-all duration-200, and the root composes cn(styles.base, hover && styles.hover, className) — so the styles.hover key, hover:bg-accent hover:border-border hover:-translate-y-1, only lands when the prop is on. It defaults to true. The -translate-y-1 is the piece readers actually notice: a small rise that reads as "this tile responds". Passing hover={false} drops all three classes but leaves the transition in place, which matters if you animate something else on the same element.

shadcn/ui's Card ships no transition and no hover state, so a card inside a link behaves exactly like a card inside a static marketing block until you say otherwise. Neither default is wrong — Drivn assumes the gallery context where every tile is clickable, shadcn assumes nothing. Recreating the Drivn feel in shadcn means copying those same three classes onto your Card; going the other direction is one prop. The Card examples page shows the grid this behavior was tuned for.

Reach for shadcn/ui's Card when the layout has a meaningful header / body / footer split — settings panels, blog post previews, dashboard metric cards with an action bar, profile summaries with avatar plus stats. The six-export surface is exactly the shape those layouts need, and the lack of size defaults lets the card flex to whatever container holds it.

Reach for Drivn's Card when you are rendering a uniform grid of square tiles with an illustration up top and a label below — component galleries, plugin marketplaces, product card grids, design system documentation. Drivn's defaults take the design decisions out of your hands so the grid stays visually consistent across every usage. If you find yourself overriding w-, aspect-, and hover: classes on every shadcn Card to land at the same showcase shape, switch. If you find yourself fighting the w-48 aspect-square default on every Drivn Card to make it stretch, switch back. The Drivn CLI installs the source either way, so the migration is a copy and replace.