Zukunft der Webentwicklung: Webkomponenten und Progressive Web Apps, Teil 1
Bei Webanwendungen ist ein Umbruch im Gange. Wer sich künftig den Quelltext einer Webseite ansieht, könnte von einem einzelnen my-app-Element im Body der Seite überrascht werden. Keine Spur des üblichen Sammelsuriums hunderter Divs und anderer Elemente.
- Stefan Neumann
Die Nutzung von Komponenten bei der Softwareentwicklung ist keine neue Idee. Zum 25-jährigen Jubiläum von Visual Basic sei an die ActiveX-Steuerelemente erinnert, die in ähnlicher Form auch unter .NET zahllosen Entwicklern das Leben erleichtert haben. Vom jQuery-Plug-in bis zu angesagten Frameworks wie Angular und React – alle bauen auf ihre Weise auf Komponenten, oft als Widgets bezeichnet. Warum also das wachsende Interesse gerade an Webkomponenten?
Die Antwort liegt im vorletzten Satz bei den Wörtern "auf ihre Weise". Alle "Controls" einer Plattform für die Desktop-Entwicklung (wie .NET) haben gemeinsam, dass sie auf eine bestimmte Art eingebunden werden und auf eine bestimmte Art mit der Plattform interagieren. Das macht deren Nutzung trotz aller spezifischer Unterschiede konsistent und damit einfach. Auch wird kein Steuerelement je ein anderes beeinflussen, es sei denn, es reißt gleich das ganze Programm in den Abgrund.
Beim Web als Plattform sieht die Sache anders aus. Bei größeren Projekten hat man die Qual der Wahl. Welches Framework, welche Library deckt die Anforderungen am besten ab? Nicht selten stellt man fest, dass eine Kombination aus mehreren Angeboten ideal wäre, aber das erhöht nicht nur unverhältnismäßig die Ladezeiten, da jedes Framework seinen eigenen Unterbau mitbringt. Auch die Chancen auf Unverträglichkeiten sind nicht gering, vor allem bei CSS. JavaScript lässt zudem viele Freiheiten, sodass die Nutzung jeder neuen Bibliothek und jedes neuen Plug-ins mit der Recherche beginnt, wie deren Einbindung umgesetzt wurde. Zum Teil wird vorhandenes HTML aufgegriffen, andere Produkte erzeugen es komplett selbst.
Die konsequente Verwendung von Webkomponenten könnte dem ein Ende setzen, denn es geht hier nicht nur um die Programmierung eigener HTML-Elemente, sondern auch um einen Paradigmenwechsel, der das DOM als Framework nutzt. So sind nicht wenige davon überrascht, dass Webkomponenten auch für Einsatzzwecke erstellt werden, die auf der Webseite nicht sichtbar sind. Die Webanwendung entsteht letztlich durch die verschachtelte Kombination der Komponenten. Treibt man das auf die Spitze, bleibt am Ende nur eine Webkomponente übrig, die die ganze Anwendung bildet. Bezogen auf Entwurfsmuster kommt hier das "Mediator Pattern" (Vermittler) zum Einsatz. Eine Webkomponente weiß von der Seite wenig, auf der sie sitzt; sie wird eingebunden und angeleitet von der über ihr sitzenden Komponente. Kommuniziert wird über die Werte von Attributen (auf deren Änderung die Komponente reagiert), letztlich über DOM-Ereignisse.
Glücklicherweise Standards
Webkomponenten haben zudem den Vorteil, dass sie auf W3C-Standards fußen, genauer den Spezifikationen für "Custom Elements", "HTML Import" und "Shadow DOM". Wichtige Browser-Hersteller haben sich zu diesen Standards bekannt, sie schon umgesetzt oder sind gerade dabei. Die Vergangenheit hat gezeigt, dass es individuelle Anwendungen auf die Dauer schwer haben, gegen Standards zu bestehen.
"Custom Elements" ermöglichen das eigentliche Erstellen der Komponente (zusammen mit den HTML5-Templates), "HTML Import" erlaubt es, diese auf die Seite zu laden, und der "Shadow DOM" sorgt schließlich dafür, dass die Komponenten sich nicht gegenseitig in die Quere kommen.
Nicht allgemein zugängliche Bereiche des DOM gibt es schon länger. Die Bedienelemente eines <video>-Elements sind in der Regel selbst wieder nur HTML-Elemente, sie tauchen im DOM allerdings nicht auf. Dieser Bereich liegt unter dem eigentlichen DOM, und zwar "in seinem Schatten". Browser-Entwickler haben lediglich Eigenschaften und Methoden für den <video>-Tag vorgesehen, die eine Interaktion über JavaScript ermöglichen. Die Shadow-DOM-Spezifikation erlaubt es Entwicklern, Ähnliches umzusetzen. Eine Webkomponente verhält sich, als säße sie in einem <iframe>, Entwickler können aber genau definieren, wo sie "durchlässig" ist, auch beim Styling. Zur Abgrenzung vom Shadow DOM wird der eigentliche DOM auch als "Light DOM" bezeichnet.
Webkomponenten sind im Browser zu registrieren. Mit jeder neuen Komponente entsteht neuer, sich wiederholender Code, der so ähnlich auch bei Desktop-Controls existiert. Dank einer IDE wie Visual Studio müssen sich Entwickler aber selten damit auseinandersetzen. Spätestens bei der zweiten oder dritten Komponente werden auch Webentwickler darüber nachdenken, wie sie diesen Prozess vereinfachen können, oder sie greifen auf vorhandene Bibliotheken wie Googles Polymer zurück.
