Quel avenir pour le framework Angular ?
Angular, le framework JavaScript largement utilisé et développé par Google, s’est imposé comme un choix incontournable pour le développement d’applications web modernes. Avec sa communauté dynamique, sa documentation exhaustive et ses fonctionnalités avancées, il est devenu un outil privilégié par les développeurs de tous niveaux. Cependant, dans un paysage technologique en perpétuelle évolution, quelle est la position actuelle du framework Angular et quel avenir peut-on envisager ?
Une amélioration continue du Framework Angular
Google et la communauté Angular travaillent constamment à l’amélioration du framework. Cette démarche inclut des mises à jour régulières qui apportent des corrections de bugs, des améliorations de performance et de nouvelles fonctionnalités. Le framework Angular continue de bénéficier d’une large adoption dans l’industrie, particulièrement pour les applications d’entreprise. Sa robustesse et sa modularité en font une solution de choix pour les projets à grande échelle.
Le moteur de rendu Ivy, introduit avec Angular 9, continue de recevoir des améliorations. Ivy rend les applications plus petites, plus rapides et plus faciles à déboguer, ce qui améliore l’expérience des développeurs et les performances des applications.
L’équipe Angular s’efforce de faciliter la migration vers les nouvelles versions du framework. De plus, un effort constant est fourni pour améliorer l’interopérabilité avec d’autres bibliothèques et frameworks. Google a démontré un engagement à long terme envers Angular, avec une feuille de route claire pour les futures versions et un support étendu pour les versions existantes.
L’avenir d’Angular semble prometteur avec des mises à jour régulières, une adoption continue et des améliorations constantes visant à optimiser la performance et la productivité. Les entreprises et les développeurs peuvent s’attendre à voir Angular rester un choix pertinent pour le développement d’applications web complexes.
Dans la continuité des nombreuses évolutions mises en place par l’équipe Angular depuis plus d’un an, quelques annonces et changements à venir pourraient néanmoins influencer le futur du framework Angular.
Les tendances qui pourraient influencer l’avenir du framework Angular
L’évolution vers le cloud
Angular est parfaitement adapté pour le développement d’applications web cloud-native. Cette tendance devrait se renforcer à mesure que les entreprises migrent vers des solutions cloud.
L’intelligence artificielle et l’apprentissage automatique
Le framework Angular intègre des capacités d’intelligence artificielle et d’apprentissage automatique, offrant aux développeurs la possibilité de créer des applications web plus intelligentes et réactives. Cette tendance est appelée à croître avec la maturation de ces technologies.
L’interface utilisateur mobile
Le framework Angular est idéal pour le développement d’applications web mobiles. Cette tendance devrait se maintenir avec l’accroissement continu de l’utilisation des appareils mobiles, grâce à son architecture modulaire, son support de TypeScript, ses performances optimisées, ses nombreuses fonctionnalités intégrées, son support pour PWA, Angular Universal pour le rendu côté serveur, sa communauté active, et sa documentation exhaustive avec des outils comme Angular CLI.
Quelles sont les nouveautés du framework Angular annoncées ?
Zoneless, la disparition de Rxjs
L’équipe a évoqué un avenir dans lequel le framework Angular fonctionnerait « sans Zone.js et RxJs » (actuellement testable au stade expérimental). Même si nous savions que le « sans zone » était prévu depuis un certain temps, il semble que l’accueil très positif d’Angular Signal ait poussé l’équipe à envisager de supprimer les Rxjs en tant que dépendance.
Une nouvelle API pour le Control Flow
La manière d'écrire les conditions structurelles et la gestion du lazyload dans le template tend à évoluer ! Comparons ces changements :
Nous passons à un contrôle de flux par bloc, mis en place pour plusieurs raisons :
- Se rapprocher davantage de la syntaxe classique de JavaScript
- Réduire la complexité associée aux <ng-template />
Nous n’aurons donc plus besoin d’utiliser <ng-template> dans nos composants, ce qui rendra nos templates plus proches d’une syntaxe “purement JS et HTML”. De plus, il ne sera plus nécessaire d’importer CommonModule ou NgIf dans le tableau des importations, car ils sont désormais intégrés !
Deux informations importantes sont à noter :
- Les directives actuelles deviendront obsolètes.
- Le tracking avec @for est désormais obligatoire pour des raisons de performance. Pour cela, il suffit d’utiliser @for (item of items; track item).
Le mot-clé @defer pour optimiser la performance de vos futures applications avec le framework Angular
Autre nouveauté : l’apparition d’un mot-clé @defer. L’objectif est de fournir une méthode agréable et facile pour gérer le chargement des différentes parties de nos pages.
Actuellement, le lazy loading nous permet de retarder le chargement du code JavaScript d’une route via loadComponent() ou loadChildren() directement dans nos fichiers de routage.
Grâce à @defer, nous pourrons désormais effectuer le lazy loading de sections distinctes de nos pages, notamment les composants utilisés dans celles-ci. Il s’agit donc d’une optimisation des performances. Voici l’exemple le plus simple :
Tout ce qui se trouvera à l’intérieur du bloc @defer sera chargé de manière asynchrone, c’est-à-dire après que tout le reste soit chargé.
Il existe également des moyens d’indiquer plus précisément quand le bloc doit être chargé.
Ici, <component /> n’est chargé que lorsque Condition est vraie. Il est important de comprendre ce que signifie "est chargé". En réalité, cela fonctionne selon le même principe que le lazy loading des pages : tout le code JavaScript nécessaire pour faire fonctionner les éléments contenus dans le bloc @defer ne sera chargé et exécuté que lorsque le bloc sera trigger.
Cela diffère de l'utilisation d'un ngIf, car un ngIf se contente de faire apparaître ou disparaître le HTML dans le template, mais le JavaScript reste chargé et est exécuté par le navigateur. Ce n'est pas le cas ici ! Le code ne se chargera que lorsque le bloc @defer sera trigger.
Ok alors, comment faire pour trigger ce bloc defer ?
Plusieurs manières de faire existent :
- Le mot-clé “when” permet une gestion impérative du bloc, comme illustré précédemment. Il suffit de lui passer une expression qui retourne un booléen.
- En revanche, le mot-clé “on” offre une approche plus déclarative. On lui passe un événement.
Voici quelques exemples :
Par défaut, les blocs @defer ne montrent aucun contenu lorsqu’ils ne sont pas activés. Cependant, il est possible de spécifier un contenu à afficher en attendant que les blocs soient eux-mêmes rendus :
Ici, dès que le bloc entre dans le champ de vision (viewport), il sera activé et le composant commencera à se charger. Cependant, si le composant est volumineux, le chargement peut prendre du temps. Par conséquent, il est possible d’ajouter un contenu de chargement qui s’affichera pendant que le composant est en cours de chargement.
Nous avons également la gestion d’erreur :
Il peut arriver que le chargement du composant échoue, par exemple si la connexion est interrompue entre le moment où l’utilisateur accède à la page et celui où le bloc devrait s’afficher. À noter que le bloc d’erreur envoie un contexte via @error.
Il y a d’autres subtilités et détails concernant @defer que je vous encourage à découvrir par vous-mêmes, mais l’essentiel est là !
Le RFC conclut en précisant que l’équipe Angular réfléchit à la manière d’intégrer tout cela avec le SSR (rendu côté serveur) et l’hydratation partielle. Il est donc probable qu’il y ait des API spécifiques pour configurer l’utilisation de @defer avec le SSR.
L’annonce surprenante d’une collaboration avec Wiz
L’équipe Angular a fait une annonce surprise concernant sa collaboration étroite avec Wiz, un framework utilisé en interne chez Google pour des applications publiques bien connues telles que YouTube, Google Photos, Drive, Gmail, et plus encore.
Cette collaboration a débuté avec les signaux partagés entre Wiz et le framework Angular. Aujourd’hui, ces signaux Angular sont à présent utilisés à 100 % sur YouTube… Un fait d’autant plus impressionnant que certains déclaraient récemment qu’Angular était sur le déclin.
À cette occasion, l’équipe Angular a également révélé sa stratégie interne : construire Angular pour les dix prochaines années et s’assurer qu’il reste un excellent choix à long terme. Ces perspectives optimistes prennent désormais tout leur sens !
L’essor du SSR (Rendu côté Serveur)
Depuis le lancement du framework Angular v17, l’utilisation du rendu côté serveur a augmenté de 37 %.
Une bonne nouvelle supplémentaire est que l’équipe Angular collabore également avec Wiz pour bientôt implémenter l’hydratation partielle. Cela nous offrira davantage d’options pour le rendu côté serveur et le lazyloading avec le mot-clé @defer.
Vers le chemin de la simplification
L’équipe Angular travaille également à améliorer la syntaxe des composants en éliminant les éléments redondants.
Plus de selectors, d’imports ni de “standalone : true” !
Ce n’est encore qu’au stade d’idée… Toutefois, rappelons-nous que les signaux l’étaient aussi peu de temps auparavant et à ce jour, ils sont une API entièrement disponible dans le framework et largement adoptée !
Syntaxe actuelle :
Syntaxe projetée :
Grâce à sa communauté solide, son engagement envers une culture de l’innovation, son vaste éventail d’applications et son intégration avec d’autres technologies, il est évident que le framework Angular est là pour durer. C’est un choix avisé pour les développeurs souhaitant créer des applications web modernes, évolutives et performantes.
Ces changements vont considérablement modifier notre approche du développement d’applications avec le framework Angular. Bien sûr, ces évolutions ne seront pas immédiates et les différentes APIs sont susceptibles de changer.
Cependant, je suis extrêmement enthousiaste à l’idée des perspectives que ces nouveautés ouvrent pour l’avenir d’Angular. Je suis convaincu que nous pourrons obtenir un framework exceptionnellement performant, offrant une excellente expérience de développement (DX) et une expérience utilisateur (UX) de qualité.
Liens utiles :
La documentation du nouveau control flow : https://v17.angular.io/guide/control_flow
Le site web de la ng-conf : https://ng-conf.org/
La chaine YouTube de la ng-conf : https://www.youtube.com/channel/UCm9iiIfgmVODUJxINecHQkA