Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Das Web der Zukunft

Web Components

Das Web der Zukunft

Bisher sind Webentwickler an die vorgegebenen HTML-Tags und Attribute gebunden. Mit Web Components ändert sich das: Webworker können damit eigene Tags entwickeln, mit komplexen Funktionen versehen und in sicher gekapselte Komponenten verpacken. Für Frontend-Entwickler entsteht so ein nützliches HTML-Plugin-System.

Das Ziel von HTML5 ist die Verwandlung des Browsers in eine universelle Applikationsplattform. Für einen Softwareentwickler sollen Webtechnologien eine mit anderen Technologie-Ökosystemen gleichwertige Wahl für das nächste Programmierprojekt sein. Um das zu erreichen wurden zahllose neue APIs erfunden, damit Webseiten wie normale Programme ohne Internetzugang benutzt werden können und eine mobile Webapp wie jede andere App den GPS-Chip des Telefons nutzen kann. Doch machen ein paar neue APIs allein den Browser zu einer Plattform? Eher nicht! Noch gibt es gibt ein großes Feature-Loch mitten in der Web-Plattform, das in naher Zukunft durch eine neue Technologie-Kombination names Web Components geschlossen wird.

Ist die Web-Plattform eine Plattform?

Eine »Plattform« im Reich der Computerei ist (ganz einfach ausgedrückt) eine Basis, die Details abstrahiert und auf der andere Dinge aufbauen können. Die JavaScript-Engine eines beliebigen Webbrowsers lässt sich als eine solche Plattform betrachten. Sie stellt dem Webentwickler eine bequem zu benutzende höhere Programmiersprache zur Verfügung, die ihm u.A. durch automatische Speicherverwaltung lästige Details abnimmt. Umgekehrt können Entwicker auf JavaScript aufbauen, indem sie entweder einfach ein JavaScript-Programm schreiben oder sich mit einem App-Framework wie etwa Ember oder AngularJS eine weitere Plattform zwischen JavaScript selbst und das eigene Projekt schieben. Auch für CSS gibt es komplexe Frameworks, die man mit ein wenig gutem Willen als auf CSS aufsetzende »Plattform« durchgehen lassen kann.

Die einzige Technologie im Browser, die auch mit aller HTML5-Magie unter keinen Umständen als »Plattform« durchgeht, ist die wichtigste von allen: HTML. Alle HTML-Tags sind fest in die Browser-Engine einprogrammiert, eigene Tags können Webworker nicht erfinden. Die Logik hinter HTML-Tags (z.B. bei <video>) ist zu 100% vor dem Webentwickler versteckt – ein Eingreifen oder Anpassen ist jenseits der sehr eingeschränkten offiziellen APIs unmöglich. Dabei wäre es doch gerade bei Video-Playern sehr naheliegend, wenn die vielen verfügbaren Video-Player-Tools auch ihre eigenen Tags hätten. Im Sourcecode wäre <flow-player> sehr viel angenehmer zu lesen als der wilde JavaScript- und <div>-Wust, den Webworker heutzutage aus Mangel an Alternativen einsetzen.

Web Components sind ein Technologiemix, der die letzte der drei Web-Technologien zur Plattform macht. Mit Web Components könnt ihr eigene HTML-Tags erfinden (z.B. <google-map>) und vorhandene Elemente um eigene Funktionen erweitern (z.B. <textarea is="mark-down">). Diese Eigenkreationen sind leicht zu benutzen, denn HTML kann fast jeder. Und ein simples Modulsystem für Web Components gibt es auch. Mit den passenden Polyfills könnt ihr Web Components schon heute nutzen und es gibt bereits Webseiten im Netz, die fertige DIY-Elemente sammeln – so muss sich nicht jeder seine eigene <google-map> bauen, sondern kann die offizielle Komponente von Google nutzen.

Web Components für selbstgebaute HTML-Tags

