Web Components (deutsch auch Webkomponenten) sind eine Gruppe von Webstandards, mit denen sich eigene benutzerdefinierte HTML-Elemente einschließlich ihres Aufbaus, Erscheinungsbilds und Verhaltens erstellen lassen, die anschließend wie die im HTML-Standard definierten HTML-Elemente verwendet werden können. Sie definieren ein browserintegriertes Komponentenmodell für Webanwendungen, das unabhängig von JavaScript-Frontendframeworks eingesetzt werden kann. Der Begriff bezeichnet keinen einzelnen Standard, sondern umfasst mehrere miteinander kombinierbare Techniken, insbesondere Custom Elements, Shadow DOM und das HTML-Element <template>. Diese Techniken sind getrennt voneinander einsetzbar und werden in den Standards der WHATWG beschrieben.^[1][2]

Frühe Konzepte der späteren Web Components wurden 2011 von dem Entwickler Alex Russell auf der Konferenz Fronteers in Amsterdam unter dem Titel Web Components and Model Driven Views vorgestellt. Russell, damals im Chrome-Team von Google tätig, stellte dabei unter anderem Konzepte wie gekapselte Dokumentbereiche und selbstdefinierte HTML-Elemente vor. Das W3C veröffentlichte im Mai 2012 mit Introduction to Web Components einen ersten Arbeitsentwurf, dem 2013 Entwürfe für die einzelnen Teilspezifikationen folgten. Die ursprünglich als einzelne W3C-Arbeitsentwürfe veröffentlichten Spezifikationen wurden später in die Living Standards der WHATWG und des DOM Standards überführt.^[3][4][5]

Google veröffentlichte 2013 das Projekt Polymer, das die noch unfertigen Web-Components-Funktionen über Polyfills auch in Browsern ohne native Unterstützung nutzbar machte und dem Konzept zu größerer Bekanntheit verhalf. Chrome und Opera implementierten ab 2014 erste Versionen der Web-Components-Funktionen, die später als v0 bezeichnet wurden.^[6]

Diese erste Fassung wurde von den übrigen Browserherstellern unterschiedlich bewertet. Mozilla und Apple äußerten unter anderem Bedenken hinsichtlich der Komplexität und der möglichen Auswirkungen auf die Ausführungsgeschwindigkeit, insbesondere beim damaligen Entwurf des Shadow DOM. Zu den ursprünglich vier vorgesehenen Bausteinen gehörten Custom Elements, Shadow DOM, HTML Templates und HTML Imports. Letztere wurden später nicht weitergeführt, nachdem sich ECMAScript-Module als allgemeiner Mechanismus zum Laden von Modulen etabliert hatten.^[7]

Nach der Überarbeitung der Spezifikationen zu einer als v1 bezeichneten Fassung wurden die überarbeiteten Spezifikationen von den großen Browserherstellern unterstützt. Chrome und Safari lieferten sie ab 2016 aus, Firefox folgte 2018 mit Version 63, und Microsoft Edge erhielt die Unterstützung 2020 mit dem Wechsel auf den Chromium-Unterbau. Damit waren Web Components in den großen Browsern ohne zusätzliche Polyfills nutzbar.^[8]

Die einzelnen Techniken werden heute nicht mehr als eigenständige Spezifikationen gepflegt, sondern sind in die bestehenden Kernstandards eingegangen. Custom Elements und das <template>-Element sind Bestandteil des HTML Living Standard der WHATWG, der Shadow DOM ist im DOM Living Standard beschrieben. Die zugehörigen CSS-Selektoren stammen aus den Modulen der CSS-Arbeitsgruppe des W3C.^[9][10][1]

Custom Elements sind eine Programmierschnittstelle zum Definieren eigener HTML-Elemente. Eine JavaScript-Klasse, die von HTMLElement erbt, wird über customElements.define() unter einem gültigen Namen registriert. Dieser Name muss mit einem ASCII-Kleinbuchstaben beginnen, mindestens einen Bindestrich enthalten und darf keine Großbuchstaben enthalten. Diese Regel dient der Vorwärtskompatibilität, damit benutzerdefinierte Elemente nicht mit künftigen Ergänzungen des HTML-Standards kollidieren.^[11][9]

Die Spezifikation unterscheidet autonome Custom Elements und erweiterte eingebaute Elemente. Autonome Custom Elements besitzen keine vom HTML-Standard vorgegebene Semantik. Erweiterte eingebaute Elemente werden von einer bestehenden Elementklasse abgeleitet und erben deren Semantik, werden jedoch nicht von allen Browsern unterstützt.^[12][13][9]

