React l’emporte par défaut et ralentit l’innovation front-end
(lorenstew.art)- Aujourd’hui, l’adoption de React se fait par défaut plutôt que pour sa supériorité technique, ce qui ralentit l’innovation dans l’écosystème front-end
- De nombreuses équipes choisissent « React, que tout le monde connaît » sans examiner les contraintes, si bien que les effets de réseau dictent les décisions d’architecture davantage que l’adéquation technique
- Des frameworks innovants comme Svelte, Solid et Qwik proposent de meilleurs modèles de performance, mais restent à l’écart de la compétition grand public faute d’adoption
- React a beaucoup de qualités, mais le vrai problème est que la mentalité du React-par-défaut augmente le coût d’opportunité et empêche d’envisager de meilleures alternatives
- Le message est qu’un écosystème sain a besoin de diversité et de concurrence, et qu’il faut choisir un framework non pas par défaut, mais selon les contraintes et l’adéquation
La victoire de React par défaut, et ses limites
- React n’est plus souvent choisi pour sa supériorité technique, mais adopté comme option par défaut
- Cela renforce l’habitude, dans les équipes, d’utiliser automatiquement React sans évaluer les contraintes du projet
- Les frameworks alternatifs (Svelte, Solid, Qwik), bien qu’ils aient des avantages de performance sur React dans certains scénarios, ne sont pas correctement évalués
- Plus qu’un problème propre à React, c’est la mentalité du React-par-défaut qui crée une structure freinant l’innovation
Le plafond de l’innovation
- Le Virtual DOM de React était pertinent en 2013, mais agit aujourd’hui comme une surcharge inutile
- Les Hooks ont résolu les problèmes des composants en classe, mais ont introduit de nouvelles complexités, comme les tableaux de dépendances et les stale closures
- Les Server Components et le React Compiler tentent d’améliorer les performances, mais il s’agit de moyens de contourner les limites du modèle React
- À l’inverse, les Runes de Svelte, la réactivité fine de Solid et la resumability de Qwik montrent un potentiel supérieur avec des modèles totalement différents
Dette technique
- Choisir React par défaut entraîne des coûts d’exécution inutiles et une charge de gestion des re-renders
- Les développeurs passent du temps sur les dépendances d’effets ou la gestion de l’hydration au lieu de produire de la valeur métier
- Dans les benchmarks, Solid affiche des performances de mise à jour 2 à 3 fois supérieures à celles de React
- Une pensée centrée sur les patterns React affaiblit les fondamentaux du web et renforce l’inertie architecturale
Les frameworks alternatifs
-
Svelte : la révolution du compilateur
- Svelte traite l’essentiel du travail au moment de la compilation et élimine le virtual DOM
- Les composants se rapprochent davantage de la structure native du web, et la surcharge à l’exécution diminue fortement
- Mais son taux d’adoption reste faible à cause de la perception selon laquelle « il y a peu d’opportunités professionnelles »
- The Guardian, Wired, Shawn Wang et d’autres cas montrent qu’après adoption de Svelte, la taille des bundles et les temps de chargement ont fortement diminué, tandis que la productivité de développement s’est améliorée
- Par exemple, Shawn Wang a réduit la taille de son site de 187KB avec React à 9KB avec Svelte
-
Solid : une approche primitive de la réactivité fine
- Solid combine une réactivité de précision (micro-réactivité) avec la syntaxe JSX
- Via les signal, il accède directement uniquement au DOM modifié, en évitant complètement le goulot d’étranglement de la reconciliation
- Il se distingue par ses excellentes performances et la simplicité de sa gestion d’état
- Les cas d’adoption restent encore limités, mais l’expérience des premières équipes montre des gains majeurs à la fois en efficacité et en simplicité du code
-
Qwik : l’innovation de la resumability
- Qwik se distingue par un démarrage immédiat grâce à la resumability, au lieu de l’hydration traditionnelle
- Il ne charge progressivement que les fonctionnalités nécessaires au moment voulu, et permet de sérialiser à la fois l’état et le code
- Il se montre particulièrement performant sur les grands sites, les sessions longues et les réseaux lents
- Beaucoup d’équipes ne l’ont pas encore essayé, mais celles qui l’ont adopté rapportent de fortes améliorations à la fois sur le temps de chargement initial et l’efficacité des ressources
-
La complexité de l’API React et la simplicité des frameworks alternatifs
- L’API de React comprend des concepts complexes comme les hooks, context, reducer, memoization, etc., ce qui augmente la charge cognitive des développeurs
- En cas de mauvaise utilisation, le risque de bugs liés aux dépendances et de surconception devient important
- Par exemple, la panne de Cloudflare du 12 septembre 2025 a aussi été causée par une erreur de configuration du tableau de dépendances de
useEffect - À l’inverse, des alternatives comme Svelte, Solid et Qwik mettent en avant, avec des API bien plus petites et ciblées, la simplicité et les principes fondamentaux du web
- Ces trois frameworks disposent tous d’une supériorité technique suffisante, mais la culture du React par défaut fait qu’ils ne sont, dans la plupart des cas, même pas testés
La prison des effets de réseau
- La domination de React crée des barrières auto-renforçantes
- Le marché de l’emploi ne recherche que des « développeurs React », et chaque organisation fige ses bibliothèques de composants et habitudes de développement autour de React
- Les dirigeants cherchant à éviter le risque choisissent naturellement le React jugé sûr, et les établissements de formation s’alignent sur ce choix
- C’est la marque d’un écosystème où la concurrence saine a disparu
Briser les effets de réseau
- Pour sortir de cette situation, un choix conscient est nécessaire
- Les responsables techniques doivent abandonner l’inertie et décider de l’architecture en fonction des exigences, et les entreprises peuvent allouer un budget pilote pour tester des alternatives
- Les développeurs, eux aussi, doivent éviter de s’enfermer dans un seul paradigme et apprendre l’esprit de plusieurs frameworks
- Les établissements de formation doivent renforcer les cours sur des concepts agnostiques vis-à-vis des frameworks, et les contributeurs open source peuvent soutenir davantage les petits écosystèmes
Le changement ne vient pas tout seul : il faut le provoquer intentionnellement.
Checklist d’évaluation d’un framework
Pour un nouveau projet, les critères suivants peuvent servir de base d’évaluation
- Exigences de performance : chargement initial, efficacité des mises à jour, taille du bundle, et recours ou non à l’optimisation au moment de la compilation
- Compétences de l’équipe et courbe d’apprentissage : tenir compte de l’expérience existante, en sachant qu’il existe aussi des alternatives compatibles avec React comme Solid
- Scalabilité et coût de possession : évaluer les coûts de long terme, y compris la maintenance, la gestion des dépendances et la dette technique
- Adéquation avec l’écosystème : équilibre entre maturité et innovation, essais pilotes sur des tâches non critiques et test du ROI
Objections fréquentes et réponses
- Maturité de l’écosystème : un écosystème plus ancien n’est pas nécessairement mieux adapté aux problèmes d’aujourd’hui. Une forte dépendance aux packages tiers entraîne aussi des effets secondaires comme un fardeau de maintenance, des vulnérabilités de sécurité et l’alourdissement des bundles. À l’inverse, un petit écosystème peut davantage se concentrer sur les fondamentaux du web, et les progrès des outils d’IA permettent de développer plus facilement et plus rapidement des solutions sur mesure.
- Problème de recrutement : la demande devient en soi un critère de recrutement. Il est possible de tester des alternatives dans des domaines non critiques, puis de combler les lacunes par l’apprentissage sur le terrain.
- Bibliothèques de composants : des design systems indépendants des frameworks, ainsi que l’usage de Web Components, permettent de réduire le verrouillage tout en préservant la productivité.
- Stabilité : React lui-même continue d’évoluer sans cesse avec les hooks, les Server Components, etc. Les frameworks alternatifs proposent souvent au contraire des API plus cohérentes.
- Nécessité de validation à grande échelle : autrefois, jQuery aussi était une référence mondiale. Rien ne garantit que les succès du passé restent valables à l’avenir.
Les effets néfastes sur l’écosystème et l’industrie dans son ensemble
- La monoculture React ralentit le développement du web lui-même
- Les talents et les capitaux se concentrent sur la résolution des problèmes de React, tandis que les innovations propres à la plateforme sont retardées
- Les établissements de formation renforcent aussi, avec des cursus centrés sur l’employabilité immédiate, l’apprentissage de compétences peu transférables
- Le développement de la plateforme web elle-même se heurte à la réponse « React suffit », et le manque de diversité de l’écosystème finit, à long terme, par nuire à tout le monde
L’écosystème souhaitable que nous pouvons construire
- La diversité est une condition indispensable à un écosystème sain
- C’est lorsque plusieurs paradigmes se concurrencent et échangent que l’innovation naît
- Les développeurs progressent en apprenant plusieurs façons de penser, et la plateforme web elle-même avance grâce à cette diversité d’expérimentations
- Miser entièrement sur un seul framework crée un point unique de défaillance. Une fois ses limites atteintes, la croissance s’arrête et de meilleures opportunités disparaissent aussi
- Pour chaque projet, il faut choisir en fonction des contraintes techniques et de l’adéquation, sans se reposer uniquement sur React comme valeur par défaut
- Seule la diversité garantit une véritable innovation
- Il est temps de ne plus planter tous la même “graine” (React), mais de participer, par des expérimentations plus diverses entre frameworks, à rendre l’écosystème web plus résilient et plus innovant
- Le choix nous appartient
19 commentaires
Il est inévitable que les développeurs juniors choisissent React, mais le vrai problème, c’est que les développeurs seniors cessent de réfléchir à d’autres alternatives.
C’est vrai que React ou Java sont déjà des vieilleries dépassées alors qu’il existe bien de meilleures alternatives, et pourtant ils continuent à dominer beaucoup trop longtemps lol
On a beaucoup expérimenté pendant la grande période chaotique des frameworks...
Dans le travail, il n’y a pas besoin de tout remplacer quand on utilise déjà quelque chose d’existant, et même pour un nouveau projet,
il n’y a finalement pas beaucoup de gens prêts à abandonner ce qui fonctionne déjà bien, à réapprendre et à migrer, sans parler des problèmes de recrutement...
J’espère vraiment que Solid va bien s’en sortir… Il faut voir comment briser le monopole de React.
Au cours de la dernière décennie, d’innombrables outils ont déferlé sur l’écosystème FE et, après bien des cycles d’essor et de déclin, on commençait à peine à retrouver une certaine stabilité — et voilà qu’on nous demande de retenter un tel chaos généralisé...
C’est un article beaucoup trop biaisé, non ?
« Des frameworks innovants comme Svelte, Solid ou Qwik offrent de meilleurs modèles de performance, mais restent en retrait dans la compétition grand public faute d’adoption »
S’il n’y a pas de critère cohérent pour définir ce que signifie le mot innovation,
il me semble que l’hypothèse de départ est déjà erronée.
Quand je lis ce genre de textes, j’ai l’impression qu’on se concentre trop sur le software engineering au lieu de se soucier de construire un produit. Au final, tout se vaut plus ou moins, donc il faut surtout bien faire le produit. Mais on passe son temps à chercher un nouveau framework, une nouvelle architecture, à faire de l’overengineering, puis à dire que ceci est meilleur et qu’il faut encore tout changer. Je pense que l’important, ce n’est pas que ce soit nouveau, mais de bien utiliser ce qu’on a pour sortir un produit.
On n’y peut pas grand-chose, puisque les grands groupes de la tech en Corée recrutent sur la base de React (Next.js).
Même pour un acteur majeur comme Vue.js, il n’y a pas beaucoup de postes proposés par les grandes entreprises tech.
On ne peut pas ignorer l’écosystème... La plupart des bibliothèques tierces et open source qui sortent ces derniers temps prennent officiellement en charge React, tandis que les autres frameworks n’ont qu’un support de la communauté, donc si on veut combiner diverses choses au final React ne peut qu’être l’option la plus sûre...
Difficile de trouver un domaine qui expérimente autant que le front-end...
Grâce à l'engagement de l'équipe de développement Facebook autour de React, le développement d'applications web est devenu plus ambitieux. Ce n'est pas le méchant... il a mis fin à l'ère de php jquery.
Avis Hacker News
Je pense que React n’est pas devenu la valeur par défaut par hasard, mais parce qu’il est très efficace et bien conçu, au point d’être devenu un standard de fait, tout en se retrouvant aujourd’hui dans le rôle du méchant.
L’affirmation selon laquelle React ralentirait l’innovation me paraît franchement absurde.
Au milieu d’innombrables frameworks « moi aussi » et de conceptions confuses, React est pratiquement le seul choix stable et raisonnable.
Je ne suis pas d’accord, humblement.
Je n’ai jamais construit d’application interactive complexe avec React, seulement quelques sites simples où l’équipe l’avait déjà choisi avant moi.
Au final, React se révèle au contraire clairement difficile à réduire à l’échelle d’un site simple.
Pour une simple page de connexion, on peut stocker l’état directement dans le DOM et envoyer les valeurs avec un simple
<form>, et l’affichage/masquage du mot de passe se gère avec un peu de JS.Mais avec React, il faut apprendre JSX, les hooks, le cycle de vie des composants, les builds de développement, le packaging de production, etc.
D’autres frameworks comme Vue ou Alpine peuvent être utilisés de manière « progressive » et on peut démarrer directement via CDN.
React se prétend aussi progressif, mais à cause de la nature de JSX, un processus de build/compilation est indispensable, et la documentation officielle ne propose pas de démarrage direct via CDN.
Ce n’est pas totalement impossible en forçant un peu, mais il faut alors envoyer le compilateur au client, ce qui est en pratique la pire option.
La plupart des sites ne sont pas du niveau de Facebook, Spotify ou Netflix (et même Netflix a annoncé s’éloigner de React), donc j’ai du mal à accepter l’idée que React soit si efficace et si bien conçu.
Quand React est apparu il y a 12 ans, c’était vraiment innovant.
Mais plusieurs frameworks similaires sont vite arrivés, et depuis, il est resté au stade du « suffisamment correct » plutôt qu’au centre de l’innovation.
Aujourd’hui, il accumule du boilerplate pour contourner les problèmes de son ancienne architecture Virtual DOM, et il est de moins en moins séduisant face aux alternatives modernes.
Le sens du titre de l’article est inversé.
En réalité, j’ai plutôt l’impression que l’« innovation » n’arrive pas à rattraper la formule React, c’est-à-dire la formule du succès.
Il faut aussi se demander à quel point l’innovation est nécessaire.
En pratique, l’itération et l’amélioration sont souvent meilleures et moins coûteuses.
J’aime bien cet article et cette vision pluraliste des années 2015-2016.
J’aimerais dire à mon équipe « faisons un petit cas d’usage séparé en Svelte », mais la grille d’évaluation joue exactement à l’inverse de ce que défend l’article.
Performance : dans 99 % des apps, personne ne verra la différence, donc on choisit React.
Compétence de l’équipe et courbe d’apprentissage : tout le monde connaît React, personne ne connaît Qwik, donc React encore.
Scalabilité, coût d’exploitation : pas de grande différence.
Écosystème : React est bien plus vaste et plus stable. Donc React.
En plus, les outils d’IA gèrent bien React en ce moment, et les développeurs apprennent presque automatiquement avec React comme centre de gravité.
Au final, React devient inévitablement le choix rationnel.
Je pense que les Web Components sont une porte de sortie face à cet oligopole des frameworks.
Tous les frameworks sauf React soutiennent activement les Web Components, et la solution consiste à utiliser un écosystème compatible de composants et d’utilitaires plutôt que de reconstruire chacun son propre écosystème façon React.
Beaucoup considèrent les Web Components comme des concurrents des frameworks, alors qu’en réalité ils définissent l’interface entre l’implémentation des composants et le navigateur, ce qui permet l’interopérabilité et un assemblage fiable.
Sur cette API bas niveau, on peut encore innover de multiples façons dans la création de composants — sans build, avec JSX, avec des templates, des syntaxes personnalisées, des compilateurs, etc. — ainsi que dans leur composition et la gestion d’état.
Pour sortir du monopole de React, il faut pouvoir dire : « notre nouveau framework Flugle fonctionne bien avec n’importe quel framework et dispose d’excellents outils d’automatisation ! »
Moi aussi, j’utilise des wrappers pour employer des Web Components et éviter le boilerplate.
Avec cette méthode, j’ai obtenu 80 % des avantages des Web Components avec très peu d’effort.
GitHub associé : ZjsComponent, voir aussi un ancien fil HN (discussion HN).
Ce n’est pas parfait, mais je n’ai pas trouvé de moyen plus simple ni plus rapide de créer de nouveaux composants HTML.
S’il n’existe pas d’alternative au niveau de React Native, les Web Components ne suffiront pas.
Les technologies du navigateur ne sont pas assez rapides pour atteindre le niveau des apps natives.
La plus grande valeur de React est de pouvoir unifier le développement GUI sur l’ensemble des plateformes.
J’ai déjà construit une application métier avec des Web Components
lit.Le fait que toutes les propriétés devaient être de type string était assez pénible, et cela n’était pas comparable à une bibliothèque de composants centrée sur le temps réel.
Dans notre grande entreprise, les applications internes doivent obligatoirement utiliser une bibliothèque React centralisée.
Ce n’est pas « React parce que c’est la valeur par défaut », c’est « seul React est autorisé ».
À mon avis, la sortie consiste à réimplémenter la bibliothèque centrale en Web Components pour pouvoir utiliser le framework de son choix.
Je me demande si certains ont eu de bonnes expériences avec les Web Components dans une bibliothèque d’UI React.
Quand on crée une bibliothèque de composants adaptée à un design system donné, s’appuyer sur une bibliothèque headless comme RAC me satisfait assez bien.
Je comprends que les Web Components puissent être complémentaires, mais je vois mal où ils sont le plus pertinents en pratique.
En réalité, cet article ne dit pas que React domine pour des raisons de performance, mais parce que son « bénéfice social » est bien supérieur à celui des alternatives, ce qui rend les autres choix difficiles.
Autrement dit, même sans être techniquement remarquable, React est devenu le choix par défaut, et je suis d’accord pour dire que les effets de réseau pèsent davantage dans la décision que l’adéquation technique.
Cela dit, pour les équipes, React conserve des avantages nets par rapport aux alternatives.
En pratique, la plupart des équipes compétentes savent très bien identifier quand elles constituent vraiment une exception justifiant un autre choix.
J’ai participé à des décisions de stack technique dans plusieurs entreprises et startups, mais je n’ai jamais entendu invoquer « les qualités propres du framework » pour justifier React.
C’était toujours la familiarité, la facilité de recrutement et l’écosystème.
On suppose que les développeurs web prennent des décisions rationnelles, mais d’après mon expérience ce n’est pas le cas.
Les gens sont facilement influencés par des biais humains comme la « preuve sociale » ou l’« autorité ».
Je n’ai jamais entendu quelqu’un dire « on utilise React parce qu’on l’aime ».
C’est toujours « parce que c’est plus facile d’embaucher ».
React est fort pour résoudre des problèmes complexes.
Mais tous les problèmes ne sont pas complexes, et utiliser par défaut un outil complexe ajoute inutilement de la complexité au projet et réduit sa flexibilité.
L’instabilité d’un écosystème qu’il faut maintenir à cause de fonctionnalités passées ou futures n’est d’ailleurs pas un problème propre à React.
J’espère voir émerger de nouveaux courants qui dépasseront le paradigme actuel des web apps.
Il y a des raisons légitimes de s’inquiéter de la monoculture frontend, c’est-à-dire du monopole de React, mais ce qui m’intrigue, c’est qu’il y a 10 ans, la situation était exactement inverse.
De nouveaux frameworks débarquaient chaque semaine sur HN, Angular 1.x vers 2.0 a été un chaos, et on parlait même de « fatigue JavaScript », tant le développement frontend était pénible.
Aujourd’hui, React s’est clairement imposé comme standard, et grâce à ça on peut se concentrer sereinement sur le développement des services.
Je ne suis pas en train de glorifier React (moi non plus je n’aime pas les hooks), mais je suis reconnaissant de ne plus être en 2015.
Il est intéressant de voir qu’avec le temps, l’ambiance commence à changer progressivement.
Je me souviens de l’époque où pullulaient les petites bibliothèques JavaScript de niche.
La domination de React est en quelque sorte une victoire.
Je pense qu’il faut se méfier de l’idée de jeter de force quelque chose de familier et de stable au nom d’une notion floue d’« innovation ».
Je me reconnais complètement là-dedans.
Entre 2009 et 2015, j’ai été assez pionnier et j’ai construit beaucoup d’expériences navigateur proches d’apps natives.
Ma force, c’était les standards du web et leur utilisation la plus directe possible, puis je me suis réorienté vers le backend et j’ai observé de loin l’ascension de React.
React me semblait inefficace, et la contrainte de JSX où « tout doit être une expression » me frustrait aussi.
Malgré cela, je reconnais à React le mérite d’avoir apporté un changement de paradigme important dans la gestion d’état.
Passer des anciens modèles d’état à un flux de données immutable à sens unique a été difficile, mais au final cela avait du sens.
Même à une époque chaotique, React a bel et bien apporté de l’innovation et un changement profond dans la manière de penser la conception des applications web.
Mais si on compare aujourd’hui avec SolidJS, Solid offre les mêmes avantages de façon plus concise, avec de meilleures performances et une maintenance bien plus simple.
Il fournit aussi mieux JSX, les composants serveur et la gestion d’état réactive, et les développeurs React peuvent y passer facilement.
La manière de penser l’architecture des apps reste presque identique, donc on retrouve pratiquement tous les avantages réels de React, en mieux, plus vite, et avec des bundles beaucoup plus petits.
Malgré tout, le marché entier reste centré sur React, donc on est forcé de continuer avec lui.
SolidJS a encore des points douloureux.
Le plus gros problème est qu’il est difficile de savoir intuitivement si une prop est un signal ou non.
Le système de types n’aide pas beaucoup non plus.
Avec React, un changement de référence signifie clairement qu’un rerender se produira côté receveur de la prop, alors qu’avec Solid il n’est pas évident de savoir si le changement sera observé.
Je pense que la plupart des gens se contentent d’utiliser ce qu’ils connaissent bien.
Beaucoup de développeurs ne veulent pas se forcer à utiliser React, mais au final ils n’ont d’autre choix que d’utiliser ce qu’ils maîtrisent.
Le temps est limité, et il faut faire des choix efficaces pour laisser de la place au reste de la vie, famille ou loisirs.
Il n’est pas nécessaire d’être prisonnier de React.
Dans mon entreprise, nous avons aussi un framework développé depuis 10 ans (en pratique, surtout par moi seul), et nous l’avons publié en open source sous licence MIT.
Lien Q.js
J’aimerais bien avoir des retours.
Les hooks ont corrigé les défauts des class components, mais ils ont aussi introduit de nouvelles complexités, comme les tableaux de dépendances, les stale closures ou les usages abusifs.
Mais ces problèmes ne viennent pas uniquement des hooks : ils existaient déjà à l’époque des composants basés sur des classes.
Les tableaux de dépendances : autrefois aussi, il était fréquent d’avoir des bugs parce qu’on ratait des changements de props ou de state.
Les stale closures existaient de la même façon avec le deuxième argument de
setState.L’abus des méthodes de cycle de vie (
componentDidMount,componentWillMount, etc.) était également fréquent.Je pense qu’on aurait déjà eu besoin autrefois d’une documentation du type « n’utilisez les Effects qu’en cas de nécessité ».
Les hooks contribuent clairement à améliorer les choses, car ils réduisent les occasions de se tromper, rendent ces occasions plus visibles et émettent même des avertissements.
Le problème des tableaux de dépendances se résout très facilement avec les règles
react-hookd’eslint.Utiliser fast-check pour tester les props aide énormément à prévenir les bugs lors de petits changements.
La communauté JavaScript pourrait sans doute arrêter d’innover pendant quelques années.
Il y a eu trop d’innovation, avec trop peu de substance.
C’est maintenant au navigateur de prendre en charge un développement de composants raisonnable pour le web.
Si le navigateur proposait directement des combobox avec support backend ou un sélecteur de date standard, on n’aurait pas à réinventer sans cesse la gestion d’état de ces contrôles UI de base.
Je pense aussi que le problème, c’est que le navigateur ne remplit plus vraiment son rôle d’origine.
Google exerce via Chrome une influence presque monopolistique, si bien que, hors des sujets qui intéressent Google et auxquels il alloue des ressources, les standards du web n’avancent pas beaucoup.
Safari et Firefox rééquilibrent un peu, mais pour évoluer en véritable plateforme différenciée, il faudrait que quelqu’un prenne le leadership et pousse dans ce sens.
Au final, faute de support au niveau de la plateforme, l’écosystème JS en est réduit à bricoler encore et encore, comme si on ressoudait des puces NAND, ce qui est assez triste.
J’ai l’impression que les navigateurs récents et CSS ont régulièrement amélioré ou résolu des cas d’usage qui dépendaient traditionnellement de JS.
Il serait souhaitable que ce mouvement continue de s’amplifier.
On pourrait même envisager de diviser les navigateurs en 5 ou 6 catégories, comme shopping, banque, social, etc.
Ainsi, les services se concurrenceraient uniquement sur l’innovation backend, tandis que le frontend offrirait une expérience unifiée, ce qui serait meilleur pour les utilisateurs.
Que chaque entreprise redéveloppe sans cesse le même frontend est un gaspillage énorme.
Un marchand de sandwichs devrait rivaliser pour faire de meilleurs sandwichs, pas pour récupérer 8 % d’utilisateurs installant son app en recréant un frontend similaire.
En fait, quand on voit ce que les frameworks ont réussi à accomplir sur une plateforme aussi complexe que HTML/CSS/JS, c’est déjà impressionnant.
Le « web » était une structure adaptée aux documents, au texte et à des formulaires simples, pas du tout une bonne base pour des applications interactives complexes.
Un jour ou l’autre, tout cela devra être entièrement repensé.
React n’a pas gagné parce qu’il est « le meilleur », mais parce qu’il est devenu le « choix sûr par défaut ».
Tout le monde connaît React, c’est facile de recruter, l’écosystème est vaste, donc c’est rassurant.
Résultat, il y a moins d’innovation, et on n’essaie même plus des alternatives plus légères comme Svelte ou Solid.
React fonctionne toujours bien, mais je pense qu’en pratique il est souvent utilisé davantage par inertie que par réelle adéquation.
Je partage l’avis de l’auteur. Cela dit, l’inertie qui pousse à utiliser React n’est pas aussi erronée qu’on le dit. Si des alternatives comme Svelte sont l’iPhone 17, alors React est à peu près un iPhone 15 ou 16. Au vu du rapport coût/bénéfice, ça reste encore tout à fait utilisable et on ne ressent pas forcément le besoin de changer. Si, pendant la grande période de confusion du front-end, nous avons choisi React, ce n’était pas, contrairement à ce que dit l’auteur, une décision vraiment consciente. C’est plutôt qu’en essayant diverses solutions, React nous a semblé la plus exploitable, et c’est ainsi qu’il a été choisi. À l’avenir, si React devient plus contraignant et qu’autre chose paraît plus pertinent, je pense qu’une transition naturelle se produira, sans qu’il soit nécessaire de se lancer délibérément dans des défis ou des expérimentations.
Comme l’illustre l’exemple de la guerre des standards des cassettes vidéo entre le VHS et le Betamax, ce n’est pas parce qu’une technologie est techniquement supérieure qu’elle sera forcément choisie par le marché.
Le problème du front-end, ce n’est pas qu’il innove de façon excessive plus que nécessaire ?
Je suis plutôt d’accord dans une certaine mesure.
Comme, côté backend, le fait qu’un framework comme Spring Boot soit devenu un standard — au point d’aboutir jusqu’au framework e-gouvernement — apporte clairement des gains de productivité, je me dis que React est peut-être en train d’évoluer de la même manière.
Oui, je pense que l’apport de React a été d’établir une conception basée sur les composants et un comportement de rendu qu’une assez large majorité comprend. Cela dit, React est en soi un framework de bas niveau pour créer des applications web, donc j’aurais aimé qu’il fournisse au moins un routeur et des formulaires par défaut, et je me demande aussi ce que cela aurait donné si, pour le state et les effects, la comparaison profonde avait été prise en charge par défaut et si l’on avait pu écrire la logique uniquement avec des structures et des fonctions. À cause des limites de la comparaison superficielle en JavaScript, on finit par écrire des classes avec la syntaxe des hooks personnalisés.
Ce n’est pas vraiment du bas niveau… Pour implémenter un formulaire, on pourrait s’en sortir en utilisant simplement les balises
inputHTML, mais avec le state, le JSX, les composants contrôlés/non contrôlés, il faut apprendre beaucoup de choses inutiles et générer beaucoup de code, donc j’imagine que c’est peut-être ce qui a motivé l’auteur de l’article.Je suis d'accord.