Wie HTML5 sind auch Web Components nicht ein großer Webstandard, sondern ein Mix verschiedener Neuerungen im Browser. Zusammen ergibt sich aus ihnen die Möglichkeit, neue HTML-Tags zu erfinden, wobei die einzelnen Neuheiten natürlich auch für andere Dinge genutzt werden können. Für sich genommen sind die verschiedenen für Web Components verwendeten APIs nicht gerade angenehm zu benutzen, weswegen ihr besser auf unterstützenden Libraries aufbaut. Das ist nicht anders als bei normaler DOM-Manipulation, wo ihr mit jQuery auch besser beraten seid, als mit den normalen Browser-APIs. Der Vollständigkeit halber sollen an dieser Stelle aber kurz die wichtigsten Bestandteile von Web Components Erwähnung finden.

Findet ein Browser ein ihm eigentlich unbekanntes Element im Markup vor (z.B. <google-map>), so behandelt er es wie ein <span>-Element und ignoriert es ansonsten einfach. Eine neue JavaScript-API für Custom Elements erlaubt es, solche Elemente nachträglich einem Upgrade zu unterziehen und selbstdefinierte Logik an das Element anzubringen. So wird aus dem unbekannten Element eine Komponente mit durch den Webentwickler definiertem Eigenleben.

Das Markup in einem HTML-Template (<template>-Element) wird vom Browser verarbeitet, aber nicht angezeigt – nur über eine JavaScript-API lässt sich Inhalt (ein gebrauchsfertiges DocumentFragment) auslesen und klonen, eventuell vorhandene Platzhalter ersetzen und das Endergebnis dann irgendwo einfügen und anzeigen. So gibt es einen bequemen Weg, unsichtbar Markup für die Verwendung in Scripts überall in einer Webseite (oder einer Komponente) unterzubringen.

Das Shadow DOM eines Elements ist eine Art Sub-DOM-Baum in einem Element, der nicht für normale Scripts und andere Einflüsse zugänglich ist. Mit Shadow-DOM könnt ihr eine scriptgesteuerte Div-Suppe elegant hinter einem anderen Element verbergen, indem ihr die Suppe als Shadow-Baum in das Element einhängt. Ein Beispiel für dieses Vorgehen sind die Bausteine des <progress>-Elements. In den meisten Browsern ist der Fortschrittsbalken über normales HTML (<div>-Elemente mit Klassen) umgesetzt, aber da es sich eben um Shadow DOM handelt, seht ihr von diesem Unterbau nichts, wenn ihr das Element inspiziert. Für Web Components, die meist ein komplexes Innenleben in selbstgebauten HTML-Elementen umsetzen wollen, ist Shadow DOM eine ganz zentrale Technologie.

HTML Imports erlauben das Laden von HTML-Dokumenten in andere HTML-Dokumente:

  1. <link rel="import" href="plugin.html">

Der Browser lädt das so verlinkte Dokument herunter, lädt alle dort referenzierten Ressourcen (Bilder, CSS, JS etc.) und verarbeitet das HTML. Das Resultat wird aber nicht einfach an Ort und Stelle in der Seite angezeigt, sondern über eine DOM-API bereitgestellt. Dort erhaltet ihr ein JavaScript-Objekt, das die geladene Datei wiederspiegelt, und könnt euch nach Herzenslust daran bedienen: enthaltene Templates klonen, eingebundene Scripts ausführen – was auch immer gerade anliegt. Im Web-Component-Kontext kann ein solcher Import alle Daten für ein Element enthalten: die nötigen Templates, das Script zum Anmelden eines neuen Tags und was sonst noch so gebraucht wird. Für alle, die neue Elemente nur benutzen und nicht unbedingt selbst schreiben wollen, reduziert sich also der gesamte Arbeitsaufwand auf das Einbinden eines einzigen <link>-Elements (und natürlich das Einbinden des importierten Custom Elements selbst).

Diese und diverse weitere Webstandards ergeben zusammen das Technologie-Universum der Web Components. Die meisten dieser neuen APIs sind ausgesprochen komplex, mühsam zu benutzen und vor allem sind sie schwer zu orchestrieren. Nicht vergessen: Web Components ergeben sich aus einem Technologie-Mix – es gibt keine wirklich fein abgestimmte API, mit der ihr mal eben ein neues Element erfindet. Es braucht also eine Art jQuery für Web Components und Polymer ist genau das.

