Polymer 2.0: Googles JavaScript-Bibliothek macht den nächsten Schritt

Polymer 2.0 verspricht eine bessere Unterstützung von ECMAScript 6 und die Interoperabilität mit anderen Webbibliotheken und -Frameworks.

In Pocket speichern vorlesen Druckansicht 14 Kommentare lesen
Polymer 2.0: Googles JavaScript-Bibliothek macht den nächsten Schritt
Lesezeit: 3 Min.
Von
  • Alexander Neumann

Die von Google entwickelte JavaScript-Bibliothek Polymer liegt seit dieser Woche in Version 2.0 vor. Die Bibliothek soll Webentwicklern helfen, benutzerdefinierte Elemente zu erstellen, die sich dann in Anwendungen einsetzen lassen. Das neue Release erscheint rund zwei Jahre nach Freigabe der damals als initial produktreifen Version 1.0 und entspricht einer umfangreichen Revision mit Verbesserungen am Dateisystem sowie der Interoperabilität mit anderen Bibliotheken und Frameworks. Außerdem unterstützt Polymer 2.0 Version 6 des ECMAScript-Standards (= ECMAScript 2015), der JavaScript zugrunde liegt.

Das neue Release implementiert die Spezifikationen "HTML Custom Elements v1", um neue HTML-Tags zu erstellen, und Shadow DOM v1 zum Erzeugen eigenständiger Webkomponenten. Polymer 2.0 verwendet nun standardmäßig ECMAScript-6-Klassen und Custom-Elements-Methoden anstelle der eigenen Factory-Methode. Entwickler können daher die Polymer-Features mit Standard-JavaScript vermengen, obwohl die Factory-Methode noch über eine Kompatibilitätsschicht unterstützt wird. Dabei entspricht die neue Version nur einem Viertel der Größe von Polymer 1.0.

Mit Polymer 2.0 ist es nicht mehr nötig, Polymer.dom für die DOM-Manipulation zu verwenden, wodurch es einfacher sei soll, die Polymer-Komponenten mit anderen Webbibliotheken und -Frameworks zu verwenden. Darüber hinaus wurde der Shadow-DOM-Code in ein wiederverwendbares Polyfill umgepackt, statt ihn in Polymer zu integrieren. Polymer 2.0 bietet einen anscheinend verbesserten Polyfill-Loader, der nur die notwendigen Polyfills lädt, was zu einer Reduzierung der Nutzlast führen soll.

Die Überarbeitung des Datensystems hat offenbar zur Folge, dass die Verteilung von Daten über Elemente einfacher zu debuggen sein soll. Ein einfacheres Array-Handling sowie stapelweise Datenänderungen haben wohl ebenfalls Auswirkungen auf die Performance und die Korrektheit der Ausführung.

Für die Migration von Polymer-1.0-Anwendungen gibt es eine Rückwärtskompatibilitäts-Layer, mit dem sich Elemente, die mit der 1.0-API geschrieben wurden, auf die neue API und native Browserfunktionen ausrichten lassen. Ein Hybrid-Pattern ermöglicht es Entwicklern außerdem, Elemente auf eine gemeinsame Untergruppe von Features in Polymer 1.0 und Polymer 2.0 zu portieren. Diese Elemente können in Anwendungen ausgeführt werden, die auf die Version der Bibliothek ausgerichtet sind. Bei der Migration mögen aber einige kleinere Template-Änderungen erforderlich sein.

Siehe dazu auf heise Developer:

(ane)