Drivn vs shadcn/ui — Aspect Ratio Component Compared

shadcn/ui exports AspectRatio from @/components/ui/aspect-ratio, a thin forwardRef wrapper around the Radix UI primitive at @radix-ui/react-aspect-ratio. You pass a ratio prop as a numeric expression — typically 16 / 9 or 4 / 3 — and any children render inside the ratio-locked container. Drivn exports the same name from the same path, but the file behind it is a single React function component with no forwardRef and no primitive import. The aspect ratio docs show the full API and props table.

Both libraries accept the same shape at the call site — <AspectRatio ratio={...}><img /></AspectRatio> — so migration in either direction is largely a find-and-replace on the import path. What diverges is the behavior when the ratio prop is omitted, the accepted type of that prop, and the dependency graph each component drags along at install time.

shadcn/ui's AspectRatio depends on @radix-ui/react-aspect-ratio, a Radix UI primitive that adds roughly two kilobytes gzipped on top of React once included. The primitive itself is small and well-maintained, but it arrives through the wider Radix dependency graph that also pulls in @radix-ui/react-primitive and a handful of shared utility packages used across every other Radix component you might have installed.

Drivn's AspectRatio depends on nothing outside of React and your existing Tailwind setup. The whole component file is fifteen lines — an interface declaration, a single function body, and an inline style that writes the aspect-ratio CSS property directly. No primitive, no forwardRef, no ref polyfill. If you open the component file after running the Drivn CLI, the source reads top to bottom without any framework abstraction. For a team that audits every runtime dependency, the difference is one fewer package in package.json and one fewer version bump to track.

shadcn/ui's ratio prop is typed as number, so you pass an arithmetic expression at every call site — ratio={16 / 9}, ratio={4 / 3}, or ratio={1} for a square. The expression is readable once and becomes repetitive noise when echoed across a media gallery, a video grid, or a list of thumbnail cards. There is no default; leave the prop off and you get a container with no enforced ratio at all.

Drivn's ratio prop accepts either a string preset ("16/9", "4/3", "1/1") or a raw number for non-standard ratios such as 2.35 for cinemascope. The preset form is a string literal union, so TypeScript autocompletes the three common ratios at every call site, and the component falls back to "16/9" if you omit the prop entirely. The numeric form is still available when you need a custom ratio — the React AspectRatio examples show both forms in context.

Neither API is objectively better. The numeric shape matches how designers think about ratios in Figma; the string preset matches how the underlying CSS aspect-ratio value actually reads in browser devtools. Pick the shape your team already uses in design specs.

Both libraries put children inside a block container whose ratio comes from the native CSS aspect-ratio property, so an image with w-full h-full object-cover or an iframe with explicit fill dimensions behaves identically in either one. The divergence is what else that container carries. Drivn's div ships with relative w-full overflow-hidden already applied through cn(), merged with whatever className you pass; shadcn's wrapper sets no layout classes of its own.

Those three classes remove boilerplate in the layouts that actually reach for a ratio box. relative lets a caption bar, a play-button overlay, or a hover gradient sit as a direct absolutely-positioned child with no wrapper in between. overflow-hidden clips a scaled-up image on hover to the box edge instead of letting it bleed across neighboring cards. w-full makes the box fill its grid or flex track by default, which is what a media grid wants anyway. With shadcn you add each of these per instance or wrap the component once yourself. Overriding them stays clean either way, because cn() runs tailwind-merge — className="w-auto" on a fixed-width thumbnail wins over the baked-in w-full. The aspect ratio docs list the full prop and class surface.

Both components lean on the native CSS aspect-ratio property, supported across every evergreen browser and roughly 94% of global traffic in 2026 per caniuse.com. For any product whose audience runs Chrome, Safari, Firefox, Edge, or their mobile counterparts from the last four years, either library works with zero fallback considerations at all.

Historically, Radix's aspect-ratio primitive shipped a padding-bottom percentage fallback for browsers that predated the native property. Modern @radix-ui/react-aspect-ratio has simplified to use the native property directly, so shadcn's behavior matches Drivn's on today's engines. Neither library gives you a polyfill for browsers from before 2022 — Internet Explorer 11 or early Android WebViews on legacy devices — out of the box.

Because Drivn's component lives in your repo after the CLI install, adding a padding-bottom fallback for a specific legacy audience is a five-line edit inside src/components/ui/aspect-ratio.tsx. That kind of surgical tweak is harder with shadcn because the fallback logic, if it returned, would need to be patched inside the Radix primitive.