Vor- und Nachteile von Web Components mit Polymer

gegenüber AngularJS ohne Polymer

Oliver Hader

Hochschule für Angewandte Wissenschaften Hof, Alfons-Goppel-Platz 1, 95028 Hof, Germany

oliver.hader@typo3.org

Abstract. Bei der Entwicklung von Web Applikationen führt die zunehmende Verlagerung von ursprünglich serverseitiger Logik in den Web-Browser zu neuen Herausforderungen und neuen Lösungsansätzen. Dieser Beitrag vergleicht das JavaScript Framework AngularJS mit dem noch relativ neuen Web Components Standard unter Einbeziehung des Polymer Frameworks. Zur Bewertung werden alltägliche und durchschnittliche Aufgaben aus der Web-Entwicklung betrachtet und für die beiden zu untersuchenden Projekte bewertet. Der Fokus liegt dabei auch auf Individualisierbarkeit, Verlässlichkeit und Alltagstauglichkeit für Web-Entwickler.

Keywords: Web, Framework, Best Practice, Polymer, AngularJS, Web Components, HTML5, Shadow DOM, Templates, Imports, Custom Elements

1 Motivation

Bei der objektorientierten Programmierung werden Wartbarkeit und Wiederverbendbarkeit von Komponenten als Vorteil hervorgehoben [8]. Die Entwicklung von Web-Anwendungen unterliegt zwar einigen anderen technischen Voraussetzungen, jedoch halten die langjährig erprobten Prinzipien und Paradigmen der Softwareentwicklung auch bei der Web-Entwicklung Einzug. Die Basistechnologien im Web sind durch HTML, JavaScript und CSS hinreichend bekannt. Jedoch gibt es auch hier immer wieder innovative Weiterentwicklungen, um den Entwicklungsansprüchen gerecht zu werden. Im Folgenden sollen die beiden JavaScript Frameworks Polymer und AngularJS zunächst einzeln betrachtet, weiterhin bzgl. alltäglichen Herausforderungen bei der Web-Entwicklung bewertet und schließlich gegeneinander verglichen werden.

Folgende Fragestellungen lassen sich daraus ableiten: • Wo liegen die Stärken und Schwächen des jeweiligen Frameworks? • Welches Framework erscheint für welchen Anwendungszweck am geeignetsten?

2 Basis-Technologien & Konzepte

Mit der Einführung von HTML 4.01 als W3C-Standard wurde bereits vor mehreren Jahren der Trennung zwischen Inhalt und Präsentation eine wichtige Rolle zugesprochen [9]. HTML als Auszeichnungssprache hat primär die Aufgabe, Informationen strukturiert definieren zu können. Die visuelle Präsentation und Formatierung fällt allein unter den Aufgabenbereich von CSS. Verhaltensweisen und Zustände einer Web-Anwendung lassen sich mittels JavaScript und der Modifikation des durch HTML definierten Document Object Models (DOM) umsetzen.

Mit HTML5 wurden dann zwar einige neue semantische Elemente wie header, footer, article oder section eingeführt, welche allerdings hauptsächlich auf eine bessere Strukturierung eines Dokuments abzielten. Nur wenige Elemente wie nav, button oder video hatten auch eine Bedeutung hinsichtlich ihres Einsatzbereichs.

Eine funktionsfähige Navigationsleiste kann damit zwar, durch Komposition der vorhandenen Elemente umgesetzt werden, jedoch muss das Vokabular dazu mehrfach redundant wiederholt werden. Wiederverwertbarkeit im Sinne von funktional getrennten Einheiten kann somit nur durch zusätzliche Hilfsmittel realisiert werden – beispielsweise durch den Einsatz von client- oder serverseitigen Frameworks.

2.1 Web Components

Web Components ist ein Überbegriff für vier zukünftige W3C-Standards der HTML5 Spezifikation – Custom Elements, Templates, Shadow DOM und HTML Imports.

