web-dev-qa-db-fra.com

Quelles sont les forces et les faiblesses réelles des nombreux cadres basés sur backbone.js?

Espérons que quelqu'un pourra partager son expérience des dernières variantes de backbone.js. J'ai plusieurs bonnes expériences avec backbone/underscore/require dans plusieurs projets et j'aimerais passer à l'étape suivante vers des solutions plus avancées pour une structure d'application complexe.

Je sais que les cadres suivants sont disponibles:

Et probablement j'en ai manqué quelques-uns.

Il y a une brève introduction sur les différences ici:

mais c'est très général. Je me demandais si quelqu'un pouvait partager son expérience avec des applications réelles utilisant ces frameworks.

Quel est l'avantage de choisir l'un par rapport à l'autre? Quand la marionnette sera-t-elle une meilleure solution par rapport au chaplin ou pourquoi la vetebre est-elle meilleure pour certaines applications, par exemple.

Bien sûr, la réponse évidente sera " utilisez ce qui convient le mieux à vos besoins ", mais je manque d'expérience avec ces frameworks pour connaître leur force/but/avantages ou scénarios préférés.

Merci!

Edit 1: a trouvé cet article: Backbone.Marionette vs Backbone-Boilerplate

Edit 2: Réponse de Mathias schafer (Chaplin) par courrier électronique:

En bref, la structure actuelle est proche de la version 1.0 car elle est déjà utilisée en production. Nous n’envisageons pas d’ajouter de grandes nouvelles fonctionnalités ou d’interrompre les changements d’API avant la 1.0.

Marionette est à coup sûr la bibliothèque la plus complète et la plus stable du marché. Il aborde plusieurs aspects du développement d'applications JS avec Backbone. Par exemple, il a une couche de vision forte que Backbone laisse complètement vide. Bien sûr, vous constaterez que certains aspects ne répondent pas à vos exigences et vous pourriez ressentir le besoin de mettre en place une structure autour de Marionette.

En revanche, Chaplin se concentre sur un aspect plutôt petit, mais très important, des applications Backbone, à savoir la structure globale des applications et le cycle de vie des modules. À cet égard, Chaplin est très opionate et ressemble plus à un framework qu’à une bibliothèque (comme dans "votre code appelle une bibliothèque, un framework appelle votre code"). Chaplin fournit des classes centrales qui reposent sur des modules d'application individuels et contrôlent l'état général de l'application. Cela donne à votre application une structure conventionnelle telle que Ruby sur Rails le fait par exemple).

Dans Chaplin, vous déclarez certaines routes mappées aux contrôleurs et Chaplin démarre le contrôleur une fois que la route correspond. Il s’occupe également de la disposition des anciens contrôleurs, ainsi que de la visualisation et du masquage des vues principales qu’un contrôleur est censé créer. C’est l’idée de base, mais Chaplin s’occupe des moindres détails pour que tout se passe bien.

Deux principes sont associés à cette structure: - Modularisation, découplage et sandboxing - Communication entre modules à l'aide de Publier/Souscrire et de Médiateur (s)

Bien entendu, ces modèles ne sont pas nouveaux dans le monde du développement logiciel et Chaplin n'est pas la seule bibliothèque qui les applique aux applications Backbone.js.

Chaplin apporte également des améliorations à la couche Vue, par exemple une CollectionView très sophistiquée, mais pas autant que Marionette avec ses régions et ses mises en forme. Mais il est relativement facile d’écrire ces méta-classes en utilisant les moyens fournis par Chaplin Views.

backbone.jsjavascript-framework
186
danikoren

La plupart des frameworks que vous envisagez résolvent les mêmes problèmes, mais ils le font de manières légèrement différentes avec des objectifs légèrement différents.

Je pense qu'il est juste de dire que tous ces projets résoudraient les problèmes dans ces catégories:

  • Fournir un ensemble raisonnable de valeurs par défaut
  • Réduire le code standard
  • Fournir une structure d'application au-dessus des blocs de construction BackboneJS
  • Extraire les modèles que les auteurs utilisent dans leurs applications

