Client side MVC and Template Engine

Präambel Das Arbeiten mit der Mindmap Mind-Map in der Webansicht soll auf einer einzigen HTML-Seite geschehen, die nie neu geladen wird, da andererseits der Nutzer zu häufig warten muss. Google Docs nutzt diese Technik. Ein Framework für eine single-page application soll uns in folgenden Punkten unterstützen: Ansprechen der JSON-Schnittstelle des Backends Neuzeichnung eines Elements, wenn sich das Model geändert hat, z.B. Model wurde serverseitig geändert Benachrichtigung des Backends, wenn clientseitig das Model geändert hat Lokalisierung (Englisch, Deutsch) //leicht selber zu bauen, daher kein Eingang in Bewertung Validierung von Eingaben es soll die Applikation leicht zu testen machen Lesezeichen erstellen. z.B. eine spezielle Sicht auf die Mind-Map bookmarken K.o.-Analyse: Diese Frameworks koppeln zu viel Logik in die Templates: http://en.wikipedia.org/wiki/AngularJS AngularJS http://agilityjs.com/ Agility http://batmanjs.org/ Batman http://emberjs.com/ Ember.js , http://en.wikipedia.org/wiki/SproutCore SproutCore (SproutCore 2.0 = Ember.js) http://knockoutjs.com/ knockout.js Regelmäßige Wartung ist notwendig bezüglich neuer Browser Versionen und das Einbringen von HTML5 Features. Diese Frameworks wurden seit einem Jahr nicht mehr gewartet: http://www.activejs.org/ ActiveJS https://github.com/ahe/choco Choco http://www.bennadel.com/projects/cormvc-jquery-framework.htm CorMVC https://github.com/paulca/eyeballs.js Eyeballs http://jamal-mvc.com/ Jamal http://code.google.com/p/trimpath/wiki/TrimJunction TrimJunction http://qooxdoo.org/ qooxdoo Diese Frameworks sind nicht oder nur umständlich zu integrieren http://cappuccino.org/ Cappuccino (nutzt als Sprache Onjective-J) Diese Frameworks besitzen zu wenig Features: http://github.com/flatiron/director Director (nur Routing) http://github.com/quirkey/sammy Sammyjs (kein Vergleich zu Backbone JS) http://scaleapp.org/ scaleApp (Library für Aufteilung in Plugins) http://www.breezejs.com/ Breeze nett für Änderungstracking und resets: http://www.breezejs.com/documentation/change-tracking http://www.breezejs.com/documentation/change-tracking, nett für Validierung Diese Frameworks sind noch unter "rapid development": http://meteor.com/faq/what-is-meteor Meteor Diese Frameworks haben quasi nur einen Entwickler und stehen auf zu wackligen Füßen: https://github.com/PureMVC/puremvc-js-multicore-framework PureMVC JS Gesamtliste http://www.activejs.org/ ActiveJS http://agilityjs.com/ Agility http://en.wikipedia.org/wiki/AngularJS AngularJS http://documentcloud.github.com/backbone/ Backbone.js http://batmanjs.org/ Batman http://www.breezejs.com/ Breeze http://canjs.us/ CanJS nett bezüglich routing http://cappuccino.org/ Cappuccino https://github.com/ahe/choco Choco http://www.bennadel.com/projects/cormvc-jquery-framework.htm CorMVC http://github.com/flatiron/director Director http://emberjs.com/ Ember.js https://github.com/paulca/eyeballs.js Eyeballs http://jamal-mvc.com/ Jamal http://javascriptmvc.com/ JavaScriptMVC http://knockoutjs.com/ knockout.js http://meteor.com/faq/what-is-meteor Meteor https://github.com/PureMVC/puremvc-js-multicore-framework PureMVC JS http://github.com/quirkey/sammy Sammyjs http://scaleapp.org/ scaleApp http://spinejs.com/ Spine.js http://en.wikipedia.org/wiki/SproutCore">SproutCore http://code.google.com/p/trimpath/wiki/TrimJunction">TrimJunction http://qooxdoo.org/">qooxdoo Kandidaten http://documentcloud.github.com/backbone/ Backbone.js http://canjs.us/ CanJS nett bezüglich routing http://javascriptmvc.com/ JavaScriptMVC http://spinejs.com/ Spine.js Gegenüberstellung und Fazit Aufgrund der Verwendung von JSPlumb, einer eigenen Datenstruktur und dem flexibilitäts-bedürftigen Anwendungsfall in diesem Projekt ist es sinnvoll, eine Library anstelle eines Frameworks zu verwenden. Nähere Erläuterung: Libraries können in existierende Architekturen einfacher eingebracht bzw. mit diesen kombiniert werden. Frameworks hingegen geben die Architektur vor und schränken somit stark ein. Aufgrund dieser Tatsache werden Ember, AngularJS, Batman, Meteor und JavascriptMVC hier nicht weiter betrachtet.

In der engeren Auswahl stehen somit backbone.js, Spine und canjs. Im Folgenden werden Vor- und Nachteile kurz aufgeführt.

backbone.js

• flexibler hinsichtlich der Templating-Engine, da es keine Build-In-Engine gibt.
• die am meisten bekannte und am meisten eingesetzte Library (tutorialize.me, DocumentCloud, official.fm, CloudApp, BitTorrent, Nike+, backstitch, a.s.o.)
• verwendet Features von underscrore.js, welches wir ebenfalls gerne verwenden würden.
• aktive extension-community (Marionette, Chaplin, Aura, Thorax, etc.)

Spine

• geschrieben in coffeescript und sehr schlank

• Es gibt kein Äquivalent zu den Collections in backbone.js

canjs

• Vergleichsweise weit weniger bekannt und eingesetzt.

• Bietet viele Features bei verhältnissmäßig wenig Code.
• unterstützt Handlebars und - somit logischerweise auch - Mustache

Da sie an Vorteilen überwiegt und weiterhin im Team bereits positive Erfahrungen mit backbone.js gesammelt wurden, fällt die Wahl auf eben jene Library. Auswahl einer passenden Templating-Engine An dieser Stelle soll eine - zu backbone.js passende - Templating-Engine ausgewählt werden. Jade, handlebars.js, trancparancy und pure haben sich während der Recherche als sinnvolle Kandidaten herausgestellt und werden im Folgenden kurz gegenübergestellt: jade (http://jade-lang.com/)

• schlank

• relativ viel Logik in den Templates

handlebars (http://handlebarsjs.com/)

• relativ strikte Trennung zwischen HTML und logik
• findet häufig Verwendung in Kombination mit backbone.js
• unterstützt mustache (und somit mustache features)
• ermöglicht ein sehr geringes, gesundes Maß an logik in den Templates. (Folge: Code kann schneller geschrieben werden und verkürzt sich)

trancparancy ( https://github.com/leonidas/transparency/)

• strikte Trennung zwischen HTML und Logik
• vergleichsweise schnell gerendert (DOM-based vs. String-based)

• Erstellung der DOM-Element kann teilweise umständlich werden, da keine einfachen Anweisungen wie if-clauses ausgeführt werden können

pure (http://beebole.com/pure/documentation/get-started/)

• strikte Trennung zwischen HTML und Logik
• vergleichsweise schnell gerendert (DOM-based vs. String-based)

• Erstellung der DOM-Element kann teilweise umständlich werden, da keine einfachen Anweisungen wie if-clauses ausgeführt werden können

[Endgültige Entscheidung fällt nach interner Absprache.]