javascript - ¿Por qué knockout.js tiene una reputación de ser mejor para proyectos pequeños, backbone.js para grande?

Question

He estado usando knockout.js durante unos meses, y encuentro que es una alegría diaria de usar. Las ventajas de no tener que administrar el estado en el dom o aplicar sus propios enlaces personalizados es increíble, y no me importa no tener características del modelo fuera de la caja. Pero cada vez que leo una visión general de knockout.js frente a otros marcos, el consenso parece ser que es genial, resulta en menos código y complejidad en general, pero es más adecuado para proyectos más pequeños. Esta declaración siempre se da como una cuestión de hecho, sin mucha explicación, así que estoy confundido en cuanto a lo que parece ser el consenso. (Para ser justos, aún no he usado Backbone y no sé cómo se comparan)

Lo he usado en dos proyectos bastante grandes, cada uno con una docena de modelos y una docena de modelos de vista más o menos, y no he visto ningún problema. El único inconveniente que puedo ver contra el Backbone en un proyecto grande es que obtendrás un rendimiento no despreciable para aplicar el knockout y administrar todas las vinculaciones. ¿Pero esa es la principal preocupación o hay algo más que me falta?

Answer 1

De mi (breve) comparación de Knockout y Backbone :

Knockout tiene como objetivo proporcionar enlaces de modelos ingeniosos y fáciles de usar entre el HTML y el Modelo. Es muy similar a XAML / Silverlight / WPF en sus patrones de implementación y uso (esto tiene sentido teniendo en cuenta de dónde viene). Knockout no proporciona orientación o construcciones más allá del modelo, sin embargo. Depende de los desarrolladores crear aplicaciones de JavaScript bien estructuradas más allá de los modelos y las asociaciones de modelos. Esto a menudo lleva a los desarrolladores sin una buena experiencia de JavaScript por un mal camino porque no se dan cuenta de que necesitan considerar una buena estructura de aplicación cuando usan Knockout. Por supuesto, este problema no es culpa de Knockout de ninguna manera. Simplemente es una falta de comprensión de lo que ofrece la herramienta, o cómo estructurar grandes aplicaciones de JavaScript, en muchos casos.

Personalmente, no me gusta Knockout. No soy fanático del patrón MVVM. Prefiero el enfoque de Backbone y paso la mayor parte del tiempo trabajando con eso. Sin embargo, creo que las opiniones "de hecho" sobre Knockout no son adecuadas para grandes aplicaciones, están equivocadas. Puede construir aplicaciones muy grandes, complejas y bien estructuradas con Knockout. Pero debe proporcionar toda la estructura más allá del enlace de datos y los modelos.

Answer 2

Descubrirá que las tendencias de las aplicaciones web, al igual que las tendencias de la moda, provocan muchas discusiones obstinadas. La mayoría de las veces, no hay una respuesta correcta o incorrecta. Pero todos tienen su propio estilo personal, y solo debes encontrar el tuyo.

Personalmente, me gustan tanto Knockout como Backbone y me complació saber que en realidad no tienes que elegir entre ellos; puedes usar un complemento llamado "Knockback" que los une muy bien.

Disfruto de la estructura MVP de Backbone, con los enlaces declarativos de Knockout. Escribí una entrada de blog sobre esto , con algunos ejemplos, si desea obtener más información.

En cuanto al golpe de rendimiento de Knockout en DOM complejos de gran tamaño, puedes solucionarlo restringiendo tus enlaces a elementos DOM específicos en lugar de aplicarlos globalmente:

ko.applyBindings(myViewModel, $(''#myElement'')[0]);

El [0] al final es necesario porque Knockout espera un elemento DOM, y no un objeto jQuery como el segundo parámetro.

Answer 3

La organización de código de las aplicaciones javascript a gran escala es un problema desafiante y es bastante independiente de qué marco utiliza, a menos que el marco proporcione mucha estructuración obstinada.

Teniendo en cuenta que ni Backbone.js ni Knockout.js han recomendado la estructura de directorios, ni la metodología recomendada de gestión del ciclo de vida y cualquier funcionalidad faltante que exista en una con respecto a otra se puede completar con complementos compatibles con la comunidad o microframeworks independientes, no hay ningún punto al considerar uno como superior a otro en el contexto del tamaño / complejidad de la aplicación.

En una nota lateral, si uno está comenzando con una aplicación de javascript a gran escala en este momento, usar Angular.js puede ser más adecuado que Knockout.js si prefiere el enfoque declarativo, el empate de datos basado en atributos DOM y el patrón MVVM, y Ember.js puede ser más adecuado que Backbone.js si prefiere plantillas MVC y basadas en cuerdas (manubrios). Ambos están en desarrollo activo y se comparan hombro a hombro con respecto a las características, y fueron diseñados específicamente para aliviar los problemas que las personas han tenido que enfrentar al trabajar con aplicaciones grandes con estructuras más pequeñas como Backbone y Knockout, que vinieron antes.