web-dev-qa-db-fra.com

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

J'utilise principalement la bibliothèque jQuery et viens de commencer à utiliser AngularJS. J'ai lu quelques tutoriels sur l'utilisation de Angular avec comment, mais je ne comprends pas bien pourquoi ni quand l'utiliser, ni quels sont les avantages que je pourrais retirer par rapport à l'utilisation de jQuery.

Il me semble que Angular vous fait penser à MVC, ce qui signifie peut-être que vous visualisez votre page Web en tant que combinaison modèle + données. Vous utilisez {{data bindings}} chaque fois que vous pensez que vous disposez de données dynamiques. Angular vous fournira alors un gestionnaire $ scope que vous pourrez renseigner de manière statique ou par le biais d'appels au serveur Web. Cela semble typiquement similaire à la manière JSP de concevoir des pages Web. Ai-je besoin de Angular pour cela?

Pour une manipulation de DOM simple, qui ne concerne pas implique la manipulation de données (par exemple: changements de couleur au passage de la souris, masquage/affichage des éléments au clic), jQuery ou Vanilla JS est suffisant et plus propre. Cela suppose que le modèle de l'angulaire mvc soit tout ce qui reflète les données de la page, et donc les propriétés CSS telles que color, display/hide, Les changements etc n'affectent pas le modèle. Est-ce que Angular présente des avantages par rapport à jQuery ou Vanilla JS pour les manipulations DOM?

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

jqueryangularjs
168
Amarsh

Liaison de données

Vous faites le tour de votre page Web et continuez à mettre des {{liaisons de données}} chaque fois que vous pensez avoir des données dynamiques. Angular vous fournira alors un gestionnaire $ scope que vous pourrez renseigner (de manière statique ou par le biais d'appels au serveur Web).

C'est une bonne compréhension de la liaison de données. Je pense que vous avez ça.

DOM Manipulation

Pour une manipulation simple dans le DOM, qui n'implique pas de manipulation de données (par exemple: changements de couleur au survol de la souris, masquage/affichage d'éléments au clic), jQuery ou old-school js est suffisant et plus propre. Cela suppose que le modèle dans mvc de angular est quelque chose qui reflète les données de la page et que, par conséquent, les propriétés CSS telles que la couleur, l'affichage/le masquage, etc., n'affectent pas le modèle.

Je peux voir que vous voulez que la "simple" manipulation DOM soit plus propre, mais ce n’est que rarement et ce devrait être vraiment "simple". Je pense que la manipulation DOM est l’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 méthode Angular à une approche Vanilla js de la manipulation DOM. Traditionnellement, nous pensons que HTML ne "fait" rien et l’écrivons comme tel. Donc, js en ligne, comme "onclick", etc. sont une mauvaise pratique car ils placent le "faire" dans le contexte de HTML, ce qui ne le fait pas. Angular renverse ce concept sur sa tête. En écrivant votre point de vue, vous pensez que HTML est capable de "faire" beaucoup de choses. Cette capacité est résumée dans les directives angular, mais si elles existent déjà ou si vous les avez écrites, vous n'avez pas à considérer "comment" c'est fait, vous utilisez simplement le pouvoir mis à votre disposition dans ce HTML "augmenté" que angular vous permet d'utiliser. Cela signifie également que TOUTE votre logique de vue est réellement contenue dans la vue, pas 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 les capacités de HTML, de sorte que vous laissez le DOM se soucier de sa manipulation (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.

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

Premièrement, je voudrais juste dire que si nous avons donné cette fonctionnalité à notre code HTML via une directive personnalisée Angular, nous avons déjà terminé . C'est une bouffée d'air frais. Plus sur cela dans un instant.

Implémentation avec jQuery

démonstration en direct ici (clic).

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 (clic).

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)'    
        });
      });
    }
  };
});

Jolie lumière, TRÈS net et ce n’est qu’une simple manipulation! À mon avis, l’approche angular gagne à tous les égards, surtout comment 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'est donc pas nécessaire d'interroger le DOM via un sélecteur. Nous avons deux fermetures Nice: 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 compile.).

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 permet à tout le code d'être modulaire, réutilisable et facilement testable, et comprend également un système de routage d'applications d'une page. Il est important de noter que jQuery est une bibliothèque de méthodes pratiques/inter-navigateurs couramment utilisées, mais Angular est un outil complet framework pour la création de fichiers uniques. applications de page. Le script angular inclut en fait sa propre version "allégée" de jQuery, de sorte que certaines des méthodes les plus essentielles sont disponibles. Par conséquent, vous pouvez faire valoir que l'utilisation de Angular IS à l'aide de jQuery (légèrement), mais Angular fournit beaucoup plus de "magie" pour vous aider dans le processus de création d'applications. .

