Frontend – la renaissance d’Angular ?

Un temps incontournable, aujourd’hui perçu comme le gros framework rigide face à d’autres options plus populaires, Angular a traversé une période de désamour marquée par une complexité excessive et une architecture vieillissante.

Captif de ses propres concepts (Modules, Zone.js, RxJS omniprésent), le framework de Google semblait condamné à ne rester qu’un choix de raison pour les grandes entreprises, perdant peu à peu le cœur de la communauté web face à React.

MAIS… depuis la version 17, Angular vit une véritable « Renaissance » : le framework s’est modernisé pour devenir plus rapide, plus léger et beaucoup plus intuitif. Et reprend du poil de la bête face à ses concurrents !

La Réactivité en révolution : les Signals

C’est le changement architectural le plus important : les Signals permettent une détection de changement ultra-fine au lieu de vérifier toute l’application.

Traditionnellement, Angular utilisait Zone.js, une bibliothèque qui surveille tous les événements (clics, timers, requêtes HTTP) et demande à Angular de vérifier tous les composants pour voir si quelque chose a changé. C’est efficace, mais gourmand en ressources. Les Signals quant à eux, permettent de délaisser Zone.js. En effet, ils fonctionnent à un niveau plus fin, sous le principe d’émission de données, avec des composants qui écoutent les changements de valeur d’un signal spécifique.

Les Signals sont introduits via une api du framework d’Angular (signal(), computed() et effect()) mais aussi avec input(), output() et model() permettant de délaisser les décorateurs @Input() et @Output().

A noter que dans les dernières versions, Angular a introduit :

LinkedSignal (v19) : Un nouveau signal qui permet de réinitialiser ou de mettre à jour une valeur en fonction d’un autre signal source
Signal Forms (v21) : Une nouvelle approche des formulaires basée sur les signaux pour une gestion d’état simplifiée et plus réactive

Le Signal Forms est un changement assez majeur dans les dernières nouveautés puisqu’il va révolutionner la manière de créer et gérer ses formulaires en Angular, l’une des fonctionnalités importantes de toute application complexe. En effet, cela implique que les FormGroup et FormControl d’Angular, autrefois utilisés pour gérer ses formulaires, seront remplacés avec des Signals, puisque dorénavant on utilisera l’api form() d’Angular pour pouvoir avoir un formulaire.

readonly loginModel = signal({email: '', password: ''}); readonly form = form(loginModel);

Cela facilite énormément les choses puisque, dorénavant, nous n’avons plus à utiliser les différentes méthodes comme patchValue ou setValue pour mettre à jour manuellement les valeurs du formulaire: il suffit de modifier directement le signal !

Les Signals ne remplacent pas totalement RxJS (qui reste toujours préférable pour faire de l’asynchrone complexe), mais ils deviennent la norme pour la gestion d’état des composants. Ils rendent le code plus lisible, plus facile à tester et surtout, ils ouvrent la porte à un futur Zoneless (c’est-à-dire sans Zone.js), pour des applications web encore plus légères.

Plus d’informations sur la documentation d’Angular concernant les signals

Le Control Flow natif : RIP les directives !

L’une des nouveautés les plus visibles pour le développeur est l’abandon des directives *ngIf, *ngFor et *ngSwitch. Bien qu’elles aient fait la renommée d’Angular, elles obligeaient à importer le CommonModule, alourdissant chaque composant.

La nouvelle syntaxe de contrôle (syntaxe avec les @) est intégrée directement au compilateur. Elle est non seulement plus lisible – se rapprochant du JavaScript pur et autres langages de templating – mais elle est aussi jusqu’à 90% plus rapide lors de l’exécution !!

@if (user.isLoggedIn()) {
  <user-profile />
} @else {
  <login-form />
}

@for (item of items(); track item.id) {
  <li>{{ item.name }}</li>
}

Cette syntaxe impose désormais la propriété track dans les boucles, évitant ainsi les problèmes de performance classiques où le DOM était intégralement reconstruit sans nécessité.

Structure et Performance

La renaissance d’Angular ne se passe pas seulement dans le code, mais aussi dans les coulisses de la compilation.

Pendant des années, Webpack a été le moteur standard, mais sa lenteur sur les gros projets devenait un frein majeur à la productivité. Sa popularité a fortement décliné au sein de la communauté js au cours de ces dernières années, à tel point que React a finit par passer de Webpack à Vite par défaut.

