Was sind die realen Stärken und Schwächen der vielen Frameworks, die auf backbone.js basieren? [geschlossen]

Ich hoffe, dass jemand seine Erfahrungen mit einigen der neuesten Backbone.js-Varianten teilen kann. Ich habe einige gute Erfahrungen mit Backbone / Unterstrich / Anforderung in mehreren Projekten und möchte den nächsten Schritt in Richtung fortschrittlicherer Lösungen für komplexe Anwendungsstrukturen machen.

Ich weiß, dass die folgenden Frameworks verfügbar sind:

• Marionette
• Geppetto (basierend auf Marionette)
• Chaplin , Chaplin - Chaplin-Boilerplate
• Wirbel
• LayoutManager
• Thorax
• Aura
• Luca
• Singool
• Rückstapel
• Backbone-Benutzeroberfläche

• Hulk

• Übrigens - ausgezeichneter Ausgangspunkt für Großprojekte

Und wahrscheinlich habe ich ein paar verpasst.

Es gibt eine kurze Einführung zu den Unterschieden hier:

• Speakerdeck Talk Link

aber es ist sehr allgemein. Ich habe mich gefragt, ob jemand mit diesen Frameworks seine Erfahrungen mit realen Anwendungen teilen kann.

Was ist der Vorteil einer Auswahl über die andere? Wann ist Marionette eine bessere Lösung als Chaplin oder warum sind Vetebrae beispielsweise für bestimmte Anwendungen besser?

Sicher, die offensichtliche Antwort lautet " Verwenden Sie das Beste für Ihre Bedürfnisse ", aber mir fehlt die Erfahrung mit diesen Frameworks, um deren Stärke / Zweck / Vorteile oder bevorzugte Szenarien zu kennen.

Vielen Dank!

Edit 1: diesen Beitrag gefunden: Backbone.Marionette vs Backbone-Boilerplate

Edit 2: Antwort von Mathias schafer (Chaplin) per Mail:

Kurz gesagt, die aktuelle Struktur entspricht in etwa der Version 1.0, da sie bereits in der Produktion verwendet wird. Wir planen nicht, große neue Funktionen hinzuzufügen oder API-Änderungen bis 1.0 zu brechen.

Marionette ist mit Sicherheit die umfassendste und stabilste Bibliothek überhaupt. Es behandelt verschiedene Aspekte der JS-App-Entwicklung mit Backbone. Zum Beispiel hat es eine starke Ansichtsebene, die das Backbone selbst vollständig leer lässt. Natürlich werden Sie feststellen, dass einige Aspekte Ihren Anforderungen nicht entsprechen und Sie möglicherweise das Bedürfnis verspüren, eine Struktur um Marionette herum aufzubauen.

Im Gegensatz dazu konzentriert sich Chaplin auf einen eher kleinen, aber sehr wichtigen Aspekt von Backbone-Apps, nämlich die gesamte App-Struktur und den Modullebenszyklus. In dieser Hinsicht ist Chaplin sehr opioniert und ähnelt eher einem Framework als einer Bibliothek (wie in „Ihr Code ruft eine Bibliothek auf, ein Framework ruft Ihren Code auf“). Chaplin bietet einige zentrale Klassen, die über einzelnen Anwendungsmodulen liegen und den gesamten App-Status steuern. Dies gibt Ihrer App eine konventionelle Struktur, wie es beispielsweise Ruby on Rails tut.

In Chaplin deklarieren Sie einige Routen, die Controllern zugeordnet sind, und Chaplin startet den Controller, sobald die Route übereinstimmt. Es kümmert sich auch um die Entsorgung alter Controller und das Ein- und Ausblenden von Hauptansichten, die ein Controller erstellen soll. Dies ist die Grundidee, aber Chaplin kümmert sich um die hässlichen Details, damit dies reibungslos verläuft.

Mit dieser Struktur gehen zwei Prinzipien einher: - Modularisierung, Entkopplung und Sandboxing - Modulübergreifende Kommunikation mit Publish / Subscribe und Mediator (s)

Natürlich sind diese Muster in der Welt der Softwareentwicklung nicht neu, und Chaplin ist nicht die einzige Bibliothek, die sie auf Backbone.js Apps anwendet.

Chaplin bietet auch Verbesserungen für die Ansichtsebene, zum Beispiel eine hochentwickelte CollectionView, aber insgesamt nicht so viel wie Marionette mit ihren Regionen und Layouts. Es ist jedoch relativ einfach, solche Metaklassen mit den von Chaplin Views bereitgestellten Mitteln zu schreiben.

