Pourquoi tout le monde utilise React, mais nous n'avons pas besoin de l'utiliser? - Histoire de la guerre frontend et raison de la naissance de Hotwire
Quand on entend parler de développement web ces jours-ci, on entend toujours la même chose.
"Le front-end doit être fait avec React."
"Tout le monde utilise React ces jours-ci."
"Si vous n'apprenez pas React, vous ne serez pas un bon développeur."
Mais est-ce vraiment vrai?
Non, pour être précis, c'est seulement à moitié vrai.
Il est vrai que React est une bonne bibliothèque.
Cependant, le problème est...
Le "besoin" de React ne représente vraiment que 10 à 20% de l'ensemble des services Web.
Et étonnamment,
La plupart des services créés par les développeurs Rails
ne rentrent pas dans ces 10 à 20%.
1. De nombreux frameworks ont été sacrifiés avant que React ne s'impose
Il y a une chose que les développeurs novices ne savent pas.
React n'était pas le "roi absolu" dès le début.
De nombreux frameworks et bibliothèques qui existaient avant
ont presque tous disparu.
AngularJS (mort)
Ember.js (sur le point de mourir)
Backbone.js (presque disparu)
Knockout.js
ExtJS
Couche frontend de Meteor
jQuery + frameworks SPA
Mithril, Riot, Preact...
L'écosystème frontend a connu
une "guerre" où plus de 100 technologies sont apparues en 10 ans,
dont 98% ont disparu.
La raison pour laquelle React a survécu est grande :
Sa structure était relativement bonne
Sa maintenance était relativement facile
Les entreprises l'ont adopté
Cependant, cela signifie que React finira par disparaître un jour.
Parce que l'essence de la technologie frontend reste toujours la même.
2. React devient de plus en plus lourd et complexe (réalité)
Au début, React était vraiment simple.
"L'interface utilisateur est une fonction de l'état."
Mais qu'en est-il de React aujourd'hui?
React
ReactDOM
JSX
Babel
Webpack
Vite
Next.js
Zustand
Redux
Suspense
Composants côté serveur
hydratation
frontière client/serveur
streaming
routage
bundler
rendu basé sur un compilateur...
Tous ces éléments
sont devenus des "discussions essentielles" dans l'écosystème React.
React n'est plus simplement une bibliothèque.
React est devenu un monde complexe en soi, devenant de plus en plus difficile chaque année.
Quels problèmes cela peut-il poser?
Barrière d'entrée élevée pour les nouveaux développeurs
Difficulté de maintenance si toute l'équipe n'est pas composée d'experts React
Ralentissement considérable au début du projet
La simplicité du serveur est compromise par la complexité du frontend
Et cela soulève cette question :
"Est-ce que mon service a vraiment besoin de React?"
3. La plupart des SaaS et services Web n'ont pas besoin de React
Les situations où React est nécessaire se résument principalement à deux :
Des applications SPA complexes avec des mises à jour d'interface utilisateur en temps réel
(ex: Figma, Slack (Web), Notion, Trello, etc.)Projets très importants nécessitant une collaboration frontend à grande échelle et inter-équipes
Mais qu'en est-il des services créés par les développeurs Rails?
Services CRUD
Tableau de bord
Blog
Communauté
Services axés sur la recherche de données
Services centrés sur les formulaires
Gestion des clients
Outils internes
SaaS
Back-office de commerce électronique
Pour ces services,
la moitié des fonctionnalités de React ne sont pas nécessaires.
De plus, l'utilisation de React
ralentit le développement
et augmente considérablement la complexité.
4. Hotwire est une technologie née de ce contexte
Hotwire est une pile technologique proposée par l'équipe Rails
et repose sur cette philosophie.
"80% du front-end n'a pas besoin d'être aussi complexe que React."
La composition de Hotwire est simple :
Turbo (streaming HTML + mises à jour partielles)
Stimulus (petit moteur JavaScript)
Cable + Streams (temps réel)
Mais l'essentiel est le suivant.
La méthode consistant à mettre à jour directement le HTML est la plus rapide, la plus facile et la plus maintenable pour la plupart des services Web.
Contrairement à React,
il n'y a pas de processus complexe de
état → différence → rendu → hydratation...
Hotwire suit fidèlement la philosophie de Rails :
Simplicité
Productivité
Vitesse de développement
Maintenabilité
Quantité de code réduite
Bonheur des développeurs
Et voici une réalité surprenante :
En réalité, Hotwire est trois fois plus rapide que React,
le volume de code est réduit d'un cinquième,
et les bugs sont considérablement réduits.
5. Pourquoi ne pas utiliser React - Hotwire a déjà résolu cela
Sur les 10 problèmes que React cherchait à résoudre,
Hotwire en résout 7 à 8 en adoptant une approche centrée sur le serveur.
Exemple :
| Problème | Approche React | Approche Hotwire |
|---|---|---|
| Mise à jour de l'interface utilisateur | Calcul de la différence → Rendu | Le serveur envoie simplement des fragments HTML |
| Gestion de l'état | Redux/Zustand | L'état du serveur = L'état de l'interface utilisateur |
| Routage | Routeur frontend | Optimisation de la navigation de page avec Turbo |
| Temps réel | WebSocket + rendu côté client | Mise à jour immédiate de l'HTML avec Turbo Stream |
| SEO | Configuration séparée | Rendu côté serveur à 100% |
| Construction | Babel/Webpack/Vite | Aucun (Pas de construction !) |
| Complexité | Hautement complexe | Faible |
Hotwire améliore considérablement la productivité des développeurs Rails.
6. Et React dans tout ça ? Il finira par disparaître. C'est presque certain.
Parce que l'histoire du frontend est faite de répétitions.
- Au début, une simple bibliothèque d'interface utilisateur → De plus en plus complexe → Devenant compliquée → L'organisation ne peut pas la maintenir → Apparition de nouvelles technologies → Changement de génération
React suit le même chemin.
En fait, les signes avant-coureurs sont déjà là.
Les composants serveur de React sont trop complexes, provoquant une réaction négative des développeurs
Problèmes de performances
Next.js prend le dessus sur les règles de React (le noyau de React n'est plus indépendant)
Apparition de concurrents (Solid, Qwik, Svelte, HTMX, etc.)
Résurgence de la tendance "Pas de construction + Web centré sur le serveur"
Actuellement, les développeurs disent :
"Le web est devenu trop complexe ces jours-ci. Nous avons besoin de simplicité."
Cette tendance a toujours été correcte historiquement.
Mainframe → PC (retour à la simplicité)
SOAP → REST (retour à la simplicité)
Ère de jQuery → React (retour à la simplicité)
SPA compliquées → Hotwire/HTMX (retour à la simplicité)
React finira par disparaître. C'est juste une question de "quand".
Conclusion - Nous choisissons une direction, pas une technologie
Ne pas apprendre React n'est pas le message.
Utilisez React lorsque c'est nécessaire.
Cependant, la plupart des services n'ont pas besoin de React. Lorsque vous utilisez une technologie complexe, le développement ralentit et la maintenance devient difficile.
Rails + Hotwire disent ceci :
"Le web doit rester simple.
Le serveur envoie de l'HTML, le navigateur l'affiche.
Toute complexité doit être ajoutée que lorsque nécessaire."
Cette philosophie
correspond parfaitement à la façon de développer à l'ère de l'IA.
Si vous êtes débutant, Hotwire est une option très convaincante.
Rapide
Simple
Clair
Peu de bugs
État du serveur = État de l'interface utilisateur
Aucun système de construction
Facile à maintenir
Idéal pour les développeurs solo
Et la phrase la plus importante :
Hotwire est une technologie qui durera beaucoup plus longtemps que React. La philosophie de Rails a résisté pendant 20 ans et ne changera pas à l'avenir.