Qu'est-ce qu'AngularJS fait de mieux que jQuery ?

Question

J'ai principalement utilisé la bibliothèque jQuery et je viens de commencer à utiliser AngularJS. J'ai lu quelques tutoriels sur comment d'utiliser Angular, mais je ne sais pas exactement pourquoi ni quand l'utiliser, ni quels avantages 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 voyez votre page web comme une combinaison modèle + données. Vous utilisez {{data bindings}} chaque fois que vous pensez avoir des données dynamiques. Angular vous fournira alors un gestionnaire $scope, que vous pourrez alimenter de manière statique ou par des appels au serveur web. Cette méthode ressemble beaucoup à la méthode JSP de conception des pages Web. Ai-je besoin d'Angular pour cela ?

Pour la simple manipulation du DOM, qui n'est pas pour la manipulation de données (par exemple, changement de couleur au passage de la souris, masquage/affichage d'éléments au clic), jQuery ou vanilla JS est suffisant et plus propre. Cela suppose que le modèle en angulaire mvc es 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/masquage, etc. n'affectent pas l'élément modèle . Angular présente-t-il des avantages par rapport à jQuery ou vanilla JS pour les manipulations du DOM ?

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

Answer 1

Liaison de données

Vous faites votre page web, et vous continuez à mettre des {{data}. bindings}} chaque fois que vous pensez avoir des données dynamiques. Angular va vous fournira alors un gestionnaire $scope, que vous pourrez alimenter (statiquement ou par des appels au serveur web).

Il s'agit d'une bonne compréhension de la liaison de données. Je pense que tu as compris.

Manipulation du DOM

Pour une simple manipulation du DOM, qui n'implique pas de manipulation de données (par exemple : changement de couleur au passage de la souris, masquage/affichage d'éléments au clic), jQuery ou les js de la vieille école sont suffisants et plus propres. Cela suppose que le modèle dans le MVC d'Angular est tout ce qui reflète les données sur la page, et donc, les propriétés css comme la couleur, l'affichage/la dissimulation, etc. n'affectent pas le modèle.

Je comprends votre point de vue sur la manipulation DOM "simple" qui est plus propre, mais seulement rarement et il faudrait qu'elle soit vraiment "simple". Je pense que la manipulation du DOM est l'un des domaines, tout comme le data-binding, où Angular brille vraiment. Comprendre cela vous aidera également à voir comment Angular considère ses vues.

Je commencerai par comparer l'approche d'Angular à celle de vanilla js pour la manipulation du DOM. Traditionnellement, nous considérons que le HTML ne "fait" rien et nous l'écrivons comme tel. Ainsi, les js en ligne, comme "onclick", etc. sont de mauvaises pratiques car ils placent le "faire" dans le contexte du HTML, qui ne "fait" rien. Angular renverse ce concept. Lorsque vous écrivez votre vue, vous pensez que le HTML est capable de "faire" beaucoup de choses. Cette capacité est abstraite dans les directives d'Angular, mais si elles existent déjà ou si vous les avez écrites, vous n'avez pas besoin de considérer "comment" c'est fait, vous utilisez simplement la puissance mise à votre disposition dans ce HTML "augmenté" qu'Angular vous permet d'utiliser. Cela signifie également que TOUTE la logique de votre 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 pourraient être considérées comme augmentant la capacité du HTML, donc vous laissez le DOM se soucier de se manipuler lui-même (pour ainsi dire). Je vais vous démontrer avec un exemple simple.

C'est la balise que nous voulons utiliser. Je lui ai donné un nom intuitif.

<div rotate-on-click="45"></div>

Tout d'abord, je voudrais juste commenter que si nous avons donné à notre HTML cette fonctionnalité via une directive Angular personnalisée, nous avons déjà terminé. . C'est une bouffée d'air frais. Je vous en dirai plus dans un instant.

Mise en œuvre avec jQuery

Démonstration 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émonstration en direct ici (cliquez).

app.directive('rotateOnClick', function() {
  return {
    restrict: '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)'    
        });
      });
    }
  };
});

Plutôt léger, TRES propre et ce n'est qu'une simple manipulation ! À mon avis, l'approche angulaire est gagnante à tous les égards, notamment en ce qui concerne la façon dont la fonctionnalité est abstraite et la manipulation du DOM est déclarée dans le DOM. La fonctionnalité est accrochée à l'élément via un attribut 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 la directive où les variables sont partagées entre toutes les utilisations de la directive, et une fermeture pour chaque utilisation de la directive dans l'environnement de travail. link (ou compile fonction).

La liaison de données bidirectionnelle et les directives pour la manipulation du DOM ne sont que le début de ce qui rend Angular génial. Angular encourage la modularité, la réutilisation et la facilité de test de tout le code et comprend également un système de routage des applications en une seule page. Il est important de noter que jQuery est une application de type bibliothèque de méthodes pratiques/transversales couramment utilisées, mais Angular est un logiciel complet cadre pour créer des applications à page unique. Le script angulaire inclut en fait sa propre version "lite" de jQuery afin que certaines des méthodes les plus essentielles soient disponibles. Par conséquent, vous pourriez faire valoir qu'utiliser Angular EST utiliser jQuery (légèrement), mais Angular fournit beaucoup plus de "magie" pour vous aider dans le processus de création d'apps.

