Shadcn Blocks vs Components: Womit du anfangen solltest

Bibliotheken, deren Quellcode du in dein Projekt kopierst, gibt es inzwischen in drei Größen: Komponenten, Blocks und Seitenvorlagen. Die Frage „shadcn blocks vs components“ stellt sich bei jedem neuen Screen. Installierst du den Block login-04 und passt ihn an, oder holst du dir button, card und input und baust das Formular selbst? Kaufst du eine Vorlage für die Landing Page, oder setzt du Abschnitte zusammen? Jeder Anbieter benutzt die Begriffe anders. Deshalb klärt dieser Beitrag, was jeder Begriff bedeutet, was dir jede Ebene abnimmt, was sie kostet, sobald dein Design vom Standard abweicht, und wo du anfangen solltest.

Wir bauen Wingo UI und sind deshalb nicht neutral. Fakten zu shadcn/ui und anderen Anbietern verlinken auf die Seite, die wir gelesen haben, und tragen das Datum unserer Prüfung: 16. Oktober 2026.

Was ist der Unterschied zwischen shadcn Blocks und Components?

Eine Komponente von shadcn/ui ist eine Datei, die du überall importierst, und ein Block ist eine Gruppe von Dateien, die Komponenten zu einem Screen zusammensetzt. Der Unterschied steht direkt in der Registry: Jedes Item im Schema von registry-item.json (opens in a new tab) hat einen Typ. Die Doku beschreibt registry:ui als UI-Komponenten und Primitives aus einer einzigen Datei und registry:block als komplexe Komponenten aus mehreren Dateien.

Die Registry-Dateien zeigen, was das praktisch heißt. So sah die Registry new-york-v4 aus, als wir sie abgerufen haben:

• Eine Komponente wie button ist eine einzige Datei vom Typ registry:ui. Sie landet in components/ui/button.tsx, und jeder Screen importiert sie.
• Ein Block wie login-01 hat zwei Dateien. Eine Datei vom Typ registry:page wird nach app/login/page.tsx geschrieben, eine vom Typ registry:component nach components/login-form.tsx. Der Block listet button, card, input, label und field als Registry-Abhängigkeiten, also installiert die CLI sie gleich mit.
• Ein größerer Block wie dashboard-01 schreibt 11 Dateien (eine Seite, eine data.json und neun Komponenten), fügt sieben npm-Pakete hinzu (vier @dnd-kit-Pakete, @tabler/icons-react, @tanstack/react-table und zod) und zieht 19 Komponenten nach.

Ein Block ist also eine Komposition, die Vorgaben zum Layout macht und manchmal auch zum Routing: login-01 legt fest, dass dein Login unter /login liegt. Installiert wird beides mit demselben Befehl: npx shadcn@latest add button oder npx shadcn@latest add login-01.

Vorlagen sind die dritte Ebene, und shadcn/ui liefert keine. Die offizielle Blocks-Seite (opens in a new tab) hat keinen Bereich für Vorlagen. Wer nach shadcn templates, shadcn page templates oder shadcn Vorlagen sucht, landet bei Produkten von Drittanbietern: ganze Seiten oder ganze Websites auf Basis von shadcn/ui, meist als Projekt heruntergeladen statt mit der CLI hinzugefügt.

Warum bedeuten die Begriffe auf jeder Website etwas anderes?

Jeder Katalog zieht die Grenzen an einer anderen Stelle, also steht dasselbe Wort für unterschiedliche Größen:

Liest du einen Vergleich blocks vs templates, achte darauf, wessen Vokabular er benutzt. Ein Block bei shadcnblocks ist meist ein Abschnitt einer Seite, ein Block bei shadcn/ui oft ein ganzer Screen.

Was nimmt dir jede Ebene ab?

Jede Stufe nach oben erspart dir Entscheidungen zu Layout und Verdrahtung und trifft mehr davon für dich.

Auf jeder Ebene sparst du dir andere Arbeit. Eine Komponente nimmt dir den schweren Teil eines Bedienelements ab: den Focus Trap im Dialog, den Roving Tab Index im Menü, den Preis, der beim Umschalten animiert wechselt. Ein Block nimmt dir das Zusammensetzen ab: welches Feld wohin kommt, die Abstände dazwischen, die Leer- und Fehlerzustände, an die schon jemand gedacht hat. Eine Vorlage nimmt dir Designentscheidungen über die ganze Seite ab: die Reihenfolge der Abschnitte, den Rhythmus, welcher Streifen grau ist.

