Un regard objectif sur la guerre des bibliothèques : React vs Vue

D'où venons-nous ? Que sommes-nous ? Où allons-nous ?

Arrêtons-nous un instant et voyons où nous en sommes. En tant que baby-boomer, je doute sincèrement qu'il y a une dizaine d'années, quelqu'un aurait pu prédire que l'Europe serait en train de devenir une réalité. développement web irait aussi loin.

Les applications bureautiques utilitaires appartiennent au passé, car tout peut être fait dans un navigateur. En fait, les applications qui doivent utiliser des API de niveau inférieur qui ne sont pas disponibles dans le navigateur sont également écrites à l'aide de moteurs et de langages de navigateur parce qu'elles sont plus faciles à maintenir.

Les applications mobiles peuvent être facilement remplacées par des outils utilisés pour le développement web - voir React NatifNativeScript. En outre, nous avons les PWA, qui "imitent" facilement le fonctionnement des applications mobiles. En outre, les composants qui alimentent une application écrite en Vue ou React peut facilement partager divers code entre les plateformes.

Nous devons admettre une chose : les applications web sont actuellement une puissance qu'il sera difficile de faire redescendre au rez-de-chaussée. En tant qu'utilisateur, je me vois les utiliser pratiquement partout : communiquer via Slack, utiliser un éditeur de code, faire des présentations ou même écrire un article de blog.

Il est difficile de prédire ce qui se passera dans quelques années. WebAssembly entre en jeu et nous permettra de déplacer les applications qui nécessitent des calculs plus complexes dans le monde du navigateur. Un fait demeure cependant inchangé : il est vraiment difficile de trouver un obstacle à la construction, à l'aide des technologies web, d'une application dont nous ne pouvons que rêver.

Le big bang dans la réalité de l'internet

Revenons un instant en arrière, avant que n'apparaissent les premiers cadres web plus importants et que les applications ne soient développées de manière impérative. Chaque mécanisme interactif d'une page était géré manuellement et était responsable d'une action spécifique.

Le meilleur exemple que l'on puisse citer est la bibliothèque jQuery, qui était à l'époque l'une des solutions les plus populaires pour gérer des événements simples. Grâce à elle, divers menus déroulants, transitions, animations, calculatrices et autres mécanismes similaires ont été mis en œuvre.

Il convient de mentionner que des problèmes dans des applications plus complexes ont déjà été constatés à l'époque - là où différentes parties indépendantes devaient, par exemple, réagir à un clic approprié ou à la frappe d'un texte. La plupart des applications n'avaient pas d'état explicite et étaient sauvées, par exemple, par les attributs des éléments ou les classes qu'ils possédaient.

À l'époque, il était clair que l'approche actuelle manquait de réactivité - une manière structurée pour les composants de communiquer entre eux et de partager, par exemple, leur état ou différents événements, ce qui rendait les applications plus faciles à maintenir et leur permettait d'offrir une bonne expérience à l'utilisateur à un faible coût.

Premiers pas vers des cadres bien connus

Au fil du temps, les premiers cadres frontaux ont commencé à apparaître à l'horizon, visant à structurer l'architecture pour des applications plus complexes.

Ces frameworks étaient principalement basés sur le modèle MVC - certains proposaient une approche plus manuelle, comme Backbone.js, tandis que d'autres, comme Knockout.js, s'appuyaient sur une liaison de données bidirectionnelle.

Cependant, on peut estimer que la rédaction de l'application était plus difficile, qu'elle nécessitait beaucoup plus de codage et qu'elle ne produisait pas nécessairement les résultats escomptés ou ne compensait pas le temps perdu dans le développement de l'application.

La principale raison pour laquelle il était difficile de trouver la moyenne d'or dans l'écosystème JS était qu'il s'agissait d'une bizarrerie par rapport à d'autres systèmes bien connus. les langages de programmation qui ont depuis longtemps tracé leur chemin.

Et je ne veux pas m'attarder ici sur les chemins qui ont accompagné le développement des différents frameworks tout au long de l'histoire. Cependant, il est important de noter une chose : la maturation de l'écosystème JS dans les navigateurs n'a pas été facile et a dû faire face à de nombreuses épreuves.

C'est la seule raison pour laquelle nous pouvons aujourd'hui créer des applications web et les développer d'une manière très simple et sans douleur.

Informations de base et légère comparaison

Au lieu de jeter de la viande, comme il est d'usage sur l'internet, examinons les deux bibliothèques, rassemblons des informations à leur sujet et comparons-les, tant en théorie qu'en pratique.

NOTE : La description des mécanismes fonctionnant en Vue se réfère spécifiquement à la version 2. La version 3 introduit un grand nombre de changements significatifs, mais n'est pas un véritable concurrent de la React pour le moment, ne serait-ce qu'en raison de sa maturité - Vue 3 date de sortie : 18 septembre 2020.