Der Fokus liegt dabei auf der Minimierung der genannten Schwächen durch individuelle semantische Erweiterbarkeit des bestehenden Vokabulars, sowie der Wiederverwertbarkeit in gekapselten Komponenten während der Web-Entwicklung.

Da die einzelnen Spezifikationen noch nicht in allen Browser-Versionen umgesetzt wurden, kommen sog. Polyfills zum Einsatz. Fehlende Unterstützung wird so weitgehend durch JavaScript nachgeahmt. Eine Garantie auf den vollständigen Funktionsumfang der Spezifikation gibt es jedoch damit auch nicht.

Custom Elements. Die Möglichkeit, eigene Elemente zu erzeugen und bestehende zu erweitern, bildet die Grundlage hinsichtlich eines individuellen HTML Vokabulars. Custom Elements werden per JavaScript registriert und werden je nach Anwendungskontext von den Hauptklassen HTMLElement bzw. SVGElement abgeleitet. Der Name eines Elements muss in diesem Zusammenhang mindestens einen Bindestrich enthalten – z.B. wecan-button anstatt wecanbutton.

Templates. Vorlagen, welche zu einem späteren Zeitpunkt mit Inhalt gefüllt werden können, stellen einen weiteren Kernaspekt zur Wiederverwertbarkeit dar und finden beispielsweise bei Wiederholung von Einträgen einer Liste Anwendung. HTML Templates werden dabei zwar vom Browser ausgewertet aber erst bei der eigentlichen Verwendung zum sichtbaren DOM hinzugefügt – bis zu diesem Zeitpunkt sind sie lediglich versteckt als sog. DocumentFragments vorhanden.

Shadow DOM. „Schattenbäume“ sind einem HTML Element untergeordnet. Elemente und CSS Definitionen innerhalb des Shadow DOM sind vor dem übergeordneten DOM versteckt und kapseln die Auswirkung auf diesen lokalen Geltungsbereich [3]. Somit kann auch das id Attribut eines HTML Knotens in unterschiedlichen Shadow DOM Bereichen den gleichen Wert belegen, weiterhin haben generische CSS Regeln keinen Einfluss auf andere Bereiche des Dokuments. Content Insertion Points in der Template Deklaration erlauben es, Inhalte von außen an das Innere des Schattenbaums durchzureichen.

Mittels CSS Scoping [4] ist es möglich, aus übergeordneten Strukturen des DOM-Baums Eigenschaften von Unterabschnitten des Shadow DOM zu beeinflussen. Durch :host wird zum Beispiel das übergeordnete Eltern-Element angesprochen – die Selektoren ::shadow und >>> gelten entweder für genau eine Ebene bzw. beliebig viele Ebenen der unterliegenden Shadow DOM Strukturen [6].

HTML Imports. Um bestehende Komponenten, samt ihrer Abhängigkeiten zu JavaScript und CSS Ressourcen, verwenden und wiederverwenden zu können, werden HTML Imports eingeführt. Damit können Bestandteile von externen HTML-Dokumenten in das aktuelle Dokument geladen werden. Ähnlich zu Templates werden die Quellen zwar verarbeitet und über das Document Objekt bereitgestellt, aber nicht automatisch zum visualisierten DOM hinzugefügt oder ausgeführt.

2.1 Data-Binding

Gemäß MVC Paradigma werden Werte eines Datenmodells durch den Controller an die Präsentationsschicht delegiert. Im Browser-Kontext beschreibt Data-Binding den Prozess dargestellte Werte innerhalb des DOM-Baums mit dem Datenmodell zu verknüpfen und diese gegenseitig zu synchronisieren. Änderungen von Werten des Datenmodells werden somit automatisch visualisiert. In der Umkehrung führen beispielsweise Texteingaben in einem Formularfeld direkt zu einer Aktualisierung der Daten. Die Synchronisation in beide Richtungen wird als Two-Way-Data-Binding bezeichnet, der Abgleich in nur eine Richtung als One-Way-Data-Binding.