Ein selbstgebautes Wetter-Widget mit Polymer

Um in aller Kürze die Fähigkeiten von Web Components zu demonstrieren, werden wir ein kleines Wetter-Widget entwickeln, das wie folgt eingebunden wird:

  1. <link rel="import" href="x-weather.html">
  2. <x-weather city="Berlin"><x-weather>

Das Widget zeigt das aktuelle Wetter für die Stadt an, die im city-Attribut angegeben ist:

Das Wetter-Widget auf einer Demoseite in Aktion

Das Widget ließe sich mit reinen Browser-Bordmitteln (d.h. den reinen Web-Component-APIs) umsetzen, aber das wäre mühsamer als nötig. Um das Ganze etwas kürzer und bequemer zu gestalten, werden wir auf das Web-Component-Tool Polymer zurückgreifen. Polymer wird oft als reiner Polyfill für Web Components verkauft, ist aber mehr als das. Es lässt sich grob in drei Teile gliedern:

  1. Eine Sammlung von Polyfills (platform.js) bringt Browsern die für Web Components nötigen Features (HTML Imports, Shadow DOM etc.) bei.
  2. Die Polymer-Library (polymer.html) stellt eine komfortable API für den Bau von eigenen HTML-Elementen bereit.
  3. Eine Sammlung von fertigen Polymer-Elementen sorgt dafür, dass ihr nicht jede Kleinigkeit selbst schreiben müsst.

Die Polyfills sind also ein Teil des Gesamtprojekts, aber im Prinzip unabhängig vom Rest. Das Polymer-Gesamtpaket (Polyfills und Library, ohne Fertig-Elemente) beschafft ihr euch am einfachsten über den Frontend-Paketmanager Bower:

  1. $ bower install Polymer/polymer

Um Library und Polyfill zu nutzen sind nur zwei Dateien von Bedeutung: platform.js für die Polyfills und polymer.html für die Library. Letztere Datei ist für den Einsatz in selbstgebauten Elementen gedacht, erstere gehört in den <head> der Index-Seite:

  1. <!doctype html>
  2. <meta charset="utf-8">
  3. <title>Wetter-Widget-Demoseite</title>
  4. <script src="bower_components/platform/platform.js"></script>

Der Einbau von platform.js muss möglichst weit oben in der Seite geschehen, da nur dann die Polyfills rechtzeitig in den Aktion treten können.

Ein Polymer-Element wird in einer eigenen Datei (in unserem Fall x-weather.html) angelegt und besteht zunächst aus folgendem Boilerplate-Code:

  1. <link rel="import" href="bower_components/polymer/polymer.html">
  2. <polymer-element name="x-weather" attributes="city">
  3.   <template></template>
  4.   <script>
  5.     Polymer('x-weather', {});
  6.   </script>
  7. </polymer-element>

Die einzelnen Teile dieses Code-Konvoluts haben folgenden Aufgaben:

  1. Das <link>-Element lädt die Polymer-Library in unsere Datei. Ohne diese Zeile würde der Rest nicht funktionieren.
  2. Das <polymer-element>-Tag enthält die Logik für unser selbstgebautes Element. Im name-Attribut wird das Tag unseres Eigenbau-Elements festgelegt und im attributes-Attribut ist vermerkt, welche Attribute unser Element haben können soll (in unserem Fall: nur city).
  3. Im <template>-Element können wir das Shadow DOM für unser Element festlegen.
  4. Das <script> enthält alle programmierte Logik für unser Element. Die Polymer()-Funktion meldet unser Element beim Browser an und legt den Prototypen für das Element fest (das z.Z. noch leere Objekt im zweiten Parameter).

