Une feuille de route Angular – Le passé, le présent et le futur d’Angular

Mises à jour d’Angular : Quoi de neuf dans la version 11

A compter de novembre 2020, la version 11.0.0 d’Angular est maintenant disponible. Bien que cette version apporte de nombreuses mises à jour à la plateforme, les fonctionnalités les plus importantes comprennent des constructions plus rapides avec TypeScript 4.0, des harnais de tests de composants et des mises à jour ESLint.

C JavaScript paléolithique – SproutCore

Au début, il y avait SproutCore. C’était le premier framework JavaScript complet visant à faciliter la création d’applications Web monopage de qualité bureautique. Ce n’est pas que cela n’était pas possible auparavant. Lorsque Google a lancé Gmail, il a montré au monde que les applications Web pouvaient réellement remplacer les applications de bureau complexes. Google a même mis en libre accès la boîte à outils Closure – un ensemble de bibliothèques et un compilateur d’optimisation qu’il a utilisés pour construire Gmail.

Le problème était que les outils Closure de Google n’étaient pas très conviviaux pour les développeurs. Ils s’appuyaient fortement sur Java, ce qui aliénait les développeurs web qui avaient l’habitude de travailler avec JavaScript, PHP, Ruby et Python. Gmail était une excellente démonstration de ce qui était possible, mais le développement d’applications similaires semblait encore hors de portée pour beaucoup.

Certains développeurs courageux ont réussi à enchaîner d’étonnantes applications à page unique en utilisant une combinaison de jQuery, de ruban adhésif et d’espoir. Alors que ces apps semblaient incroyables pour les utilisateurs finaux, pour les développeurs qui y travaillaient, les apps se sont rapidement transformées en des tas énormes de dettes techniques qui faisaient que l’équipe de développement redoutait de se rendre au travail le matin.

En conséquence, quelques développeurs entreprenants ont commencé à travailler sur des frameworks qui mettraient les applications de type Gmail à la portée des développeurs web du monde entier. SproutCore a été le premier de ces frameworks à prendre son envol. Il était livré avec un ensemble complet de widgets qui permettaient de construire des applications web complexes sans même toucher au HTML ou au CSS.

Cela a fini par être formidable pour les anciens développeurs de bureau qui avaient été traînés à coups de pieds et de cris sur le web. Plusieurs autres frameworks ont surgi avec des objectifs similaires ; GWT et Cappuccino étaient les plus importants. Ces frameworks évitaient même le JavaScript en transposant d’autres langages en JS. Encore une fois, c’était génial pour les développeurs de bureau. Mais cela laissait les développeurs web passionnés sur le carreau et leur donnait l’impression que leurs compétences HTML, CSS et JavaScript durement acquises n’avaient aucune valeur.

Cela laissait une ouverture pour un framework qui embrassait vraiment le web, au lieu d’essayer de le plâtrer et de prétendre que c’était autre chose. Quelques premiers frameworks (Backbone et Knockout) sont apparus, et ont obtenu un succès modéré. Ember est également apparu à cette époque. Il a pris SproutCore, l’a dépouillé jusqu’à l’os et a essayé de le reconstruire en quelque chose de vraiment convivial pour le Web. Ember voulait être l’homme à six millions de dollars du monde JavaScript : reconstruire mieux, plus fort et plus vite.

Aucun de ces frameworks n’a connu une popularité fulgurante. Le monde attendait quelque chose de mieux. En 2010, ce quelque chose de mieux est apparu – il a été nommé Angular.

L’âge d’or d’Angular

Même avant la sortie de la version 1.0 d’Angular, ce dernier a pris d’assaut le monde du développement frontal. Enfin, nous avions un framework JavaScript facile à utiliser qui traitait le HTML comme un citoyen de première classe. Les développeurs et les concepteurs pouvaient désormais travailler ensemble pour créer des applications monopages étonnantes. Cela a été un soulagement pour les concepteurs, qui avaient été agacés et offensés parce que les frameworks plus anciens avaient traité HTML et CSS comme des outils pour barbares, des outils qu’aucun développeur civilisé ne devrait avoir à toucher.

