React vs Angular

Ces dernières années, une kyrielle de plateformes Javascript dynamiques et volontaires est venue balayer le paradigme de l’ancien temps qui consistait à générer les pages web côté serveur. En lead de cette révolution, les deux acteurs majeurs du marché : ReactReact est un framework de développement JavaScript populaire., la bibliothèque de Facebook, et Angular, le framework de Google.

Le marché : un combat au coude-à-coude

Les deux géants américains trustent la tête du marché, suivis de près par Vue, le petit dernier de la compétition, et loin devant tous les autres. Si AngularAngular est un framework de développement JavaScript populaire basé sur TypeScript. jouit d’une meilleure image auprès des architectes et des décideurs, React est en revanche très populaire auprès des développeurs. Pourquoi ? Levons le capot, et nous verrons que cela n’a rien d’étonnant…

Les technos : même plateforme, même langage… ou presque

React et Angular sont tous les deux servis par le gestionnaire de paquet tout-puissant NPM, et bien sûr les deux technologies produisent in fine du Javascript. Pourtant, là où React se base sur la norme ECMAScript 6, Angular a adopté depuis longtemps la surcouche de Microsoft TypeScript. Résultat : des syntaxes, des contraintes et des possibilités différentes.

React et ECMAScript 6

ECMAScript est le standard normalisé qu’implémente JavaScriptLangage de scripting orienté objet (à l’instar d’ActionScript). C’est un langage de programmation à typage faible, orienté prototype donc faiblement objet, et événementiel donc massivement asynchrone. En découlent les inconvénients suivants :

• risque d’erreurs de transtypage fort
• code faiblement structuré, plus difficile à maintenir
• énormément d’actions réalisées en callback : complexité d’enchaînement des opérations, lisibilité faible

Angular et Typescript

En tant que surcouche de JavaScript, TypeScript apporte une structuration supplémentaire sur le typage (fort, obligatoire et surtout contrôlé au transpilage [opération permettant de passer du code TypeScriptLangage de programmation basé sur JavaScript. au code JavaScript]), et sur l’approche objet (tout est classe ou interface, à la mode JavaLangage de développement très populaire !, donc une structure plus forte). Chacun est libre d’y voir des contraintes ou des outils…

L’architecture : l’ultrastructure contre pas-de-structure…

Au fur et à mesure de son évolution, Angular a mis en place un panel de composants logiciels de plus en plus large et de plus en plus obligatoire. Ainsi, la boîte à outil de la plateforme Google propose impose dans sa dernière version modules, components, services, guards, directives, pipes, et bien sûr class, interfaces et enums. Un set complet, soutenu par Angular CLI, la command line chef d’orchestre d’Angular. A cela s’ajoutent différents design patterns (comme les stores) et de nombreuses fonctionnalités natives (routage, authentification, appels de web services, etc).

En face, React propose une syntaxe pour créer des composants… et c’est tout. OK, je force un peu le trait. Mais l’impression de vide lorsqu’on passe d’Angular à React est vertigineuse, et ce même lorsque (comme moi) on a derrière soi un long passé de développement JavaScript en roues libres et structuré malgré tout. Clairement, les deux partis pris s’opposent : d’un côté la volonté d’imposer une façon de faire unique, de l’autre un starter kit minimaliste et la liberté quasi absolue. Là encore, chacun y verra ce qu’il veut y voir.

Le templating : MVC vs monocouche

Et le templating dans tout ça ? Oui car, ne l’oublions pas, le but de ces technologies est avant tout de gérer des pages web. Et une fois de plus, les solutions retenues s’opposent.

React propose une syntaxe propre nommée JSX (pour JavaScript Extension). Elle permet une description déclarative du code HTMLHTML (HyperText Markup Language) est un langage permettant de décrire le découpage d'une page web. au sein même du code JavaScript en évitant l’écueil du string en echo (coucou le PHPLangage de programmation s’exécutant côté serveur et permettant la création dynamique de pages web ou d'APIs.…). C’est sobre, pratique et efficace. On est assez proche des JSP de Java (coucou l’antiquité…), en mieux. C’est donc une vraie réussite, si on exclut le fait que, par conséquent, la vue est dans le contrôleur (coucou l’antiquité bis…). On reboucle avec le paragraphe précédent : pas de structure.

Angular sépare bien sûr la couche vue de la couche contrôle, et propose toute une syntaxe de tags, composants et « outils » HTML pour décrire les opérations lambda de binding de données et d’événements, ainsi que les boucles, conditions, contrôles et formattages divers. Comme toujours chez Angular, c’est complet et c’est complexe (en première impression), mais c’est efficace.

Un détail tout de même, qui fera peut-être pencher la balance en faveur de React : la qualité du HTML et du CSSFeuilles de style qui permettent de mettre en forme des pages web. produits. Angular pollue outrageusement ses templates de tags et d’attributs propres à son fonctionnement interne, là où React laisse un code propre (à la charge du développeur) et dépouillé de tout gri-gri superflu. Pour les puristes du HTML 5, de la sémantique, de l’accessibilité voire du SEO, c’est un avantage non négligeable.

L’apprentissage : du pédiluve au grand bain, gare à la noyade

