Im letzten Post habe ich einige Grundlagen zur Entwicklung mit JavaScript erklärt. Hier wurde wahrscheinlich auch denen, die JavaScript immer noch nur für kleine Gimmicks in Webseiten nutzen klar, dass sich die Skript-Sprache inzwischen viel weiter entwickelt hat.

Früher war es üblich, die meisten der Aktionen, die auf einer Webseite durchzuführen waren, auf der Serverseite ablaufen zu lassen, clientseitige Scripts waren nur zur Ergänzung vorgesehen. So war auch die Welt der Web-Entwicklung lange Sprachen wie PHP, JSP, ASP und ähnlichen vorbehalten. Dann kam Ajax und man verlagerte zunehmend Aktionen auf die Client-Seite und stellte auf dem Server dazu passende Services bereit, die dann die eigentlichen Aktionen durchführten und Daten in Form von XML, oder später immer häufiger als JSON, an den Client lieferten, wo diese von JavaScript wieder als HTML-Elemente in die Seite eingebettet wurden. Trotzdem lagen die eigentlichen Seiten stets auf Serverseite in eigenen Dateien vor und es wurden viele Post-Backs und damit Round-Trips zum Server benötigt. Da man jedoch zunehmend “responsive” Seiten haben wollte, bei denen der Benutzer nicht darauf warten muss, dass die komplette aktualisierte Seite vom Server zurück kommt, musste etwas Neues her.

Die konsequente Weiterführung dieses Trends ist die Single-Page App. Hierbei gibt es nur noch eine einzige HTML-Seite, in der JavaScript eingebettet ist. Dieses beinhaltet entweder die komplette Webseite oder lädt bei Bedarf weitere JavaScripts nach. Auf diese Weise handelt es sich bei einer solchen Seite genau genommen nicht mehr um eine Webseite, sondern um eine richtige Anwendung. Damit lässt sich auch wie bei einem herkömmlichen Client-Server-System sehr flexibel entscheiden, wo welche Teile der Geschäftslogik laufen sollen. Man kann weiterhin alle Logik auf dem Server ablaufen lassen, oder man kann die eigenen Rechner-Ressourcen schonen und Berechnungen auf die Clients auslagern. Es empfiehlt sich jedoch weiterhin, sensible Geschäftslogik auf dem Server auszuführen. Es gibt zwar viele Werkzeuge, um den ausgelieferten JavaScript-Code schwerer manipulierbar zu machen, aber hier verhält es sich wie bei allem, das man an Clients ausliefert – was beim Client ist, steht auch unter dessen Kontrolle.

 

Um eine Single-Page App sauber aufzubauen empfiehlt es sich, nicht einfach wild drauf los zu basteln. Wie bei allem in der IT sollte man genau planen und prüfen, ob es Hilfsmittel, Frameworks oder Pattern gibt, die einem Arbeit abnehmen. Bei Oberflächen haben sich hier die Pattern MVC und MVVM etabliert. Diese propagieren eine Trennung von Daten, Ansicht und Logik, was neben der sauberen Aspekt- und Aufgaben-Trennung auch der Testbarkeit zu Gute kommt. Hier gibt es im JavaScript-Umfeld mehrere Frameworks für Single-Page Apps, wie zum Beispiel angularjs, ember, polymer, meteor, backbone.js oder knockout, um nur einige zu nennen. Unter den vielen Framework-Vertretern hat sich das von Google entwickelte angularjs sehr stark etabliert. Es wurde 2009 von Miško Hevery entwickelt und hat sich in den letzten Jahren immer weiter verbreitet. Basis des Systems ist quasi die virtuelle Erweiterung des HTML-Namensraums um eigene Elemente, hinter denen sich dann wieder Teile des Programms mit HTML-Markup und Javascript-Logik verstecken und die sich einfach schachteln lassen. Da das angularjs-Framework nun doch schon einige Jahre auf dem Buckel hat, wurde entschieden, das ganze Framework mit den gesammelten Erfahrungen neu zu implementieren. Angular 2 ist aktuell zwar noch im Alpha-Stadium, jedoch ist es schon sehr weit entwickelt und für unsere kleine Demo-App ist es auf jeden Fall schon reif. Zur Entwicklung von Angular 2 nutzt das Google-Team kein reines JavaScript, sondern hat sich auf eine JavaScript-Erweiterung von Microsoft – früher unvorstellbar – gestützt, nämlich TypeScript.

TypeScript bringt viele der Vorteile, die kommende ECMA-Script Versionen bieten werden schon heute und ermöglicht außerdem die explizite Angabe von Typen für Variablen. Es wird nicht direkt interpretiert, sondern beim Build von einem Compiler in JavaScript übersetzt. Da das Angular 2-Team auf TypeScript aufbaut, halte ich es für eine gute Idee, beim Einsatz von Angular 2 ebenfalls diesen Weg zu wählen.

 

Nun wollen wir aber unsere App nicht nur im Browser laufen lassen, sondern wollen eine volle Integration. Hier bietet sich Apache Cordova an. Dieses Framework ermöglicht es, eine mit HTML5, CSS3 und JavaScript entwickelte Applikation als App auf die verschiedensten Plattformen zu bringen, allen voran die gängigsten – iOS und Android neben Windows, Windows Phone und weiteren. Prinzipiell lassen sich alle Plattformen mit dem selben Quellcode bedienen, selbst der Zugriff auf die meisten nativen Funktionen der Geräte ist über die umfangreiche API des Cordova-Frameworks einfach möglich. Und sollten die Funktionen doch nicht ausreichen, kann man einfach weitere Plugins schreiben – dies natürlich dann für alle Plattformen, die man einsetzen möchte getrennt.

Möchte man neben den mobilen Plattformen auch klassische Desktops unterstützen, so kann man dies mit dem Framework NW.js tun. Dies ist nicht der Fokus dieser Artikel-Reihe, jedoch ist die Funktionsweise sehr ähnlich.

 

Nach so viel Theorie freue ich mich schon auf den nächsten Artikel, wenn es endlich an den Code geht. 😉