La première chose qui a semblé magique aux développeurs essayant Angular pour la première fois était la liaison de données bidirectionnelle. Avant cela, la plupart des développeurs n’avaient vu ce type de liaison de données que dans des frameworks de bureau comme WPF et Windows Forms. C’était formidable de pouvoir lier des formulaires et d’autres éléments d’interface utilisateur à des objets de modèle JavaScript. Alors que la liaison de données bidirectionnelle pouvait causer des problèmes de performance lorsqu’elle était surutilisée, les équipes qui l’utilisaient judicieusement ont constaté qu’Angular leur permettait de créer des applications frontales complexes beaucoup plus rapidement que jamais.

Angular s’est avéré populaire pour plus que la simple liaison facile de données à des éléments HTML. Les directives Angular ont fourni un moyen facile de créer des composants HTML + CSS réutilisables. Bien que d’autres frameworks JavaScript aient fourni cela avant Angular, Angular a été le premier à devenir extrêmement populaire. Les composants réutilisables étaient utilisés depuis longtemps dans les frameworks côté serveur. Les contrôles utilisateur ASP.NET et les modèles partiels dans Rails et Django ne sont que quelques
exemples.

Enfin, Angular a rendu l’injection de dépendances populaire dans le monde du développement frontal. L’injection de dépendances était depuis longtemps populaire dans les applications d’entreprise, ce qui explique peut-être pourquoi elle n’avait pas pris dans le monde JavaScript. Les développeurs frontaux ont longtemps eu une aversion pour ce qu’ils considèrent comme des modèles de conception de logiciels d’entreprise inutilement complexes. Cette préoccupation n’est pas sans fondement. Vous est-il déjà arrivé, au cours de l’écriture d’une application, de vous dire  » Ce dont j’ai vraiment besoin ici, c’est d’un  » SimpleBeanFactoryAwareAspectInstanceFactory ? « 

L’injection de dépendances, pourtant, a fait ses preuves. Et Angular a rendu l’injection de dépendance facile à utiliser pour un public qui ne l’avait pas beaucoup utilisé dans le passé. Vous avez besoin d’un client HTTP ? Ou peut-être aimeriez-vous faire de l’animation ? Aucun problème. Angular dispose de services intégrés pour cela. Il suffit de les demander, et Angular les injectera dans vos composants. Pas besoin d’instancier quoi que ce soit vous-même.

Ou peut-être vouliez-vous utiliser les objets window ou location du navigateur sans rendre impossible le test unitaire de vos composants en dehors d’un navigateur ? Angular vous a couvert là aussi, avec ses services intégrés $window et $location. Au moment de l’exécution, vous obtenez les objets du navigateur que vous attendez. Et lors de l’exécution de tests unitaires côté serveur dans Node.js, vous pouviez passer des services fictifs dans vos composants pour vous assurer qu’ils se comportaient comme prévu dans divers scénarios.

Si tout cela ne suffisait pas, Angular a également simplifié l’enregistrement et l’injection de vos propres services. Pour les développeurs qui étaient habitués à lier toutes leurs données au DOM et à espérer le meilleur, c’était génial. Si vous écriviez une nouvelle application frontale faisant appel à des API qui coûteraient beaucoup d’argent à votre entreprise en cas de surutilisation, vous préféreriez probablement être en mesure d’écrire des tests à l’avance pour vous assurer que votre application n’essaie pas de faire quelque chose comme appeler l’API Twilio 800 millions de fois.

Donc, vous créeriez un service Twilio qui est injecté au moment de l’exécution. Au moment des tests, vous créeriez un service fantaisie qui enregistre le coût de chaque appel d’API que votre application essaie de faire. Vous écrivez des tests qui couvrent les scénarios d’utilisation courants et vous vous assurez que ces scénarios n’entraînent pas une facture à 7 chiffres pour votre entreprise. Dans l’ensemble, la plupart des développeurs ont trouvé que les directives Angular combinées à l’injection de dépendances permettaient d’écrire des applications frontales modulaires et testables en utilisant des techniques d’ingénierie logicielle éprouvées. De nombreuses équipes de développement ont décidé que cela résultait en un état de choses heureux, et ont décidé de se lancer à fond dans Angular.

