La guerre des frameworks JavaScript est terminée

Et il n’y a qu’un seul vainqueur.

Les participants : la guerre entre frameworks a été un sujet brûlant dans la communauté JS. Backbone, Sencha et d’autres ont disparu. jQuery a, de façon surprenante, encore une grande communauté. Il y a aussi eu des cas qui ont moins bien tourné, comme Angular.

jQuery : le plus ancien participant. Il a gagné en popularité en corrigeant les problèmes de compatibilité entre navigateurs. Mais il était difficile de faire évoluer des applications avec. Aujourd’hui, il n’est plus dominant et n’est plus le meilleur choix.

AngularJS : déjà en mode LTS et retiré du service. Ce fut un grand bond en avant dans l’écosystème des frameworks, et beaucoup le regrettent. Il n’est plus maintenu, donc ce n’est plus un participant.

Angular :

• est apparu pour concurrencer React. À cause des problèmes de performance et de robustesse d’AngularJS, beaucoup de programmeurs enviaient React. Angular a cherché à moderniser AngularJS et à exploiter les améliorations d’ES6 pour rivaliser avec React.
• Sa courbe d’apprentissage très raide a été sa plus grande difficulté. Il nécessitait de nombreux concepts. Il héritait de la courbe d’apprentissage d’AngularJS, avec en plus de nouvelles difficultés comme RxJS ou l’injection de dépendances hiérarchique (DI).
• Une autre inquiétude venait de nombreuses promesses non tenues. Par exemple, la V2 permettait de créer facilement des pages en server-side rendering (SSR), mais au 24/02/2022, elles ne pouvaient toujours pas fonctionner sans JS.
• Le plus gros problème a été la fragmentation et les mises à niveau de version. Les upgrades de version étaient trop difficiles, si bien que les utilisateurs n’osaient pas prendre le risque. Les statistiques du site npm le montrent.

VueJS :

• a été la réponse pour les développeurs qui voulaient de meilleures performances qu’AngularJS, et quelque chose de plus stable et plus simple à utiliser qu’Angular. Dans son système de templates, Vue était très proche d’AngularJS, ce qui lui permettait de conserver la simplicité d’AngularJS tout en tirant sa force de React.
• Mais VueJS a eu de sérieux problèmes dans les versions 1 et 2. Il gérait mal les tableaux, et ses auteurs ont reproché à JavaScript le mauvais choix de leur algorithme de mise à jour. Dépendance à des bibliothèques comme Vuex ou Redux.
• Ce problème a été résolu en version 3. Cependant, rejeter la faute sur les autres pour ses propres erreurs ne convenait pas à la communauté.

SvelteJS :

• un concurrent en pleine croissance. Il fait de grandes promesses. Il affirme que son principal avantage est de traduire les composants dans un langage impératif. Selon ses partisans, c’est mieux que le déclaratif de React.
• Son usage est simple. En revanche, les éléments générés par cette traduction en commandes ne sont pas aussi prévisibles qu’ils en ont l’air. Dans certains cas, les changements ne peuvent pas être détectés correctement. L’état peut alors être corrompu et la view peut ne pas se mettre à jour correctement. Ce problème suscite beaucoup d’inquiétudes et, comme autrefois pour VueJS, il devient difficile de justifier n’importe quel projet SvelteJS.

StencilJS :

• n’est pas strictement un framework. Il permet d’écrire des composants et de les convertir vers d’autres frameworks. Actuellement, il peut les convertir vers Angular, React, Vue et Web Components.
• Il pose la question : est-ce un code similaire à celui des autres frameworks ? (voir texte original)

Mitosis :

• vous n’en avez probablement jamais entendu parler, mais c’est la raison pour laquelle cet article a été écrit. C’est le framework le plus récent créé par Misko Hevery, le créateur d’Angular.
• Il poursuit le même objectif que StencilJS. Il traduit les composants vers de nombreux frameworks.
• Lui aussi pose la question : est-ce un code similaire à celui des autres frameworks ? (voir texte original)

React :

• l’un des plus anciens frameworks présents dans le registre npm depuis plus de 10 ans. Il a beaucoup changé, mais reste en grande partie compatible avec ses anciennes versions. Tous les changements ont été des améliorations. Certains disent que faire du React avec les hooks en a fait un bien meilleur framework.
• Sa meilleure qualité ne réside ni dans les hooks ni dans les fonctionnalités visibles, mais dans l’inverse. Il adopte les standards modernes de JS et JSX. Ce n’est plus un framework. Peut-être que ça ne l’a jamais été. React a tellement cherché à suivre les standards qu’il a fini par s’effacer lui-même du code utilisateur.

Donc, le vainqueur est…

• JSX. C’est aussi React, mais surtout la philosophie derrière React. React lui-même est une bibliothèque. Il peut être remplacé par de nombreuses autres bibliothèques, comme Preact ou React Native. En y regardant de plus près, StencilJS ou Mitosis ressemblent beaucoup à React, et ce n’est pas un hasard.
• « Le meilleur framework est celui qui s’efface du code utilisateur »
• React exploite largement JS et JSX. Le code utilisateur est indépendant de React. Le même code peut fonctionner dans d’autres frameworks sans modifications majeures.
• Donc, sans aucun doute, React est le vainqueur de la guerre des frameworks.
• Parce que ce n’est pas le framework dans le code utilisateur.

[piriri11]

L’essentiel, c’est sans doute d’appliquer autant que possible le conseil de l’Oncle Bob, « ne vous mariez pas avec un framework » : qu’il s’agisse de React, de Vue ou d’Angular, on peut probablement prendre du plaisir à développer avec n’importe lequel si l’on écrit son code dans cet esprit.

[polygon]