Hiermit haben wir also dem Browser gesagt, dass wir ein neues Element namens <x-weather> erfunden haben, das ein Attribut namens city hat. Noch macht das neue Element nichts, aber im ersten Schritt könnten wir es einfach den Wert seines city-Attributs anzeigen lassen. Polymer bringt hierfür sein eigenes Data Binding mit, so dass wir bloß {{city}} in das <template> für das Shadow DOM zu schreiben brauchen und schon funktioniert es:

  1. <link rel="import" href="bower_components/polymer/polymer.html">
  2. <polymer-element name="x-weather" attributes="city">
  3.   <template>
  4.     Das Wetter in <strong>{{city}}</strong>
  5.   </template>
  6.   <script>
  7.     Polymer('x-weather', {});
  8.   </script>
  9. </polymer-element>

Wir könnten an dieser Stelle noch einiges an Detailarbeit verrichten (was passiert z.B. wenn das Attribut fehlt, nachträglich entfernt oder hinzugefügt wird?) aber für den Moment belassen wir das Element wie es jetzt ist. Wichtiger ist, dass wir auch tatsächlich das Wetter anzeigen. Als Wetter-Quelle verwenden wir die API von openweathermap.org und erledigen die AJAX-Requests darauf über ein weiteres Polymer-Element.

Das Polymer-Projekt enthält eine ganze Sammlung gebrauchsfertiger Web Components. Eine dieser Fertig-Komponenten ist das <core-ajax>-Element, über das wir unsere API-Calls abwickeln werden. Installieren lässt sich das Element ganz einfach via Bower:

  1. $ bower install Polymer/core-ajax

Polymer-Elemente wie unser <x-weather>-Element können natürlich andere Polymer-Elemente verwenden. Hierzu wird das eine Element einfach via HTML Import in das andere Element geladen und dann das neue Element einfach wie jedes andere Element im Shadow-DOM-Template benutzt:

  1. <link rel="import" href="bower_components/polymer/polymer.html">
  2. <link rel="import" href="bower_components/core-ajax/core-ajax.html">
  3. <polymer-element name="x-weather" attributes="city">
  4.   <template>
  5.     Das Wetter in <strong>{{city}}</strong>:
  6.     {{weather.main.temp}} ° C, {{weather.weather[0].description}}
  7.     <core-ajax
  8.       auto
  9.       url="http://api.openweathermap.org/data/2.5/weather"
  10.       params='{"q":"{{city}}", "mode":"json", "units": "metric", "lang": "de"}'
  11.       handleAs="json"
  12.       response="{{weather}}"></core-ajax>
  13.   </template>
  14.   <script>
  15.     Polymer('x-weather', {});
  16.   </script>
  17. </polymer-element>

Das <core-ajax>-Element hat einen Haufen interessanter Attribute:

  • auto startet automatisch einen Request, wenn das Element lädt oder wenn sich die Werte von url oder params ändern.
  • url ist das Ziel unseres Requests.
  • params enthält die Parameter des Requests in Form von JSON. Wichtig hier: wir können Data Binding in den Attributen verwenden und notieren deshalb für die Ort-Parameter q einfach {{city}}. Polymer kümmert sich darum, dass dort jeweils der Wert eingetragen wird, der auch im city-Attribut des Elements selbst steht.
  • handleAs legt fest, wie wir die Antwort des Requests verarbeitet wissen möchten (als Text, JSON, XML etc.).
  • response legt den Namen der Variable fest, in dem das Ergebnis des Requests gespeichert wird.

Das wichtigste Attribut ist in unserem Fall response, denn dessen Wert (weather) können wir wiederum benutzen, um die Wetterdaten anzuzeigen – ganz einfach mit Data Binding. Wir schreiben in unser Shadow DOM, dass wir gerne {{weather.main.temp}} und {{weather.weather[0].description}} angezeigt hätten und fertig ist das Wetter-Widget! Und dank der in Polymer eingebauten Polyfills funktioniert es sogar in jedem modernen Browser.