Face à ces environnements aux antipodes, quid des développeurs ? Nous le disions, ils préfèrent en majorité React. Pas étonnant, la complexité d’un Angular rebute là où la légèreté d’un React séduit. Quant à la qualité du code produit, on sait que la lisibilité et la maintenabilité ne sont pas la priorité des équipes techniques (no offense, vous savez bien que c’est un peu vrai…).

Pourtant, passé la rebutante phase d’apprentissage, Angular se révèle être un framework très efficace, qui permet un développement rapide avec peu de limitations techniques. A condition de faire l’effort d’assimiler son architecture, donc un exercice théorique, sujet de phobie chez bon nombre de développeurs. Sans cela, à moins d’un management béton, c’est la noyade assurée.

Mais alors, React aurait-il des brassards intégrés ? Que nenni ! Quiconque a déjà développé une application en JavaScript natif connait la difficulté de ne pas sombrer dans l’écueil critique d’une app mono-fichier incompréhensible pour qui ne l’a pas écrite… et parfois pour l’auteur lui-même.

Causes différentes, mais noyade quand même. Là-dessus, pas de miracle : il faut se former, manger du code et prendre de la hauteur de vue.

La plateforme : NPM ou l’enfer des modules

Si la version native d’Angular est plus étoffée que celle de React, chaque technologie stimule une communauté vivace et enthousiaste qui publie à foison des plugins par myriades, disponibles sur le gestionnaire de paquets ubiquit NPM. Et là, c’est le drame…

Certes, on n’a jamais vu un gestionnaire de paquets efficace (RPZ apt, seule exception… et encore). Mais tout de même ! Sans parler de la gestion des dépendances, que l’on peut sobrement qualifier de mauvaise (on n’est pas si méchant que ça), la gestion de versions est catastrophique. Migrer d’une version d’Angular à une autre est un cauchemar, installer un hot deploy sur React (oui, car ce n’est pas natif… coucou le vide sidéral) est une épreuve. Internet regorge de tutoriaux plus faux les uns que les autres, de tips et de soluces qui au mieux n’apportent rien, au pire créent une régression… OK, j’exagère à nouveau. Mais pas tant que ça. Seule consolation : dans notre match, sur ce sujet, c’est un partout, balle au centre.

Les performances : et ça va vite cet engin ?

Plutôt, oui. Les fanatiques du paradigme ancien dans lequel le serveur fait tout et le client ne fait rien ont tendance à s’effrayer de voir déporter tant de calculs sur un frêle navigateur. A fortiori lorsqu’ils pensent à Mamie et son Windows XP en 2018… Mais Mamie devrait investir (c’est Microsoft qui le dit), et n’importe quelle machine de moins de 10 ans peut supporter la charge d’un rendu de page React ou Angular.

Alors bien sûr, il est toujours possible de faire lagger une application. Coder mal n’est pas une gageure, c’est même assez facile. Les boucles infinies sont fatales à votre onglet, les fautes algorithmiques grossières ne sont pas discrètes… (ce qui leur permet de ne pas dépasser la phase de développement). Mais pour peu que vous compreniez ce que vous faites, les performances ne sont pas un problème. Quant au React vs Angular, selon notre expérience, sur ce point, c’est un nouveau match nul.

La maintenance : et ça fait longtemps que vous faites ça ?

Dernier point : maintenance et évolutions.

A court terme d’abord : a priori vous avez les mêmes équipes qu’en développement initial, donc pas de problème. Même mal codée, une application n’est jamais complètement hermétique à son auteur. Une fois de plus, pourtant, Angular prend l’avantage grâce à sa structure, qui permet une lisibilité bien supérieure, et facilite par conséquent l’entrée de nouvelles ressources sur le projet. Dans le cas de React, cela dépendra de la structure que vous aurez mise en place, ce qui valorise énormément la phase de conception en amont du projet.

A long terme ensuite : les deux technologies ont désormais quelques années et quelques versions dans les pattes. Elles sont fiables et éprouvées. Les plugins que vous utilisez vont-ils être maintenus ? Voyez qui les édite, quitte à opter pour des solutions payantes, mais il est clair que le geek du coin offre des perspectives de stabilité bien inférieures à celles d’un éditeur établi. Les deux plateformes seront-elles encore là dans 10 ans ? Impossible à dire… qui aurait parié dessus il y a 10 ans ?

Conclusion : React VS Angular, and the winner is…

… Angular ! Sans surprise, le framework de Google remporte les suffrages. Certes il est mal aimé des développeurs, certes il est compliqué, certes NPM nous fait des misères… Mais Angular est professionnel là où React est dilettante.

La technologie de Facebook apporte des éléments intéressants, et son approche ouverte plaira à tous les codeurs épris de liberté. Il n’empêche que la liberté implique de faire des choix, et qu’en les laissant intégralement à la responsabilité du développeur, React propose moins un framework qu’une bibliothèque JavaScript.

En somme, React vs Angular, c’est un peu Joe la Bidouille vs les Psychorigides : d’un côté je-fais-ce-que-je-veux, de l’autre tu-fais-ce-que-je-veux. Chacun décidera en son âme et conscience…