Was kostet es, einen Block anzupassen?

Ein Block kostet so viel, wie sein Ablauf von deinem abweicht. Die offiziellen Blocks von shadcn/ui halten diese Kosten sichtbar, weil sie aus kurzem Markup mit festen Texten bestehen.

Laut seiner Registry-Datei schreibt npx shadcn@latest add login-01 diese Dateien:

app/login/page.tsx            # registry:page, rendert <LoginForm />
components/login-form.tsx     # registry:component, etwa 70 Zeilen
components/ui/button.tsx      # dazu card, input, label, field

LoginForm nimmt nur className und die übrigen Props eines div an. Der Titel, der Platzhalter, „Forgot your password?“ und „Login with Google“ stehen als Strings im JSX. Das <form>-Element hat keinen Submit-Handler, keine Validierung und keinen Fehlerzustand. Für einen kostenlosen Ausgangspunkt ist das eine faire Entscheidung: Die Datei ist kurz, gut lesbar und gehört dir. Es bedeutet aber auch, dass du für jede Änderung diese Datei bearbeitest:

• Texte, Farben und Abstände: günstig. Du änderst die Strings und Klassen.
• Verhalten: schreibst du selbst. Submit-Handling, Feldfehler, ein Hinweis bei fehlgeschlagener Anmeldung, ein Ladezustand, eine Ansicht zum Zurücksetzen des Passworts und ein Code-Schritt: alles neuer Code.
• Updates: Den Merge machst du selbst. Die shadcn CLI (opens in a new tab) behält entweder deine Datei oder überschreibt sie (--overwrite), und add --diff zeigt einen 2-Wege-Diff, der nicht sagen kann, welche Zeilen von dir sind. Unser Guide shadcn-Komponenten aktualisieren, ohne deine Änderungen zu verlieren zeigt den 3-Wege-Merge, der das löst.

Wenn dein Login aus E-Mail und Passwort mit einem Social-Button besteht, ist login-01 in ein paar Minuten angepasst. Brauchst du Magic Links, Zwei-Schritt-Codes und Passwort-Wiederherstellung, schreibst du den Großteil des Screens selbst, und der Block hat dir bei den ersten 70 Zeilen geholfen.

Was ändern Blocks mit Props an der Rechnung?

Ein Block, der über Props gesteuert wird, verlegt die üblichen Änderungen an die Stelle, an der du ihn aufrufst. Die Datei bleibt so, wie sie geliefert wurde, und Updates bleiben günstig. So baut Wingo UI seine Blocks. Der Preis ist die Größe: Unser Block Login Page hat 1.617 Zeilen plus eine Layout-Datei mit 180 Zeilen, gegenüber den 70 Zeilen von login-01. Den liest du nicht in einem Rutsch, und sein Inneres umzuschreiben ist eine größere Aufgabe, als ein kurzes Formular zu bearbeiten.

Dafür bekommst du, gesteuert über Props, den Ablauf, den login-01 weglässt: die Methoden Passwort, Magic Link und Code per E-Mail, einen zweiten Schritt mit Code nach dem Passwort, eine Ansicht zum Zurücksetzen, Wartezeiten fürs erneute Senden und den Fehlerhinweis. Wirft ein Handler einen Error, zeigt das Formular dessen Nachricht an.

// app/(auth)/login/page.tsx
"use client";

import Link from "next/link";
import { useRouter } from "next/navigation";
import { LoginPage, type SignInValues } from "@/components/blocks/login-page";

async function post(url: string, body: unknown) {
  const res = await fetch(url, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(body),
  });
  if (!res.ok) {
    const data = await res.json().catch(() => ({}));
    throw new Error(data.message ?? "Etwas ist schiefgelaufen. Versuch es noch einmal.");
  }
}

export default function LoginRoute() {
  const router = useRouter();
  return (
    <LoginPage
      linkComponent={Link}
      methods={["password"]}
      twoFactor
      providers={[]}
      registerHref="/sign-up"
      onSignIn={(values: SignInValues) => post("/api/auth/sign-in", values)}
      onVerifyCode={(code) => post("/api/auth/two-factor", { code })}
      onForgot={(email) => post("/api/auth/forgot", { email })}
      onReset={(password) => post("/api/auth/reset", { password })}
      onSuccess={() => router.push("/app")}
    />
  );
}

