Je compile ici mes arguments pro/con React et Angular. C'est mon avis, vous avez le droit d'avoir le vôtre, je le respecte totalement. Juste qu'à force de voir des gens bâcher sans quasiment d'argument Angular, je me suis dit que ça valait peut-être le coup que je fasse un article honnête qui ne cherche pas à dénigrer l'un ou l'autre mais poser des vrais arguments.

Je précise que j'ai commencé à faire du React après avoir suivi une formation React (SFEIR School React). Quand j'écris cet article, plus d'un an a passé où j'ai lancé deux projets en React, passer plusieurs mois entier à ne faire que du React sur ces deux projets mais aussi un autre projet qui a été commencé il y a 2-3 ans, à lire des articles autour de React dans ma veille quotidienne. Je suis dans un contexte client où la tendance est React et donc on s'échange beaucoup de bonne pratique, etc. Des conditions idéales je pense pour rejoindre le mouvement React comme bon nombre d'autres personnes du pôle après avoir fait du Angular. Et j'ai commencé à faire du React plein d'étoile dans les yeux.

Arguments contre Angular

Commençons par la partie qu'on voit le plus partout : les arguments qui sont contre Angular. En effet j'ai beau être plutôt partisan d'Angular, j'ai aussi quelques critiques envers le framework : je ne suis pas un fanatique décérébré en somme, je suis lucide sur ce qui crée de la friction en Angular.

La Syntaxe et la structure sont lourdes

C'est un point qu'on retrouve souvent et que je partage. Angular repose sur une écriture de composant à base de classe avec des annotations des fichiers séparés pour le html, le css et le code du composant. Le fait d'avoir plein de fichiers crée une certaine lourdeur. Le style classe avec beaucoup d'annotation rappelle beaucoup le Java annoté avec Spring (surtout que les classes Typescript sont formatées comme les classes Java, les décorateurs Typescript sont en @ comme pour Java, etc.).

L'un des derniers frameworks à utiliser des classes

La tendance actuelle côté frontend c'est les composants-fonctions comme en React, les composants déclaratifs comme en Vue ou même les syntaxes légères à la Svelte. Les classes sont les grandes absentes.

Je sais qu'en React on peut toujours faire des composants classes mais ce n'est plus la tendance. Par contre en Angular c'est comme ça depuis Angular 2 et ça ne bouge pas. On a des hooks sur les cycles de vie sur chaque composants classe qui sont à définir via des interfaces à implémenter. On a aussi des éléments qui pourraient être des fonctions qui deviennent des classes comme les Pipe (mais sans classes pas d'injection de dépendance et donc impossible de créer un Pipe qui dépendant d'autre chose).

L'injection de dépendance est omniprésente

Autre élément qui ressemble à ce qu'on fait en Java avec Spring (mais pas que) c'est l'injection de dépendance. On la retrouve absolument partout. Même l'utilisation de TypeScript permet d'éviter de mapper manuellement les éléments injectés, on se rend vite compte qu'on a pas le choix de passer par là et que beaucoup de chose ne se devine pas. On est d'accord que la documentation Angular est très complète mais parfois on ne sait juste pas ce qu'il faut qu'on s'injecte et comment pour obtenir les éléments qu'on veut.

L'injection de dépendance est aussi un piège au niveau des tests : si on gère mal nos modules on se retrouve très vite avec une quantité énorme d'éléments à fournir / mocker pour faire nos tests.

Le CLI et le compilateur sont des boites noires

Quand on fait de l'Angular difficile de se passer du CLI et du compilateur inclu. Parce que beaucoup l'oubli mais les composants Angular sont compilés sous une autre forme que celle qu'on écrit (on ne retrouve plus de séparation html/css/ts et le template html est réécrit en code js qui gère le DOM de façon réactive, etc.). Mais ça rend la chose un peu opaque. On sait tout faire via la CLI mais sans le CLI on ne saurait pas faire. Même si c'est vrai qu'on peut éjecter le CLI pour utiliser directement webpack mais du coup on se retrouve avec beaucoup de configuration à faire pour gérer les mêmes choses, configuration qu'il faudra maintenir…