2.2 Frameworks

Die genannten Technologien werden schon seit mehreren Jahren diskutiert und ausgearbeitet – der Prozess bis zu einer offiziellen Verabschiedung als W3C-Standard ist jedoch ein langwieriges Unterfangen. Aus pragmatischen Gesichtspunkten entstanden deshalb in der Vergangenheit Projekte und Frameworks, mit dem Ziel, die geplanten Technologien schon im Vorfeld verwenden zu können.

Einerseits existieren Ansätze, die versuchen mittels Polyfills sehr nahe am geplanten Standard zu bleiben und Defizite der Spezifikation durch eigene Hilfskonstruktionen abzufedern – hierzu zählen beispielsweise die Projekte Polymer, X-Tags und MapleJS. Andererseits gibt es auch Projekte, welche die technischen Konzepte aufgreifen, diese aber eigenwillig interpretieren und implementieren – wozu beispielsweise die Frameworks EmberJS, AngularJS und React zählen.

3 Analyse

Stellvertretend für die beiden im letzten Abschnitt genannten Framework-Sichtweisen werden im Folgenden die JavaScript Projekte Polymer in der Version 1.4 und AngularJS in der Version 1.0.2 zunächst einzeln betrachtet und später gegeneinander verglichen. Dabei werden die relevanten technischen Grundlagen herausgearbeitet und die Tauglichkeit hinsichtlich durchschnittlicher Herausforderungen aus dem Umfeld der Web-Entwicklung bewertet. Mit dem Fokus, wiederverwertbare Bausteine zu generieren und existierende Lösungen verwenden bzw. erweitern zu können, wurde das WeCAn Experiment [1] definiert. Folgende Problemstellungen sollen durch Polymer und AngularJS auf ihre Art und Weise gelöst werden und somit eine einheitliche Bewertung unter gleichen Voraussetzungen ermöglichen: • Integration einer Navigationskomponente auf Basis des Bootstrap Frameworks.

Als notwendige Parameter sind dabei die Angabe eines Seitentitels (Brand-Name), sowie pro Navigationselement jeweils eines Namens und Ziels, zu betrachten.

• Integration einer Landkarte, auf der Basis von Google Maps. Zusätzlich sollen verschiedene Ortspunkte jeweils durch Längen- und Breitengrad definiert werden und mit einem frei wählbaren Titel in der Landkarte visualisiert werden.

• Integration eines Nachrichten-Moduls, zur Eingabe eines beliebigen Textes. Nach dem Absenden einer Nachricht, soll diese in einer Liste mit vorangegangenen Nachrichten erscheinen. Die Anzahl aller Nachrichten soll zusätzlich in einer separaten Komponente außerhalb des Nachrichten-Moduls visualisiert werden.

• Integration eines E-Mail Eingabefeldes mit automatischer Validierung und Visualisierung hinsichtlich eines gültigen E-Mail Formats.

3.1 Web Components mit Polymer

Kernaspekte. Das JavaScript Framework Polymer erweitert die Web Components Standards durch Funktionalitäten, um den Umgang mit individuellen Elementen einerseits zu vereinfachen und andererseits auf einen gemeinsamen Nenner zu bringen [5]. Der Einsatz von Polyfills ist hier obligatorisch. Im Folgenden werden die Unterschiede zur ursprünglichen Web Components Spezifikation dargestellt.

Shadow DOM. Seit der Version 1.0 verwendet Polymer eine eigene, aufgeweichte Variante des Shadow DOM, welche mit Shady DOM bezeichnet wird. Dadurch werden Unzulänglichkeiten der Polyfills reduziert, aber dennoch das Verhalten von Shadow DOM vereinfacht nachgestellt. Diese Variante gilt als Übergangslösung, bis die native Implementierung in gängigen Browser-Versionen verfügbar ist.