Voici un excellent article pour plus d'informations sur le sujet : Comment "penser en AngularJS" si j'ai une formation en jQuery ?

Différences générales.

Les points ci-dessus visent à répondre aux préoccupations spécifiques du PO. Je vais également donner un aperçu des autres différences importantes. Je vous suggère également de lire d'autres documents sur chaque sujet.

Angular et jQuery ne peuvent raisonnablement pas ê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 framework a plus de pouvoir dans l'écriture d'une application qu'une bibliothèque. C'est exactement la raison d'être d'un framework. Vous pouvez écrire votre code en JS, ou ajouter une bibliothèque de fonctions communes, ou encore ajouter un framework 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 :

Pourquoi utiliser un cadre ?

Les 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, il n'est donc d'aucune aide à cet égard. Nous avons tous vu les murs typiques du code spaghetti de jQuery. Ce n'est pas la faute de jQuery - c'est la faute des développeurs qui ne savent pas comment architecturer le code. Cependant, si les développeurs savaient comment architecturer le code, ils finiraient par écrire une sorte de "cadre" minimal pour fournir les bases (achitecture, etc.) dont je viens de parler, ou ils ajouteraient quelque chose. Par exemple, vous pourriez ajouter RequireJS pour agir comme une partie de votre cadre pour écrire du bon code.

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

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

Avant d'aborder plus avant Angular, j'aimerais souligner qu'il n'est pas le seul de 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 du framework construit au-dessus peuvent fournir. Ce n'est tout simplement pas comparable.

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

Angular (revisité).

Dans le prolongement de ce que j'ai dit précédemment sur les fonctionnalités des frameworks, j'aimerais faire l'éloge de la manière dont Angular les fournit et essayer de clarifier pourquoi cette solution est, de fait, supérieure à jQuery seul.

Référence DOM.

Dans mon exemple ci-dessus, il est absolument inévitable que jQuery doive s'accrocher au DOM afin de fournir une fonctionnalité. Cela signifie que la vue (html) est concernée par la fonctionnalité (parce qu'elle est étiquetée avec une sorte d'identifiant - comme "image slider") et que JavaScript est concerné par la fourniture de cette fonctionnalité. Angular élimine ce concept par l'abstraction. Un code correctement écrit avec Angular signifie que la vue est capable de déclarer son propre comportement. Si je veux afficher une horloge :

<clock></clock>

C'est fait.

Oui, nous devons passer par JavaScript pour que cela ait un sens, mais nous le faisons de la manière opposée à l'approche de jQuery. Notre directive Angular (qui se trouve dans son propre petit monde) a "augumenté" le html et le html accroche la fonctionnalité en lui-même.

MVW Architecure / Modules / Injection de dépendances

Angular vous offre un moyen simple de structurer votre code. Les éléments de la vue appartiennent à la vue (html), les fonctionnalités de la vue augmentée appartiennent 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 angulaires qui permettent de gérer la configuration et la modification des services, etc. Toute fonctionnalité que vous créez est automatiquement disponible partout où vous en avez besoin via le sous-système Injector qui se charge de l'injection de dépendances dans toute l'application. Lorsque j'écris une application (module), je la décompose en d'autres modules réutilisables, chacun avec ses propres composants réutilisables, puis je les inclus dans le projet plus vaste. Une fois que vous avez résolu un problème avec Angular, vous l'avez automatiquement résolu d'une manière utile et structurée pour le réutiliser à l'avenir et l'inclure facilement dans le projet suivant. A ÉNORME Le bonus de tout cela est que votre code sera beaucoup plus facile à tester.

Il n'est pas facile de faire "fonctionner" les choses en Angular.

MERCI MON DIEU. Le code spaghetti de jQuery mentionné plus haut est le résultat d'un développeur qui a fait en sorte que quelque chose "fonctionne" puis est passé à autre chose. Vous pouvez écrire du mauvais code Angular, mais il est beaucoup plus difficile de le faire, car Angular vous combattra à ce sujet. Cela signifie que vous devez profiter (au moins un peu) de l'architecture propre qu'il fournit. En d'autres termes, il est plus difficile d'écrire du mauvais code avec Angular, mais plus pratique d'écrire du code propre.

Angular est loin d'être parfait. Le monde du développement web ne cesse de croître et d'évoluer, et de nouvelles et meilleures méthodes sont mises en avant pour résoudre les problèmes. React et Flux de Facebook, par exemple, présentent de grands avantages par rapport à Angular, mais comportent aussi leurs propres inconvénients. Rien n'est parfait, mais Angular a été et reste génial pour le moment. De même que jQuery a permis au monde du web d'avancer, Angular l'a fait et le fera encore.