Les composants sans CLI c'est galère

Le CLI c'est plus qu'un wrapper pour le compilateur, c'est aussi un gros outil de génération de code. On va pouvoir générer tous les fichiers qui sont nécessaire très vite pour un composant, un service, un pipe, etc. On peut le faire mais même, on se sent presque obligé vu que créer un composant c'est à minima :

  • créer un dossier au nom du composant
  • créer un fichier .ts avec le boilerplate qui va bien
  • créer un fichier .html qui est à référencer dans le .ts
  • créer un fichier .css qui est à référencer dans le .ts
  • créer un fichier .spec.ts avec le boilerplate qui va bien
  • déclarer notre composant dans un module pour le rendre accessible via ce module

Oubliez une étape et votre composant ne fonctionnera pas, ne compilera pas ou ne sera pas utilisable au choix. Vous vous ferez sans doute un peu insulter par le compilateur au passage.

Clairement si vous faite de l'Angular, utilisez le CLI vous éviterez beaucoup d'erreur…

Le ticket d'entrée est cher

Comparativement à beaucoup de framework, Angular est très complet. Voir trop complet pour certains. Dans tous les cas il faut connaître beaucoup de chose pour être efficace. Et ça prend du temps pour tout maîtriser. Rien que les concepts de bases, associés aux éléments les plus courants vous allez vite vous retrouver à bosser sur le sujet sur 3-4 jours avant de pouvoir vous lancer si vous êtes seul.

Je suis quand même un peu mauvaise langue du fait du tutoriel étape par étape de la documentation : le Tour of Heroes. C'est une application assez connue maintenant qui permet de faire un tour complet de tout ce qu'il faut comprendre et connaître à minima pour faire des applications en Angular. C'est très bien fait, mais c'est un long tutoriel, et beaucoup de chose ne se devine pas.

Un framework qui évolue peu…

…en surface. L'expérience développeur est importante. On le voit beaucoup au niveau des choix d'évolutions sur React ou Vue (entre autres). Pas que Angular n'évolue plus. C'est plutôt qu'on est surtout sur des évolutions sous le capot diront nous. Le moteur bouge pas mal, on a vu plusieurs refontes du moteur de rendu, plusieurs grosses versions du compilateur, etc. Mais on a souvent peu de changement au niveau de la syntaxe qu'on utilise au quotidien : tout fonctionne comme avant.

C'est d'ailleurs un peu ce qui est recherché : le framework est très stable à l'usage, les évolutions sont offertes via des changements interne au framework et on a pas besoin de recoder certaines choses pour en profiter si on suit les guides. C'est une approche très déclarative.

Arguments pour React

Même si je préfère Angular, ce n'est pas pour autant que je n'apprécie pas faire du React sur pas mal d'aspect.

La documentation est très claire

Si j'aime la complétude de la documentation Angular, je dois avouer que la documentation React a l'avantage certain d'être très simple et très clair. On peut l'expliquer facilement par le fait que React propose beaucoup moins de fonctionnalité qu'Angular en premier lieu. Mais aussi par le fait qu'un effort certain est mis en avant pour décrire chaque petit élément avec des guides, des exemples, etc.

La communication et le partage d'information

Il y a beaucoup de communication autour de React. Si on cherche un article sur un élément en particulier on en trouvera forcément un.

Mais on ne trouve pas que des articles qui ne parle que de React lui-même, on trouve aussi beaucoup de contenu autour de l'usage de React dans divers contextes ou pour montrer certains patterns ou point théorique de programmation. Rien qu'en lisant des articles autour de React on peut en apprendre beaucoup sur la programmation – en particulier fonctionnelle – et sur ce point la communauté React est très forte.

Composants fonctions

C'est je pense mon point fétiche : une simple fonction utilisé comme composant. Je suis convaincu que moins créé un composant est compliqué moins on hésitera a en créer en tant que développeur, et en faire à travers seulement une fonction c'est juste parfait.

La syntaxe est extrêmement légère. On a directement un composant pur du coup on profite directement d'une partie des optimisations de React sans coût.

Programmation fonctionnelle et Hooks

C'est très lié à l'utilisation de fonction pour faire des composants mais très vite on en arrive à utiliser beaucoup les patterns de programmation fonctionnelle. En particulier avec des High-Order Components ou HOC (qui ne sont que des High-Order Fonctions).

On pourra aussi retrouver beaucoup de mécanique qui étaient propres aux composants classes via les hooks. Que ce soit la gestion d'un état, la gestion des références vers des éléments, la mémoïsation, etc.

La création d'un hook personnalisé est extrêmement simple, il répond juste à des conventions – comme le fait de faire commencer le nom d'un hook par "use" – et ces conventions doivent être respectés si on veut que tout fonctionne bien (par exemple la majorité des outils reposent sur le nommage des hooks pour déterminer qu'une fonction est un hook).

Léger et adaptatif

En dernier point positif je parlerai de la légèreté ressentie à l'utilisation de React. Par légèreté je prend en compte deux aspects. D'une part le fait qu'on a l'impression de presque toujours faire des choses simples avec React, c'est très agréable. D'autre part le fait qu'on a peu de contrainte, deux applications React peuvent ne pas du tout être structurées de la même façon et pourtant c'est bien du React.

Arguments contre React

Pas un framework

"A JavaScript library for building user interfaces" est indiqué sur le site officiel. Mais React est-il une librairie ou un framework qui ne s'assume pas ? Pour moi on est dans le second cas. A mon sens il y a deux grandes familles de librairies : soit c'est une librairie qui vient compléter un framework (exemple : ngx-bootstrap, NgRx, react-redux), soit c'est une librairie qui vit indépendamment et qui n'impose pas d'architecture d'application (exemple : Redux, ImmerJS, RxJS). React ne rentre dans aucune de ces deux cases.

On est face à un framework qui nous propose de créer des applications graphiques en usant du JSX avec différentes implémentations qui permettent d'utiliser un code commun entre plusieurs plateformes. Nous avons une certaine organisation du code qui est recommandée. Il y a pas mal de guide pour indiquer comment faire une bonne application. On retrouve d'ailleurs des patterns pour gérer beaucoup plus que l'aspect graphique : l'asynchronie, les états, etc.

Pour moi c'est un défaut parce qu'on se retrouve avec un écosystème un peu bancal qui découle au point suivant.

Pas suffisant out-of-box

Si je suis la documentation React et que je souhaite créer une application la solution mise en premier en avant est la possibilité d'ajouter React à une page html statique via CDN. En avançant un peu on trouve des recommandations d'outils pour créer des applications : Create-React-App (ou CRA), Next.Js, Gatsby, etc.

Si on fait le choix de l'outil le plus proche de React – CRA – on se retrouve avec une application minimale qui démarre mais qui ne permet pas en l'état de créer une application : nous avons React pour créer des composants, Jest pour faire des tests unitaires, webpack sous le capot pour lancer des tests unitaires, en option TypeScript si on l'a choisi à la création du projet et c'est à peu près tout. C'est très minimal, mais il va manquer des choses pour faire une vraie application, typiquement : une librairie pour faire des appels HTTP (car sauf application vraiment petite on voudra utiliser plus que fetch pour faire nos requêtes), en général on utilisera aussi un store (Redux par exemple) pour pouvoir gérer simplement un état global, un routeur (pour gérer plusieurs pages).

Là où si je prends Angular, j'ai tout pour faire mon application et la tester (y compris des tests bout en bout avec Protractor) par exemple.

Pas d'écosystème officiel

Gros inconvénient de React c'est qu'on a pas ou peu d'écosystème officiel au sens où quand on démarre en React on va se retrouver à installer des librairies dont le nom est react-quelque-chose, qu'on pense être officiel mais qui sont en fait développer par des équipes indépendantes pour compléter React.

En soi que des gens extérieurs développent ces librairies est très bien. Mais React commence tout juste à avoir une petite liste de librairie recommandé. Ça implique des cycles de vie différent de React, potentiellement des casses dû à des incompatibilités qui apparaissent d'un coup, le besoin de suivre les sorties de chaque librairie indépendamment…

Dans un vrai framework, on pourrait directement suivre la sortie du framework comme un seul bloc.

Create-React-App ne tient pas la route en 2020

Pour ceux qui ne connaîtraient pas Create-React-App (ou CRA) c'est un outil en ligne de commande permettant de générer un projet React avec un ensemble de script et pré-configuration pour accélérer le démarrage d'un projet React. Grosso-modo la même base que Angular CLI. Dans l'idée je trouve CRA très bien, pour les mêmes raisons que je trouve très bien Angular CLI. Dans la pratique ce n'est pas la même chose…

Sur l'année qui vient de s'écouler j'ai créé deux projets React à partir d'un dossier vide. Le premier à la main (en configurant donc Webpack principalement) et le second via CRA. Ce que je peux vous dire c'est que ça va beaucoup plus vite avec CRA au début mais que sur la durée avoir la main sur Webpack est bien plus pratique… La différence fondamentale entre CRA et Angular CLI c'est la possibilité de configurer des choses. Grosso-modo les choix de CRA sont figés totalement et bourrés de défauts : impossible de changer de framework de test (j'ai des soucis avec Jest, mais je pourrais en reparler dans un article dédié), le démarrage est lent, il y a des grosses fuites mémoires (Windows 10 finit par tuer CRA sur ma machine tellement il consomme de ressource), il y a des bugs au niveau de la détection des fichiers qui ont changé sur le disque (problème que je n'ai jamais vu sur le projet React sans CRA et sur un projet Angular, tous les sur la même machine), aucun outillage pour installer des librairies communes (de la même façon qu'on a ng add @ngrx/store, j'aimerai quelque chose du genre create-react-app add redux).

J'ai pendant un temps pensé que le projet était sans doute très récent comparé à Angular CLI, ce qui pourrait expliquer cette différence. Mais si on regarde le démarrage des projets on est sur environ un an d'écart (premier commit sur Angular CLI en mars 2015, premier commit sur Create-React-App en juillet 2016). Dans le monde React la génération de code typiquement d'a pas lieu d'être (quand on compare à Angular), mais ça aurait dû être une force pour faire bien d'autres choses avec cet outil ! De même façon que Vue qui est beaucoup plus récent a un CLI qui est extrêmement puissant et permet beaucoup plus de chose que Angular CLI sur l'aspect suivi du projet et des dépendances en particulier.

Le Virtual DOM

Je sais que tout le monde ne sera pas d'accord avec moi sur ce point mais pour moi ce n'est pas une bonne chose. Selon moi, mon travail consiste à créer des applications qui sont fiables, performantes mais qui ne consomme pas des resources de manière absurde. Le Virtual DOM c'est une surconsommation de ressource que je trouve inutile.

Déjà à mon sens le Virtual DOM ne fait qu'ajouter de la complexité : nos composants vont aller modifier un faux DOM et une routine va comparer ce faux DOM et le vrai DOM pour aller reporter les modifications. On a donc un intermédiaire qui pourrait être évité. Ce Virtual DOM est stocké en mémoire. C'est un peu comme si toutes nos pages étaient dédoublées pour aucune vraie raison. On pourrait me rétorquer que React est performant, que les re-rendu sont rapides, que c'est une abstraction à la complexité du DOM, etc. Je pourrai dire de mon côté que la plupart des autres frameworks n'utilisent pas de Virtual DOM pour justement les problèmes de performance, et que certains proposent une abstraction bien du forte du DOM comme Svelte qui est dans les tendances ces derniers mois.

TypeScript c'est la galère

Même si on est pas obligé de faire du TypeScript quand on fait du React, il faut avouer que ça tend à être la norme que nos projets frontend soient en TypeScript (que ce soit une bonne chose ou non n'est pas le débat ici). Je trouve l'expérience catastrophique…

Dans mon équipe on est quatre à travailler avec Visual Studio Code et deux qui travaillent avec JetBrains WebStorm. On a configuré ce qu'il faut pour que TypeScript soit correctement prit en charge. On utilise les fichiers de typage officiel. On a testé deux stratégies : on type ce qu'on pense avoir besoin de typer (basiquement les modèles d'échanges avec les backends, les fonctions clés, les actions Redux) et la stratégie "on type absolument tout". Les deux fonctionne mal…

La première stratégie a conduit a des grosses erreurs de typage à cause de any qui se promenait un peu partout et cassait notre typage : TypeScript était inutile car ne donnait aucune contrainte sur les types. Et en parallèle on se retrouvait à quand même perdre un temps fou à typer beaucoup de chose… La seconde stratégie nous permet d'être très strict au niveau de TypeScript qui nous engueule très facilement, mais nous oblige à un minimum de logique de type. Dans le même temps on a des types complexe car React ne se prête pas très bien au typage via TypeScript, et les typings officiels n'aident pas.

J'évoquerai aussi les typages de React-Redux qui sont juste hyper contraignant pour des raisons absurdes. Basiquement : on doit avoir un type AppAction qui est un union type du type de toutes nos actions, ce qui n'a aucun sens. Dans le même temps dans le monde Angular, NgRx et NgXS (des stores équivalents à Redux) proprosent des actions typés fortement mais évite cette énumération géante qui empêche certaines possibilités de factorisation via des actions génériques…

Arguments pour Angular

Un framework stable dans le temps

Si vous revenez au tout début de l'article je l'ai mis dans ses défauts mais c'est aussi sa force : il est très stable. Le code que j'écris aujourd'hui sera à priori toujours fonctionnel dans quelques années et résistera bien au monté de version du framework. En particulier grâce au CLI qui permet une assistance forte au moment des montées de versions en encaissant la plupart des changements à effectuer.

Performances accrues sans effort

Pour faire des vrais gros gains de performance il faudra toujours faire quelques efforts. Mais j'ai pu noter sur la plupart de mes projets Angular que les performances étaient croissantes au fil des mises à jour du framework sans que je ne fasse rien. En particulier grâce à des refontes régulières du moteur sans casse d'API (à part de temps à autre quelques API à la marge qui seront clairement documentées). Depuis Angular 2 on aura vu trois moteurs de rendus différents se succéder sans quasiment de changement à faire sur notre code, en particulier Ivy arrivé récemment qui ne demande aucun changement.

Une compilation efficace

On dit souvent qu'un projet Angular est lourd dû au volume de dépendance à télécharger. Mais en vérité il s'agit pour beaucoup de dépendance qui sont utilisées à la compilation. Le bundle Angular est très optimisé, avec peu de raison de vouloir trop modifier d'option car tout a été pensé au fil du temps par beaucoup de gens de la communauté. Basiquement l'arrivée des compilations AOT (Ahead Of Time, compilation optimisé avant de livrer, contrairement à la compilation JIT ou Just-In-Time qui se fait au moment de l'exécution) de sorte à accélérer le temps de traitement et réduit la taille du binaire Angular qu'il faudra embarquer dans l'application.

L'écosystème est important et très développé

Même si c'est le cas pour d'autres frameworks, Angular a une très large communauté. Communauté qui est très ouverte aux changements. Communauté qui produit aussi des bibliothèques de qualités. On trouve toujours une réponse à nos problèmes. La plupart du temps la documentation Angular suffit une fois qu'on a maitrisé le vocabulaire de base.

Les schématics

Une super idée permettant d'étendre les commandes disponibles via le CLI Angular. On peut ajouter des commandes, mais on peut aussi personnaliser un peu certaines commandes en se greffant sur le pipeline de compilation et définir des actions à effectuer à l'installation via ng add. Le tout étant très bien fait on a pas besoin d'éjecter le CLI mais juste à l'étendre. De plus en plus de bibliothèque en profite pour simplifier la vie des développeurs comme NgRx qui propose des commandes pour générer des fichiers pour gérer le store, ajouter des réducers, etc.

Le système de schématics étant très générique, il est réutilisé pour d'autres projets tel quel NestJS qui les utilisent pour sont CLI.

Typage naturel

Un projet Angular peut être réalisé en JavaScript ou Dart mais la majorité du temps on prendra le choix par défaut, c'est-à-dire TypeScript. Le typage est complet, simple et naturel. On sent que le framework a été pensé pour fonctionner avec TypeScript.

Le plus gros défaut du typage Angular est que le mode strict du compilateur n'est pas activé par défaut.

Documentation bien faite

La plupart du temps quand on a un souci avec Angular, c'est qu'on ne sait pas comment faire tel ou tel chose. Dans ces cas-là on peut toujours trouver un guide ou un paragraphe de documentation – sur le site officiel – pour nous donner la solution. C'est très rare que je ne trouve pas ce que je cherche sur la documentation.

Un framework vraiment complet

La documentation est complète, le ticket d'entrée est cher, mais on a avec Angular un framework clé en main disons. On a tout de base. Tout ne sera pas embarqué dans notre application si on ne l'utilise pas, mais on peut facilement utiliser Angular pour résoudre tous nos problèmes. Toutes les problématiques courantes ont été adressées et on a juste à suivre les guides pour savoir comment utiliser ces solutions. Quand je dis tout, c'est tout : routage, internationalisation, formulaire, état partagé, client http, test unitaire, test d'intégration, test bout en bout, etc.

Sur d'autres frameworks comme React, il faudra parcourir Internet pour choisir parmi beaucoup de proposition de la communauté pour choisir une solution qui sera peut-être abandonnée un moment ou un autre.

Le ticket d'entrée est cher mais rentable

Il faut du temps pour vraiment comprendre Angular et maitriser le framework. Par contre une fois ce ticket pris on peut vraiment se débrouiller face au framework. Pas toujours de la façon la plus simple (au sens où on peut potentiellement trouver des raccourcis à certaines choses) mais pas de façon compliquée non plus. Il faut juste se caler sur la logique et tout devient assez naturel.

Le CLI : votre meilleur ami pour les mises à jour

Je l'ai déjà dit mais le CLI vous aidera en effectuant carrément les changements à votre place pour la grande majorité des cas. Je trouve souvent les mises à jour presque trop faciles en fait.

Un autre élément que j'apprécie (mais qu'on devrait avoir sur npm de base…) c'est la possibilité d'avoir une vérification des compatibilités transitive. Quand on fait ng upgrade, une routine va bien chercher à mettre à jour toutes les dépendances mais en respectant les dépendances transitives de dépendances aussi. Typiquement, si je fais ng upgrade qui me donne une version @angular/core à x.2.3 qui dépend de TypeScript 3.5.x, TypeScript sera mis à jour pour la dernière 3.5.x même si la version 3.6.0 est sortie. Avec npm ce ne sera pas le cas, toutes les versions seront montées au maximum possible. Cette mécanique contribue à rendre les montés de version le moins cassant possible, même si on pourra toujours mettre à jours certaines dépendances manuellement ensuite pour diverses raisons.

Incremental DOM

Angular ne repose pas sur un Virtual DOM, en Angular le moteur ira éditer directement le DOM. Depuis les versions récentes d'Angular on utilise Ivy comme moteur de rendu (Angular 7 en pré-version, 8 à activer et 9 par défaut). Ce moteur fonctionne sur le principe de l'Incremental DOM.

Le concept est très simple : un changement dans un composant va devenir une instruction de rendu qui sera transmise à un moteur qui lui ira modifier le minimum de chose possible dans le DOM pour répercuter le changement. C'est très logique comme mécanique, ça demande d'embarquer un moteur plus petit pour fonctionner que d'autres systèmes et c'est surtout très performant avec une abstraction du DOM qui se gère à la compilation.

Cet article détail plus que moi le fonctionnement de l'Incremental DOM : https://blog.nrwl.io/understanding-angular-ivy-incremental-dom-and-virtual-dom-243be844bf36

RxJS intégré de base et très naturellement

Même si ça pourrait être un défaut, car on doit du coup apprendre à utiliser RxJS en même temps qu'Angular : Angular est construit en partie sur RxJS. Personnellement je suis un grand fan de cette bibliothèque qui permet d'exprimer beaucoup de concept fonctionnel et de gérer de la réactivité très simplement.

Comme ça fait partie intégrante d'Angular, c'est très naturel de l'utiliser avec le framework. Je pense par exemple au client http fourni par Angular qui renvoie des Observable et le pipe Async qui permet d'utiliser des Observable quasiment comme des objets classiques et d'optimiser la réactivité du rendu de manière très simple.

Très proche du HTML, CSS et JS natif et vanilla

Quand on développe avec Angular, on est assez proche du navigateur, on a peu d'abstraction comparé à d'autres frameworks comme React (le JSX avec une balise div n'est pas vraiment une balise div, c'est une abstraction, pas en Angular). On a un découpage très net entre le template html, le style en css (ou avec un pré-processeur avec des scss par exemple) et le code métier associé dans des fichiers TypeScript. Angular va surtout gérer pour nous l'activation de hook sur le cycle de vie et la gestion de l'injection de dépendance. Le reste du temps on va être très standard si on code correctement.

Très proche des WebComponents

Du fait de sa syntaxe à base de classe, du découpage très net html/css/ts on se retrouve avec quelque chose de très proche des WebComponents. Aussi bien en termes de logique que de syntaxe. Angular repose d'ailleurs intégralement sur des Custom Elements qui sont une des parties de la spécification des WebComponents. On trouvera aussi le projet Angular Element qui vise à créer des WebComponent à partir de composant Angular.

Sans affirmer que c'est la direction choisie, mais on peut facilement penser qu'à l'avenir Angular compilera les composants en WebComponents de sorte à s'appuyer encore plus sur le navigateur et limiter le code superflu à embarquer.

Formulaires faciles

On sera d'accord ou non avec moi, mais dans le monde professionnel on a très souvent des formulaires à créer dans nos pages. Angular propose énormément d'éléments qui permettent de gérer ceux-ci très simplement, que nos formulaires soient statiques ou dynamiques, avec une gestion très simple de la validation des données.

Conclusion

Malgré ma volonté de mettre en avant les points négatifs et positif de Angular et React, comme annoncé dès le début j'ai une préférence pour Angular. Et même si j'aime beaucoup pas mal de chose côté React, je pense qu'il reste un gros travail à faire.

Dans le même temps ça ne veut pas dire que je pousserai à l'utilisation de Angular pour tous les cas clients. La raison principale étant que même si Angular peut répondre à tous les problèmes (comme React le peut aussi qu'on soit bien d'accord) il n'est pas forcément toujours le meilleur choix. Si je caricature un peu, mais je dirais que si j'ai une application basée sur des formulaires, je favoriserai toujours Angular ; mais pour une application assez simple avec majoritairement de l'affichage je pourrais pencher pour React pour la facilité à créer des très petits composants réutilisables.

Crédit photo : https://pixabay.com/illustrations/fire-and-water-fight-hands-fire-2354583/