Pourquoi knockout.js ont la réputation d’être mieux pour les petits projets, backbone.js pour gros ?

Question

J'ai été en utilisant knockout.js pendant quelques mois, et de trouver tous les jours une joie à utiliser. Les gains de ne pas avoir à gérer l'état sur le dom ou d'appliquer vos propres raccourcis clavier est incroyable, et je ne me dérange pas de ne pas avoir sorti de la boîte caractéristiques du modèle. Mais chaque fois que je lis un aperçu de knockout.js vs d'autres cadres, le consensus semble être que c'est génial, il en résulte moins de code et de la complexité dans l'ensemble, mais il est mieux adapté pour les petits projets. Cette déclaration est toujours donnée comme une question de fait, sans trop d'explications, donc je suis confus quant à ce que le consensus semble être. En toute honnêteté je n'ai pas utilisé épine Dorsale encore et ainsi de ne pas vraiment savoir comment ils se comparent)

Je l'ai utilisé sur deux très grands projets, chacun avec environ une dizaine de modèles, et d'une dizaine de vue des modèles, et n'ont pas vu de problème avec elle. Le seul inconvénient que je peux voir vs épine Dorsale dans un grand projet, c'est que vous allez obtenir certains non-négligeable de performances pour avoir knock-out d'appliquer et de gérer l'ensemble des liaisons. Mais est-ce que la préoccupation principale ou est-il autre chose que je suis absent?

Answer 1

De mon (court) comparaison de knock-out et de la colonne vertébrale:

Knock-out vise à fournir lisse, facile à utiliser modèle des liaisons entre le HTML et le Modèle. Il est très XAML/Silverlight/WPF comme dans sa mise en œuvre et des modèles d'utilisation (ce qui est logique compte tenu d'où il vient). Knock-out ne fournit pas de conseils ou de constructions au-delà de la modèle. C'est aux développeurs de construire bien structuré applications JavaScript delà des modèles et des liaisons. Cela conduit souvent les développeurs sans JavaScript de l'expérience d'un mauvais chemin d'accès, car ils ne réalisent pas qu'ils ont besoin d'une bonne structure de l'application lors de l'utilisation de knock-out. Bien sûr, ce problème n'est pas la faute de knock-out par tous les moyens. C'est tout simplement un manque de compréhension de ce que l'outil fournit, ou comment structurer les grandes applications JavaScript, dans de nombreux cas.

Personnellement, je n'aime pas les Huitièmes de finale. Je ne suis pas un fan de la pattern MVVM. Je préfère l'épine Dorsale de l'approche, et je passe la plupart de mon temps à travailler avec elle. Cependant, je pense que la "question de fait" avis sur knock-out ne pas être adapté pour les grandes applications sont mauvais. Vous pouvez construire de très grandes, complexe et bien structuré applications avec knock-out. Mais vous devez fournir l' ensemble de la structure au-delà de la liaison de données et les modèles.

Answer 2

Vous trouverez cette application web tendances, comme les tendances de la mode, de l'étincelle beaucoup de opinions discussions. La plupart du temps, il n'y a pas de bonne ou de mauvaise réponse. Mais tout le monde a son propre style, et vous avez juste à trouver le vôtre.

Personnellement, j'aime les deux knock-out et de la colonne vertébrale et a été heureux d'apprendre que vous n'avez pas à choisir entre les deux; vous pouvez utiliser un plugin appelé "Knockback" qui les relie ensemble gentiment.

J'aime le titre de MVP de la structure de la colonne vertébrale, avec le déclaratif des liaisons de knock-out. J'ai écrit un billet de blog à propos de cette, avec quelques exemples, si vous souhaitez en savoir plus.

Comme pour les performances de knock-out sur grand complexe DOMs, vous pouvez contourner ce problème en limitant vos fixations spécifiques des éléments du DOM au lieu de l'appliquer à l'échelle mondiale:

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

[0] à la fin est nécessaire, car knock-out s'attend à un élément du DOM, et non pas un objet jQuery comme le 2e paramètre.

Answer 3

Code de l'organisation à grande échelle des applications javascript est un problème difficile et est tout à fait indépendant de ce qui cadre que vous utilisez moins de le cadre propose un grand nombre d'opinions de structuration.

Considérant ni Backbone.js ni Knockout.js ont recommandé la structure de répertoire, ou recommandé gestion du cycle de vie de la méthodologie et quelle que soit la fonctionnalité manquante est là, dans l'un relativement à l'autre, ils peuvent être remplis avec soutenue par la communauté, des plugins ou des stand-alone microframeworks, il est sérieusement pas de point en considérant comme supérieur à un autre dans le contexte de la taille et de la complexité de la demande.

Sur une note de côté, si on commence avec une grande échelle javascript de l'application à l'heure actuelle, à l'aide de Angular.js peut-être plus adapté que Knockout.js si vous préférez l'approche déclarative, DOM attribut de base de la liaison de données et le pattern MVVM, et Ember.js peut-être plus adapté que Backbone.js si vous préférez MVC et de chaîne en fonction de (Guidon) modèles. Les deux sont dans une phase active de développement et de comparer l'épaule à l'épaule à l'égard de fonctionnalités, et ont été spécialement conçus pour soulager les problèmes que les gens ont été confrontés à travailler avec des applications de grande taille avec de plus petites structures comme l'épine Dorsale et knock-out, qui est venu avant.