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 drop their children inside a block-level container that enforces the target ratio via the native CSS aspect-ratio property. Children render in normal flow and are typically sized to fill the container with w-full h-full object-cover when the child is an image. For iframes — a YouTube embed, a Vimeo player, a Google Maps panel — the same fill pattern works because iframes respect explicit dimensions reliably across engines.

Drivn also adds relative and overflow-hidden to the container at install time. The relative anchor lets absolutely-positioned children (captions, play-button overlays, gradient hovers) sit inside the ratio box without an extra wrapper. The overflow-hidden keeps oversized content — a Ken Burns zoom, a scaled-up image hover — clipped to the box edge. shadcn's wrapper does not set either class by default, so overlay patterns need their own positioning wrapper on top. For a responsive hero section with text on media, Drivn removes one layer of wrapper JSX.

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.