Client side MVC and Template Engine

Final Decision

• backbone.js
  • with handlebars

This page was taken from German MediaWiki and will be translated later

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:

1. Ansprechen der JSON-Schnittstelle des Backends
2. Neuzeichnung eines Elements, wenn sich das Model geändert hat, z.B. Model wurde serverseitig geändert
3. Benachrichtigung des Backends, wenn clientseitig das Model geändert hat
4. Lokalisierung (Englisch, Deutsch) //leicht selber zu bauen, daher kein Eingang in Bewertung
5. Validierung von Eingaben
6. es soll die Applikation leicht zu testen machen
7. Lesezeichen erstellen. z.B. eine spezielle Sicht auf die Mind-Map bookmarken

K.o.-Analyse:

Diese Frameworks koppeln zu viel Logik in die Templates:

1. http://en.wikipedia.org/wiki/AngularJS AngularJS
2. http://agilityjs.com/ Agility
3. http://batmanjs.org/ Batman
4. http://emberjs.com/ Ember.js ,
5. http://en.wikipedia.org/wiki/SproutCore SproutCore (SproutCore 2.0 = Ember.js)
6. 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:

1. http://www.activejs.org/ ActiveJS
2. https://github.com/ahe/choco Choco
3. http://www.bennadel.com/projects/cormvc-jquery-framework.htm CorMVC
4. https://github.com/paulca/eyeballs.js Eyeballs
5. http://jamal-mvc.com/ Jamal
6. http://code.google.com/p/trimpath/wiki/TrimJunction TrimJunction
7. http://qooxdoo.org/ qooxdoo

Diese Frameworks sind nicht oder nur umständlich zu integrieren

1. http://cappuccino.org/ Cappuccino (nutzt als Sprache Onjective-J)

Diese Frameworks besitzen zu wenig Features:

1. http://github.com/flatiron/director Director (nur Routing)
2. http://github.com/quirkey/sammy Sammyjs (kein Vergleich zu Backbone JS)
3. http://scaleapp.org/ scaleApp (Library für Aufteilung in Plugins)
4. http://www.breezejs.com/ Breeze nett für Änderungstracking und resets:
5. 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":

1. http://meteor.com/faq/what-is-meteor Meteor

Diese Frameworks haben quasi nur einen Entwickler und stehen auf zu wackligen Füßen:

1. https://github.com/PureMVC/puremvc-js-multicore-framework PureMVC JS

Gesamtliste

1. http://www.activejs.org/ ActiveJS
2. http://agilityjs.com/ Agility
3. http://en.wikipedia.org/wiki/AngularJS AngularJS
4. http://documentcloud.github.com/backbone/ Backbone.js
5. http://batmanjs.org/ Batman
6. http://www.breezejs.com/ Breeze
7. http://canjs.us/ CanJS nett bezüglich routing
8. http://cappuccino.org/ Cappuccino
9. https://github.com/ahe/choco Choco
10. http://www.bennadel.com/projects/cormvc-jquery-framework.htm CorMVC
11. http://github.com/flatiron/director Director
12. http://emberjs.com/ Ember.js
13. https://github.com/paulca/eyeballs.js Eyeballs
14. http://jamal-mvc.com/ Jamal
15. http://javascriptmvc.com/ JavaScriptMVC
16. http://knockoutjs.com/ knockout.js
17. http://meteor.com/faq/what-is-meteor Meteor
18. https://github.com/PureMVC/puremvc-js-multicore-framework PureMVC JS
19. http://github.com/quirkey/sammy Sammyjs
20. http://scaleapp.org/ scaleApp
21. http://spinejs.com/ Spine.js
22. http://en.wikipedia.org/wiki/SproutCore">SproutCore
23. http://code.google.com/p/trimpath/wiki/TrimJunction">TrimJunction
24. http://qooxdoo.org/">qooxdoo

Kandidaten

1. http://documentcloud.github.com/backbone/ Backbone.js
2. http://canjs.us/ CanJS nett bezüglich routing
3. http://javascriptmvc.com/ JavaScriptMVC
4. 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