Que fait AngularJS mieux que jQuery?

J’utilise principalement la bibliothèque jQuery et je viens juste de commencer à utiliser AngularJS. J’ai lu quelques didacticiels sur l’ utilisation d’Angular, mais je ne sais pas pourquoi ou quand l’utiliser, ni quels sont les avantages que je pourrais trouver par rapport à l’utilisation de jQuery.

Il me semble qu’Angular vous fait penser à MVC, ce qui signifie peut-être que vous visualisez votre page Web comme une combinaison modèle + données. Vous utilisez {{data bindings}} chaque fois que vous pensez avoir des données dynamics. Angular vous fournira alors un gestionnaire $ scope, que vous pourrez renseigner de manière statique ou via des appels au serveur Web. Cela ressemble de manière caractéristique à la manière de concevoir les pages Web JSP. Ai-je besoin d’Angular pour cela?

Pour les manipulations de DOM simples, qui n’impliquent pas de manipulation de données (par exemple: changements de couleur sur le mousehover, masquage / affichage d’éléments sur un clic), jQuery ou vanilla JS est suffisant et plus propre. Cela suppose que le modèle du fichier mvc d’ angular est tout ce qui reflète les données de la page . Par conséquent, les propriétés CSS, telles que la couleur, l’affichage / masquage, les modifications, n’affectent pas le modèle . Est-ce qu’Angular présente des avantages par rapport aux manipulations JQuery ou JS vanilla pour DOM?

Que peut faire Angular qui le rend utile pour le développement par rapport à ce que jQuery peut faire avec les plugins?

Liaison de données

Vous faites le tour de votre page Web et vous continuez à mettre {{data bindings}} à chaque fois que vous pensez avoir des données dynamics. Angular vous fournira alors un gestionnaire $ scope, que vous pourrez remplir (de manière statique ou via des appels au serveur Web).

Ceci est une bonne compréhension de la liaison de données. Je pense que vous l’avez compris.

Manipulation DOM

Pour les manipulations DOM simples, qui n’impliquent pas de manipulation de données (par exemple: changements de couleur sur le mousehover, masquage / affichage d’éléments sur un clic), jQuery ou old-school js est suffisant et plus propre. Cela suppose que le modèle dans mvc angular est tout ce qui reflète les données sur la page, et par conséquent, les propriétés css telles que la couleur, l’affichage / masquer, etc., les modifications n’affectent pas le modèle.

Je peux voir votre point ici sur la “simple” manipulation de DOM étant plus propre, mais que rarement et il devrait être vraiment “simple”. Je pense que la manipulation de DOM est un des domaines, tout comme la liaison de données, où Angular brille vraiment. Comprendre cela vous aidera également à voir comment Angular considère ses vues.

Je commencerai par comparer la voie angular à une approche vanille de la manipulation de DOM. Traditionnellement, nous pensons que le HTML ne «fait» rien et l’écrit comme tel. Donc, les inline js, comme “onclick”, etc. sont une mauvaise pratique car ils placent le “faire” dans le contexte du HTML, ce qui ne “fait” pas. Angular retourne ce concept sur sa tête. Lorsque vous écrivez votre sharepoint vue, vous considérez le HTML comme capable de “faire” beaucoup de choses. Cette capacité est abstraite dans des directives angulars, mais si elles existent déjà ou si vous les avez écrites, vous n’avez pas à considérer “comment” cela est fait, vous utilisez simplement la puissance mise à votre disposition dans ce HTML “augmenté” angular vous permet d’utiliser. Cela signifie également que toute votre logique de vue est réellement contenue dans la vue, et non dans vos fichiers javascript. Encore une fois, le raisonnement est que les directives écrites dans vos fichiers javascript peuvent être considérées comme augmentant la capacité du HTML, donc vous laissez le DOM se soucier de se manipuler (pour ainsi dire). Je vais démontrer avec un exemple simple.

C’est le balisage que nous voulons utiliser. Je lui ai donné un nom intuitif.

 

Tout d’abord, je voudrais juste dire que si nous avons donné cette fonctionnalité à notre HTML via une directive angular personnalisée, nous en avons déjà terminé . C’est une bouffée d’air frais. Plus sur cela dans un instant.

