Das Dokument vergleicht die JavaScript-Frameworks Polymer und AngularJS, wobei es sich auf Web Components und deren Vor- und Nachteile konzentriert. Polymer bietet erweiterte Funktionen wie Shadow DOM und Data Binding, was die Wiederverwendbarkeit von Komponenten optimiert, während AngularJS das MVC-Paradigma nutzt, um Applikationen zu strukturieren. Es werden auch spezifische Herausforderungen in der Web-Entwicklung analysiert, um die jeweiligen Stärken und Schwächen der beiden Frameworks zu identifizieren.

1. 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. 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.

3. 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.

4. 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.

5. 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.

6. 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

7. 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.

8. 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.

9. • 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

10. 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