J'utilise principalement la bibliothèque jQuery et je viens de commencer à utiliser AngularJS. J'ai lu quelques tutoriels sur la façon d'utiliser Angular, mais je ne sais pas pourquoi ou quand l'utiliser, ni quels avantages je peux trouver par rapport à la simple 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. Tu utilises{{data bindings}} chaque fois que vous pensez avoir des données dynamiques. Angular vous fournira alors un gestionnaire $ scope, que vous pouvez remplir de manière statique ou via des appels au serveur Web. Cela ressemble de manière caractéristique à la manière JSP de concevoir des pages Web. Ai-je besoin d'Angular pour cela?

Pour une manipulation simple du DOM, qui n'implique pas de manipulation de données (ex: changement de couleur au survol 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 dans le mvc d' 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 / masquage, etc., les modifications n'affectent pas le modèle . Angular a-t-il des avantages sur jQuery ou vanilla JS pour les manipulations DOM?

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

Liaison de données

Vous créez 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 remplir (statiquement ou via des appels au serveur Web).

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

Manipulation DOM

Pour une manipulation DOM simple, qui n'implique pas de manipulation de données (par exemple: changement de couleur au survol de la souris, masquage / affichage des éléments au clic), jQuery ou js old-school est suffisant et plus propre. Cela suppose que le modèle dans le mvc d'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 / masquage, etc., les modifications n'affectent pas le modèle.

Je peux voir votre point ici sur le fait que la manipulation DOM "simple" est plus propre, mais rarement et elle 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 vais commencer par comparer la méthode Angular avec une approche vanilla js de la manipulation DOM. Traditionnellement, nous pensons que le HTML ne "fait" rien et l'écrivons comme tel. Ainsi, les js en ligne, comme "onclick", etc. sont une mauvaise pratique car ils placent le "faire" dans le contexte du HTML, ce qui ne "fait" pas. Angular renverse ce concept sur sa tête. Lorsque vous écrivez votre point de vue, vous pensez que le HTML est capable de «faire» beaucoup de choses. Cette capacité est abstraite dans les directives angulaires, 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é" qui angular vous permet d'utiliser. Cela signifie également que TOUTE votre logique de vue est vraiment 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 la capacité du HTML, vous laissez donc 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.

<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 angulaire personnalisée, nous avons déjà terminé . C'est une bouffée d'air frais. Plus sur cela dans un instant.

Implémentation 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]'));

Implémentation avec Angular

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

Assez léger, TRÈS propre et ce n'est qu'une simple manipulation! À mon avis, l'approche angulaire gagne à tous égards, en particulier la façon dont la fonctionnalité est abstraite et la manipulation 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, et nous avons deux belles fermetures - une fermeture pour la fabrique de directives où les variables sont partagées entre toutes les utilisations de la directive , et une fermeture pour chaque utilisation de la directive dans la linkfonction (oucompile fonction).

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 promeut que tout le code est modulaire, réutilisable et facilement testable et comprend également un système de routage d'applications sur une seule page. Il est important de noter que jQuery est une bibliothèque de méthodes pratiques / multi-navigateurs couramment nécessaires, mais Angular est un cadre complet pour la création d'applications à page unique. Le script angulaire inclut en fait sa propre version "allégée" de jQuery afin que certaines des méthodes les plus essentielles soient disponibles. Par conséquent, vous pourriez soutenir que l'utilisation d'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.

C'est un excellent article pour plus d'informations connexes: Comment est-ce que je "pense dans 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 lire davantage sur chaque sujet.

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

Angular est un framework, jQuery est une bibliothèque. 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 puissance pour écrire une application qu'une bibliothèque. C'est exactement le but d'un cadre. Vous êtes invité à écrire votre code en JS simple, ou vous pouvez ajouter une bibliothèque de fonctions communes, ou vous pouvez ajouter un cadre pour réduire considérablement le code dont vous avez besoin pour accomplir la plupart des choses. Par conséquent, une question plus appropriée est:

Pourquoi utiliser un framework?

De bons frameworks peuvent aider à structurer votre code afin qu'il soit modulaire (donc réutilisable), DRY, lisible, performant et sécurisé. jQuery n'est pas un framework, donc cela 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 concevoir du code, ils finiraient par écrire une sorte de «cadre» minimal pour fournir la base (architecture, etc.) dont j'ai discuté il y a un instant, ou ils ajouteraient quelque chose. Par exemple, vous pourrait ajouter RequireJS pour agir dans le cadre de votre cadre d'écriture de bon code.

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

• Création de modèles
• Liaison de données
• routage (application d'une seule page)
• architecture propre, modulaire et réutilisable
• Sécurité
• fonctions / fonctionnalités supplémentaires pour plus de commodité

Avant de discuter davantage d'Angular, j'aimerais souligner qu'Angular n'est pas le seul en son genre. Durandal, par exemple, est un framework basé sur jQuery, Knockout et RequireJS. Encore une fois, jQuery ne peut pas, à lui seul, fournir ce que Knockout, RequireJS et tout le framework construit sur eux peuvent. 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 basant sur mes points précédents sur ce que les frameworks fournissent, j'aimerais féliciter la façon dont Angular les fournit et essayer de clarifier pourquoi cela est en fait supérieur à 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 des fonctionnalités. Cela signifie que la vue (html) est préoccupée par la fonctionnalité (car elle est étiquetée avec une sorte d'identifiant - comme "curseur d'image") et JavaScript est préoccupé 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 passer à JavaScript pour que cela signifie quelque chose, mais nous le faisons de manière opposée à 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épendances

Angular vous offre un moyen simple de structurer votre code. Les objets de vue appartiennent à la vue (html), la fonctionnalité de vue augmentée appartient aux directives, d'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 aident à 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 prend en charge l'injection de dépendances dans toute l'application. Lors de l'écriture d'une application (module), je la décompose en d'autres modules réutilisables, chacun avec leurs propres composants réutilisables, puis je les inclut dans le plus grand projet. Une fois que vous résolvez un problème avec Angular, vous Je l'ai automatiquement résolu d'une manière utile et structurée pour une réutilisation future et facilement incluse dans le prochain projet. UNEUn énorme bonus à tout cela est que votre code sera beaucoup plus facile à tester.

Ce 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 développeur qui a fait quelque chose de "fonctionner" et qui est ensuite passé à autre chose. Vous pouvez écrire du mauvais code Angular, mais c'est beaucoup plus difficile à faire, car Angular vous combattra à ce sujet. Cela signifie que vous devez profiter (au moins un peu) de l'architecture propre qu'elle 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 de changer et il existe de nouvelles et meilleures façons de résoudre les problèmes. Le React et le Flux de Facebook, par exemple, présentent de grands avantages par rapport à Angular, mais présentent leurs propres inconvénients. Rien n'est parfait, mais Angular a été et est toujours génial pour le moment. Tout comme jQuery a déjà aidé le monde du Web à avancer, Angular a fait de même, et beaucoup à venir.