Drivn vs shadcn/ui — Toast Compared

The starting point of any honest comparison: this is not Drivn's queue versus shadcn's queue. shadcn/ui retired its original Radix-primitive Toast and now recommends a Sonner component that renders <Toaster /> from the Sonner library. Drivn does the same — its Toast is a Toaster that mounts Sonner once near your app root. So stacking behaviour, swipe-to-dismiss, auto-dismiss timers, the promise API, and accessibility live-region announcements are identical, because they come from the same upstream package on both sides.

What that means in practice is that you cannot pick one of these for a fundamentally better notification engine — there isn't one. You pick based on the wrapper's defaults: which icons are wired, how the surface is themed, and how cleanly the install drops into your stack. The rest of this page is about exactly those defaults, copied verbatim from the Drivn registry so you can see precisely what npx drivn add toast gives you over a bare Sonner install.

The most visible difference is the icon map. A bare Sonner install shows no leading icon on typed toasts unless you wire one yourself. Drivn's Toaster passes an icons prop to Sonner that maps each toast type to a lucide-react icon: CheckCircle2 for success, Info for info, AlertTriangle for warning, XCircle for error, and a Loader2 spinning at animate-spin for the loading state. Every icon is sized w-4 h-4 so it sits consistently against the text.

This is the block you would otherwise hand-author against the Sonner API. Because Drivn ships it pre-wired and you own the source after install, you can swap any icon for your own brand set by editing the one icons object — no fork, no config layer. The snippet below is copied verbatim from the registry.

The second difference is how the toast surface is themed. shadcn's Sonner wrapper leans on the theme prop from next-themes plus a set of toastOptions classNames. Drivn instead drives the surface entirely from its own design tokens through Sonner's CSS custom properties: --normal-bg is set to var(--card), --normal-text to var(--card-foreground), --normal-border to var(--border), and --border-radius to 12px. Because those tokens already flip between light and dark in Drivn's theme system, the toast follows your theme without a separate theme prop.

The practical payoff is that a Drivn toast matches a Drivn Card out of the box — same background, same border colour, same corner radius — so notifications feel like part of the same surface family rather than a bolted-on library default. The style block below is verbatim from the registry.

Because Drivn re-exports toast directly from Sonner (export { Toaster, toast }), every call you know from the Sonner or shadcn docs works unchanged. toast.success, toast.error, toast.info, toast.warning, and toast.loading all fire the matching typed toast with the pre-wired icon. The second argument carries options — a description string for a secondary line, an action object with a label and onClick for an inline button, and toast.promise for tying a toast to an async lifecycle.

This is deliberate: Drivn does not invent a new notification API on top of Sonner, it just gives you better defaults underneath the same calls. So migrating a shadcn Sonner setup to Drivn is mechanical — swap the import path, keep every toast() call. For the full set of usage patterns, the Toast examples page walks the variants, descriptions, actions, and positioning one at a time.