Templates. Durch eigene Custom Elements, welche das ursprüngliche Template Element erweitern, wird der Funktionsumfang vergrößert. So ist es möglich, Iterationen mit dom-repeat durchführen zu können, oder mittels dom-if Bestandteile nur unter einer bestimmten Bedingung anzeigen zu lassen.

Data-Binding. Zu synchronisierende Variablen werden bei Polymer in zwei geschweifte Klammern ({{property}} – Two-Way) bzw. in zwei eckige Klammern ([[property]] – One-Way) eingeschlossen.

Abb. 1: Verwendung von Data-Binding zum Lesen via AJAX und Ergebnis-Iteration [16]

<template> <my-ajax url=”…/api/product” as=”{{data}}”></my-ajax> <template is=”dom-repeat” items=”{{data.products}}”> {{item.title}} </template> </template>

Event Handling. Jedes Element ist in der Lage, eigene Events zu definieren und auszulösen. Die Definition von Event-Listenern erfolgt deklarativ über das HTML Markup als Attribut mit dem on-Präfix und der Zuweisung einer JavaScript Funktion. Zu den Standard-Events gehören auch plattformübergreifende Gesten, wie up, down, tap oder track. Die Events tap und click sind dabei gleichbedeutend.

Abb. 2: Deklaration eines Event-Handlers für den Maus-Klick auf eine Schaltfläche [16]

<button on-tap=”handleTap”>Bestellen</button>

Stylesheets. CSS Regeln, die über das link Element innerhalb eines Polymer Elements eingebunden sind, werden durch Polymer automatisch in ein style Element eingebettet. Weiterhin ist es bereits möglich CSS Variables in diesen Komponenten zu verwenden, einem weiteren zukünftigen W3C Standard.

Erweiterungen. Polymer selbst biete eine Vielzahl von verwendbaren Komponenten über den Component Catalog an. Darüber hinaus liefert Component Kitchen eine umfangreiche Sammlung an Lösungen, welche auch ohne Polymer funktionieren.

Hinsichtlich der Erweiterbarkeit von bestehenden Verhaltensweisen, wird empfohlen, Individualisierungen über eigene neue Komponenten zu realisieren [7], anstatt bestimmte bestehende Funktionalitäten mittels komplizierter JavaScript und DOM Manipulationen zu überladen.

Kritik. Die Entwicklungsgeschwindigkeit beim Polymer Projekt seit Beginn des Jahres 2015 ist beachtenswert. Allerdings gehen damit auch nicht abwärtskompatible Änderungen [10] einher, die eine manuelle Migration von Version 0.5 zu 1.0 benötigen. Viele Aspekte sind noch als experimentell gekennzeichnet [11] und somit vermutlich auch zukünftig Themen bei hinsichtlich fehlender Abwärtskompatibilität.

3.2 AngularJS

Kernaspekte. AngularJS ist ein JavaScript Framework mit Anwendung das MVC1 Paradigmas. Ein prominentes Anliegen ist es, das bestehende HTML Vokabular durch eigene Elemente und Template-Definitionen beliebig erweitern zu können [12]. Die in der Dokumentation verwendeten Begriffe Custom Elements und Templates lassen zwar auf eine Verbindung zu den gleichlautenden HTML5 Spezifikationen der Web Components schließen, sind allerdings in Version 1.4 eher als freie Interpretation des Standards zu sehen, um eine ähnliche Funktionsweise generell anwenden zu können. Durch die Umsetzung mittels Polyfills sind die Basistechnologien somit weiterhin nur HTML und JavaScript. Seit Sommer 2014 wird an der Version 2.0 gearbeitet, welche sich momentan im Alpha-Status befindet. Die zukünftige Version basiert weitgehend auf den Spezifikationen zu Web Components – damit würde der Aufwand, die eigenen Polyfills weiterzuentwickeln und zu pflegen auf ein Minimum reduziert.

