Si ce n’est pas React, qu’utiliser ?
(infrequently.org)> « Le frameworkisme ne fonctionne plus. La réponse n’est pas un autre outil, mais le courage de faire de l’ingénierie »
- Au cours des dix dernières années, plus de 100 projets ont été menés à travers divers produits et stacks techniques pour le web desktop et mobile
- Une grande partie du temps a été consacrée à résoudre des problèmes de performance et d’accessibilité causés par des frameworks front-end comme React, plutôt qu’à améliorer les Web API
- React est déjà une technologie legacy, mais continue malgré cela d’être adopté dans de nouveaux projets
- Certains affirment que React est « moderne », mais cela revient seulement à répéter les méthodes du passé
Règle de complexité minimale côté client
- Le code côté serveur peut être contrôlé par les développeurs, ce qui permet de gérer efficacement les performances et la disponibilité
- Le code côté client s’exécute dans une grande variété d’environnements hors du contrôle des développeurs, ce qui rend difficile la garantie de stabilité et de performances
- La meilleure stratégie consiste à réduire la quantité de code envoyée au client
- Prioriser HTML et CSS afin de minimiser la dépendance à JavaScript
- React et les frameworks similaires entraînent des duplications de code inutiles et des baisses de performance
Alors, quelles alternatives ?
Une discussion qui se divise en deux questions
- Question étroite : « S’il faut faire du rendu côté client, quelle technologie peut remplacer React ? »
- Il vaut la peine d’envisager des frameworks modernes (par ex. Svelte, Lit, FAST, Solid, Qwik, Marko, HTMX, Vue, Stencil, etc.)
- Cela dit, même avec ces frameworks, il faut gérer strictement la payload côté client et la complexité. JavaScript coûte au moins 3 fois plus que HTML/CSS
- Question large : « Comment réévaluer entièrement une stack technique dépendante de React ? »
- Il ne s’agit pas simplement de remplacer par un nouvel outil, mais de comprendre les objectifs et les limites de l’architecture existante puis de la redessiner
Approche de la question étroite
- Créer plusieurs petits PoC (Proof of Concept) pour évaluer la scalabilité des performances et les limites
- Ces expérimentations objectives offrent aux équipes une expérience d’ingénierie réellement utile
Situation typique des équipes qui posent la question large
- Elles se sentent souvent perdues dans les discussions sur le remplacement de React
- Le plus souvent, les décisions ont été prises en suivant l’architecture existante
- Absence de compréhension claire de l’expérience utilisateur et de prise de décision fondée sur les données
Différence entre frameworkisme et approche centrée utilisateur
- Frameworkisme : croire qu’ajouter toujours plus de fonctionnalités au framework résoudra tous les problèmes
- En pratique, cela ne résout souvent pas les problèmes des utilisateurs
- Cela ignore les patterns atypiques et les preuves fondées sur les données
- Réalisme : mesurer l’expérience utilisateur et prendre des décisions fondées sur des données réelles
- Comprendre les besoins et les contraintes des utilisateurs, puis concevoir la stack technique sur cette base
- Le point de départ, ce sont toujours les besoins des utilisateurs
Comment introduire le réalisme
- Exploiter les données RUM : utiliser des métriques de performance centrées utilisateur comme les Core Web Vitals
- Tests de performance : utiliser des outils comme WebPageTest (WPT) pour mesurer les parcours utilisateurs critiques (critical user journeys)
- Relier objectifs business et expérience utilisateur : évaluer, à partir des données, les axes d’amélioration et le retour sur investissement
Pourquoi l’approche fondée sur les données est importante
- Au lieu d’adopter un framework sur la base de la confiance, vérifier son efficacité avec des données
- Comparer le coût réel et l’effet réel de l’adoption technologique dictée par la mode
- Encourager des choix techniques axés sur l’optimisation mesurable de l’expérience utilisateur
Rien de ce qui a de la valeur n’a été perdu
L’effet de politiques qui freinent la diffusion de React
- Interdire React et d’autres approches centrées sur les frameworks contribue à réduire les coûts et à recentrer les équipes sur l’utilisateur
- Mais sans écarter complètement le frameworkisme, il reste difficile d’obtenir des gains de fond
- Même si l’on évite une erreur, l’effet reste limité si l’on investit dans d’autres erreurs de la même catégorie
Solutions générales au problème large
Centré utilisateur
- Les décideurs doivent être directement responsables des conséquences de leurs choix d’ingénierie
- Sans excuses possibles, si le système ne fonctionne pas bien pour les utilisateurs (en particulier les utilisateurs marginalisés), il faut introduire une version alternative
- Il n’existe que des problèmes à résoudre ; il faut exclure toute « sanctuarisation » des approches existantes
Approche fondée sur les preuves
- Il faut un engagement commun en faveur du réalisme entre management et ingénierie
- Dans la prise de décision, les meilleures preuves doivent toujours l’emporter
Garde-fous
- Des politiques sont nécessaires pour empêcher les promesses illusoires du frameworkisme
- Exemple : les exigences techniques de progressive enhancement du Government Digital Service britannique
- Les politiques peuvent être ajustées selon le contexte de l’organisation (par ex. créer un circuit d’escalade pour les exceptions)
- Mais l’essentiel est de fixer des critères clairs. Une politique fondée sur les preuves a un impact puissant
Évaluation comparative des technologies
- Ne pas déployer un nouveau système sans parcours utilisateurs critiques (critical user journeys) clairement définis
- Les parcours utilisateurs critiques représentent les tâches que les utilisateurs effectuent le plus souvent dans le système
- Sur cette base, mener des comparatifs (bakeoffs) pour tester les performances de chaque technologie sous contraintes
- Les product managers ne doivent pas se contenter de proposer des expérimentations : ils doivent définir une hypothèse produit claire et les critères de succès
- Cela peut être inconfortable, mais c’est un rôle clé du product manager
- Le départ des PM qui jugent cela incompatible avec leur travail est un coût acceptable
Études de cas
Comprendre la différence entre réalisme et frameworkisme à travers des cas concrets
- Critères de choix technologique
- Le choix technologique est évalué selon le nombre de mises à jour de données importantes et la durée des sessions
- Certaines catégories d’applications se caractérisent par des sessions longues et des mises à jour fréquentes des données
- Dans ce cas, un modèle de données local peut être pertinent
- Mais cela relève de cas rares et exceptionnels
- Dans le cas de sessions courtes
- Les sites dont la durée moyenne de session est courte doivent minimiser le volume initial de JavaScript chargé
- La plupart des sites n’ont pas besoin d’une architecture SPA
- Lorsqu’une architecture SPA est nécessaire
- Une architecture SPA ne doit être envisagée que si certaines conditions sont réunies
- Sessions longues et multiples mises à jour des mêmes données
- Les sites qui ne remplissent pas ces conditions ne devraient pas adopter une SPA
- Une architecture SPA ne doit être envisagée que si certaines conditions sont réunies
- La question essentielle
- Le choix ne se situe pas entre frameworks JavaScript
- Dans la plupart des cas, l’essentiel est de déterminer s’il est pertinent d’utiliser des outils orientés SPA
- Pour la majorité des sites, la réponse est clairement « non »
Sites web informationnels (Informational)
- Structure optimale : HTML sémantique et, si nécessaire, progressive enhancement
- Les générateurs de sites statiques (Hugo, Astro, 11ty, Jekyll) conviennent bien
- Pour les contenus fréquemment mis à jour, utiliser des outils CMS comme WordPress
- Les blogs, sites marketing, sites d’entreprise et sites d’information publique doivent réduire au maximum la payload JavaScript côté client
- Il ne faut pas utiliser de frameworks conçus pour les architectures SPA
- Pourquoi le balisage sémantique et la progressive enhancement sont adaptés
- Caractéristiques : sessions courtes et modèle de données détenu par le serveur
- La source des données affichées sur la page est toujours gérée côté serveur
- Aucune abstraction de modèle de données côté client ni définition de composants n’est nécessaire
- Configuration CMS :
- Un éditeur à faible trafic mais forte interaction pour les auteurs
- Une interface de consultation à fort trafic mais faible interaction pour les lecteurs
- Caractéristiques : sessions courtes et modèle de données détenu par le serveur
E-commerce
- Architecture recommandée : HTML sémantique généré côté serveur et progressive enhancement
- L’écart de performance entre Amazon et ses concurrents basés sur React est net
- Plus de 70 % du trafic de Walmart vient du mobile, et une SPA basée sur Next.js a un impact négatif sur le business
- Pourquoi la progressive enhancement est adaptée
- Structure générale de l’e-commerce :
- Page d’atterrissage avec produits disponibles et fonctions de recherche
- Pages de résultats avec filtres et comparaison
- Pages produit avec médias, avis et alternatives recommandées
- Écrans de gestion du panier, paiement et compte
- État détenu par le serveur :
- Maintien d’un contenu frais (par ex. les prix)
- Réduction de la latence grâce à l’optimisation de pages légères
- Usage de stratégies de cache agressives, d’optimisation d’images et de réduction de taille des pages
- Structure générale de l’e-commerce :
Sites orientés consommation média (Media)
- Structure de base : conception fondée sur la progressive enhancement
- Ajouter de la complexité selon l’évolution du produit si nécessaire
- Pourquoi la progressive enhancement et l’architecture en îlots (Islands) conviennent
- Des éléments interactifs comme les fils de commentaires peuvent être construits comme des modèles de données indépendants
- Ils peuvent être implémentés dans une page statique au moyen de Web Components
- Quand une SPA est adaptée
- Persistance de la lecture média :
- Nécessité de conserver un mini-player pendant la navigation entre pages
- Utiliser une technologie SPA tout en maîtrisant la taille du JS client
- Support de la lecture hors ligne :
- Besoin d’une logique pour gérer un cache média local
- Envisager des systèmes de synchronisation de données comme Zero ou Y.js
- Persistance de la lecture média :
Réseaux sociaux (Social)
- Modèle hybride : peu d’interactions sur un modèle de données détenu par le serveur + mises à jour média intermittentes
- Pourquoi la progressive enhancement convient
- Interactions courantes :
- Clics sur « j’aime », mises à jour occasionnelles, etc.
- Une approche hybride avec Hotwire ou HTMX est adaptée
- Interactions courantes :
- Quand une SPA est adaptée
- Îlots d’interaction profonde :
- Exploiter le cache client pour des usages comme l’enregistrement de brouillons de posts
- Support hors ligne :
- Livrer d’abord le HTML, puis implémenter la synchronisation et la logique hors ligne via un Service Worker
- Îlots d’interaction profonde :
Applications de productivité (Productivity)
- Les applications de productivité centrées sur les documents ont des exigences complexes (édition collaborative, support hors ligne, mode de consultation léger)
- Un modèle de données local et une architecture orientée SPA peuvent être adaptés
- Pourquoi une SPA peut convenir
- Mises à jour fréquentes des données :
- Pour des actions comme la saisie clavier ou le glisser-déposer à la souris, la logique côté client prend l’avantage
- Nécessité de maîtriser les contraintes de performance :
- Gestion de la taille du bundle initial
- Mise en place de stratégies de chargement différé des packages
- Mises à jour fréquentes des données :
Autres classes d’applications (Other Application Classes)
- Exigences spécifiques :
- 3D CAD, éditeurs de programmation, game streaming, jeux web, montage média, systèmes de production musicale, etc.
- Chaque catégorie doit être évaluée avec le même soin que les applications de productivité
- Conditions de succès :
- Définir les parcours utilisateurs critiques
- Analyser la profondeur moyenne des sessions
- Définir des indicateurs de garantie de performance
- Maîtriser les scripts et ressources essentiels
Un mot sur les logiciels d’entreprise
- Les « applications métier d’entreprise » provoquent généralement les pires problèmes de performance
- Tableaux de bord, systèmes de workflow, applications de chat d’entreprise, etc.
- La performance est une culture :
- Échec à définir et mesurer le temps de chargement initial ainsi que la performance après interaction
- Une culture centrée sur les développeurs qui ignore les utilisateurs devient toxique
« Mais… »
- Les managers attachés à un framework particulier, React compris, déroulent souvent toutes sortes de justifications pour défendre ce choix
- Mais ces discussions ne placent pas l’expérience utilisateur au centre, et ce manque revient sans cesse.
« ...nous devons aller vite »
- Question : « Et selon vous, combien de temps cela va durer ? »
- Les projets basés sur NPM développés rapidement entraînent des problèmes d’accessibilité, de faibles performances et une hausse de la complexité, ce qui finit par ralentir l’exécution.
- Coût de remédiation : résoudre les problèmes JavaScript prend des mois, et le rythme de livraison des fonctionnalités ralentit encore davantage.
- Pour atteindre le Product-Market Fit, il faut prioriser l’accessibilité et la qualité.
- Choisir React pour « aller vite » coûte en réalité plus cher à long terme et freine la croissance.
« ...ça marche bien chez Facebook »
- La plupart des entreprises ne font pas face aux mêmes problèmes que Facebook.
- Facebook subit lui aussi des problèmes de performance liés à React, mais sa position dominante masque ces effets.
- Les entreprises ordinaires ne doivent pas copier aveuglément l’exemple de Facebook.
« ...notre équipe connaît déjà React »
- Un développeur React est un développeur web. CSS, HTML, JavaScript et le travail sur le DOM sont indispensables.
- React est la couche la plus simple et la plus remplaçable de la stack technique.
- Il n’existe pas de barrière majeure à l’apprentissage de frameworks plus petits et plus rapides comme Preact, Svelte, Lit ou FAST.
« ...il faut que le recrutement soit facile »
- Le secteur IT offre aujourd’hui une excellente opportunité de recruter de très bons développeurs.
- La connaissance de React ne peut pas être un critère de recrutement suffisant.
- Les développeurs qui connaissent React peuvent généralement apprendre facilement les standards du web.
- Des systèmes plus simples offrent au contraire un meilleur ROI.
« ...tout le monde a des smartphones rapides »
- Avec la hausse de l’usage mobile sur les dix dernières années, l’idée que les ressources client sont bon marché est déjà une hypothèse erronée.
- Les utilisateurs de téléphones peu performants peuvent très bien constituer une part importante de la clientèle.
- Choisir React revient dangereusement à supposer que tous les utilisateurs ont des appareils haut de gamme.
« ...React est un standard du secteur »
- React n’est pas un standard cohérent.
- Les approches propres à React (class components vs function components), l’usage ou non de TypeScript, le choix des outils de gestion d’état, etc., changent d’un projet à l’autre.
- Une stack React est toujours mouvante, et prétendre qu’il s’agit d’un « standard » n’est qu’une fiction confortable.
« ...l’écosystème… »
- Les bibliothèques réellement compatibles uniquement avec React sont très rares, et la plupart des outils fonctionnent aussi avec Preact, etc.
- Tous les packages NPM deviennent de la dette technique pour l’avenir.
- Les dépendances inutiles comme le CSS-in-JS ne font qu’augmenter les coûts.
« ...Next.js est suffisamment rapide »
- Next.js embarque par défaut les problèmes de performance de React.
- Des outils HTML-first (par ex. Astro, 11ty) offrent de meilleures performances que Next.js.
- Il existe aussi un problème de lock-in vers les API de startups financées par le capital-risque.
« ...React Native ! »
- React Native rend les apps mobiles plus lentes et coûte cher à maintenir.
- Utiliser PWA et Capacitor/Cordova est un meilleur choix.
- Facebook lui-même s’éloigne de React Native.
12 commentaires
Les entreprises ordinaires ne devraient pas suivre aveuglément l’exemple de Facebook.
Il est fort probable que les utilisateurs de téléphones peu performants fassent aussi partie des principaux clients du produit.
React Native ralentit les applications mobiles et exige des coûts de maintenance élevés.
Mdr mdr mdr mdr mdr mdr
L’article est beaucoup trop long, au point que son fil directeur se dilue.
L’auteur semble considérer que l’idée de recourir à React relève forcément d’un biais en faveur des frameworks.
Après avoir dit qu’il fallait sortir de cette logique et aborder les choses au cas par cas, il cherche pourtant à élaborer une recette pour toutes les formes de besoins en ingénierie.
On remarque aussi une volonté excessive de monopoliser la discussion en répondant à toutes les objections possibles. Ses contre-arguments aux objections sont beaucoup trop étroits.
Autrement dit, au-delà d’un cas particulier, l’auteur semble très mal armé, tant dans son attitude que dans sa maîtrise du débat, pour mener une discussion générale sur le sujet.
Au final, même si je n’aime pas particulièrement utiliser React, l’attitude unilatérale de l’auteur m’a surtout donné envie d’écouter un peu plus ce qu’ont à dire ceux qui défendent son usage.
À titre personnel, je pense pour l’instant que React reste la meilleure option, donc voici mon avis.
J’ai commencé le développement web à l’époque de php et jQuery, et dans mon entreprise actuelle j’ai travaillé avec AngularJS, Angular, React en style classes puis React en style hooks. De ce point de vue, il est moins pénible de changer de stack technique une fois que les tâtonnements des premiers utilisateurs ont eu lieu et que l’écosystème de bibliothèques est en place. Si on raisonne en versioning sémantique, cela revient à utiliser la version majeure juste en dessous de la toute dernière. Comme les exigences et les fonctionnalités de haut niveau ne changent pas, ce n’est pas vraiment un problème, mais sans documentation ni retours d’expérience sur les technologies de base, la productivité ne suit pas. En plus, compte tenu de la nature des projets dans mon entreprise, contrairement à un service SaaS, le cycle produit est long et il existe des périodes consacrées uniquement à la maintenance, ce qui rend encore plus difficile l’adoption des toutes dernières technologies.
Je pense qu’il faudra sans doute reconsidérer une transition technologique le jour où React basculera vers Next.js, mettra fin au support du SPA et imposera un changement d’architecture. Et si Vue était un peu plus largement adopté, il figurerait évidemment parmi les candidats. Il n’y a aucune raison de ne pas l’utiliser.
Pourquoi recommander Capacitor ou Cordova sous prétexte que RN rendrait les applications mobiles lentes ? Même si seule l’UI paraît native, je pense que c’est une approche bien meilleure en termes de performances qu’une appli web hybride.
Malheureusement, sur le marché du recrutement en Corée, si « l’obsession des frameworks ne passe pas », il y a de très fortes chances que vous soyez éliminé très tôt en entretien. Dans beaucoup d’entretiens, on pose des questions que l’on ne peut connaître qu’après avoir beaucoup utilisé un framework.
Le développeur RN pleure à chaudes larmes
Pour être sérieux, RN a du sens dans la mesure où il permet de gérer des composants natifs via un bundle JS, donc son cas d’usage est complètement différent de celui d’une PWA.
Il y a déjà des aspects difficiles à gérer même avec une WebView, alors une PWA ? À long terme, je pense que ça ira dans cette direction, mais pour l’instant c’est prématuré. J’ai surtout l’impression qu’on fait une comparaison qui n’a pas de sens au départ.
Oui. Le corps de l’article donne presque l’impression qu’il n’y a quasiment pas besoin d’applications natives.
Tant qu’il y aura des gens attirés par la nouveauté, ce genre de débat se répétera. Le fait qu’il existe déjà des systèmes construits avec React signifie que l’on ne peut pas ignorer la question du recrutement en espérant que la réalité changera. Les raisons pour lesquelles Facebook poussait React et celles pour lesquelles, dix ans plus tard, des entreprises classiques choisissent React ne sont pas les mêmes.
Je pense que les discussions visant à changer d’architecture et de paradigme doivent être menées avec plus de prudence et chercher à convaincre le plus grand nombre possible de personnes.
Mais bon,
preactreste dans l’esprit de React, et dès qu’on sort de React, le nombre de bibliothèques...Quand une bibliothèque a l’air valable, elle est presque toujours réservée à React, les développeurs Vue en pleurent.
Je l’utilise bien pourtant, donc j’ai quand même l’impression qu’il y a un certain acharnement injustifié... Écrit de façon aussi interminable, ça donne l’impression qu’on nous pousse à croire qu’on est face à un gros problème.
Avis Hacker News
Je pense que la plupart des raisons invoquées contre React cherchent à résoudre les mauvais problèmes. Les problèmes de performance ne sont pas vraiment majeurs. Dans la plupart des cas, améliorer le backend est plus efficace
Si React et jQuery ont gagné en popularité, c’est parce que le code paraît propre. Les premiers exemples de code AngularJS n’étaient pas agréables à regarder
Le cœur de React, c’est de permettre de rendre de façon fonctionnelle un état d’interface en O(n). Par le passé, gérer des transitions d’état en O(n^2) était complexe
Si l’on continue à utiliser React, c’est parce que c’est une technologie stable et mature, comme Java. La communauté et les ressources sont abondantes
L’article d’Alex montre sa frustration face à un débat qui revient sans cesse. Beaucoup de gens ne lisent pas l’article jusqu’au bout
Dire qu’un développeur React est un développeur web paraît de moins en moins juste. Il y a de plus en plus de développeurs qui ne connaissent que React en SPA et les frameworks de style
La plupart des sites n’ont pas besoin d’une SPA. Mais pour les entreprises qui ont besoin de beaucoup de données, une SPA est avantageuse
Je n’aime pas React. En tant que développeur surtout backend, je préfère du HTML généré côté serveur avec un peu de JavaScript
Si le développement frontend se déplace vers les frameworks JavaScript, c’est à cause du coût de maintenance
Il y a beaucoup de mauvaises critiques de React. Les développeurs React parviennent à faire le travail sans créer un nouveau langage de templates