© saicle/Shutterstock.com
JavaScript-Frameworks im Vergleich

Get ready to rumble!


Heute steigen einige der bekanntesten JavaScript-Frameworks in den Ring, um ihre Kräfte zu messen und den König unter ihnen zu krönen. Aber lassen Sie uns einen Schritt zurückgehen und sehen, wie es zu dieser Auseinandersetzung kam …

Beginnt man als Programmierer mit der Arbeit am Frontend einer neuen Webapplikation, sieht man sich einer Vielzahl unbeantworteter Fragen gegenüber, von denen eine der bedeutendsten die nach den einzusetzenden Werkzeugen ist. Das sollte Ihnen jetzt keine Angst machen, aber die Wahl des passenden Frameworks ist eine wesentliche und schwerwiegende Entscheidung im Lebenszyklus einer Applikation, stellt sie doch einige Weichen für die zukünftige Entwicklung wie beispielsweise den grundsätzlichen Aufbau der Applikation und die Herangehensweise bei der Definition von Komponenten. Außerdem ist der Austausch des Frameworks in einer Applikation ein schwerwiegender Eingriff, der immer schmerzhafter und teurer wird, je später er im Lebenszyklus einer Software erfolgt. Dieser Artikel soll Ihnen einige der wichtigsten JavaScript-Frameworks und deren Vorzüge und Nachteile näherbringen.

Welches Framework ist also das beste?

Würden wir in einer perfekten Welt leben, gäbe es ein JavaScript-Framework, das sämtliche Probleme löst – und der Fall wäre erledigt. Sie müssten sich dann nur noch den Quellcode des Frameworks herunterladen, ihn in Ihre HTML-Struktur einbinden und könnten mit der Entwicklung Ihrer Applikation beginnen. Jedoch ist die Welt, in der wir leben, in diesem Zusammenhang weit entfernt von einem perfekten Zustand. Es ist noch nicht einmal so, dass für eine bestimmte Problemstellung nur eine Lösungsoption existiert. Vielmehr scheint es, als ob gefühlt jede Woche ein neues Framework entsteht, das alles besser, einfacher und viel schneller als alles bisher Dagewesene löst.

Und genau hierin steckt das zweite Ziel dieses Artikels. Er soll Ihnen zeigen, wie Sie auch Frameworks bewerten können, die in diesem Artikel nicht erwähnt werden. Das hat natürlich auch noch den praktischen Hintergrund, dass hier schon allein aus Platzgründen nicht alle Frameworks ausführlich behandelt werden können.

Welche Bewertungskriterien und warum?

Bevor Sie im Anschluss gleich die einzelnen Frameworks kennen lernen, erfahren Sie zunächst noch etwas über die einzelnen Disziplinen, in denen sich die Kontrahenten messen werden. Die vier Frameworks, die in diesem Kapitel gegenübertreten, messen sich in zwölf Runden, wie es sich für einen ordentlichen Faustkampf gehört.

In der ersten Runde soll die Philosophie des Frameworks in die Waagschale geworfen werden. Der offensichtlichste Teil sind das Motto und der Leitspruch des Frameworks. Hinzu kommen die Aussagen des Herstellers über das jeweils angedachte Einsatzgebiet.

Die zweite Runde beschäftigt sich mit der Historie des jeweiligen Frameworks und den eventuellen Turbulenzen, die dabei durchlaufen wurden.

Eine wichtige Rolle bei einem Framework spielen außerdem die Releasezyklen. Sind diese fest oder unregelmäßig? Gibt es häufig größere Änderungen oder ist die Weiterentwicklung des Frameworks eher von kontinuierlicher Modernisierung geprägt?

Runde vier beleuchtet das Lizenzmodell der Frameworks. Handelt es sich um frei verfügbare Software oder fallen Lizenzkosten an? Darf das Framework bedenkenlos weitergegeben werden oder muss etwas beachtet werden?

Gerade wenn Sie noch keine Erfahrung mit einem Framework haben, ist die Verfügbarkeit und Qualität der Dokumentation entscheidend. Runde fünf fühlt den Frameworks hinsichtlich der Beschreibung auf den Zahn.

In Runde sechs geht es dann noch ein Stück weiter in Richtung Praxisrelevanz. Hier vergleichen sich die einzelnen Frameworks in ihren Kernfeatures und ihrem Gesamtumfang.

Ganz ähnlich, aber noch ein Stück allgemeingültiger geht es dann in der siebten Runde zu, in der die architektonischen Ansätze der Frameworks gegenübergestellt werden.

Ein Framework kommt selten allein. Diese Aussage trifft gerade für die achte Runde zu, in der die Abhängigkeiten der Frameworks zur Diskussion stehen. Also Bibliotheken, die Sie benötigen, um das Framework überhaupt betreiben zu können.

Wie bei einem Sportler, so ist es auch bei einem Framework so, dass es erst durch seine Fans richtig stark wird – also die dahinterstehende Community. Und so beleuchtet Runde neun die Unterstützung durch die Community.

In der zehnten Runde geht es schließlich mit konkreten Implementierungen beziehungsweise einer Betrachtung der Vorgehensweise ans Eingemachte.

