Côté développement web, l’écosystème de bibliothèques et de frameworks à disposition des développeurs est toujours plus florissant. Parmi ces solutions, certaines se démarquent particulièrement, et c’est le cas d’Angular. Pourtant, la majorité des développeurs souhaitent s’en affranchir. Il est donc venu le temps pour nos experts ARCA de mettre les pieds dans le plat : Angular est-il la solution parfaite pour vos besoins ?
Pour commencer, clarifions la différence entre frameworks et bibliothèques. En effet, nous parlerons dans cet article des 3 écosystèmes les plus utilisés : Angular, React, et Vue. Angular et Vue sont des frameworks, là où React est une bibliothèque. La différence ? Le contrôle du flux d’exécution. Un framework possède son propre cycle de vie, et appellera votre code lorsqu’il en aura besoin. Au contraire, une bibliothèque laisse le flux d’exécution au développeur. C’est lui qui décide quand appeler cette bibliothèque, et son code n’en est pas (forcément) entièrement dépendant.
#1. Dans les faits
En introduction, nous parlions d’un mauvais taux de satisfaction. Pour bien comprendre, appuyons nous sur une enquête annuelle : StateOfJs. Chaque année, une grande concertation publique est menée auprès des développeurs en fin d’année. Chacun peut y répondre, et l’enquête 2020 a rassemblé 23 765 réponses en provenance de 137 pays, contre moins de 10 000 répondants à la première édition en 2016. Cette étude dont les résultats sont rendus publics permet donc d’avoir une bonne vision de ce qui est utilisé, et comment.
State of JS 2020
Pour en revenir aux chiffres, on peut voir que concernant les frameworks front-end (abus de langage !), Angular est le deuxième framework le plus utilisé (56%) de manière consistante depuis 2016, juste derrière React. Pourtant, en terme d’intérêt (est-ce que l’on souhaite apprendre cette technologie) et de satisfaction, on peut voir qu’Angular est avant dernier sur cette même période. La satisfaction en 2020 est seulement de 42%, contre plus de 80% dans le top 5 du classement.
Utilisation
Satisfaction
Nous voyons même, dans un second graphique, qu’avec le temps ce désamour envers Angular ne fait que se confirmer.
Comment alors expliquer qu’Angular soit utilisé par plus d’un développeur sur deux, mais qu’ils semblent tous s’intéresser à une autre technologie ? La première raison serait que les développeurs ont tendance à être plus intéressés par ce nouveau machin que personne ne connait que par une technologie qu’ils utilisent depuis longtemps. Soit. Mais la deuxième raison pourrait être plus profonde, nous sommes donc aller voir nos experts pour mieux comprendre.
#2. Une opinion forte
Nous l’avons dit, une bibliothèque répond à un besoin technique, là ou un framework va imposer son style. On dit qu’il est opiniâtre (de l’anglais « opinionated »). Et dans le genre opiniâtre, Angular est bien placé ! En imposant sa manière de faire, il contraint le développeur dans un cycle entièrement Angular et à emprunter un chemin unique. Pour David, c’est un problème : « C’est rassurant pour les architectes et les divers décideurs, car ils connaissent déjà la manière dont le code sera découpé et compilé. Mais ça relègue le développeur comme simple exécutant, et limite la portée de sa veille technique : toutes les connaissances que le développeur aura apprises en développement front avant d’utiliser Angular seront ignorées par le framework. Le développeur ayant fait de la veille technique et connaissant un large choix de bibliothèques, mais pas celles utilisées par Angular, se retrouvera devant Angular au même niveau qu’un développeur junior, sans pouvoir utiliser ce qu’il aura appris. ». Il ajoute que pour lui, il s’agit de rentrer dans un moule sans apporter d’expertise. Toute veille technique qui s’écarte du Angular way n’est donc pas encouragée car elle ne sera pas applicable. « Angular enferme les développeurs dans un écosystème unique. ».
Angular ecosystem
On se heurte donc à un mur : il faut apprendre Angular avant de pouvoir utiliser Angular. Une marge de progression énorme, qui en décourage plus d’un ? Pas pour Arthur : « Je suis d’accord qu’Angular peut avoir une courbe de progression plus importante que du Vue ou du React, mais la différence que je vois c’est que là où la montée en compétence sera regroupée sous Angular. ». On apprend, une bonne fois pour toute, les compétences nécessaires, là où sur d’autres technologies plus ouvertes (dans le sens des choix techniques), la progression est en escalier : on apprend au fur et à mesure que le besoin émerge. Il ajoute ensuite : « j’ai l’impression de souvent entendre que c’est super compliqué mais d’un autre côté, j’ai l’impression que la majorité des personnes utilisent le framework sans savoir comment utiliser certaines briques comme les observables , alors que c’est au coeur d’Angular. Quelque soit l’outil, si on l’utilise comme on a l’habitude d’utiliser les autres sans chercher à savoir comment il fonctionne, je pense qu’on va se heurter tôt ou tard à des difficultés. ». Quelque soit la hauteur du mur et des difficultés, rien n’est insurmontable !
Un mur a surmonter
#3. Un couteau suisse bien (trop?) armé
Une autre raison derrière cette courbe de progression important : Angular fait tout. Ce qui répond au titre donc. Mais pose aussi évidemment des problèmes ! En effet Angular est un monolithe qui répond à tous les besoins de tous les projets. Il se doit donc d’être très générique et complet, et cela se paie en temps d’apprentissage. David nous explique : « Même si techniquement il est possible de faire grandir un projet Angular petit à petit au fur et à mesure des besoins, en pratique les projets Angular commencent avec toute la panoplie de bibliothèques activées, pour être «future-proof», puisque c’est cette même peur du futur qui a fait adopter cette technologie en premier lieu. Sur un autre projet avec par exemple Vue, on pourra apprendre peu a peu les concepts dont on a besoin: on pourra commencer par apprendre les système de templating et de composants, puis, quand le besoin se fait sentir, on ajoutera un routeur. Le routeur officiel, ou un autre, pourquoi pas. Il en ira de même pour le client http et les autres bibliothèques. ». Cette volonté de future-proofing vient aussi avec un handicap : une application en Angular sera bien souvent plus lourde qu’avec une autre technologie. Il faut donc se demander si l’application va vraiment grossir au point ou maintenir les bibliothèques deviendra plus complexe que d’adopter un écosystème unique – et uni. Pour de gros projets, être à l’épreuve du futur est toujours une bonne idée. Mais dans le cas de certains petits projets, Angular apportera bien souvent plus de complexité que nécessaire.
Ce monolithe implique aussi des temps de chargement longs. On trouve pléthore d’articles sur le sujet, et cet unique problème a mené a la création de compilateurs différents, de systèmes de chargement en lazy-loading et de cache. Regardez cet article par exemple. Vous y apprendrez comment garder une taille de bundle raisonnable, comment utiliser NgModuleFactoryLoader, et Angular PWA pour mettre en cache des ressources statiques. Maintenant prenons un peu de recul et demandons-nous : avons-nous envie de connaître cette glue technique, n’était-ce pas le travail d’Angular de nous abstraire justement de la glu technique « bas niveau » des navigateurs ? Pour David, c’est sans appel : « On ne peut pas dire qu’il ne le fait pas, mais je doute que replonger dans de nouveaux problèmes techniques pour éviter les anciens soit un réel progrès. ». Une autre manière d’éviter des temps d’itération trop longs a été l’utilisation de deux compilateurs : un compilateur JIT pour le développement, et un compilateur AOT pour le code de production. Mais ils ne se comportent pas pareil, bien sûr ! Par exemple, l’utilisation d’une variable privée dans un template ne posera pas de problème pour le compilateur JIT, mais fera planter le code une fois en production. Il en va de même pour l’utilisation d’une méthode qui retourne une instance dans la liste de providers d’un composant. Du coup, un développeur Angular ne sait pas si son code va fonctionner sans le tester avec le compilateur AOT sur son poste, ce qui implique un temps de compilation long. C’est dommage pour un outil censé faciliter justement le développement itératif. Et puis, tout bug trouvé en mode prod devra se débugger sans aide des sources ni du débuggeur pas-à-pas, même si l’on peut toujours récuperer les sources pour reproduire.
#4. Des pièges à éviter ?
Nous avons déjà parlé du premier piège : l’obligation d’apprendre la majorité du framework, de suite, avant de pouvoir se sentir productif. Avant de pouvoir afficher un composant sur une page, il faudra au minimum comprendre la stack suivante :
- Comment est codé un composant Angular, et son cycle de vie.
- Sass ou scss, et les specifités Angular afférentes, comme ng-deep ou host
- Les templates angular
- Le système de module Angular
- L’outil Angular client appelé ng-cli
- Le routeur Angular
- Comment fonctionne l’injection de dépendances, et du coup ce qu’est un provider, et un service, et une factory, et leurs scopes, et…
Bien vite, on se retrouve aussi à devoir apprendre :
- Les pipes, et ce qu’est une directive
- Les @Input et les @Output
- Les Validators pour les formulaires
- Comment utiliser les compilateurs JIT et AOT au besoin
Cependant, pour des petits projets avec un domaine restreint, toute cette complexité n’est pas nécessaire : le projet aura donc une taille disproportionnée (en terme de poids de fichiers à télécharger par l’utilisateur) par rapport à l’utilisation et l’utilité finales. C’est couteux, en bande passante pour les transferts de fichiers, et en maintenabilité. Et toute cette complexité vient dans le but de créer une Single Page App, avec plusieurs routes, etc. Il sera difficile de faire des micros-app qui viendront se brancher sur un élément précis d’une page HTML, c’est souvent un choix à challenger dans ces cas là.
Angular vient aussi équipé d’une technologie particulière : les observables. Si il est possible de l’utiliser comme une bibliothèque (et donc, dans n’importe quel projet), de part sa nature opiniâtre Angular a fait le choix technique pour nous. Les développeurs web qui ont l’habitude d’utiliser des promesses au lieu des observables peuvent être décontenancés, car la gestion est tout à fait différente. Il faudra par exemple penser à fermer un observable pour éviter les fuites mémoires, là où la promesse n’a que 2 états : en cours, ou terminé. Heureusement, dans le service http (qui fait les requêtes) Angular émet des observables qui sont automatiquement fermés ! Mais attention, ce n’est pas le cas partout. Pour Arthur, c’est un choix gagnant : « [les observables], c’est au coeur d’Angular. Oui c’est un choix assumé. Je trouve ça beaucoup plus souple à utiliser. Tu peux très facilement combiner tes observables pour arriver à ton résultat final, et si tu as des traitements un peu complexes, ça serait beaucoup moins maintenable avec des promises. Les observables ne génèrent pas de fuite mémoire s’ils sont bien utilisés. ». On pourra même ajouter une bibliothèque qui gère la fermeture des observables pour nous, au cas où
Vous l’aurez compris, le débat est houleux à la rédaction ! Merci à David et Arthur pour ces avis éclairés. Ils ont finalement réussi à se mettre d’accord sur un point. Se voulant restrictif pour mieux guider les développeurs, et ainsi limiter les manières de se tromper, Angular se retrouve au final truffé de pièges à éviter, ce qui mène au paradoxe suivant : conçu pour être utilisable par tous, il faut en réalité être un développeur expérimenté pour naviguer entre les divers pièges et produire un projet de qualité, maintenable et performant. En clair : Angular répondra toujours à votre besoin, mais pas toujours de manière optimale. Pour tirer au maximum profit de ce framework, il vaut donc mieux s’entourer d’experts… comme ceux d’ARCA ! 😇
