Drivn vs shadcn/ui — Progress Compared

shadcn/ui's Progress is a thin re-export layer over @radix-ui/react-progress. The component file is roughly twenty-five lines: it imports ProgressPrimitive from the Radix package, wraps ProgressPrimitive.Root with the project's bg-primary/20 relative h-2 w-full overflow-hidden rounded-full className, and renders a ProgressPrimitive.Indicator child whose inline style sets transform: translateX(-${100 - (value || 0)}%). The Radix package itself implements the ARIA progressbar pattern, the indeterminate state, the value clamping, and the controlled-vs-uncontrolled semantics.

Drivn's Progress ships forty lines that import React for the type namespace and cn for className merging. There is no 'use client' directive because the file does not use useState, useEffect, or any other client-only API — the percentage is computed inline during render and written into the inner <div> width. The styles object holds two keys and is reproduced verbatim from the registry below. The same dependency-shape trade-off appears in Drivn vs shadcn Card and Drivn vs shadcn Popover — Drivn keeps the primitive local, shadcn delegates to Radix.

Drivn computes the fill percentage inline during render. The component reads value (default 0) and max (default 100) from props, then runs Math.min(100, Math.max(0, (value / max) * 100)) to clamp the result into the [0, 100] range. The clamp covers the two edge cases that matter — a value greater than max (the bar still caps at 100% rather than overflowing) and a negative value (the bar caps at 0% rather than rendering a negative width). The clamped number is written into the inner <div> width via the style prop, which is the most performant path because the browser updates the inline width on each re-render without invalidating the surrounding layout.

shadcn/ui delegates the same problem to Radix. The Radix root accepts value and max and computes the indicator transform as translateX(-${100 - (value || 0)}%) — at zero the indicator sits fully off-screen to the left, at 100 the indicator sits flush at the left edge. The transform approach uses the GPU compositor rather than layout, which animates more smoothly for high-frequency value updates (an upload progress bar that updates every few hundred milliseconds, for instance). Drivn's width approach is fine for the steadier update cadences that ship in practice — multi-step form progress, page-scroll progress, a passwordstrength meter that updates on keystroke.

Drivn wires the ARIA progressbar pattern by hand. The outer <div> carries role="progressbar", aria-valuenow={value}, aria-valuemin={0}, and aria-valuemax={max}. Screen readers read the four attributes together to announce the current value and the range — "Progress, fifty percent" or "Progress, fifty out of one hundred" depending on the assistive tech. The four attributes ship with the registry source so a copy-paste install lands on an accessible bar without further work. The clear omission is the aria-busy and indeterminate-state pair: Drivn does not support value={null} for an indeterminate spinner-style bar, so a file upload whose total size is unknown does not have a built-in shape.

shadcn/ui inherits the full Radix progressbar contract: passing value={null} (or omitting value) flips the indicator into indeterminate mode and drops aria-valuenow, which is the correct ARIA pattern for indeterminate progressbars. Radix also supports the WAI-ARIA getValueLabel callback for custom announcement strings — useful for the "step three of five" framing that benefits from a human label rather than a raw percentage. For projects that need indeterminate state or custom labels, the shadcn flavor is the right call. For projects where the value is always known (form progress, scroll progress, upload progress with a known total), the Drivn wiring is enough. The same trade-off framing applies to Drivn Slider — manual ARIA on a thin file, Radix wiring on the shadcn equivalent.

Drivn animates the bar through a CSS transition on the inner <div>. The bar className includes transition-all duration-300 ease-out, so when the value prop changes the inner <div> width transitions from the old percentage to the new percentage over 300ms with an ease-out curve. The behaviour feels right for step-driven progress (advancing through a multi-step form, completing a task in a checklist) and for slower update cadences. For a fast-updating value — an upload progress bar that ticks every 100ms — the 300ms transition can lag visibly behind the actual value, in which case overriding the transition duration through the optional className prop is the small fix.

shadcn/ui animates the indicator through a CSS transform transition. The Radix indicator uses transition: all .5s ease-out (or whatever the project sets on the wrapper), and the translateX transform composites on the GPU rather than triggering a layout. The two approaches end up visually similar at typical progress cadences, with the transform-based animation pulling ahead at high-frequency updates because the browser does not have to re-measure the layout on each frame. The Drivn approach trades a little smoothness at high frequencies for a code path that reads top-to-bottom in twenty lines and has no Radix surface to learn.

Drivn uses a single component. The call site reads <Progress value={65} /> for a fixed value, or <Progress value={progress} max={steps} /> when the bar tracks a step counter. One import — import { Progress } from "@/components/ui/progress" — covers the whole component. There is no Progress.Indicator, no Progress.Root, no compound API — the registry ships one named export. The TypeScript signature accepts value, max, and className, and the component clamps any out-of-range value to [0, 100] without throwing.

shadcn/ui ships the same <Progress value={65} /> shape because the wrapper hides the Radix Root/Indicator split — the consumer never sees the two pieces. The differences appear when the project needs the indeterminate state (<Progress value={null} /> on shadcn, edit the component file on Drivn), when the project needs custom announcement strings (<Progress getValueLabel={(v, max) => "Step " + v + " of " + max} /> on shadcn, not exposed on Drivn), or when the project wants to use the Radix unstyled primitive elsewhere (already paid the dependency on shadcn, would re-introduce it on Drivn). For most progress bars — a determinate value from zero to a known max — both call sites read identically. See Progress examples for the call-site shapes Drivn ships out of the box.

Pick shadcn/ui's Progress when the project already standardizes on Radix elsewhere (Dialog, Tooltip, Popover) and the progress bar needs indeterminate state, custom ARIA labels, or the transform-based animation curve. Upload bars with unknown total sizes, multi-step indicators that benefit from "Step N of M" announcements, and high-frequency progress (think audio playback scrubbers re-rendering every animation frame) all live in this column because the Radix machinery handles them without per-bar wiring. The cost is one Radix package in the bundle, which most projects already pay for through another component.

Pick Drivn's Progress when the priority is keeping the dependency tree small and the call site editable. Form progress, page-scroll progress, password-strength meters, and any determinate value known at render time all live in this column because the forty-line file reads top-to-bottom and the styles object lives in plain sight. The component does not need 'use client', so it renders on the server inside a Server Component out of the box — useful for content-driven pages where the progress reflects build-time data. Pair the Progress with the Drivn Card for the surrounding shell and the Drivn Badge for the matching label. See the Progress examples page for the call-site shapes that fit each scenario.