Angular rend l’utilisation de JS plus supportable, mais possède une très grosse courbe d’apprentissage bien pentue, avec des ressources vraiment mal foutues.

Et surtout, le problème vient de l’habitude de jQuery.

AngularJS est l’anti-jQuery, ça ne fonctionne pas du tout pareil, mais personne n’est là pour vous montrer comment faire la transition. Ce sera le but de ce dossier, un dossier qui va être long car ce framework est un gros morceau.

Quand utiliser AngularJS ?

Tous les sites ne sont pas faits pour être créés avec Angular. En effet, si votre site est essentiellement composé de contenu statique, avec juste un peu de dynamique pour quelques widgets, Angular n’a aucun intérêt.

Angular est lourd à mettre en œuvre, on va donc se faire chier à sortir le bazooka quand on monte au front, pas quand on fait une garde de nuit en rase campagne.

Malgré le fait que Google interprète maintenant les pages en JS, le texte reste roi, et Angular vous force à faire des pages en pur JS, rendant le référencement aléatoire de votre contenu. Les hacks que l’on voit un peu partout sur la toile pour compenser cela sont très loin d’obtenir l’effet d’un référencement naturel de contenu facilement accessible à l’ancienne.

En fait, le plus gros défaut d’Angular, c’est qu’il ne permet pas, pour le moment, de faire de la dégradation gracieuse. Soit le mec a Javascript et il a accès au site. Soit le site est illisible.

jQuery a donc encore de beaux jours devant lui.

Typiquement, on ne prendra pas Angular pour :

• La partie publique d’un blog de type WordPress.
• Un wiki type Wikipédia.
• Un forum ou site collaboratif.
• Un tube vidéo.

Ce sont des sites dont le contenu est important. On veut que les moteurs de recherche puisse les indexer de fond en comble. On veut que ce soit lisible sans JS et par les aveugles (sauf le tube vidéo :-D). Les ajouts de JS se feront par petites touches.

On utilisera plutôt Angular pour :

• Une app grand public.
• La partie admin d’un blog.
• Un logiciel d’entreprise.
• Un réseau social.

Ce sont des sites pour lesquels l’ergonomie est plus importante que le contenu. Le public est captif, et on peut exiger Javascript, prix à payer pour une expérience utilisateur moderne.

Vous noterez qu’il y a une certaine opposition entre vieux format (wiki, forum, blog) et format contemporain (app, réseau social). Ce n’est pas un hasard. Les premiers sont orientés contenu, les seconds orientés usage. C’est ainsi que le Web a évolué, et Angular est là exactement pour répondre à cette évolution.

Il est néanmoins tout à fait possible de faire des choses hybrides. Rien n’empêche de faire des parties du sites statiques, et d’autres très dynamiques, de mélanger les deux sur une même page. Par exemple, sur un blog, vous pouvez mettre l’article en statique pour le ref et la facilité de consultation, et la partie commentaires en Angular, pour améliorer l’expérience utilisateur.

Que va apporter Angular ?

Les avantages sont doubles.

D’abords, il y a les avantages pour vous, le développeur. Angular vous force en effet à utiliser un style Javascript très propre qui tend à découpler les composants, isoler les services, lisser les angles et refaire le papier peint à fleur. L’application en devient plus propre, plus facile à faire évoluer et à maintenir. Toutes les bonnes pratiques d’organisation d’une app JS ont une réponse angularesque. Ce n’est pas forcément celle que vous voulez, mais elle marche.

Ensuite, Angular va vous rendre plus productif. Pas tout de suite, évidement, coincés que vous êtes dans votre logique jQuerinne. Mais une fois le cap passé, coder beaucoup de JS sera immensément plus simple et plus rapide, car Angular vous épargne beaucoup de logique répétitive.

En prime, ce framework est orienté tests. Ce n’est pas obligatoire, mais c’est bien plus facile qu’avec des modules jQuery.

Mais il y a également les avantages pour l’utilisateur. Puisque qu’Angular est complètement dynamique, il bénéficiera automatiquement d’une app plus réactive, avec moins de rechargements, plus de fonctionnalités aussi. En effet, vous rechignerez moins à rajouter cette fonction “delete-row” si vous savez que ça vous prend 3 lignes de code.

Attention cependant, il y a aussi des inconvénients.

Angular est lourd, c’est long à charger, ça bouffe de la ressource pour chaque tab, et si vous avez beaucoup de traitements sur une page, vous avez intérêt à optimiser votre race le bouzin sinon ça va ramer. Tout le monde n’est pas sur une machine de dev propre à 8 cœurs avec une ligne ADSL qui a tout compris.

En fait, si votre site est destiné à être consulté ainsi : je cherche, je consulte du contenu, et je m’en vais, charger Angular est un pur gâchis. Il faut au moins que l’on interagisse un peu avec le site pour que ça vaille le coup : créer du contenu, manipuler des informations, se faire notifier, etc.

Et puis il y a la tentation, la tentation forte de tout faire à la main côté client. Avec son lot de problèmes de sécurité (le delete qui fait pas de vérif), de merdier dans l’histo de navigation (le clic du milieu qui marche pas, le back qui back pas où on veut), les sessions qui font des siennes (je suis déco, mais y mon avartar là, pourquoi ?), etc.

Angular n’est pas une solution pour le bidouilleur Javascript de devenir soudainement grand programmeur Web, et ne dispense pas de coder correctement.

Si je fais de l’Angular, je dois faire du NodeJS ?

Non.

Angular est une techno parfaitement neutre, elle est limitée au client, et par conséquent, vous êtes libres de choisir votre techno côté serveur : .Net, PHP, Ruby, Java, Python…

Par contre, pour les tests, les outils sont très orientés autour de l’écosystème NodeJS : npm, grunt, PhantomJS, etc. Il va falloir mettre les mains dans le cambouis, avec son lot de trucs qui s’installent pas, de dépendances mal branlées, de doc pas à jour, de code JS peu expressif et tout le bordel. C’est tout le problème du JS, la communauté a gardé le côté crade et à l’arrache du langage. Heureusement, ils ont récupéré les designers du monde Ruby, donc vous aurez des tutos obsolètes, mais très jolis.

Ok, mais je peux faire quoi avec ?

Car finalement, quand on n’a pas utilisé Angular, on se demande finalement qu’est-ce que ça apporte par rapport à jQuery.

Essentiellement, c’est que ça divise par 100 les manipulations du DOM. Avec Angular, on met ses données dans un tableau d’objets JS, on indique où les afficher, et on manipule ensuite notre array. Le DOM est mis à jour sans qu’on doive s’en soucier.

Ça à l’air de rien comme ça, mais si vous ouvrez vos fichiers JS avec jQuery, vous verrez qu’ils sont blindés de .click()code et de .append(). C’est la majorité du code ! Code qu’on a pas besoin d’écrire avec Angular.

L’organisation d’Angular invite aussi naturellement à écrire un code linéaire. Pas de blocs dans des blocs dans des blocs, chaînes de callbacks et amas de closures. Il y en a toujours, mais bien moins.

Après, on fait finalement la même chose qu’on ferait avec jQuery, mais plus facilement. Ce qui explique qu’on fait rarement une app full JS avec jQuery, ce qui est infernal à coder, alors qu’on le fait systématiquement avec Angular, car c’est son milieu naturel.

Ce qui va vous surprendre avec cette façon de faire, c’est que tout ce qui s’affiche dans la page passe par Angular. En fait, on a généralement une API REST, et Angular en front pour afficher le site. Pas trop de templating côté serveur.

Et on verra des exemples concrets de tout ça dans les parties suivantes :)