Drivn vs shadcn/ui — Scroll Area Compared

shadcn/ui's Scroll Area is a layer over @radix-ui/react-scroll-area. The component file imports ScrollAreaPrimitive from the Radix package and re-exports ScrollAreaPrimitive.Root plus ScrollAreaPrimitive.Viewport as ScrollArea, then composes a ScrollBar from ScrollAreaPrimitive.Scrollbar, ScrollAreaPrimitive.Thumb, and ScrollAreaPrimitive.Corner. Radix supplies the JavaScript that measures the content, sizes the thumb, and keeps the custom bar in sync with the scroll position.

Drivn's Scroll Area imports React and the local cn() utility — nothing else. Every class the component uses lives in the styles object below, reproduced verbatim from the registry. styles.base sets scrollbar-width: thin and scrollbar-color for Firefox, then a run of ::-webkit-scrollbar pseudo-element rules for Chromium and Safari: a 1.5-unit-wide track, a rounded-full thumb tinted bg-border, and a hover state that darkens the thumb to bg-muted-foreground/30. No Radix, no JavaScript, no icon package. See the Scroll Area examples page for the call sites, and the Separator component for the same zero-dependency framing applied to a divider.

This is the real divergence. Drivn does not draw a scrollbar at all — it lets the browser scroll natively and restyles the browser's own scrollbar with CSS. Firefox honours scrollbar-width: thin and scrollbar-color; Chromium and Safari honour the ::-webkit-scrollbar family. The result is a thin, theme-tinted bar that costs zero JavaScript and zero layout work, because the browser was going to paint a scrollbar anyway.

shadcn/ui hides the native scrollbar and paints its own. Radix renders a ScrollAreaThumb div whose height and offset are computed in JavaScript from the viewport and content sizes, updated on every scroll and resize. The payoff is pixel-identical scrollbars across every engine and full control over the thumb through a className on ScrollBar. The cost is the Radix package in the bundle, a 'use client' boundary, and a JavaScript handler running while the user scrolls. Drivn's component, by contrast, is a single <div> that spreads ...props and merges className through cn() — it has no state, so it renders fine as a server component. See the Scroll Area component reference for the full props table.

Both libraries expose vertical and horizontal scrolling, and both default to vertical. Drivn reads an orientation prop — 'vertical' or 'horizontal' — and uses it to pick a key from the orientations map. Vertical resolves to overflow-y-auto overflow-x-hidden, horizontal to overflow-x-auto overflow-y-hidden, so exactly one axis scrolls and the other is clipped. The map is reproduced verbatim below; there is no diagonal or both-axes mode, which keeps the contract small and predictable.

For a horizontal Scroll Area the child content has to be wider than the container — typically a flex row with w-max so the items lay out at their natural width and overflow sideways. shadcn/ui passes its orientation to the Radix ScrollBar and renders a matching horizontal Radix thumb. The end result is the same affordance; the difference stays the dependency tree and the rendering model. A horizontal Scroll Area pairs well with the Drivn Card for a swipeable row of tiles — see the Scroll Area examples for that call site.

A Scroll Area only scrolls when its content is taller (or wider) than the box. Neither Drivn nor shadcn/ui can infer a height for you — the component is a styled <div>, and a <div> grows to fit its content by default. To get scrolling you set a fixed height or a max-height through the className: <ScrollArea className="h-48"> caps the box at 12rem and lets anything past that scroll. This is the single most common reason a Scroll Area appears not to work — the content simply fit.

shadcn/ui has the same requirement; its Radix viewport also needs a constrained height before the custom thumb appears. Because the height lives on the className in both libraries, the sizing code is identical and a migration touches nothing here. Drivn merges that className onto the base styles through cn(), so Tailwind's height utilities, arbitrary values like h-[420px], and max-h-* classes all work. Inside a Dialog or a Card, a max-h-* on the Scroll Area keeps a long list from pushing the surrounding layout.

Pick shadcn/ui's Scroll Area when pixel-identical scrollbars across every browser are a hard requirement — a design system that must look the same in Firefox, Chrome, and Safari down to the thumb width, or a product where the scrollbar is part of the brand. Radix's JavaScript-painted thumb gives that exact control, plus a ScrollBar element you can restyle freely. Projects already standardized on Radix pay no extra dependency cost, since the package family is likely in the bundle already.

Pick Drivn's Scroll Area when the priority is a small dependency tree and a component that renders on the server. It is one <div> with a CSS-styled native scrollbar — no Radix, no JavaScript, no 'use client' boundary, and no scroll handler running during interaction. The scrollbar still looks thin and on-theme in every modern engine; it just is not guaranteed pixel-identical between them. For most apps — a sidebar, a chat log, a horizontal card row, a long settings panel — that trade is worth it. Pair the Scroll Area with the Drivn Table for scrollable data and the Command menu for scrollable result lists. See the Scroll Area examples for ready call sites.