Quelles sont les perspectives pour Marko JS ?
Comme il est soutenu par eBay, je m'y intéresse récemment, mais il n'est même pas mentionné dans l'article original...

[minhoryang]

« Beaucoup a changé, mais reste compatible avec la plupart des versions précédentes » pour React — je n’ai pas vraiment eu souvent cette expérience de compatibilité.
« Fragmentation et montées de version » pour Angular — mais sur ce point, j’ai souvent eu une expérience fluide.

[roxie]

Je pense qu’il faudrait classer JSX non pas comme un framework, mais comme une spécification. Je vois bien ce que vous voulez dire, mais l’introduction est beaucoup trop longue pour quelque chose dont on aurait pu se passer, et surtout le titre est putaclic. Vous utilisez en plus un style qui rabaisse la qualité du texte lui-même.

[xguru]

Merci pour le résumé et pour les bons commentaires ~ ! Je pense que ce genre de discussions pourra beaucoup aider d'autres personnes ;)

[plastic041]

Dans l’ensemble, j’ai l’impression que c’est un article étrange.

D’abord, la partie sur Svelte.
Quand on lit l’article original, il est écrit que lors de la mise à jour d’un tableau, écrire quelque chose comme array[0] += 1 pose problème parce que la mise à jour ne se fait pas. Mais la documentation officielle de Svelte indique aussi qu’un tableau doit être réaffecté pour que la mise à jour soit prise en compte, et de toute façon, dans React non plus, ce n’est pas comme ça qu’on met à jour un tableau, non ?

Il y a aussi la partie sur VueJS.
En le comparant à Angular, l’article parle des inconvénients de Vue, mais je ne vois pas bien l’intérêt de dire que Vue n’est pas terrible en mettant côte à côte du code Angular qui fonctionne et du code Vue qui ne fonctionne pas.

[pppqqq]

Je pense que c’est une critique tout à fait valable. La différence entre réaffectation et mutation est un point déroutant pour les débutants, et puisque Svelte comme Vue utilisent une syntaxe distincte mais proche de JavaScript, les comportements qui ne correspondent pas à ce qu’on attend méritent effectivement d’être critiqués.

Vue, en particulier, met à jour l’état lorsque set est déclenché via des proxies ; à première vue, cela semble simple, mais il y a beaucoup de pièges possibles, donc je comprends tout à fait en profondeur cette critique sur ce point.

React est bien plus libre vis-à-vis de ce problème : une réaffectation ne met pas à jour l’état, et l’on fournit des mises à jour unidirectionnelles dans le cadre standard de JavaScript en appelant explicitement une fonction comme setUpdate, donc il n’y a dès le départ aucun risque de confusion entre le fait de modifier seulement une partie d’un tableau et une réaffectation, par exemple.

[tequila]

C’est un peu une remarque annexe, mais dans Vue 3, ce type de mise à jour de tableau est pris en charge de manière réactive, donc j’ai l’impression que l’article se contente de critiquer aveuglément l’ancienne version de Vue avant de passer rapidement à autre chose... ^^;; Alors qu’en React, le fait que ce genre de mise à jour ne fonctionne pas est loin d’être un inconvénient mineur, mais j’ai le sentiment que ce point caractéristique n’est pas vraiment traité comme il le devrait, haha.

[tenshi]

L’article original a aussi reçu beaucoup de commentaires, et beaucoup d’entre eux soulignaient divers problèmes.

[riddler]

La partie « est-ce un code similaire à celui d’autres frameworks ? » avec les explications sur StencilJS et Mitosis m’a semblé confuse, donc j’ai regardé le texte original, et il semble bien que la question soit plutôt de savoir si le code utilisé par ces deux frameworks ne ressemble pas à ce qu’on a déjà vu dans d’autres frameworks.

Je pense qu’ils l’ont formulé dans le sens où l’écriture du code est similaire à celle de React.

[jjpark78]

Je trouve l’évaluation de VueJS bien trop sévère..

React non plus n’est certainement pas totalement affranchi de la dépendance à redux..

Si l’on parle de taille de base d’utilisateurs, il est vrai que React est de loin numéro 1,

mais sur le plan technique, on ne peut pas dire que c’est un projet inférieur à React.

[cckn1985]

Le point principalement avancé ici à propos de VueJs n’est-il pas moins la dépendance à des bibliothèques externes que « l’attitude consistant à rejeter sur JS la responsabilité des problèmes qu’ils ont eux-mêmes causés » ?

Quoi qu’il en soit, il me semble clair que l’opinion publique sur vueJS n’est effectivement pas très bonne.

Si vous allez lire le texte, le passage mentionnant la dépendance à Vuex et Redux explique aussi que, pour résoudre les problèmes apparus dans VueJS 2, des bibliothèques comme Vuex et Redux étaient « indispensables ».

[jjpark78]

Cela figure déjà dans plusieurs commentaires de l’article original, mais

quand la complexité augmente, que ce soit avec Vue ou React, des bibliothèques de gestion d’état / de cache comme Redux deviennent toutes « indispensables ».

C’est vrai, dans l’article original, c’est présenté comme un inconvénient de VueJS, alors que pour React, cela n’a « délibérément » pas été mentionné.

Le comportement de la communauté n’a pas vraiment d’importance de mon point de vue..

[road4one]

Avec React, redux n’est pas indispensable. On peut gérer l’état avec contextAPI ou useReducer, par exemple. Je ne pense pas pour autant que ce soit un argument permettant de dire que React est meilleur que Vue.

[cckn1985]

Oui, haha, je ne pense pas que ce soit un bon article dans l’ensemble.

L’auteur a fixé sa conclusion à l’avance et dénigre les autres frameworks pour y parvenir.