C'est un excellent post pour plus d'informations connexes: Comment puis-je "penser à AngularJS" si j'ai un fond jQuery?

Différences générales.

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

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

Angular est un framework, jQuery est une librairie. Les cadres ont leur place et les bibliothèques ont leur place. Cependant, il ne fait aucun doute qu'un bon framework a plus de pouvoir pour écrire une application qu'une bibliothèque. C'est exactement le but d'un cadre. Vous êtes le bienvenu pour écrire votre code en clair JS, ou vous pouvez ajouter une bibliothèque de fonctions communes ou un cadre pour réduire considérablement le code dont vous avez besoin pour accomplir la plupart des tâches. Par conséquent, une question plus appropriée est:

Pourquoi utiliser un framework?

De bons frameworks peuvent aider à architecturer votre code de manière qu'il soit modulaire (donc réutilisable), SEC, lisible, performant et sécurisé. jQuery n'est pas un framework, donc cela n'aide en rien. 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 architecturer 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 discuté il y a un moment, ou ils ajouteraient quelque chose. pourrait ajouter RequireJS pour agir dans le cadre de la rédaction de code correct.

Voici quelques éléments fournis par les cadres modernes:

  • Templating
  • Liaison de données
  • routage (application d'une seule page)
  • architecture propre, modulaire, réutilisable
  • sécurité
  • fonctions supplémentaires pour plus de commodité

Avant de poursuivre la discussion sur Angular, je voudrais souligner que 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, par lui-même, fournir ce que Knockout, RequireJS et tout le framework construit sur eux 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é).

En me fondant sur mes remarques précédentes sur ce que fournissent les frameworks, je voudrais mentionner la façon dont Angular les fournit et essayer de clarifier pourquoi c’est en fait un avantage supérieur à jQuery seul.

Référence DOM.

Dans mon exemple ci-dessus, jQuery doit absolument se connecter au DOM pour fournir des fonctionnalités. Cela signifie que la vue (html) est concernée par la fonctionnalité (car elle est identifiée par un identifiant quelconque - comme "curseur d'image") et que JavaScript est concerné par la fourniture de cette fonctionnalité. Angular élimine ce concept via 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>

Terminé.

Oui, nous devons utiliser JavaScript pour que cela ait un sens, mais nous le faisons dans le sens opposé de l’approche jQuery. Notre directive Angular (qui est 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épendance

Angular vous donne un moyen simple de structurer votre code. Les objets 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 la logique à la vue appartiennent aux contrôleurs. Il existe également d'autres composants angular qui facilitent 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 qui prend en charge l'injection de dépendances dans l'application. . Lors de l'écriture d'une application (module), je la divise en d'autres modules réutilisables, chacun avec leurs propres composants réutilisables, puis je les inclus dans le projet plus grand. 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 en vue de sa réutilisation future et que vous pourrez facilement inclure dans le projet suivant. Un bonus de ÉNORME est que votre code sera beaucoup plus facile à tester.

Il n’est pas facile de faire "fonctionner" les choses dans Angular.

DIEU MERCI. Le code spaghetti jQuery mentionné ci-dessus est le résultat d’un dev qui a fait quelque chose de "travail" 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 tirer parti (au moins un peu) de la nouvelle architecture fournie. En d'autres termes, il est plus difficile d'écrire du code incorrect avec Angular, mais plus pratique d'écrire du code propre.

Angular est loin d'être parfait. Le monde du développement Web évolue et évolue sans cesse, et de nouveaux moyens plus efficaces sont proposés pour résoudre les problèmes. React de Facebook et Flux, par exemple, présentent de grands avantages par rapport à Angular, mais présentent toutefois leurs propres inconvénients. Rien n’est parfait, mais Angular a été et reste génial pour le moment. Tout comme jQuery a autrefois aidé le monde du Web à progresser, Angular et beaucoup d’autres à venir.

274
m59