Mise en œuvre avec jQuery

démo en direct ici (cliquez).

 function rotate(deg, elem) { $(elem).css({ webkitTransform: 'rotate('+deg+'deg)', mozTransform: 'rotate('+deg+'deg)', msTransform: 'rotate('+deg+'deg)', oTransform: 'rotate('+deg+'deg)', transform: 'rotate('+deg+'deg)' }); } function addRotateOnClick($elems) { $elems.each(function(i, elem) { var deg = 0; $(elem).click(function() { deg+= parseInt($(this).attr('rotate-on-click'), 10); rotate(deg, this); }); }); } addRotateOnClick($('[rotate-on-click]')); 

Mise en œuvre avec angular

démo en direct ici (cliquez).

 app.directive('rotateOnClick', function() { return { ressortingct: 'A', link: function(scope, element, attrs) { var deg = 0; element.bind('click', function() { deg+= parseInt(attrs.rotateOnClick, 10); element.css({ webkitTransform: 'rotate('+deg+'deg)', mozTransform: 'rotate('+deg+'deg)', msTransform: 'rotate('+deg+'deg)', oTransform: 'rotate('+deg+'deg)', transform: 'rotate('+deg+'deg)' }); }); } }; }); 

Assez légère, très propre et c’est juste une manipulation simple! À mon avis, l’approche angular l’emporte à tous égards, en particulier sur la manière dont la fonctionnalité est abstraite et la manipulation de dom est déclarée dans le DOM. La fonctionnalité est accrochée à l’élément via un atsortingbut html, il n’y a donc pas besoin d’interroger le DOM via un sélecteur, et nous avons deux belles fermetures – une fermeture pour la fabrique de directives où les variables sont partagées pour tous les usages de la directive et une fermeture pour chaque utilisation de la directive dans la fonction link (ou fonction de comstack ).

La liaison de données bidirectionnelle et les directives pour la manipulation DOM ne sont que le début de ce qui rend Angular génial. Angular encourage tous les codes à être modulaires, réutilisables et facilement testables et comprend également un système de routage d’applications à une seule page. Il est important de noter que jQuery est une bibliothèque de méthodes de navigation / de navigation polyvalentes, mais Angular est une infrastructure complète pour créer des applications à une seule page. Le script angular inclut en fait sa propre version “lite” de jQuery afin que certaines des méthodes les plus essentielles soient disponibles. Par conséquent, vous pouvez avancer qu’utiliser Angular IS en utilisant jQuery (légèrement), mais Angular fournit beaucoup plus de «magie» pour vous aider dans le processus de création d’applications.

Ceci est un excellent post pour plus d’informations connexes: Comment est-ce que je “pense dans AngularJS” si j’ai un arrière-plan jQuery?

Différences générales

Les points ci-dessus visent les préoccupations spécifiques du PO. Je vais aussi donner un aperçu des autres différences importantes. Je suggère de faire des lectures supplémentaires sur chaque sujet également.

Angular et jQuery ne peuvent raisonnablement être comparés.

Angular est un framework, jQuery est une bibliothèque. Les frameworks ont leur place et les bibliothèques ont leur place. Cependant, il ne fait aucun doute qu’un bon cadre a plus de pouvoir pour écrire une application qu’une bibliothèque. C’est exactement le but d’un cadre. Nous vous invitons à écrire votre code en langage JS, ou vous pouvez append une bibliothèque de fonctions communes, ou vous pouvez append une structure pour réduire considérablement le code nécessaire pour accomplir la plupart des tâches. Par conséquent, une question plus appropriée est la suivante:

Pourquoi utiliser un framework?

De bons frameworks peuvent aider à architecturer votre code de manière à ce qu’il soit modulaire (donc réutilisable), DRY, lisible, performant et sécurisé. jQuery n’est pas un framework, donc ça n’aide pas à cet égard. Nous avons tous vu les murs typiques du code spaghetti jQuery. Ce n’est pas la faute de jQuery – c’est la faute des développeurs qui ne savent pas comment concevoir du code. Cependant, si les développeurs savaient comment architecturer du code, ils finiraient par écrire une sorte de “framework” minimal pour fournir la base (architecture, etc.) dont j’ai parlé il y a un instant, ou bien ils appendaient quelque chose. pourrait append RequireJS pour agir dans le cadre de votre framework pour écrire du bon code.

