Drivn vs shadcn/ui — Navigation Menu Compared

Count what actually lands in node_modules after each install. Drivn's NavigationMenu adds lucide-react for the single ChevronDown glyph on the Trigger, and nothing else. The file imports React and the cn helper, declares a styles object with seven keys — root, list, item, trigger, triggerIcon, content, link — and bolts five sub-components onto the root through Object.assign. That is the entire surface: class strings plus one onPointerDown handler. Running npx drivn add navigation-menu grows the dependency graph by nothing you were not already shipping.

shadcn/ui's version wraps @radix-ui/react-navigation-menu, which is roughly fifteen kilobytes minified before it pulls in its own shared internals — @radix-ui/react-context, @radix-ui/react-primitive, @radix-ui/react-collection. Each of those exists to support features Drivn deliberately does not have: cross-trigger arrow keys, a shared viewport, a sliding indicator. If the header never uses them, the runtime is weight with no payoff attached. The same accounting shows up in Drivn vs shadcn Dropdown Menu and Drivn vs shadcn Button, where Radix carries the state and Drivn hands it back to the browser.

Drivn's open/close is pure CSS. Each Item carries relative group/item, and the Content inside it carries opacity-0 invisible by default plus group-hover/item:opacity-100 group-hover/item:visible and the matching group-focus-within/item:* rules. Hover the trigger or tab into it, the parent item gets the hover/focus state, and the content panel becomes visible through a 150ms transition-[opacity,visibility]. Close happens the moment hover and focus leave the item. No React state, no controller, no data-state attribute — the browser handles it as native CSS state transitions, which means SSR works without a hydration boundary and the panel never "flashes" closed on first render.

shadcn/ui's open/close is JavaScript-driven through Radix. The primitive owns a controller that tracks the active item, sets data-state="open" on the open trigger, and mounts the matching content into the viewport. The model gives you a single open panel at a time even when the user hovers multiple triggers in quick succession, and it supports controlled mode via value and onValueChange props. The trade is a runtime that has to mount and reconcile state on every interaction, plus animation timing handled through data-[motion=from-start]:slide-in-from-left style attribute selectors rather than transition rules. Both reach the same end visual; the underlying execution model is where they diverge.

Drivn's focus model is native tab order plus the group-focus-within/item selector. Tab into a Trigger button, the panel opens because focus is inside the item; tab again, focus moves to the first focusable element inside Content (the first Link); tab through the links and out the bottom of the panel, focus moves to the next item's trigger and the previous panel closes because focus left the item. The keyboard path is the same as visiting links in any HTML page — there is no arrow-key handler, no aria-orientation, no roving tabindex. For most product headers this is the correct model because the user is navigating to a page, not selecting from a menu of commands.

shadcn/ui's focus model is Radix's arrow-key menu pattern. Tab into the list, then press Left/Right arrows to move between triggers without closing the open panel. Press Down to descend into the open panel, Up to leave. The pattern matches the WAI-ARIA Authoring Practices "menubar" pattern, which is appropriate for application command menus where the user is choosing an action rather than navigating. Pick shadcn when the menu is part of an application toolbar and the keyboard discoverability matters; pick Drivn when the menu is a marketing-site or product-site header and the native tab order is what users already know. The pattern lines up with the Drivn vs shadcn Dropdown split when the menu is a single-trigger surface rather than a multi-panel header.

shadcn/ui's NavigationMenu exposes two parts Drivn does not — NavigationMenu.Viewport and NavigationMenu.Indicator. The Viewport is a single shared container that the active panel renders into, positioned absolutely below the list, with its width and height animated as the user moves between triggers (Apple's top-bar style). The Indicator is a small element — typically a triangle or a bar — that slides horizontally to sit under the active trigger. Both effects require the Radix controller to know which trigger is active, which is part of why the runtime exists.

Drivn's NavigationMenu has neither. Each Content panel sits absolutely positioned at left-0 top-full directly under its own Item — so the panel appears under the trigger that hovered it, with no shared viewport, no width animation between triggers, and no sliding indicator. The trade-off is visual: a Drivn menu looks like a series of independent dropdowns, while a shadcn menu feels like a single morphing surface. If the morphing surface is the design goal — Apple, Vercel, Linear-style top bars — shadcn fits cleanly. If the independent dropdown is the goal, Drivn is forty fewer lines of code and zero Radix runtime to ship. See the NavigationMenu examples page for the call-site shapes both styles look like at typical product-header complexity.

Pick shadcn/ui's NavigationMenu when the design calls for a morphing viewport (one shared panel that resizes between triggers), arrow-key navigation across triggers, a sliding indicator under the active trigger, or a controlled value API so the open state is driven by a route or analytics event. The Radix runtime earns its weight on application toolbars where the menu is a real command surface and the keyboard discoverability is a feature rather than a footnote. The library also slots in cleanly when the rest of the form stack already uses Radix primitives like Drivn vs shadcn Dropdown Menu territory.

Pick Drivn's NavigationMenu when the menu is a marketing or product header with hover-revealed dropdowns, the panels are independent and do not need to share a viewport, and the priority is shipping fewer kilobytes of JavaScript. The CSS-driven open/close runs without hydration cost, the markup is one local TypeScript file over a native <nav>, and the dot-notation API — NavigationMenu.List, .Item, .Trigger, .Content, .Link — composes through a single import. Pair it with a Drivn Button for the call-to-action on the right side of the header and a Drivn Dialog for the mobile menu, and the whole header ships without any Radix runtime in the bundle.