Polymer 1.0: Das Experiment ist vorüber

Als Experiment für eine standardisierte Komponentenbildung bei Webapplikationen gestartet, wurde Polymer nun mit Version 1.0 auf eine stabile und für Produktiv-Apps einsatzbereite Basis gestellt. Dieser Artikel möchte diskutieren, welche Erfahrungen und Motivationen hinter der aktuellen Vorgehensweise stecken, welche Neuerungen es gibt und wie Webkomponenten nach Polymer 1.0 migriert werden können.

Eines sollte gleich vorweg gesagt werden: In der Entwicklung von Polymer 0.8, die als Alpha-Version von 1.0 angesehen werden kann, blieb kaum ein Stein auf dem anderen. Matt McNulty, einer der Köpfe hinter dem Thema Webkomponenten bei Google, bezeichnete die Entwicklung von Polymer und der Webkomponenten vor Version 0.8 als ein gemeinsames großes Communityexperiment unter der Leitfrage, wie komplexe Webapplikationen zukünftig strukturiert werden. Sind Webkomponenten ein vielversprechender Ansatz, um die Entwickler von Webapplikationen produktiver werden zu lassen? Mit kurzen Feedback- und Iterationszyklen wurde in einer sehr interaktiven Art und Weise getestet, ob sich die Kombination aus vorgeschlagenen Webstandards (nativ und als Polyfill), Polymer-Bibliothek und bestehenden Komponenten für die alltägliche Entwicklung von Webapplikationen eignet. Diese Phase wurde mit Polymer 0.5 erfolgreich abgeschlossen.

Aber es blieb eine Reihe von Fragen offen. Werden die anderen Browserhersteller neben Chrome die vorgeschlagenen Standards nativ implementieren? Und wenn ja, wann? Gesetzt den Fall, dass ein Webbrowser Webkomponenten nicht nativ unterstützt, welche Performance ist dann mit Polyfills möglich und welche Einschränkungen müssen dafür gegebenenfalls in Kauf genommen werden? Ab wann und wie kann ich eine komplexe Webapplikation mit zahlreichen Webkomponenten über alle wichtigen Webbrowser, sowohl Desktop als auch mobil, produktiv und ohne Bedenken einsetzen?

Das noch junge Webkomponentenökosystem stand vor der Frage, wie es angesichts dieser unklaren und nicht komplett beeinflussbaren Rahmenbedingungen den Weg in die Produktion finden sollte. Das Polymer-Team entschied sich, nicht auf die native Implementierung der Webkomponentenspezifikationen durch die Browserhersteller zu warten. Stattdessen wurde untersucht, ob es möglich wäre, mit einer gründlichen Komplettüberarbeitung des gesamten Stacks und gepaart mit permanenten und sorgfältigen Performancemessungen den Geschwindigkeitsverlust gegenüber einer nativen Implementierung auf allen unterstützten Browsern auf 10 bis 20 Prozent zu begrenzen. Nach den ersten vielversprechenden Ergebnissen zur Zeit des Chrome Developer Summits im letzten Jahr bildete dieser Ansatz die Grundlage für die Polymer-Version 0.8. Dabei handelt es sich um einen robusten, skalierbaren und für den Produktionseinsatz optimierten Webkomponentenunterbau auf allen unterstützten Browsern – schlank, aber dennoch funktional nahe an den Möglichkeiten von Version 0.5. Die Geschwindigkeitseinbußen sind gegenüber einer nativen Browserunterstützung überschaubar. In der Weiterentwicklung von 0.8 bis Version 1.0 änderte sich die Implementierung nur noch minimal.

Zum aktuellen Zeitpunkt befindet sich 1.1.5 in einer stabilen Version und wird kontinuierlich weiterentwickelt. Die Ergebnisse (Abb. 1) in Bezug auf die Start-up-Performance zeigen die Fortschritte zwischen 0.5 und 1.1. Die Core- Elemente wurden in Iron-Elemente umbenannt (core-list wird zu iron-list) und von Polymer selbst entkoppelt. Die von Google unterstützten und mitentwickelten Elemente sind auf der Elements-Website aufgelistet, Iron- und Paper-Elemente bilden dabei die wichtigsten Kollektionen.

Aufgrund des großen Funktionsumfangs wird in diesem Artikel nur auf die für die Beispielkomponente unseres ersten Artikels „Von Kompositionen und Arrangements“ in dieser Ausgabe auf Seite XX relevanten Features näher eingegangen und einige wichtige Funktionen beispielhaft vorgestellt.

Grundlegende Änderungen

Wesentlich verändert hat sich Polymer in seinem Aufbau. So gibt es nun unterschiedliche Varianten: Micro, Mini und Polymer (bzw. Standard). Micro enthält den geringsten, Standard den größten Funktionsumfang. So ist es für eigene Komponenten möglich, aus einer der drei Varianten auszuwählen. Die einzelnen Varianten bauen als Schichten aufeinander auf. Abbildung 2 zeigt dies schematisch. Dadurch ist es einfach möglich, auch leichtgewichtige Komponenten zu erstellen.