In diesem Zustand ist das Element natürlich noch ein reiner Prototyp, Fehlerbehandlung und eine JavaScript-API fehlen noch. Aber ihr erhaltet schon ein ganz guten Eindruck, was Web Components leisten können, wie die Polymer-Library so tickt und welche Auswirkungen der Einsatz von Web Components auf die tägliche Webentwickler-Praxis haben könnte.

Vorteile von Web Components für die Praxis

Die Frage, die sich jeder gestandene Frontendler mittlerweile stellen sollte, ist natürlich: Brauchen wir Web Components überhaupt? Offensichtlich ist, dass sie in der Webentwicklung bisher nicht so richtig gefehlt haben, denn komplexe Webapps gibt es schon länger. Allerdings bieten Web Components durchaus so manchen Vorteil, der das Leben im Frontend in Zukunft sehr viel angenehmer machen kann.

Zunächst führen Web Components erstmals ein richtiges Plugin-System für das Frontend ein. Alle anderen »Plugin«-Systeme, die es bisher gab (z.B. jQuery-Plugins), waren zwischen den Frameworks nicht einheitlich und erforderten am Ende doch immer wieder JavaScript-Kenntnisse. Mit Web Components gibt es den einheitlichen Weg des HTML-Imports und geladene Features werden einfach per HTML-Tag eingebunden.

Tags als Plugin-Schnittstelle zu verwenden führt auch dazu, dass ähnliche Plugins wie von selbst ähnliche APIs erhalten. Aktuell unterscheidet sich beispielsweise die Einbindung einer Google-Map auf lästig-subtile Weise von der Einbindung eines Openstreetmap- oder eines Bing-Karten-Ausschnitts. Für alle drei Karten-Einbindungen müsst ihr nicht nur JavaScript selbst beherrschen, sondern auch die anbieterspezifische JavaScript-Bibliothek auf dem Kasten haben. Als Web Components nähert sich die Umsetzung aller Karten einander an und auch die Benutzung wird einfacher, da es ja nur noch HTML zu schreiben gilt:

  1. <!--
  2.   OSM-Karten-Komponente
  3.   http://component.kitchen/components/static-openstreetmap
  4. -->
  5. <static-openstreetmap
  6.   lat="52.280849"
  7.   long="8.070086"
  8.   zoom="10">
  9. </static-openstreetmap>
  10.  
  11. <!--
  12.   Komponente für Bing Maps
  13.   http://component.kitchen/components/bing-maps-element
  14. -->
  15. <bing-maps
  16.   latitude="52.280849"
  17.   longitude="8.070086"
  18.   zoom="4">
  19. </bing-maps>
  20.  
  21. <!--
  22.   Offizielle Google-Maps-Komponente
  23.   http://googlewebcomponents.github.io/google-map/components/google-map/
  24. -->
  25. <google-map
  26.   latitude="52.280849"
  27.   longitude="8.070086"
  28.   zoom="10">
  29. </google-map>

Die Attribute der Komponenten sind zwar nicht exakt identisch, aber verglichen mit den Unterschieden in den JavaScript-APIs sind die Differenzen doch sehr überschaubar. Und vor allem: es ist reines HTML! Die Verwendung all dieser Plugins könnte also einfacher nicht sein.

Unter der Haube bestehen die Karten-Komponenten natürlich noch immer aus HTML – den Div-Suppen, die im Shadow DOM lauern. Shadow DOM macht aber noch mehr, als die Sub-DOM-Bäume nur zu verstecken. Es legt auch eine Grenze um die Sub-DOM-Bäume, so dass sie von CSS und JavaScript, das von außerhalb der Komponente stammt, nicht mehr versehentlich beeinflusst werden können. Umgekehrt kann eine Komponente nicht versehentlich mit ihren Styles und Scripts auf die die Komponente einbettende Seite einwirken. Die Shadow-Grenze kann bei Bedarf überschritten werden, aber das muss der Frontend-Entwickler explizit tun. Unbeabsichtigte Wechselwirkungen zwischen Komponente und Seite sind ausgeschlossen. Eine Web Component ist ein komplett eigenständiges, gekapseltes Plugin.

