Ya hace poco más de dos años que trabajo para una empresa que utiliza Backbone JS para sus sistemas, ¿Por que!?, simple, por que el código se viene desarrollando desde hace años y funciona bien.
Así que a pesar de que sufrimos muchos de los problemas comunes relacionados a grandes aplicaciones echas con Backbone, todo sigue bajo control.
Trabajar con Backbone es algo que me gusta, además la empresa es bastante estricta con el código así que esto me dio un mejor entendimiento acerca de como JavaScript funciona (o cómo debería funcionar).
El mundo sigue girando y existen cosas increíbles para aprender, pero antes de probar un nuevo framework quise probar Marionette JS.
Marionette JS se utiliza por arriba de Backbone y brinda soluciones a algunos problemas comunes que suelen encontrarse en aplicaciones echas con Backbone.
Así que comencé a jugar con el ejemplo marionette-wires para tener un setup básico funcionando con gulp.
Luego de un tiempo pude tener un ABM básico que funciona con localStorage, utilizando Radio para comunicar acciones y behaviors para reutilizar código etc.. fuente aquí.
Probar Marionette viniendo de una base Backbone fue una muy buena experiencia.
¿Usaría Marionette en el 2016?
Estoy muy contento de haber probado Marionette, mientras lo probaba pensaba en usarlo para algunas cosas, pero eso fue antes de probar react/redux.
Fue una buena opción para introducirme a ES6 sin dejar un ambiente conocido (Backbone), además me permitió ver las ventajas de usar ES6 sin quedarme loco intentando entender otros paradigmas impuestos por otros frameworks.
Claro que veo los beneficios de usar Marionette en un proyecto que ya lo usa, pero no lo comenzaría a usar en un proyecto grande que ya está funcionando, por que lo más probable es que las cosas que Marionette soluciona ya estén solucionadas dentro del mismo proyecto.
Para cosas chicas voy a estar usando react/redux.
Y para proyectos grandes? todavía no se.. quizás Ember?
Demo y fuentes
