Wo stehen wir mit der Umsetzung von Web Components nach Fertigstellung der Version 1.0?
Die Grundidee der Web Components ist es, die Entwicklung von wiederverwendbaren und auf einem offenen Web-Standard basierenden User-Interface-Elementen zu ermöglichen, den sogenannten Custom Elements. Diese Elemente können durch ein HTML-Import-Statement und das Verwenden eines selbstdefinierbaren HTML-Tags eingebunden werden – das alles nativ im Browser, ohne externe Bibliotheken verwenden zu müssen. Web Components werden derzeit durch mehrere Editor’s Drafts des W3C ausschließlich durch Google-Mitarbeiter spezifiziert. Web Components erweitern für den Entwickler die Mächtigkeit von HTML. So bietet zum Beispiel HTML derzeit keine Möglichkeit, Markup-Fragmente als Schablonen zu deklarieren, um sie erst bei der tatsächlichen Verwendung eines Custom Elements sichtbar werden zu lassen. Der Editor’s Draft definiert dazu das HTML-Template, welches die Deklaration solcher HTML-Fragmente ermöglicht.
Ein weiterer wichtiger Vorschlag ist die Einführung des Shadow DOM. Er bezieht sich auf die Fähigkeit des Browsers, Teile des DOMs (Subtree) zwar beim Rendern der Seite mit einzubeziehen, die dabei aber nicht Teil des DOMs des Hauptdokuments sind. Dies ermöglicht eine weitgehende Kapselung der Komponenten.
Um Custom Elements verwenden zu können, muss man ihre Definition importieren können, ähnlich wie dies bei objektorientierten Sprachen notwendig ist. Dazu dienen HTML-Imports, die nichts weiter als Verknüpfungen zu externen HTML-Dokumenten sind. Trifft der Parser auf solche Imports, wird eine Import-Map erstellt und die HTML-Dokumente werden in definierter Reihenfolge geladen. Dabei wird die sogenannte De-Duplication sichergestellt, also bereits geladene Import-Pfade werden ignoriert.
Polymer – von 0.5 zu 1.x
Seit Alex Russel 2011 die Idee der Web Components [1] vorgestellt hat, ist viel geschehen. Aus der damaligen reinen Konzeptarbeit ist inzwischen Realität geworden. Bereits 2013 hat Google das Framework Polymer veröffentlicht und Chrome unterstützt die Web-Component-Spezifikation schon seit 2014 nativ.
Bisher ist Chrome jedoch der einzige Browser, der die Spezifikation vollständig umsetzt, schließlich stammt die Web-Component-Spezifikation in erster Linie von Google selbst und es wurden nur wenige Anstrengungen unternommen, andere Browserhersteller mit einzubeziehen. So konnte man sich bis heute noch nicht auf eine gemeinsame Spezifikation einigen. Im November 2014 veröffentlichte Google mit der Version 0.5 die erste vollständige Polymer-Implementierung. Diese zeigte bereits das Potenzial der Anwendung von Web Components auf, offenbarte aber auch Mängel in der Implementierung. Das ständige Ändern der Spezifikation und zu große Ambitionen in der Bereitstellung neuer Funktionalitäten machten Polymer für umfangreichere Projekte praktisch unbenutzbar.
Dies zeigte sich besonders bei Browsern mit geringer nativer Unterstützung, wie dem Internet Explorer (IE). Die erstellten Anwendungen wurden langsam bis hin zur Unbrauchbarkeit. Tatsächlich sind Unterschiede bei der Geschwindigkeit zwischen IE, Firefox und Chrome auch heute noch deutlich wahrnehmbar.
Polymer 1.0 – Mit welchen Änderungen müssen Entwickler umgehen?
Mit der zur Google I/O im Mai 2015 [2] etwas hastig fertiggestellten Version 1.0 von Polymer will Google das Framework nun auf eine neue Ebene gehoben haben und glaubt produktionsreif zu sein. Was hat sich nun bezogen auf die Version 0.5 geändert? Es wurde erkannt, dass die Komplexität der Shadow-DOM-Implementierung mittels Polyfills ein Hindernis darstellt und so wurde in der Folge aus dem Shadow DOM der sogenannte Shady DOM - eine speziell auf Performance optimierte DOM-Version mit den dazugehörigen Zugriffsmethoden.
Das (One-Way-, Two-Way-) Property-Binding lässt sich nun genauer den Anforderungen der Anwendungslogik anpassen. Das Two-Way-Binding ist technisch aufwendig und auch nicht in jedem Fall notwendig. Wo es möglich ist, sollte man darauf verzichten. Die umfangreiche Expression-Syntax wurde fallen gelassen, wahrscheinlich aus Gründen der Performance oder aufgrund fehlender Zeit bis zur Fertigstellung. Als simpler Ersatz können die Computed Properties dienen, diese sind performanter, aber natürlich nicht ganz so ausdrucksstark. Reicht ihre Mächtigkeit nicht, sind die früheren Expressions nun selbst per JavaScript zu implementieren. Der Code füllt sich schnell mit einer relativ großen Anzahl von Funktionen, die nur den Computed Properties dienen. Erst mit der neuesten Version 1.2 ist dies durch die Einführung von sogenannten Compound Bindings verbessert worden. Damit können gebundene Variablen nun auch Teil einer längeren Zeichenkette sein.
Nicht zuletzt wurden mit 1.0 sowohl Tags als auch Properties umbenannt und es wurde die Möglichkeit genommen, von eigenen Elementen zu erben. Stattdessen wurden die Behaviours eingeführt - eine Art Code-MixIn. Unterm Strich wurden allzu weitgehende, zu ambitionierte Konzepte entfernt und an die Realität des derzeit technisch sinnvoll Möglichen angepasst. Die großen Änderungen bezogen auf 0.5 erscheinen sinnvoll und der Aufwand dafür gut investiert, auch wenn es sich bei Polymer 1.x um ein nahezu komplett neues Framework handelt. Möchte man wechseln, bedeutet dies aber einen großen Aufwand für alle, die ihre Projekte von 0.5 auf 1.x migrieren möchten.
Allerdings hinterlässt auch Polymer 1.x den Eindruck von „unfertig”. Vielleicht war der Zeitdruck aufgrund der Präsentation zur Google I/O zu groß. Dieser Eindruck entsteht zum Beispiel auch beim Betrachten der Polymer-Elementbibliothek. Einige UI-Elemente waren zum Launch noch nicht vorhanden oder sind bis heute nicht fehlerfrei implementiert. Diese Lücken müssen im Projekt entsprechend geschlossen werden, was zusätzlichen Aufwand bedeutet.
Durch die aktive Weiterführung seitens Google erhalten das Framework und die Elementbibliothek allerdings ständig Updates und auch neue Elemente kommen hinzu. So ist es nur eine Frage der Zeit, bis der Stand von 0.5 wieder erreicht ist. Wir hatten für ein Modernisierungsvorhaben in einem Unternehmensumfeld die Aufgabe, eine bereits auf Polymer 0.5 erstellte Codebasis auf den aktuellen Stand zu migrieren. Die Umstellung auf die neuen APIs war dabei nicht nur Fleißarbeit. Auch prinzipiell unterschiedliches Verhalten und die oben genannten Lücken im Umfang der UI-Elemente haben dabei den größten Aufwand erzeugt. Ebenfalls mussten zuvor vorhandene Elemente nachimplementiert werden.
Ist Polymer 1.x nun produktionsreif?
Alles in allem ist Polymer 1.x eine gute Einser-Version. Die wesentlichen Ideen der Web-Component-Spezifikation lassen sich, ebenso wie die schon fertigen UI-Komponenten, einfach und performant verwenden. Natürlich ist nicht alles perfekt, aber es wurde eine gute Grundlage zur weiteren Pflege geschaffen. Einem produktiven Einsatz steht nun tatsächlich nichts mehr im Wege.
Einsatz im Enterprise-Umfeld
Große Firmen - viele Teams - komplexe Projekte
Auch für Geschäftsanwendungen steigen die Anforderungen in Bezug auf User Experience (UX), um in komplexen Zusammenhängen geeignete User-Interaktion zu ermöglichen. Die allgegenwärtigen CRUD-Masken reichen dafür nicht mehr aus. Web Components ermöglichen die Bereitstellung neuer Metaphoren [3] und ausgefeilter Benutzerdialoge in strukturierter und wiederverwendbarer Form, erfordern aber ein hohes Maß an fachlicher Strukturierung.
Im Umfeld stärker modularisierter Anwendungen, welche wir in Zukunft hoffentlich häufiger antreffen werden, ermöglicht der Einsatz von Komponenten die weitgehend einheitliche Umsetzung moderner UI-Konzepte. Damit erscheint der Einsatz von Web Components in solchen Projekten attraktiv. Ob dies aber längerfristig tragbar ist, hängt stark von der Stabilität der konkret verwendeten Frameworks ab.
Was bietet Polymer dem Entwickler?
Das große Plus von Polymer in solchen Geschäftsanwendungen liegt in der Unterstützung einer komponentenbasierten Entwicklung. Dabei ist zum ersten Mal auch eine Form der aus der objektorientierten Welt bekannten Kapselung von internen Strukturen und Vererbungen möglich. Zumindest ist Vererbung schon jetzt für native HTML-Elemente möglich. Zusammen mit einem Dependency-Management-Tool wie Bower lassen sich auch komplexe Abhängigkeiten recht einfach abbilden, verwalten und automatisch auflösen, ähnlich wie es das Java-Ökosystem schon eine ganze Weile durch Maven oder ähnliche Tools realisiert.
Polymer stellt für den schnellen Einstieg eine umfangreiche Anzahl von leicht verwendbaren UI-Elementen zur Verfügung. Solange man Material Design und dessen Idee einsetzen kann, ist das auch unkompliziert möglich. Lassen die Vorgaben zum Corporate Design beziehungsweise zur Corporate Identity den Einsatz jedoch nicht zu, wird man eigene UI-Komponenten entwickeln. Dafür kann man auf einen reichen Fundus von Basis-Elementen (wie zum Beispiel iron-ajax, welches einen asynchronen HTTP-Aufruf ermöglicht) oder Behaviours zurückgreifen. Die Möglichkeiten, relativ einfach eine eigene Dokumentation der erstellten Elemente zu erzeugen und die eigenen Elemente Unit-Test unterziehen zu können, runden das Bild ab. Die mit Material Design einhergehenden und gut dokumentierten Design-Prinzipien erleichtern bei konsequenter Umsetzung die Entwicklung benutzerzentrierter Anwendungen, die sich für den Anwender durchgängig und intuitiv anfühlt. Tauscht man dies gegen die oftmals nur statischen UI-Vorgaben in Unternehmen ohne ein adäquates UX-Konzept, fehlt dem Entwickler der notwendige Rahmen. Wir haben erlebt, dass daraus dann leicht eine Funktionen-zentrierte Entwicklung entsteht, ohne übergreifende Navigations- und Interaktionskonzepte.
![Abb. 1: Der Elemente-Katalog erlaubt eine schnelle Übersicht und Auswahl der angebotenen Elemente [^Poly]](https://res.cloudinary.com/innoq/image/upload/uploads-production/PolymerCatalog_0c6d0a2b-1ec8-487e-ac8b-604c2a8f7397.png)
Polymer erfordert aber auch einen Einarbeitungsaufwand, man sollte die Komplexität bei der Entwicklung nicht unterschätzen. Polymer nutzt noch immer ein komplexes Konstrukt aus Laufzeitumgebungen (unterschiedliche Browser), CSS, DOM, JavaScript und Polyfills. Je komplexer eine solche Webanwendung wird, desto mehr muss man die internen Vorgänge verstehen und mit vorhandenen Workarounds umgehen lernen. Die gilt besonders, wenn es um die Seitengeschwindigkeit geht. Wer nicht gerade sehr simple Webseiten implementiert, wird hier früher oder später optimieren müssen.
Ist Polymer also zu Größerem bestimmt?
Der Einsatz von komplexen Frontend-Frameworks in großen Geschäftsanwendungen muss sehr gut abgewogen werden. Je umfangreicher die gewünschte Webanwendung ist und je komplexer die UX, desto sinnvoller ist der Einsatz von Polymer. Je mehr die Anwendung formularbasiert (CRUD – Create, Read, Update, Delete) sein soll, desto weniger. Beim Einsatz von Polymer ist es in jedem Fall ratsam, in eine gründlich durchdachte und formulierte Frontend-Architektur zu investieren und so für Struktur zu sorgen. Nur so lassen sich von Anfang an Element-Wildwuchs und Performanz-Probleme bändigen.
Ausblick
Im zweiten Teil dieser Serie zeigen wir die konkrete technische Anwendung von Polymer in der aktuellen Version 1.0.