Soyons clairs : en creusant plus profondément dans les deux bibliothèques, vous pouvez voir qu'il y a en fait plus de similitudes que de différences. En laissant de côté la manière d'utiliser les bibliothèques en tant que telles, elles ont toutes deux des concepts de fonctionnement très similaires. Elles sont toutes deux alimentées par un écosystème similaire et leur utilisation n'est pas diamétralement différente.

● Le diable se cache dans les détails - plus nous utilisons un outil, plus nous remarquons les inconvénients de ses différentes solutions. Un bon exemple est celui de la liaison bidirectionnelle des données, qui est le plus souvent utilisée dans les domaines suivants Vue en tant que propriété du modèle v : elle facilite souvent les choses, prend en charge un grand nombre d'éléments automatiquement et ne nécessite pas de coder un support supplémentaire pour la modification des valeurs.

Toutefois, dans certains cas, il est nécessaire de suivre spécifiquement une tentative de changement et de réagir en conséquence. Vue Les effets mécaniques, tels que les propriétés calculées, font que l'effet obtenu est souvent bien pire qu'avec une approche manuelle ;

● Un autre aspect intéressant est le JSX, qui est une manière très "vagabonde" de modéliser le contenu rendu à l'aide de React. Les avis divergent au sein de la communauté des développeurs.

D'après mes observations, il semble que les développeurs qui utilisent un environnement autre que JS, par ex. PHP ou C#, sont plus enclins à modéliser les points de vue de manière à ce qu'ils soient plus faciles à comprendre. Vue ne.

En résumé, les modèles connus de Vue permettent de définir des vues de manière très claire et élégante, tandis que le JSX de React permet de les construire dans de nombreux cas plus rapidement, en les adaptant à des besoins spécifiques et en nécessitant souvent moins de code pour construire des structures diverses ;

● Examinons également les écosystèmes de ces deux outils. En principe, nous pouvons dire qu'ils ne diffèrent en rien. Tous deux sont appelés bibliothèques pour une raison : ils fournissent le strict minimum pour la prise en charge d'applications web réactives.

Les autres éléments, liés à la communication avec l'API, au flux de données, aux composants de l'interface utilisateur utilisés dans les différentes sous-pages, sont des "fournisseurs", c'est-à-dire des bibliothèques provenant de l'extérieur, qui doivent être correctement rattachées à l'interface utilisateur. projet. C'est un peu comme le monde des Lego : si vous voulez construire un ensemble cohérent, vous devez l'assembler à partir de petits blocs individuels.

Cette allégorie se réfère précisément aux composants attachés, qui sont la force des applications créées avec React ou Vue;

● Une chose importante, en particulier pour les personnes qui ne sont pas très expérimentées dans l'environnement JS, est le niveau d'entrée dans une bibliothèque particulière. En d'autres termes - la complexité de l'outil, consistant en le temps direct que vous devez consacrer à la compréhension de ses mécanismes.

Je pense qu'une chose doit être dite sans équivoque : dans le cas de la VueIl est beaucoup plus simple. Nous avons une liaison de données bidirectionnelle, nous avons un modèle élégamment spécifié qui est trompeusement similaire aux solutions dans d'autres langages, par exemple twig, et enfin - nous n'avons pas de maux de tête causés par l'apprentissage des théories concernant le fonctionnement des crochets individuels et les cas dans lesquels des mécanismes spécifiques doivent être utilisés.

Que disent les statistiques ?

S'aligner directement sur la voix de la foule n'est pas exactement un bon choix. Cependant, une bonne étape pour prendre une bonne décision est d'analyser ce que disent les personnes qui ont interagi avec ces bibliothèques.

Et oui - étoiles sur github peut être un indicateur de l'implication de la communauté d'une bibliothèque particulière dans son développement, de la façon dont elle est perçue par les développeurs et de l'intérêt qu'ils portent à son évolution. Les ingénieurs qui démarrent un dépôt particulier reçoivent souvent des notifications sur les nouvelles versions ou les changements de code, ce qui se traduit par une connaissance directe de la bibliothèque.

Cependant, le nombre d'étoiles sur github ne doit pas être considéré comme un oracle - tous les développeurs qui aiment un outil ne laisseront pas une marque - mais plutôt comme un signe de la passion pure que les développeurs ont pour un projet open-source particulier.

Google Trends est un service bien connu qui permet d'étudier l'intérêt pour des sujets spécifiques au fil du temps. Bien qu'il ne s'agisse pas d'un indicateur rationnel de la qualité ou de l'utilisation, il peut fournir toutes sortes d'analyses.

