¿Cuáles son las fortalezas y debilidades del mundo real de los muchos marcos basados ​​en backbone.js? [cerrado]

Espero que alguien pueda compartir su experiencia con algunas de las últimas variantes emergentes de backbone.js que existen. Tengo buena experiencia con backbone / subrayado / requerimiento en varios proyectos y me gustaría dar el siguiente paso hacia soluciones más avanzadas para una estructura de aplicación compleja.

Sé que los siguientes marcos están disponibles:

• Marioneta
• Geppetto (basado en Marioneta)
• Chaplin , Chaplin - chaplin-boilerplate
• Vértebras
• LayoutManager
• Tórax
• Aura
• Luca
• Singool
• pila posterior
• UI de red troncal

• casco

• Por cierto - excelente punto de partida para proyectos a gran escala

Y probablemente me perdí algunas.

Aquí hay una breve introducción sobre las diferencias:

• enlace de conversación de altavoz

Pero es muy general. Me preguntaba si alguien puede compartir su experiencia con aplicaciones de la vida real utilizando estos marcos.

¿Cuál es el beneficio de elegir uno sobre el otro? ¿Cuándo será la marioneta una mejor solución sobre Chaplin, o por qué los veteranos son mejores para ciertas aplicaciones, por ejemplo?

Claro, la respuesta obvia será " usar lo que sea mejor para sus necesidades ", pero me falta la experiencia con estos marcos para conocer su fortaleza / propósito / ventajas o escenarios preferidos.

¡Gracias!

Edición 1: encontré esta publicación: Backbone.Marionette vs Backbone-Boilerplate

Edición 2: Respuesta por Mathias schafer (Chaplin) por correo:

En resumen, la estructura actual está cerca de la versión 1.0 ya que ya se usa en producción. No planeamos agregar una nueva característica grande o romper los cambios de API hasta 1.0.

Marionette es sin duda la biblioteca más completa y estable que existe. Aborda varios aspectos del desarrollo de aplicaciones JS con Backbone. Por ejemplo, tiene una capa de vista fuerte que Backbone deja completamente vacía. Por supuesto, encontrará que algunos de los aspectos no satisfarán sus demandas y puede sentir la necesidad de establecer una estructura alrededor de Marionette.

Por el contrario, Chaplin se centra en un aspecto bastante pequeño pero muy importante de las aplicaciones Backbone, a saber, la estructura general de la aplicación y el ciclo de vida del módulo. En este sentido, Chaplin es muy optimista y se parece más a un marco que a una biblioteca (como en "su código llama a una biblioteca, un marco llama a su código"). Chaplin proporciona algunas clases centrales que se encuentran por encima de los módulos de aplicaciones individuales y controlan el estado general de la aplicación. Esto le da a su aplicación una estructura convencional como Ruby on Rails lo hace, por ejemplo.

En Chaplin, declaras algunas rutas que se asignan a los controladores, y Chaplin inicia el controlador una vez que la ruta coincide. También se ocupa de la eliminación de los controladores antiguos y de mostrar y ocultar las vistas principales, que se supone que debe crear un controlador. Esta es la idea básica, pero Chaplin se encarga de los detalles feos para que esto funcione sin problemas.

Hay dos principios que vienen junto con esta estructura: - Modularización, desacoplamiento y sandboxing - Comunicación entre módulos utilizando Publicar / Suscribir y Mediador (es)

Por supuesto, estos patrones no son nuevos en el mundo del desarrollo de software, y Chaplin no es la única biblioteca que los aplica a las aplicaciones Backbone.js.

Chaplin también proporciona mejoras para la capa de Vista, por ejemplo, un CollectionView altamente sofisticado, pero en total no tanto como Marionette con sus Regiones y Diseños. Pero es relativamente fácil escribir tales metaclases utilizando los medios que proporciona Chaplin Views.

