21 % des développeurs (indeed.com) utilisent l’une ou l’autre des versions Angular pour réaliser des applications Web de haut niveau, fortement sollicitées. On joue ici dans la cour des « grands ».

Mais Angular pose des problèmes de compréhension, ne serait-ce qu’entre ses deux versions, qui ont évolué en parallèle.

La vraie question, aujourd’hui, est de savoir quelle est la technologie qu’il faut retenir pour construire des sites Web capables de supporter des très gros trafics et connectables à des applications serveurs lourdes. Le problème n’est pas simple et concerne bien sûr l’aspect client avec Angular ou React, mais aussi les serveurs, avec Node, Java, ASP.NET ou tout autre framework dynamique.

Dans ce dossier, nous avons choisi de faire le point sur Angular, sur les avantages comparés d’Angular face à AngularJS et de procéder à quelques « zooms » sur ce qui fait l’intérêt d’Angular, la programmation réactive par exemple, l’usage de TypeScript plutôt que de JavaScript en direct, la modularité du code, etc.

Angular, de l’avis des usagers est une réussite, un peu compliqué à mettre en œuvre, plus en tout cas qu’une API telle que Vue.js, voire même que React, celui-ci continuant de faire la course en tête.

Aucun TI ne peut, en tout cas, ignorer Angular, d’où le coup de projecteur que nous lui appliquons.

La confusion des dénominations

Angular, ne pas confondre avec AngularJS, est une réécriture par la même équipe de Google de l’API JavaScript proposée à l’origine par deux chefs de projets, Miško Hevery, coach en gestion de projets agiles et Adam Abrons, qui travaillaient chez Google. Il y a donc bien deux Angular, le premier conforme à ses origines JavaScript et le second, basé sur le transpiler Microsoft TypeScript, beaucoup plus performant et entièrement réécrit, que l’on utilise aujourd’hui pour des sites à très fort trafic, ce que fait React par exemple, à qui on l’oppose souvent, dynamiques, basés sur le mécanisme SPA (Single Page Application) et MVC (Modèle Vue Contrôleur).

Il subsiste un certain flou entre ces deux versions, ce qui vient d’une dénomination maladroite, qui a entraîné une évidente confusion. Ce qui est sûr, c’est que les deux communautés ne se mélangent pas, sans véritablement s’opposer et c’est dans les internes des deux plates-formes, dans les techniques de programmation, que l’on va trouver les véritables différences entre les deux options. Leur point commun étant JavaScript.

Aujourd’hui, AngularJS et la version TypeScript, sont incontournables et un développeur sur cinq, environ, les ont adoptés, qui sont sûrs de cette façon, de disposer des paradigmes les plus modernes, non seulement pour des sites Web bien structurés et à fort trafic, mais aussi pour les applications qui se « webisent » partout, dans une sorte de « no man’s land » entre les vieilles applications HTML statiques et les sites à clients riches, souvent propriétaires, comme on en a connu dans les années 2000.

_{AngularJS n’ira pas plus loin que la version 1.7. Car depuis 2016, Angular prend la relève, qui en est à la version 8. Ce ne sont pas les mêmes produits.}

Comprendre l’évolution du framework

Tout a donc commencé en 2009 quand Hevery et Abrons ont élaboré leur première version d’AngularJS, qui à l’origine était uniquement destinée à manipuler des fichiers JSON. Très rapidement, l’API a pris une tournure plus générale et à la fin 2010, AngularJS a été versé dans les répertoires GitHub, avec un statut résolument Open Source, le projet ayant été repris, entre temps, en grande partie par Google.

En fait, la première « vraie » version AngularJS a été la 1.0, sortie en juin 2012.

Le schisme s’est produit en 2014, pour livraison en 2016, d’une version très différente que l’on désigne aujourd’hui par le vocable simplifié d’Angular, avec des changements et une réécriture totale du produit.

AngularJS et ses principes révolutionnaires…pour l’époque

Il faut se remettre dans le concept de la fin des années 2000, quand de nombreux développeurs élaboraient des sites Web statiques, voire faiblement dynamiques et se contentaient d’insérer du JavaScript dans de l’HTML pour produire des effets un peu moins « ringards » que ce l’on avait à l’époque.

Les concepts d’AngularJS nous paraissent évidents aujourd’hui.