Marionette, que je construis depuis décembre 2011, a également quelques objectifs et idéaux bien distincts:

  • Architecture d'application composite
  • Influence du modèle de messagerie d'entreprise
  • Options de modularisation
  • Utilisation incrémentielle (pas d'exigence du tout ou rien)
  • Pas de blocage du serveur
  • Rendez-le facile pour changer ces valeurs par défaut
  • Code comme configuration/sur configuration

Je ne dis pas qu'aucun des autres cadres n'a les mêmes objectifs. Mais je pense que l'unicité de Marionette vient de la combinaison de ces objectifs.

Architecture d'applications composites

J'ai travaillé pendant plus de 5 ans dans des systèmes logiciels distribués à clients lourds utilisant WinForms et C #. J'ai créé des applications pour les ordinateurs de bureau, les ordinateurs portables (smart-clients), les appareils mobiles et les applications Web, partageant toutes un ensemble fonctionnel de base et fonctionnant plusieurs fois avec le même serveur dorsal. Pendant ce temps, j'ai appris la valeur de la modularisation et très rapidement je me suis orienté vers la conception d'applications composites.

L'idée de base est de "composer" l'expérience utilisateur et le traitement de votre application à partir de nombreuses pièces individuelles plus petites qui ne se connaissent pas nécessairement. Ils s'enregistrent eux-mêmes auprès de l'ensemble du système d'application composite, puis communiquent par divers moyens de messages et d'appels découplés.

J'ai écrit un peu à ce sujet sur mon blog en présentant Marionette en tant qu'architecture d'application composite pour Backbone:

Files d'attente de messages/modèles

Les mêmes systèmes distribués à grande échelle ont également tiré parti de la mise en file d'attente des messages, des modèles d'intégration d'entreprise (modèles de messagerie) et des bus de service pour gérer les messages. Ceci, plus que toute autre chose, a eu une influence considérable sur mon approche du développement logiciel découplé. De ce point de vue, j’ai commencé à voir les applications WinForms à mémoire unique, en mémoire, et bientôt, le développement de mes applications côté serveur et Web a pris toute son influence.

Cela s'est directement traduit par la façon dont je regarde la conception d'applications Backbone. Je fournis un aggrégateur d'événements dans Marionette, à la fois pour l'objet Application de haut niveau et pour chaque module créé dans l'application.

Je pense aux messages que je peux envoyer entre mes modules: messages de commande, messages d'événement, etc. Je pense également à la communication côté serveur en tant que messages avec ces mêmes modèles. Certains modèles ont déjà fait leur apparition chez Marionette, mais d'autres pas encore.

La modularisation

La modularisation du code est extrêmement importante. La création de petits packages bien encapsulés, concentrés sur des points d'entrée et de sortie bien définis, est indispensable pour tout système de taille et de complexité importantes.

Marionette fournit la modularisation directement à travers ses module définitions. Mais je reconnais aussi que certaines personnes aiment RequireJS et veulent l'utiliser. Je fournis donc à la fois une version standard et une version compatible RequireJS.


MyApp = new Backbone.Marionette.Application();

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

  // your module code goes here

});

(Aucun article de blog disponible pour cela, pour le moment)

Utilisation incrémentielle

C’est l’une des philosophies fondamentales de Marionette dans toutes les parties de Marionette: aucune condition préalable à l'utilisation de Marionette "tout ou rien".

Backbone lui-même adopte une approche très progressive et modulaire avec tous ses objets de construction. Vous êtes libre de choisir ceux que vous souhaitez utiliser, quand. Je crois fermement en ce principe et m'efforce de faire en sorte que Marionette fonctionne de la même manière.

À cette fin, la majorité des pièces que j'ai intégrées à Marionette sont conçues pour fonctionner de manière autonome, pour travailler avec les éléments centraux de Backbone et pour encore mieux travailler ensemble.

