Drivn vs shadcn/ui — Breadcrumb Compared

shadcn/ui's Breadcrumb is a tree of co-dependent exports. A typical usage pulls Breadcrumb, BreadcrumbList, BreadcrumbItem, BreadcrumbLink, BreadcrumbPage, and BreadcrumbSeparator from the same file, then nests them in a specific order. The import statement alone runs past eighty characters, and refactoring a route means editing six places that all reference the same component family.

Drivn's Breadcrumb uses one named import. Every sub-component hangs off the root via Object.assign, so TypeScript autocompletes Breadcrumb.Item, Breadcrumb.Page, and Breadcrumb.Separator after you type the dot. The same hierarchy is visible in the JSX, but the import and the parent-child relationship live in a single place. Smaller diffs on refactor, less import churn, and no risk of importing BreadcrumbLink from the wrong file in a monorepo with multiple component libraries.

In shadcn/ui, every separator is typed manually. After every BreadcrumbItem except the last, you place a <BreadcrumbSeparator />. A three-level breadcrumb needs two separator tags; a five-level breadcrumb needs four. The separator is part of the markup, and the JSX tree grows linearly with depth.

Drivn's Breadcrumb injects separators at render time. The root uses React.Children.toArray(children).flatMap() to iterate over children and inserts a Breadcrumb.Separator before every item past the first. You write only the items. A three-level breadcrumb has three JSX children, not five; a five-level breadcrumb has five, not nine. The JSX stays focused on the trail itself, while separator strategy is handled once in the root component and never repeated at call sites.

shadcn/ui's Breadcrumb pulls @radix-ui/react-slot for the asChild prop on BreadcrumbLink. Slot is a small primitive but it is still a runtime dependency your bundler resolves and your package.json records. Across a full shadcn install that uses many components with asChild, Slot becomes one of the most frequently-imported pieces.

Drivn's Breadcrumb has zero runtime UI dependencies. The source imports React, the local cn() utility, and two Lucide icons — ChevronRight for the default separator and MoreHorizontal for the ellipsis. The total component is around eighty lines. If you need to render the link as a Next.js <Link>, you edit the local Item function in src/components/ui/breadcrumb.tsx after install and swap the <a> for a <Link>. For most breadcrumb patterns — static site nav, docs trees, settings pages — that is a one-line edit you make once.

Both libraries ship a ChevronRight as the default separator. Replacing it is where the APIs diverge. shadcn/ui's BreadcrumbSeparator renders whatever children you pass — a chevron, a slash, a dot — but because every separator in the tree is a separate JSX node, you pass the same child into each one or wrap the separator in your own component that always injects the same glyph.

Drivn's Breadcrumb root accepts a separator prop. Pass <span>/</span> once on the root and every auto-injected separator uses the slash. The prop is typed as React.ReactNode, so any JSX works — an icon from a different set, a styled character, a branded element. Changing the trail's glyph across a whole app is a single prop override at the root layout.

Both libraries get the core accessibility right. The root renders as a <nav> with aria-label="Breadcrumb", the list uses <ol> for ordered semantics, each link sits inside an <li>, and the current page has aria-current="page" so screen readers announce it distinctly from the links.

Drivn's Breadcrumb also marks separators as aria-hidden="true" with role="presentation" so assistive tech ignores the visual dividers. The ellipsis component wraps its icon with an <span className="sr-only">More pages</span> so users navigating with a screen reader hear a meaningful label instead of silence. shadcn/ui's Breadcrumb handles the same patterns, and the two implementations pass the same axe and Lighthouse checks. The accessibility story is a wash — both are correct by default. The difference lives elsewhere, in composition surface and runtime footprint.