Diese Kapselung macht einerseits die Benutzung der Komponenten für Anfänger einfach und ungefährlich, andererseits bietet sich natürlich auch neue Angriffsfläche für das Arsenal der modernen Frontend-Tools. Für eine Komponente, die komplett in sich geschlossen ist, ist es natürlich traumhaft einfach, automatisierte Unit Tests anzulegen. Und nicht nur die Funktionalität lässt sich überprüfen. Wenn Komponenten auch ihre jeweils eigenen Styles mitbringen, lässt sich natürlich auch die Darstellung der Einzel-Plugins automatisch mit Tools wie Wraith bequem prüfen.

Es zeigt sich, dass Web Components zahlreiche kleine Vorteile auf ihrer Seite haben, die vom nur HTML beherrschenden CMS-Redakteur bis hin zu Frontend-Nerd für alle Seiten etwas bieten. An dieser Stelle stellt sich natürlich die Frage, ab wann wir diese Vorteile denn genießen dürfen.

Browserunterstützung und Tools

Da Web Components ein bunter Technologie-Mix und kein Einzel-Webstandard sind, kann die Antwort auf die Frage nach der Browserunterstützung nur »uneinheitlich« lauten. Natürlich gibt es keinen Browser, der alles von Shadow DOM bis zu HTML-Imports komplett perfekt beherrscht. Die eigentliche Frage muss aber wie immer lauten, inwiefern das ein Problem ist.

Wie schon erwähnt sind die APIs der eigentlichen Web-Component-Technologien sehr unhandlich, weswegen zum Komponenten-Bau in aller Regel auf Tools wie Polymer zurückgegriffen wird. Setzt ihr eine solche Library ein, gibt es natürlich die Möglichkeit, an den nötigen Stellen Polyfills einzubauen, was alle Component-Libraries und natürlich auch Polymer machen. Da Web Components noch als Zukunftstechnologie gelten, kümmern sich die Polyfills nur um die aktuellen Versionen der Browser, die allerdings auch allesamt unterstützt werden. Manches komplexere Feature (wie z.B. Shadow DOM) kann mit Browser-Bordmitteln nicht perfekt nachgebildet werden, aber grundsätzlich funktioniert Komponentenbau und -benutzung in allen aktuellen Versionen aller Browser.

Was geschieht in alten Browsern? Alte Browser verstehen die neuen APIs nicht und werden entsprechend kein Komponenten-Upgrade von unbekannten Elementen vornehmen. Das bedeutet, dass die Elemente einfach nur ihren Text-Inhalt anzeigen – und so ist Progressive Enhancement möglich! Github benutzt beispielsweise Web Components zur Anzeige der letzten Änderung an einer Datei in der Repository-Ansicht (also z.B. hier):

  1. <time
  2.   datetime="2014-10-06T11:37:19Z"
  3.   title="6. Okt 2014 13:37 MESZ"
  4.   is="time-ago">
  5. 4 days ago</time>

Das Attribut is="time-ago" ist die Web-Component-Magie an diesem Code-Schnipsel. Denn ihr könnt nicht nur mit Web Components eigene HTML-Tags erfinden, sondern auch vorhandene Elemente erweitern. Github modifiziert mit seiner time-ago-Komponente das time-Element dahingehend, dass sich die angezeigte Zeit im Browser des Nutzers automatisch aktualisiert, wenn Zeit verstreicht. Diese Funktion enfällt naturgemäß in Browsern, die das is-Attribut oder andere Component-APIs nicht beherrschen. Allerdings tut das der Benutzbarkeit des Elements keinerlei Abbruch, denn es steht ja weiterhin eine einigermaßen korrekte Zeitangabe im Element – nur das Auto-Update (eine reine Bonusfunktion) fehlt. Ein perfektes Beispiel für Progressive Enhancement und die punktuelle Einsatztauglichkeit von Web Components in der Browserlandschaft von heute.

