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.

Here is the actual fork in the road. Drivn never draws a scrollbar; it lets the browser scroll the way it always has and restyles the bar the browser was going to paint regardless. Firefox reads scrollbar-width: thin and scrollbar-color, while Chromium and Safari read the ::-webkit-scrollbar family — a 1.5-unit track, a rounded-full thumb tinted bg-border, and a bg-muted-foreground/30 hover state. Nothing measures, nothing recalculates, and no work happens during the scroll itself.

shadcn/ui takes the opposite bet: hide the native bar, render a Radix ScrollAreaThumb, and keep its height and offset in sync with JavaScript on every scroll and resize event. What that buys is exactness — the same thumb, the same width, in every engine — plus a ScrollBar element you can restyle at will. What it costs is the Radix package, a 'use client' boundary, and a handler running while the user drags. The Drivn side of the trade is easy to audit because there is so little of it: one <div>, a cn() merge of the base styles with your className, and a ...props spread. No state means no hooks, and no hooks means the component is server-renderable by default. The Scroll Area component reference carries 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.