Die wichtigsten Bestandteile des Frameworks werden im Folgenden dargestellt.

Module. Sie bilden einen gemeinsamen Container für eine bestimmte Anwendung. Unterschiedliche Module können dann wiederum in einem separaten Modul zu einer kompletten Anwendung aggregiert werden – Abhängigkeiten werden dabei durch Dependency Injection2 aufgelöst.

View. Sie liefern auf der Grundlage von Templates die entsprechenden Ausgaben für den Benutzer. Ein View ist jeweils einem Controller zugeordnet. Das integrierte Routing Modul delegiert den Kontextwechsel innerhalb einer Web Applikation an die entsprechende Kombination aus Controller und dem zugehörigen View.

Controller. Die Anwendungslogik eines Views wird in einem Controller gekapselt. Über einen Scope wird das Domänenmodell nur den beteiligten Komponenten zur Verfügung gestellt und zusätzlich gekapselt.

Abb. 3: Definition eines Moduls mit Abhängigkeiten zu den externen Modulen communication und ngRoute, sowie einer schematischen Routing-Definition [1], [16]

angular.module('wecan', ['communication', 'ngRoute',]) .config(['$routeProvider', function($routeProvider) { $routeProvider .when('/communication', { templateUrl: 'partials/communication.html', controller: 'communicationCtrl'}) .otherwise({ redirectTo: '/home'});}]) .controller('communicationCtrl', function($scope) { })

1 Model-View-Controller; auch Model-View-ViewModel (MVVM) oder ~-Presenter (MVP) 2 Entwurfsmuster zur Reglementierung von Abhängigkeiten eines Objekts zur Laufzeit

Directives. Die Umsetzung von eigenen Elementen erfolgt über Directives, welche das eigentliche Herzstück von AngularJS darstellen. Sie beinhalten weitere Methoden, welche den Lebenszyklus eines Custom Elements hinsichtlich Bereitstellung, Kompilierung und Interaktion beeinflussen können [13].

Abb. 4: Darstellung der vier Möglichkeiten zur Verwendung der Direktive myDirective im Markup, mittels Element, Attribut, CSS Klassenname und Kommentar [13]

<my-directive> <div myDirective></div> <div class=“myDirective“></div> <!-- directive: myDirective; -->

Filter. Daten, die für die Präsentationsschicht bestimmt sind, können vor der Ausgabe über Filter einerseits reduziert und andererseits auch zusätzlich kodiert oder formatiert werden – beispielsweise für ein bestimmtes Datums- oder Zahlenformat.

Abb. 5: Verwendung des number Filters, resultierend in 12,345.00 (Default Locale) [16]

<span>{{ 12345 | number:2 }}</span>

Scope. Die Benachrichtigung und Delegation bei der Änderung von Werten hinsichtlich des Data-Bindings wird über automatisch generierte Scope-Instanzen gewährleistet [14]. Diese stellen das wichtigste Bindeglied bei der Verknüpfung von Darstellung (View) und Logik (Controller) dar. Es gibt einen globalen RootScope, für den Datenaustausch auf oberster Ebene, wie auch gekapselte Scopes auf der Controller Ebene. Directives erhalten – je nach Definition – einen ChildScope oder einen eigenen isolierten Scope.

Erweiterungen. Über den ngmodules.org Katalog lassen sich eine Vielzahl an Erweiterungen für bestimmte Szenarien finden. Ein Zähler hinsichtlich der Verwendung von Modulen gibt einen ersten Anhaltspunkt hinsichtlich der subjektiven Qualität und Eignung durch andere Anwender bzw. Entwickler.