La mayoría de (¿todos?) Los marcos que estás viendo resuelven los mismos problemas, pero lo hacen de maneras ligeramente diferentes con objetivos ligeramente diferentes.

Creo que es justo decir que todos estos proyectos resolverían los problemas en estas categorías:

• Proporcionar un conjunto razonable de valores predeterminados
• Reduce el código repetitivo
• Proporcione una estructura de aplicación sobre los bloques de construcción BackboneJS
• Extraer patrones que los autores usan en sus aplicaciones

Marionette, que he estado construyendo desde diciembre de 2011, también tiene en mente unos objetivos e ideales muy distintos:

• Arquitectura de aplicación compuesta
• Influencia del patrón de mensajería empresarial
• Opciones de modularización
• Uso incremental (sin requisito de todo o nada)
• Sin bloqueo de servidor
• Facilite cambiar esos valores predeterminados
• Código como configuración / sobre configuración

No digo que ninguno de los otros marcos tenga estos mismos objetivos. Pero creo que la singularidad de Marionette proviene de la combinación de estos objetivos.

Arquitectura de aplicaciones compuestas

Pasé más de 5 años trabajando en sistemas de software distribuido de cliente grueso utilizando WinForms y C #. Creé aplicaciones para computadoras de escritorio, computadoras portátiles (clientes inteligentes), dispositivos móviles y aplicaciones web, todas compartiendo un conjunto funcional central y trabajando muchas veces con el mismo servidor. En este tiempo, aprendí el valor de la modularización y rápidamente avancé por un camino de diseño de aplicaciones compuestas.

La idea básica es "componer" la experiencia de tiempo de ejecución de su aplicación y procesarla a partir de muchas piezas individuales más pequeñas que no necesariamente se conocen entre sí. Se registran en el sistema global de aplicaciones compuestas y luego se comunican a través de diversos medios de mensajes y llamadas desconectados.

Escribí un poco sobre esto en mi blog, presentando Marionette como una arquitectura de aplicación compuesta para Backbone:

• 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/

Colas de mensajes / Patrones

Los mismos sistemas distribuidos a gran escala también aprovecharon las colas de mensajes, los patrones de integración empresarial (patrones de mensajes) y los buses de servicio para manejar los mensajes. Esto, más que cualquier otra cosa, tuvo una tremenda influencia en mi enfoque para el desarrollo de software desacoplado. Comencé a ver aplicaciones WinForms en memoria de un solo proceso desde esta perspectiva, y pronto mi desarrollo de aplicaciones web y del lado del servidor tomó influencia de esto.

Esto se ha traducido directamente en cómo veo el diseño de la aplicación Backbone. Proporciono un agregador de eventos en Marionette, tanto para el objeto Aplicación de alto nivel como para cada módulo que cree dentro de la aplicación.

Pienso en los mensajes que puedo enviar entre mis módulos: mensajes de comando, mensajes de eventos y más. También pienso en la comunicación del lado del servidor como mensajes con estos mismos patrones. Algunos de los patrones ya han llegado a Marionette, pero otros aún no.

• 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/ (código WinForms, pero aún aplicable)

Modularización

La modularización del código es tremendamente importante. Crear paquetes pequeños y bien encapsulados que tengan un enfoque singular con puntos de entrada y salida bien definidos es imprescindible para cualquier sistema de cualquier tamaño y complejidad significativos.

Marionette proporciona modularización directamente a través de sus moduledefiniciones. Pero también reconozco que a algunas personas les gusta RequireJS y quieren usar eso. Por lo tanto, proporciono una compilación estándar y una compilación compatible con RequireJS.

MyApp = new Backbone.Marionette.Application();

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

  // your module code goes here

});

(No hay publicaciones de blog disponibles para esto, todavía)

Uso incremental

Esta es una de las filosofías centrales que cuento en cada parte de Marionette que puedo: no hay requisito de "todo o nada" para usar Marionette.

