Y a-t-il vraiment des gens qui aiment React ?

 (jsx.lol)
1 points par GN⁺ 4 시간 전 | 2 commentaires | Partager sur WhatsApp
  • Une collection de ressources curatoriales rassemblant des textes critiques sur React et les outils de son écosystème, organisée sous forme de citations issues de divers développeurs et blogueurs
  • De nombreux articles pointent les limites structurelles de React, notamment la dégradation des performances, l’augmentation de la complexité et les problèmes d’hydratation
  • Le choix technologique centré sur React se serait imposé davantage par inertie et par effet de réseau que par adéquation technique, au point que l’hypothèse selon laquelle « tout le monde connaît React » passerait avant les décisions d’architecture
  • Les inquiétudes autour de la sécurité et de la gouvernance de React Server Components et de Next.js se sont accrues, et CVE-2025-55182 a été divulguée comme une vulnérabilité d’exécution de code à distance non authentifiée notée CVSS 10.0
  • La confusion dans la conception des API, la crise de qualité et la complexité de l’écosystème React compliquent la maintenance à long terme et l’apprentissage, alimentant les débats sur l’orientation de React, des Hooks aux fonctionnalités UI modernes en passant par le rythme des releases

Présentation du site

  • Un site de curation qui pose la question provocatrice : « Does anybody actually like React? »
  • Une collection cherry-picked d’articles critiques sur React et les outils influencés par React
  • Propose un abonnement RSS

Critiques fondamentales de React lui-même

Problèmes de sécurité et de gouvernance

Problèmes de conception d’API et de courbe d’apprentissage

  • Is it Time to Regulate React?

    • L’échec central de React est aggravé par une conception d’API confuse
    • La documentation manque de clarté, et les débats sur la bonne manière de l’utiliser n’en finissent pas

  • I don't have time to learn React

    • Contrairement à l’idée selon laquelle React enseignerait l’UI moderne, il en couvre en réalité très peu
    • autofocus est cassé, et les custom elements ne fonctionnent pas hors versions expérimentales
    • Pour utiliser des fonctions modernes comme dialog ou popover, il faut recourir à useEffect
    • À cause du système de synthetic events, on apprend à peine le véritable fonctionnement du DOM
    • Ce n’est pas une UI moderne, mais une UI au niveau de 2013

  • The React Blog Post: Reflections and Reactions

    • Il est étrange de balayer tous les problèmes comme de simples « skill issues » et d’affirmer qu’ils se règlent avec des bibliothèques externes
    • Une technologie devrait permettre de reprendre le travail même après trois ans d’absence, mais ce n’est pas le cas du front-end, et en particulier de React

  • React, where are you going?

    • Deux problèmes rendent React moins agréable aujourd’hui : ownership et complexity
    • Inquiétude que les nouveaux développeurs puissent être intimidés par React

Problèmes de performance et d’expérience utilisateur

  • Why use React?

    • On se retrouve fondamentalement prisonnier du tristement célèbre schéma d’hydratation
    • Une structure où tout le calcul est fait côté serveur en JavaScript, où le HTML est envoyé immédiatement, puis où le même JavaScript est renvoyé côté client

  • How React 19 (Almost) Made the Internet Slower

    • Après une levée de boucliers publique et des débats virulents, l’équipe React a suspendu le changement

  • An even faster Microsoft Edge

    • Passage de React à une architecture moderne Web Components + HTML-first
    • Avec des bénéfices particulièrement importants pour les utilisateurs sur matériel peu puissant

  • Switching costs

    • Souhait de voir davantage de plaintes sur l’expérience utilisateur terrible imposée par React côté client
    • Mais en réalité, les critiques se concentrent presque uniquement sur l’expérience développeur

  • Pivoting From React to Native DOM APIs: A Real World Example

    • Une équipe de développement est passée du « VDOM écrasant » de React aux API DOM modernes
    • Avec une amélioration immédiate de la vitesse et des interactions

Problèmes mobiles et de plateforme

Problèmes d’écosystème et de communauté

  • React Won by Default – And It's Killing Frontend Innovation

    • Quand il faut un nouveau frontend, on ne part plus de « quelles sont les contraintes et quel outil convient », mais de « utilisons React, tout le monde le connaît »
    • Un cycle auto-renforcé où ce sont les effets de réseau, et non l’adéquation technique, qui déterminent l’architecture

  • Conferences, Clarity, and Smokescreens

    • D’après le travail de conseil et les données du secteur, la communauté React traverse une crise de qualité profonde et mesurable
    • Les participants à React Summit n’en entendent pas parler

  • Why Silicon Valley CTOs Are Secretly Moving Away from React

    • Les développeurs React sont nombreux, mais les véritables experts qui comprennent les patterns en profondeur deviennent de plus en plus rares et coûteux
    • Les ingénieurs les plus expérimentés quittent d’autres stacks, épuisés par la complexité

  • Increasingly miffed about the state of React releases

    • Un an et demi s’est écoulé depuis la dernière release de React, plus longtemps que dans n’importe quel cycle de release précédent

Critiques des React Server Components

  • React Server Components: the Good, the Bad, and the Ugly

    • React avait presque complètement cessé d’améliorer le client side (depuis l’arrêt des expérimentations en 2019)
    • Un framework legacy conçu pour résoudre des problèmes à l’échelle de Facebook avec des ressources à l’échelle de Facebook, inadapté à la plupart des cas d’usage

  • React Server Components are a bad choice (for shipping)

    • Pour livrer vite, il ne faut pas utiliser React Server Components
    • En revanche, c’est utilisable pour l’apprentissage, l’expérimentation ou la création de contenu

Retour aux fondamentaux et mise en avant des alternatives

Cas de migration et de transition

  • We Rewrote our React App in Svelte in Three Weeks

    • Il avait jusque-là ignoré les gros titres présentant Svelte comme le framework « le plus aimé », mais rejoint désormais le camp Svelte

  • Moving on from React

    • Après un faux départ avec React en 2023, migration vers une stack mieux adaptée au domaine métier du client

  • Moving on from React, a Year Later

    • Le frontend lourd en JS de l’ère du « fat client » est en train de disparaître
    • Le battage médiatique autour des edge applications est inutile pour construire de nombreux types d’entreprises

  • Replacing React: How Liveview solved our performance problems

    • Exploration de LiveView à cause des problèmes de performance d’une SPA React
    • Conviction acquise après deux jours d’exploration, puis remplacement de la SPA React par LiveView en quelques semaines

Tendance générale et perspectives

Hooks et paradigmes alternatifs

  • Why Signals Are Better Than React Hooks

    • Les Hooks de React sont difficiles à bien utiliser, et encore plus à utiliser de façon performante
    • Ils sont à l’origine d’une baisse de la qualité du code et des performances dans de nombreuses applications

Critiques métaphoriques

  • What Is React.js?

    • Une vidéo qui compare au christianisme l’étrangeté de ses partisans, leur excès de sérieux et une documentation sans fin

À lire aussi

2 commentaires

 
bichi 2 분 전

React, c’est juste une religion (une secte).
 