Weitere Neuerungen sind der schnellere Start und die Performance zur Laufzeit, ein verbessertes Data Binding und Shady DOM. Shady DOM ist eine Alternative zum schwergewichtigen Shadow DOM, bei dem der lokale DOM des Templates einer Komponente nicht in einen Shadow Tree eingefügt, sondern durch Polymer verwaltet wird. Die Laufzeit soll sich dadurch vor allem in Browsern ohne native Unterstützung für Shadow DOM drastisch verbessern, da hier nicht auf Polyfills zurückgegriffen werden muss. Hinzu kommt, dass leichtgewichtige Komponenten nicht notwendigerweise Shadow DOM verwenden sollten.

Migration von 0.5 auf 1.0

Um die Komponente nach Version 1.0 zu migrieren, werden im Folgenden einzelne wichtige Änderungen vorgestellt. Aufgrund der Fülle an Änderungen kann leider nur auf eine Auswahl eingegangen werden. Zunächst müssen alle Abhängigkeiten in der bower.json auf Version 1.0 angepasst und durch ein

die 1.0er Abhängigkeiten aufgelöst werden. Anschließend können spezifische Änderungen für Polymer nachgezogen werden.

Am leichtesten anpassen sich die Elementregistrierung. Bisher wird ein Element wie in Listing 1 registriert und konfiguriert.

In Polymer 0.8 wird dies nun durch den Code wie in Listing 2 realisiert.

Neu ist die Trennung des Skriptteils vom deklarativen Markup in Listing 2. Zu beachten ist, dass die id des <dom-module> dem Attribut is im Skriptteil entspricht und dass <dom-module> vor dem <script> deklariert wird, damit Polymer auf die entsprechende id zugreifen kann.

Das Einbinden von Mixins erfolgt nun durch die Angabe des Behavior-Objekts im Attribut behaviors des Polymer-Objekts. Auch die Definition der öffentlichen Attribute hat sich geändert; so werden diese nicht mehr im publish-, sondern im properties-Objekt mit der Angabe eines Konfigurationsobjekts definiert. Dieses legt den Datentyp und einen Default-Wert fest. Zusätzlich können ein reflectToAttribute-, ein readOnly-, ein notify-, ein computed- und ein observer-Attribut definiert werden. Damit werden alle Funktionen, die im Zusammenhang mit einem Property der Polymer-Komponente stehen, kompakt und übersichtlicher zusammengefasst, als das in 0.5 der Fall war.

Für die Beispielkomponente ändert sich die Definition dabei wie in Listing 3 (vorher) und Listing 4 (nachher) gezeigt.

Die Angabe der Datentypen ist explizit gefordert und wird für die Deserialisierung eines Attributs verwendet. Auch die Observer werden nun direkt im Attribut konfiguriert und nicht mehr wie in 0.5 über das observe-Objekt, welches aber auch weiterhin in 1.0 enthalten ist.

Praktisch in Polymer 0.5 sind die deklarativen Event Handler, die auch in 1.0 verfügbar bleiben. Allerdings fallen die geschweiften Klammern weg. Der Code verändert sich wie folgt:

Im Wesentlichen sind die gezeigten Veränderungen problemlos umsetzbar. Interessanter wird der Einsatz von Shady DOM, der per Default als Alternative zum schwergewichtigen Shadow DOM in allen Browsern aktiv ist – auch in Chrome.

Optional kann Shadow DOM aktiviert werden, der dann in Browsern ohne native Unterstützung einen Polyfill erfordert oder nativ unterstützt wird. Polymer verwendet in diesem Fall den nativen Shadow DOM, wenn er auf der entsprechenden Plattform vorhanden ist. Der Entwickler muss sicherstellen, dass bei Browsern ohne native Unterstützung das Polyfill für Shadow DOM vorhanden ist.

Polymer 1.0 führt dazu einen Abstraktions-Layer ein, der von den Entwicklern genutzt werden muss, um nicht direkt auf das DOM-API zuzugreifen. Dies würde dazu führen, dass Zugriffe über den querySelector bei Shady DOM nicht greifen.

Weitere Neuerungen

Grundlegend verändert hat sich das Data Binding. So sind keine Polymer Expressions mehr innerhalb von Binding-Ausdrücken erlaubt, die beispielsweise einfache Berechnungen oder String-Konkatenationen ermöglichten. Hierfür sollen als Ersatz Computed Properties eingesetzt werden.

Auch wird ab 0.8 nur noch der gesamte Inhalt von DOM-Knoten ersetzt und nicht mehr einzelne Teile darin, da String-Operationen relativ teuer sind. Die Änderungen werden durch folgendes Beispiel verdeutlicht:

Textinhalte ersetzen so immer den gesamten Inhalt eines Knotens, in diesem Beispiel den Inhalt des <span> -Tags. Anstelle der String-Konkatenationen können Computed Properties eingesetzt werden (Listing 5).

Die Funktion wird dabei sowohl bei der Änderungen des Werts in firstName wie auch in lastName aufgerufen.

Um Werte nicht auf die Properties des JavaScript-Objekts der entsprechenden Komponente zu setzen, sondern auf die Attribute des HTML-Elements, kann $= anstelle von = verwendet werden:

