Frameworks kommen und gehen. jQuery dominierte zehn Jahre, dann kam Angular, dann React, jetzt wachsen Svelte und Solid. Jeder Wechsel bedeutet: Komponentenbibliotheken neu schreiben, Teams umschulen, Migrationsprojekte finanzieren. Web Components versprechen einen Ausweg – Komponenten, die in jedem Framework funktionieren, weil sie auf Browser-Standards basieren.
Die drei Säulen
Custom Elements erlauben die Definition eigener HTML-Elemente. <my-button> wird vom Browser als eigenständiges Element mit eigenem Lebenszyklus (connectedCallback, disconnectedCallback, attributeChangedCallback) behandelt. Custom Elements können Attribute entgegennehmen, Events feuern und haben einen klar definierten Lebenszyklus.
Shadow DOM kapselt das interne DOM und CSS einer Komponente vollständig. Styles innerhalb des Shadow DOM können nicht nach außen leaken, und äußere Styles können nicht eindringen – es sei denn, die Komponente stellt explizite CSS Custom Properties oder ::part()-Selektoren als Styling-API bereit. Diese Kapselung löst eines der größten Probleme großer Codebases: CSS-Konflikte zwischen Komponenten.
HTML Templates (<template> und <slot>) definieren wiederverwendbare Markup-Strukturen, die erst bei Bedarf geklont und in das DOM eingefügt werden. Slots ermöglichen Content-Projection – ein Pattern, das aus allen modernen Frameworks bekannt ist, hier aber browsernativ funktioniert.
Praxistauglichkeit 2025
Der Browser-Support ist vollständig: alle modernen Browser unterstützen Custom Elements v1, Shadow DOM v1 und HTML Templates. Das war vor fünf Jahren noch anders. Tools wie Lit (Google), Stencil (Ionic) und Fast (Microsoft) vereinfachen die Entwicklung erheblich.
Lit ist dabei das am weitesten verbreitete Tool: Es generiert schlanke Custom Elements mit reaktiver Datenbindung und deklarativem Template-System. Die Bundle-Size liegt bei ~5 KB (gzip) für die Runtime – deutlich leichter als jedes Framework.
Prominente Design-Systeme, die auf Web Components setzen: Adobe Spectrum Web Components, IBM Carbon Web Components, SAP UI5 Web Components, GOV.UK Web Components (experimentell). Die Gemeinsamkeit: große Organisationen mit heterogenen Tech-Stacks, in denen Framework-Vielfalt Realität ist.
Web Components + Design Tokens
Web Components und Design Tokens ergänzen sich ideal. Die Styling-API einer Web Component basiert auf CSS Custom Properties – genau das Format, das Token-Build-Pipelines als Output erzeugen.
/* Von außen steuerbar über CSS Custom Properties */
:host {
--button-bg: var(--color-action-primary, #2563EB);
--button-radius: var(--radius-md, 6px);
background: var(--button-bg);
border-radius: var(--button-radius);
}Token-Werte fließen über CSS Custom Properties in die Komponente – ohne Build-Tool-Integration, ohne Framework-spezifische Adapter. Das ist die reinste Form der Trennung von Verhalten und Styling.
Grenzen und Trade-offs
Web Components sind kein Allheilmittel. Server-Side Rendering (SSR) ist mit Shadow DOM komplex – Declarative Shadow DOM verbessert die Situation, ist aber noch nicht überall etabliert. Die Developer Experience liegt hinter React/Svelte/Vue zurück, insbesondere bei reaktiver Datenbindung ohne Lit. Form-Participation API ist relativ neu und nicht in allen Szenarien smooth.
Kernpunkte
- Web Components basieren auf drei W3C-Standards: Custom Elements, Shadow DOM und HTML Templates.
- Browser-Support ist 2025 vollständig – Lit, Stencil und Fast vereinfachen die Entwicklung.
- Adobe, IBM, SAP und GOV.UK setzen auf Web Components für ihre Design-Systeme – alle mit heterogenen Tech-Stacks.
- CSS Custom Properties als Styling-API verbinden Web Components nahtlos mit Token-Architekturen.
- SSR bleibt der größte Trade-off – Declarative Shadow DOM verbessert die Situation.
- Web Components sind besonders relevant für Organisationen mit Framework-Vielfalt und langen Planungshorizonten.