Die meisten (alle?) Frameworks, die Sie betrachten, lösen dieselben Probleme, aber sie tun dies auf leicht unterschiedliche Weise mit leicht unterschiedlichen Zielen.

Ich denke, es ist fair zu sagen, dass all diese Projekte die Probleme in diesen Kategorien lösen würden:

• Stellen Sie sinnvolle Standardeinstellungen bereit
• Kesselschildcode reduzieren
• Stellen Sie die Anwendungsstruktur über den BackboneJS-Bausteinen bereit
• Extrahieren Sie Muster, die Autoren in ihren Apps verwenden

Marionette, die ich seit Dezember 2011 baue, hat auch einige sehr unterschiedliche Ziele und Ideale im Auge:

• Zusammengesetzte Anwendungsarchitektur
• Einfluss des Enterprise-Messaging-Musters
• Modularisierungsoptionen
• Inkrementelle Verwendung (keine Alles-oder-Nichts-Anforderung)
• Keine Server-Sperrung
• Machen Sie es sich einfach, diese Standardeinstellungen zu ändern
• Code als Konfiguration / Überkonfiguration

Ich sage nicht, dass keines der anderen Frameworks dieselben Ziele verfolgt. Aber ich denke, Marionettes Einzigartigkeit beruht auf der Kombination dieser Ziele.

Zusammengesetzte Anwendungsarchitektur

Ich habe mehr als 5 Jahre in verteilten Thick-Client-Softwaresystemen mit WinForms und C # gearbeitet. Ich habe Apps für Desktop, Laptop (Smart-Client), mobile Geräte und Webanwendungen erstellt, die alle einen Kernfunktionssatz gemeinsam nutzen und viele Male mit demselben Server-Back-End arbeiten. In dieser Zeit lernte ich den Wert der Modularisierung und ging sehr schnell einen Weg des Entwurfs zusammengesetzter Anwendungen.

Die Grundidee besteht darin, die Laufzeiterfahrung und den Prozess Ihrer Anwendung aus vielen kleineren, einzelnen Teilen zu "komponieren", die nicht unbedingt voneinander wissen. Sie registrieren sich beim gesamten zusammengesetzten Anwendungssystem und kommunizieren dann über verschiedene Mittel entkoppelter Nachrichten und Anrufe.

Ich habe in meinem Blog ein wenig darüber geschrieben und Marionette als zusammengesetzte Anwendungsarchitektur für Backbone vorgestellt:

• http://lostechies.com/derickbailey/2011/11/17/introduction-to-composite-javascript-apps/
• http://lostechies.com/derickbailey/2011/12/12/composite-js-apps-regions-and-region-managers/

Nachrichtenwarteschlangen / -muster

Dieselben verteilten Großsysteme nutzten auch Nachrichtenwarteschlangen, Unternehmensintegrationsmuster (Messaging-Muster) und Servicebusse, um die Nachrichten zu verarbeiten. Dies hatte vor allem einen enormen Einfluss auf meinen Ansatz zur entkoppelten Softwareentwicklung. Aus dieser Perspektive sah ich WinForms-Anwendungen mit einem einzigen Prozess im Speicher, und bald wurde meine serverseitige und Webanwendungsentwicklung davon beeinflusst.

Dies hat sich direkt darin niedergeschlagen, wie ich das Design von Backbone-Anwendungen betrachte. Ich stelle in Marionette einen Ereignisaggregator bereit, sowohl für das übergeordnete Anwendungsobjekt als auch für jedes Modul, das Sie in der Anwendung erstellen.

Ich denke an Nachrichten, die ich zwischen meinen Modulen senden kann: Befehlsnachrichten, Ereignismeldungen und mehr. Ich denke auch an die serverseitige Kommunikation als Nachrichten mit denselben Mustern. Einige der Muster haben bereits Eingang zu Marionette gefunden, andere noch nicht.

• http://lostechies.com/derickbailey/2011/07/19/references-routing-and-the-event-aggregator-coordinating-views-in-backbone-js/
• http://lostechies.com/derickbailey/2012/04/03/revisiting-the-backbone-event-aggregator-lessons-learned/
• http://lostechies.com/derickbailey/2009/12/23/understanding-the-application-controller-through-object-messaging-patterns/ (WinForms-Code, aber immer noch anwendbar)

Modularisierung