La red troncal en sí adopta un enfoque muy incremental y modular con todos sus objetos de bloques de construcción. Usted es libre de elegir cuáles quiere usar, cuándo. Creo firmemente en este principio y me esfuerzo por asegurarme de que Marionette funcione de la misma manera.

Con ese fin, la mayoría de las piezas que he incorporado a Marionette están hechas para estar solas, para trabajar con las piezas centrales de Backbone y para trabajar juntas aún mejor.

Por ejemplo, casi todas las aplicaciones Backbone necesitan mostrar dinámicamente una vista Backbone en un lugar particular de la pantalla. Las aplicaciones también deben manejar el cierre de vistas antiguas y la limpieza de memoria cuando se instala una nueva. Aquí es donde Regionentra Marionette's para jugar. Una región maneja el código repetitivo de tomar una vista, llamar a render y rellenar el resultado en el DOM por usted. Luego cerrará esa vista y la limpiará para usted, siempre que su vista tenga un método de "cierre".

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

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

Pero no es necesario que use las vistas de Marionette para usar una región. El único requisito es que se extienda desde Backbone.View en algún punto de la cadena de prototipos del objeto. Si elige proporcionar un closemétodo, un onShowmétodo u otros, Marionette's Region lo llamará por usted en el momento adecuado.

• 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/

Sin bloqueo de servidor

Construyo aplicaciones Backbone / Marionette sobre una amplia variedad de tecnologías de servidor:

• ASP.NET MVC
• Ruby on Rails
• Ruby / Sinatra
• NodeJS / ExpressJS
• PHP / Slim
• Java
• Erlang
• ... y más

JavaScript es JavaScript, cuando se trata de ejecutarse en un navegador. El JavaScript del lado del servidor también es increíble, pero tiene cero efecto o influencia en cómo escribo mi JavaScript basado en el navegador.

Debido a la diversidad en los proyectos que construí y las tecnologías de back-end que usan mis clientes, no puedo y no bloquearé a Marionette en una sola pila de tecnología del lado del servidor por ningún motivo. No proporcionaré un proyecto repetitivo. No proporcionaré una gema de rubí o un paquete npm. Quiero que la gente entienda que Marionette no requiere un servidor de fondo específico. Es JavaScript basado en navegador, y el back-end no importa.

Por supuesto, apoyo totalmente a otras personas que proporcionan paquetes para su idioma y marco. Enumero esos paquetes en el Wiki y espero que la gente continúe construyendo más paquetes a medida que vean una necesidad. Pero ese es el apoyo de la comunidad, no el apoyo directo de Marionette.

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

Cambie fácilmente los valores predeterminados

En mi esfuerzo por reducir el código repetitivo y proporcionar valores predeterminados razonables (que es una idea que directamente "tomé prestada" del LayoutManager de Tim Branyen), reconozco la necesidad de que otros desarrolladores utilicen implementaciones ligeramente diferentes a las mías.

Proporciono renderizado basado en <script>etiquetas en línea para plantillas, usando la plantilla Underscore.js por defecto. Pero puede reemplazar esto cambiando los objetos Renderery / u TempalteCacheobjetos en Marionette. Estos dos objetos proporcionan el núcleo de las capacidades de representación, y hay páginas wiki que muestran cómo cambiar esto para motores de plantillas específicos y diferentes formas de cargar plantillas.

Con v0.9 de Marionette, se vuelve aún más fácil. Por ejemplo, si desea reemplazar el uso de bloques de script de plantilla en línea con plantillas precompiladas, solo tiene que reemplazar un método en el Renderer:

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

y ahora toda la aplicación usará plantillas precompiladas que adjuntará al templateatributo de su vista .

Incluso proporciono un complemento Marionette.Async con v0.9 que le permite admitir vistas de representación asíncrona. Me esfuerzo continuamente para que sea lo más fácil posible reemplazar los comportamientos predeterminados en Marionette.

Código como configuración

