Viaje a través de la jungla MVC de JavaScript

 

 

 

  • Patrones de diseño de interfaces inteligentes, vídeo de 10h + formación UX
  • Clase magistral de CSS moderno avanzado, con Manuel Matuzović

  • Índice
    1. Lecturas adicionales sobre SmashingMag:
    2. ¿Qué es JavaScript MVC, o más bien MV*?
    3. ¿Cuándo necesita un marco JavaScript MV*?
    4. El desafío de elegir: ¿demasiadas opciones?
    5. TodoMVC: una aplicación común para el aprendizaje y la comparación
    6. Nuestros criterios sugeridos para seleccionar un marco
    7. Dojo y el auge de los marcos de JavaScript
    8. La colección TodoMVC
    9. Marcos: ¿cuándo utilizar qué?
    10. ¿Qué piensan los desarrolladores sobre los frameworks más populares?
      1. ascua.js

    Al escribir una aplicación web desde cero, es fácil sentir que podemos arreglárnoslas simplemente confiando en una biblioteca de manipulación DOM (como jQuery ) y un puñado de complementos de utilidad. El problema con esto es que no lleva mucho tiempo perderse en una pila anidada de devoluciones de llamadas de jQuery y elementos DOM sin ninguna estructura real para nuestras aplicaciones.

     

    Al escribir una aplicación web desde cero, es fácil sentir que podemos arreglárnoslas simplemente confiando en una biblioteca de manipulación DOM (como jQuery ) y un puñado de complementos de utilidad. El problema con esto es que no lleva mucho tiempo perderse en una pila anidada de devoluciones de llamadas de jQuery y elementos DOM sin ninguna estructura real para nuestras aplicaciones.

    En resumen, estamos atrapados en el código espagueti . Afortunadamente, existen marcos de JavaScript modernos que pueden ayudar a darle estructura y organización a nuestros proyectos, mejorando la facilidad de mantenimiento a largo plazo.

    Lecturas adicionales sobre SmashingMag:

    • Navegando con Sails.js: un marco estilo MVC para Node.js
    • Una introducción completa a Backbone.Marionette
    • Comenzando con las plantillas PHP
    • Una introducción a Redux

    ¿Qué es JavaScript MVC, o más bien MV*?

    Estos marcos modernos brindan a los desarrolladores un camino fácil para organizar su código utilizando variaciones de un patrón conocido como MVC (Modelo-Vista-Controlador). MVC separa las preocupaciones de una aplicación en tres partes:

     

    • Los modelos representan el conocimiento y los datos específicos del dominio en una aplicación. Piense en esto como un "tipo" de datos que puede modelar, como un usuario, una foto o una nota. Los modelos deben notificar a cualquiera que los observe sobre su estado actual (por ejemplo, Vistas).
    • Las vistas normalmente se consideran la interfaz de usuario de una aplicación (por ejemplo, su marcado y plantillas), pero no tienen por qué serlo. Deben conocer la existencia de Modelos para poder observarlos, pero no comunicarse directamente con ellos.
    • Los controladores manejan la entrada (por ejemplo, clics, acciones del usuario) en una aplicación y se puede considerar que las Vistas manejan la salida. Cuando un Controlador actualiza el estado de un modelo (como editar el título de una foto), no se lo indica directamente a la Vista. Para esto sirve la naturaleza observadora de la relación Vista y Modelo.

    Los marcos de JavaScript 'MVC' que pueden ayudarnos a estructurar nuestro código no siempre siguen estrictamente el patrón anterior. Algunos marcos incluirán la responsabilidad del Controlador en la Vista (por ejemplo, Backbone.js ), mientras que otros agregarán sus propios componentes obstinados a la mezcla, ya que consideran que esto es más efectivo.

    Por esta razón, nos referimos a dichos marcos como si siguieran el patrón MV*, es decir, es probable que tenga una Vista y un Modelo, pero es más probable que también incluya algo más.

    Nota: También existen variaciones de MVC conocidas como MVP (Model-View-Presenter) y MVVM (Model-View ViewModel). Si eres nuevo en esto y sientes que hay mucho que asimilar, no te preocupes. Puede tomar un poco de tiempo entender los patrones, pero he escrito más sobre los patrones anteriores en mi libro en línea Aprendizaje de patrones de diseño de JavaScript en caso de que necesite más ayuda.

    ¿Cuándo necesita un marco JavaScript MV*?

    Al crear una aplicación de una sola página usando JavaScript, ya sea que implique una interfaz de usuario compleja o simplemente intente reducir la cantidad de solicitudes HTTP requeridas para nuevas Vistas, es probable que se encuentre inventando muchas de las piezas que componen un marco MV*. como Backbone o Ember.

    Al principio, no es muy difícil escribir un marco de aplicación que ofrezca alguna forma obstinada de evitar el código espagueti; sin embargo, decir que es igualmente trivial escribir algo del estándar de Backbone sería una suposición tremendamente incorrecta.

     

    Hay mucho más que implica estructurar una aplicación que unir una biblioteca de manipulación DOM, plantillas y enrutamiento. Los marcos MV* maduros normalmente no solo incluyen muchas de las piezas que usted se encontraría escribiendo, sino que también incluyen soluciones a problemas con los que se encontrará más adelante. Esto supone un ahorro de tiempo cuyo valor no debes subestimar.

    Entonces, ¿dónde probablemente necesitarás un marco MV* y dónde no?

    Si está escribiendo una aplicación que probablemente solo se comunicará con una API o un servicio de datos de back-end, donde gran parte del trabajo pesado para ver o manipular esos datos se realizará en el navegador, es posible que encuentre un marco JavaScript MV*. útil.

    Buenos ejemplos de aplicaciones que entran en esta categoría son GMail y Google Docs . Estas aplicaciones normalmente descargan una única carga útil que contiene todos los scripts, hojas de estilo y marcas que los usuarios necesitan para tareas comunes y luego realizan muchos comportamientos adicionales en segundo plano. Es trivial cambiar entre leer un correo electrónico o documento y escribir uno y no es necesario pedirle a la aplicación que vuelva a representar la página completa.

    Sin embargo, si está creando una aplicación que aún depende del servidor para la mayor parte del trabajo pesado de Vistas/páginas y solo está usando un poco de JavaScript o jQuery para hacer las cosas un poco más interactivas, un marco MV puede ser excesivo. Ciertamente, existen aplicaciones web complejas en las que la representación parcial de las vistas puede* combinarse con una aplicación de una sola página de manera efectiva, pero para todo lo demás, es posible que le resulte mejor optar por una configuración más simple.

    El desafío de elegir: ¿demasiadas opciones?

    La comunidad JavaScript ha experimentado una especie de renacimiento en los últimos años, y los desarrolladores crean aplicaciones aún más grandes y complejas a medida que pasa el tiempo. El lenguaje todavía difiere mucho de los lenguajes más clásicos que los ingenieros de software están acostumbrados a usar (C++, Java), así como de los lenguajes utilizados por los desarrolladores web (PHP, Python, .Net, etc.). Esto significa que en muchos casos estamos tomando prestados conceptos sobre cómo estructurar aplicaciones de lo que hemos visto hecho en el pasado en estos otros lenguajes.

    En mi charla “ Digerir JavaScript MVC: abuso de patrones o evolución ”, mencioné que actualmente hay demasiadas opciones cuando se trata de qué usar para estructurar su aplicación JavaScript. Parte de este problema se debe a cómo los diferentes desarrolladores de JavaScript interpretan cómo se debe organizar una aplicación JavaScript escalable: ¿MVC? ¿MVP? ¿MVVM? ¿Algo más? Esto lleva a que se creen más marcos con una visión diferente de MV* cada semana y, en última instancia, a más ruido porque todavía estamos tratando de establecer la "forma correcta" de hacer las cosas, si es que existe. Muchos desarrolladores creen que no es así.

    Nos referimos al estado actual de los nuevos marcos que aparecen con frecuencia como "Otro síndrome más del marco" (o YAFS). Si bien la innovación es, por supuesto, algo que deberíamos agradecer, YAFS puede generar una gran confusión y frustración cuando los desarrolladores simplemente quieren comenzar a escribir una aplicación pero no quieren evaluar manualmente 30 opciones diferentes para seleccionar algo que se pueda mantener. En muchos casos, las diferencias entre algunos de estos marcos pueden ser muy sutiles, si no difíciles de distinguir.

     

    TodoMVC: una aplicación común para el aprendizaje y la comparación

    Ha habido un gran auge en el número de frameworks MV* lanzados en los últimos años.

    Backbone.js , Ember.js , AngularJS, Spine , CanJS … La lista de soluciones nuevas y estables continúa creciendo cada semana y los desarrolladores pueden perderse rápidamente en un mar de opciones. De mentes que han tenido que trabajar en aplicaciones complejas que inspiraron estas soluciones (como Yehuda Katz y Jeremy Ashkenas ), existen muchos contendientes fuertes sobre lo que los desarrolladores deberían considerar usar. La pregunta es, ¿qué usar y cómo elegir?

    Entendimos esta frustración y queríamos ayudar a los desarrolladores a simplificar su proceso de selección tanto como fuera posible. Para ayudar a resolver este problema, creamos TodoMVC , un proyecto que ofrece la misma aplicación Todo implementada en la mayoría de los marcos JavaScript MV* populares de la actualidad. Considérelo como una cita rápida para marcos. Las soluciones se ven y se sienten iguales, tienen un conjunto de características comunes y nos facilitan comparar la sintaxis y la estructura de diferentes marcos, para que podamos seleccionar aquel con el que nos sentimos más cómodos o, al menos, reducir nuestras opciones.

    Esta semana lanzaremos una nueva versión de TodoMVC , sobre la cual puedes encontrar más detalles más abajo en la sección de aplicaciones.

    En un futuro cercano queremos llevar este trabajo aún más lejos, brindando guías sobre en qué se diferencian los marcos y recomendaciones sobre qué opciones considerar para tipos particulares de aplicaciones que desee crear.

    Nuestros criterios sugeridos para seleccionar un marco

    Por supuesto, seleccionar un marco implica algo más que simplemente comparar las implementaciones de la aplicación Todo. Es por eso que, una vez que hayamos filtrado nuestra selección de marcos potenciales a solo unos pocos, se recomienda dedicar algo de tiempo a hacer un poco de diligencia debida. Es posible que el marco que elijamos deba admitir la creación de funciones no triviales y podría terminar utilizándose para mantener la aplicación en los años venideros.

    • ¿De qué es realmente capaz el marco? Dedique tiempo a revisar tanto el código fuente del marco como la lista oficial de características para ver qué tan bien se ajustan a sus requisitos. Habrá proyectos que pueden requerir modificar o ampliar la fuente subyacente y, por lo tanto, asegúrese de que, si este fuera el caso, haya realizado la debida diligencia en el código.
    • ¿Se ha probado el marco en producción? es decir, ¿los desarrolladores realmente han creado e implementado aplicaciones grandes que sean de acceso público? Backbone tiene una sólida cartera de estos (SoundCloud, LinkedIn), pero no todos los marcos la tienen. Ember se utiliza en varias aplicaciones grandes, incluidas las herramientas de usuario de Square. JavaScriptMVC se ha utilizado para impulsar aplicaciones en IBM, entre otros lugares. No sólo es importante saber que un marco funciona en producción, sino también poder observar el código del mundo real e inspirarse en lo que se puede construir con él.
    • ¿Está maduro el marco? Generalmente recomendamos a los desarrolladores que no se limiten a "elegir uno y seguirlo". Los nuevos proyectos suelen generar muchos rumores en torno a sus lanzamientos, pero recuerde tener cuidado al seleccionarlos para usarlos en una aplicación de nivel de producción. No querrás arriesgarte a que el proyecto quede estancado, pasando por períodos importantes de refactorización u otros cambios importantes que tienden a planificarse con más cuidado cuando un marco está maduro. Los proyectos maduros también tienden a tener documentación más detallada disponible, ya sea como parte de sus documentos oficiales o impulsados ​​por la comunidad.
    • ¿Es el marco flexible u obstinado? Sepa qué sabor busca, ya que hay muchos marcos disponibles que proporcionan uno u otro. Los marcos obstinados te bloquean (o te sugieren) que hagas las cosas de una manera específica (la de ellos). Por diseño son limitantes, pero ponen menos énfasis en que el desarrollador tenga que descubrir cómo deberían funcionar las cosas por sí solo.
    • ¿Realmente has jugado con el marco? Escriba una pequeña aplicación sin utilizar marcos y luego intente refactorizar su código con un marco para confirmar si es fácil trabajar con él o no. Por mucho que investigar y leer sobre el código influya en su decisión, es igualmente importante escribir código real utilizando el marco para asegurarse de que se sienta cómodo con los conceptos que impone.
    • ¿El marco tiene un conjunto completo de documentación? Aunque las aplicaciones de demostración pueden ser útiles como referencia, casi siempre te encontrarás consultando los documentos oficiales del marco para descubrir qué admite su API, cómo se pueden crear tareas o componentes comunes con ella y cuáles son los problemas que vale la pena destacar. Cualquier marco que valga la pena debe tener un conjunto detallado de documentación que ayude a guiar a los desarrolladores a usarlo. Sin esto, puede depender en gran medida de los canales de IRC, los grupos y el autodescubrimiento, lo cual puede estar bien, pero a menudo consume demasiado tiempo en comparación con un gran conjunto de documentos proporcionados por adelantado.
    • ¿Cuál es el tamaño total del marco, teniendo en cuenta la minificación, el gzipping y cualquier edificio modular que admita? ¿Qué dependencias tiene el marco? Los marcos tienden a enumerar solo el tamaño total de la biblioteca base, pero no enumeran los tamaños de las dependencias de las bibliotecas. Esto puede significar la diferencia entre optar por una biblioteca que inicialmente parece bastante pequeña, pero que podría ser relativamente grande si, por ejemplo, depende de jQuery y otras bibliotecas.
    • ¿Ha revisado la comunidad en torno al marco? ¿Existe una comunidad activa de contribuyentes y usuarios del proyecto que podrían ayudarlo si tiene problemas? ¿Han estado usando el marco suficientes desarrolladores como para que existan aplicaciones de referencia, tutoriales y tal vez incluso screencasts que pueda usar para aprender más sobre él?

    Dojo y el auge de los marcos de JavaScript

    Como muchos de nosotros sabemos, el kit de herramientas Dojo fue uno de los primeros esfuerzos para brindar a los desarrolladores un medio para desarrollar aplicaciones más complejas y algunos podrían decir que en parte nos inspiró a pensar más en las necesidades de las aplicaciones no triviales. Me senté para preguntarle a Dojos Dylan Schiemann , Kitson Kelly y James Thomas qué pensaban sobre el auge de los marcos JavaScript MV*. Blog sopper tappers

     

     

    P: ¿Dojo ya no resolvió todo esto? ¿Por qué no ha sido la solución dominante para los desarrolladores que desean crear aplicaciones más estructuradas (y menos triviales)?

    Hace años, mientras el panorama de JavaScript evolucionaba desde la adición de Ajax y Chrome simples a una página, Dojo estaba evangelizando un enfoque de “juego de herramientas” para crear aplicaciones web complejas.

    Muchas de esas características estaban muy por delante de las necesidades de la mayoría de los desarrolladores. Con el surgimiento del navegador como plataforma de aplicaciones dominante, muchas de las innovaciones iniciadas en The Dojo Toolkit ahora aparecen en kits de herramientas más nuevos. MVC era solo otro paquete que Dojo ha proporcionado durante bastante tiempo, junto con paquetes de código modular, OO en JS, widgets de interfaz de usuario, gráficos para varios navegadores, plantillas, internacionalización, accesibilidad, almacenes de datos, marcos de prueba, un sistema de compilación y mucho más. mucho más.

    Las bibliotecas de JavaScript no deberían terminar en "consulta", razón por la cual Dojo, desde el principio, se centró en completar el panorama para el desarrollo de aplicaciones de nivel empresarial. Este es el mismo enfoque que se tiene hoy con MVC, es simplemente otra “herramienta en el arsenal”.

    ¿Por qué Dojo no es el conjunto de herramientas dominante? Su objetivo nunca fue ser la única opción. El objetivo era proporcionar una colección abierta de herramientas que pudieran usarse con cualquier otra cosa, dentro de proyectos, y también copiarse libremente en otros trabajos. Dojo fue criticado por ser lento e incluso después de que se abordó eso, fue criticado por ser lento. Tratar de sacudir esa percepción es un desafío. Es muy difícil documentar un conjunto de herramientas rico en funciones. Hay 175 subpaquetes en Dojo 1.8 y más de 1400 módulos.

    Esto no es sólo un desafío desde el punto de vista de la documentación, también significa que Dojo no hace nada. Lo cual es bueno si estás creando software, pero es muy difícil cuando estás empezando y tratando de descubrir por dónde empezar. Todas estas son cosas en las que hemos estado intentando trabajar para Dojo 1.8, en forma de tutoriales y documentación significativamente mejorada.

    P: ¿Por qué los desarrolladores deberían seguir considerando Dojo y qué ideas tienen preparadas para el futuro del proyecto? He oído que la versión 1.8 será otro hito importante.

    En Dojo 1.8, dojox/mvc da un paso más hacia la madurez total. Se ha invertido mucho tiempo, esfuerzo, pruebas y concientización de la comunidad en el paquete. Se centra en proporcionar un modelo MVC que aproveche el resto de Dojo. Junto con dojox/app, un marco de aplicación diseñado para facilitar la creación de aplicaciones enriquecidas en escritorio y dispositivos móviles, crea un marco holístico para crear una aplicación del lado del cliente.

     

    En la forma típica de Dojo, esta es sólo una de las muchas formas viables de crear aplicaciones con Dojo.

    En 1.8, el submódulo MVC no solo se vuelve más maduro, sino que también se basa en un marco sólido. No solo le brinda un lenguaje de marcado para crear sus vistas, expresar sus modelos o desarrollar un controlador. Es mucho más que simplemente conectar algunos controles a una fuente de datos. Como aprovecha el resto de Dojo, puedes incorporar cualquier otra cosa que necesites.

    En Dojo 2.0 buscaremos llevar la modularidad a un nuevo nivel, para que sea aún más fácil tomar un poco de esto y un poco de aquello y unirlo todo. También estamos explorando los conceptos de isomorfismo, donde debería ser transparente para el usuario final dónde se ejecuta su código, ya sea del lado del cliente o del servidor y, en última instancia, debería ser transparente para el desarrollador.

    La colección TodoMVC

    En nuestra nueva versión, ahora existen implementaciones de Todo para los marcos más populares y en los laboratorios se está trabajando en una gran cantidad de otros marcos de uso común. Estas implementaciones han pasado por muchas revisiones, a menudo incorporando sugerencias y consejos de mejores prácticas de los autores, contribuyentes y usuarios del marco de la comunidad.

    Siguiendo los comentarios realizados anteriormente por el autor de Backbone.js, Jeremey Ashkenas y Yehuda Katz, TodoMVC ahora también ofrece implementaciones consistentes basadas en una especificación oficial de la aplicación, así como enrutamiento (o administración de estado).

    No pretendemos que las aplicaciones de aprendizaje más complejas no sean posibles (ciertamente lo son), pero la simplicidad de una aplicación Todo permite a los desarrolladores revisar áreas como la estructura del código, la sintaxis de los componentes y el flujo, que creemos que son suficientes para permitir una comparación entre marcos y provocar una mayor exploración con una solución particular o un conjunto de soluciones.

    Nuestras aplicaciones incluyen:

    • columna vertebral.js
    • ascua.js
    • angularjs
    • columna vertebral.js
    • KnockoutJS (MVVM)
    • dojo
    • Yui
    • batman.js
    • Cierre
    • Agilidad.js
    • Derribo.js

    Para aquellos interesados ​​en las versiones de AMD:

    • Backbone.js + RequireJS (usando AMD)
    • Ember.js + RequireJS (usando AMD)

    Y nuestros laboratorios incluyen:

    • canjs
    • maria.js
    • cujo.js
    • Meteorito
    • SocketStream + jQuery
    • ext.js
    • Sammy.js
    • JavaScriptMVC
    • Kit de herramientas web de Google
    • TropaJS
    • Stapes.js
    • soma.js
    • DUELO
    • fidel
    • Aceitunas
    • PlastronJS
    • Dijon
    • rAppid.js
    • En bancarrota
    • o_O
    • Divertido
    • AngularJS + RequireJS (usando AMD)

    Nota: Hemos implementado una versión de nuestra aplicación Todo usando solo JavaScript y otra usando principalmente convenciones jQuery. Como puede ver, si bien estas aplicaciones son funcionalmente equivalentes a algo que podría escribir con un marco MVC, no hay separación de preocupaciones y el código se vuelve más difícil de leer y mantener a medida que crece la base del código.

     

    Nos sentimos honrados de que durante el año pasado, algunos autores de marcos nos hayan involucrado en discusiones sobre cómo mejorar sus soluciones, ayudándonos a aportar nuestra experiencia con una multitud de soluciones. También hemos avanzado lentamente hacia que TodoMVC sea casi una aplicación de facto que implementan nuevos marcos y esto significa que es más fácil hacer comparaciones iniciales cuando se revisan las opciones.

    Marcos: ¿cuándo utilizar qué?

    Para ayudarlo a comenzar a reducir los marcos para explorar, nos gustaría ofrecerle los siguientes resúmenes de marcos de alto nivel que esperamos lo ayuden a orientarse hacia algunas opciones específicas para probar.

    Quiero algo flexible que ofrezca una solución minimalista para separar preocupaciones en mi aplicación. Debería admitir una capa de persistencia y sincronización RESTful, modelos, vistas (con controladores), comunicación basada en eventos, plantillas y enrutamiento. Debería ser imperativo, permitiendo actualizar la Vista cuando cambia un modelo. Me gustaría que algunas decisiones sobre la arquitectura dependieran de mí. Idealmente, muchas grandes empresas han utilizado la solución para crear aplicaciones no triviales. Como es posible que esté construyendo algo complejo, me gustaría que hubiera una comunidad de extensión activa en torno al marco que ya haya intentado abordar problemas más importantes ( Marionette , Chaplin , Aura , Thorax ). Idealmente, también hay herramientas de andamiaje ( grunt-bbb , brunch ) disponibles para la solución. Utilice Backbone.js.

    Quiero algo que intente abordar el desarrollo de aplicaciones a nivel de escritorio para la web. Debe ser obstinado, modular, admitir una variación de MVC, evitar la necesidad de conectar todo en mi aplicación manualmente, admitir persistencia, propiedades calculadas y tener plantillas de actualización automática (en vivo). Debería admitir una gestión estatal adecuada en lugar de la solución de enrutamiento manual que muchos otros marcos recomiendan utilizar. También debería venir con documentación completa y, por supuesto, plantillas. También debería tener herramientas de andamiaje disponibles (ember.gem, ember for brunch). Utilice Ember.js.

    Quiero algo más liviano que admita plantillas de enlace en vivo, enrutamiento, integración con las principales bibliotecas (como jQuery y Dojo) y que esté optimizado para el rendimiento. También debería admitir una forma de implementar modelos, vistas y controladores. Puede que todavía no se utilice en tantas aplicaciones públicas grandes, pero tiene potencial. Idealmente, la solución debería ser creada por personas que tengan experiencia previa en la creación de muchas aplicaciones complejas. Utilice CanJS.

    Quiero algo declarativo que use la Vista para derivar el comportamiento. Se centra en lograr esto a través de etiquetas y componentes HTML personalizados que especifican las intenciones de su aplicación. Debería admitir ser fácilmente comprobable, administración de URL (enrutamiento) y separación de preocupaciones a través de una variación de MVC. Se necesita un enfoque diferente a la mayoría de los marcos, proporcionando un compilador HTML para crear su propio DSL en HTML. Puede estar inspirado en las próximas funciones de la plataforma web, como los componentes web, y también tiene sus propias herramientas de andamiaje disponibles (angular-seed). Utilice AngularJS.

     

    Quiero algo que me ofrezca una base excelente para crear aplicaciones a gran escala. Debería admitir una infraestructura de widgets madura, módulos que admitan carga diferida y puedan ser asincrónicos, una integración simple con CDN, una amplia gama de módulos de widgets (gráficos, tablas, cuadrículas, etc.) y un fuerte soporte para la internacionalización (i18n, l10n). Debería tener soporte para programación orientada a objetos, MVC y los componentes básicos para crear arquitecturas más complejas. Utilice Dojo.

    Quiero algo que se beneficie de la infraestructura de extensión YUI. Debería admitir modelos, vistas y enrutadores y simplificar la escritura de aplicaciones de múltiples vistas que admitan enrutamiento, transiciones de vistas y más. Si bien es más grande, es una solución completa que incluye widgets/componentes, así como las herramientas necesarias para crear una arquitectura de aplicación organizada. Es posible que tenga herramientas de andamiaje (yuiproject), pero es necesario actualizarlas. Utilice YUI.

    Quiero algo simple que valore las interfaces asincrónicas y que carezca de dependencias. Debería ser obstinado pero flexible sobre cómo crear aplicaciones. El marco debe proporcionar elementos básicos como modelo, vista, controlador, eventos y enrutamiento, sin dejar de ser pequeño. Debe estar optimizado para su uso con CoffeeScript y venir con documentación completa. Utilice la columna vertebral.

    Quiero algo que facilite la creación de interfaces de usuario dinámicas complejas con un modelo de datos subyacente limpio y enlaces declarativos. Debería actualizar automáticamente mi interfaz de usuario en caso de cambios en el modelo mediante enlaces bidireccionales y admitir el seguimiento de dependencia de los datos del modelo. Debería poder usarlo con cualquier marco que prefiera, o incluso con una aplicación existente. También debería venir con plantillas incorporadas y ser fácilmente extensible. Utilice KnockoutJS.

    Quiero algo que me ayude a crear sitios web y aplicaciones web sencillas. No espero que haya una gran cantidad de código involucrado, por lo que la organización del código no será una gran preocupación. La solución debería abstraer las diferencias del navegador para que pueda concentrarme en las cosas divertidas. Debería permitirme vincular eventos fácilmente, interactuar con servicios remotos, ser extensible y tener una enorme comunidad de complementos. Utilice jQuery.

    ¿Qué piensan los desarrolladores sobre los frameworks más populares?

    Como parte de nuestra investigación sobre los marcos MV* para TodoMVC y este artículo, decidimos realizar una encuesta para reunir las experiencias de quienes utilizan estas soluciones. Preguntamos a los desarrolladores qué marco utilizan con más frecuencia y, lo que es más importante, por qué los recomendarían a otros. También les preguntamos qué sentían que aún faltaba en el proyecto que eligieron.

    Hemos agrupado algunas de las respuestas más interesantes a continuación, por marco.

    ascua.js

    Ventajas: la combinación de plantillas activas y objetos observables ha cambiado la forma en que escribo JavaScript. Puede ser un poco complicado al principio, pero terminas con una buena separación de responsabilidades. Descubrí que una vez que tengo todo configurado, agregar funciones bastante complejas solo requiere un par de líneas de código. Sin Ember, habría sido un infierno implementar estas mismas características. Desventajas: Ember aún no ha llegado a 1.0. Muchas cosas todavía están cambiando, como el enrutador y los datos de Ember. El nuevo sitio web es muy útil, pero todavía no hay tanta documentación para Ember como para otros frameworks, específicamente Backbone. Además, con tanta magia en el marco, puede dar un poco de miedo. Existe el temor de que si algo se rompe no puedas entender exactamente por qué. Ah, y los mensajes de error que te envía Ember a menudo apestan.

    Ventajas: Los factores clave: a) Funciones que me permiten evitar muchos textos repetitivos (fijaciones, propiedades de la computadora, capa de visualización con los manillares geniales). b) el equipo central: soy desarrollador de Rails y conozco el trabajo de Yehuda Katz. Confío en el chico =) Contras: Documentación. Es realmente triste que Ember no tenga buena documentación, tutoriales, screencast como Backbone, Angular u otros frameworks. En este momento, examinamos el código en busca de documentos que no sean los ideales.<






    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    Viaje a través de la jungla MVC de JavaScript

    Viaje a través de la jungla MVC de JavaScript

    Patrones de diseño de interfaces inteligentes, vídeo de 10h + formación UX Clase magistral de CSS moderno avanzado, con Manuel Matuzović Índice

    programar

    es

    https://pseint.es/static/images/programar-viaje-a-traves-de-la-jungla-mvc-de-javascript-801-0.jpg

    2024-04-04

     

    Viaje a través de la jungla MVC de JavaScript
    Viaje a través de la jungla MVC de JavaScript

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20