Voici quelques éléments que les frameworks modernes fournissent:

  • Templating
  • Liaison de données
  • routage (application d’une seule page)
  • architecture propre, modulaire et réutilisable
  • Sécurité
  • fonctions / caractéristiques supplémentaires pour plus de commodité

Avant de discuter de Angular, j’aimerais souligner qu’Angular n’est pas le seul en son genre. Durandal, par exemple, est un framework construit sur jQuery, Knockout et RequireJS. Encore une fois, jQuery ne peut pas, à lui seul, fournir ce que Knockout, RequireJS et l’ensemble de la structure peuvent créer. C’est juste pas comparable.

Si vous devez détruire une planète et que vous avez une écanvas de la mort, utilisez l’écanvas de la mort.

Angulaire (revisité).

En me basant sur les points précédents concernant les frameworks, je voudrais vous féliciter de la manière dont Angular les fournit et essayer de clarifier pourquoi il s’agit d’une question factuellement supérieure à celle de jQuery.

Référence DOM.

Dans mon exemple ci-dessus, il est absolument inévitable que jQuery doive être connecté au DOM pour fournir des fonctionnalités. Cela signifie que la vue (html) concerne les fonctionnalités (car elle est étiquetée avec une sorte d’identifiant – comme “slider image”) et JavaScript est soucieux de fournir cette fonctionnalité. Angular élimine ce concept via l’abstraction. Un code correctement écrit avec Angular signifie que la vue peut déclarer son propre comportement. Si je veux afficher une horloge:

  

Terminé.

Oui, nous devons aller à JavaScript pour faire en sorte que cela signifie quelque chose, mais nous le faisons à l’inverse de l’approche jQuery. Notre directive angular (qui se trouve dans son propre petit monde) a “augmenté” le html et le html lui-même.

MVW Architecure / Modules / Dependency Injection

Angular vous offre un moyen simple de structurer votre code. Les éléments de vue appartiennent à la vue (html), la fonctionnalité de vue augmentée appartient aux directives, les autres logiques (comme les appels ajax) et les fonctions appartiennent aux services, et la connexion des services et de la logique à la vue appartient aux contrôleurs. Il existe également d’autres composants angulars qui aident à la configuration et à la modification des services, etc. Toutes les fonctionnalités que vous créez sont automatiquement disponibles partout où vous en avez besoin via le sous-système Injector. Lors de l’écriture d’une application (module), je la décompose en d’autres modules réutilisables, chacun avec ses propres composants réutilisables, puis les inclut dans le projet plus grand. Une fois que vous avez résolu un problème avec Angular, vous l’avez résolu d’une manière utile et structurée pour pouvoir être réutilisée ultérieurement et facilement incluse dans le prochain projet. Un bonus énorme à tout cela est que votre code sera beaucoup plus facile à tester.

Ce n’est pas facile de faire que les choses “fonctionnent” dans Angular.

DIEU MERCI. Le code spaghetti jQuery mentionné ci-dessus est le résultat d’un développeur qui a fait fonctionner quelque chose et qui a ensuite évolué. Vous pouvez écrire un mauvais code angular, mais il est beaucoup plus difficile de le faire, car Angular vous combattra. Cela signifie que vous devez tirer parti (au moins quelque peu) de l’architecture propre qu’elle offre. En d’autres termes, il est plus difficile d’écrire du code incorrect avec Angular, mais plus pratique pour écrire du code propre.

Angular est loin d’être parfait. Le monde du développement Web ne cesse de grandir et d’évoluer et de nouvelles méthodes plus efficaces sont mises au point pour résoudre les problèmes. Par exemple, React et Flux de Facebook présentent de grands avantages par rapport à Angular, mais présentent des inconvénients. Rien n’est parfait, mais Angular a été et est toujours génial pour le moment. Tout comme jQuery a aidé le monde du Web à progresser, il en a été de même pour Angular.