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 dem Attribut is im Skriptteil entspricht und dass vor dem