Ein modulares Web: iFrames und Web Components

iFrame – Background und Use Cases

Das iFrame- oder Inline-Frame-Element wird verwendet, um ein anderes HTML-Dokument in den Textkörper der aktuell aufgerufenen Seite einzubetten. Auf diese Weise entsteht ein verschachtelter Browsing-Kontext, in den nützliche Inhalte von Websites oder Diensten von Drittanbietern ohne großen Konfigurationsaufwand direkt eingefügt werden können. Ein zweiter und verwandter Anwendungsfall für iFrames ist die Wiederverwendung von Geschäftslogik, die bereits in einer bestehenden Webanwendung als eingebettete Widgets implementiert ist (man denke an Echtzeit-Chat-Widgets).

Nachteile der iFrame-Technologie

Die Verwendung von iFrames für einen der beschriebenen Anwendungsfälle hat jedoch mehrere Nachteile. Dazu gehören unter anderem:

1. Der verschachtelte Kontext, der in eingebetteten Seiten entsteht, könnte zu einer geringeren SEO-Bewertung der Host-Seite führen, da Suchmaschinen den Inhalt der Quell-URL des iFrames zuordnen.
2. iFrames erzeugen effektiv „Browser-Fenster“ innerhalb der bestehenden Seite, ein potenzieller Albtraum für die Benutzerfreundlichkeit, der zu unbeabsichtigten verschachtelten und vertikalen Bildlaufleisten führt, wenn er nicht sorgfältig konfiguriert wird.
3. Der isolierte Browsing-Kontext eines iFrames bedeutet, dass jeder Link innerhalb eines iFrames den Standort des iFrames auf diesen Link umleitet, während er auf der ursprünglichen Host-URL innerhalb des Webbrowsers bleibt.

Trotz dieser Nachteile können Vorkehrungen getroffen werden, um die Probleme zu minimieren oder gar zu beseitigen.

Das Versprechen von Webkomponenten

Hier kommen die Web Components ins Spiel: eine Reihe von vier Webtechnologien, die Entwickler*innen helfen, individuelle UI-Steuerelemente zu implementieren, die stark gekapselt (konfliktfrei) und wiederverwendbar (modular und zusammensetzbar) sind.

1. Die API für Custom Elements ermöglicht es, benutzerdefinierte HTML-Elemente (benannt und mit benutzerdefinierten Attributen/Ereignissen definiert) wie jedes andere Element zu definieren und zu verwenden.
2. Die Shadow-DOM-API ermöglicht ein gekapseltes DOM-Element, das mit einem Host-DOM-Element verbunden ist. CSS-Stile, die im Shadow-DOM angewendet werden, fließen nicht in das Host-Dokument ein, und umgekehrt.
3. Die HTML-Templates-API bietet <template>- und <slot>-Tags zur einfachen Markierung von UI für die Wiederverwendung, ohne sie zu rendern.
4. Die HTML-Import-API ermöglicht den Import von Webkomponenten aus separaten Ressourcendefinitionen.

Zusammengenommen weist die Technologie der Web Components auf eine Zukunft hin, in der die Entwicklung von Webanwendungen schlanker, weniger repetitiv (mehr DRY — wiederhole dich nicht!) und erweiterbar wird. Wetter-Widgets, die auf mehreren Websites unterschiedlich aussehen müssen, müssen nicht mehr in mehreren Projekten entwickelt werden. Stattdessen kann ein benutzerdefiniertes <Wetter>-Element einmal entwickelt und möglicherweise auf jeder anderen Website importiert, konfiguriert und ausgeführt werden.

Die Zukunft beginnt jetzt

Angesichts des großen Versprechens von Web Components bedeutet die Realität der begrenzten Entwicklerwerkzeuge und der schlechten Browserkompatibilität, dass diese Zukunft nicht bald verwirklicht werden wird. Als Entwickler*innen können wir realistischerweise nur auf neuere, funktionsbereite Browser wie Chrome oder Firefox abzielen und nicht auf immergrüne Browser, die immer noch zu den harten Anforderungen der Kund*innen gehören. Auch die Auswahl an Bibliotheken und Frameworks für die Erstellung von Webkomponenten ist begrenzt:

• Erstellen von „Vanilla“-Web Components unter Verwendung der „(Nicht-)Standard“-Web Components-APIs
• Polymer: von Google entwickelte Bibliothek zur Erstellung und Verteilung von Webkomponenten
• Einbindung anderer Web-App-Bibliotheken durch Registrierung von Vue/React/Angular-Komponenten als Web-Komponenten
  • Vue-web-component-wrapper (Web Component als Build-Ziel in Vue CLI)
  • Web-react-components

Hands-on @ Factorial und Schlussfolgerung

Bei Factorial haben wir unsere Erfahrung mit der Entwicklung von Vue.js kombiniert, um zwei auf Webkomponenten basierende Projekte zu realisieren. Das erste war eine Echtzeit-Chat-Schnittstelle, die in ein hybrides Drupal 7/Socket.IO-Setup integriert wurde. Das zweite Projekt war ein Proof-of-Concept für eine wiederverwendbare UI-Komponentenbibliothek, die auf eine progressive, dezentrale Designüberholung in einer Reihe von bestehenden Webanwendungen abzielte. Die erstklassige Entwicklererfahrung, die das Vue.js Ökosystem bietet, machte die Erstellung von wiederverwendbaren Webkomponenten zu einem Kinderspiel im Vergleich zu „Vanilla“ oder Polymer Ansätzen. Wir hoffen, dass die Unterstützung für die Erstellung von Webkomponenten mit der Zeit und über weitere Frontend-Frameworks hinweg reifen wird.

Zusammenfassend lässt sich sagen, dass die iFrame-Technologie trotz ihrer Unzulänglichkeiten auf absehbare Zeit Bestand haben wird. Für den Hauptanwendungsfall, das Einbetten von Inhalten wie Videos und Karten, sind iFrame-Lösungen schnell, zuverlässig und von den Anbietern gut dokumentiert. Für komplexere Anwendungsfälle, bei denen es darum geht, wiederverwendbare und modulare Schnittstellen zu erstellen, ist die Webkomponententechnologie interessant und vielversprechend. Es bedarf nun einer gemeinsamen Anstrengung von Browseranbietern, UI-Frameworks und uns Webentwickler*innen, um Webkomponenten voranzutreiben.