D’abord découpler les manipulations du modèle DOM, des traitements métiers, ce qui s’est fait par application du pattern MVC. Avec ce pattern, la « vue » est élaborée grâce à une version étendue d’HTML, avec de nouvelles balises pour gérer les transferts de données bidirectionnels entre le modèle et la vue. D’où un gros avantage, une synchronisation automatique de ces données des deux côtés du système et moins de code JavaScript à écrire dans les applications.

Toujours dans le pattern MVC, les modèles ont été constitués en couches appelées « scopes », des objets JavaScript qui correspondent aux contextes d’exécution d’une partie des vues. Les scopes référençant, comme il se doit, autant les modèles de données, que les méthodes contextuelles.

AngularJS s’appuie en complément sur la notion de contrôleur, qui est chargé de fournir les données et les actions avec lesquelles l’utilisateur pourra interagir dans les vues. Le contrôleur a donc pour vocation d’initialiser le modèle, de l’exposer avec les fonctions de la vue, via l’objet $scope et de réagir aux changements qui interviennent dans le modèle.

Du point de vue structure, les scopes sont organisés de manière hiérarchique, sous forme d’arbre, dont le sommet $rootScope permet d’accueillir de nouveaux contrôleurs. Une application pourra comporter plusieurs scopes, créés avec ngController, ngRepeat…, AngularJS utilisant la méthode $new pour les ajouter, à partir d’un scope père, dont le nouveau scope va hériter les caractéristiques. Grâce à cette organisation, on pourra appeler une fonction appartenant à la hiérarchie des scopes, à laquelle appartient un scope donné.

Parmi les autres grands principes qui ont présidé au lancement d’AngularJS, figure la prise en compte des tests, tout au long du développement, l’idée d’Hevery et Abrons étant que les tests vont dépendre directement de la manière dont sont architecturées les applications et qu’en appliquant les principes MVC, par exemple et donc en décorrélant le modèle, le contrôle et la vue, ce sont les tests qui vont en profiter.

A noter encore deux points très importants : le fait qu’AngularJS dispose d’un mécanisme de gestion des dépendances, ce qui n’était pas une généralité et qu’il peut mettre en œuvre des process asynchrones de type non bloquants, le client n’ayant pas à attendre que le serveur ait fini son travail, avant de lancer une autre tâche.

Tout cela explique autant que l’aide de Google et celle de la communauté, qu’AngularJS ait été une grande réussite.

_{D’une certaine manière AngularJS et Angular sont le Yin et le Yang du développement. Deux approches apparemment différentes d’un même problème, celui des applications Web à forte sollicitation et complexité, mais qui peuvent aussi être très complémentaires, comme le Yin et le Yang, plus en tout cas que ce qu’elles semblent être au premier abord.}

L’arrivée d’Angular

A partir de la version 2 d’AngularJS, le framework a été entièrement réécrit, de sorte qu’il y a bien aujourd’hui deux Angular, le premier AngularJS que l’on a évoqué et le second Angular, tout simplement, qui n’a rien à voir avec le précédent. Au point que l’on est parfois amené à les comparer pour choisir la meilleure solution…

Globalement, Angular, qui a été conçu pour le monde des mobiles, est plus complexe à utiliser et surtout exploite des concepts, qui peuvent dérouter les usagers.

Mais le plus important est qu’Angular ne laisse pas beaucoup de place à l’imagination. C’est un système relativement fermé, qui propose un moyen pour traiter tous les aspects du développement, sous couvert d’une organisation à base de modules. Il s’agit d’un véritable framework, un cadre de développement et pas simplement d’une librairie.

Et de fait, Angular comporte tout ce qu’il faut pour « travailler », sans que le développeur ait à se poser (trop) de questions sur des addons à aller chercher, à droite et à gauche, mais sans nécessairement rupture avec ce que propose déjà AngularJS, certains outils ayant été introduits dans la précédente version. Ce qui fait dire à certains chefs de projets, que les deux plates-formes sont aussi différentes que le Yin et le Yang chinois, des approches complémentaires sur les gros sites Web, mais qui au fond, parlent tous les deux chinois…

Avec Angular, c’est la « maison mère » qui se charge de l’intendance :