Die Modularisierung von Code ist enorm wichtig. Das Erstellen kleiner, gut gekapselter Pakete mit einem einzigartigen Fokus und genau definierten Ein- und Ausstiegspunkten ist ein Muss für jedes System von erheblicher Größe und Komplexität.

Marionette bietet Modularisierung direkt durch seine moduleDefinitionen. Aber ich erkenne auch, dass einige Leute RequireJS mögen und das nutzen wollen. Daher biete ich sowohl einen Standard-Build als auch einen RequireJS-kompatiblen Build an.

MyApp = new Backbone.Marionette.Application();

MyApp.module("MyModule", function(MyModule, MyApp, Backbone, Marionette, $, _){

  // your module code goes here

});

(Dafür ist noch kein Blog-Beitrag verfügbar)

Inkrementelle Verwendung

Dies ist eine der Kernphilosophien, die ich in jeden Teil von Marionette einbringe, den ich kann: keine "Alles-oder-Nichts" -Anforderung für die Verwendung von Marionette.

Das Backbone selbst verfolgt mit all seinen Bausteinobjekten einen sehr inkrementellen und modularen Ansatz. Sie können frei wählen, welche Sie wann verwenden möchten. Ich glaube fest an dieses Prinzip und bemühe mich sicherzustellen, dass Marionette genauso funktioniert.

Zu diesem Zweck sind die meisten Teile, die ich in Marionette eingebaut habe, dafür gebaut, allein zu stehen, mit den Kernstücken von Backbone zu arbeiten und noch besser zusammenzuarbeiten.

Beispielsweise muss fast jede Backbone-Anwendung eine Backbone-Ansicht an einer bestimmten Stelle auf dem Bildschirm dynamisch anzeigen. Die Apps müssen auch alte Ansichten schließen und den Speicher bereinigen, wenn eine neue eingerichtet wird. Hier kommt Marionette Regionins Spiel. Eine Region verarbeitet den Boilerplate-Code, mit dem Sie eine Ansicht erstellen, Rendering aufrufen und das Ergebnis für Sie in das DOM einfügen. Dann wird diese Ansicht geschlossen und für Sie bereinigt, vorausgesetzt, Ihre Ansicht verfügt über eine "Schließen" -Methode.

MyApp.addRegions({
  someRegion: "#some-div"
});

MyApp.someRegion.show(new MyView());

Sie müssen jedoch nicht die Ansichten von Marionette verwenden, um eine Region zu verwenden. Die einzige Voraussetzung ist, dass Sie sich irgendwann in der Prototypenkette des Objekts von Backbone.View aus erweitern. Wenn Sie eine closeMethode, eine onShowMethode oder andere bereitstellen , wird Marionette's Region sie zum richtigen Zeitpunkt für Sie aufrufen.

• http://lostechies.com/derickbailey/2011/12/12/composite-js-apps-regions-and-region-managers/
• http://lostechies.com/derickbailey/2011/09/15/zombies-run-managing-page-transitions-in-backbone-apps/

Keine Server-Sperre

Ich erstelle Backbone / Marionette-Apps auf einer Vielzahl von Servertechnologien:

• ASP.NET MVC
• Ruby on Rails
• Rubin / Sinatra
• NodeJS / ExpressJS
• PHP / Slim
• Java
• Erlang
• ... und mehr

JavaScript ist JavaScript, wenn es darum geht, in einem Browser ausgeführt zu werden. Serverseitiges JavaScript ist ebenfalls fantastisch, hat jedoch keinen Einfluss darauf, wie ich mein browserbasiertes JavaScript schreibe.

Aufgrund der Vielfalt der von mir erstellten Projekte und der von meinen Kunden verwendeten Back-End-Technologien kann und wird ich Marionette aus irgendeinem Grund nicht an einen einzelnen serverseitigen Technologie-Stack binden. Ich werde kein Boilerplate-Projekt bereitstellen. Ich werde kein Rubinjuwel oder ein npm-Paket zur Verfügung stellen. Ich möchte, dass die Leute verstehen, dass Marionette keinen bestimmten Back-End-Server benötigt. Es ist browserbasiertes JavaScript, und das Back-End spielt keine Rolle.

Natürlich unterstütze ich andere Menschen, die Pakete für ihre Sprache und ihren Rahmen anbieten. Ich liste diese Pakete im Wiki auf und hoffe, dass die Leute weiterhin mehr Pakete erstellen, wenn sie einen Bedarf sehen. Aber das ist Community-Unterstützung, keine direkte Unterstützung von Marionette.