Dass Web Components zwar eine Zukunftstechnologie sind, aber nicht so weit weg sind, zeigt sich nicht nur an Github, sondern auch an der bereits sehr aktiven Community der Komponentenbastler. Auf Seiten wie Component Kitchen und CustomElements.IO werden bereits fleißig Komponenten veröffentlicht und auch die vielen fertigen Polymer-Elemente sind nicht zu verachten. Web Components kommen zwar aus der Zukunft, stehen aber offensichtlich bereits mit einem Bein in der Gegenwart.

Fazit und offene Fragen

Viele neue APIs, diverse Libraries, zahlreiche Komponentensammlungen – unter dem Label Web Components entsteht ein neues Technologie-Universum für Frontend-Module. Erstmals gibt es einen verbindlichen Weg, Funktionalität für das Frontend in Plugins zu bündeln und sie als selbsterfundene oder modifizierte HTML-Tags einzusetzen. JavaScript-Nerds können komplexe Funktionalität in sicher gekapselte Komponenten verpacken, und jeder, der auch nur ein bisschen HTML versteht, kann die Komponenten benutzen. Im Prinzip ist also für alle, die hin und wieder Webseiten basteln, etwas dabei.

Da die Technologie allerdings noch sehr neu ist, sind naturgemäß noch nicht alle Fragen beantwortet. Wie zum Beispiel komplett in sich gekapselte Komponenten mit Responsive Webdesign zusammengehen sollen, ist noch nicht abschließend geklärt. Media Queries in Komponenten sind jedenfalls kein taugliches Mittel, denn was interessiert es das in irgendeiner Spalte stehende Plugin, wie breit gerade die Renderingfläche ist? Wie soll der Autor einer Komponente sein Werk responsiv machen, wenn er nicht die Breakpoints der ggf. zahlreichen Nutzer der Komponente kennt? Zu diesem Problem gibt es bestenfalls erste Überlegungen, aber eine wirklich praxistaugliche und einsatzerprobte Lösung kennt noch niemand.

Auch wie ihr Komponenten in den Workflow einer komplexen Frontend-App integriert, ist noch nicht wirklich durchprobiert. Theoretisch sind Web Components ganz normale HTML-Elemente, die für JavaScript wie ganz normale DOM-Knoten aussehen. Eine mit AngularJS o.Ä. geschriebene App könnte demnach ihr eigenes Data Binding problemlos an die Komponenten andocken, so dass die HTML-Plugins ihrerseits eine Komponente des View-Layers darstellen. Aber klappt das wirklich so einfach? Müssen spezielle Herangehensweisen angewandt werden? Was sind die Best Practices für eine komponentengestützte MVC-App? Auf großer Bühne hat das noch niemand ausprobiert.

Ungeachtet der verbleibenden Fragezeichen lässt sich festhalten, dass Web Components die Zukunft der Frontend-Entwicklung entscheidend mit formen werden. Durch Web Components wird die Web-Plattform zu einer echten Plattform. Jeder Webentwickler kann eigene HTML-Elemente erfinden oder vorhandene Elemente erweitern, so wie auch jeder JavaScript-Entwickler seine eigenen Funktionen schreiben kann. Dies ermöglicht einheitliche, benutzerfreundliche und gekapselte Plugins, die jeder benutzen kann und die das Potenzial haben, Frontend-Entwicklung an vielen Stellen etwas angenehmer zu machen. An den Fronten rund um Browserunterstützung und Best Practices für den Einsatz ist zwar noch viel zu lernen und auch die APIs und Libraries wollen erst mal gemeistert werden. Aber das galt ja auch mal für HTML5.

Kommentare

Marc
am 09.12.2014 - 09:38

Danke, Peter. Also DANKE. Web Components sehen auf den ersten Blick auch wieder wie so ein Hammer aus, mit dem alle Probleme zu Nägeln werden. Ich denke, man sollte immer auch beachten, dass (wie bei GitHub) geschehen, meist ein "enhancen" bestehender Elemente ausreicht und man sein Projekt nicht mit einer neuen Component-Suppe überfluten sollte.

Permanenter Link

Andreas
am 09.12.2014 - 15:37

