Share
Así que has aceptado el desafío de ir más allá del lado del cliente; bien hecho. ¿Has considerado todos los marcos y no estás seguro de cuál elegir? No estas solo. Sigue leyendo.
Mi experiencia, al aprender la forma de escribir aplicaciones del lado del cliente, está demostrando ser abrupta y difícil. No es fácil elegir usar deliberadamente MV * en el cliente para alguien que escribió JavaScript, basado completamente en jQuery y sus complementos. Este es un paradigma completamente nuevo; requiere conocimientos básicos de programación y una comprensión considerable del diseño de JavaScript (el lenguaje). Si tu experiencia se relaciona con la mía, sigue leyendo!
Explicaré las principales diferencias entre dos de los marcos de JavaScript más populares del lado del cliente: Backbone.js y Ember.js. Cada una de estas herramientas tiene puntos fuertes, así como puntos débiles que pueden ayudarlo a tomar una decisión más reflexiva..
Descargo de responsabilidad: como profesionales del software, debemos tratar con la diversidad de opiniones. Backbone y Ember son resultados de profesionales expertos y con experiencia, como tú y yo. Una herramienta no es mejor que la otra; Solo sirven a diferentes multitudes y, ergo, resuelven diferentes problemas. Gracias Trek por los sólidos consejos..
Backbone es mucho más fácil de aprender que Ember.
En primer lugar, debe comprender que Backbone y Ember atienden especialmente a multitudes ligeramente diferentes. En cuanto a la complejidad, Backbone es mucho más fácil de aprender que Ember. Sin embargo, se dice que una vez que aprendes Ember, difícilmente se vuelve más complejo. Tome la palabra de Trek en ello. Si recién estás comenzando con un JavaScript real, entonces quizás Backbone sea tu herramienta. Sin embargo, si sabe que va a lidiar con mucho más que un simple caso de uso o dos, es posible que prefiera Ember..
Jeremy Ashkenas construyó Backbone para que fuera posible sacar la verdad de la DOM. Lo que quiere decir con esto es: cualquier negocio que hicieras usando solo jQuery / Mootools / Prototype podría y debería extraerse mejor en estructuras de JavaScript puras: objetos, por así decirlo. En lugar de usar DOM Elementos para definir los elementos y el comportamiento de su negocio, Backbone lo invita a hacerlo al revés. Los objetos de JavaScript son el núcleo y el DOM es meramente una representación de esos datos.
Con Backbone, tienes algunas aseveraciones dadas:
Accentsconagua
DOM Se le da un control completo sobre la forma en que construye su aplicación. Backbone estaba destinado a brindarte una forma básica de diseñar tus objetos modelo y cómo estos interactúan entre sí a través de enlaces de eventos..
Representación HTML al DOM Es de tu responsabilidad. Usted es libre de elegir cualquier motor de plantilla: Bigote, DoT, Manillares, Subrayado, etc. El Backbone contiene una Ver Prototipo que tiene la responsabilidad de articular el DOM y tu núcleo de JavaScript.
Cuando Tilde comenzó a construir Ember, lo hizo con un objetivo mucho más desafiante: Proporcionar convenciones estándar en el desarrollo del lado del cliente, eliminando la mayor cantidad de repeticiones posible.. El resultado es un marco mucho más ambicioso que apunta a una arquitectura predecible y un desarrollo estable.
Ember comparte algunos puntos comunes con Backbone en la forma en que intenta extraer datos y comportamientos de la red. DOM Al proporcionar prototipos de JavaScript extensibles, pero lo hace de una manera muy diferente a la de Backbone..
Ember se encuentra en:
Tanto Backbone como Ember tienen conceptos clave comunes, como puntos de vista. Ambos representan DOM Comunicación, respectivamente. La forma en que logran este concepto son algo diferentes, aunque.
Usaré el caso de uso de Todo para los ejemplos a continuación, inspirados en el escaparate de TodoMVC.
Una vista de Backbone podría ser algo como esto:
var TaskView = Backbone.View.extend (tagName: "li", template: "task-template", render: function () // su código para representar aquí., events: "click .mark-done" : "mark_as_done", "change .body": "update_body", mark_as_done: function () / * code here * /, update_body: function () / * code here * /);
Esta es simplemente la definición de su punto de vista. Deberá crear una instancia si desea que esté en la página. Algo como esto hará el truco:
var task_view = new Task (model: task_model); $ ("body"). append (task_view.el); Observe que estamos pasando un modelo para que pueda mantener una referencia al objeto de datos que alimenta la plantilla. los modelo La propiedad dentro de la vista se puede utilizar para llamar a una plantilla externa, a través de un identificador. He usado algo como esto en el pasado:
var TaskView = Backbone.View.extend (template: "# task-template", render: function () this. $ el.html (Mustache.render ($ (this.template) .html ()), this. modelo); // recorte);
Ember tiene un enfoque diferente a las vistas. De hecho, la convención establece que las vistas deben hablar directamente con los controladores y no con los modelos. Esta es una buena práctica, si pretende seguir una arquitectura estable. Explicaré la muestra para la misma vista:
var TaskView = Ember.View.extend (templateName: "task-template", mark_as_done: function () / * code here * /, update_body: function () / * code here * /);
Eso es. Pero, ¿dónde está todo el material de representación? Bueno, Ember levanta esa placa para ti. Simplemente diga qué es la plantilla, el controlador que contiene el objeto de datos y, a continuación, solo debe agregarlo a la DOM.
var task_view = TaskView.create (controller: task_controller // Ember.ObjectController); task_view.append ();
Al crear una nueva instancia de vista, enlazará el contenido del controlador (que puede ser un Objeto.beber o una lista de ellos) a la vista. Cuando decida añadir la vista a la DOM, Buscará la plantilla y colocará el marcado generado por usted..
La columna vertebral es más explícita y menos mágica..
La espina dorsal es más explícita y menos mágica. Creas un Ver, Dígale qué plantilla usar y cómo, registre los eventos y haga lo que tiene que hacer. Ellos son los dueños de la página. Eso es un gran comienzo para aquellos que vienen de un fondo jQuery. Sin embargo, cuando algo necesita ser actualizado en el DOM, te enfrentarás a algo.
Con Ember, las actualizaciones son automáticas. Usted dice qué plantilla es y las devoluciones de llamada de eventos son funciones dentro del objeto de vista. Cada vez que se actualiza un objeto, la vista actualiza automáticamente la página..
Algunos enlaces de eventos comunes están integrados en Ember y otros deben colocarse en la plantilla. Es bueno para aquellos que vienen desde una perspectiva de back-end, ya que reduce la repetición de la placa de manera considerable..
Los modelos en Backbone y Ember son bastante similares. Poseen información para una entidad empresarial..
Un ejemplo de un modelo de Backbone se ve así:
var TaskModel = Backbone.Model.extend ();
Con esta simple línea de código, tienes un modelo de trabajo con DESCANSOComunicación completa incorporada. Obtienes métodos como salvar para persistir los datos y ha podido recuperar cargarlo gratis; No se requiere ningún complemento. La validación también está integrada en la forma en que se guardan los datos al proporcionar un validar devolución de llamada, que devuelve un valor booleano que indica que el registro se guardará o no. La implementación de la validación aún está a cargo del desarrollador..
Para crear una nueva tarea, crea una instancia de una nueva tarea. Modelo de tarea.
var task = new TaskModel (body: "Mow the lawn", done: false);
Puede inyectar tantos atributos como desee, porque la lista de atributos de la tarea no es estricta (piense en ello como sin esquemas). Todavía puede establecer un por defecto propiedad al extender Backbone.Modelo.
Con Ember, no hay modelos, solo objetos. Podría verse algo como esto:
var TaskObject = Ember.Object.extend ();
Similar a Backbone, necesitas extender desde Objeto.beber para crear una clase de objeto. Hereda toda la funcionalidad básica para una clase con devoluciones de llamada para cuando se cambia, se crea y se destruye, entre otras características. Sin embargo, no tiene comunicación back-end fuera de la caja.. Ember.Data Se está desarrollando como una extensión de Objeto.beber por el equipo central de Ember para satisfacer esa necesidad. Ya se puede usar, pero no es estable en la medida en que la documentación lo indica..
Los objetos de madera también se consideran sin esquemas. Para inyectar valores predeterminados en objetos Ember, extienda Objeto.beber pasando un objeto con tantos atributos como necesite.
var TaskObject = Ember.Object.extend (body: "Mow the lawn", done: false);
Backbone tiene una forma consolidada de sincronización con una capa de persistencia sobre DESCANSO y esa es una buena convención allí. Es una cosa menos que tienes que configurar para trabajar con un servidor backend.
Ember está abriéndose camino hacia la fabricación de Ember.Data Listo para uso de producción, y se ve prometedor. Aun así, la particularidad de los objetos Ember que tienen enlaces de dos vías hace que resulte más fácil realizar conexiones entre objetos..
En este punto de su lectura, tiene un punto de inflexión entre la estabilidad de Backbone en la comunicación con el servidor backend y los enlaces de Ember. Lo que sea más importante para usted debe determinar su decisión..
Aquí es donde los marcos se separan. Tienen una gran brecha conceptual sobre cómo unir las cosas en tu aplicación. Mientras Backbone se esfuerza por ser lo más simple y flexible posible, Ember sacrifica el tamaño de la base de código para una mejor arquitectura. Es un intercambio, de verdad.
Advertencia: los siguientes ejemplos no contienen ejemplos de plantillas HTML.
Como señalé, Backbone apunta a la simplicidad que se convierte en flexibilidad y logra dichos atributos precisamente a través de la falta de una clase de controlador. La mayor parte del caballo de batalla se distribuye entre vistas, colecciones, modelos y el enrutador (en caso de que elija utilizar Backbone's Enrutador).
Teniendo en cuenta una lista de tareas que deben gestionarse, se requeriría:
Colección almacenar las tareas.Modelo almacenar información de una tarea.Ver para representar la colección.Ver para representar cada tarea.Enrutador para gestionar URLs.La mayor parte de la lógica de la aplicación vivirá en las vistas, ya que conectan los modelos a la DOM. No hay una clara distinción de responsabilidades, ya que la vista lo hace todo. Puede ser bueno para aplicaciones pequeñas que no requieren una arquitectura sólida..
Para mostrar una lista de tareas, terminarías con algo como esto:
var TaskList = Backbone.Collection.extend (model: Task);
var TaskModel = Backbone.Model.extend ();
var TaskListView = Backbone.View.extend (render: function () this. $ el.empty (); for (_i = 0, _i < this.collection.length; _i++) var task = this.collection.models[_i]; this.$el.append(this.renderItem(task)); var tasks = this.$el.html(); this.$el.html(Mustache.to_html(template, tasks: tasks, no_tasks: !this.collection.length )); , renderItem: function(task) var view = new Row( model: task ); var el = view.render(); return el.el; , );
var TaskView = Backbone.View.extend (tagName: "tr", render: function () this. $ el.html (M.to_html (template, this.model.attributes)); return this;);
var Router = Backbone.Router.extend (initialize: function () this.tasks = new TaskList; this.view = new TaskListView (collection: this.tasks);, rutas: "": "tasks_list" ,, task_list: function () this.view.render (); $ (". bucket: first"). html (this.view.el);, start: function () Backbone.history.start ( pushState: true, root: "/ tickets /");); Tenga en cuenta que la colección no tiene una plantilla propia; más bien, delega a una vista de tarea única que se representa y se anexa al resultado final que se coloca en la página.
El número de clases requeridas para tener la misma configuración es ligeramente mayor.
Colección, tendrías un ArrayController, que funciona muy parecido.ObjectController para gestionar una sola tarea. Modelo, tendrías un Objeto / DS.Modelo, que funcionan igual.Vers.Enrutador También es responsable de administrar las URL.Podría estar pensando que los dos marcos no son muy diferentes entre sí. Es bastante tentador, pero no es exactamente cierto. Algunas diferencias particulares son:
DOM, no el controlador.La separación de las preocupaciones es buena a largo plazo. El controlador maneja los datos, las vistas manejan el DOM, período. Este tipo de diseño desacoplado y cohesivo, sin placa de calderas permite una capacidad de prueba más enfocada.
La implementación para mostrar la misma lista de tareas sería algo como lo siguiente, considerando una aplicación Ember completa:
window.App = Ember.Application.create (); App.ApplicationController = Ember.ObjectController.extend (); App.ApplicationView = Ember.View.extend (templateName: "application");
App.Task = Ember.Object.extend ();
App.TasksController = Ember.ArrayController.extend (content: []);
App.TasksView = Ember.View.extend (templateName: "my-list");
App.Router = Ember.Router.extend (root: Ember.Route.extend (index: Em.Route.extend (route: '/', connectOutlets: function (router) router.get ('applicationController') .connectOutlet ('tareas');)); En el caso de Ember, no se dice mucho sobre cómo se hacen las cosas dentro. Se retira todo ese espacio para que pueda concentrarse en lo que realmente importa en su aplicación: define un objeto de tarea, un controlador de lista de tareas con una matriz llamada contenido, su vista y el enrutador simplemente los combinan todos y lo ponen en la página.
Después de darse cuenta de cómo realmente funciona Ember, comienza a ser liberador..
Como era de esperar, este segmento fue el más difícil de comprender en ambos marcos. La columna vertebral fue definitivamente más fácil de aprender y su naturaleza flexible le da control sobre la forma en que los objetos y DOM interactuar. Esto podría ser bueno para usted, si realmente necesita ese tipo de flexibilidad pero aún desea mantener una estructura para la lógica de su aplicación en el lado de JavaScript.
En cuanto a Ember, su implementación impresionante podría dar miedo al principio. Sin embargo, después de darse cuenta de cómo realmente funciona Ember, comienza a ser liberador. Todas las convenciones que el marco establece para usted lo liberan de la plantilla y la configuración, lo que le permite concentrarse en su aplicación. Esto es similar a lo que hizo Rails para el desarrollo de servidores que atrajo tanta atención..
Ember estaba destinado a levantar las cargas comunes del desarrollo de JavaScript en el navegador.
Hasta ahora, el objetivo principal de mostrar las dos herramientas ha sido reconocer su único y noble propósito: delegar poder al lado del cliente, a través de la estructura y el método.
La fuerza central de la columna vertebral es definitivamente su enfoque KISS. Le proporciona lo mínimo para dejar ir el DOM como soporte principal de su aplicación, y comience a usar objetos JavaScript reales que se pueden probar y diseñar correctamente.
La red troncal viene con colecciones, modelos, vistas y enrutador, entre otras pequeñas utilidades. Eres libre de hacer lo que quieras con ellos..
Ember, por otro lado, fue construido con una mentalidad diferente, ya que apunta a una forma mucho más convencional y de opinión de construir aplicaciones web. Aborda un conjunto de problemas comunes, tales como repetitivo, enlace de datos y DOM Templar para que no tenga que preocuparse por ellos desde el principio. Ember estaba destinado a levantar las cargas comunes del desarrollo de JavaScript en el navegador.
Ember viene repleto de objetos, controladores, vistas de actualización automática, máquinas de estado, enlaces, observadores y un enrutador (que también es una máquina de estado), todos ellos combinados con una buena dosis de convenciones. Ya tienes una arquitectura diseñada y lista para comenzar a trabajar sin perder el foco..
Cuidado con la brecha de aprendizaje. Su experiencia y herencia cultural determinarán en gran medida la rapidez con la que se une al lado del cliente. Si tienes miedo de lo que debes hacer o de cuál elegir, entonces te puse en un nervio y eso es bueno. ¿Quieres una buena respuesta para elegir?? Ambos.
Si no estás seguro de cómo jQuery hace toda su magia, comienza a aprender Backbone. Para empezar, es más fácil y la documentación es muy sencilla de leer y entender. Después de que hayas terminado, comienza a construir algo. Ensuciarse Consulta estos tutoriales si necesitas ayuda..
Si todavía estás en la oscuridad, lee las entradas de Yehuda Katz sobre cómo funciona JavaScript.
Una vez que obtenga una mejor visión de cómo funciona el JavaScript como idioma, comenzará a comprender mejor cómo los objetos interactúan entre sí. Cuando lo hagas, ve por Ember. Es más complicado al principio, pero no te rindas. Empieza a leer los documentos y las guías. Es posible que desee consultar la entrada del blog de Trek Glowacki antes de ensuciarse las manos..
Personalmente, me estoy inclinando hacia Ember; Disfruto de su robustez a escala macro, y también prefiero sus convenciones. Backbone es una herramienta más maleable y más fácil para aplicaciones más pequeñas o características pequeñas dentro de una aplicación existente.
Todavía estoy aprendiendo ambos, y tengo algunos desafíos que enfrentar:
¿Qué piensas de todo este desastre? ¿Tienes algún reto en mente? ¿Alguna dificultad o impedimento? Házmelo saber!