Für das Überladen von bestehenden Funktionalitäten gibt es diverse Herangehensweisen, welche aber stark von der Struktur und Kapselung des zu beeinflussenden Moduls abhängen. So ist es beispielsweise möglich, das zu überladende Element mit einem eigenen Element zu dekorieren und Events über einen isolierten Scope abzufangen oder separat zu verarbeiten. Eine weitere Möglichkeit besteht darin, die eigentlich gekapselte Kontrollfunktion zu beeinflussen [15].

Kritik. Mit AngularJS wird es ermöglicht, eine Web Applikation aus „einem Guss“ unter Anwendung des MVC Paradigmas zu erstellen. Die stark bindenden Vorgaben des Frameworks hinsichtlich Scoping, Wiederverwertbarkeit und Erweiterbarkeit von externen Modulen stellen Entwickler auf eine harte Probe – im ungünstigsten Fall müssen vorhandene Lösungen teilweise neu implementiert werden, um die gewünschte Interoperabilität zwischen unterschiedlichen Modulen zu erreichen.

4 Vergleich

4.1    Gegenüberstellung  von  Polymer  und  AngularJS  

Tabelle 1. Vergleichskriterien von Polymer Web Components mit AngularJS

Aspekt Polymer Web Componets AngularJS Aktuelle Version(en)

1.0.2 (29.05.2015)

1.4.0 (27.05.2015) 2.0-alpha.26 (04.06.2015)

Lizenz BSD License MIT License Technologie HTML5, JavaScript, CSS, Custom

Elements, Templates, HTML Import, Shadow DOM

HTML5, JavaScript, CSS

Kompatibilität ab Internet Explorer 10, Firefox, Chrome, Opera, Safari

ab Internet Explorer 9, Firefox, Chrome, Opera, Safari

Anwendungs-bereich

leichtgewichtige Komponenten, aber auch Browser Anwendunen

Browser Anwendungen

Erweiterbarkeit Überladen aufwendig bis unmöglich, eher Komponenten-Neukomposition

Überladen weitgehend möglich, stark abhängig von Implementierung

Bibliotheken vielzählig, Google Element Catalog vielzählig, teilweise aber Wildwuchs Dokumentation strukturiert & geeignet, teilweise

aber noch für Version 0.5 und somit veraltet, gute Qualität bei Blog-Posts der Community

strukturiert & bedingt geeignet, allerdings wenig offizielle Beispiele für Spezialfälle zu Scoping oder Interceptors

Abwärts-kompatibilität

mittelmäßig, sehr hohe Anzahl an Breaking-Changes zwischen 0.5 und 1.0, keine Deprecation-Strategie

gut, geringe Anzahl an Breaking-Changes zwischen 1.3 und 1.4, Deprecation-Strategie vorhanden

Entwicklungs-aktivität

sehr stark, 0.5.5 (02/2015), 0.8 (03/2015), 0.9 & 1.0 (je 05/2015)

stark, 1.3.9 (01/2015), 1.4.0 (05/2015), 2.0-alpha.26 (06/2015)

4.2 Umsetzung des WeCAn Experiments durch Polymer und AngularJS

• Bootstrap Navigation: Durch die Content Insertion Points bei Web Components war die Umsetzung in Polymer einfach durchführbar – Austausch unter den Komponenten erfolgt über den neuen Behavior Scope. In AngularJS war dagegen das korrekte Scoping für den Datenaustausch über verschachtelte Ebenen hinweg zeitaufwendig – genaue Kenntnisse hinsichtlich des Kontrollflusses waren nötig.

• On-Page-Routing: Durch das integrierte Routing Modul bei AngularJS war eine Lösung innerhalb von wenigen Minuten umzusetzen. Die bei Polymer verwendete Komponente war zum Zeitpunkt der Integration schlecht dokumentiert. Die Analyse des Quellcodes zur Verwendung war somit notwendig.