GN⁺ 4 시간 전
Avis sur Hacker News

  • Il y a des choses que je n’aime pas dans React. React est un framework pour afficher du HTML interactif à l’écran, pas pour faire de la programmation extraordinairement complexe
    Premièrement, il repose trop sur des concepts et une terminologie compliqués. Comparé à Vue, useEffect correspond à watch et useMemo à computed
    Deuxièmement, cette manière inutilement « intelligente » a déteint au-delà de la terminologie, jusque dans l’écosystème. L’ancien Redux demandait d’écrire beaucoup de code dans plusieurs fichiers juste pour incrémenter un nombre de 1, et on avait l’impression que c’était parce que son auteur aimait les concepts malins d’informatique théorique. À la même époque, avec VueX, il suffisait simplement d’incrémenter ce nombre. Heureusement, l’écosystème React a aujourd’hui davantage d’outils de gestion d’état raisonnables
    Troisièmement, React ne fournit pas d’outils de travail CSS par défaut
    Quatrièmement, React ne s’occupe pas lui-même de l’optimisation. Il faut savoir quand et comment utiliser ou ne pas utiliser useEffect et useMemo, et il existe tout un folklore autour de l’optimisation React. C’est problématique alors même que le rerender est au cœur du modèle. Avec Vue, le framework pousse à utiliser ses propres outils et gère la plupart des optimisations en interne, si bien que je n’ai jamais eu à me dire qu’il fallait optimiser manuellement une app Vue
    Cinquièmement, ce folklore est lui-même un problème. L’API de React et la « bonne manière d’écrire du React » ont trop souvent changé en profondeur, au point qu’il est encore très difficile de distinguer ce qui est toujours vrai de ce qui ne l’est plus
    En résumé, React se concentre trop sur les idées, l’informatique théorique et les abstractions de haut niveau, et pas assez sur le fait de rendre simple l’affichage de HTML interactif à l’écran
    J’utilise beaucoup React, Vue et Svelte, mais avec React je dois constamment me préoccuper de choses que Vue ou Svelte auraient déjà prises en charge. Côté performances, les trois se valent à peu près
    J’avais aussi écrit un billet à ce sujet auparavant : https://www.brachkow.com/notes/what-i-like-in-vue/

  • En tant que personne qui a traversé tous les grands courants de JavaScript depuis environ 16 ans, j’aime React dans un certain sens
    React est le pire framework JavaScript, si l’on exclut tous les autres que nous avons essayés
    Je choisirais React n’importe quand plutôt qu’Angular 1. Je préférerais le MVC lourd d’Angular 1 à l’approche Backbone où il faut tout réassembler soi-même à chaque fois, et la structure MVC minimale de Backbone valait mieux que l’ancien chaos façon soupe de JQuery. À l’époque, j’aurais immédiatement choisi la manipulation du DOM et les ajouts de bibliothèque standard de JQuery plutôt que les API natives
    React a aussi ses compromis, mais on en est arrivé là après avoir longtemps subi d’innombrables alternatives qui ne fonctionnaient pas

    • J’aime bien travailler avec React, et je le choisirais plutôt que ce qui existait avant. En revanche, si mes besoins se limitent à cela, je ne choisirais pas React plutôt que htmx/data-star et le rendu côté serveur, même s’il y a quelques pages un peu plus complexes
    • En revanche, je ne comprends pas pourquoi on choisirait React plutôt que Vue. Ce qui m’a le plus frustré, c’est que Vue finit toujours par se rapprocher de React. La structure d’origine des composants Vue, avec le template HTML, l’état JavaScript et les styles CSS réunis au même endroit, était vraiment excellente. La manière de récupérer des données via une URL à l’intérieur d’un composant était aussi très intuitive
    • D’accord. Je suis passé du HTML cgi-bin écrit à la main à JQuery, puis à Angular v1 et enfin à React, et React est un outil que je prends volontiers en main. Il fait ce dont j’ai besoin
    • Je préfère React à Angular, et Vue à React
    • Je me demande si vous avez essayé Svelte. Je ne vois pas très bien pourquoi quelqu’un pourrait préférer React. À mes yeux, le seul vrai avantage de React, c’est d’être une sorte d’IBM du front-end. On ne se fait pas licencier pour avoir choisi React

  • Bien sûr qu’il y a des gens qui aiment React. Ce n’est pas comme JavaScript qu’on est pratiquement obligé d’utiliser, et personne n’est non plus forcé d’utiliser React ou un autre framework web, pourtant React a gagné. On peut au moins y voir la preuve que beaucoup l’aiment suffisamment plus que la plupart des autres frameworks
    Jusqu’à la fin des années 2010, la plainte récurrente dans le développement web était que tout changeait trop vite et qu’il fallait sans cesse apprendre quelque chose de nouveau, et cette plainte était légitime. Mais maintenant qu’une monoculture React s’est installée au sommet, tout le monde se plaint aussi de ça. On ne peut vraiment jamais gagner

    • Au travail, je n’ai presque jamais pu choisir le framework ou la bibliothèque. Presque tout le temps, je reprenais un projet commencé des années auparavant par quelqu’un d’autre, ou j’étais dans une organisation aux choix très contraints. Personnellement, je ne choisirais pas React
      Si React a gagné, c’est parce qu’il est devenu le choix par défaut et que les gens aiment ce qui leur est familier
    • React a des avantages, mais il tend aussi à être choisi par inertie plus que parce que c’est le meilleur outil pour le travail. Des raisons comme « tout le monde utilise React, donc on maximise le vivier de recrutement et de prestataires » ou « un projet React rend bien sur un CV » jouent aussi
    • Au contraire, on se retrouve souvent forcé d’utiliser React et Next.js. Beaucoup de fournisseurs SaaS ont des partenariats avec Vercel et n’ouvrent des points d’extension que de ce côté-là
      Si on veut utiliser autre chose, il faut implémenter l’intégration soi-même, trouver un projet open source qui l’a déjà fait, ou demander à une IA
      C’est faisable pour un projet perso, mais difficile à imaginer dans un cadre professionnel
    • Je ne comprends pas ce que signifie l’idée que personne n’est forcé d’utiliser React. J’aimerais bien savoir où se trouve ce merveilleux nouveau monde où l’on peut apprendre Lisp, l’utiliser pour tout ce qu’on veut, et où la culture d’entreprise n’a aucune influence sur les choix techniques

  • J’aime React. J’ai aussi essayé sérieusement le camp HTMX/Hotwire.
    Je voulais créer un bouton de retour qui, si l’utilisateur venait de la boîte de réception, utilise l’API du navigateur pour revenir en arrière, et sinon le renvoie vers le lien de la boîte de réception afin de préserver le défilement. Il fallait relier le comportement dans le HTML pour appeler une fonction de retour, puis, dans le contrôleur, déterminer la page précédente avant de renvoyer soit un bouton de retour JavaScript activé, soit un lien en dur. La logique était éparpillée dans 3 fichiers.
    Avec React, le JavaScript dans le composant peut déterminer si la page précédente est la boîte de réception et, selon cette valeur, afficher soit le JSX du bouton de retour, soit un lien. Tout se règle dans un seul fichier. Pour moi, il suffit de modéliser une seule entité conceptuelle, alors qu’avec les autres approches il faut forcer la fonctionnalité à entrer dans 3 entités distinctes.
    Est-ce que c’est plus lent ? Clairement oui. Mais ça me rend heureux. Si vous souffrez dans la base de code React désordonnée de votre entreprise, il faut blâmer vos collègues. Sans React, ce serait sûrement encore pire.

    • C’est pour ça que je déteste les applications React en page unique. On dirait qu’elles trouvent toujours une manière stupide de casser le bouton retour et les boutons de navigation du navigateur.
      À part parfois pour améliorer les formulaires, je préférerai toujours htmx / le rendu côté serveur et le comportement natif.
    • À mon avis, HTMX est préférable uniquement pour ce qui touche à l’état des données. Pour quelque chose comme un bouton de retour intelligent, qui ne dépend pas de l’état d’une ressource, il vaut mieux ne pas le calculer côté backend.
      Dans l’approche htmx recommandée, il suffit de relier un bouton onclick à du JavaScript inline ou, si ça ne plaît pas, d’appeler une fonction comme goBackOrInbox.
      function goBackOrInbox() { if (document.referrer) { const path = new URL(document.referrer).pathname; if (path.startsWith('/inbox')) { history.back(); return; } } window.location.href = '/inbox'; }
      Si vous utilisez souvent ce motif, il suffit de le paramétrer en passant en argument le chemin vers lequel naviguer.
    • J’ai l’impression que la meilleure façon de résoudre le problème du bouton retour, c’est de ne pas trop compliquer les choses et de s’assurer que seules les actions vers lesquelles on veut réellement revenir entrent dans l’historique du navigateur. La formulation même du problème semble crier : « avec une meilleure structure, ce serait un problème qu’on n’aurait même pas besoin de résoudre ».
    • Il y a sûrement des parties complexes ici et là, mais j’ai l’impression qu’on pourrait aussi le faire avec des Web Components.

  • J’ai utilisé du code React pendant longtemps, et maintenant je travaille dans mon entreprise sur un gros projet Vue. Avant, tout le monde disait que Vue était le choix le plus simple et le plus accessible des deux, mais je commence à voir les choses autrement.
    React a cette élégance où les composants ne sont fondamentalement que des fonctions, avec peu de choses autour. Si on met de côté l’écosystème Next.js, c’est ce que j’ai vu de plus élégant dans le développement frontend.
    Vue, en revanche, donne une impression de mélange. On y voit les traces de développeurs backend qui ne voulaient pas vraiment apprendre JavaScript, qui l’ont adopté et encensé, et le résultat ressemble à un mélange maladroit qui ne s’emboîte pas proprement.

    • Je n’ai jamais vraiment compris ce point de vue. Les composants React ne sont pas juste des fonctions, ce sont des fonctions accompagnées d’un contexte injecté de façon quasi magique auquel on accède via les hooks. Ces hooks exigent toutes sortes de garanties, et si on n’y prête pas attention, on obtient des résultats difficiles à déboguer. Je trouve ça très loin de l’élégance.
      J’ai utilisé tous les principaux frameworks, et aujourd’hui je construis une grande application web Angular. Dans Angular, les composants sont exprimés sous forme de classes avec template et styles. Les écouteurs d’événements appellent généralement des méthodes de la classe, et l’état peut être aussi simple que des propriétés de classe. C’est bien plus naturel et il y a beaucoup moins de pièges. Bien sûr, pas zéro.
    • Je me demande depuis combien de temps vous utilisez Vue. J’ai eu une réaction similaire il y a quelques années en découvrant Vue avec un bagage React. Mais aujourd’hui, je préfère Vue à React, et je choisis Vue en priorité aussi bien pour mes projets personnels que professionnels.
      Le ressenti à l’usage est un peu différent. Il y a des choses plus simples avec React et d’autres plus simples avec Vue, mais le fait que Vue utilise des signaux est pour moi un gros avantage.

  • Plus que par React lui-même, je m’intéresse surtout à la question de la meilleure façon d’écrire des interfaces en code
    Je suis fan de React et je l’utilise dans presque toutes les applications web que je crée, mais le problème le plus grand et le plus évident, c’est qu’écrire une UI avec React ne semble pas aussi naturel que d’écrire un outil en ligne de commande en Go ou une application temps réel en Elixir
    Certains langages sont étonnamment naturels et sans friction pour des tâches précises. Mais pour l’UI, personne n’a encore vraiment résolu le problème. Swift, JSX/HTML, Svelte, ou n’importe quel framework populaire du genre donnent tous l’impression de contourner partiellement le problème. On dirait qu’à un moment donné, les concepteurs du langage ou du framework ont dû introduire un compromis syntaxique un peu sale, bizarre ou pénible pour satisfaire les exigences
    L’interface naturelle de l’UI étant visuelle, des outils comme Figma peuvent constituer une partie importante de la solution. Malgré tout, il manque encore quelque chose. Il devrait exister une façon plus intuitive d’exprimer du visuel en code. Les solutions actuelles sont difficiles à critiquer précisément, mais elles semblent toujours un peu insuffisantes quelque part

    • Je ressens un peu la même chose. Quand React est sorti, ça m’a semblé parfait par rapport aux alternatives de l’époque, donc j’ai vraiment adoré
      Même aujourd’hui, je préfère React à presque tout, y compris Svelte, Vue et Solid. Mais récemment, j’ai commencé à utiliser Crank(https://crank.js.org/), et ça me semble un pas de plus dans la direction que j’aimerais voir. Cela dit, jusqu’ici je ne l’ai utilisé que sur des projets jouets, donc il est difficile de dire à quel point ça passe à l’échelle, à la fois côté performances et expérience développeur
    • Je suis tout à fait d’accord avec l’idée que « certains langages sont étonnamment naturels et sans friction pour des tâches précises, mais personne n’a encore vraiment résolu l’UI ». Quand on lit des livres[1] du début des années 90 qui abordaient déjà ce problème, on voit que cela s’applique encore aujourd’hui
      La meilleure analyse que j’aie vue jusqu’ici se trouve dans l’article de Chatty, « Programs = Data + Algorithms + Architecture: consequences for interactive software engineering »[2]. C’est un peu difficile à lire, mais ça en vaut largement la peine
      En résumé, le problème, c’est l’architecture, et plus précisément le décalage entre langage et architecture. Le style architectural d’appel/retour induit par les langages de programmation « généralistes » ne correspond pas à l’architecture dont les interfaces utilisateur ont besoin, et entre même en conflit avec elle
      J’ai aussi écrit sur ce sujet dans « Can Programmers Escape the Gentle Tyranny of call/return? »
      L’approche actuelle consiste d’abord à créer Objective-Smalltalk[4], un langage de programmation qui permet d’exprimer facilement des styles architecturaux alternatifs
      Avec ça, je construis actuellement un framework UI appelé interscript, qui inclut aussi HTMXNative et plusieurs composants annexes
      Cela semble plutôt bien fonctionner
      [1] Par exemple : Myers et al., « Languages for developing user interfaces » https://api.taylorfrancis.com/content/books/mono/download?id...
      [2] https://opendl.ifip-tc6.org/db/conf/ehci/ehci2007/Chatty07.p...
      [3] https://2020.programming-conference.org/details/salon-2020-p...
      [4] https://objective.st
    • En tant qu’ingénieur, il est facile de regarder chaque problème en se disant : « il existe une solution parfaite, on ne l’a simplement pas encore trouvée »
      Mais avec le temps, on finit par accepter des réponses moins idéalistes. Peut-être qu’une telle solution n’existe pas. L’espace du problème est peut-être trop complexe pour qu’il existe une solution générale humainement praticable couvrant toutes les formes possibles. S’il y a bien un domaine où cela pourrait être vrai, c’est sans doute l’UI

  • Oui. React est de loin l’interface la plus intuitive, réussissant à combiner les styles déclaratif et impératif. À mon avis, il n’existe rien d’approchant JSX parmi les frameworks UI, tous langages confondus

    • Flutter, SwiftUI, Jetpack Compose et beaucoup d’autres plateformes ont implémenté React comme modèle pour leurs propres frameworks UI
    • Si c’est si intuitif, je ne comprends pas pourquoi presque toutes les applications React contiennent des bugs de performance

  • J’aime vraiment beaucoup Svelte, et j’utilise SvelteKit pour les applications plus complexes
    Dans beaucoup de cas où j’aurais utilisé React auparavant, j’ai trouvé que c’était une bien meilleure évolution
    Svelte me semble aussi bien plus facile à apprendre pour quelqu’un qui connaît les bases du développement web, de HTML, CSS et JavaScript. Pourtant, on voit souvent aujourd’hui des gens commencer le développement web directement avec React, et j’ai l’impression que l’ordre est un peu inversé
    Personnellement, je crée des applications mobiles avec SvelteKit + Capacitor, et j’ai décrit la configuration ici : https://bryanhogan.com/blog/web-to-app-sveltekit-capacitor
    Pour les simples landing pages, je préfère Astro

    • Moi aussi, je commence toujours par prendre Svelte + SvelteKit. Utiliser Kit pour une application simple peut être excessif, mais c’est agréable de l’avoir sous la main quand ça devient plus complexe que prévu
      Je suis d’accord avec l’idée que commencer le développement web avec React donne l’impression de prendre les choses à l’envers aujourd’hui. Svelte évite bien ce problème en traitant HTML comme sa langue maternelle. En commençant le développement web avec Svelte(Kit), on a de fortes chances d’apprendre davantage les fondamentaux qu’en commençant avec React
    • Pour moi, la combinaison Svelte + Astro est idéale. C’est excellent pour les sites de documentation et les pages avec de l’interactivité facultative

  • Je suis biaisé parce que j’ai fait partie des personnes qui ont contribué à rendre React possible, mais j’aime vraiment React. Avant, j’essayais toutes sortes de choses pour corriger les problèmes que je rencontrais côté frontend. Mais après l’arrivée de React, ce besoin a disparu, et j’ai enfin pu me concentrer simplement sur le fait de construire

  • L’une des présentations que j’ai le plus appréciées est https://www.youtube.com/watch?v=h9SDuTSy7ps. D’après mon expérience, l’architecture de React est vraiment bonne et convient assez bien à la création de grandes applications
    Malheureusement, le plus gros problème de React est qu’il vous force à entrer dans l’écosystème JS/TS. Pour moi, JavaScript/TypeScript est sans aucun doute plus proche d’une cible de compilation que d’un système que j’ai envie de manipuler directement
    Je suis satisfait d’Elm. La communauté est vraiment petite et il faut parfois créer soi-même ses bibliothèques. Le TEA paraît parfois peu naturel quand on vient de React, mais j’aime toujours travailler avec Elm parce que je n’ai pas à me soucier d’états implicites et imprévisibles comme useEffect
    En plus, Claude semble mieux tenir le coup avec Elm qu’avec React, au moins dans les grosses codebases effrayantes

    • D’après mon expérience, Elm est en pratique mort. Mieux vaut utiliser React et TypeScript, qui ont des bibliothèques toujours fonctionnelles. Il y a aussi eu des tentatives pour permettre de compiler TypeScript en natif
    • J’aime bien le TEA, mais je n’ai jamais complètement compris comment il passe à l’échelle dans une app avec des composants réutilisables ou des pages suffisamment complexes. Je me demande s’il existe une manière consensuelle de gérer cela
      L’état semble être un grand tabou, donc ça donne aussi une impression de contradiction. Je me demande si cela signifie qu’au final, toute app Elm devient une app React + Redux globale sans effets. J’aimerais en savoir plus sur ce qui rend Elm agréable et sur la manière dont on y travaille. Des liens me conviennent aussi