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

Question

He estado utilizando knockout.js durante algunos meses, y me resulta 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 realmente 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 un problema con eso. 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

Desde mi (corto) comparison of Knockout and Backbone:

Knockout tiene como objetivo proporcionar mancha, fácil de usar fijaciones modelo entre el HTML y 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 todos de la estructura más allá del enlace de datos y los modelos.

Answer 2

Encontrará que las tendencias de las aplicaciones web, al igual que las tendencias de la moda, provocan una gran cantidad de discusiones con opiniones. 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 tiene 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. I wrote a blog entry about this, con algunos ejemplos, si desea obtener más información.

En cuanto al impacto en el rendimiento del nocaut en grandes departamentos de ultramar complejos, puede evitar que al restringir sus fijaciones a los elementos DOM específicos en lugar de aplicar a nivel mundial:

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.

Considerando que ni Backbone.js ni Knockout.js han recomendado la estructura de directorios, o la metodología recomendada de gestión del ciclo de vida y cualquier funcionalidad faltante en una con respecto a otra puede completarse con complementos compatibles con la comunidad o microframeworks independientes, hay No tiene sentido 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, usar Angular.js puede ser más adecuado que Knockout.js si prefiere el enfoque declarativo, el atributo de DOM basado en el enlace de datos y el patrón MVVM, y Ember.js puede ser más adecuado que Backbone.js si prefieres MVC y plantillas basadas en cadenas (Handlebars). 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.