• ·         Des outils de configuration pour les builds et l’optimisation des installations
• ·         Un modules d’animation HTML que l’on a déjà avec AngularJS
• ·         Un module de « routing », qui joue un rôle essentiel dans la fabrication des SPA « Single Page Applications » et la gestion des « components », mis à jour dans la page en fonction des évènements
• ·         Un module formulaires
• ·         Un module de debug
• ·         Un autre pour les tests unitaires et e2e (end to end)

Au total, le ressenti des développeurs est une certaine complexité de mise en œuvre et pour certains, réticence à s’habituer à des concepts qu’ils ne connaissent pas.

_{L’arrivée de la modularité dans la plate-forme Angular a profondément changé le comportement du framework. Les applications sont mieux structurées et plus faciles à maintenir.}

Les modules, au cœur d’Angular

La nouvelle version d’Angular, celle baptisée 2.0 à l’origine, est structurée autour du concept de modules, l’équipe conceptrice s’étant délibérément orientée vers cette option, ce qui n’a pas été le cas d’AngularJS, voire d’autres langages comme Java, ce dernier n’ayant découvert la modularité qu’avec le très récent JDK 9.

JavaScript, grâce à sa conformité ECMAScript 6 est également « frappé » de modularité et donc AngularJS aussi, le problème étant que ce n’est pas de la même modularité dont il s’agit et que celle d’AngularJS n’est pas transposable à Angular. Ce sont deux approches différentes.

La modularité Angular est fondée sur un mécanisme particulier, dit NgModule, qui lui-même est basé sur un pattern bien connu, de décorateur, dont il est une implémentation concrète.

Un décorateur, personne ne l’a oublié, est une fonction qui modifie une classe JavaScript, pour la surcharger et améliorer ses fonctionnalités, sans la transformer, ni passer par un héritage. Le décorateur prend en entrée la classe à modifier, dont il crée une version modifiée, sans changer de nom. Il ne fait qu’implémenter un comportement nouveau, les deux classes, celle d’origine et celle modifiée devant cependant hériter de la même classe mère. @NgModule est un décorateur qui intervient sur un certain nombre de propriétés, qu’il va pouvoir modifier à sa convenance :

·         declarations où on déclare les classes de « vue » du module, les components, directives et pipes

·         exports : pour déclarer un sous-ensemble de « declarations » qui sera visible par d’autres modules

·         imports : pour déclarer les modules dont dépend le module nouveau

·         providers, bootstrap, schemas, entryComponents, etc, que nous laissons le soin à nos lecteur de découvrir.

Le mécanisme NgModule est très puissant, pas évident à comprendre, différent de celui implémenté dans EcmasScipt, mais au moins il permet de faire du « travail propre », les modules et les « components » constituant une trame très séduisante pour écrire de véritables applications urbanisées. L’effort d’appréhension mérite d’être effectué.

L’environnement Angular

Habituellement les développeurs qui travaillent avec Angular « se font aider » par quelques artefacts annexes, qui contribuent à leur boîte à outils :

·         Angular CLI, qui est l’interface en mode commandes, pour créer les projets, ajouter des fichiers, effectuer les mises à jour et surtout tester les applications et les déployer. CLI n’est pas compatible avec AngularJS.

·         Un éditeur de texte, parmi un grand nombre de solutions, à commencer par Visual Studio Code, Sublimte Text, plus que des outils tels que WebStorm et surtout Angular IDE, qui n’a pas convaincu les foules.

·         RxJS, dont on peut difficilement se passer dès lors que l’on a à gérer de multiples « canaux » de données, qu’il faut traiter de manière asynchrone.

Ce RxJS mérite que l’on s’y attarde. Il s’agit d’un élément essentiel dont Angular fait un large usage dans ses différents modules et que les développeurs doivent absolument maîtriser.

RxJS est une librairie JavaScript qui applique les principes de programmation réactive, celle-ci étant fondée sur les concepts d’ « observables », les objets que l’on veut « observer », par l’intermédiaire d’ « observateurs ».

A vrai dire, l’idée n’est pas révolutionnaire et on sait faire à peu près la même chose avec d’autres langages, à commencer par PHP, mais RxJS est particulièrement bien conçu, au point de constituer un argument clé dans la panoplie Angular.