Soy fanático de la "convención sobre la configuración" en ciertos contextos. Es una forma poderosa de hacer las cosas, y Marionette ofrece un poco de esto, aunque no demasiado, honestamente. Muchos otros marcos, especialmente LayoutManager, proporcionan más convenciones sobre la configuración que Marionette.

Esto se hace con propósito e intención.

He creado suficientes complementos, marcos, complementos y aplicaciones de JavaScript para conocer el dolor de tratar de hacer que las convenciones funcionen de manera significativa y rápida. Se puede hacer con velocidad, pero generalmente a costa de poder cambiarlo.

Con ese fin, adopto un enfoque de "código como configuración" para Marionette. No proporciono muchas API de "configuración" en las que puede proporcionar un objeto literal con valores estáticos que cambien una franja de comportamientos. En cambio, documente los métodos que tiene cada objeto, tanto a través del código fuente anotado como a través de la documentación API real, con la intención de decirle cómo cambiar Marionette para que funcione de la manera que desee.

Al proporcionar una API limpia y clara para los objetos Marionette, creo una situación en la que reemplazar el comportamiento de un objeto específico o Marionette en su conjunto es relativamente simple y muy flexible. Sacrifico las configuraciones de API "simples" para la flexibilidad de proporcionar su propio código para que las cosas funcionen de la manera que desee.

No encontrará una API de "configuración" u "opciones" en Marionette. Pero encontrará una gran cantidad de métodos que tienen un propósito muy específico, con firmas limpias, que facilitan cambiar la forma en que funciona Marionette.

Actualmente estoy usando backbone con el módulo administrador de diseño y el manillar como motor de plantillas y me resultó muy fácil configurar una pequeña aplicación usando un backend de Grails ya existente. Antes de comenzar a usar el administrador de diseño, leí sobre Marionette y Chaplin y ambos me parecieron realmente poderosos pero complejos. Entonces recordé por qué elegí originalmente backbone.js: simplicidad. Todos esos marcos están agregando lo que la columna vertebral ha dejado fuera por diseño. No digo que un marco sea malo, pero si necesito algo más complejo, intentaré otros proyectos, como ember.js o sproutcore, ya que tienen una base de código única, escrita con un objetivo en mente de sus desarrolladores. Aquí tenemos marcos encima de otro. Por supuesto, el backbone es un backbone no solo para crear aplicaciones, sino también para escribir una biblioteca más poderosa, pero lo único que creo que es realmente pobre es la capa de vista, ya que le falta un administrador de diseño y la posibilidad de anidar vistas. Con el administrador de diseño, esa brecha se llena bastante bien.

Entonces, mi respuesta a su pregunta es: comience por usar la red troncal tal como está y pregúntese qué falta y cuáles eran sus expectativas sobre el marco. Si encuentra que hay demasiadas cosas olvidadas por la red troncal, vaya y búsquelas en los otros marcos y elija la que más se ajuste a sus necesidades. Y si todavía no está seguro de la elección, tal vez la red troncal no sea para usted y tenga que buscar alguna otra solución (ember.js, sproutcore, ExtJs, JavaScript MVC son buenos). Si tiene experiencia en escribir aplicaciones de cliente, realmente no necesita experiencia en todo el marco para elegir la correcta (para usted, por supuesto)

He estudiado los diversos marcos construidos con Backbone.js y he creado las vértebras para un proyecto en HauteLook. Los objetivos del proyecto incluían ... carga dinámica de scripts, formato de módulo AMD, gestión de dependencias, compilación con bibliotecas en su mayoría de código abierto, organizar código en paquetes, optimizar y compilar para una o varias aplicaciones de una sola página, alojar en un servidor totalmente en caché, por ejemplo, sin servidor scripting de lado usando solo una API para datos, y lo más divertido para mí, usar el desarrollo impulsado por el comportamiento para el proyecto. Hay una descripción del proyecto en: http://www.hautelooktech.com/2012/05/24/vertebrae-front-end-framework-built-with-backbone-js-and-requirejs-using-amd/

