Eine praktische und zukunftsfähige Sache: Web Components

Web Components sind benutzerdefinierte HTML-Elemente. Sie können wie normale Tags verwendet werden – die Entwickler:innen geben ihnen jedoch ein eigenes Verhalten und Aussehen mit. Ein Web Component besteht aus drei Teilen:

1. Custom Element

2. Shadow DOM (versteckter DOM-Baum mit eigener HTML-Struktur und eigenem CSS-Stile)

3. HTML-Template

In einer Live-Coding-Session zeigte Arco den Tech-Teams, wie das Zusammenspiel funktioniert. In seinen Beispielen – einem Button, einer Tageszeit-spezifischen Begrüßung und einer Tab-Navigation – wies er auf die unterschiedliche Komplexität hin. Diese Elemente werden aber alle individuell definiert und bekommen durch Style Encapsulation über einen Shadow DOM ein eigenes Verhalten und/oder Aussehen, unbeeinflusst von anderem CSS auf der Seite. Daher sehen die Elemente gleich aus und bleiben stabil, selbst bei viel oder konfliktreichem CSS. Entwickler bauen sie per Skript ins HTML ein.

Warum punkten Web Components gegenüber Frameworks?

In seinem Vortrag betonte Arco einen sehr großen Vorteil: Durch Einhalten von Webstandards – wie die des W3C – sind Web Components technologisch sehr langlebig. Wer heute Komponenten entwickelt, kann so mit einer Kompatibilität über viele Jahre rechnen. Web Components haben jedoch noch weitere Vorteile gegenüber Frameworks wie React oder Vue.

Die Vorteile im Überblick

1. Keine Runtime, kleinere Bundle-Größe
   Web Components laufen nativ im Browser ohne zusätzliches JS-Overhead

2. Direkte DOM-Interaktion
   Kein Virtual DOM – stattdessen volle Kontrolle über den echten DOM

3. Mehr Freiheit, weniger Vorgaben
   Starre Pattern sind aufgehoben. In der Entwicklung wird die Komplexität und Architektur definiert. (Vorsicht vor falschen Patterns!)

4. HTML-natives Kompositionsmodell
   Server rendert HTML, Client aktiviert punktuell Interaktion via Custom Elements

5. Framework-agnostisch
   Web Components lassen sich nahtlos in React/Vue-Apps einbinden, ohne Konfiguration, ideal für Cross-Framework-Wiederverwendung

Ein zentrales Argument ist also, dass Web Components keine eigene Runtime benötigen. Dies hält Bundles kleiner und reduziert die Einstiegshürde. Statt eine komplette App-Infrastruktur zu bootstrappen, lassen sich einzelne interaktive Bausteine als Custom Elements in bestehende Seiten integrieren. Dies ist ideal, wenn der Großteil serverseitig gerendert wird und nur punktuell Interaktion nötig ist. Hinzu kommt: die Style Encapsulation über den Shadow DOM. Die Komponenten sehen überall gleich aus, unabhängig davon, welches CSS bereits auf der Seite existiert. Das erleichtert die Konsistenz über verschiedene Anwendungen und Teams hinweg.

Praxisbeispiele aus dem denkwerk

Arco und seine Kolleg:innen nutzen Web Components für Kunden-Projekte. So haben sie etwa im interdisziplinären Team mit Experience und Visual Design ein Design System entwickelt. Das Design-System nutzt die Web Components-Library „Shoelace“ als Basis. Damit baute das Tech-Team ein UI-Framework auf und passte es an das neu gestaltete Digital Branding an. Es entstand ein Set von Core Components wie Buttons, Formular-Controls oder Navigationselementen. Diese wurden in „plain HTML“-Projekten ebenso nutzbar gemacht wie in diversen Frameworks (hier: React, Vue oder auch Svelte).

In einem anderen großen Projekt arbeitete das Team mit einem CMS, also mit klassischem serverseitigem Rendering. Um mit einfachen Mitteln die UX zu verbessern, hat das Projektteam auch hier Web Components eingesetzt – etwa in der Tab-Navigation, im Header oder im mobilen Menü – als schlanke Custom Elements, die die Interaktion übernehmen, während der Content weiterhin vollständig serverseitig gerendert wird.

Wo stoßen Web Components an Grenzen? Und wo lohnen sie sich?

Trotz aller Vorteile, resümierte Arco in seinem Vortrag:

„Web Components sind keine Lösung für alles, sondern haben Upsides und Downsides. Es gibt immer eine Reihe verschiedener Lösungen und man muss individuell bewerten, ob sich Web Components für ein Projekt anbieten.“

Arco Mul, Lead Software Developer bei denkwerk

Flexibilität und eine kritische Prüfung ihrer Lösungswege sind also von den Entwicklern gefragt. Auch in der anschließenden Diskussion zum Einsatz von Web Components wurde dies deutlich.

Themen wie

• Serverseitiges Rendering

• Formular-Handling und

• Accessibility

sind bei Web Components deutlich anspruchsvoller als in etablierten UI-Frameworks. Dafür bringen UI-Frameworks abstrahierte Patterns mit. Zwar existieren Workarounds – wie das serverseitige Rendering mit Lit oder Libraries wie Shoelace, welche das Formular-Handling schon richtig machen – aber: Sie erfordern Erfahrung und müssen richtig integriert werden. Auch die Integration in komplexe Framework-Setups kann etwa bei SSR oder hochgradig dynamischen Apps zusätzlichen Aufwand verursachen. Hier sind React, Vue & Co. weiterhin die bessere Wahl. Vor allem dann, wenn eine komplette Single-Page-Application mit umfangreichem State-Management entsteht.

Besonders attraktiv sind Web Components, wenn folgende Bedingungen erfüllt sind:

• wenig, aber gezielte Interaktion auf ansonsten serverseitig gerenderten Seiten

• strenger Performance-Fokus

• Bedarf an cross-framework-fähigen Design Systemen

Für Unternehmen mit mehreren Technologie-Stacks und heterogenen Teams ermöglichen sie ein gemeinsames UI-Fundament, ohne einen Framework-Lock-in zu erzwingen. Gleichzeitig wirken sie wie ein „Reality Check“ in einer überfragmentierten Frontend-Welt: Statt für kleine Features ein ganzes Framework zu laden, lässt sich mit Web Components bewusst minimalistisch arbeiten – dort, wo sie passen und in Kombination mit Frameworks.