Attention, spoiler ! Angular en a fait de même : depuis la version 17, Angular est passé de Webpack vers Vite et esbuild à son tour, qui est un véritable tournant. Ce changement est une petite révolution pour le quotidien des développeurs : le temps de build initial et le rafraîchissement à chaud (HMR) ont été divisés par 3 ou 4. Là où il fallait parfois attendre de longues secondes pour voir une modification s’afficher, l’expérience est désormais rapide, voire quasi instantanée, alignant enfin Angular sur la fluidité et l’agilité des outils de build les plus modernes du marché.

Sur une vision plus large, Angular a simplifié énormément de notions complexes d’Angular en … les supprimant ! ❌

Notion considérée comme « complexe », et s’établissant comme une des plus grandes barrière à l’entrée :les modules. Pendant plus de sept ans, tout développeur Angular devait se plier à un rituel complexe : la création de NgModules. Pour afficher un simple bouton, il fallait le déclarer dans un module, l’importer dans un autre, et s’assurer que toute la chaîne de dépendances était cohérente. Cette architecture, bien que robuste pour de très gros projets, était devenue un fardeau cognitif et technique.

Les modules agissaient comme des intermédiaires obligatoires. Ils rendaient le code verbeux et rendaient le Tree Shaking (l’élimination du code inutile) difficile pour les outils de build. Résultat : des bundles plus lourds et une courbe d’apprentissage décourageante pour les débutants habitués à la simplicité de React ou Svelte.

Depuis la version 17, les Standalone Components sont désormais la norme. Un composant est maintenant autonome : il gère lui-même ses importations. Cela une apporte une simplicité (plus besoin de créer un fichier module), et une meilleure clarté (tout est visible au niveau du composant).

Si les Standalone Components ont simplifié la structure, les Deferrable Views (@defer) ont révolutionné la performance au chargement. Avant, fragmenter une application en petits morceaux (Lazy Loading) demandait une configuration complexe au niveau du routeur. Désormais, vous pouvez retarder le chargement de n’importe quel composant lourd directement dans votre template avec une simplicité déconcertante :

@defer (on viewport) {
  <heavy-chart-component />
} @placeholder {
  <div>Chargement du graphique...</div>
}

Grâce à @defer, Angular ne télécharge le code du composant que lorsque l’utilisateur le voit à l’écran (ou au survol, ou après un délai). C’est une arme absolue pour améliorer le LCP (Largest Contentful Paint) et réduire drastiquement la taille du bundle initial.

SSR et Hydration

Autre changement notable: celui-ci concerne la partie SSR d’Angular. Pas forcément utilisé par tout le monde, mais il mérite néanmoins d’être mentionné.

Pendant longtemps, le rendu côté serveur (SSR) avec Angular Universal était perçu comme une « verrue » complexe à maintenir. Avec la renaissance, le SSR est devenu un citoyen de première classe.🥇

L’introduction de l’Hydratation complète (v17) puis incrémentale (v19) change la donne. Au lieu de détruire le HTML envoyé par le serveur pour le remplacer par le rendu client (le fameux « flicker » ou clignotement), Angular « réhydrate » intelligemment le DOM existant. Résultat : les applications sont interactives presque instantanément.

Quant au SEO, les moteurs de recherche indexent un contenu déjà rendu et performant. Google ne se contente plus de lire vos mots-clés ; il mesure l’expérience utilisateur. Cela améliore donc le LCP qui est une métrique importante pour l’expérience utilisateur. Un contenu déjà rendu, c’est l’assurance que Google comprend votre page immédiatement, complètement et qu’il vous récompense pour la vitesse que vous offrez à l’internaute, améliorant donc votre référencement par rapport aux concurrents.

Conclusion

Toutes ces évolutions, des Signals aux Standalone Components, convergent vers un seul but ultime : l’abandon de Zone.js.

Pendant une décennie, cette bibliothèque a été le moteur d’Angular, se chargeant de tout le mécanisme gérant la détection de changements. Mais cette omniprésence avait un coût : une boîte noire difficile à déboguer et des performances bridées par une vérification globale et systématique de l’application.

Ce sont tous ces changements opérés par l’équipe d’Angular qui rendent aujourd’hui le comportement du framework plus prévisible et plus proche des standards du JavaScript moderne.

Alors, is Angular back in the game ??

Ressources utiles concernant Angular, son fonctionnement et ses nouveautés :

https://angular.dev

https://angular-university.io