Der Lebenszyklus eines Custom Elements wird über Rückruffunktionen gesteuert. Dazu gehören insbesondere connectedCallback() und disconnectedCallback() beim Einfügen oder Entfernen des Elements aus dem Dokument sowie attributeChangedCallback() bei Änderungen beobachteter Attribute.^[11][9]

Über Element.attachShadow() erhält ein Element einen gekapselten Teilbaum (Shadow Tree), dessen Inhalte zwar dargestellt werden, jedoch nicht Teil des regulären Dokumentbaums der einbettenden Seite sind. Innerhalb des Shadow DOM definierte Formatvorlagen wirken sich nicht auf das übrige Dokument aus, während globale CSS-Regeln umgekehrt grundsätzlich nicht in den Shadow Tree hineinwirken. Dadurch ermöglicht der Shadow DOM die Kapselung von Web Components und verhindert Konflikte zwischen den CSS-Regeln der Komponente und der einbettenden Seite. Über Mechanismen wie :host, ::part(), ::slotted() sowie benutzerdefinierte CSS-Eigenschaften lässt sich die Darstellung dennoch gezielt von außen beeinflussen, etwa zur Anpassung an ein Corporate Design.^[14][1][15]

Das HTML-Element <template> nimmt Markup auf, das der Browser zwar verarbeitet, aber nicht darstellt. Im Template enthaltene Inhalte werden zunächst nicht als Teil des Dokuments verarbeitet. <template> dient damit als Vorlage für wiederverwendbare Strukturen.^[16][17]

Das HTML-Element <slot> dient in Verbindung mit dem Shadow DOM dazu, Inhalte aus dem umgebenden Dokument an definierten Stellen in eine Komponente einzublenden. Neben einem unbenannten Standardslot können benannte Slots verwendet werden, die über das Attribut slot angesprochen werden. Auf diese Weise lässt sich eine Komponente von außen mit Inhalt befüllen, ohne ihre innere Struktur offenzulegen.^[18][19]

Der Web Almanac des HTTP Archive weist für das Jahr 2024 den Einsatz von Custom Elements auf 7,9 Prozent der untersuchten mobilen und 7,7 Prozent der Desktop-Webseiten aus. 2022 lagen die Anteile noch bei 3,6 beziehungsweise 2,9 Prozent. Der Bericht nennt unter anderem den verstärkten Einsatz von Komponenten in Website-Baukästen und E-Commerce-Plattformen als mögliche Erklärung.^[20][21]

Im professionellen Umfeld werden Web Components unter anderem für die Entwicklung wiederverwendbarer Komponentenbibliotheken und Designsysteme eingesetzt. Aufgrund ihrer Standardisierung und Frameworkunabhängigkeit eignen sie sich außerdem für Architekturen auf Basis von Microfrontends, bei denen Benutzeroberflächen aus unabhängig entwickelten Komponenten zusammengesetzt werden.^[22][23]

Web Components können unmittelbar mit den standardisierten Webschnittstellen oder mithilfe spezialisierter Bibliotheken und Compiler entwickelt werden. Viele Werkzeuge übernehmen wiederkehrende Aufgaben wie das Aktualisieren der Darstellung oder die Erstellung von Komponenten aus deklarativen Vorlagen. Darüber hinaus unterstützen zahlreiche Webframeworks die Einbindung oder Erzeugung von Custom Elements, wodurch sich Web Components auch in bestehende Anwendungen integrieren lassen.^[24][22]

Bekannte Bibliotheken zur Entwicklung von Web Components sind beispielsweise Lit und Stencil.^[22][25]

Die Web-Standards stellen ausschließlich ein Komponentenmodell bereit. Funktionen wie Datenbindung, Routing oder Zustandsverwaltung sind nicht Bestandteil der Spezifikationen und werden bei Bedarf durch Bibliotheken oder Webframeworks ergänzt. Die geringere Abstraktionsebene kann dazu führen, dass Webentwickler mehr Infrastruktur selbst auswählen oder implementieren müssen als bei vollständigen Frontendframeworks. Da der Name eines Custom Element innerhalb eines HTML-Dokuments nur einmal registriert werden kann, können unterschiedliche Versionen derselben Komponente nicht gleichzeitig verwendet werden.^[24][26]

Die Kapselung durch Shadow DOM kann bestimmte Mechanismen der Barrierefreiheit erschweren. Entwickler müssen insbesondere bei autonomen Custom Elements die Semantik und Zugänglichkeit explizit berücksichtigen.^[27]

• Awesome Web Components auf GitHub (englisch) – kuratierte Liste rund um Web Components