Browserseitge Technologie

Momentan läuft die Mathenacht-Webseite auf einer nicht mehr optimalen Implementierung. Diese soll gegen eine neue ausgetauscht werden; @simon überlegt für die Browser-Seite den Einsatz von Ember.js; mir schwebt eher Angular 2 vor.

In diesem Thema sammeln wir andere Vorschläge und Argumente sowohl für als auch gegen die jeweiligen Systeme.

Generell sollten wir, auch wenn sich einige Frameworks direkt in der Auslieferung mit Daten bestücken lassen, auf eine saubere Schnittstelle achten und die Web-Applikation getrennt von den Daten ausliefern. Diese Trennung von Darstellung (Web-Applikation) und Daten erleichtert die zukünftige Wartung und Weiterentwicklung.

Mein Favorit für die Entwicklung der Web-Applikation ist Angular, da ich dort durch meine Arbeit schon einiges an Kenntnissen und Werkzeuge habe, die ich nicht neu aufbauen muss. Das klingt vielleicht egoistisch - und das mag es auch sein -, bedenkt aber bitte, dass dadurch die Lernkurve für alle Beteiligten flacher wird, weil es jemanden gibt, den man fragen kann.

Weg von den individuellen Betrachtungswinkeln, hin zu objektiveren Punkten:

Bei VoidCanvas gibt es einen Vergleich zwischen AngularJS, Ember und backbone.

Die Punkte für Angular 1, die dort genannt wurden, gelten auch für Angular - mit Ausnahme des Dirty Checkings und der Getter + Setter. An der Stelle wurde in Angular2 massiv geändert, so dass jetzt Getter und Setter benutzt werden. Außerdem läuft dirty checking nicht mehr mittels Polling, sondern mittels isDirty-Benachrichtigungen, was das ganze deutlich performanter macht.

Die Implementierung von Angular2 Apps läuft in TypeScript, was Typsicherheit auf Compiler-Ebene mit sich bringt. Ist ganz hilfreich, vor allem in Bezug auf IntelliSense beim Programmieren.

Zu EmberJS kann ich noch nichts sagen, weil ich es mir noch nicht angesehen habe. Ich habe aber ein kleines Projekt an der Hand, dass ich mit EmberJS umsetzen werde, um das Framework näher kennen zu lernen. Ich melde mich, wenn ich damit weitergekommen bin - oder daran verzweifelt.

Hier schon mal ein längerer Beitrag, warum EmberJS für Entwickler empfehlenswerter ist / sein kann als Angular.

Ich habe mich jetzt einige Tage mit EmberJS beschäftigt und muss sagen, es ist ein größenmäßig recht kleines System, das auch zügig lädt. Ein kurzer Vergleich mittels Hello World inkl. Bild:

  • EmberJS: ca. 850 kB, 750 ms
  • Angular 2.4.1, Optimierung mittels Rollup.js: ca. 750 kB, 500 ms
  • Angular 2.4.1, Optimierung mittels WebPack: ca. 1 MB, 800 ms

Im Gegensatz zu Angular schreibt EmberJS die Ordner- und Dateistruktur durch ihr Motto Convention over Configuration zwingend vor. Das an sich ist nicht schlecht, nur werden die Dateien einer Komponente nach ihrer Funktion (Model, View, Controller) über drei verschiedene Ordner verteilt. Handelt es sich dann auch noch um verschachtelte Komponenten, geht das ganze auch noch in Ordner-Bäume hinab. Das MVC-Paradigma, das hier in der Datei-Struktur umgesetzt wird, war zur Gründungszeit von EmberJS durchaus aktuell und hat auch heute noch seine Berechtigung. Allerdings haben sich in der Zwischenzeit weitere Paradigmen hervorgetan wie Webkomponenten, bei denen die Dateien anhand ihrer Komponenten in Ordnern abgelegt werden. Man verliert also bei der Wartung nicht so viel Zeit damit, in der Ordnerstruktur nach den jeweiligen Dateien zu suchen. Außerdem ist das in meinen Augen übersichtlicher.

Und ja, ich spreche durchaus aus beruflicher Erfahrung, wenn ich sage, dass eine einfache und übersichtliche Ordner- und Dateistruktur die Entwicklung und Wartung massiv erleichtert.

Von daher spreche ich mich für Angular als browserseitige Technologie aus.

@Simon, Dein Kommentar bitte.