• https://github.com/derickbailey/backbone.marionette/wiki/Available-packages

Ändern Sie einfach die Standardeinstellungen

In meinem Bestreben, den Code für das Boilerplate zu reduzieren und sinnvolle Standardeinstellungen bereitzustellen (eine Idee, die ich direkt vom LayoutManager von Tim Branyen "ausgeliehen" habe), erkenne ich die Notwendigkeit, dass andere Entwickler etwas andere Implementierungen verwenden als ich.

Ich biete Rendering basierend auf Inline- <script>Tags für Vorlagen an, wobei standardmäßig Underscore.js Vorlagen verwendet werden. Sie können dies jedoch ersetzen, indem Sie die Rendererund / oder TempalteCacheObjekte in Marionette ändern . Diese beiden Objekte bilden den Kern der Rendering-Funktionen, und es gibt Wiki-Seiten, die zeigen, wie Sie dies für bestimmte Template-Engines und verschiedene Arten des Ladens von Vorlagen ändern können.

Mit v0.9 von Marionette wird es noch einfacher. Wenn Sie beispielsweise die Verwendung von Inline-Vorlagenskriptblöcken durch vorkompilierte Vorlagen ersetzen möchten, müssen Sie im Renderer nur eine Methode ersetzen:

Backbone.Marionette.Renderer.render = function(template, data){
  return template(data);
};

Jetzt verwendet die gesamte Anwendung vorkompilierte Vorlagen, die Sie an das templateAttribut Ihrer Ansicht anhängen .

Ich biete sogar ein Marionette.Async-Add-On mit Version 0.9 an, mit dem Sie das asynchrone Rendern von Ansichten unterstützen können. Ich bin ständig bemüht, es so einfach wie möglich zu machen, das Standardverhalten in Marionette zu ersetzen.

Code als Konfiguration

Ich bin ein Fan von "Konvention über Konfiguration" in bestimmten Kontexten. Es ist eine leistungsstarke Methode, um Dinge zu erledigen, und Marionette bietet ein wenig davon - wenn auch nicht zu viel, ehrlich. Viele andere Frameworks - insbesondere LayoutManager - bieten mehr Konventionen über die Konfiguration als Marionette.

Dies geschieht mit Absicht und Absicht.

Ich habe genug JavaScript-Plugins, Frameworks, Add-Ons und Anwendungen erstellt, um zu wissen, wie schwierig es ist, Konventionen auf sinnvolle und schnelle Weise zum Laufen zu bringen. Dies kann mit Geschwindigkeit erfolgen, jedoch normalerweise auf Kosten einer Änderung.

Zu diesem Zweck verfolge ich Marionette als "Code als Konfiguration". Ich biete nicht viele "Konfigurations" -APIs an, in denen Sie ein Objektliteral mit statischen Werten bereitstellen können, die eine Reihe von Verhaltensweisen ändern. Stattdessen dokumentiere ich die Methoden, über die jedes Objekt verfügt - sowohl durch kommentierten Quellcode als auch durch die eigentliche API-Dokumentation -, um Ihnen zu erklären, wie Sie Marionette so ändern können, dass sie wie gewünscht funktioniert.

Durch die Bereitstellung einer sauberen und klaren API für die Marionettenobjekte schaffe ich eine Situation, in der das Ersetzen des Verhaltens eines bestimmten Objekts oder der Marionette als Ganzes relativ einfach und sehr flexibel ist. Ich opfere die "einfachen" Konfigurations-API-Aufrufe für die Flexibilität, Ihren eigenen Code bereitzustellen, damit die Dinge so funktionieren, wie Sie es möchten.

In Marionette finden Sie keine API "Konfigurieren" oder "Optionen". Sie werden jedoch eine große Anzahl von Methoden finden, die jeweils einem bestimmten Zweck dienen, mit sauberen Signaturen, die es einfach machen, die Funktionsweise von Marionette zu ändern.