Le déclin d’Angular ? L’essor de React

Alors que les choses étaient pour la plupart formidables dans le monde d’Angular, ce n’était pas tout le soleil et les sucettes. Les développeurs commençaient à rencontrer de graves problèmes de performance lorsqu’ils essayaient de lier trop d’objets de modèle à trop d’éléments DOM. Certaines applications ralentissaient à vue d’œil. Les appels directs à $digest et autres sorcelleries de magie noire commençaient à devenir nécessaires pour obtenir des performances acceptables. À peu près au même moment, un nouveau challenger est apparu : React. Au début, React ne semblait pas représenter un trop grand danger pour Angular. Après tout, ces cinglés de React s’étaient donné la peine d’inventer JSX, qui ressemblait beaucoup à un moyen d’intégrer du balisage dans votre code. Ne nous étions-nous pas donné beaucoup de mal pour inventer des langages de templating pour la raison explicite d’éviter de mélanger le markup et le code ?

Comme il s’est avéré, l’approche de React était assez populaire dans la communauté de développement front-end. Il n’a cependant pas connu une popularité fulgurante. Angular était encore dominant, et il semblait que cela resterait ainsi. Jusqu’à ce que la popularité d’Angular reçoive un bon coup de pied dans les dents d’une source inattendue : l’équipe Angular elle-même.

L’introduction d’Angular 2

Angular 2 a été annoncé pour la première fois lors de la conférence ng-europe en 2014. Les plans de l’équipe Angular ont été un choc pour la communauté Angular, c’est le moins que l’on puisse dire. La réaction des développeurs Angular a été rapide et négative… et non sans raison. Angular 2 se débarrasserait de nombreux concepts familiers d’Angular 1, introduirait un nouveau langage de templating incompatible (et oh, au fait) serait également programmé à l’aide d’un langage entièrement nouveau.

AngularJS

Bien qu’Angular 1 et Angular 2 aient été appelés ‘Angular’, en réalité, il s’agissait de frameworks très différents avec quelques points communs. Pour éviter toute confusion, l’équipe d’Angular a commencé à désigner l’ancienne version d’Angular par ‘AngularJS’, et la nouvelle version par simplement ‘Angular’. Cela est intuitivement logique puisque AngularJS était écrit en JavaScript, et Angular non. Pour que la distinction entre les frameworks reste claire, je ferai référence à Angular 1 comme AngularJS à partir de maintenant.

En raison de tout cela, les développeurs d’AngularJS ont perdu confiance dans l’avenir du framework. Ils ont menacé de passer à un nouveau framework sur les projets futurs, et c’est précisément ce que beaucoup d’entre eux ont fait. React a été le plus grand bénéficiaire de l’exode massif d’AngularJS.

Bien que React n’ait pas fait autant qu’AngularJS, dans un sens, c’était positif. Si vous utilisez une bibliothèque de vues qui n’essaie pas d’inclure tout plus l’évier de cuisine, il est beaucoup plus difficile pour les développeurs de cette bibliothèque de vous couper l’herbe sous le pied à l’avenir. Au début, l’utilisation de React était un peu difficile par rapport à AngularJS. Vous avez dû bricoler un patchwork de bibliothèques juste pour couvrir la fonctionnalité que l’AngularJS fournissait hors de la boîte.

De nombreuses équipes ont vu cela comme un bon moyen de réduire le risque, car il était peu probable que les développeurs de toutes ces bibliothèques décident de faire des changements de rupture incompatibles avec le passé en même temps, ce qui est essentiellement ce qu’Angular avait fait.

L’émergence de Vue

Pour aggraver les malheurs d’AngularJS, un autre framework nommé Vue est apparu à peu près au même moment où le drame d’Angular 2 se produisait. Vue était inspiré par AngularJS mais visait à le simplifier et à se débarrasser de ce que le créateur de Vue considérait comme une complexité inutile (Vue semblait donc très familier aux développeurs AngularJS existants). Vue a fourni un refuge sûr pour de nombreux développeurs AngularJS qui ne voulaient pas passer à React.

Cela ne signifie pas que les développeurs AngularJS n’attendaient pas patiemment l’apparition d’Angular 2. Mais il est clair qu’il y a eu un exode massif d’AngularJS vers React et Vue en raison de l’incertitude causée par les plans pour Angular 2.

Réveiller de ses cendres avec Angular 2

Éventuellement, Angular 2 a été publié. Comme prévu, il a supprimé de nombreux concepts familiers d’AngularJS, mais a conservé quelques-uns des meilleurs morceaux comme les services et l’injection de dépendances. Heureusement pour la santé mentale des développeurs, Angular utilise TypeScript ordinaire et non un fork comme prévu initialement.

Pour rendre les choses plus confuses, l’équipe Angular a maintenu un fork du nouveau framework qui utilisait le langage de programmation Dart au lieu de TypeScript. Initialement, les versions TypeScript et Dart ont été développées de manière synchronisée, générées à partir d’une seule base de code. Finalement, les versions TS et Dart d’Angular ont décidé de suivre des voies séparées, et Angular Dart existe désormais de manière autonome.

Malgré cette confusion, la popularité d’Angular a recommencé à augmenter après la sortie d’Angular 2. Cela s’est produit lentement. Comme cela se produit souvent dans le développement de logiciels, les tendances ont changé. Les développeurs ont réalisé qu’un gros framework inclus dans les batteries pouvait en fait être utile. Après tout, lorsque votre application devient suffisamment grande, vous finissez par avoir réellement besoin de toutes ces piles.

Les développeurs d’entreprise, en particulier, ont commencé à revenir vers Angular. Cela a du sens. Habituellement, lorsque vous commencez une application web d’entreprise, vous savez qu’elle va être complexe. Il n’y a aucun intérêt à commencer avec un minuscule MVP quand vous savez dès le début les 87 choses que votre application va devoir faire.

Où est Angular 3 ?

Bien qu’Angular 2 n’était pas parfait, de nombreux développeurs d’applications web complexes ont commencé à réaliser que le nouvel Angular amélioré répondait bien à leurs besoins. Heureusement pour eux, Angular avait quelques améliorations passionnantes en magasin. Plus important encore, l’équipe Angular a démontré qu’elle pouvait publier de manière cohérente de nouvelles versions du framework avec peu de changements de rupture entre les versions

Dans un geste qui semblait étrange à l’époque, l’équipe Angular a décidé de sauter entièrement la version 3 et de passer à la version 4. Cela a été fait pour une bonne raison : l’équipe travaillant sur le paquet routeur d’Angular avait déjà poussé et publié la version 3, tandis que le reste d’Angular était encore à la version 2.3. Ils ont décidé de garder toutes les versions du paquet Angular en synchronisation en allant de l’avant, et tout faire passer à la version 4 pour la prochaine version était le moyen le plus facile d’y parvenir.

Angular 4

Angular 4 avait quelques changements significatifs, y compris l’ajout de la compilation en avance sur le temps, ce qui a entraîné de petits paquets JavaScript de production et un temps de chargement de l’application plus court. La prise en charge du rendu côté serveur a été ajoutée, ce qui a donné un coup de pouce aux équipes qui souhaitaient effectuer le rendu de leur application à l’avance pour améliorer les performances de chargement initial. De nombreuses autres améliorations ont été ajoutées dans l’ensemble du framework, mais la mise à niveau des apps d’Angular 2 à 4 a été rapide et sans douleur dans la plupart des cas.

Angular 4.3 et Angular 5

Angular 4.3 a ajouté un nouveau client HTTP qui était plus facile à utiliser que l’ancien service HTTP. Dans Angular 5, l’ancien service HTTP était déprécié et serait abandonné dans la prochaine version. Malgré cet inconvénient, il y a eu relativement peu de récriminations car la mise à niveau a été simple dans la plupart des cas. Angular 5 a également ajouté un meilleur support de l’internationalisation et d’autres optimisations de compilation.

Angular 6 et 7

Angular 6 et 7 ont déçu certains développeurs. Il n’y a pas eu de grands changements, mais de nombreuses petites améliorations de la qualité de vie, notamment au niveau de l’outillage Angular CLI. La diminution du nombre de changements visibles n’est pas une indication que l’équipe Angular a cessé d’innover. Au lieu de cela, cela montre que le framework est mature, de sorte que l’équipe de développement est maintenant libre de faire plus de travail en coulisses, de corriger les bugs et d’améliorer les performances.

La stabilité du framework depuis la sortie d’Angular 2 a attiré certains développeurs AngularJS de la vieille école dans le monde Angular. Elle a également attiré l’attention des équipes de développement des entreprises. Lorsque vous créez des applications d’entreprise qui peuvent vivre pendant des décennies, l’idéal est d’utiliser un framework dont les nouvelles versions sont prévisibles, mais qui n’évolue pas trop rapidement. Un développeur qui n’a utilisé qu’Angular 2 pourrait être opérationnel et contribuer à une app Angular 7 en quelques minutes.

Angular 8 et Angular Ivy

Et cela nous amène à aujourd’hui. Comme nous l’avons vu, Angular a parcouru un long chemin. Il est passé de l’amour des développeurs web à l’injure, puis à l’admiration, bien qu’il ne soit pas encore aimé à nouveau comme il l’était à ses débuts.

À l’horizon, nous avons Angular 8. Une tonne de travail a été faite dans Angular 8 pour le rendre facile à utiliser avec le système de construction Bazel, ce qui est une nouvelle absolument incroyable pour tous les 3 développeurs qui l’utilisent en dehors de Google. Lisez les changements apportés à Angular 8.

Plus excitant, cependant, l’équipe Angular travaille dur sur un nouveau rendu appelé Angular Ivy. Il est destiné à être un remplacement drop-in pour le rendu actuel. Pour la plupart, les apps actuelles n’auront pas besoin de faire des changements pour utiliser Angular Ivy.

Si Angular Ivy est un remplacement drop-in, pourquoi les développeurs devraient-ils s’en soucier ? Deux raisons importantes : la vitesse, et la taille du bundle – deux préoccupations très importantes. Pendant quelques années, il semblait que les développeurs web étaient devenus un peu fous. Les équipes expédiaient des paquets JavaScript de 5 Mo, 10 Mo, voire plus, et pensaient que cela ne posait aucun problème. Après tout, les applications fonctionnaient parfaitement sur les MacBook Pros alimentés en i7 des développeurs, alors elles devraient fonctionner correctement pour tout le monde, non ?

Malheureusement, dans le monde réel, tout le monde n’utilise pas le dernier et le meilleur matériel. Des centaines de millions de personnes accèdent à Internet uniquement sur des téléphones Android plus anciens, avec une puissance de traitement légèrement supérieure à celle d’une pomme de terre, par le biais de connexions Internet à peine plus rapides qu’un accès commuté. Pour ces utilisateurs, un énorme paquet JavaScript met une éternité à se charger, et encore plus longtemps à être analysé et exécuté par leur appareil. Même dans des cas moins extrêmes, il existe d’innombrables utilisateurs dans le monde qui n’utilisent pas le matériel le plus récent et le plus performant. Pour eux, les applications JavaScript massives sont utilisables (mais pénibles).

Angular Ivy

Le moteur de rendu Angular Ivy aidera de plusieurs façons :

1. Il est écrit avec un œil sur l’efficacité, donc il accomplira les mêmes tâches tout en exécutant beaucoup moins d’instructions du CPU. Cela améliorera à la fois l’autonomie de la batterie et la santé mentale des utilisateurs avec des appareils moins que puissants.
2. Le moteur de rendu sera écrit d’une manière beaucoup plus modulaire que le moteur de rendu actuel. Cela le rendra beaucoup plus propice au tree-shaking et à l’élimination du code mort. En conséquence, votre bundle JavaScript de production ne comprendra que le code nécessaire pour exécuter votre application, au lieu de regrouper tout plus l’évier de cuisine comme cela se produit souvent avec le rendu actuel.
3. En plus de la réduction de la taille du bundle et de l’amélioration de la vitesse de rendu, Angular Ivy a quelques autres améliorations de la qualité de vie pour les développeurs Angular. Les temps de reconstruction sont significativement plus rapides. Donc, si vous exécutez votre application en mode développement et attendez que vos modifications apparaissent, vous allez maintenant passer beaucoup moins de temps à attendre.
4. La vérification des types de templates est améliorée, ce qui signifie que vous attraperez plus d’erreurs au moment de la compilation plutôt qu’au moment de l’exécution. Les bugs de templates au moment de l’exécution sont ennuyeux, car soit ils vous mordent pendant les tests, soit ils mordent vos utilisateurs lorsqu’ils essaient d’utiliser votre application.
5. Le compilateur de templates Angular Ivy générera du code lisible par l’homme, ce que le compilateur actuel de View Engine ne fait pas. Cela sera pratique lorsque vous essayez de traquer les bugs difficiles de template.

