Single-Page Applications ohne Framework: Web Components als Ersatz für React & Co.?

Wer heute eine größere clientseitige Webanwendung schreibt, greift für gewöhnlich zu den üblichen Verdächtigen: Angular, React, Vue.js, Blazor und Co. Doch die Frontend-Landschaft wird sich durch Web Components verändern.

Single-Page Applications eignen sich hervorragend zur Entwicklung performanter und offlinefähiger Webanwendungen. Es existieren viele Frameworks und Bibliotheken, die die Entwicklung beschleunigen und vereinfachen. Diese Frameworks übernehmen etwa Aufgaben wie Templating, Data Binding, Routing, Dependency Injection und Ähnliches.

Alle großen Frontend-Plattformen haben früher oder später ein Komponentenmodell eingeführt (z.B. COM). Mit den Web Components hat das Web sein natives Komponentenmodell vergleichsweise spät erhalten. Seit Microsoft Edge auf Chromium aufsetzt, ist dieses in den vier großen Webbrowsern Chrome, Edge, Firefox und Safari verfügbar. Technisch basieren Web Components vorwiegend auf den Schnittstellen Custom Elements zur Definition benutzerdefinierter HTML-Elemente und Shadow DOM zum Kapseln der Elementinhalte, um sie äußeren Einflüssen etwa durch CSS zu entziehen. Sie können, wie normale HTML-Elemente auch, benutzerdefinierte Eigenschaften definieren und Ereignisse auslösen. Darüber lässt sich eine Kommunikationsinfrastruktur zwischen einzelnen Komponenten aufbauen, was bis hin zur komplexen SPA skaliert.

class MyElement extends HTMLElement {
  constructor() {
     super();

     const shadow = this.attachShadow({mode: 'open'});
     shadow.innerHTML = 'Test!';
  }
}
customElements.define('my-element', MyElement);

Die Einführung einer Web Component ist denkbar einfach: Es muss lediglich eine neue JavaScript-Klasse definiert werden, die vom HTMLElement erbt (siehe Listing). Kein Modul-Bundler, keine Rendering-Engine, keine Abhängigkeiten, keine Abstraktionsschichten, kein Build-Prozess. Einfache Anwendungen auf Basis von Web Components werden nur wenige Kilobyte groß. Nachteile sind jedoch, dass Web Components von Haus aus weder Data Binding unterstützen noch Templating-Magie wie das aus Angular bekannte *ngFor zum Wiederholen von DOM-Knoten. Auch Routing gestaltet sich mit reinen JavaScript-Bordmitteln als eher kompliziert. Weiterhin können derzeit noch nicht flächendeckend benutzerdefinierte Formularsteuerelemente "erfunden" werden, die Form-Associated Custom Elements sind aber schon unterwegs.

Für viele Features braucht es Bibliotheken

Um diese Nachteile teilweise wieder auszugleichen, bieten sich neue Bibliotheken an: Vaadin Router vereinfacht das Routing deutlich und bietet eine Express-ähnliche Routensyntax, die auch Angular-Entwickler kennen. Die Bibliothek lit-element aus dem Polymer-Umfeld bringt Data Binding und eine Art Templating. Für beides braucht es weiterhin keinen Build-Prozess, durch die Abhängigkeiten wird die Anwendung jedoch schon mehrere hundert Kilobyte groß. Damit ist sie wieder größer als ein Produktiv-Build einer kleinen Angular-App.

Web Components sind außerdem interoperabel: Angular unterstützt etwa das Erzeugen von Web Components aus Angular-Komponenten heraus das Erzeugen von Web Components aus Angular-Komponenten heraus, Web Components wiederum lassen sich in jedem beliebigen Framework verwenden – das öffnet auch die Tür zu Microfrontends.

Mit Web Components lassen sich schon heute vollwertige Anwendungen bauen. Ausgestattet mit den richtigen Bibliotheken können Entwickler damit teilweise auch SPA-Frameworks ersetzen. Allerdings müssen sich Web-Component-Entwickler ihren Toolbelt erst selbst zusammenstellen. Frameworks wie Angular bringen alles Notwendige im Lieferumfang bereits mit. Gerade wer von einer komplett anderen Technologie ins Web wechselt, wird die Vorteile eines Opinionated-Framework wie Angular spüren. Kurzum gesellen sich Web Components als weitere valide Option zu den bekannten SPA-Frameworks.

()