• Google Maps: Die von Google entwickelte Komponente ermöglichte eine flexibel konfigurierbare Integration der Landkarte innerhalb kürzester Zeit. Ein für AngularJS verfügbares Modul konnte zwar schnell eingebaut werden, jedoch war die Anpassung der Marker aufwendig. Unzulänglichkeiten bei der automatischen Positionierung der Landkarte wurden über einen eigenen Controller behoben.

• Nachrichten Komponente: Der Transfer der Daten in einem separaten Scope war bei beiden Frameworks nicht zufriedenstellend umzusetzen – durch die Neuerungen mit Polymer 1.0 konnte jedoch die Lösung, nach den Migrationsarbeiten, in einem geringeren Zeitraum erreicht werden.

• E-Mail Eingabefeld: In AngularJS ist das erwünschte Verhalten bereits enthalten und wird rein deklarativ mittels HTML umgesetzt. Eine entsprechende Komponente des Polymer Element Katalogs erfüllt zwar die Anforderung, jedoch ließ sich das Aussehen nur durch eine Neukomposition ändern und anpassen.

Tabelle 2. Vergleich3 der Zielumsetzung hinsichtlich des WeCAn Experiments

Aspekt Polymer Web Componets AngularJS Bootstrap Navigation 8 (gut) 3 (schlecht) On-Page-Routing 7 (gut) 9 (sehr gut) Google Maps (3rd Party) 8 (gut) 5 (durchschnittlich) Nachrichten Komponente 6 (durchschnittlich gut) 5 (durchschnittlich) E-Mail Eingabefeld 4 (durchschnittlich schlecht) 8 (sehr gut)

5 Fazit

Beim direkten Vergleich von Polymer Web Components mit AngularJS fällt auf, dass jedes Framework seine Berechtigung hat und dabei jeweils eine unterschiedliche Philosophie und Herangehensweise verfolgt. Im Hinblick auf das Resultat können jedoch beide Ansätze nahezu gleichwertig betrachtet werden.

Bei der Entscheidung für nur exakt eines dieser Projekte, sei angemerkt, dass der Fokus dennoch auf der Lösung der eigentlichen Problemsituation liegen sollte. So punkten Web Components bei atomar gekapselten und frei wiederverwertbaren Komponenten und AngularJS spielt seine Stärke bei der Umsetzung von umfangreichen Single-Page Web-Anwendungen aus. Die Kombination von beiden Ansätzen innerhalb eines Problemkontexts erscheint somit auch legitim – so können die jeweiligen relativen Stärken zu einer symbiotischen Lösung vereint werden. Diese These wird ein Stück weit durch die genannte Entscheidung des AngularJS Entwickler-Teams, Version 2.04 auf der Basis von Web Components neu zu entwickeln, getragen und bestätigt.

An dieser Stelle sei auch angemerkt, dass Aufgaben nicht zwingend mit einem Framework erledigt werden müssen. Anstatt simple DOM Manipulationen über Watcher5, Scoping und Data-Binding eines schwergewichtigen Frameworks zu „erschlagen“, empfiehlt es sich auch weiterhin, direkt Low-Level-Funktionalitäten in JavaScript zu verwenden – auch mit einer leichtgewichtigen Bibliothek wie jQuery.

3 Punktevergabe von 1 bis 9, wobei 1 „sehr schlecht“ und 9 „sehr gut“ bedeutet 4 vgl. http://ng-learn.org/2014/03/AngularJS-2-Status-Preview/ 5 AngularJS $watcher zur Überwachung von Änderungen auf Objekt-Ebene bzw. im DOM

Referenzen & Quellen

[1] Dokument „Web Components vs. AngularJS“. In: GitHub. Bearbeitungsstand: 4. Juni 2015. URL: https://github.com/ohader/wecan (Abgerufen: 4. Juni 2015)

[2] Dokument „HTML Imports“. In: HTML5 Rocks. Bearbeitungsstand: 18. Dezember 2014. URL: http://www.html5rocks.com/en/tutorials/webcomponents/imports/ (Abgerufen: 4. Juni 2015)

