SPAs erreichen dies dadurch, dass viel mehr Applikationslogik als vormals üblich direkt im Browser des Anwenders ausgeführt wird. Auch die übertragene Datenmenge wird reduziert, da üblicherweise nicht mehr die komplette Seite in HTML übertragen wird, sondern lediglich die Nutzdaten (oft im JSON Format). Vielen Lesern wird dieser Strukturierungsansatz noch in ähnlicher Form von den Rich Clients bekannt vorkommen, die Gedanken sind auch sehr ähnlich.
Klassischer Aufbau einer Webanwendung:
Aufbau einer Single Page Application:
Da SPAs nun jedoch viel größer sind als die paar JQuery Selektoren, die wir im letzten Projekt noch in einer Datei ablegen konnten, sollten wir nun auch softwaretechnisch andere Geschütze auffahren.
Auf der Java Backendseite haben wir uns schon lange diesem Thema gewidmet und haben dort z.B. mit Maven einen passablen Ansatz um ein Projekt aufzusetzen und zu strukturieren, mit Spring eine ordentlich Lösung um mittels Dependency Injection die Anwendung wartbarer zu gestalten, das MVC Pattern (wie z.B. in Spring MVC oder JSF), welches uns dabei hilft, wiederkehrende Aufgaben wie das Binden von Daten an Eingabefeldern elegant zu formulieren und JUnit, das uns dabei unterstützt unsere Applikation sauber zu testen.
Auf dem Client haben wir nun ganz ähnliche Aufgaben vor uns:
- Wir wollen Daten von den Eingabefeldern in ein Modell übertragen (Databinding).
- Unsere Erfahrung hat gezeigt, dass wir Remoting und Anzeigebelange besser trennen sollten, also ist etwas wie Dependency Injection wahrscheinlich eine gute Idee.
- Wir wollen ähnlich wie wir das vom Server kennen, unsere Applikation gut testen, vielleicht sogar testgetrieben vorgehen.
- Die Projektstruktur sollte so aufgebaut sein, dass sie mit dem Projekt mitwächst.
- Das Ganze sollte über ein Buildsystem einfach gehandhabt werden können.
Und üblicherweise wollen wir uns das nicht vor jedem Projekt neu ausdenken müssen.
Glücklicherweise gibt es für SPAs schon Bibliotheken und Frameworks wie Sand am Meer (manche sagen, es gibt schon zu viele), so dass wir dort nicht zwingend kreativ werden müssen ?
Das Pro und Contra zu Single Page Applications will ich an dieser Stelle gar nicht groß aufwerfen. Der Ansatz macht sicherlich nicht überall Sinn. Falls das Ziel eine schicke, zeitgemäße Anwendung ist, die sich schnell anfühlt, so ist dieser Ansatz aber meiner Meinung nach eine Überlegung wert.
Ziel
“Welches SPA Framework soll ich nun verwenden?” Ich möchte im Laufe dieser Artikelserie drei bekanntere Ansätze miteinander vergleichen und Ihnen bei Ihrer Auswahl ein wenig helfen:
- AngularJS,
- EmberJS und
- KnockoutJS.
Spannend finde ich unter anderem diese Fragen:
- Wie schnell kann ich mit den benannten Lösungen produktiv werden?
- Wie wartbar sind der Code und die Struktur der resultierenden Anwendung?
- Wie einfach lassen sich anspruchsvollere Anforderungen wie z.B. Drag and Drop umsetzen?
- Wie gut kann ich Tests für diese Umgebung schreiben?
- Wie groß und aktiv ist die Community?
- Wie gut ist es um die Dokumentation bestellt?
- Existiert sinnvolle Toolunterstützung?
- Ist es ein Problem, Third Party Bibliotheken einzubinden?
Seitenblick: NodeJS:
Bei der Entwicklung von Single Page Applications werden Sie früher oder später auf NodeJS stoßen. NodeJS ist in erster Linie eine Möglichkeit, Serveranwendungen in JavaScript zu schreiben. Das ist allerdings für uns nur am Rande interessant. NodeJS bringt zudem ein paar Tools mit, die das Arbeiten mit JavaScript ein wenig angenehmer gestalten, wird also von uns als Runtime Umgebung verwendet. Um diese Tools haben sich in bewährter Unix-Manier eine Vielzahl an weiteren Tools entwickelt, die sehr praktisch sind.
Zu nennen sind hier:
- npm
- npm ist der Standardpaketmanager für NodeJS und wird von NodeJS mitgeliefert.
- kann auch als rudimentäres Buildsystem verwendet werden.
- wird nicht nur für NodeJS Pakete sondern auch für die Installation von weiteren Tools verwendet.
- Bower
- Bower ist der geläufigste Paketmanager für die Webentwicklung.
- Bower ist weniger restriktiv als npm.
- fort findet man die Pakete für AngularJS und co.
- grunt
- grunt ist vergleichbar mit ant und sorgt für die Build-Automatisierung.
- Eine große Community verwendet grunt und steuert neue Tasks bei.
- Unter diesen Tasks sind praktische Dinge wie
- Code-Linting,
- Vergleichbar mit Findbugs
- TDD Unterstützung,
- Minifizierungen.
- Code-Linting,
- Yeoman
- Yeoman ist ein Projekt Scaffolding Tool.
- Es generiert die Projektstruktur, konfiguriert das Buildsystem und bringt je nach verwendetem Generator noch passende Helferlein mit.
- ist vergleichbar mit Maven Archetypes.
Ich hatte schon viel Gutes von Yeoman gehört, es aber bisher noch nie eingesetzt. So ich habe die Gunst der Stunde genutzt und Yeoman für das Aufsetzen der Projekte zu Rate gezogen. Ich komme in jedem Teil kurz auf Yeoman zu sprechen und werde erörtern, ob es mich sinnvoll unterstützt hat.
Beispielanwendung
Um mich diesen Fragen zu nähern, möchte ich mit jeder dieser Technologien eine kleine Beispielanwendung bauen.
Diese Anwendung ist direkt aus dem Leben gegriffen: Ich gehe sehr gerne auf Konzerte, verpasse dieser aber auch zu oft ? Da muss Hilfe her!
Ich möchte also eine kleine Anwendung haben, die mir alle anstehenden Konzerte anzeigt. In separaten Listen soll die Anwendung zudem anzeigen, ob ich zu dem Konzert auf jeden Fall oder nur vielleicht hingehen möchte.
Die Konzerte kann ich über ein Formular einpflegen. Zwischen den Listen kann ich einzelne Konzerte per Drag und Drop hin und herziehen. Ein Konzert ist je nach Fälligkeit eingefärbt.
Ein Beispiel findet sich hier: http://concertangular.herokuapp.com/
Ich habe mich hier ausschließlich auf das Frontend gestürzt, ein Backend ist zu diesem Zeitpunkt noch nicht vorgesehen.
Ich hoffe, ich konnte ein wenig Appetit anregen und werde im nächsten Teil dieser Artikelserie vorstellen, wie ich diese Applikation mit Hilfe von AngularJS umgesetzt habe.
