Wir bei innFactory setzen seit jeher auf React und React-Native als Technologie für unsere Frontends. Die Stabilität und das langanhaltende Wachstum der Community ist einzigartig in der Javascript Welt. Doch wäre es nicht schön, wenn man sich gar nicht so festlegen müsste? Wenn man gar keine Diskussion, ob Angular oder React, bräuchte? Wenn man neue Stars wie Vue.js einfach adaptieren könnte? Kurzum, wenn man sich nicht mehr für ein Framework entscheiden müsste und bestehende Komponenten einfach in jedem verwenden könnte? Das was sich ein bisschen wie ein Traum vor dem Aufwachen an einem Sonntag anhört, könnte bald Wirklichkeit werden, denn Web Components haben das Potential die aufgezählten Fragen überflüssig zu machen. Im folgenden Artikel gehen wir allgemein auf Web Components ein und klären, ob sie ein tatsächlicher Mehrwert sind.
Was sind Web Components?
Der W3C-Standard “Web Components” ist nun endlich in den meisten Browsern angekommen und erfährt gerade einen rasanten Zuwachs an Unterstützer. Kurz und knackig gesagt sind Web Components eigene HTML-Tags, die in reinem Javascript implementiert werden können und ganz dem Prinzip der komponentenbasierten Entwicklung folgen. Neben den HTML-Tags bringt die Web Components Spezifikation auch noch 3 weitere Standards mit:
- Shadow DOM: Kapselt das CSS für den selbst erstellten HTML-Tag ohne andere HTML Elemente zu beeinflussen
- HTML Imports: Importiert den erstellten HTML-Tag oder andere HTML Files
- HTML Templates: Werden erst vom Browser geladen, wenn das Template aktiviert wird (bessere Alternative zu ‘display: none’)
Neue Frameworks im Framework Dschungel?
Prinzipiell lassen sich Web Components in reinem Javascript implementieren. Allerdings bringt das ziemlich viel Overhead mit sich, wie die Codebeispiele im Bild zeigen. Darum gibt es einige Frameworks, wie z.B. Polymer, StencilJS oder Skate.js, die die Erstellung von Web Components erleichtern. Jetzt fragt man sich natürlich, wenn man zum Erstellen von Web Components wieder ein Framework braucht, wie um alles in der Welt soll damit der Javascript Framework Dschungel das Ende finden? Das liegt daran, das sie nah an dem W3C Standard liegen und die Komponenten können zusätzlich in beliebigen anderen Frameworks eingesetzt werden. Somit verlieren klassische Frameworks die schmerzhafte Abhängigkeit, die man sich einholt, sobald man eine produktive Anwendung damit baut. Setzen sich Web Components durch, wird es aus unternehmerischer Sicht kaum mehr relevant sein, welches Framework man einsetzt. Sobald man Komponenten in einem geschrieben hat, kann man leicht auf ein anderes migrieren und den SourceCode mitnehmen als ob es Lego Bausteine von einem anderem Legoset wären.
Vergleich von “Web Components in reinem Javascript” mit Implementierungen in den erwähnten Frameworks: https://github.com/shprink/web-components-todo
Welche Browser unterstützen Web Components?
Die offizielle Unterstützung von den Browsern ist im letzten Jahr deutlich besser geworden. Dies ist aber auch nur relevant, wenn man Web Components in plain Javascript entwickelt. Sobald man Polymer, StencilJS oder Skate.js verwendet, werden ältere Browser über sog. Polyfills versorgt. D. h. die endgültige Unterstützung der Browserherstellern bringt lediglich einen leichten Geschwindigkeitsvorteil. Alle Funktionalitäten von Web Components können somit aktuell verwendet werden.
Browser Unterstützung des Web Components Standards 03/2018
Die Besonderheit von StencilJS
Im Gegensatz zu Polymer ist Stencil ganz gewiss kein weiteres Framework. Stencil wurde von den erfahrenen Ionic-Team ins Leben gerufen und ist ein Compiler der nach Web Components mit reinem Javascipt, HTML und CSS kompiliert. Eine in StencilJS programmierte Komponente hat somit bei Auslieferung keine Abhängigkeit. Trotzdem bring Stencil Polyfills für ältere Browser mit und bietet neben reinem Javascript einige Erleichterungen besonders im Life Cycle Management der Komponenten. Auch einen großen Kritikpunkt von Web Components kann StencilJS aushebeln: StencilJS ermöglicht severseitiges Rendering. Die Implementierung einer Komponente ist recht einfach und ähnelt der von React. Als Beispiel hier einen Timer, der startet sobald er im Browser geladen ist:
import { Component, State } from '@stencil/core';
@Component({
tag: 'custom-timer'
})
export class CustomTimer {
timer: number;
@State() time: number = Date.now();
componentDidLoad() {
this.timer = window.setInterval(() => {
this.time = Date.now();
}, 1000);
}
componentDidUnload() {
clearInterval(this.timer);
}
render() {
let time = new Date(this.time).toLocaleTimeString();
return (
<span>{ time }</span>
);
}
}
Fazit
Der Standard Web Components wirkt äußerst vielversprechend. Das Potential den Framework Dschungel einzudämmen haben Web Components durchaus. Das komplette Ende des Dschungels werden sie aber nur herbeiführen, wenn die W3C den Standard noch verbessert, um nicht mehr auf overhead-mindernde Techniken wie Polymer oder StencilJS angewiesen zu sein. Erst dann könnten nicht nur die großen Frameworks wie React oder Angular fallen, sondern generell gar keine mehr vonnöten sein.
Eins haben aber Web Components gewiss und das ist eventuell der Schlüssel zu einer Microservice Architektur im Frontend. Denn Web Components lassen sich unabhängig von einem Framework und vom Technologiestack der Microservice-Teams einsetzen. Dazu ein Artikel, der einen tieferen Einblick in eine Microservice Architektur in der UI gibt.