Ich verwende derzeit das Backbone mit dem Layout-Manager-Modul und dem Lenker als Vorlagen-Engine und fand es sehr einfach, eine kleine Anwendung mit einem bereits vorhandenen Grails-Backend einzurichten. Bevor ich anfing, Layout Manager zu verwenden, las ich über Marionette und Chaplin und beide schienen mir wirklich mächtig, aber komplex zu sein. Dann erinnerte ich mich, warum ich ursprünglich backbone.js gewählt hatte: Einfachheit. All diese Frameworks fügen hinzu, was das Backbone vom Design her ausgelassen hat. Ich sage nicht, dass ein Framework schlecht ist, aber wenn ich etwas Komplexeres brauche, probiere ich andere Projekte wie ember.js oder sproutcore aus, da sie eine eindeutige Codebasis haben, die mit dem Ziel geschrieben wurde, dass ihre Entwickler dies tun. Hier haben wir Frameworks über einem anderen. Natürlich ist das Backbone ein Backbone nicht nur zum Erstellen von Anwendungen, sondern auch zum Schreiben einer leistungsstärkeren Bibliothek. Aber das einzige, was ich wirklich schlecht finde, ist die Ansichtsebene, da ein Layout-Manager fehlt und die Möglichkeit besteht, Ansichten zu verschachteln. Mit dem Layout-Manager ist diese Lücke recht gut gefüllt.

Meine Antwort auf Ihre Frage lautet also: Beginnen Sie mit der Verwendung von Backbone wie es ist und fragen Sie sich, was fehlt und was Sie von dem Framework erwartet haben. Wenn Sie feststellen, dass das Backbone zu viele Dinge auslässt, suchen Sie sie in den anderen Frameworks und wählen Sie das aus, das Ihren Anforderungen am nächsten kommt. Und wenn Sie immer noch nicht sicher sind, ist das Backbone vielleicht nichts für Sie und Sie müssen nach einer anderen Lösung suchen (ember.js, sproutcore, ExtJs, JavaScript MVC sind alle gut). Wenn Sie Erfahrung im Schreiben von Client-Apps haben, benötigen Sie nicht wirklich Erfahrung mit allen Frameworks, um das richtige auszuwählen (für Sie natürlich).

Ich habe die verschiedenen Frameworks untersucht, die mit Backbone.js erstellt wurden, und die Wirbel für ein Projekt bei HauteLook erstellt. Die Projektziele umfassten ... dynamisches Laden von Skripten, AMD-Modulformat, Abhängigkeitsmanagement, Erstellen mit meist Open Source-Bibliotheken, Organisieren von Code in Paketen, Optimieren und Erstellen für eine oder mehrere Einzelseiten-Apps, Hosten auf einem vollständig zwischengespeicherten Server, z. B. ohne Server -Seitiges Scripting, das nur eine API für Daten verwendet, und das lustigste für mich, verwenden verhaltensgesteuerte Entwicklung für das Projekt. Eine Beschreibung des Projekts finden Sie unter: http://www.hautelooktech.com/2012/05/24/vertebrae-front-end-framework-built-with-backbone-js-and-requirejs-using-amd/

Unser Problem:

Ausgewählte Bibliotheken (jQuery, Underscore.js, Backbone.js, RequireJS, Moustache) bieten Modulladen, Abhängigkeitsmanagement, Anwendungsstruktur (für Modelle, Sammlungen, Ansichten und Routen), asynchrone Interaktionen mit der API, verschiedene Dienstprogramme und Objekte zum Verwalten asynchroner Verhaltensweisen zB (Versprechen) Aufgeschobene, Rückrufe. Die verbleibende Logik zur Vervollständigung des Frameworks umfasst:

• ein Objekt (Modell) zum Verwalten des Status der einseitigen Anwendung;
• ein Layout-Manager zum Präsentieren, Anordnen / Übergehen und Löschen von Ansichten und
• Controller, die auf Routen reagieren, den Anwendungsstatus abrufen / festlegen und die Arbeit an den Layout-Manager übergeben.

Unsere Lösungen (implementiert in Wirbeln):

Anwendungsstatus-Manager -

Der Anwendungsmanager speichert Daten im Speicher und speichert Daten im Browserspeicher, um eine Ressource für allgemeine Daten / Metadaten bereitzustellen. Bietet auch Daten (Status) zum Rekonstruieren der Seitenaufrufe basierend auf vorherigen Interaktionen (z. B. ausgewählte Registerkarte, angewendete Filter). Der Anwendungsstatusmanager bietet eine Strategie für Ressourcen zum Abrufen des Status. Soll als Zustandsmaschine fungieren.

Layout Manager -