On peut au moins rappeler le principe : on crée un observable avec une méthode (« of » est la plus simple), puis on fait appel à une méthode telle que « subscribe » pour surveiller le comportement de l’observable : si un certain évènement se produit (ici la chaîne de caractères "Goal"), alors on fait quelque chose…

import { of } from ‘rxjs’ ;

const monObservable = Observable.of(‘Goal’);

monObservable.subscribe((value) => { console.log(value);});

Le gros intérêt de RxJS est de traiter avec élégance le problème de la sollicitation des serveurs, qui deviennent non bloquants, puisque l’on peut lancer un autre traitement en attendant que le serveur ait fini son travail. De cette manière on peut envisager de prendre en charge un nombre très importants de sollicitations sur ce serveur, sans bloquer la moitié de la planète pour cela.

Cette capacité à mettre en place des serveurs non bloquants en JavaScript est une qualité partagée par d’autres frameworks que l’on compare à Angular, tels que EmberJS, Knockout ou Backbone.js. Mais aussi Node.JS.

_{L’un des gros avantages d’Angular est qu’il constitue une véritable galaxie, avec tout un ensemble d’outils complémentaires, intégrés à l’environnement qui permettent de le considérer comme une plate-forme pérenne sur laquelle il est possible de fonder une stratégie à long terme. D’autant qu’avec le temps et de l’expérience, certains de ses défauts les plus relevés, la complexité du codage, par exemple, finissent par s’estomper.}

Avantages et inconvénients d’Angular

Il faut bien voir que AngularJS et Angular sont deux produits différents, qui chacun ont leurs avantages et inconvénients.

Angular a l’avantage d’être fondé sur TypeScript de Microsoft, qui est un transpiler JavaScript, le meilleur moyen (avec d’autres transpilers comme CoffeeScript) pour écrire du code JavaScript de bonne tenue, plus sûr et mieux organisé. TypeScript permet au programmeur d’exploiter des fonctions anonymes, des génériques, le tout sur un typage statique, donc rassurant, etc.

Angular présente le gros avantage de la modularité, de nombreuses fonctionnalités ayant été déportées vers des modules, avec une hiérarchie dans les « components », qui est somme toute plus simple que l’organisation à base de contrôleurs d’AngularJS. Ce qui est directement perceptible dans la montée des pages SPA, voire dans les PWA, ces applications « à la marque » Google, qui ont le même comportement sur un mobile, que si elles avaient été développées avec un SDK natif.

Un autre avantage d’Angular par rapport à JS est le choix du mécanisme de mise à jour des données liées, entre le modèle et la vue MVC, de type « one-way binding » et non pas « two-way binding » comme c’était le cas auparavant. Angular a d’ailleurs suivi React dans ce cheminement.

Il faut rappeler que le mode « one-way » veut dire qu’il n’y a qu’un seul sens de mise à jour des données, soit du modèle vers la vue, soit l’inverse, mais pas les deux. Autrement dit si un  traitement est effectué dans le modèle qui met à jour une donnée « binded », donc liée à une donnée de la vue (l’interface cliente), elle est répercutée sur le client, mais l’opération ne peut pas se faire dans les deux sens. Ce qui réduit les risques de confusion.

Certains présentent également le pattern MVVM (Model-View-ViewModel), cher à Microsoft, comme une qualité supplémentaire, qui est une forme dérivée des modèles MVC (Model-View-Controller) et MVP (Model-View-Presenter), qui permet par exemple à des développeurs de travailler sur la même application et avec le même jeu de données, sans qu’il y ait de confusion ou d’obstacle à la maintenance et aux tests, qui justement restent un aspect essentiel du framework.

La fausse opposition Angular/PHP

Bien que ce soit une erreur de vouloir absolument opposer Angular et PHP, le sujet revient souvent dans les forums, chez les développeurs, qui se demandent quelle solution choisir.

En fait, ils ne jouent pas dans la même cour et Angular doit être placé au-dessus de PHP, en complément, PHP effectuant les traitements centraux, mais cédant la « main » à Angular sur le poste de travail, pour générer dynamiquement les pages HTML, plutôt que de le faire lui-même. C’est cette dualité qui est intéressante.

En fait, PHP est un langage de « backend » et Angular un produit de « frontend », ce qui n’est pas pareil…