Next.js UI Library Roundups List Five. This Site Uses Zero.

This storefront's package.json lists 8 production dependencies. One of them touches the UI at all — lucide-react, for icons. No shadcn/ui, no Radix, no MUI, no Chakra, no daisyUI, no NextUI: the roundups that dominate this search all recommend one of those five, and this codebase's 92 components use none of them.

The short answer

"Best Next.js UI library" roundups compare shadcn/ui, Radix, MUI, Chakra and daisyUI. This site ships zero of them — 92 components (7 atoms, 41 molecules, 33 organisms, 11 templates) built directly on Tailwind v4's @theme tokens, with a single import rule enforcing the hierarchy a library would otherwise impose for you.

What the roundups recommend

Search "next js ui library" and the top results — a DaisyUI landing page, a ThemeSelection roundup, a WrapPixel "25+ Top UI frameworks" list — converge on the same five names: shadcn/ui (Radix primitives, code you copy rather than a package you install), Chakra UI, daisyUI (Tailwind class names, no client runtime), NextUI, and Radix UI unstyled underneath most of the above. Every one solves the same problem: a library maintains the components, ships accessible defaults, and hands you a theming API to override.

What this codebase ships instead

Nothing from that list. A grep of package.json for any of the five names, or their usual peers (@radix-ui/*, @chakra-ui/*, class-variance-authority, clsx), returns zero matches. The only UI-adjacent dependency is lucide-react for icons. Everything else — buttons, cards, accordions, modals, carousels — is a hand-written component against Tailwind utility classes, organized into an explicit four-layer hierarchy:

92 files, zero of them importing a component-library package.

The rule that replaces the library's guardrails

A UI library's real value isn't just the components — it's that you can't accidentally import a Dialog into a Card in a way that breaks the design system, because the package boundary prevents it. This codebase gets the same guarantee from one enforced rule instead of a package boundary:

A level may only import from the levels below it. Never import sideways within a level, and never import an organism into a molecule.

Button.tsx (an atom) can only import from React/Next.js itself:

// src/components/atoms/Button.tsx (trimmed)
const variants: Record<ButtonVariant, string> = {
  primary: "bg-primary text-white hover:bg-primary-600",
  outline:
    "border border-stroke-tertiary bg-white text-text-color hover:bg-gray-50",
  dark: "bg-gray-900 text-white hover:bg-gray-800",
};

export default function Button({ variant = "primary", href = "#", className = "", children, ...rest }) {
  const classes = `${base} ${variants[variant]} ${className}`.trim();
  return isRoutable(href, external)
    ? <Link href={href} className={classes} {...rest}>{children}</Link>
    : <a href={href} className={classes} {...rest}>{children}</a>;
}

Three variants, one className escape hatch for call-site overrides — no cva, no cn() helper, no theming provider. A molecule can import this atom; an atom can never import a molecule back. Nothing enforces that at the TypeScript level — it's a convention, checked by review, not a compiler — which is the actual cost side of skipping a library: you get the freedom of hand-written components without a package's compile-time guardrail, and you keep the rule alive by discipline instead of a linter.

The same variant pattern, repeated by hand across every atom

A library like shadcn/ui gives you cva() (class-variance-authority) to declare variants once, generically, for any component. This codebase has no such helper — every atom that needs variants declares its own plain Record, and every atom that doesn't still follows the same "sensible default, override via className" shape:

// src/components/atoms/SectionHeading.tsx
export default function SectionHeading({
  as: Tag = "h2",
  className = "text-3xl font-bold !leading-[1.2] text-title-color md:text-[40px]",
  children,
}: { as?: "h1" | "h2"; className?: string; children: ReactNode }) {
  return <Tag className={className}>{children}</Tag>;
}

No variants object here at all — SectionHeading only ever has one look, so its "API" is a full-string default plus a className prop that replaces it outright. Button needed an actual variants record because it has three distinct looks; SectionHeading and SectionLabel don't, so they skip the abstraction rather than building a generic variant system nothing in the codebase would use. A library tends to ship one mechanism (cva, or a variant prop convention) for every component regardless of how many looks it actually has; this codebase's atoms each carry only as much variant machinery as their own call sites require.

Where zero-library has a real, documented cost

The Button atom above has no dark-mode variants baked in — every call site that needs a dark background does its own override:

<Button variant="primary" className="dark:bg-gray-800 dark:text-white/80">

A library with a theming system (Chakra's color mode, shadcn's CSS variables) solves this once, centrally. This codebase's documented convention is the opposite: "the shared Button atom has no dark variants — use the established call-site className workarounds." That's a real, acknowledged tradeoff, not a hidden one — 92 hand-written components mean 92 places a future dark-mode change might need a matching edit, instead of one theming object a library would let you update in place.

The comparison

When a library is the right call instead

This isn't an argument that libraries are wrong — it's what one storefront's actual tradeoff looks like. A UI library earns its cost fast on anything with genuinely hard interaction contracts: a combobox with keyboard nav and screen-reader announcements, a date-range picker, a data table with sortable/resizable columns. This catalog has none of those — its most complex client interaction is an accordion (FaqItem) and a carousel (TemplateGallery) — so the accessibility work a library would otherwise buy has a small, one-time surface here instead of an ongoing maintenance one.

Troubleshooting

Frequently asked questions

Is it bad practice to build a Next.js app without a UI library? No — it's a tradeoff. You give up centralized theming and pre-built accessibility in exchange for zero dependency weight and full control. This site's 92 components make that tradeoff explicitly and document where it costs the most (dark-mode overrides).

What replaces shadcn/ui's theming here? Tailwind v4's @theme tokens in globals.css — a --color-primary scale and semantic tokens (text-color, title-color) that every atom and molecule reads from, the same role a library's theme object plays.

Doesn't skipping a library mean rebuilding accessibility from scratch? For each component, yes — see Button's hand-built aria-disabled + tabIndex={0} pattern for a disabled CTA. That cost is proportional to how many genuinely complex interactive patterns you have; this catalog's are few.

How does this codebase stop components from being imported out of order? A documented rule ("a level may only import from levels below it"), enforced by code review — not the compiler. A library's package boundary would enforce the equivalent automatically.

Templates in this post

ASoc Ignite, ASoc Iris and ASoc Keystone are Next.js + Tailwind landing page templates, built on the same library-free component system described above.

Browse the full sets: Next.js landing page templates, Tailwind landing page templates.