Patrice Ferlet
Patrice Ferlet
Créateur de ce blog.
Publié le nov. 11, 2017 Temps de lecture: 6 min

Me suivre sur Mastodon

Angular, ReactJS, VueJS, comparer l'incomparable

thumbnail for this post

Angular, VueJS et React sont souvent comparés entre eux - et la mode est de comparer les bananes et les carottes on dirait…

Permière erreur, la plupart des articles que je lis sur les comparatifs React, Vue, Angular ne parlent pas d’Angular, mais de AngularJS. Seconde erreur très répandue: vouloir à tout prix comparer des technologies qui n’ont rien à voir - on va donc décrire le problème ici. Mais avant tout, pourquoi on parle d’eux ?

L’application monopage

JQuery fut à la mode et force est de constater que son reigne s’éffondre mois après mois. Aujourd’hui, on parle de SPA (Single Page Application) ou “application monopage” dans la langue de Jean-Pierre Pernaut. Et pour réussir à faire une application complète, active, réactive, structurée, il faut une technologie adaptée.

Jusque là, on ne jurait que par AngularJS, développé par Google, ou Knockout qui ont apporté le “two way data binding” de manière magistrale. Sauf que voilà, quand un truc mache bien, tout le monde s’empresse de vouloir proposer sa vision, sa version, sa technique. Il y en a d’autres, plus ou moins bien fichus, mais je ne suis pas là pour les comparer.

ReactJS est venu remuer le sac pour proposer une autre façon de faire. Développée et utilisée par FaceBook, cette librairie est devenue vraiment populaire et on comprend pourquoi !

Nous voilà donc avec deux grands noms (Google et Facebook) qui apportent tous les deux des technologies qui vont faire grand bruit.

Au milieu de tout ça vient le David contre les Goliath, j’ai nommé VueJS. Développé par un ancien de chez Google (de l’équipe AngularJS), le dénommé Evan You, cette librairie apporte un vent frais dans la fournaise.

Les technologies du net changent. Aujourd’hui les projets se portent de plus en plus vers une séparation “API/client léger” - les sites qui génèrent des pages de manière plus ancêstrale sont en train de devenir “old school”. Cela permet de vraiment séparer deux partie: la vue frontale et l’acquisition de la donnée. Nous ne sommes plus obligé de gérer la vue du coté où sont traitées les données, et ça en tout honnêteté c’est un vrai grand pas en avant.

Mais depuis quelques mois, AngularJS a changé… en fait il n’est plus, enfin si… mais non… bon je m’explique.

AngularJS n’est pas Angular !

Bien que ce soit la même équipe, le même éditeur (Google) et quasi le même site, les deux technologies sont différentes - et à tel point que beaucoup pense que le nom aurait du changer.

Angular n’est pas un framework JS, ni une librairie.

C’est un framework TypeScript, bien que vous puissiez développer en JS si ça vous chante, qui déporte littéralement tout le développement en dehors de la page. Car Angular “génère” votre application (en JS).

Petite note: VueJS permet de développer en TypeScript, c’est pas répandu mais ça se fait.

On est donc bel et bien en dehors de ce que propose ReactJS et VueJS qui, elles, sont des librairies qui s’intègrent dans une page. L’approche est différente, la techno est différente, alors pourquoi s’obstiner à les comparer ?

Je comprend bien que vous puissiez faire le comparatif puisque, au final, on se retrouve à travailler dans la même optique. Mais le choix ne doit pas se faire sur la technologie, elle doit se faire sur l’orientation du développeur ou intégrateur qui va travailler.

Certainement que dans l’esprit collectif, c’est AngularJS qui a laissé une empreinte trop persistente.

Imaginons que nous développions un Framework qui transforme tout mon PHP en une application JS/HTML. Vous comprennez bien que l’approche est différente de ReactJS et VueJS ? Vous ne feriez pas la comparaison parce que d’un coté on développe une application dans un langage dont le rendu se fera dans un navigateur, et de l’autre vous développeriez avec des librairies JS une application qui est “intégrée” dans une page.

Il n’y a rien de péjoratif dans le fait d’être une librairie JS, et il n’y a rien de gratifiant d’être un Framework TypeScript, ce sont juste deux approches très différentes, et pas comparables.

Et bien là c’est pareil ! Angular vous propose de développer des classes, des components, des services… vous propose de l’injection de dépendance, des méthodes d’appel HTTP vers les API, etc… et cela “compile” un site monopage qui saura utiliser un backend.

Bref, la cible de développeur n’est pas la même, l’approche est différente.

Donc on choisi comment ?

Il faut s’abstraire de la technique en premier lieu.

Posez-vous les questions suivantes:

  • est-ce que c’est une application poussée qui demande du développement “applicatif” ?
  • est-ce que ce sont des intégrateurs ou des développeur applicatifs qui vont bosser dessus ?
  • est-ce que c’est l’interface qui prime ou le fonctionnement applicatif ?

Avec ces questions, vous allez ensuite chercher les compétences utilisée pour intégrer la page. Les “dev” préfèrent généralement Angular, puis VueJS, les intégrateurs vont plutôt préférer ReactJS, puis VueJS.

Vous l’aurez compris: VueJS rassemble beaucoup, son approche mixe les deux concepts. Cela-dit, moi en tant que dev, j’ai une préférence pous le TypeScript (notamment pour son intégration dans un IDE qui est très avancée, sur Vim c’est vraiment bien fichu) - mais je ne choisi pas Angular parce qu’il est mieux que React ou Vue.

Je choisi Angular parce que l’orientation MVC est, de mon point de vue, plus adaptée à mes travaux.

Je ne suis pas intéressé pour générer du HTML depuis JS/JSX, loin de moi l’idée de critiquer cette approche, elle ne convient juste pas dans mes développements. Mais vous, certainement que oui, et je le comprendrai sans souci. Au boulot, un de mes collègue a justement préféré React puisque sont besoin étaiat de travailer sur l’interface en tapant sur quelques enpoints d’API REST.

Moi de mon coté, je développe une application qui demande 40 endpoints, du contrôle poussé dans le fonctionnement, et j’avais vraiment besoin d’injection de dépendance pour éviter le boxon inmaintenable vue la dose de code à engendrer. L’interfaçage est purement HTML (template) et je peux donner cette partie à une autre équipe, donc Angular est plus adapté à ce projet.

C’est l’approche qui est comparée, pas le fonctionnement… vous me suivez ?

Comparer autrement

Ce qui m’agace finalement, ce n’est pas de vouloir comparer les technologies, c’est le fait de l’orienter sur la “technique” alors que la comparaison devrait se faire sur l’oritentation de développement.

Si vous êtes un développeur orienté structure/class/objet (Java, Go, Python, PHP…) vous allez certainement préferer apprendre le TypeScript (qui est franchement pas sorcier) et créer l’application dans une optique de “framework”.

Si vous êtes plutôt intégrateur, que vous chercher à définir une interface plus “animée”, alors VueJS et ReactJS sont certainement plus adaptés à vos besoins.

C’est don inadapté de comparer les bananes et les carottes, demandez vous plutôt si vous en êtes au plat principal ou au dessert. Là, vous pourrez choisir entre des librairies JS ou des framework applicatif. Donc entre VueJS, React et Angular.

Et surtout, gardez bien à l’esprit que Angular != AngularJS pour ne pas comparer l’incomparable.

comments powered by Disqus