Nuestro problema:

Las bibliotecas seleccionadas (jQuery, Underscore.js, Backbone.js, RequireJS, Moustache) proporcionan carga de módulos, gestión de dependencias, estructura de la aplicación (para modelos, colecciones, vistas y rutas), interacciones asíncronas con API, diversas utilidades y objetos para gestionar comportamientos asincrónicos , por ejemplo (Promesas) diferidos, devoluciones de llamada. La lógica restante necesaria para completar el marco incluye:

• un objeto (modelo) para administrar el estado de la aplicación de una sola página;
• un administrador de diseño para presentar, organizar / hacer una transición y vistas claras, y
• controladores que responden a rutas, obtienen / establecen el estado de la aplicación y transfieren el trabajo al administrador de diseño.

Nuestras soluciones (implementadas en vértebras):

Gerente de estado de la aplicación -

El administrador de aplicaciones almacena datos en la memoria y también los conserva en el almacenamiento del navegador para proporcionar un recurso para datos / metadatos comunes. También proporciona datos (estado) para reconstruir las vistas de la página en función de interacciones anteriores (por ejemplo, pestaña seleccionada, filtros aplicados). El administrador de estado de la aplicación proporciona una estrategia para que los recursos recuperen el estado. Destinado a actuar como una máquina de estado.

Gerente de diseño -

El administrador de diseño tiene una o varias vistas, así como destinos de documentos (DOM) para cada vista (representada). Una página puede hacer una transición entre muchas vistas, por lo que el administrador de diseño realiza un seguimiento de los estados de vista, por ejemplo, renderizado, no renderizado, visualizado, no visualizado. Puede usar el administrador de diseño para cargar y renderizar de forma diferida vistas (separadas) que es muy probable que solicite un visitante del sitio, por ejemplo, cambios de pestañas en una página. La transición entre los estados de vista es administrada por este objeto. Se puede borrar un diseño completo para que se eliminen los objetos de visualización y sus enlaces, preparando estos objetos para la recolección de basura (evitando pérdidas de memoria). El administrador de diseño también comunica el estado de la vista con los controladores.

Controlador -

Una función de controlador de ruta llama a un objeto controlador y es responsable de obtener el estado relevante (modelos de aplicación) para generar una página (diseño), (también responsable de establecer el estado cuando cambian las rutas). El controlador pasa datos dependientes (modelos / colecciones) y objetos de vista construidos para una página solicitada al administrador de diseño. Como efecto secundario, el uso de controladores evita que el objeto de rutas se hinche y se enrede. Una ruta debe correlacionarse con un controlador que luego inicia la vista de la página, manteniendo las funciones de manejo de ruta magras.

La aplicación Todos está alojada tanto en modo dev como optimizada en Heroku ...

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

Muchos de los conceptos en los otros marcos se toman prestados, por ejemplo, la necesidad de eliminar vistas para obtener una vista previa de las pérdidas de memoria como señala Derick Bailey: http://lostechies.com/derickbailey/ ; el Layout Manager por Tim Branyen http://tbranyen.github.com/backbone.layoutmanager/

En resumen, Backbone.js está destinado a ser una herramienta en su aplicación, la biblioteca Backbone.js no proporciona toda la arquitectura que necesitará para crear una aplicación, pero proporciona excelentes interacciones con una API y una estructura de código sólida para ... Vistas (también actúan como controladores) y sus modelos y colecciones de capas de datos, y finalmente Rutas. Construimos vértebras para cumplir los objetivos de nuestro proyecto y decidimos extraer el código como marco para que otros lo usen, aprendan o lo que sea.