Die elfte und zwölfte Runde sollen schließlich die Entscheidung bringen, indem sie die Vor- und Nachteile des jeweiligen Frameworks herausstellen.

Nun muss ich nur noch kurz die vier Kontrahenten vorstellen. Die Runde wird durch Backbone eröffnet. Dieses Framework steht eher für solides Handwerk und Transparenz. Gefolgt von Ember.js, einer eleganteren Lösung, die versucht, dem Entwickler viel Arbeit abzunehmen. Im Anschluss daran lernen Sie React kennen, eine sehr leichtgewichtige Lösung zur Umsetzung von Frontend-lastigen Applikationen. Den Abschluss bildet AngularJS, das Web-Application-Framework, das uns Google beschert.

Backbone

Backbone ist ein relativ einfaches JavaScript-Framework. Das erklärte Ziel dieser Software ist es, Struktur in Applikationen zu bringen – nicht mehr, aber auch nicht weniger. Das merken Sie vor allem an den Features des Frameworks: Die wichtigsten Bestandteile sind Router, Models, Collections und Views. Alle Teile des Frameworks gruppieren sich um die Organisation und Anzeige von Daten.

Der Grundstein für Backbone.js wurde am 30. September 2010 mit einem initialen Commit in das GitHub Repository des Projekts gelegt. Seitdem floss die Arbeit von über 220 Contributors in über 2 600 Commits in das Projekt ein.

Das Projekt weist seit seiner Entstehung keine festgelegten Releasezyklen auf. Zwischen den einzelnen Versionen liegen zeitweise mehrere Monate. Zum Zeitpunkt der Erstellung dieses Artikels lag Backbone in der Version 1.1.2 vom 20. Februar 2014 vor.

Wie die meisten JavaScript-Frameworks ist auch Backbone ein Open-Source-Framework, das auf GitHub gehostet wird. Unter [1] können Sie auf den Quellcode und die gesamte Entwicklungshistorie des Projekts zugreifen. Das Projekt unterliegt der MIT-Lizenz. Sie können das Framework also bedenkenlos in Ihrem Projekt einsetzen, ohne dass für Sie weitere Kosten dadurch entstehen.

Die Dokumentation von Backbone ist unter [2] verfügbar. Die Seite ist recht einfach gehalten, beschreibt aber das verfügbare API und dessen Verwendung recht gut. Was in dieser Dokumentation allerdings zur Gänze fehlt, sind Vorschläge zum Aufbau einer Applikation, also wie der Quellcode am besten zu strukturieren ist und wie auch in größeren Applikationen eine gute Wartbarkeit erzielt werden kann. Allerdings gibt es Verweise auf eine Reihe von Tutorials, in denen Sie Ihr Wissen über Backbone weiter vertiefen können.

Backbone besteht im Kern aus Router, Models, Col­lec­tions und Views. Mit diesen Komponenten werden Sie hauptsächlich zu tun haben, wenn Sie eine Applikation mit diesem Framework erstellen. Der Router ist für die grundsätzliche Navigation in der Applikation zuständig. Hierbei können Sie wählen, ob Sie über PushState oder über Hash-Navigation navigieren möchten. Mit jedem URL können Sie eine Funktion assoziieren, der dann dafür verantwortlich ist, den jeweiligen Status der Applikation herzustellen. Einer der wichtigsten Teile des Status sind die Daten der Applikation: Sie werden im Normalfall in Objekten, den Models, vorgehalten. Models in Backbone besitzen vordefinierte Funktionen, die Sie zum Auslesen und Speichern der Daten benutzen können. Die Standardmethode zum Speichern ist REST. Die Visualisierung der Daten übernehmen die Views. Diese Objekte stellen zum einen die HTML-Objekte und Templates dar und zum anderen sämtliche Funktionen, die für die Interaktion des Benutzers mit der Applikation erforderlich sind. Die Collections sind schließlich Sammlungen von Models. Sie werden hauptsächlich verwendet, um Operationen auf mehrere Models anzuwenden. So werden vor allem Array-Operationen wie Suche, Sortierung, Map und Reduce angeboten.

Erstellen Sie Ihre Applikation mit Backbone, folgt sie in den meisten Fällen dem MVC-Pattern, wobei sowohl die Models als auch die Views den Vorgaben von Backbone folgen. Die Controller-Komponente entspricht dem Router, der dafür sorgt, dass die Views ihre Models kennen. Im Idealfall legen Sie die einzelnen Komponenten in separaten Dateien ab und strukturieren sie entsprechend der Features Ihrer Applikation in Unterverzeichnissen, sodass der Quellcode insgesamt besser wartbar wird.

Bevor Sie jedoch Ihre Applikation verwenden können, müssen Sie einige Abhängigkeiten erfüllen. Backbone benötigt als Basis jQuery und Underscore. Ist eine der beiden Bibliotheken nicht installiert, funktioniert Backbone.js nicht. jQuery wird dabei für DOM-Operationen und für die AJAX-Kommunikation mit dem Server benötigt, Underscore stellt Hilfsfunktionen zur Verfügung. So stammen viele der Array-Funktionen der Collections von Underscore, aber auch die Tem­plate-Engine von Underscore kann beim Rendering der Views verwendet werden.

Der Hype um Backbone legt sich langsam aber...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang