Maison > Article > interface Web > React Fatigue : pourquoi certains développeurs passent à autre chose
Ne vous méprenez pas, j'adore React. J'ai commencé à l'apprendre en 2021, lorsque les hooks faisaient fureur et que React était à la hausse. Comparés au passe-partout Java que j'ai dû apprendre à l'université, JavaScript et React me semblaient rafraîchissants. J'ai plongé dans le chemin frontend de Scrimba pour React, où la création de mini-projets était à la fois amusante et informative. Issu d'une formation UI/UX, j'ai également adoré les interfaces utilisateur épurées que je pouvais créer à l'aide des bibliothèques de conception de React.
Mais récemment, l’attrait de React semble s’atténuer. Les discussions autour de ces enjeux se multiplient, ce qui peut expliquer pourquoi certains grands noms de la technologie se retirent. Alors, que se passe-t-il avec React ?
React a ses atouts, en particulier dans les projets complexes nécessitant une gestion avancée de l'état, mais ces atouts s'accompagnent souvent du compromis d'un JavaScript lourd côté client. Dans les applications plus simples ou exigeantes en performances, cela peut créer des expériences utilisateur lentes, ce qui constitue un gros inconvénient pour les entreprises qui privilégient la vitesse.
Certaines critiques récentes, bien résumées dans un article sur Picallilli, soulignent à quel point React est profondément ancré, ce qui le rend difficile à remplacer malgré les réactions négatives. L’auteur souligne que même si les frameworks alternatifs se multiplient, React dispose d’une énorme base de code existante qui le maintiendra pertinent pendant longtemps. De plus, l'engagement de React à évoluer, comme l'ajout de la prise en charge d'éléments personnalisés (composants Web) dans la version 19, pourrait faciliter les migrations et la flexibilité.
Les développeurs ne sont pas les seuls à remettre en question React : les entreprises agissent en conséquence.
Netflix a annoncé son passage à Vanilla JS pour certains projets, Microsoft opte pour des composants Web dans Edge, Shopify s'éloigne de React sur certains projets, Airbnb se tourne vers des frameworks spécifiques au système d'exploitation pour les applications mobiles au lieu de React Native, et Kelly Sutton de Gusto passe à StimulusJS.
La tendance vers des solutions indépendantes du framework se développe, les entreprises se concentrant davantage sur les performances, la flexibilité et évitant le poids que React apporte souvent.
Les mises à jour régulières et les versions de fonctionnalités de React peuvent être à la fois une bénédiction et une malédiction. Un article récent affirmait que l’évolution rapide de React signifiait que les entreprises devaient presque réécrire leurs applications tous les 2,5 ans, ce qui est difficile. Les équipes qui ne mettent pas à jour fréquemment risquent d’accumuler des dettes technologiques, et les nouveaux développeurs finissent par gérer les transitions de versions comme React 17 à 19, ce qui peut être frustrant.
Tout ce débat m'a même amené à reconsidérer ma propre pile technologique pour un nouveau site de blog que je souhaite créer. Mon site de portfolio initial a été construit avec React et déployé sur Vercel, mais cette fois, j'ai exploré des options comme Next.js, Gatsby, Astro et Hugo. Puisque le référencement est une priorité pour le blog, je l'ai limité à Gatsby et Hugo. J'ai lu des articles sur la simplicité de Hugo et Go : certains développeurs affirment que les nouveaux utilisateurs peuvent écrire du code Go solide en une semaine, tandis que React a souvent l'impression qu'il a besoin d'un doctorat pour suivre les nouveaux hooks et fonctionnalités. Donc, je pars avec Hugo, et je pourrais peut-être récupérer du Go en cours de route. Mais ne vous inquiétez pas, je n'abandonne pas React !
En fin de compte, le choix technologique dépend du projet et de l’expertise de l’équipe. React reste fort dans les domaines nécessitant une gestion étatique sophistiquée et une interactivité riche. Cependant, pour les projets plus petits ou plus simples, il est difficile d’ignorer l’attrait des alternatives plus légères et plus flexibles.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!