La respuesta a su pregunta en mi opinión es aprender de todos los marcos y usar lo que necesita para cumplir sus objetivos, si encuentra que los objetivos de su proyecto se ajustan estrechamente a uno de los marcos construidos con Backbone, entonces excelente, de lo contrario, construya su propio marco Hay grandes ejemplos compartidos por la comunidad. O si se encuentra un poco perdido en la dirección de su aplicación, elija algo más obstinado y estructurado, tal vez Ember.js. Lo mejor es que hay una buena variedad de opciones para ayudarlo a codificar usando un patrón similar a MVC (MVX) con JavaScript.

Desarrollé el marco Luca mientras trabajaba en BenchPrep, donde lo usamos para desarrollar varias aplicaciones grandes de una sola página en la parte superior de la biblioteca backbone.js.

Había trabajado con ExtJS durante varios años antes y he robado mis conceptos favoritos de ese marco, como la arquitectura impulsada por componentes donde desarrolla sus vistas como componentes independientes y luego las une con otros componentes utilizando vistas de contenedor. Y dado que se basa en gran medida en la configuración, desarrollar una aplicación en Luca se parece mucho a describir un objeto con JSON.

Una ventaja de este enfoque es la capacidad de reutilizar componentes en varias aplicaciones o en diferentes lugares de su aplicación, con solo pequeños cambios utilizando la extensión de Backbone. También es muy fácil experimentar con diferentes diseños / presentaciones de componentes haciendo solo pequeños ajustes a la configuración JSON.

Además de una amplia gama de funciones de ayuda / utilidad, Luca se envía con muchos derivados de Backbone de nivel más alto que puede juntar de cualquier manera imaginable para construir una interfaz de usuario compleja.

Vistas, Componentes, Contenedores

• Modelo aumentado, vista, colección, clases de enrutador
• Opciones de configuración que facilitan la comunicación entre Modelos, Colecciones, Vistas, la Aplicación y sus respectivos administradores.
• Contenedores (diseño de división / columna, diseño de cuadrícula, vista de pestaña, vista de tarjeta / asistente)
• FormView con todos los componentes de campo estándar y ayudantes para sincronizar con un Backbone.
• GridView, para generar elementos de cuadrícula desplazables desde una Luca.
• CollectionView, para generar vistas basadas en una colección
• Barras de herramientas / botones

Twitter Bootstrap Styles y Markup gratis

• Luca juega muy bien con el marco de arranque de Twitter. Simplemente configurando Luca.enableBootstrap = true e incluyendo el CSS, sus componentes (como las vistas de pestañas, las barras de herramientas, los botones, los formularios, los campos, las cuadrículas, etc.) usarán automáticamente el marcado compatible con Twitter Bootstrap y las convenciones de clase CSS.
• Utiliza el sistema Grid para el diseño y responde a la mayoría de las clases de css base de bootstrap de una manera inteligente
• Los componentes Luca.Viewport y GridLayout están configurados para funcionar con los sistemas de red receptivos, fluidos o estáticos de bootstrap.
• Su objetivo es proporcionar una coincidencia individual para los componentes de arranque de Twitter, para representarlos como vistas de red troncal configurables

El componente de aplicación

• La máquina de estado basada en Backbone.Model proporciona métodos getter / setter y eventos de cambio de atributos como un estilo de flujo de control de aplicaciones
• Componente de controlador integrado que oculta / muestra páginas de la aplicación en respuesta a eventos de Backbone.Router o State Machine
• Integrated Collection Manager, que realiza un seguimiento de las colecciones que ha creado, le permite ampliarlas, agruparlas, asignarles parámetros predeterminados
• Un administrador de sockets que es una capa de abstracción sobre los servicios de websocket que hace que el empuje sea tan fácil como Backbone.
• Un enrutador de eventos de teclado que desencadena eventos clave con nombre en componentes que desean responder a dichos eventos

Mejoras de colección y modelo