Der Layout-Manager verfügt über eine oder mehrere Ansichten sowie Dokumentziele (DOM) für jede (gerenderte) Ansicht. Eine Seite kann zwischen vielen Ansichten wechseln, sodass der Layout-Manager den Ansichtsstatus verfolgt, z. B. gerendert, nicht gerendert, angezeigt, nicht angezeigt. Sie können den Layout-Manager verwenden, um Ansichten, die ein Site-Besucher sehr wahrscheinlich anfordert, verzögert zu laden und (getrennte) Ansichten zu rendern, z. B. Registerkartenänderungen auf einer Seite. Der Übergang zwischen Ansichtszuständen wird von diesem Objekt verwaltet. Ein gesamtes Layout kann gelöscht werden, sodass Ansichtsobjekte und ihre Bindungen entfernt werden, wodurch diese Objekte für die Speicherbereinigung vorbereitet werden (wodurch Speicherlecks verhindert werden). Der Layout-Manager kommuniziert auch den Ansichtsstatus mit den Controllern.

Controller -

Ein Controller-Objekt wird von einer Route-Handler-Funktion aufgerufen und ist dafür verantwortlich, dass der relevante Status (Anwendungsmodelle) zum Generieren einer Seite (Layout) abgerufen wird (auch für das Festlegen des Status, wenn sich Routen ändern). Der Controller übergibt abhängige Daten (Modelle / Sammlungen) und erstellte Ansichtsobjekte für eine angeforderte Seite an den Layout-Manager. Als Nebeneffekt verhindert die Verwendung von Controllern, dass sich das Routenobjekt aufbläht und verheddert. Eine Route sollte einem Controller zugeordnet werden, der dann die Seitenansicht startet und die Routenbehandlungsfunktionen schlank hält.

Die Todos-App wird sowohl im Entwicklungsmodus gehostet als auch auf Heroku optimiert ...

• http://vertebrae-framework.herokuapp.com/
• http://vertebrae-optimized.herokuapp.com/

Viele der Konzepte in den anderen Frameworks sind entlehnt, z. B. die Notwendigkeit, Ansichten zu zerstören, um eine Vorschau von Speicherlecks anzuzeigen, wie von Derick Bailey hervorgehoben - http://lostechies.com/derickbailey/ ; der Layout Manager von Tim Branyen http://tbranyen.github.com/backbone.layoutmanager/

Zusammenfassend ist Backbone.js ein Werkzeug in Ihrer Anwendung. Die Backbone.js-Bibliothek bietet nicht die gesamte Architektur, die Sie zum Erstellen einer Anwendung benötigen, bietet jedoch hervorragende Interaktionen mit einer API und einer soliden Codestruktur für ... Ansichten (verhalten sich auch wie Controller) und Ihre Datenschichtmodelle und -sammlungen und schließlich Routen. Wir haben Wirbel gebaut, um die Ziele unseres Projekts zu erreichen, und beschlossen, den Code als Rahmen für andere zu extrahieren, um ihn zu verwenden, zu lernen oder was auch immer.

Die Antwort auf Ihre Frage lautet meiner Meinung nach, aus allen Frameworks zu lernen und das zu verwenden, was Sie benötigen, um Ihre Ziele zu erreichen. Wenn Sie feststellen, dass Ihre Projektziele eng mit einem der mit Backbone erstellten Frameworks übereinstimmen, ist dies großartig, ansonsten haben Sie Ihr eigenes Framework erstellt Es gibt großartige Beispiele, die von der Community geteilt werden. Oder wenn Sie sich in Richtung Ihrer Bewerbung etwas verloren fühlen, wählen Sie etwas, das mehr Meinung und Struktur hat, vielleicht Ember.js. Das Tolle ist, dass es eine gute Auswahl gibt, mit denen Sie mithilfe eines (MVX) MVC-ähnlichen Musters mit JavaScript codieren können.

Ich habe das Luca-Framework während meiner Arbeit bei BenchPrep entwickelt, wo wir damit mehrere große Apps für einzelne Seiten über der Bibliothek backbone.js entwickelt haben.

Ich habe einige Jahre zuvor mit ExtJS gearbeitet und meine Lieblingskonzepte aus diesem Framework gestohlen, z. B. die komponentengesteuerte Architektur, in der Sie Ihre Ansichten als eigenständige Komponenten entwickeln und sie dann mithilfe von Containeransichten mit anderen Komponenten zusammenfügen. Und da es stark auf der Konfiguration basiert, fühlt sich die Entwicklung einer App in Luca sehr danach an, ein Objekt mit JSON zu beschreiben.