Il est facile de constater que le parcours des cinq dernières années a été relativement similaire lorsqu'il s'agit de comparer les deux protagonistes de l'article d'aujourd'hui. La conclusion de base que l'on peut tirer de ce tableau est que React est plus performant en termes de popularité de recherche par rapport à son adversaire.

Pour être clair, le fait d'être en tête de Google Trends ne signifie pas qu'une bibliothèque est meilleure. Il s'agit de la popularité du public, comme je l'ai mentionné précédemment - probablement plus de personnes ont entendu parler de cet outil, il a peut-être suscité plus d'intérêt parmi les membres de l'Union européenne. CTOs, développeurs de logiciels ou les personnes qui souhaitent simplement apprendre un outil particulier.

Ce graphique se reflète-t-il dans la réalité ? Dans une certaine mesure, oui. D'une manière générale, les personnes interrogées sont plus nombreuses à faire preuve d'une connaissance diversifiée et sophistiquée des sujets suivants React que Vue. Quelles opinions pouvez-vous obtenir en parlant avec ces personnes ? J'essaierai d'en donner un aperçu dans le paragraphe suivant.

État de la JS  est un site qui interroge chaque année les personnes travaillant sur les technologies liées à JavaScript. Son objectif est de recueillir des informations auprès des développeurs sur la manière dont ils perçoivent les outils avec lesquels ils travaillent au quotidien.

Les questions couvrent des outils individuels pour différents objectifs - par exemple, des outils utilisés sur le front-end et sur le back-end, mais aussi des outils pour les tests, la gestion de l'état de l'application, etc. Le site pose une série de questions sur l'outil lui-même, les intérêts, les expériences et une évaluation globale qui se résume à la phrase "Utiliseriez-vous cet outil dans de futurs projets ?"

Le site lui-même vous permet de faire de nombreuses analyses, de comparer des outils pertinents et parfois de découvrir des bibliothèques moins connues qui commencent à bien se comporter dans le monde du JS, gagnant en popularité tout en bénéficiant d'un taux de "bonheur d'utilisation" élevé. Je vous encourage sincèrement à parcourir le contenu de ce site.

Résumons la section à l'aide de statistiques. L'analyse de différents types de graphiques peut souvent être une très bonne option pour comparer différents aspects de sujets donnés. Cependant, il est important de prendre en compte le fait que suivre la voix de la foule n'est pas nécessairement la chose la plus intelligente à faire. Au lieu de cela, vous pouvez prendre une décision éclairée en utilisant certaines des leçons tirées des analyses de graphiques.

Meilleur choix pour les développeurs

J'ai mentionné plus haut le seuil d'entrée plus bas pour l'obtention d'un permis de conduire. Vue - En effet, il permet de se concentrer un peu plus rapidement sur le développement de l'application, en utilisant l'outil et en réduisant au minimum le temps nécessaire pour se familiariser avec l'environnement, les mécanismes et les différents cas d'utilisation.

D'une manière générale, je suis d'avis que Vue est plus adapté aux personnes qui n'ont pas encore eu affaire à des bibliothèques frontales. Il vous permettra certainement d'obtenir des résultats satisfaisants en peu de temps d'une manière plus encourageante.

Cependant, disons-le haut et fort, la méconnaissance du langage dans lequel nous utilisons des outils spécifiques nous portera préjudice tôt ou tard. C'est un élément négligeable pour les choses simples, mais au fur et à mesure que la complexité des applications créées augmente, il sera de plus en plus difficile de construire des applications de manière décente sans une bonne connaissance des éléments suivants JavaScript.

Je ne fais pas vraiment référence à la capacité d'écrire des fonctions sophistiquées, car cette partie peut être largement remplacée, par exemple, par des vendeurs. Je fais référence à certaines erreurs courantes qui peuvent être commises dans le langage et au fait de ne pas être conscient que le comportement incorrect n'est pas dû à l'utilisation de la bibliothèque, mais à l'utilisation du langage. L'erreur la plus courante qui se manifeste ici est la soi-disant immutabilité - c'est-à-dire la connaissance du mécanisme de référence dans JavaScript.

Je ne suis pas en mesure de dire quelle bibliothèque est la meilleure pour les développeurs plus ou moins familiers avec JavaScript. Mais je sais une chose : si vous voulez avoir une idée réelle de la façon dont le développement avec les deux outils se présente "de l'intérieur", essayez d'écrire des applications dans chacun d'entre eux. Cela vous donnera une idée, vous permettra de voir quels mécanismes vous attirent le plus et quel est le meilleur choix pour vous.

Comme je l'ai mentionné précédemment, les deux bibliothèques sont alimentées par des écosystèmes similaires et ont une vision similaire de la construction d'applications avec de petits composants. Les deux bibliothèques se portent bien - rien n'indique qu'elles disparaîtront dans un avenir proche. Par conséquent, les offres d'emploi dans les deux bibliothèques resteront à un niveau similaire.

