nicht angemeldet
JavaScript SPA-Frameworks
Hallo allerseitsm,
ich bin gerade bei der Evaluierung von JavaScript Single-Page-Application Frameworks.
Meine Anforderungen sind:
- RESTful data layer (wie zb ember-data)
- MV*-Structure
- Dynamic Routes
- Testing-support
- Coding by convention
- SEO-Unterstuetzung
- Vorgeschriebene Strukturen
- Browser-History-Support
- Komplette API-Dokumentation
- Production-ready
- gute Community
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.
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.
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. Wohlbemerkt ist das nur meine eigene Meinung.
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.
KNOCKOUT, CANJS, SPINE
Diese habe ich mir bisher noch nicht naeher angeschaut - habe das auf grund deren geringen Verbreitung etwas Bedenken.
Hat einer von euch hier tiefergehende Erfahrungen in SPA-Frameworks und kann mir ggfs. eines empfehlen (oder auch abraten), welches nicht in meiner Liste vorhanden ist?
Hier mal ein Link zu einem interessanten Blogpost von Steven Anderson - Core-Entwickler von Knockout.js - ueber die "Throne of JS"-Konferenz von 2012.
Vielen Dank,
Kris
-
BACKBONE
Die Freiheiten fuehren leider dazu, dass jeder im Team "seine eigene Suppe kocht". Dies moechte ich verhindern.Warum legt ihr nicht selber weitere Coding-Guidelines fest? Oder bedient euch bei anderen?
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.Was stellst du dir denn unter "Dynamic Routes" vor? Routing ist ebenfalls Serversache.
Defacto glaube ich, du wirst nie ein Framework finden, das deinen Wünschen zu 110% entspricht. Wähle das kleinste Übel. http://jster.net/ bietet eine gute Anlaufstelle, um sich nach JS-Frameworks umzusehen.
-
Warum legt ihr nicht selber weitere Coding-Guidelines fest?
Meiner Erfahrung nach klappt so etwas nicht - oder zumindest sehr selten. Entweder weil der Teamlead ausgetauscht wird, oder die Entwickler, oder das Wiki mit dem Dokument oder oder.. besser ist es immer per Definition vorgesetzte Strukturen zu haben.
Oder bedient euch bei anderen?
Library-Empfehlungen hierzu?
Was stellst du dir denn unter "Dynamic Routes" vor? Routing ist ebenfalls Serversache.
zB aehnlich wie bei ember.js.
http://jster.net/ bietet eine gute Anlaufstelle, um sich nach JS-Frameworks umzusehen.
Danke.
-
Meiner Erfahrung nach klappt so etwas nicht - oder zumindest sehr selten. Entweder weil der Teamlead ausgetauscht wird, oder die Entwickler, oder das Wiki mit dem Dokument oder oder.. besser ist es immer per Definition vorgesetzte Strukturen zu haben.
Also gerade nicht "convention over configuration"?
Oder bedient euch bei anderen?
Library-Empfehlungen hierzu?Ich persönlich versuche mich an die Google-Coding-Guidelines zu halten. Einfach, weil ich schon vorher einen ähnlichen Schreibstil entwickelt habe.
Das sind allerdings nur Basis-Javascript Richtlinien, gewisse Frameworks erfordern oft zusätzliche Regeln.Was stellst du dir denn unter "Dynamic Routes" vor? Routing ist ebenfalls Serversache.
zB aehnlich wie bei ember.js.Ah okay, habe noch nicht mit ember.js gearbeitet. Für alle, denen es genauso geht, hier ist eine gute Einführung: https://gist.github.com/2728699
Ergibt natürlich Sinn, immerhin sprechen wir über Single Page Applications.-
Also gerade nicht "convention over configuration"?
Naja, habe mich wohl etwas lasch ausgedrueckt :)
Wenn eine Technik/Software/whatsoever bereits eine vorgegebene Struktur mit sich bringt, so wird diese a) kontinuierlicher eingehalten (da es evtl. ueberhaupt keine andere Wege der Implementierungen gibt) und b) ist die Einarbeitungszeit neuer Entwickler ueberschaubarer, ggfs. kennen sie sich mit dem Framework gar bereits aus.Ich persönlich versuche mich an die Google-Coding-Guidelines zu halten.
Guter Link - kannte ich noch nicht.
Ergibt natürlich Sinn, immerhin sprechen wir über Single Page Applications.
Wie ich anfangs schrieb gefaellt mir von ember.js sehr viel. Zu schade, dass die noch nicht etwas weiter sind.
-
Also gerade nicht "convention over configuration"?
Naja, habe mich wohl etwas lasch ausgedrueckt :)
Wenn eine Technik/Software/whatsoever bereits eine vorgegebene Struktur mit sich bringt, so wird diese a) kontinuierlicher eingehalten (da es evtl. ueberhaupt keine andere Wege der Implementierungen gibt)Naja, das ist sehr naiv, aber ich verstehe den Kern deiner Aussage ;)
Ergibt natürlich Sinn, immerhin sprechen wir über Single Page Applications.
Wie ich anfangs schrieb gefaellt mir von ember.js sehr viel. Zu schade, dass die noch nicht etwas weiter sind.Auf github gibt es bereits ein stable release, die Frage ist natürlich, wie weit es hinter der Version, mit der du gearbeitet hast, hinterher hängt.
-
Naja, das ist sehr naiv, aber ich verstehe den Kern deiner Aussage ;)
Naiv.. so so :-)
Auf github gibt es bereits ein stable release, die Frage ist natürlich, wie weit es hinter der Version, mit der du gearbeitet hast, hinterher hängt.
Ja, aber in der 0.9er ist noch nicht das v2-Routing aktiv, und es wird noch mit outlets gearbeitet.
-
-
Wenn eine Technik/Software/whatsoever bereits eine vorgegebene Struktur mit sich bringt, so wird diese a) kontinuierlicher eingehalten (da es evtl. ueberhaupt keine andere Wege der Implementierungen gibt) und b) ist die Einarbeitungszeit neuer Entwickler ueberschaubarer, ggfs. kennen sie sich mit dem Framework gar bereits aus.
Aus diesem Grund verwenden wir CoffeeScript, den ECMAScript 5 Strict Mode, AMD/Require.js/Almond.js/R.js, die Template-Sprache HAML Coffee zusammen mit der Rails Asset-Pipeline. Für serverseitige Templates werden ebenfalls HAML, für CSS wird Sass/Compass verwendet.
Das sind jetzt alles Techniken, die erst einmal nicht zusammenhängen, aber sie bilden zusammen mit jQuery, Backbone.js und Chaplin/Marionette einen robusten Stack für Single-Page-Apps, der einem gute Defaults vorgibt, Regeln auferlegt und Komfort bietet.
Es kommt eben nicht nur auf den Wahl des JavaScript-MVC-Stacks an (z.B. Backbone + Chaplin + weitere Plugins), sondern auf den gesamten Entwicklungsstack.
Mathias
-
-
-
-
-
Hi,
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.Dazu gibt's Chaplin.js, das genau das Ziel verfolgt, gewisse Strukturen für Backbone-Applikationen vorzugeben.
Viele Grüße,
Flo-
Hi Flo,
Dazu gibt's Chaplin.js, das genau das Ziel verfolgt, gewisse Strukturen für Backbone-Applikationen vorzugeben.
Vielen Dank fuer den Link!
Grusz,
Kris
-
-
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-
Hallo,
[..]
Vielen Dank fuer deine Einschaetzung der Thematik.
Dass der Beitrag von _dir_ kommt unterstreicht die Relevanz.Ich denke, ich werde mir chaplin tatsaechlich mal naeher anschauen. Aber ich hatte auch schon den Verdacht, dass es keine out-of-the-box Loesung geben wird. Von daher muss ich mir jede einzelne Komponente wohl genauer Anschauen und die Libraries kombinieren, die meinen Anspruechen individuell am gerechtesten werden.
Vielen Dank auf jeden Fall,
Kris
-