Doch ich möchte Komponenten-Suppe, da die Applikation dann einen (im HTML) semantischen Aufbau bekommt und keine div Wüsten mehr notwendig sind. In unsere Applikation gibt es keine Standard-Tags mehr.

Permanenter Link

Marc
am 09.12.2014 - 23:45

Eure Web-Apps haben keine Standard-Tags mehr? Fehlt da der Ironie-Tag?

Permanenter Link

Andreas
am 13.01.2015 - 09:22

Permanenter Link

Florence Maurice
am 09.12.2014 - 14:55

Ich gebe hin & wieder auch Einstiegskurse und merke dann, wie durch die vielen neuen Möglichkeiten von CSS3& HTML5 die Dinge auch immer komplexer werden.
WebComponents scheinen mir deswegen zukunftsfähig: Zwar ist die Erstellung komplex, aber die Benutzung wunderbar einfach, denn sie ermöglichen genau das, was Leute wollen, beispielsweise einfach mal eine Google Maps einbinden, einen Bootstrap-Button nutzen oder Ähnlich ... ohne sich um mehr kümmern zu müssen. Wie du auch in deinem Artikel sagst: es ist für alle was dabei.

Permanenter Link

Raoul Schaffranek
am 09.12.2014 - 21:18

Hallo Peter,
danke dir für diese tolle Einführung. Gerade bei so großen Themen ist es ermunternd, viele Stimmen dazu zu hören. Bei selfhml haben wir Web Components heute morgen auch zum Thema gemacht. Die Leute fragen sich seither, ob es Zufall sei, dass wir mit unseren Beiträgen zeitlich so nah aneinander liegen. Koninzidenz oder Vorbestimmung – in jedem Fall möchte ich euch WebKrauts einen schönen Gruß von selfhtml und einen persönlichen Gruß von mir hier lassen
– Raoul Schaffranek

Permanenter Link

Gunnar Bittersmann
am 10.12.2014 - 12:56

Die Webkrauts tun dieses Jahr aber auch alles, um mich ruhigzustellen. ;-)

Da muss ich schon auf Nebenschauplätze ausweichen: Bei „42 °C“ kommt ein Leerzeichen zwischen Zahl und Einheit, aber nicht zwischen ° und C. Vielleicht kann das noch berichtigt werden, damit das niemand falsch nachmacht.

Das Leerzeichen zwischen Zahl und Einheit ist am besten ein geschütztes: 42&nbsp;°C, denn Zeilenumbruch zwischen Zahl und Einheit ist doof. Noch besser wäre U+202F NARROW NO-BREAK SPACE, das wird aber möglicherweise nicht von allen Systemen unterstützt. (Und an eine benannte Entity dafür haben die (oder sollte man sagen: der) HTML5-Macher auch nicht gedacht.)

Permanenter Link

Chris
am 16.12.2014 - 08:34

Verstehe ich das richtig, dass in den Web Components Cross-Domain-Calls möglich sind, oder wird das in JSONP gekapselt?

Permanenter Link

Peter Kröner
am 16.12.2014 - 13:50

Für Web Components gilt die ganz normale Same Origin Policy.

Permanenter Link

Chris
am 17.12.2014 - 07:41

Ich habe mir auf deinem Blog dieses Beispiel angeschaut (http://cdn2.peterkroener.de/uploads/2014/wc/index-weather.html) und da ist kein JSONP. Die API Url taucht direkt in XHR Requests auf... Oder hab ich da was übersehen?

Permanenter Link

Hans Chr. Reinl
am 12.01.2015 - 14:51

Wie Peter schon sagt: es gelten die gleichen Regeln, wie bei anderen Ajax-Calls auch. Die Wetter API setzt allerdings [code]Access-Control-Allow-Origin:*[code], weshalb man da auch ohne JSONP arbeiten kann.

Permanenter Link

Chris
am 13.01.2015 - 18:34

Das hab ich dann wohl übersehen ;)

Permanenter Link

Die Kommentare sind geschlossen.