Der Haken ist die Kehrseite davon, dass der Block schon ohne Props fertig aussieht: Jeder Handler, den du nicht übergibst, wird simuliert. Lässt du onVerifyCode weg, akzeptiert die Ansicht für den zweiten Schritt 123456. Lässt du onForgot weg, läuft die Anfrage zum Zurücksetzen durch, ohne dass etwas verschickt wird. Prüf vor dem Release, dass jede Methode und jede Ansicht, die du einschaltest, ihren Handler hat.

Hier ist ein Pricing-Screen auf allen drei Ebenen.

Komponente: eine Preistabelle in deiner eigenen Seite

Die Pricing Table ist eine einzelne Komponente. Ihr gehören die Pläne, der Schalter Monthly / Yearly, die rollenden Preise und das Karussell auf dem Smartphone. Dir gehört die Seite drumherum.

// app/(marketing)/pricing/page.tsx
"use client";

import { PricingTable, type PricingPlan } from "@/components/ui/pricing-table";

const plans: PricingPlan[] = [
  { id: "free", name: "Free", price: 0, features: ["3 Projekte", "Community-Support"] },
  {
    id: "pro",
    name: "Pro",
    price: { monthly: 12, yearly: 120 },
    featured: true,
    features: ["Unbegrenzte Projekte", "Automatisierungen", "Bevorzugter Support"],
    cta: { label: "Kostenlos testen", href: "/sign-up?plan=pro" },
    note: "14 Tage kostenlos, ohne Karte",
  },
  { id: "business", name: "Business", price: { monthly: 24, yearly: 240 }, features: ["SSO", "Audit-Log"] },
];

export default function PricingRoute() {
  return (
    <main className="mx-auto max-w-5xl px-4 py-16">
      <h1 className="text-3xl font-semibold tracking-tight">Preise</h1>
      <PricingTable plans={plans} defaultPeriod="yearly" className="mt-10" />
    </main>
  );
}

Block: die ganze Pricing-Seite

Der Block Pricing Page setzt diese Tabelle mit einem Währungsschalter, einer Vergleichstabelle, Kundenzitaten, einem FAQ und einem Abschlussstreifen zusammen. Deine Pläne und dein FAQ gehen als Daten hinein, und einen Abschnitt schaltest du mit einem Boolean ab.

// app/(marketing)/pricing/page.tsx
"use client";

import Link from "next/link";
import { useRouter } from "next/navigation";
import { PricingPage } from "@/components/blocks/pricing-page";

export default function PricingRoute() {
  const router = useRouter();
  return (
    <PricingPage
      linkComponent={Link}
      header={false}
      footer={false}
      showTestimonials={false}
      currencies={["USD"]}
      faqs={[{ question: "Kann ich jederzeit kündigen?", answer: "Ja. Dein Plan bleibt bis zum Ende des Zeitraums aktiv." }]}
      onSelectPlan={(planId, period, currency) =>
        router.push(`/sign-up?plan=${planId}&period=${period}&currency=${currency}`)
      }
    />
  );
}

Mit header={false} und footer={false} sitzt die Seite in deinem eigenen Site-Layout, und ein einziger Eintrag in currencies blendet den Währungsschalter aus. Lässt du plans weg, erscheinen die Beispielpläne. Das ist praktisch, solange du die Daten anbindest, landet aber auch schnell aus Versehen in Produktion. Gibt onSelectPlan ein Promise zurück, dreht sich der Spinner im Button des Plans, bis es abgeschlossen ist.

Vorlage: eine ganze Seite aus Abschnitten

Die Vorlage Landing Page liegt eine Ebene höher. Sie rendert einen Hero, Logos, ein Feature-Raster, eine Produkttour, Zahlen, Zitate, einen Pricing-Teaser, ein FAQ und einen Abschlussstreifen. Jedes dieser Elemente ist ein Marketing-Abschnitt, den du auch einzeln installieren kannst, etwa die Hero Section.

// app/(marketing)/page.tsx
"use client";

import Link from "next/link";
import { LandingPage } from "@/components/templates/landing-page";