Par exemple, presque toutes les applications Backbone doivent afficher dynamiquement une vue Backbone à un endroit particulier de l'écran. Les applications doivent également gérer la fermeture des anciennes vues et le nettoyage de la mémoire lorsqu'un nouveau est mis en place. C'est ici que Region de Marionette entre en jeu. Une région gère le code général de prise de vue, d'appel de rendu et d'insertion du résultat dans le DOM pour vous. Ensuite, fermez cette vue et nettoyez-la pour vous, à condition que votre vue dispose d'une méthode "proche".


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

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

Mais vous n'êtes pas obligé d'utiliser les vues de Marionette pour utiliser une région. La seule exigence est que vous étendiez à partir de Backbone.View à un moment donné de la chaîne de prototypes de l'objet. Si vous choisissez de fournir une méthode close, une méthode onShow ou d'autres méthodes, Marionette's Region l'appellera au bon moment.

Pas de blocage du serveur

Je crée des applications Backbone/Marionette au-dessus d'une grande variété de technologies de serveur:

  • ASP.NET MVC
  • Rubis sur rails
  • Ruby/Sinatra
  • NodeJS/ExpressJS
  • PHP/Slim
  • Java
  • Erlang
  • ... et plus

JavaScript est JavaScript, lorsqu'il s'agit de fonctionner dans un navigateur. JavaScript côté serveur est génial aussi, mais il n’a aucun effet ou influence sur la façon dont j’écris mon JavaScript basé sur un navigateur.

En raison de la diversité des projets que j'ai construits et des technologies d'arrière-plan utilisées par mes clients, je ne peux pas et ne vais pas enfermer Marionette dans une pile technologique côté serveur pour une raison quelconque. Je ne fournirai pas de projet passe-partout. Je ne fournirai pas de paquet Ruby gem ou npm. Je veux que les gens sachent que Marionette n’exige pas de serveur d’arrière-plan spécifique. C’est un JavaScript basé sur un navigateur, et le back-end n'a pas d'importance.

Bien sûr, je soutiens pleinement les autres personnes fournissant des packages pour leur langage et leur framework. J'énumère ces paquets dans le wiki et espère que les gens continueront à en créer davantage au fur et à mesure de leurs besoins. Mais c’est le soutien de la communauté, pas le soutien direct de Marionette.

Changez facilement les valeurs par défaut

