01
Entscheidung
CTO, Bereichsleitung, Budgetverantwortung, technische Produktverantwortung
Kapitel01, 02, 15, 14, 16, Anhang A
Begründete Wahl zwischen bauen, anpassen und kaufen, mit Kostenrahmen, Teamaufstellung und Fahrplan
Fachhandbuch
Die Blaupause: Komponentenbibliothek bauen.
Das Handbuch für Teams, die eine eigene Komponentenbibliothek planen, bauen oder sanieren: Architektur, Design-Tokens, Barrierefreiheit, ein Element für alle Frameworks und der Betrieb über Jahre. Mit 67 Codebeispielen, 34 Checklisten und Mosaik als durchgängigem Fallbeispiel.
- 16 Kapitel
- 67 Codebeispiele
- 34 Checklisten
- ab 390 € zzgl. USt.
01Für wen das Handbuch ist
Eine Bibliothek ist ein Produkt, kein Projekt.
Wer eine Komponentenbibliothek baut, trifft Entscheidungen, die Jahre tragen müssen. Das Handbuch liefert die Kriterien dafür, die erprobten Muster und die typischen Fehler, bevor sie teuer werden.
- Mehrere Anwendungen sollen gleich aussehen und sich gleich bedienen lassen, auch über verschiedene Frameworks hinweg.
- Sie entscheiden, ob Sie eine Bibliothek selbst bauen, eine bestehende anpassen oder eine kaufen.
- Eine gewachsene Bibliothek ist schwer zu pflegen, Theming und Barrierefreiheit fehlen.
- Die Leitung erwartet einen Business Case mit Kostenrahmen, Teamaufstellung und Fahrplan.
02Der Inhalt
16 Kapitel, vom Entschluss bis zum Betrieb.
Jedes Kapitel endet mit dem Wichtigsten in Kürze. Die Anhänge sammeln alle Checklisten zum Abhaken und ein Glossar.
01Wie Sie dieses Handbuch nutzenDieses Kapitel klärt die Begriffe, zeigt drei Lesepfade durch das Buch und stellt das Fallbeispiel Mosaik vor.5
- Was eine Komponentenbibliothek ist
- Für wen dieses Handbuch ist
- Drei Lesepfade durch das Buch
- Das Fallbeispiel Mosaik
- Konventionen in diesem Buch
02Eigene Bibliothek, anpassen oder kaufen?Dieses Kapitel liefert die Kriterien, die realistischen Optionen und eine nachvollziehbare Kostenrechnung für die Grundsatzentscheidung.6
- Die Frage richtig stellen
- Fünf Entscheidungskriterien
- Die realistischen Optionen
- Gesamtkosten über fünf Jahre: Eine Schätzrechnung
- Business Case und Risiken
- Exit-Strategie: Den Ausstieg vor dem Einstieg planen
03Architektur und GrundentscheidungenEinige Entscheidungen lassen sich nach dem ersten Release kaum noch zurücknehmen: Plattform, Basisbibliothek, Kapselung, Paketzuschnitt, Browserbasis, Namen und Build.8
- Warum Web Components die gemeinsame Basis sind
- Lit 3 als Basis und die Alternativen
- Shadow DOM, Light DOM oder beides
- Repository, Pakete und Abhängigkeiten
- Browserbasis festlegen
- Namen, Präfixe und die Custom Element Registry
- TypeScript und Decorators
- Build, Module und Tree Shaking
04Das KomponentenmodellEine Komponente ist so gut wie ihre öffentliche API.8
- Die öffentliche API als Vertrag
- Attribute und Properties
- Events
- Slots, Unterelemente und Parts
- Wiederverwendbares Verhalten mit Controllern und Mixins
- Zustand und Formularbeteiligung
- Fokus und Lebenszyklus
- Leistung und Definition of Done
05Design-Tokens und ThemingDesign-Tokens machen Gestaltungsentscheidungen benennbar, prüfbar und für Werkzeuge lesbar.8
- Was Tokens sind und was nicht
- Drei Ebenen: Basis, Semantik, Komponente
- Das DTCG-Format 2025.10
- Die Token-Pipeline von JSON zu CSS, TypeScript und Tailwind
- Farbrampen, OKLCH und Kontrast
- Themes und Farbschemata zur Laufzeit
- Komponenten-Tokens, Dichte, Form und Typografie
- Abgleich mit Figma
06Styling und AnpassbarkeitShadow DOM schützt Komponenten vor fremden Stilen und zwingt dadurch zu einer ausdrücklichen Styling-API.8
- Kapselung durch Shadow DOM und ihre Folgen
- Die öffentliche Styling-API als Vertrag
- Varianten, Größen und Dichte
- Light DOM, Tailwind und globale Stile
- Constructable Stylesheets und Leistung
- Fokus, Hochkontrast und Schreibrichtung
- Versionierung der Styling-API
- Typische Fehler und Checkliste
07BarrierefreiheitBarrierefreiheit entsteht zum größten Teil in den Komponenten und nicht in den Anwendungen.8
- Warum die Bibliothek der wirksamste Ort ist
- Muster aus dem ARIA Authoring Practices Guide
- Shadow DOM: Fallen und Lösungen
- Tastatur und Fokus
- Fokusverwaltung in Overlays
- Formulare: Beschriftung, Fehler, Validierung
- Bewegung, Kontrast und erzwungene Farben
- Testen und dokumentieren
08Ein Element für alle FrameworksDas Custom Element ist die einzige Quelle, alle Framework-Pakete sind dünne, generierte Adapter.8
- Eine Quelle, viele dünne Adapter
- Das Custom Elements Manifest als Vertrag
- Architektur eines Wrapper-Generators
- React: Native Unterstützung, trotzdem Wrapper
- Angular: Standalone Components, Signal Inputs und Formulare
- Vue 3 und Svelte 5
- Typdefinitionen und serverseitiges Rendern
- Wrapper testen und abnehmen
09Das Fundament: Dienste jenseits der KomponentenKomponenten brauchen gemeinsame Dienste für Overlays, Sprache, Abhängigkeiten, Drag & Drop, Layout, Bewegung und Icons.8
- Was in die Bibliothek gehört und was in die Anwendung
- Overlays, Portale und Positionierung
- Internationalisierung
- Dependency Injection und Router
- Drag & Drop barrierefrei
- Layout und Bewegung: Breakpoints, Container Queries, Animationen
- Icons: Registry, Laden nach Bedarf und Lizenzen
- Entscheidungshilfe: Gehört das in die Bibliothek?
10Qualität: Tests und PrüfungenEine Bibliothek wird von vielen Anwendungen genutzt, und jeder Fehler erreicht alle gleichzeitig.8
- Teststrategie für eine Bibliothek
- Komponententests im echten Browser
- Interaktion, Barrierefreiheit und Cross-Browser
- Visuelle Regression
- API-Stabilität und Typen
- Wrapper, Pakete und Budgets
- Die CI-Pipeline
- Definition of Done und typische Fehler
11Dokumentation für Menschen und MaschinenEine Komponentenbibliothek ist nur so gut wie das, was andere über sie erfahren können.7
- Doku-Arten und ihre Leser
- Die API-Referenz aus dem Manifest
- Beispiele, Playground und Doku-Plattform
- Schreibrichtlinien: Beschreibungen mit Bedeutung
- Dokumentation für KI-Assistenten
- Ein MCP-Server für das Design-System
- Qualitätssicherung der KI-Doku
12Werkzeuge rund um die BibliothekKomponenten allein machen ein Design-System nicht nutzbar.7
- Welche Werkzeuge sich wann lohnen
- Playground je Komponente
- Themes: Editor, Generator, Paletten, Kontrast und Audit
- Token-Bridge, Motion und Typografie
- Visueller Designer, Rezepte und Starter-Vorlagen
- Icon-Galerie und KI-Kontext-Generator
- Reihenfolge und Dogfooding
13Veröffentlichen, versionieren, verteilenEine Komponentenbibliothek ist nur so verlässlich wie ihre Releases.7
- Semantic Versioning für Komponentenbibliotheken
- Changesets: Versionen und Changelogs im Monorepo
- Das Paketformat: ES-Module, exports, Typen, Manifest
- Die Wahl der Registry
- CDN-Auslieferung und Importmaps
- Deprecation, Migrationsleitfäden und Codemods
- Release Notes, Pipeline und Herkunftsnachweis
14Betrieb und GovernanceDieses Kapitel zeigt, wie eine Komponentenbibliothek nach dem ersten Release lebendig bleibt: Teammodell, Rollen, Beitragsprozess, Entscheidungsprotokolle, Support, Kennzahlen, Kommunikation, Finanzierung und Lebenszyklus.7
- Teammodelle und Rollen
- Beiträge und Entscheidungen
- Roadmap, Priorisierung und Support
- Adoption messen, ohne Zahlen zu erfinden
- Kommunikation: Changelog, Release Notes und Sprechstunde
- Finanzierung und interne Verrechnung
- Lebenszyklus von Komponenten
15Fahrplan: In 12 Monaten zur eigenen BibliothekDieses Kapitel übersetzt die Blaupause in einen Fahrplan mit vier Phasen, Meilensteinen und Abnahmekriterien.7
- Der Fahrplan im Überblick
- Phase 1, Monat 1 bis 2: Fundament
- Phase 2, Monat 3 bis 6: Kernkomponenten
- Phase 3, Monat 7 bis 9: Ausbau und Frameworks
- Phase 4, Monat 10 bis 12: Reife und Betrieb
- Die ersten 25 Komponenten in begründeter Reihenfolge
- Teamaufstellung und kleinere Teams
16Fallstudie MosaikMosaik zeigt öffentlich und nachprüfbar, wie eine frameworkunabhängige Komponentenbibliothek in großem Umfang aussehen kann.6
- Steckbrief
- Entstehung: Vier Epochen und eine Lehre
- Die tragenden Entscheidungen
- Was andere Teams übernehmen können und was nicht
- Offene Punkte aus Käufersicht
- Lehren
AAnhang A: ChecklistenDie wichtigsten Checklisten des Handbuchs an einer Stelle, zum Abhaken in Projekten, Reviews und Releases.10
- Bereit für eine eigene Bibliothek
- Architekturentscheidungen
- Neue Komponente: Definition of Done
- Design-Tokens
- Barrierefreiheit je Komponente
- Framework-Wrapper
- Release
- Deprecation
- Dokumentation
- Governance
BAnhang B: GlossarDie wichtigsten Fachbegriffe des Handbuchs in alphabetischer Reihenfolge, jeweils kurz erklärt.7
- A bis B
- C
- D bis E
- F bis K
- L bis P
- R bis S
- T bis Z
03Für jede Rolle
Drei Wege durch das Buch.
Kaum jemand liest ein Handbuch dieses Umfangs von vorn bis hinten. Drei Lesepfade führen jeweils zu einem greifbaren Ergebnis.
02
Architektur
Frontend-Lead, Architekturverantwortung
Kapitel01, 03, 04, 05, 06, 07, 08, 09, 13
Tragfähige Grundentscheidungen, festgehalten als ADR, und eine Paketstruktur für alle Frameworks
03
Umsetzung
Entwicklungsteam der Bibliothek, Design, Barrierefreiheit
Kapitel01, 04, 05, 06, 07, 10, 11, 12, 13, Anhang A
Komponenten, die getestet, dokumentiert, barrierefrei und veröffentlicht sind
04Einblick
Entscheidungen statt Meinungen.
Wo es mehrere Wege gibt, stellt das Handbuch sie nebeneinander und begründet seine Empfehlung. Vier Arten von Hervorhebungen ordnen das Wissen ein.
- Aus der Praxis: Erfahrungswissen und bewährtes Vorgehen.
- Stolperstelle: Typische Fehler und ihre Folgen.
- So macht es Mosaik: Belegte Lösungen aus dem Fallbeispiel.
- Das Wichtigste in Kürze: Die Kernaussagen am Ende jedes Kapitels.
05Das Fallbeispiel
Lernen an einer großen Bibliothek.
Mosaik zeigt öffentlich und nachprüfbar, wie eine frameworkunabhängige Komponentenbibliothek in großem Umfang aussehen kann. Kapitel 16 leitet die tragenden Entscheidungen her und trennt, was andere Teams übernehmen sollten, von dem, was nur in diesem Umfang trägt.
- 347Custom Elements einschließlich Unterelementen
- 329generierte Wrapper je Framework
- 10.000+Design-Tokens als CSS Custom Properties
- 32Werkzeuge im öffentlichen MCP-Server
Steckbrief aus Kapitel 16, Stand November 2026. Alle Empfehlungen und Codebeispiele gelten unabhängig von Mosaik.
06Preis und Lizenz
Drei Lizenzstufen, ein Handbuch.
Wählen Sie die Stufe nach der Zahl der Personen, die mit dem Handbuch arbeiten. Die Codebeispiele dürfen Sie in jeder Stufe in eigene Software übernehmen.
Einzellizenz
Für eine Person
390 €zzgl. USt., einmalig
- Handbuch als PDF
- Einsatz in beliebig vielen eigenen Projekten
- Codebeispiele in eigener Software nutzen
- Version 0.9, Stand November 2026
Teamlizenz
Für bis zu 10 Personen
1.490 €zzgl. USt., einmalig
- Handbuch als PDF
- Einsatz in beliebig vielen eigenen Projekten
- Codebeispiele in eigener Software nutzen
- Version 0.9, Stand November 2026
Unternehmenslizenz
Für alle Beschäftigten des Unternehmens
2.990 €zzgl. USt., einmalig
- Handbuch als PDF
- Einsatz in beliebig vielen eigenen Projekten
- Codebeispiele in eigener Software nutzen
- Version 0.9, Stand November 2026
Es gelten die Lizenzbedingungen. Der Verkauf startet in Kürze. Das Angebot richtet sich ausschließlich an Unternehmen.
07Fragen und Antworten
Häufige Fragen
Für welche Technologie sind die Codebeispiele geschrieben?
In TypeScript mit Lit 3, einer verbreiteten Basis für Web Components. Kapitel 08 zeigt, wie aus einem Element Wrapper für React, Angular, Vue und Svelte entstehen.
Brauche ich Mosaik, um das Handbuch zu nutzen?
Nein. Mosaik dient als Fallbeispiel und zeigt, wie eine große Bibliothek die Entscheidungen umsetzt. Die Empfehlungen und Codebeispiele gelten unabhängig davon.
Welche Lizenzstufe brauche ich?
Die Einzellizenz gilt für eine Person, die Teamlizenz für bis zu 10 Personen und die Unternehmenslizenz für alle Beschäftigten. Bei Einzel- und Teamlizenz legt das Unternehmen die berechtigten Personen fest und kann sie bei einem Wechsel austauschen.
Darf ich die Codebeispiele in eigener Software verwenden?
Ja, auch in Software, die Sie an Dritte weitergeben. Nicht erlaubt ist, das Handbuch selbst weiterzugeben oder Teile davon in eigene Produkte, Vorlagen oder Schulungsunterlagen zu übernehmen.
Wie erhalte ich das Handbuch und eine Rechnung?
Direkt nach dem Kauf erhalten Sie einen Link zum Herunterladen und eine Rechnung mit ausgewiesener Umsatzsteuer.
Wie aktuell sind die Inhalte?
Versionen, Browserunterstützung und Normen geben den Stand November 2026 wieder. Webstandards und Werkzeuge entwickeln sich laufend weiter. Version und Stand stehen auf dem Deckblatt.
Fragen zur Blaupause? Schreiben Sie mir.
Ob passende Lizenzstufe oder Fragen zum Inhalt: Schreiben Sie mir oder vereinbaren Sie ein kostenloses und unverbindliches Erstgespräch per Microsoft Teams.