[3] Dokument „Shadow DOM: The Basics“. In: Rob Dodson talks internets. Veröffentlichung: 27. August 2015. URL: http://robdodson.me/shadow-dom-the-basics/ (Abgerufen: 4. Juni 2015)

[4] Dokument „CSS Scoping Module Level 1“. In: W3C CSS Working Group Editor Drafts. Bearbeitungsstand: 29. Mai 2015. URL: http://drafts.csswg.org/css-scoping/#selectordef-host0 (Abgerufen: 4. Juni 2015)

[5] Dokument „What is Polymer“. In: Polymer Documentation. Bearbeitungsstand: 28. Mai 2015. URL: https://www.polymer-project.org/1.0/docs/start/what-is-polymer.html#is-polymer-web-components-is-it-elements (Abgerufen: 4. Juni 2015)

[6] Dokument „Shadow DOM CSS Cheat Sheet“. In: Rob Dodson talks internets. Veröffentlichung: 11. April 2014. URL: http://robdodson.me/shadow-dom-css-cheat-sheet/ (Abgerufen: 4. Juni 2015)

[7] Dokument „Inheritance and composition with Polymer“. In: Pascal Precht, Thoughts on Vim mastery and the future of the web. Veröffentlichung: 14. Juli 2014. URL: https://pascalprecht.github.io/2014/07/14/inheritance-and-composition-with-polymer/ (Abgerufen: 4. Juni 2015)

[8] Dokument „A Realistic Look at Object-Oriented Reuse“. In: Dr. Dobb’s – The World of Software Development. Veröffentlichung: 1. Januar 1998. URL: http://www.drdobbs.com/a-realistic-look-at-object-oriented-reus/184415594 (Abgerufen: 12. Juli 2015)

[9] Dokument: „Introduction to HTML 4“. In: W3C Recommendation. Bearbeitungsstand: 24. Dezember 1999. URL: http://www.w3.org/TR/html401/intro/intro.html#h-2.4 (Abgerufen: 12. Juli 2015)

[10] Dokument „Release notes“. In Polymer Documentation. Bearbeitungsstand: 29. Mai 2015. URL: https://www.polymer-project.org/1.0/docs/release-notes.html (Abgerufen: 4. Juni 2015)

[11] Dokument „Experimental features & elements“. In Polymer Documentation. Bearbeitungsstand: 29. Mai 2015. URL: https://www.polymer-project.org/1.0/docs/devguide/experimental.html (Abgerufen: 4. Juni 2015)

[12] Dokument „Web Components Architecture & Development with AngularJS“. In: Leanpub, publish early, publish often. Bearbeitungsstand: 1. Entwurf, Oktober 2014. URL: https://leanpub.com/web-component-development-with-angularjs/read#leanpub-auto-chapter-2---angularjs-as-a-ui-component-framework (Abgerufen: 5. Juni 2015)

[13] Dokument „The Hitchhiker’s Guide to the Directive“. In: codef0rmer, Amit Gharat. Bearbeitungsstand: 8. Juni 2013. URL: https://amitgharat.wordpress.com/2013/06/08/the-hitchhikers-guide-to-the-directive/ (Abgerufen: 5. Juni 2015)

[14] Dokument „A Practical Guide to AngularJS Directives (Part Two)“. In: SitePoint, Sandeep Panda. Bearbeitungsstand: 17. Januar 2014. URL: http://www.sitepoint.com/practical-guide-angularjs-directives-part-two/ (Abgerufen: 5. Juni 2015)

[15] Dokument „Extending an Existing Directive in Angularjs“. In: Avi Haiat, Coding Experience. Bearbeitungsstand: 10. März 2014. URL: http://thaiat.github.io/blog/2014/03/10/extending-an-existing-directive-in-angularjs/ (Abgerufen: 5. Juni 2015)

[16] Eigene Darstellung / Eigenes Beispiel