Dans mes efforts pour réduire le code habituel et fournir des valeurs par défaut raisonnables (une idée que j'ai directement "empruntée" à LayoutManager de Tim Branyen), je reconnais la nécessité pour d'autres développeurs d'utiliser des implémentations légèrement différentes de celles que je connais.

Je fournis un rendu basé sur inline <script> balises pour les modèles, en utilisant Underscore.js comme modèle par défaut. Mais vous pouvez le remplacer en modifiant les objets Renderer et/ou TempalteCache dans Marionette. Ces deux objets constituent le cœur des capacités de rendu. Il existe des pages de wiki qui montrent comment changer cela pour des moteurs de templates spécifiques et différentes façons de charger des modèles.

Avec v0.9 de Marionette, cela devient encore plus facile. Par exemple, si vous souhaitez remplacer l'utilisation de blocs de script de modèle inline par des modèles précompilés, il vous suffit de remplacer une méthode sur le moteur de rendu:


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

à présent, l'application entière utilisera des modèles précompilés que vous joindrez à l'attribut template de votre vue.

Je fournis même un complément Marionette.Async avec v0.9 qui vous permet de prendre en charge le rendu asynchrone des vues. Je m'efforce continuellement de faciliter le plus possible le remplacement des comportements par défaut dans Marionette.

Code comme configuration

Je suis fan de "convention sur la configuration" dans certains contextes. C'est un moyen efficace de faire avancer les choses, et Marionette en fournit un peu - mais pas trop, honnêtement. De nombreux autres frameworks - notamment LayoutManager - fournissent plus de convention de configuration que Marionette.

Ceci est fait avec un but et une intention.

J'ai construit suffisamment de plugins, de frameworks, de modules complémentaires et d'applications JavaScript pour comprendre à quel point il est difficile d'essayer de faire en sorte que les conventions fonctionnent de manière significative et rapide. Cela peut être fait avec rapidité, mais généralement au prix de pouvoir le changer.

À cette fin, j’adopte une approche "code en tant que configuration" pour Marionette. Je ne fournis pas beaucoup d'API de "configuration" dans lesquelles vous pouvez fournir un littéral d'objet avec des valeurs statiques qui modifient une multitude de comportements. Au lieu de cela, je documente les méthodes de chaque objet - à la fois par le code source annoté et par la documentation de l'API - dans le but de vous expliquer comment modifier Marionette pour qu'elle fonctionne comme vous le souhaitez.

En fournissant une API propre et claire pour les objets Marionette, je crée une situation dans laquelle le remplacement du comportement d'un objet spécifique ou de Marionette dans son ensemble est relativement simple et très flexible. Je sacrifie les appels "simples" de l'API de configuration pour la flexibilité de fournir votre propre code pour que les choses fonctionnent comme vous le souhaitez.

Vous ne trouverez pas d'API "Configurer" ou "Options" dans Marionette. Mais vous trouverez un grand nombre de méthodes qui ont chacune un objectif très spécifique, avec des signatures propres, qui permettent de changer facilement le fonctionnement de Marionette.

132
Derick Bailey

J'utilise actuellement Backbone avec le module de gestionnaire de disposition et le guidon comme moteur de modélisation et j'ai trouvé très facile de configurer une petite application à l'aide d'un backend Grails déjà existant. Avant de commencer à utiliser le gestionnaire de mise en page, j'ai lu des articles sur Marionette et Chaplin et les deux me semblaient vraiment puissants mais complexes. Ensuite, je me suis rappelé pourquoi j'avais initialement choisi backbone.js: la simplicité. Tous ces frameworks ajoutent ce que le backbone a laissé de côté. Je ne dis pas qu'un framework est mauvais, mais si j'ai besoin de quelque chose de plus complexe, j'essaierai d'autres projets, comme ember.js ou sproutcore, car ils ont une base de code unique, écrite avec un objectif dans l'esprit de leurs développeurs. Ici nous avons des frameworks sur un autre. Bien sûr, le backbone est un backbone non seulement pour la création d’applications, mais aussi pour l’écriture de bibliothèques plus puissantes, mais la seule chose que je trouve vraiment médiocre est le calque de vue, car il manque un gestionnaire de disposition et la possibilité d’imbrication de vues. . Avec le gestionnaire de disposition, cet écart est assez bien rempli.

Ma réponse à votre question est donc la suivante: commencez à utiliser l’ossature telle quelle et demandez-vous ce qui manque et quelles étaient vos attentes concernant le cadre. Si vous trouvez qu'il y a trop d'éléments omis par Backbone, cherchez-les dans les autres cadres et choisissez celui qui vous convient le mieux. Et si vous n’êtes toujours pas confiant dans votre choix, peut-être que la colonne vertébrale n’est pas faite pour vous et que vous devez chercher une autre solution (ember.js, sproutcore, ExtJs, JavaScript MVC sont tous bons). Si vous avez de l'expérience dans l'écriture d'applications clientes, vous n'avez pas vraiment besoin d'expérience sur tout le framework pour choisir celui qui vous convient (pour vous, bien sûr).

25
Pierpaolo Follia

J'ai étudié les différents frameworks construits avec Backbone.js et construit les Vertebrae pour un projet à HauteLook. Les objectifs du projet étaient les suivants: chargement de script dynamique, format de module AMD, gestion des dépendances, construction avec des bibliothèques principalement open source, organisation du code dans des packages, optimisation et construction pour une ou plusieurs applications à une seule page, hôte sur un serveur entièrement en cache, par exemple. aucun script côté serveur utilisant uniquement une API pour les données, et le plus amusant pour moi, utilise le développement basé sur le comportement pour le projet. Vous trouverez une description du projet à l'adresse suivante: http://www.hautelooktech.com/2012/05/24/vertebrae-front-end-framework-built-with-backbone-js-and-requirejs-using -AMD /

Notre problème:

Les bibliothèques sélectionnées (jQuery, Underscore.js, Backbone.js, RequireJS, Moustache) permettent le chargement de modules, la gestion des dépendances, la structure d'application (pour les modèles, les collections, les vues et les routes), les interactions asynchrones avec l'API, divers utilitaires et objets permettant de gérer les comportements asynchrones. , par exemple (Promesses) Différé, rappels. La logique restante nécessaire pour compléter le cadre comprend:

  • un objet (modèle) pour gérer l'état de l'application à page unique;
  • un gestionnaire de disposition pour présenter, organiser/faire la transition et effacer les vues, et
  • les contrôleurs qui répondent aux itinéraires, obtiennent/définissent l'état de l'application et confient le travail au gestionnaire de disposition.

Nos solutions (implémentées dans Vertebrae):

Application State Manager -

Le gestionnaire d'applications stocke les données en mémoire et les conserve également dans le stockage du navigateur afin de fournir une ressource pour les données/métadonnées communes. Fournit également des données (état) pour reconstruire les vues de page en fonction des interactions précédentes (onglet sélectionné, filtres appliqués, par exemple). Le gestionnaire d'état d'application fournit une stratégie pour que les ressources récupèrent l'état. Destiné à agir comme une machine d'état.

Layout Manager -

Le gestionnaire de disposition a une ou plusieurs vues ainsi que des destinations de document (DOM) pour chaque vue (rendue). Une page peut effectuer la transition entre plusieurs vues. Le gestionnaire de disposition conserve donc une trace des états des vues, par exemple. rendu, non rendu, affiché, non affiché. Vous pouvez utiliser le gestionnaire de disposition pour charger et rendre paresseux les vues (détachées) qu'un visiteur du site est susceptible de demander, par exemple. onglet change sur une page. La transition entre les états de vue est gérée par cet objet. Une présentation entière peut être effacée de sorte que les objets de vue et leurs liaisons soient supprimés, préparant ces objets pour la récupération de place (évitant les fuites de mémoire). Le gestionnaire de disposition communique également l'état d'affichage avec le (s) contrôleur (s).

Contrôleur -

Un objet contrôleur est appelé par une fonction de gestionnaire d’itinéraires. Il lui incombe de générer l’état pertinent (modèles d’application) pour générer une page (mise en page) (ainsi que de définir l’état lorsque les itinéraires changent). Le contrôleur transmet les données dépendantes (modèles/collections) et les objets de vue construits pour une page demandée au gestionnaire de disposition. En tant qu'effet secondaire, l'utilisation de contrôleurs empêche les objets de route de devenir gonflés et emmêlés. Un itinéraire doit être mappé sur un contrôleur, qui quitte ensuite la vue en page, tout en maintenant les fonctions de traitement de l'itinéraire.

L'application Todos est hébergée en mode dev et optimisée sur Heroku ...

De nombreux concepts des autres cadres sont empruntés, par exemple. la nécessité de supprimer les vues pour prévisualiser les fuites de mémoire, comme l'a souligné Derick Bailey - http://lostechies.com/derickbailey/ ; le gestionnaire de mise en page par Tim Branyen http://tbranyen.github.com/backbone.layoutmanager/

En résumé, Backbone.js est censé être un outil dans votre application. La bibliothèque Backbone.js ne fournit pas toute l'architecture dont vous aurez besoin pour créer une application, mais elle offre d'excellentes interactions avec une API et une structure de code solide pour ... Les vues (agissent également comme des contrôleurs), ainsi que vos modèles et collections de couches de données, et enfin, les itinéraires. Nous avons construit Vertebrae pour répondre aux objectifs de notre projet et avons décidé d’extraire le code en tant que cadre à utiliser, à apprendre ou autre.

La réponse à votre question à mon avis est d'apprendre de tous les cadres et d'utiliser tout ce dont vous avez besoin pour atteindre vos objectifs. Si vous trouvez que les objectifs de votre projet correspondent étroitement à l'un des cadres construits avec Backbone, c'est formidable, sinon créez votre propre cadre. il y a d'excellents exemples partagés par la communauté. Ou si vous vous trouvez un peu perdu dans le sens de votre application, choisissez quelque chose de plus structuré, peut-être Ember.js. Ce qui est génial, c’est qu’il existe un bon assortiment de choix pour vous aider à coder avec un modèle (MVX) de type MVC avec JavaScript.

13
pixelhandler

J'ai développé Luca framework alors que je travaillais chez BenchPrep, où nous l'avons utilisé pour développer plusieurs applications volumineuses d'une page au-dessus de la bibliothèque backbone.js.

Je travaillais avec ExtJS depuis plusieurs années et j'avais volé mes concepts préférés dans ce cadre, tel que l'architecture pilotée par composants, dans laquelle vous développiez vos vues en tant que composants autonomes, puis que vous les réunissiez avec d'autres composants à l'aide de vues de conteneur. Et comme il est fortement basé sur la configuration, développer une application dans Luca donne l'impression de décrire un objet avec JSON.

L'un des avantages de cette approche est la possibilité de réutiliser des composants dans plusieurs applications ou à différents endroits de votre application, avec seulement des modifications mineures à l'aide de l'extension Backbone. Il est également très facile d'expérimenter de nombreuses dispositions/présentations de composants en n'améliorant que légèrement la configuration JSON.

Outre une large gamme de fonctions utilitaires et utilitaires, Luca est livré avec de nombreux dérivés Backbone de niveau supérieur que vous pouvez assembler de toutes les manières imaginables pour construire une interface utilisateur complexe.

Vues, ​​Composants, Conteneurs

  • Cours de modèle, de vue, de collection et de routeur augmentés
  • Options de configuration facilitant la communication entre les modèles, les collections, les vues, l'application et ses gestionnaires respectifs.
  • Conteneurs (Disposition Séparée/Colonne, Disposition Grille, Vue par Onglets, Carte/Wizard Vue)
  • FormView avec tous les composants de champ standard et des aides pour la synchronisation avec un Backbone.Model
  • GridView, pour générer des éléments de grille défilables à partir d'un Luca.Collection
  • CollectionView, pour générer des vues basées sur une collection
  • Barres d'outils/boutons

Twitter Bootstrap Styles et balises gratuits

  • Luca joue très bien avec le framework Twitter bootstrap. En définissant simplement Luca.enableBootstrap = true et en incluant le CSS, vos composants (tels que les onglets, les barres d’outils, les boutons, les formulaires, les champs, les grilles, etc.) utiliseront automatiquement le balisage compatible Twitter Bootstrap et Conventions de classes CSS.
  • Utilise le système de grille pour la mise en page et répond de manière intelligente à la plupart des classes css de base bootstrap.
  • Les composants Luca.Viewport et GridLayout sont configurés pour fonctionner avec les systèmes de grille réactifs, fluides ou statiques de bootstrap.
  • Vise à fournir une correspondance individuelle pour les composants Twitter bootstrap, afin de les représenter sous forme de vues de backbone configurables.

Le composant d'application

  • La machine d'état basée sur Backbone.Model fournit des méthodes de lecture/définition et des événements de changement d'attribut en tant que style de flux de contrôle d'application
  • Composant contrôleur intégré qui masque/affiche les pages de l'application en réponse aux événements Backbone.Router ou State Machine
  • Integrated Collection Manager qui garde une trace des collections que vous avez créées, vous permet de les définir, de les regrouper et de leur attribuer des paramètres par défaut
  • Un gestionnaire de sockets qui est une couche d’abstraction au-dessus des services websocket qui rend Push aussi simple que Backbone.Event
  • Un routeur d'événement de clavier qui déclenche des événements de clé nommés sur des composants qui répondent à de tels événements

Améliorations apportées aux collections et aux modèles

  • Les collections sont basées sur backbone-query , qui fournit une interface de requête très similaire à mongoDb
  • activer un stockage local Backbone.sync simplement en définissant collection.localStorage = true
  • population automatique de collections dont les données sont initialisées au chargement de la page
  • méthodes mises en cache/propriétés calculées. met en cache le résultat des méthodes de collecte et expire le cache en réponse aux événements de modification/ajout/suppression de la collection ou de ses modèles
  • propriétés calculées sur les modèles. construire des attributs basés sur des fonctions complexes et mettre à jour automatiquement la valeur calculée en réponse aux changements

Événements et crochets

Les composants de Luca sont plus libéraux en ce qui concerne les événements qu’ils émettent par rapport aux composants stock du Backbone. Ils émettront des événements comme avant: initialize, after: initialize, before: render, after: render, activation, first: activation, désactivation, first: désactivation, ce qui vous permettra de régler plus finement le comportement de vos composants. De plus, en définissant un événement dans la propriété @hooks de votre vue, il appellera automatiquement une fonction portant le même nom si elle existe. Cela évite beaucoup de code de style de rappel, ce qui améliore la lisibilité.

Vous pouvez également configurer la classe Luca.Events pour publier les événements sur un canal de publication/abonnement global, ce qui facilite la construction d'une grande application et facilite la communication entre modules.

Le Ruby Gem

Luca a été développé spécifiquement pour fonctionner avec les API Rails et Sinatra. Pour cette raison, il est actuellement optimisé pour une pile spécifique, mais ne vous verrouille en aucun cas sur un serveur spécifique.

Luca est distribué en tant que partie d'un Ruby Gem configuré pour fonctionner sur le pipeline de ressources, ou en tant que fichier JS téléchargeable.

Vous n'êtes pas obligé d'utiliser Rails ou Sinatra. Mais si vous le faites, j'ai inclus beaucoup de choses utiles:

  • Les fichiers avec l'extension .luca sont traités en tant que HAML avec interpolation de variable de style JST. (équivalent à .jst.ejs.haml) par le pipeline d’actifs
  • Un harnais de tests pour les tests unitaires basés sur Jasmine, basés sur un navigateur ou sans tête, ainsi que de nombreux assistants pour les tests Backbone et Underscore.
  • Un point de terminaison API pour l'ensemble d'outils de développement fourni avec Luca (nous en parlerons plus tard)
  • Un point de terminaison d'API qui vous permet d'utiliser Redis en tant que moteur de stockage sans schéma pour Luca.Collection avec une configuration minimale

Les outils de développement

  • Les applications Luca peuvent activer une console coffeescript dans le navigateur avec des assistants et des commandes spécifiques à Luca qui facilitent la surveillance, l'inspection et le débogage des applications et des composants Luca.

An example of the Luca in browser Development Console powered by CoffeeScript

  • À l'aide de Rails Gem et de l'éditeur de composants basé sur Luca CodeMirror, vous pouvez modifier le code source de Luca Framework ainsi que les composants spécifiques à l'application directement dans le navigateur, à l'aide de Coffeescript. Vous obtiendrez des commentaires immédiats en réponse à vos modifications, les instances des objets affectés étant actualisées avec le prototype mis à jour, et vous pourrez enregistrer vos modifications sur le disque.

  • Le Component Tester est un bac à sable actif permettant de jouer avec les composants qui composent votre application de manière isolée. Il vous fournit des outils pour modifier le prototype du composant, configurer ses dépendances et configurer le composant. Le composant sera rendu de nouveau immédiatement chaque fois que vous effectuez une édition. Vous pouvez afficher et modifier le balisage généré par le composant, ainsi que le code CSS directement dans le navigateur, et voir vos modifications immédiatement. Cela en fait un outil d'expérimentation très précieux.

  • Le testeur de composants va bientôt s'intégrer à Jasmine afin que vous puissiez voir les résultats de vos tests unitaires de composants en temps réel lorsque vous modifiez leur code.

A screenshot of the component tester

Luca est un travail en cours, mais maintient une API stable (pas encore 1.0) et a été utilisé dans plusieurs applications de production de grande taille. C'est certainement un cadre très avisé, mais je travaille à le rendre plus modulaire. Je travaille activement sur la documentation et les exemples de composants.

13
Jonathan Soeder

Je suis co-auteur de Chaplin et j’ai écrit une comparaison approfondie entre Chaplin.js et Marionette.js:

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

Ce n'est pas une "fusillade", mais tente d'expliquer les deux approches de manière équilibrée.

11
molily