Weitere Neuerungen und Änderungen zum Data Binding sind ausführlich in den Docs zu finden.

Polymer bietet aber neben den funktionalen Aspekten auch einige Layouthelfer, die beispielsweise das CSS-Flexbox-Layout umsetzen. In 0.5 ist es möglich, diese als Attribute des zu definieren. Mit 1.0 werden Flexbox-Definitionen durch die Anwendung von importierten Custom CSS Properties eingebracht:

Cross-Scope Styling

Es ist häufig der Fall, dass sich gewisse Styling-Regeln auf alle in einer Webapp verwendeten Elemente beziehen – man denke zum Beispiel an eine Theme-Farbe wie das Blau von Facebook. In 0.5 standen hierfür die Pseudo-Selektoren ::shadow und /deep/ zur Verfügung. Diese sind im 1.0er Release als deprecated markiert und durch shared-styles ersetzt worden. Durch diese ist es möglich, ein globales dom-module zu definieren, das Styles beinhaltet, die überall import werden und durch das include-Attribute des Style-Tags in die Komponente geladen werden können. Außerdem wird empfohlen, Style-Tags direkt im Template zu deklarieren, da Polymer auf diese Methode optimiert ist.

Roadmap und offene Probleme

Da mit 1.0 eine solide Basis geschaffen ist, sind die Themen, die zum aktuellen Zeitpunkt angegangen werden, eher Evolution als Revolution. Es wird also Feinschliff und Konsolidierung betrieben.

So soll zum Beispiel der leichtgewichtige Shadow DOM-Polyfill Shady DOM modularisiert und auch außerhalb von Polymer verwendbar gemacht werden. Außerdem steht noch nicht fest, wie Shady DOM angepasst werden kann, um eine bessere Interoperabilität mit externen Frameworks zu ermöglichen.

Für das Cross-Scope Styling soll es nach 1.0 ein Build-Tool geben, das das Styling von Komponenten bereits zur Build-Zeit berechnet, um während der Laufzeit keine weiteren Berechnungen durch einen Scope Styling Polyfill durchführen zu müssen. Die genutzte Syntax soll dabei an CSS Custom Properties anlehnen.

Zusätzlich wird es die Möglichkeit geben, dass Komponenten auch von nicht nativen Elementen erben können – dieses Feature wird erst später eingeführt, da die meisten Anwendungsfälle über Behaviors abgebildet werden können.

Das nach Version 0.5 entfernte Feature, dass nur Teile des Inhalts eines DOM-Knotens per Databinding ersetzt werden können, soll später in performanterer Weise wieder eingeführt werden.

Auch die Momentan noch rudimentäre Gestenerkennung soll durch optional hinzuschaltbare Komponenten ausgebaut werden.

Die wichtigste Baustelle in 1.x stellt jedoch das verfügbare Tooling dar, an dem mit Hochdruck in verschiedene Richtungen gearbeitet wird. Zu den sich noch in der Entwicklung befindlichen Tools gehören der erwähnte Style-Preprocessor, ein Polymer-Linter, und Polymer Designer, ein UI-Builder mit GUI.

Fazit

Polymer 0.8 stellt basierend auf den Ideen, Prinzipien und Erfahrungen der Version 0.5 eine komplett neue Implementierung zur Verfügung, die voll und ganz auf Performance und Produktionstauglichkeit ausgelegt ist. Zu diesem Zweck sind viele Funktionen, wie beispielsweise das Data Binding, nochmals grundlegend überarbeitet worden. In der Zeit zwischen 0.8 und 1.0 sind die notwendigen Konsolidierungsarbeiten und Performanceverbesserungen erledigt worden. Ziel war es, einen robusten, soliden, performanten und für die Produktion im Google-Maßstab optimierten Stack für Webkomponenten bereitzustellen, der ein möglichst breites Spektrum an Webbrowsern für Desktops und mobile Endgeräte unterstützt.

Mit Polymer 1.0 ist dieser Schritt zumindest aus Plattformsicht gelungen und der Entwicklung von produktiven Webkomponenten sollte nichts mehr im Weg stehen. Jetzt ist es an den Webentwicklern, dem Projekt mit standardisierten Webkomponenten zum Durchbruch zu verhelfen. Klar ist: Wer einmal mit Webkomponenten entwickelt hat, kann nur schwer wieder loslassen.

We’re hiring!

Tapetenwechsel gefällig? Wir sind auf der Suche nach begeisterten Frontend-Entwicklern, die unsere Projektteams im Umfeld von JavaScript, HTML und CSS unterstützen und auch vor innovativen Themen wie AngularJS und Progressive Web Apps nicht zurückschrecken. Jetzt Bewerben!

Weiterlesen

Mehr Informationen zu unseren Dienstleistungen rund um die Web-Entwicklung gibt es auf unserer Website. Unser Portfolio umfasst außerdem die Anwendungsentwicklung für Android & iOS mit speziellem Fokus auf Enterprise-Apps. Für direkten Kontakt schreibt an info@inovex.de oder ruft an unter +49 721 619 021-0.