Drivn vs shadcn/ui — Label Component Compared

Drivn's Label is a function over the native <label> element. The file imports React and the cn utility and ships zero runtime UI dependencies. After npx drivn add label your package manifest is unchanged — no new entry in dependencies, no new resolution in the lockfile. The component reads as twelve lines of TypeScript and stays that way through every upgrade because there is nothing under it to upgrade.

shadcn/ui's Label wraps @radix-ui/react-label, which adds one runtime entry to your dependencies and one transitive resolution to the lockfile. The Radix package is small — roughly two kilobytes minified — but it is still one more semver-tracked surface to upgrade and one more name in your dependency graph. For a component this thin, the dependency reads as overhead: the only behavior Radix adds over the native <label> is a polyfill for click forwarding in environments that already work, and the click forwarding in modern browsers works without it. Compare this with the Drivn vs shadcn Input pattern where the trade-offs around state libraries are larger.

Drivn's Label has no "use client" directive because the component uses no client-only APIs. There is no useState, no useEffect, no event handlers in the component body. Render the Label inside a Next.js Server Component and it streams as part of the static HTML — no client bundle weight, no hydration cost, no boundary the bundler has to draw around it. Pair it with a Client Component Input and the boundary lives on the Input, not on the Label.

shadcn/ui's Label file starts with "use client" because Radix's Label primitive carries hooks under the hood. The directive forces the file into the client bundle even when every call site renders inside a Server Component, which means the Radix runtime ships down the wire on every page that imports a Label. For a form-heavy app the cost is small in absolute terms but consistent — every page that renders a labeled field pays the Radix tax. Drivn skips this by not depending on Radix in the first place.

The two state rules shadcn bakes into its Label className are conventions as much as styles. peer-disabled:cursor-not-allowed peer-disabled:opacity-50 only fires when the disabled input is a preceding sibling carrying Tailwind's peer class, and group-data-[disabled=true]:pointer-events-none group-data-[disabled=true]:opacity-50 only fires when an ancestor carries both group and data-disabled="true". Get the markup order or the marker class wrong and nothing happens — the label sits at full opacity next to a disabled field, which is a silent miss rather than a type error.

Drivn's Label carries text-sm font-medium text-foreground and nothing else, so the disabled state is something you state outright. At the call site that reads <Label className={cn(disabled && "opacity-50 cursor-not-allowed")} htmlFor="email">. If the pattern repeats across a large form stack, add a disabled?: boolean prop to your local @/components/ui/label.tsx — the file lives in your repo after install, so it is a few lines in one place and the type flows to every call site immediately. Either way the rule is visible where the field is written, and it never depends on where the Input or Checkbox happens to sit in the DOM.

Both libraries pair the Label with form controls the same way at the call site. Pass htmlFor on the Label and id on the control, and the browser handles click-to-focus natively. With a Drivn Input the wiring is a flex flex-col gap-2 container, a Label on top, an Input below, and the same htmlFor/id pair. With a Drivn Checkbox the wiring is a flex items-center gap-2 container, a Checkbox on the left, a Label on the right, same htmlFor/id pair.

shadcn's default Label adds flex items-center gap-2 directly to the Label className, which means a Label rendered next to a Checkbox already has the inline-flex layout built in. Drivn keeps the Label layout-neutral and asks the consumer to wrap it in the container of their choice, which adds one wrapping div to the Checkbox case but keeps the Label itself flexible for non-inline layouts (a stacked Input field above the Label, a Label as a section heading, a Label inside a Card header). The trade is a tiny amount of wrapping markup at the call site versus a tiny amount of baked-in layout on the component.

Pick shadcn/ui's Label when you want the disabled-state styling out of the box, you are already invested in Radix primitives across your form stack (Radix's Dialog, Select, and Popover all sit next to it), and the "use client" directive on every form field is acceptable for your routing model. The peer-disabled and group-disabled rules slot into shadcn's broader form conventions cleanly, and the Radix dependency is one entry in a project that already pulls Radix for other components.

Pick Drivn's Label when you want zero runtime deps on the smallest possible form primitive, you want the Label to render inside a Next.js Server Component without a client bundle hit, and you prefer explicit className composition at the call site over baked-in state selectors. The component is twelve lines, has no transitive dependencies, and pairs with Drivn's Input, Checkbox, and Select without any cross-component conventions. For the broader argument around Radix versus native primitives, see Drivn vs shadcn Button.