Drivn vs shadcn/ui — Dropdown Component Compared

shadcn/ui's DropdownMenu is a flat namespace of about fifteen named exports — DropdownMenu, DropdownMenuTrigger, DropdownMenuContent, DropdownMenuItem, plus the checkbox, radio, submenu, group, portal, label, separator, and shortcut variants. The trigger uses Radix's asChild to adopt your button: wrap a <Button> in <DropdownMenuTrigger asChild> and Radix forwards refs and event handlers onto it. Drivn collapses the surface into dot notation. One import gets you the whole compound, and Dropdown.Trigger already renders Button with variant="outline" and rounded="md" inside the registry source — no asChild, no Slot.

Items are the other simplification. shadcn places icons as inline JSX inside <DropdownMenuItem> and styles destructive items by overriding className. Drivn moves both into props: <Dropdown.Item icon={Edit}> accepts a Lucide component or a ReactElement, and <Dropdown.Item destructive> flips on the destructive utility from the styles object. The call site goes from fifteen imports plus a Slot adapter to two imports and a flat children block.

shadcn's DropdownMenu pulls @radix-ui/react-dropdown-menu into package.json, and that package transitively brings in @radix-ui/react-popper, @radix-ui/react-portal, @radix-ui/react-presence, @radix-ui/react-slot, and a handful of internal Radix primitives. The recipe is a styling layer on top of a ~30 KB gzipped runtime that handles focus management, keyboard navigation, submenus, and floating-positioning math. For an actions menu with three to five options, most of that runtime is unused weight in your bundle.

Drivn ships zero runtime UI dependencies for the dropdown. The component imports React, cn from @/utils/cn, and Drivn's Button for the trigger. No Radix, no Floating UI, no portal manager. The full file weighs around 168 lines and adds well under 2 KB of gzipped JS to the route that uses it. The tradeoff is honest: you lose keyboard navigation, submenus, checkbox items, and typeahead. For a click-driven actions menu — the Edit/Duplicate/Delete row on a table, the user-avatar menu in a header, a kebab on a card — that tradeoff is the right one.

shadcn animates the DropdownMenu through tailwindcss-animate and Radix's data-[state=open] and data-[state=closed] attributes. The recipe applies data-[state=open]:animate-in, data-[state=closed]:animate-out, fade-in-0, zoom-in-95, and slide-in-from-top-2 to the content surface, plus a separate data-[side=*]:slide-in-from-* set for the four sides Radix can position toward. The animation is driven by Radix's presence component, which keeps the element in the tree long enough for the exit transition to play.

Drivn uses a plain CSS transition on opacity and scale. The styles.content block in the registry source declares transition-[opacity,scale] duration-150 ease-out, and Dropdown.Content toggles between opacity-100 scale-100 when open and opacity-0 scale-95 pointer-events-none when closed. No data-[state] attribute, no animate-in utility, no presence manager — the element stays in the DOM and CSS handles the fade and the slight scale. The result is a 150 ms entrance and exit that ships without a runtime animation library.

Radix gives shadcn's DropdownMenu the full keyboard menu pattern from the ARIA Authoring Practices Guide: arrow keys to move focus, Home and End to jump to the ends, typeahead to filter by first letter, Escape to close while restoring focus to the trigger, and Tab to close while moving forward. Submenus open on ArrowRight, checkbox and radio items toggle on Space, and the floating content stays positioned through scroll and viewport edges via @radix-ui/react-popper.

Drivn's Dropdown ships outside-click and click-to-close, and that is all. The DropdownRoot component attaches a mousedown listener on document and calls setOpen(false) whenever the click lands outside the ref. Dropdown.Item calls the consumer's onClick and then closes the menu. There is no keyboard navigation, no submenus, no checkbox or radio items, and no Escape handler. If your menu needs the full keyboard pattern, pick shadcn's Radix-backed version. If it is three to five click-driven actions where mouse and touch are the primary inputs — the case Dropdown is designed for — Drivn's smaller surface is the right shape.

Pick shadcn's Radix-backed DropdownMenu when the menu is a primary interaction surface that has to satisfy WCAG keyboard requirements, when items include checkbox or radio state, when you need submenus for hierarchical actions, or when the content must portal to escape an overflow: hidden ancestor. Power-user tools, document editors, dashboard chrome with many toggles, and design-system menus that ship to large teams all benefit from what Radix provides. The runtime cost is the price of admission for that behavior.

Pick Drivn's Dropdown when the menu is a short list of click-driven actions: the user-avatar menu in a header, an Edit/Duplicate/Delete row on a Table, a kebab menu on a Card, an action menu next to a Button group. The align prop covers the two positions these patterns need, the icon and destructive props on Dropdown.Item cover the styling cases, and the file you own after install stays under 200 lines. If the same app later grows a menu that needs submenus or full keyboard navigation, drop shadcn's DropdownMenu in for that specific surface — the two patterns can coexist without conflict.