Ein Vorteil dieses Ansatzes ist die Möglichkeit, Komponenten in mehreren Apps oder an verschiedenen Stellen in Ihrer App wiederzuverwenden, wobei die Erweiterung von Backbone nur geringfügige Änderungen erfordert. Es ist auch sehr einfach, mit vielen verschiedenen Layouts / Präsentationen von Komponenten zu experimentieren, indem nur geringfügige Änderungen an der JSON-Konfiguration vorgenommen werden.

Zusätzlich zu einer Vielzahl von Hilfs- / Dienstprogrammfunktionen bietet Luca Ships viele Backbone-Derivate auf höherer Ebene, die Sie auf jede erdenkliche Weise zusammensetzen können, um eine komplexe Benutzeroberfläche zu erstellen.

Ansichten, Komponenten, Container

• Erweitertes Modell, Ansicht, Sammlung, Router-Klassen
• Konfigurationsoptionen, die die Kommunikation zwischen Modellen, Sammlungen, Ansichten, der Anwendung und ihren jeweiligen Managern erleichtern.
• Container (Split- / Spaltenlayout, Rasterlayout, Registerkartenansicht, Karten- / Assistentenansicht)
• FormView mit allen Standardfeldkomponenten und Hilfsprogrammen für die Synchronisierung mit einem Backbone.Model
• GridView zum Generieren von scrollbaren Rasterelementen aus einer Luca.Collection
• CollectionView zum Generieren von Ansichten basierend auf einer Sammlung
• Symbolleisten / Schaltflächen

Twitter Bootstrap Styles und Markup kostenlos

• Luca spielt sehr gut mit dem Twitter Bootstrap Framework. Durch einfaches Setzen von Luca.enableBootstrap = true und Einbeziehen des CSS verwenden Ihre Komponenten (wie die Registerkartenansichten, Symbolleisten, Schaltflächen, Formulare, Felder, Raster usw.) automatisch Twitter Bootstrap-kompatible Markup- und CSS-Klassenkonventionen.
• Verwendet das Grid-System für das Layout und reagiert auf intelligente Weise auf die meisten Bootstrap-Basis-CSS-Klassen
• Die Komponenten Luca.Viewport und GridLayout sind so eingerichtet, dass sie mit den reaktionsschnellen, flüssigen oder statischen Grid-Systemen von Bootstrap funktionieren.
• Ziel ist es, eine Eins-zu-Eins-Übereinstimmung für Twitter-Bootstrap-Komponenten bereitzustellen, um sie als konfigurierbare Backbone-Ansichten darzustellen

Die Anwendungskomponente

• Die auf Backbone.Model basierende Zustandsmaschine bietet Getter / Setter-Methoden und Attributänderungsereignisse als Stil des Anwendungssteuerungsflusses
• Integrierte Controller-Komponente, die Seiten der App als Reaktion auf Backbone.Router- oder State Machine-Ereignisse ausblendet / anzeigt
• Der integrierte Sammlungsmanager, der die von Ihnen erstellten Sammlungen verfolgt, ermöglicht es Ihnen, sie zu erfassen, zu gruppieren und ihnen Standardparameter zuzuweisen
• Ein Socket Manager, der eine Abstraktionsschicht über Websocket-Diensten darstellt und Push so einfach wie Backbone.Event macht
• Ein Tastaturereignis-Router, der benannte Schlüsselereignisse für Komponenten auslöst, die auf solche Ereignisse reagieren möchten

Sammlungs- und Modellverbesserungen

• Sammlungen basieren auf Backbone-Abfragen , die eine Abfrageschnittstelle bieten, die mongoDb sehr ähnlich ist
• Aktivieren Sie einen lokalen Speicher Backbone.sync, indem Sie einfach collection.localStorage = true festlegen
• Automatische Auffüllung von Sammlungen, deren Daten beim Laden der Seite gebootet werden
• zwischengespeicherte Methoden / berechnete Eigenschaften. Zwischenspeichern des Ergebnisses von Erfassungsmethoden und Ablaufen des Caches als Reaktion auf das Ändern / Hinzufügen / Entfernen von Ereignissen in der Sammlung oder ihren Modellen
• berechnete Eigenschaften für die Modelle. Erstellen Sie Attribute basierend auf komplexen Funktionen und aktualisieren Sie den berechneten Wert automatisch als Reaktion auf Änderungen

Ereignisse und Haken

