nicht angemeldet
Hallo,
BACKBONE
Die derzeitige Applikation nutzt Backbone.js. An sich ein feines Projekt. Mir fehlen jedoch eindeutige Strukturen, wo was zu geschehen hat. Es wird zu wenig vorgeschrieben. Die Freiheiten fuehren leider dazu, dass jeder im Team "seine eigene Suppe kocht". Dies moechte ich verhindern.
Backbone ist eine winzige Bibliothek, kein Framework und keine Full-Stack-Lösung. Siehe dazu meine Präsentationen. Backbone kann höchstens einen Mosaikstein in einer Architektur darstellen. Dass ihr damit an Grenzen stößt, weil es euch wenig vorgibt und nicht skaliert – das versuche ich Leuten seit Jahren zu vermitteln. ;)
Wenn ihr an Backbone festhaltet, solltet ihr euch Thorax, Backbone.Marionette oder Chaplin.js anschauen und ein leistungsfähiges Entwicklungs- und Build-Environment wie z.B. oder Grunt, Brunch oder Ruby on Rails wählen.
Marionette hat wenig feste Vorgaben, es ist sehr offen und modular mit einer ganzen Reihe von wertvollen Architekturpatterns. Man muss diese Patterns nicht alle nutzen (Marionette Application, Modules, Router/Controller, Layouts/Regions, verschiedene Views, ferner Event Aggregators und Commands). Man sollte es aber, wenn man Marionette verwendet. Viele Patterns sind in separate Projekte ausgelagert (z.B. Bakbone.Wreqr), können also auch in Backbone-Projekten zum Einsatz kommen, in denen nicht Marionette verwendet wird.
Chaplin gibt einen relativ festen MVC-Kern vor, der Ruby on Rails zum Vorbild hat und die grundlegenden Abläufe in der App regelt. Sinn davon sind definierte Modul-Lifecycles und somit ein effizientes Speichermanagement. Das hat Marionette auch, es ist in Chaplin nur fest verdrahtet, man kommt also schwer drumherum (convention over configuration). Darüber hinaus bietet Chaplin viele Abstraktionen and Helferlein, ist aber bewusst nicht so modular und vielseitig wie Marionette. Chaplin zielt auf recht bestimmte Single-Page-Apps ab, deren Interface klassischen Websites ähnelt: Es gibt einen austauschbaren Hauptinhalt, der durch Controller repräsentiert wird.
Disclaimer: Ich bin ein Maintainer von Chaplin, habe aber auch mit Marionette gearbeitet und kann beides empfehlen. Beide sind immer noch Backbone-basiert, also musst du eruieren, ob sie für deine Ansprüche reichen.
EMBER
Hierfuer habe ich mir ember.js naeher angeschaut. Ich finde das Konzept sehr gelungen. Allerdings musste ich in zwei Wochen Evaluierung bereits meinen rudimentaeren Code auf drei verschiedene Versionen migrieren. Das liegt daran, dass ember.js noch sehr stark in der Entwicklung steckt. Und es ist recht unersichtlich, wann die final fertig sein wird.
Ember profitiert derzeit von einem Hype, ist im langfristigen Produktiveinsatz aber noch nicht verbreitet.
Im Gegensatz zu Backbone und Backbone-basierten Lösungen wird hier sofort sehr groß gedacht. Das erinnert mich an andere UI-Frameworks, die soviel Cleverness und Magie besitzen, dass man vor Bäumen den Wald nicht mehr sieht. Wer die angepriesenen »ambitionierten Webanwendungen« bauen will, muss sich erst einmal ambitioniert in Ember einarbeiten. Da ist Backbone in seiner Einfachheit (im Positiven wie im Negativen) kein Vergleich.
ANGULAR
Angular.js ist auch ein weit verbreitetes Framework. Allerdings finde ich die Loesungswege fuer Probleme umstaendlich. Auch werden die Verantwortlichkeiten - welche Komponente fuer was zustaendig ist, und wie diese hinreichend interagieren - nicht tiefgehend erklaert.
Das ist auch meine Auffassung. Angular eignet sich für einen ganz bestimmten Typ an Interfaces. Das sind stark Data-Binding-getriebene Formulare mit entsprechenden Logiken. Auf der Ebene der Anwendungsarchitektur (die z.B. Chaplin und Marionette adressieren) bietet mir Angular zu wenig.
BATMAN, METEOR
Beide Framework beduerfen einer eigenen Serverinstanz. Das beisst sich mit meinem angestrebten RESTfull-Konzept: Alle Datenzugriffe sollen ausschlieszlich ueber eine REST-API erfolgen - unabhaengig davon, welche Sprache/Technik/Server im Backend dafuer zustaendig ist.
Meteor zielt ebenfalls auf einen ganz bestimmten Anwendungstyp ab (Realtime-Datenübertragung), der bei dir nicht zu gegeben scheint – von der technischen Basis ganz abgesehen.
KNOCKOUT, CANJS, SPINE
Diese habe ich mir bisher noch nicht naeher angeschaut - habe das auf grund deren geringen Verbreitung etwas Bedenken.
Bei Knockout steht wieder das Data-Binding im Vordergrund, manche kombinieren es auch mit Backbone (Knockback). CanJS und Spine sind m.W. Backbone in grün, sie unterscheiden sich nur im Detail.
Grüße,
Mathias