img - GitHub Pages
img - GitHub Pages
img - GitHub Pages
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
4.16. RP15 No Duplication 84<br />
Problem von Rendr<br />
Unterstützt nur Handlebars [Kat] für View-<br />
Templates<br />
Quelltext für Client kann nicht automatisch zusammengefasst<br />
und zur Übertragung optimiert werden<br />
Rendr ist mittels CoffeeScript [Ash] implementiert<br />
Wiederholte Überprüfung der aktuellen Runtime-<br />
Umgebung (Client oder Server) mittels entsprechender<br />
if -Statements<br />
Lösung durch barefoot<br />
Keine Vorgabe resp. ohne Template-Engine verwendbar<br />
Barefoot verwendet hierfür die browserifymiddleware<br />
(siehe auch 4.18 “RP17 Static<br />
Assets”)<br />
Barefoot setzt auf pures JavaScript unter Verwendung<br />
von Underscore [Aire]<br />
Einmalige Überprüfung, anschliessende Verwendung<br />
umgebungsspezifischer Mixins<br />
Abbildung 4.6.: Rendr vs. barefoot<br />
Diskussion<br />
Ähnlich den zwei Typen von Webapplikationen sind hier zwei kontroverse Strömungen<br />
in der Entwicklergemeinschaft erkennbar [Comd]: Die eine Gruppe drängt zur alleinigen<br />
Nutzung der neusten Features und tendiert daher eher zu Lösungen mit reinen<br />
JavaScript Clients. Andere Gruppierungen geben sich vergleichsweise konservativ. Sie<br />
argumentieren damit, dass:<br />
• zum Einen die Kompatibilität zu weniger leistungsstarken Browsern resp. Java-<br />
Script Engines (Smartphones, alte Browserversionen etc.) gewährleistet sein müsse<br />
• zum anderen die Umsetzung einer ebensolchen unobtrusive Lösung entsprechend<br />
aufwändig sei.<br />
Beiden Lagern kann das Projektteam mit der umgesetzten Beispielapplikation entgegentreten:<br />
Mit barefoot sind Webapplikationen möglich, welche mit einer einzigen, durchgängigen<br />
Codebasis sowohl das statische als auch clientseitige Rendering von User Interfaces<br />
resp. deren Ausführung ermöglicht. Daraus resultiert eine im Vergleich zur doppelten<br />
Implementierung höhere Effektivität im Entwicklungsprozess. Gleichzeitig kann<br />
das Erlebnis für den Endbenutzer optimiert werden.<br />
Ob sich die Investition in die Entwicklung einer Webapplikation, welche RP14 Unobtrusive<br />
JavaScript genügt, lohnt, kann das Projektteam nicht pauschal beantworten. Je<br />
nach Anforderungen kann die Erfüllung dieser Richtlinie aber zu einer höheren Akzeptanz<br />
bei den Benutzern führen. Frameworks wie barefoot können zudem künftig dazu<br />
beitragen, einfacher eine “unobtrusive” Lösung umzusetzen.<br />
4.16. RP15 No Duplication<br />
Um RP15 einfach erklären zu können, soll folgendes Beispiel dienen:
Change language