Pourquoi knockout.js a la réputation d'être meilleur pour les petits projets, backbone.js pour les grands?
J'utilise knockout.js depuis quelques mois et je trouve que c'est un plaisir quotidien à utiliser. Les avantages de ne pas avoir à gérer l'état sur le dom ou à appliquer vos propres liaisons personnalisées sont incroyables, et cela ne me dérange pas de ne pas avoir de fonctionnalités de modèle prêtes à l'emploi. Mais chaque fois que je lis une vue d'ensemble de knockout.js par rapport à d'autres frameworks, le consensus semble être qu'il est génial, il en résulte moins de code et de complexité dans l'ensemble, mais il est mieux adapté aux petits projets. Cette déclaration est toujours donnée en fait, sans grande explication, donc je suis confus quant à ce que semble être le consensus. (Pour être honnête, je n'ai pas encore utilisé Backbone et je ne sais donc pas vraiment comment ils se comparent)
Je l'ai utilisé sur deux projets assez importants, chacun avec environ une douzaine de modèles et une douzaine de modèles de vues ou plus, et je n'ai pas vu de problème avec ça. Le seul inconvénient que je peux voir par rapport à Backbone dans un grand projet est que vous obtiendrez des performances non négligeables pour que l'application Knockout applique et gère toutes les liaisons. Mais est-ce la principale préoccupation ou y a-t-il autre chose qui me manque?
De mon (court) comparaison de Knockout et Backbone :
Knockout vise à fournir des liaisons de modèle lisses et faciles à utiliser entre le HTML et le modèle. C'est très XAML/Silverlight/WPF comme dans ses modèles d'implémentation et d'utilisation (cela a du sens compte tenu de son origine). Knockout ne fournit cependant pas de conseils ou de constructions au-delà du modèle. Il appartient aux développeurs de créer des applications JavaScript bien structurées au-delà des modèles et des liaisons de modèles. Cela conduit souvent les développeurs sans une bonne expérience JavaScript sur une mauvaise voie car ils ne réalisent pas qu'ils doivent considérer une bonne structure d'application lors de l'utilisation de Knockout. Bien sûr, ce problème n'est en aucun cas la faute de Knockout. Il s'agit simplement d'un manque de compréhension de ce que l'outil fournit ou de la façon de structurer de grandes applications JavaScript, dans de nombreux cas.
Personnellement, je n'aime pas Knockout. Je ne suis pas fan du modèle MVVM. Je préfère l'approche de Backbone et je passe la plupart de mon temps à travailler avec. Cependant, je pense que les avis "concrets" sur Knockout ne convenant pas aux grandes applications sont faux. Vous pouvez créer des applications très grandes, complexes et bien structurées avec Knockout. Mais vous devez fournir tous la structure au-delà de la liaison de données et des modèles.
Vous constaterez que les tendances des applications Web, comme les tendances de la mode, spark beaucoup de discussions d'opinion. La plupart du temps, il n'y a pas de bonne ou de mauvaise réponse. Mais tout le monde a son propre style personnel, et il vous suffit de trouver le vôtre.
Personnellement, j'aime Knockout et Backbone et j'ai été ravi d'apprendre que vous n'avez pas vraiment à choisir entre eux; vous pouvez utiliser un plugin appelé "Knockback" qui les relie bien.
J'apprécie la structure MVP de Backbone, avec les liaisons déclaratives de Knockout. J'ai écrit une entrée de blog à ce sujet , avec quelques exemples, si vous souhaitez en savoir plus.
En ce qui concerne les performances de Knockout sur les grands DOM complexes, vous pouvez contourner cela en restreignant vos liaisons à des éléments DOM spécifiques au lieu de les appliquer globalement:
ko.applyBindings(myViewModel, $('#myElement')[0]);
Le [0] à la fin est nécessaire car Knockout attend un élément DOM, et non un objet jQuery comme 2e paramètre.
L'organisation du code des applications javascript à grande échelle est un problème difficile et est assez indépendante du cadre que vous utilisez - à moins que le cadre ne fournisse beaucoup de structuration d'opinion.
Étant donné que ni Backbone.js ni Knockout.js n'ont de structure de répertoire recommandée, ou de méthodologie de gestion du cycle de vie recommandée et toute fonctionnalité manquante dans l'un par rapport à l'autre peut être remplie avec des plugins pris en charge par la communauté ou des microframesworks autonomes, il n'y a vraiment aucun intérêt à considérer l'une comme supérieure à l'autre dans le contexte de la taille/complexité de l'application.
Sur une note latérale si l'on commence avec une application javascript à grande échelle à l'heure actuelle, l'utilisation d'Angular.js peut être plus adaptée que Knockout.js si vous préférez l'approche déclarative, la liaison de données basée sur les attributs DOM et le modèle MVVM, et Ember.js peut être plus adapté que Backbone.js si vous préférez les modèles MVC et basés sur des chaînes (guidons). Les deux sont en développement actif et se comparent côte à côte en ce qui concerne les fonctionnalités, et ont été spécialement conçus pour soulager les problèmes rencontrés par les personnes travaillant avec de grandes applications avec des cadres plus petits comme Backbone et Knockout, qui l'ont précédé.