Je suis un développeur web et je commence à développer une application web à grande échelle, mais je ne sais pas quel cadre à utiliser. Je pensais à Angular.js, mais j’ai également examiné Backbone.js. Pour vous, quel serait le meilleur cadre ? ou du moins avoir une comparaison entre les deux pour voir la performance.
Réponses
Trop de publicités?
Quelqu'un ici prétendant qu'une solution est plus rapide ou plus lent que les autres n'en savent pas beaucoup au sujet de ces bibliothèques ou de cadres (ou tests de perf en général) ou est un menteur.
La Performance est très difficile caractéristique à mesurer à cause des nombreuses variables qui influent sur elle. Juste pour en nommer quelques-uns:
- la qualité de l'essai et de référence code
- la qualité de la bibliothèque ou du code de la structure de
- type de demande
- la qualité de l'application du code
- navigateur utilisé
- client hw
- d'autres processus en cours d'exécution dans le même temps sur le client hw
- la qualité et la vitesse de la connexion internet
- la charge du serveur et les performances du serveur
- et la liste continue encore et encore...
mais plus important encore, que voulez-vous dire exactement par la performance? la performance est un terme très large qui couvre trop de choses, y compris:
- temps qu'il faut pour l'amorçage de l'application
- le temps qu'il faut pour répondre à une action de l'utilisateur
- l'utilisation des ressources (cpu/mémoire/réseau)
- la performance de manipulation du dom fait par la bibliothèque/cadre/le code de l'application
- garbage collector amitié
- et là encore, la liste continue encore et encore...
La meilleure façon de répondre à votre question, c'est de créer une application qui est bien représentative de l'application vous avez l'intention de construire et de mettre en œuvre avec la concurrence librairies/frameworks. Ensuite, écrivez une qualité benchark qui permettra de les comparer en tête à tête dans un environnement stable.
C'est évidemment une tâche laborieuse et seulement quelqu'un avec beaucoup en jeu serait de l'entreprendre.
Il existe cependant une autre solution à ce problème: comprendre le cadre/la bibliothèque que vous utilisez et en particulier:
- apprendre la base des flux et des algorithmes que le cadre/la bibliothèque utilise en interne. alors que vous ne doit généralement pas de soins, quand vous entrez dans une perf de problèmes, la compréhension de la façon dont votre application s'exécute, vous permettra de vous identifier et résoudre les problèmes de perf
- vérifier si la performance est quelque chose que la bibliothèque/cadre écrivains ont de l'expertise dans
- vérifier si le cadre/la bibliothèque vous aide à identifier les problèmes de performance et de les corriger
Comme pour la comparaison réelle entre la colonne vertébrale et AngularJS, la comparaison de deux solutions très différentes.
Épine dorsale de ne pas faire de manipulation du dom pour vous, de sorte que la vitesse de votre application dépendra essentiellement de comment bien pouvez-vous faire de manipulation du dom (est-ce votre expertise?).
AngularJS n'est plus de la manipulation du dom pour vous et nous avons une tonne d'expertise dans ce domaine, sauf si vous êtes vraiment bon, vous aurez un moment difficile d'appariement nous.
Deuxièmement, épine dorsale du modèle de mutation observation est basée sur les événements, le modèle des wrappers et artificielle des getters et setters. Non seulement que cela peut être très inefficace en raison de l'absence d'événement de coalescence (il y a peut être une solution de contournement pour cette dernière épine dorsale versions), mais l'utilisation de l'artificiel getters et setters interfère également avec le compilateur JIT dans votre navigateur.
Misko a écrit un long post sur la façon Angulaire du fait de son magique modèle de mutation de l'observation. Donc, je ne vais pas le répéter ici. Mais en fait, la performance d'une application AngularJS est directement liée au nombre et à la complexité des liaisons utilisées dans la vue actuelle de l'application. Avec cela à l'esprit, vous pouvez facilement prédire Angulaire de la performance. Encore mieux, c'est qu'avec des outils comme AngularJS Batarang extension pour Chrome, nous vous permettent de facilement instrument de votre application et de comprendre ce qui les liaisons sur la page sont lents et cela vous permet de vous concentrer sur la fixation des parties de votre code qui comptent vraiment.
Je vais conclure en disant qu'aucune bibliothèque ou cadre sera la meilleure solution pour votre cas d'utilisation, de sorte que vous devriez en apprendre davantage sur les outils que vous créez vos applications avec et lorsque cela est vraiment nécessaire, de décider qui est le meilleur pour un cas d'utilisation. Mon pari est que pour la plupart des applications que vous allez écrire, la performance n'est pas va sensiblement changer si vous changez de cadre ou de la bibliothèque. Je voudrais donc mettre plus de poids sur d'autres facteurs comme la productivité, la facilité d'utilisation, la testabilité, de la communauté et de la documentation avant que je ne vous soucier de la performance.
Et la dernière chose: les repères sont souvent trompeuses, mais de vérifier celles-ci et de les prendre avec un grain de sel.
-
Backbone + Ember: http://jsfiddle.net/jashkenas/CGSd5/ -
AngularJS: http://jsfiddle.net/mhevery/vYknU/23/
Scuba Josh
Points
91
Vous pouvez faire épine dorsale plus rapide plus facile si vous le strip vers le minimum. J'ai enlevé la dépendance de souligner ou de lodash du backbone rendant façon plus légère et modifié il y a des événements à utiliser bean et à peu près enderjs libs moins de morphée, j'ai troqué pour l'interpolation de la lumière.Je vais vous dire ce son wayyyyy plus vite que angulaires. Le chargement des Pages en millisecondes vs secondes. La chose angulaire est design pattern MVVM est lent parce que vous avez une tonne de direct DOM interaction. Javascript est rapide avec les dom. Il faut donc utiliser le DOM aussi peu que possible et c'est impossible avec MVVM. De son mieux pour avoir votre logique séparée avec de très petites rapide et léger références DOM, l'utilisation de pointeurs quand vous le pouvez est toujours une meilleure option. Je l'ai utilisé et examiné chaque cadre en ligne de bye ligne. Stock vous obtiendrez les mêmes performances de modification est une autre histoire. Épine dorsale de stock est pléthorique et la plupart des moteurs de template sont lents. Donc, utiliser dotjs pour les modèles, l'utilisation d'ender et pas jquery, utiliser bean pour des événements personnalisés. Angulaire a une très lente moteur de template c'est cuit et lourde DOM utilisation le rend encore plus lent... sans parler de toutes les liaisons déclaratives mélangé dans le balisage est difficile à maintenir et à lire. J'ai fait jsperfs sur juste au sujet de chaque cadre et de la bibliothèque connu pour JS-je construire le cadre de vie. Oui, il ya beaucoup de variables qui entrent en jeu, mais si c'est bien fait je choisirais épine dorsale de tous les jours de la semaine. MVVM va mourir... MVP où son à quand il s'agit de l'avant la fin de cadres.
Danny
Points
211
Il y a une autre comparaison de performances entre angulaire et Ember KO ici :
http://jsperf.com/Angular-vs-Knockout-vs-Ember/2
Grand vainqueur dans ce cas est angulaire, mais comme dit précédemment, des tests de performances sont rarement simples ou équitable.
Hasith
Points
1645
jusopi
Points
72
pas forcément une réponse, mais une autre ressource de liaison w/ un générique pour et le contre pour chaque cadre. Je pense qu'Igor Minar dit, c'est vraiment important, se concentrer sur ce qui est facile à apprendre, facile à mettre en œuvre et ne pas obtenir de la manière de votre productivité par rapport à obséder sur la performance.
http://codebrief.com/2012/01/the-top-10-javascript-mvc-frameworks-reviewed/
Pour ce que ça vaut, Angular JS et Ember JS faire appel à moi, principalement en raison de leur utilisation de la liaison est très bien comme Flex mécanisme de liaison (de haut niveau) ET qu'il laisse le code HTML pour la plupart découplée de la contrôleur/modèle logique.