export default function HomeRoute() {
  return (
    <LandingPage
      linkComponent={Link}
      design="minimal"
      ctaTone="brand"
      showStats={false}
      labels={{
        heroTitle: "Rechnungen, die deine Kunden pünktlich zahlen",
        heroDescription: "Verschick, verfolge und mahne Rechnungen aus einem Posteingang.",
      }}
    />
  );
}

design ändert den Look aller Abschnitte auf einmal (classic, bold, editorial oder minimal), und Overrides pro Abschnitt wie heroProps haben trotzdem Vorrang.

Wann startest du mit Komponenten, einem Block oder einer Vorlage?

Starte auf der höchsten Ebene, auf der du nur Inhalte, Texte, Farben und Handler ändern würdest. Würdest du Layout oder Zustände neu schreiben, starte eine Ebene tiefer.

• Starte bei Standard-Screens mit einem Block. Sign-in, Sign-up, Pricing, Einstellungen, Checkout und Fehlerseiten funktionieren in den meisten Produkten gleich. Sie haben viele Zustände (Fehler, Laden, Codes, leere Listen), die man leicht vergisst. Unsere Guides zur shadcn Login-Seite und zur shadcn Pricing-Seite listen diese Zustände im Detail.
• Starte bei Marketing-Seiten mit einer Vorlage. Eine Landing-, Kontakt- oder FAQ-Seite hat ein festes Design und wechselnde Inhalte. Eine Vorlage trifft den Rhythmus, und du ersetzt die Texte.
• Starte beim Kern deines Produkts mit Komponenten. Der Editor, das Board, das Dashboard, das nur deine App hat. Ein Block, der für das Produkt von jemand anderem entworfen wurde, arbeitet dort gegen dich, und das Schwierige steckt ohnehin in den Komponenten.
• Starte mit Komponenten, wenn dein Design System weit vom Standard entfernt ist. Weichen deine Abstände, deine Typo-Skala und dein Radius von denen des Blocks ab, fasst du jede Zeile an.
• Starte bei einem Prototyp mit einem Block, auch wenn er nicht gut passt. Ein funktionierender Screen zeigt dir an einem Nachmittag, welche Zustände du brauchst. Danach entscheidest du, ob du ihn behältst oder aus Komponenten neu baust.

Die meisten echten Apps kombinieren alle drei Ebenen: eine Vorlage für die Startseite, Blocks für Auth und Pricing und Komponenten für das Produkt selbst.

Wie gehst du eine Ebene tiefer, ohne neu anzufangen?

Nutz die Teile, aus denen ein Block gebaut ist. So verlierst du sein Design nicht, wenn du den Block verlässt. Der Block Login Page exportiert sein Layout als AuthFrame: eine Formularspalte, die einen Smartphone-Screen füllt, ab 1024px mit einem Hero daneben. Eine Einladungs- oder Sign-up-Seite kann ihr eigenes Formular in den Rahmen setzen und passt trotzdem zum Login-Screen. AuthFrame ist selbst eine Client-Komponente, also kann die Seite im Beispiel unten eine Server-Komponente bleiben.

// app/(auth)/invite/page.tsx
import { AuthFrame } from "@/components/blocks/login-page-frame";
import { Button } from "@/components/ui/button";
import { Input } from "@/components/ui/input";

export default function InviteRoute() {
  return (
    <AuthFrame
      layout="split"
      heroLabel="Über Acme"
      hero={<p className="text-lg font-medium">Dein Team ist schon hier.</p>}
    >
      <form action="/api/invites/accept" method="post" className="flex flex-col gap-4">
        <h1 className="text-2xl font-semibold tracking-tight">Tritt Acme bei</h1>
        <Input name="name" label="Vollständiger Name" autoComplete="name" required />
        <Input name="password" type="password" label="Passwort" autoComplete="new-password" required />
        <Button type="submit" fullWidth>
          Einladung annehmen
        </Button>
      </form>
    </AuthFrame>
  );
}

Bei Vorlagen geht das genauso. Passt die Landing Page größtenteils, behalte sie und überschreib einen Abschnitt über seine *Props. Liegt sie weit daneben, setz die Abschnitte, die du brauchst, selbst zusammen: npx wingo-ui@latest add hero-section faq-section cta-section.

Shadcn Blocks vs Templates: Wo bekommst du was?

