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.

shadcn/ui's Label ships with two opinionated state selectors baked into the className. The peer-disabled:cursor-not-allowed peer-disabled:opacity-50 rule fades the Label when a sibling input marked with peer is disabled. The group-data-[disabled=true]:pointer-events-none group-data-[disabled=true]:opacity-50 rule does the same when an ancestor container carries data-disabled="true". Both selectors assume a specific markup convention — that you wrap the input with the peer class or wrap the form field with a group parent — and they fail open when the convention is missing.

Drivn's Label ships with none of this. The component is a styled native <label> with text-sm font-medium text-foreground and nothing else. To handle disabled state in a Drivn form, add the conditional class at the call site — <Label className={isDisabled && "opacity-50"} ...> — or extend the Label file in your repo with a disabled prop typed as boolean. Both options are explicit edits to the local source, which trades the shadcn baked-in convention for a more direct control surface. For form patterns at scale, see how the Drivn Input and Checkbox components pair without an enforced peer convention.

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.