Luca-Komponenten sind liberaler in Bezug auf die Ereignisse, die sie auslösen, als die Standard-Backbone-Komponenten. Sie senden Ereignisse wie vor: initialisieren, nach: initialisieren, vor: rendern, nach: rendern, aktivieren, zuerst: aktivieren, deaktivieren, zuerst: deaktivieren, und dies ermöglicht es Ihnen, das Verhalten Ihrer Komponenten genauer abzustimmen. Wenn Sie in Ihrer Ansicht ein Ereignis in der Eigenschaft @hooks definieren, wird automatisch eine ähnlich benannte Funktion für Sie aufgerufen, falls vorhanden. Dies verhindert viel Rückrufcode, was die Lesbarkeit verbessert.

Sie können die Luca.Events-Klasse auch so konfigurieren, dass die Ereignisse in einem globalen Publish / Subscribe-Kanal veröffentlicht werden. Dies erleichtert das Erstellen einer großen Anwendung und unterstützt die Kommunikation zwischen Modulen.

Der Rubin Edelstein

Luca wurde speziell für die Arbeit mit Rails- und Sinatra-APIs entwickelt und ist daher derzeit für einen bestimmten Stack optimiert, bindet Sie jedoch in keiner Weise an einen bestimmten Server.

Luca wird als Teil eines Ruby Gems geliefert, das für die Arbeit an der Asset-Pipeline konfiguriert ist, oder als herunterladbare JS-Datei.

Sie müssen weder Rails noch Sinatra verwenden. Aber wenn Sie das tun, habe ich viele nützliche Dinge aufgenommen:

• Dateien mit der Erweiterung .luca werden als HAML mit Variableninterpolation im JST-Stil verarbeitet. (entspricht .jst.ejs.haml) durch die Asset-Pipeline
• Ein Testgeschirr für Browser- oder kopflose Jasmine-basierte Unit-Tests zusammen mit vielen Backbone- und Underscore-Testhelfern.
• Ein API-Endpunkt für das mit Luca gelieferte Entwicklungstoolset (dazu später mehr)
• Ein API-Endpunkt, mit dem Sie Redis als schemenlose Speicher-Engine für Luca.Collection mit minimaler Konfiguration verwenden können

Die Entwicklungswerkzeuge

• Luca-Anwendungen können eine Coffeescript-Konsole im Browser mit Luca-spezifischen Hilfsprogrammen und Befehlen aktivieren, die beim Überwachen, Überprüfen und Debuggen von Luca-Anwendungen und -Komponenten helfen

• Mit Hilfe des Rails Gem und des CodeMirror-basierten Komponenteneditors von Luca können Sie den Quellcode des Luca Framework sowie die anwendungsspezifischen Komponenten mithilfe von Coffeescript direkt im Browser bearbeiten. Sie erhalten sofortiges Feedback als Reaktion auf Ihre Änderungen, wobei die Instanzen der betroffenen Objekte mit dem aktualisierten Prototyp aktualisiert werden, und Sie können Ihre Änderungen auf der Festplatte speichern.

• Der Komponententester ist eine Live-Sandbox zum isolierten Spielen mit den Komponenten, aus denen Ihre Anwendung besteht. Es bietet Ihnen Tools zum Ändern des Prototyps der Komponente, zum Einrichten ihrer Abhängigkeiten und zum Konfigurieren der Komponente. Die Komponente wird bei jeder Bearbeitung sofort neu gerendert. Sie können das von der Komponente generierte Markup sowie das CSS direkt im Browser anzeigen und bearbeiten und Ihre Änderungen sofort anzeigen. Dies macht es zu einem sehr wertvollen Experimentierwerkzeug.

• Der Komponententester wird in Kürze in Jasmine integriert, sodass Sie die Ergebnisse Ihrer Komponententests in Echtzeit anzeigen können, während Sie deren Code bearbeiten

Luca ist in Arbeit, verfügt jedoch über eine stabile API (noch nicht 1.0) und wurde in mehreren großen Produktions-Apps verwendet. Es ist definitiv ein sehr einfühlsames Framework, aber ich arbeite daran, es modularer zu gestalten. Ich arbeite aktiv an der Dokumentation und den Beispielkomponenten.

Ich bin Mitautor von Chaplin und habe einen ausführlichen Vergleich zwischen Chaplin.js und Marionette.js geschrieben:

http://9elements.com/io/index.php/comparison-of-marionette-and-chaplin/

Dies ist kein „Shootout“, sondern versucht, beide Ansätze ausgewogen zu erklären.