Drivn vs shadcn/ui — Tooltip Compared

The starting point is the foundation. shadcn/ui's Tooltip is a styled wrapper over @radix-ui/react-tooltip: you mount a TooltipProvider, compose Tooltip, TooltipTrigger, and TooltipContent, and Radix tracks an open state in JavaScript, renders the content in a portal, and positions it with collision detection. Drivn's Tooltip imports nothing but React and the cn class helper, and it never tracks state at all. The wrapper is a <span> with the Tailwind group class; the tip is a sibling <span> that starts at opacity-0 and flips to opacity-100 whenever the group is hovered or holds focus.

What you trade is real and worth naming: Radix gives you a portal that escapes overflow: hidden parents, configurable open and close delays, and collision-aware flipping when the tip would clip the viewport. Drivn renders the tip inline, so a parent with overflow: hidden can clip it, and there is no delay or auto-flip. What you gain is a tooltip with zero UI dependencies and zero JavaScript for show and hide — no provider to mount, no portal, no Radix version to track — that you own outright after install.

shadcn/ui's Tooltip needs a TooltipProvider mounted somewhere above it — typically at the app root — because Radix shares delay timing and open state across tooltips through context. Drivn needs nothing of the sort. Each Tooltip is fully self-contained: a group wrapper and a tip span, with the visibility driven entirely by the group-hover:opacity-100 and group-focus-within:opacity-100 Tailwind classes. There is no React state, no effect, and no portal — what you render is what ends up in the DOM, in place.

The practical effect is that adding a tooltip is a one-line wrap with no setup tax. You do not register a provider, you do not manage an open prop, and there is no hydration boundary to think about — the component is not even marked 'use client' because it runs no client-side logic. The cost of that simplicity is the inline rendering noted above: because the tip is a normal positioned span rather than a portalled layer, it participates in its parent's stacking and clipping context. For most buttons, icons, and labels that is exactly what you want; for a tooltip inside a scroll container with hidden overflow, it is the trade to weigh.

Both libraries place the tip on any of four sides, but they get there differently. Radix takes a side prop and computes the final position at runtime, flipping it if it would collide with the viewport edge. Drivn takes a position prop typed as keyof typeof styles.positions and indexes straight into a styles.positions object — top, bottom, left, or right — each a static set of Tailwind utilities that absolutely-position and center the tip relative to the trigger. The position names autocomplete from the object itself, with no magic strings.

Because the placement is plain CSS, there is no collision detection: a top tooltip stays on top even near the top edge of the screen. That is the deliberate trade for zero JavaScript. In exchange, restyling or repositioning is a direct edit to the styles.positions object in your installed file — change mb-2 to mb-3, add an arrow, or introduce a new position key — rather than configuring a Radix prop layer. The block below is verbatim from the registry.

Moving a shadcn Tooltip to Drivn collapses the four-part composition into a single wrap. Where shadcn nests Tooltip, TooltipTrigger, and TooltipContent under a TooltipProvider, Drivn takes the trigger as children and the tip text as a content string prop — <Tooltip content="Copy">{trigger}</Tooltip>. You also delete the provider at your app root. The side prop maps to Drivn's position, and any delayDuration you configured has no equivalent because there is no JS delay to tune.

Keep Radix when you genuinely need what it provides: a portal so the tip escapes a clipping parent, collision detection so it flips near the viewport edge, or precise open and close delays for a dense UI. Reach for Drivn's Tooltip when you want a dependency-free, no-JavaScript hover hint that you own outright — which covers the large majority of icon buttons and labels. The Tooltip examples page walks the positions, multiline content, and icon triggers one at a time.