• Las colecciones se basan en backbone-query , que proporciona una interfaz de consulta muy similar a mongoDb
• habilitar un almacenamiento local Backbone.sync simplemente configurando collection.localStorage = true
• población automática de colecciones cuyos datos se arrancan al cargar la página
• métodos en caché / propiedades calculadas. almacenar en caché el resultado de los métodos de recopilación y caducar el caché en respuesta a eventos de cambio / agregar / eliminar en la recopilación o sus modelos
• propiedades calculadas en los modelos. crear atributos basados ​​en funciones complejas y actualizar automáticamente el valor calculado en respuesta a los cambios

Eventos y ganchos

Los componentes de Luca son más liberales con los eventos que emiten en comparación con los componentes principales de Backbone. Emitirán eventos como before: initialize, after: initialize, before: render, after: render, activación, primero: activación, desactivación, primero: desactivación, y esto le permite ajustar con mayor precisión el comportamiento de sus componentes. Además, al definir un evento en la propiedad @hooks en su vista, automáticamente llamará a una función con un nombre similar si existe. Esto evita una gran cantidad de código de estilo de devolución de llamada que mejora la legibilidad.

También puede configurar la clase Luca.Events para publicar los eventos en un canal global de publicación / suscripción, lo que facilita la creación de una aplicación grande y ayuda en la comunicación entre módulos.

La gema de rubí

Luca se desarrolló específicamente mientras trabajaba contra las API de Rails y Sinatra y, debido a esto, actualmente está optimizado para una pila específica, pero de ninguna manera lo encierra en un servidor específico.

Luca viene distribuido como parte de una Ruby Gem configurada para trabajar en la canalización de activos, o como un archivo JS descargable.

No es obligatorio usar Rails o Sinatra. Pero si lo hace, he incluido muchas cosas útiles:

• Los archivos con la extensión .luca se procesan como HAML con interpolación variable de estilo JST. (equivalente a .jst.ejs.haml) por la canalización de activos
• Un arnés de prueba para el navegador, o pruebas de unidad sin cabeza basadas en jazmín junto con muchos ayudantes de prueba de Backbone y Underscore.
• Un punto final de API para el conjunto de herramientas de desarrollo que se incluye con Luca (más sobre esto más adelante)
• Un punto final API que le permite utilizar Redis como un motor de almacenamiento sin esquema para Luca.Colección con configuración mínima

Las herramientas de desarrollo

• Las aplicaciones de Luca pueden habilitar una consola coffeescript en el navegador con ayudantes y comandos específicos de Luca que ayudan a monitorear, inspeccionar y depurar las aplicaciones y componentes de Luca

• Con la ayuda de Rails Gem y el editor de componentes basado en CodeMirror de Luca, puede editar el código fuente de Luca Framework y los componentes específicos de la aplicación directamente en el navegador, utilizando Coffeescript. Verá comentarios inmediatos en respuesta a sus ediciones, con las instancias de los objetos afectados que se actualizan con el prototipo actualizado, y puede guardar sus cambios en el disco.

• El Component Tester es un sandbox en vivo para jugar con los componentes que componen su aplicación de forma aislada. Le proporciona herramientas para modificar el prototipo del componente, configurar sus dependencias y configurar el componente. El componente se volverá a procesar inmediatamente cada vez que realice una edición. Puede ver y editar el marcado que genera el componente, así como el CSS directamente en el navegador y ver sus cambios de inmediato. Esto lo convierte en una herramienta de experimentación muy valiosa.

• El probador de componentes pronto se integrará con Jasmine para que pueda ver los resultados de sus pruebas de unidad de componentes en tiempo real a medida que edita su código

Luca es un trabajo en progreso, pero mantiene una API estable (aún no 1.0) y se ha utilizado en varias aplicaciones de producción de gran tamaño. Definitivamente es un marco muy obstinado, pero estoy trabajando para hacerlo más modular. Estoy trabajando activamente en la documentación y los componentes de muestra.

Soy coautor de Chaplin y he escrito una comparación en profundidad entre Chaplin.js y Marionette.js:

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

Este no es un "tiroteo", pero trata de explicar ambos enfoques de manera equilibrada.