Le résultat net : des apps plus petites, des apps plus rapides, des développeurs plus heureux et des utilisateurs plus heureux.

Angular 9

Voici un aperçu d’Angular 9.

Les principaux points saillants comprennent :

• Fonctionnalités intégrées d’Angular
• Développement mature avec Angular
• Compréhension des moteurs de vue Angular
• Angular Ivy résout des problèmes de longue date
• Angular Ivy et mobile
• Sélecteur-…less Directives
• Amélioration des diagnostics Angular
• Internationalisation avec Angular Ivy
• DI et Type-Safe dans Angular 9
• Injection de dépendance Changements dans Angular Core
• Benchmarks Angular (Angular 8.2.7 vs. 9.0.0-next.5)

Angular 10

La version 10.0.0 d’Angular a été publiée fin juin 2020. Une version majeure, Angular 10 comprend des changements tels qu’un nouveau sélecteur de plage de dates dans Angular Material, la mise à niveau des versions de TypeScript, des mises à jour de versions de bibliothèques, et plus encore.

Les nouvelles fonctionnalités comprennent :

• Interface du compilateur Ngtsc
• Configurer les délais d’attente asynchrones
• Rapport sur le fichier de verrouillage stale
• Calcul paresseux des basePaths

.

• Fusion des fichiers de traduction
• Mappage explicite

Angular 11

Angular version 11.0.0 a été publiée en novembre 2020. La version majeure d’Angular 11 fournit des mises à jour sur l’ensemble de la plateforme, y compris le CLI et le framework de composants.

Les fonctionnalités importantes comprennent :

• Des constructions plus rapides avec TypeScript 4.0
• Harnais de test des composants
• Mises à jour d’ESLint
• Aperçu du service de langue mis à jour
• Prise en charge du remplacement des modules chauds (HMR) mis à jour
• Amélioration des rapports et de la journalisation
• Inliaison automatique des polices

Le passé d’Angular, Present, and Future

Si vous avez utilisé Angular depuis ses premiers jours jusqu’à aujourd’hui, alors félicitations ! Bien qu’il y ait eu de nombreux passages à vide, nous avons fini par obtenir un framework rapide, moderne et agréable à utiliser.

Si vous étiez un développeur AngularJS mais que vous êtes passé à React, Vue, ou autre, je vous encourage à donner un autre regard à Angular. Il vaut votre temps, même si vous décidez de rester avec ce que vous utilisez maintenant.

Et si vous n’avez jamais utilisé Angular du tout, pourquoi ne pas lui donner une chance ?

Nous venons de faire un tourbillon à travers le passé, le présent et le futur d’Angular. Sans aucun doute, cela a été un sacré tour. Indépendamment de vos antécédents Angular, j’espère que vous avez apprécié la visite !

Quel framework travaillez-vous avec et pourquoi ? Si vous avez des questions ou des commentaires, assurez-vous de les entrer ci-dessous.

Vous cherchez des composants d’interface utilisateur agnostiques au framework ? GrapeCity dispose d’un ensemble complet de composants d’interface utilisateur JavaScript, notamment des grilles de données, des graphiques, des jauges et des contrôles de saisie. Nous proposons également de puissants composants de feuille de calcul, des contrôles de rapport et des vues de présentation améliorées. Nous avons un support profond pour Angular (ainsi que React et Vue) et nous nous consacrons à l’extension de nos composants pour une utilisation dans les frameworks JavaScript modernes.