Les conclusions sont simples : utilisez ce qui vous convient, accumulez de l'expérience et évaluez. Cela vous aidera à développer une approche rationnelle pour déterminer s'il est préférable d'utiliser l'une ou l'autre bibliothèque dans le cadre d'un projet particulier ; essayez également d'expérimenter - rien n'enseigne aussi profondément que les erreurs commises dans le passé.

Meilleur choix pour CTO

Ce n'est un secret pour personne qu'il n'existe pas de solution miracle qui soit la meilleure pour un projet particulier. Les outils utilisés pour créer des applications vieillissent rapidement, surtout au niveau du front-end, et il est souvent difficile de trouver ses marques dans les dernières tendances.

Cependant, le choix de la technologie n'est pas, ou du moins ne devrait pas être, une question d'adéquation avec les tendances actuelles. Nous devrions plutôt l'orienter vers des attentes et des hypothèses spécifiques concernant l'application que nous allons construire. Chacune des bibliothèques comparées a ses forces et ses faiblesses, qui, adaptées au cas d'utilisation, nous permettront de faire le choix le plus raisonnable.

Une option intéressante pourrait être les résumés technologiques des grandes entreprises, qui décrivent souvent leurs cas d'utilisation, la manière dont le développement d'applications importantes s'est déroulé ou se déroule actuellement et les erreurs qu'elles ont commises dans le passé. Peut-être trouverons-nous parmi eux des cas particulièrement intéressants dans le contexte du choix d'une bibliothèque pour un projet particulier.

Les caractéristiques à prendre en compte pour choisir les bons outils pour l'application en cours de développement sont : le temps de développement de l'application, la facilité d'utilisation de l'outil, la facilité d'utilisation de l'outil, la facilité d'utilisation de l'outil. maintenance de l'applicationLe choix des bibliothèques dépend de plusieurs facteurs : la complexité de l'application et l'expérience des développeurs dans l'utilisation de bibliothèques spécifiques.

Les développeurs sont les personnes qui passent le plus de temps avec les outils que je compare et ce sont eux qui peuvent fournir les meilleurs conseils et vous aider à faire le meilleur choix dans le grand choc des bibliothèques. C'est au cours du développement de l'application que l'on voit les différents problèmes qui découlent directement du choix de la technologie, et que l'on a la meilleure vue sur ce qui nuit à l'utilisation d'un outil particulier pour des fonctionnalités particulières.

Comme je l'ai mentionné précédemment, les deux bibliothèques ne semblent pas disparaître de la base de données de la marchéIl n'est pas possible de prendre des décisions sur la base de statistiques ou d'opinions, du moins pas dans les années à venir. Au lieu de prendre des décisions basées sur des statistiques et des opinions
de diverses personnes sur l'internet - il serait peut-être plus judicieux de s'adresser aux développeurs.

Nous leur présentons ce que nous attendons de l'application, le temps dont nous disposons pour la livrer et nous leur permettons d'échanger librement leurs points de vue sur les deux solutions avant de prendre une décision finale.

Conclusions

Les guerres sur l'internet sont généralement - ou peut-être dans tous les cas - inutiles. Il y aura toujours des personnes qui s'entêteront à affirmer que leur choix est meilleur sans donner d'arguments rationnels confirmant leur décision.

Au lieu de nous laisser aveugler par des choix spécifiques, concentrons-nous sur l'analyse, essayons de tirer des conclusions appropriées et utilisons-les pour ajuster ou rejeter une solution spécifique.

Comme le titre l'indique, je n'ai pas l'intention de couronner une bibliothèque particulière comme remède à tous les maux. Au lieu de cela, quelques hypothèses sont présentées et les points forts et faibles des deux bibliothèques sont révélés. J'ai donné quelques conseils sur ce qu'il faut rechercher lors du choix de l'une ou l'autre bibliothèque afin de prendre une décision judicieuse et de ne pas se laisser guider par les tendances ou par des personnes aléatoires sur l'internet.

Chaque outil peut répondre aux besoins du projet de manière satisfaisante. Aucun des deux ne disparaîtra rapidement du marché dans les années à venir. Ils disposent tous deux de communautés puissantes et d'une certaine maturité, ce qui montre qu'ils se portent bien.

Le choix final est entre vos mains. Toutefois, si vous avez des doutes ou si vous souhaitez simplement discuter de votre cas avec The Codest, n'hésitez pas à nous contacter !

En savoir plus :

Pourquoi vous devriez (probablement) utiliser Typescript

Comment ne pas tuer un projet avec de mauvaises pratiques de codage ?

Stratégies de récupération des données dans NextJS