Die offizielle Registry von shadcn/ui ist die kostenlose Option ohne Vorlagen, shadcnblocks hat den größten Katalog an Abschnitten und Vorlagen, und Wingo UI liefert weniger Blocks, die dafür über Props gesteuert werden. Stand: 16. Oktober 2026.

Die Zahlen zu Wingo UI stammen aus unserer Registry, Release 1.9.0. Login Page, Pricing Page, Pricing Table und Landing Page sind Pro. Die Vorlagen für die Kontakt- und die FAQ-Seite sind kostenlos, ebenso Grundbausteine wie Button, Input und Card.

Wo die anderen die bessere Wahl sind:

• Du willst kostenlose, kurze Dateien, die du sowieso bearbeitest: die offiziellen shadcn Blocks. Sie sind klein genug, um sie in einer Minute zu lesen, und die Lizenz kostet nichts.
• Du brauchst eine große Auswahl an Marketing-Abschnitten oder eine Astro-Website: shadcnblocks hat weit mehr Varianten als die beiden anderen und liefert für die meisten seiner Vorlagen eine Astro-Version.
• Du willst Blocks, die du über Props konfigurierst, die sich auf Smartphones gut verhalten und die du nach dem Bearbeiten aktualisieren kannst: Genau dafür ist Wingo UI gebaut. Den Überblick über den ganzen Markt gibt unser Guide zu shadcn-Alternativen, der 14 Bibliotheken vergleicht, und die Kategorie Vergleiche und Alternativen sammelt die direkten Gegenüberstellungen.

Was ist dein nächster Schritt?

Nimm den Screen, den du gleich bauen willst, und wende die Regel von oben an: Würdest du nur Inhalte und Handler ändern oder auch das Layout? Ist es ein Standard-Screen, öffne die Doku zu Login Page oder Pricing Page und probier die Props im Playground aus, bevor du irgendetwas installierst. Beide gehören zu Wingo UI Pro, siehe Preise. Willst du mit kostenlosen Teilen anfangen, gibt dir npx wingo-ui@latest add button input card die Komponenten, auf denen die Blocks aufbauen.

Häufige Fragen

Was ist der Unterschied zwischen shadcn Blocks und Components?

Eine Komponente von shadcn/ui ist eine einzelne Datei wie button.tsx, die du einmal installierst und überall importierst. Ein Block besteht aus mehreren Dateien und setzt Komponenten zu einem Screen zusammen: login-01 schreibt app/login/page.tsx und components/login-form.tsx und installiert button, card, input, label und field als Abhängigkeiten.

Hat shadcn/ui offizielle Vorlagen?

Nein. Stand 16. Oktober 2026 hat die offizielle Registry 97 Blocks (70 Chart-Varianten, 16 Sidebars, 5 Login, 5 Sign-up und 1 Dashboard) und keine Seitenvorlagen. Komplette Vorlagen kommen von Drittanbietern wie shadcnblocks, das 21 Stück listet (eine davon kostenlos), oder aus Bibliotheken wie Wingo UI.

Sind shadcn Blocks kostenlos?

Die offiziellen Blocks auf ui.shadcn.com sind kostenlos und stehen wie die Komponenten unter der MIT-Lizenz. Block-Bibliotheken von Drittanbietern, die sich über die shadcn CLI installieren lassen, sind oft kostenpflichtig: shadcnblocks beginnt bei 149 $ einmalig, Stand 16. Oktober 2026.

Kann ich einen shadcn Block aktualisieren, nachdem ich ihn bearbeitet habe?

Nicht automatisch. Die shadcn CLI behält entweder deine Datei oder überschreibt sie, und add --diff zeigt einen 2-Wege-Diff, der deine Änderungen nicht von Änderungen am Original unterscheiden kann. Ein 3-Wege-Merge pro Datei behält beides, und npx wingo-ui@latest update führt diesen Merge für Wingo UI aus.

Soll ich Blocks nutzen oder aus Komponenten bauen?

Nimm einen Block, wenn sein Ablauf zu deinem passt und du vor allem Texte, Farben und Handler ändern würdest. Bau aus Komponenten, wenn du Layout oder Zustände neu schreiben würdest, denn einen fremden Screen so weit umzubauen kostet mehr, als deinen eigenen zusammenzusetzen.