React Paris 2025

Dev, cloud & sécu20–21 mars 2025Paris, New Cap Event Center2e édition

Deux jours de conférence mono-track en anglais (20 et 21 mars 2025), précédés d'une journée de workshops payants le 19 mars et de deux meetups gratuits (18 et 19 mars) ; organisée par BeJS, 18 speakers, MC Tejas Kumar et Sarah Dayan. Replays : playlist YouTube « React Paris 2025 » (https://www.youtube.com/playlist?list=PL53Z0yyYnpWitP8Zv01TSEQmKLvuRh_Dj).

React 19 et les Server Components entrent dans le quotidien : moins de useState et de JavaScript, plus d'URL, de HTML natif et de serveur, sur fond de premiers usages concrets de l'IA dans le front et de rappels insistants sur l'accessibilité à l'approche de l'European Accessibility Act.

18 sessions résumées · 18 vidéos · mise à jour le jeudi 8 octobre 2026 · synthèse à compléter

Sources lues et limites de cette synthèse

Corpus : Programme officiel archivé (Wayback Machine, mars 2025) et 17 transcripts sur 18 talks de la playlist officielle « React Paris 2025 » (chaîne BeJS, vidéos publiées le 25/03/2025), complétés par la description YouTube du talk de Kent C. Dodds, les slides PDF de François Best et une mention dans la newsletter This Week in React #227 (26/03/2025).

Limites : Aucun retour de participant détaillé n'a été trouvé, à part la mention de Sébastien Lorber (This Week in React) : les résumés décrivent ce qui a été dit sur scène (sous-titres automatiques anglais, parfois bruités sur les noms propres), pas la réception par le public. Le talk d'ouverture de Kent C. Dodds n'est résumé que d'après son descriptif. Les cinq workshops du 19 mars et les meetups ne sont pas documentés.

Synthèse globale

Synthèse établie à partir des transcripts des talks (ce qui a été dit sur scène) : aucun retour de participant détaillé n'a été trouvé à ce jour.

1. React 19 en pratique : la chasse au useState

Le jour 1 forme un bloc cohérent, presque une démonstration en trois temps. David Khourshid ouvre avec « Goodbye, useState », François Best enchaîne sur l'état dans l'URL avec nuqs, puis Aurora Scharff reconstruit une app Next.js où il ne reste « no useEffects or useStates » hormis une transition. Le message commun : l'état local n'est qu'un recours parmi d'autres, après l'URL, le serveur, le FormData, les valeurs dérivées et les stores. Les speakers se répondent explicitement : Khourshid renvoie au talk de Best, Scharff termine avec une variante nuqs de sa démo. Le MC conclut la séquence en plaisantant qu'on se fait « bully » pour ses mauvaises pratiques.

2. Le serveur et le réseau, nouveau terrain du front

Kent C. Dodds ouvre l'édition sur l'idée que les Server Components et les Actions font « disparaître » la complexité du réseau (d'après le descriptif, transcript non récupéré). Le thème revient sous des angles très concrets : Aurora Scharff détaille Suspense, use(), useOptimistic et le Partial Prerendering ; Tomas Jansson (Elkjøp) raconte l'abandon de l'edge, trop loin des API, et un TTFB réduit de 40 % en supprimant un proxy CDN. Antoine Chalifour apporte le contrepoint : le modèle loader/action de Remix, élégant au départ, devient coûteux quand les données ne suivent plus les routes, d'où sa migration partielle vers TanStack Query.

3. La plateforme web d'abord, l'accessibilité en ligne de mire

Plusieurs talks plaident pour moins de JavaScript et plus de HTML sémantique. Jemima Abu remplace thème, accordéon et modale par :has(), <details> et popover. Kateryna Porshnieva enchaîne en montrant au lecteur d'écran ce que le natif apporte et ce qu'ARIA promet sans le tenir. Le sujet traverse l'édition : Jean Burellier (Sanofi) rappelle que l'European Accessibility Act s'applique dans trois mois, outils internes compris ; Dominika Zając montre les outils DevTools de contraste et d'arbre d'accessibilité ; Yu Ling Cheng (Pigment) propose d'embarquer l'accessibilité dans les composants du design system pour ne plus la répéter en revue de code.

4. L'IA : du streaming à l'appareil, encore en phase d'exploration

L'IA occupe le début du jour 2, sur un ton expérimental. Tejas Kumar improvise un live coding demandé par le public (streamer du JSON produit par un LLM, NDJSON, Vercel AI SDK, UI générative) et finit sur MCP. Nico Martin fait tourner tout un assistant dans le navigateur (Whisper, Gemma 2, RAG local, Web Bluetooth) et constate que les petits modèles exigent plus de garde-fous. Ailleurs, l'IA apparaît par touches : assistant de DevTools (Zając), LLM nourri de la documentation du design system (Burellier), « vibe state management » de Cursor moqué par Khourshid. Contrairement à l'édition 2026, l'IA reste un sujet parmi d'autres, pas le fil conducteur.

5. Qualité et maintenabilité : outiller plutôt que débattre

Un fil commun relie des talks très différents : remplacer l'avis par un critère. Héla Ben Khalfallah (Ekino) propose des métriques de graphe pour décider du découpage, du code mort et des tests à écrire en priorité. Kate Marshalkina (Aetion) raconte comment un lint Playwright, des tests isolés et des rapports lisibles ont rendu fiable une suite E2E réglementaire, puis déclenché la modernisation du code. Violina Popova applique la même logique au produit avec l'A/B testing. Dominik Dorfmeister livre l'envers du décor côté librairie : prendre son temps avant d'ajouter une API, oser en retirer et tester les bêtas.

6. Le développeur front, acteur du produit et de l'organisation

Deux talks sortent du code. Tomas Jansson explique comment un développeur peut faire financer une réécriture dans un grand groupe : un problème chiffré, des alliés hors de l'équipe, deux mois de preuve plutôt qu'un programme de deux ans. Yu Ling Cheng décrit trois niveaux de collaboration avec design et produit, du « est-ce réaliste ? » à la traduction des contraintes techniques en coûts. Jean Burellier ajoute que les difficultés d'un design system à l'échelle sont surtout communautaires (adoption, feedback, inner source), pas techniques.

7. Vie de l'événement et limites du corpus

Conférence mono-track en anglais, organisée par BeJS au New Cap Event Center, avec Tejas Kumar et Sarah Dayan comme MC, Q&A via Slido et une clôture ludique (renderers React pour terminal, MIDI ou DALL-E par Matias Gonzalez Fernandez). Les vidéos sont publiées quatre jours après l'événement ; Sébastien Lorber (This Week in React) dit avoir assisté au vendredi et salue de « great talks ». Le corpus ne contient aucun retour participant détaillé : on sait ce qui a été dit sur scène, pas ce que le public en a retenu. Les workshops du 19 mars et le talk d'ouverture de Kent C. Dodds ne sont pas documentés sur le fond.

Actions concrètes citées

  1. Réserver useState à l'état interne d'un composant : valeurs dérivées calculées au rendu, useRef pour ce qui ne s'affiche pas, useReducer ou un store pour la logique contrainte (Khourshid).
  2. Mettre dans l'URL tout état partageable (filtres, tri, pagination), avec un parseur typé comme nuqs, en surveillant taille, SEO (URL canonique) et bouton retour (Best).
  3. Pousser la récupération de données au plus près des composants, sous Suspense, avec des fallbacks dimensionnés pour éviter le CLS ; useOptimistic et useTransition pour le retour immédiat (Scharff).
  4. Avant d'écrire du JavaScript, vérifier ce que la plateforme offre : <details name>, attribut popover, :has(), @starting-style, animations pilotées par le scroll (Abu).
  5. Préférer le HTML sémantique à ARIA, relier labels, descriptions et erreurs par useId, et tester avec getByRole / getByLabelText puis avec un vrai lecteur d'écran (Porshnieva).
  6. Pour streamer du JSON produit par un LLM, passer en NDJSON (un objet par ligne) ou s'appuyer sur un SDK qui valide avec Zod (Kumar).
  7. Rendre les tests Playwright fiables avec eslint-plugin-playwright, des tests isolés en mode parallèle et des rapports lisibles par le back (Marshalkina).
  8. Pour vendre une réécriture en entreprise, partir d'un problème chiffré, trouver des alliés hors de l'équipe et ne demander que deux mois de preuve (Jansson, Elkjøp).
  9. Tester les bêtas des librairies que vous utilisez : c'est le seul moment où leur API peut encore changer (Dorfmeister).
  10. En A/B test, ne changer qu'une variable, fixer hypothèse, KPI et durée avant de lancer, et faire tourner les variantes en même temps (Popova).

Session par session

Jeudi 20 mars

Conférence▶ vidéod'après le programme

Abracadabra: The Vanishing Network

Kent C. Dodds — Epic Web

  • Talk d'ouverture de la conférence (9 h 15, suivi d'un Q&A).
  • D'après le descriptif : le réseau entre serveur et client est la principale source de complexité du développement web (UI initiale, appels d'API à la navigation, soumissions de formulaires).
  • Thèse annoncée : les React Server Components et les Actions font « disparaître » cette complexité et permettent de meilleures expériences utilisateur.
  • Le reste du jour 1 y fait écho : Jean Burellier cite la présentation « juste avant » sur le réseau, Aurora Scharff et David Khourshid prolongent sur RSC et formulaires.
  • Contenu exact non vérifié : transcript non récupéré.

Conférence▶ vidéo + transcript

Building a design system with React in 2025, what's new?

Jean Burellier — Sanofi

  • Contexte Sanofi : des milliers d'applications internes et publiques, toutes régulées, déclinées par pays. Le design system est porté par 4 ingénieurs et 2 designers pour plus de 2 000 ingénieurs.
  • Choix d'un design system maison, sans librairie tierce (objectif : zéro dépendance) : cycles produit de 7 à 8 ans, besoins multi-supports, accessibilité au-delà de la loi, personnalisation par marque.
  • Ce qui change en 2025 : coexistence CSR/SSR, compatibilité React, Remix et Next.js, React 18 et 19 ; jusqu'à 48 variantes de test par cas (frameworks, versions, navigateurs, rendu). L'European Accessibility Act arrive dans trois mois et vise aussi les outils internes.
  • Résultats annoncés : délai de livraison réduit de 25 à 45 %, prototype en moins d'une heure, site statique en quatre heures ; un socle validé fait passer la validation qualité de deux ou trois mois à moins d'une semaine.
  • Points durs : construire la communauté, viser zéro breaking change, boucle de feedback, culture inner source encore à installer.
  • Pistes : playground pour non-développeurs, assistant LLM nourri de la documentation, tests « canari » sur les projets les plus utilisés (inspiré de Node.js), composants métier complets (profil, recherche d'essai clinique).

Conférence▶ vidéo + transcript

I Can't Believe It's Not JavaScript

Jemima Abu — Google Developer Expert

  • Rappel historique : JavaScript a été créé pour soutenir HTML et CSS (validation côté client), pas pour porter tout le contenu. Anecdote left-pad pour illustrer la dépendance excessive.
  • Règle proposée : si la page était imprimée sans JavaScript, le contenu devrait rester lisible ; garder JS pour la fonctionnalité (par exemple persister un choix de thème).
  • Démos CodePen sans JS : sélecteur de thème avec :has(), accordéon <details> (accessibilité native, recherche dans la page, exclusivité avec l'attribut name), modale avec l'attribut popover (focus, fermeture au clic extérieur), ::backdrop.
  • Fonctions encore expérimentales montrées : calc-size(auto), @starting-style, animations pilotées par le scroll (animation-timeline, animation-range).
  • Q&A : pour un thème persistant en SSR, stocker le choix en local et laisser le CSS gérer l'affichage.

Conférence▶ vidéo + transcript

Demystifying Accessibility in React Apps

Kateryna Porshnieva — Buffer

  • Bases : l'arbre d'accessibilité (rôle, nom accessible, états) exposé aux technologies d'assistance ; démonstrations au lecteur d'écran tout au long du talk.
  • Première règle d'ARIA : ne pas l'utiliser si le HTML natif suffit. ARIA ne change que la sémantique, pas le comportement, et les pages qui en usent ont en moyenne plus d'erreurs.
  • Boutons icônes : aria-hidden sur l'icône, composant VisuallyHidden plutôt qu'aria-label (non traduit) ; :focus-visible, :has() et @media (hover: hover) pour les actions au survol.
  • Formulaires : labels reliés explicitement, aria-describedby pour aides et erreurs, useId pour les identifiants, aria-required et aria-invalid (aussi utilisés comme sélecteurs CSS), erreurs pas uniquement en couleur.
  • Notifications : régions live (role=status, role=alert).
  • Tests : axe, Lighthouse, jsx-a11y, puis requêtes sémantiques de Testing Library ; enfin lecteur d'écran et tests avec des utilisateurs handicapés (pratique de Buffer).

Conférence▶ vidéo + transcript

Goodbye, useState

David Khourshid — Stately

  • Suite de son ancien talk « Goodbye useEffect » : useState n'est pas à bannir, mais on l'utilise trop, surtout avec React 19.
  • Pièges : closures (préférer le setter fonctionnel), identité d'objet (Map, Set), re-rendus inutiles ; useRef pour un état qui n'affecte pas l'UI.
  • Alternatives : l'URL pour l'état partageable (renvoi vers nuqs), Server Components, Suspense, useTransition ou TanStack Query pour les données, FormData et useActionState pour les formulaires, React Hook Form ou TanStack Form pour les cas complexes.
  • Modélisation : regrouper l'état lié, enums de chaînes et unions discriminées pour éliminer les états impossibles, valeurs dérivées calculées au rendu.
  • useReducer pour la logique contrainte (gestion « indirecte » par événements, testable), useSyncExternalStore, XState Store ; ouverture vers le local-first.
  • Formule mémorable : la « vibe state management », empilement de useState que génère Cursor laissé sans contrôle.

Conférence▶ vidéo + transcript

Type-Safe URL State Management in React with nuqs

François Best — 47ng

  • Le vrai intérêt de l'état dans l'URL n'est pas la survie au rechargement mais deux « super-pouvoirs » : téléportation (partage de lien) et voyage dans le temps (favoris, historique). L'URL devient aussi une frontière client/serveur.
  • Cinq points de vigilance : taille (environ 2 000 caractères), lisibilité des liens (l'URL est une UI), migrations de schéma des liens déjà partagés, bouton retour cassé par des push abusifs, limitation de débit des API d'historique par les navigateurs, SEO (URL canonique).
  • Démo de nuqs : useQueryState compatible avec l'API de useState, parseurs typés, adaptateurs Next.js et React Router, routage shallow par défaut, shallow: false pour déclencher le rendu serveur.
  • Descripteurs déclaratifs réutilisés côté serveur (createLoader), client (useQueryStates) et liens (createSerializer), avec renommage des clés dans l'URL.
  • François Best (speaker) rappelle qu'il assistait à la première édition un an plus tôt.

Conférence▶ vidéo + transcript

React Server Components: Elevating Speed, Interactivity, and User Experience

Aurora Scharff — Crayon Consulting

  • Démo live sur une app Next.js App Router + Prisma volontairement lente, améliorée pas à pas en partant d'une base sans JavaScript.
  • Étapes : loading.tsx, requêtes déplacées dans les composants qui les consomment et parallélisées sous Suspense, skeletons dimensionnés pour garder un CLS à zéro.
  • Promesses passées aux composants clients et lues avec use() ; formulaire next/form, recherche pilotée par l'URL, useTransition pour l'indicateur d'attente, attribut data-pending et :has() pour signaler le chargement sans état global.
  • useOptimistic pour des filtres réactifs indépendants du réseau, cache() pour dédupliquer les appels, staleTimes côté client, puis Partial Prerendering (expérimental).
  • Résultat : score Lighthouse de 99 malgré des requêtes de plus de 2 secondes, « no useEffects or useStates » hormis la transition. Variante avec nuqs montrée en fin de talk.

Conférence▶ vidéo + transcript

What we learned rebuilding the largest Nordic electronic retail website in Next.js?

Tomas Jansson — Elkjøp Nordic

  • Point de départ : un site Angular lent, critiqué publiquement sur Reddit ; le parcours jusqu'au checkout passe de deux minutes à 33 secondes après la réécriture.
  • Volet conduite du changement : parler coûts et revenus plutôt que techno, chiffrer, trouver des premiers alliés hors des développeurs, réduire le périmètre (ni CMS ni recherche) et ne demander que deux mois à trois développeurs pour une preuve.
  • Volet technique : abandon du rendu à l'edge quelques jours avant la bascule (trop loin des API), suppression d'un proxy CDN superflu (-40 % de TTFB).
  • Pages statiques et cachables malgré l'i18n et les feature flags, encodés par le middleware dans un segment d'URL ; Server Actions, invalidation du cache par événements et tags, attente du Partial Prerendering.
  • Outils Vercel appréciés : déploiements de preview, Speed Insights, environnements, toolbar.

Conférence▶ vidéo + transcript

Bridging Code and Creativity: Level Up Your Game as a Frontend Engineer

Yu Ling Cheng — Pigment

  • Jeu de rôle en trois niveaux pour le développeur front qui travaille avec design et produit.
  • Niveau 1, construire en autonomie : poser deux questions factuelles, est-ce réaliste ? (données réelles) et est-ce cohérent ? (déjà dans le design system ?), puis lister ce qu'il faut recevoir (assets, cas limites, interactions, formats, responsive).
  • Niveau 2, façonner la fonctionnalité : face à une option qui semble plus simple mais ne l'est pas, ne pas trancher en cinq minutes ; prendre le temps de traduire les contraintes techniques en coûts et maintenance.
  • Niveau 3, élargir son influence : composants et hooks qui embarquent l'accessibilité, guidelines écrites, feature flags pour itérer sur des données réelles, previews de pull request pour tester une idée avec designers et PM.

Vendredi 21 mars

Conférence▶ vidéo + transcript

Using AI Effectively in 2025

Tejas Kumar — DataStax

  • Talk improvisé : Tejas Kumar dit n'avoir rien préparé et avoir demandé aux participants, la veille, ce qu'ils voulaient apprendre. Réponse majoritaire : gérer le streaming de l'IA dans une UI React.
  • Live coding (avec Cursor et quelques ratés CORS assumés) : réponse OpenAI streamée, lecture d'un ReadableStream, puis problème du JSON partiel.
  • Solution manuelle : NDJSON imposé par prompt système et tampon côté serveur. Solution outillée : streamObject du Vercel AI SDK avec schéma Zod.
  • Démo d'UI générative (films, bande-annonce, carte) : le LLM choisit l'outil et fournit les props, les composants restent écrits par le développeur. Message : « I'm not building another chatbot ».
  • Fin sur MCP (base Astra pilotée depuis Cursor, serveur MCP de TanStack Router) et l'idée que l'anglais devient la prochaine abstraction.

Conférence▶ vidéo + transcript

Let's build K.I.T.T. with JavaScript

Nico Martin — Freelance

  • Projet personnel : recréer KITT (K 2000) entièrement dans le navigateur, sur l'appareil, sans requête réseau.
  • Briques : WebGPU, Transformers.js avec Whisper (transcription) et Kokoro (synthèse vocale), WebLLM avec Gemma 2 (environ 33 tokens/s générés en local).
  • Personnalité par simple prompt système ; mémoire via un RAG agentique sur 6 275 scènes de la série, résumées par un LLM local (3,1 millions de tokens en entrée, plusieurs jours de calcul) et stockées dans IndexedDB.
  • Function calling en texte brut (balises XML) ; les petits modèles exigent davantage de garde-fous (appels en double).
  • Corps physique : voiture Lego pilotée par Arduino via Web Bluetooth. Débouché annoncé : un client mail hors ligne avec IA locale, proposée en opt-in.

Conférence▶ vidéo + transcript

From Chaos to Clarity: Mathematical Foundations for Maintainable React Applications

Héla Ben Khalfallah — Ekino

  • Constat : JavaScript laisse tout passer et les revues de code reposent sur des avis ; objectif, des critères déterministes de qualité.
  • Théorie des graphes : fichiers comme nœuds, imports comme arêtes ; détection de cycles, communautés (méthode de Louvain) pour découper les modules, centralité pour l'instabilité, le code mort et prioriser les tests unitaires, densité pour repérer le code spaghetti. Outils : madge, graphology, son outil open source.
  • Théorie des catégories : transformations plutôt que mutations, composition de petites fonctions, foncteurs, monades, lenses, transducers.
  • Lambda-calcul : curryfication, fonctions d'ordre supérieur, évaluation paresseuse, mémoïsation, trampolines.
  • Lecture critique : talk très conceptuel, peu ancré dans React lui-même.

Conférence▶ vidéo + transcript

Work Smarter, not Harder with Chrome DevTools

Dominika Zając — Qualtrics

  • Fil rouge : les « petites questions » des collègues et la fonctionnalité DevTools qui y répond vite, démontrées sur le site de React Paris.
  • CSS : CSS Overview (couleurs et problèmes de contraste), émulation des déficiences visuelles, correction automatique du contraste dans le color picker, arbre d'accessibilité complet, paint flashing, document.designMode pour les designers.
  • Assistant IA intégré à DevTools (styles, erreurs CORS, requêtes réseau), avec la mise en garde de ne pas lui faire une confiance aveugle.
  • Recorder pour rejouer et exporter (Puppeteer) des scénarios de reproduction ; panneau Performance avec métriques locales et terrain (CrUX), annotations, insights, Lighthouse.
  • Réseau : surcharge locale des réponses et des en-têtes, blocage de requêtes pour tester les fallbacks.

Conférence▶ vidéo + transcript

A Tale of Two Components: Mastering A/B Testing in React

Violina Popova — ClipMyHorse.TV

  • L'A/B test pour remplacer l'intuition par la donnée ; démarche scientifique : analytics, observation, hypothèse, ciblage, variantes, résultats.
  • Bonnes pratiques : une seule variable, KPI choisi avant, durée minimale (une semaine, deux à quatre pour les gros changements), variantes simultanées, bonne audience.
  • Feature flags et A/B tests distingués ; mise en œuvre avec GrowthBook et Google Analytics, logique de choix de variante isolée.
  • Cas réel ClipMyHorse.TV (France et Suède) : supprimer le mois d'essai a augmenté la conversion payante (+1,74 point combiné, 25 % d'abonnés payants en plus selon la speaker), le taux d'annulation pendant l'essai étant élevé.

Conférence▶ vidéo + transcript

At the top of the pyramid: Playwright testing at scale

Kate Marshalkina — Aetion

  • Contexte : couvrir 64 epics de tests end-to-end exigés par la réglementation, sur une app React 17 non typée et un back Java vieux de dix ans.
  • Stratégie ad hoc, le « testing mushroom » : d'abord un chapeau de tests E2E comme filet de sécurité, puis intégration et unitaires.
  • Leçons : tests instables dus à un mauvais usage des API (corrigé par eslint-plugin-playwright), dépendances entre tests cassées par le mode fully parallel, rapports lisibles grâce au décorateur step et à Allure.
  • Vitesse : de 51 à 17 minutes en augmentant les workers, 10 minutes gagnées sur 200 tests grâce à un cache réseau (« mocking without mocks »).
  • Effet de bord : un an après, React mis à jour, monorepo, feature-sliced design et migration TypeScript ; « everything else becomes easier when you've got your testing right ».

Conférence▶ vidéo + transcript

React Query API Design - Lessons Learned

Dominik Dorfmeister — Sentry

  • Une bonne API est minimale et intuitive au départ, puissante quand l'app grandit : useQuery donne 80 % de la valeur, le reste s'apprend au besoin.
  • Les versions majeures servent à casser des API, pas à livrer des fonctionnalités ; mention de l'epoch semver d'Anthony Fu.
  • Concevoir avec les types dès le départ : suppression des surcharges de useQuery en v5 (de 125 à 25 lignes de types).
  • Prendre son temps avant d'ajouter une option : refetchPage était une erreur, remplacée par maxPages ; l'inversion de contrôle (options en callbacks) plutôt que des options dédiées comme le debounce.
  • Pragmatisme (erreurs typées Error par défaut), courage de retirer (callbacks onSuccess supprimés en v5).
  • Appel principal : tester les bêtas et remonter du feedback, car stable veut seulement dire que l'API ne peut plus changer. Il mentionne avoir livré deux jours plus tôt un adaptateur de streaming expérimental, ce que Tejas Kumar avait salué le matin.

Conférence▶ vidéo + transcript

Using Remix, the wrong (?) way

Antoine Chalifour — Geckosocial

  • Retour d'expérience sur deux ans de Remix (désormais React Router v7) pour un SaaS de publication LinkedIn construit en solo.
  • Le modèle Remix (loader, action, revalidation globale) est simple et stable, mais il a coincé : éditeur riche Lexical incompatible SSR et progressive enhancement, données non liées à une route, revalidation devenue coûteuse, formulaires complexes.
  • Migration incrémentale vers TanStack Query et React Hook Form : alimenter le cache dans les clientLoader, lire le cache, clientAction vers une API indépendante, puis invalidation ciblée et mutations.
  • Ce qu'on perd : stabilité de page par défaut, gestion des courses, progressive enhancement. Ce qu'on garde : Vite, routing imbriqué, redirections d'authentification côté serveur, intégration dans un serveur NestJS.
  • Message : un framework est un outil, on n'est pas obligé d'en utiliser toutes les fonctionnalités ; migrer par petites étapes, sans réécrire.

Conférence▶ vidéo + transcript

A journey into the fiber

Matias Nahuel Gonzalez Fernandez — Basement Studio

  • Dernier talk de l'édition : comment fonctionnent les renderers custom de React (comme React Three Fiber) via react-reconciler.
  • Principe expliqué avec un « React Pizza Fiber » : un objet de configuration de callbacks (createInstance, appendChild…) et un conteneur.
  • Série d'expériences volontairement inutiles : composition d'images avec Jimp, rendu ASCII dans le terminal (jusqu'à un Space Invaders et Doom), fichiers MIDI, modèles 3D avec JSCAD, et un renderer qui envoie l'arbre JSX à DALL-E.
  • Philosophie : apprendre en s'amusant, sans viser la production.

Sessions sans retour trouvé (6)

  • Workshop React Performance (Kent C. Dodds, 19/03, payant)
  • Workshop Accessibility in React (Kateryna Porshnieva, 19/03, payant)
  • Workshop Getting started with AI (-agents) in the browser (Nico Martin, 19/03, payant)
  • Workshop Going Full-stack with Astro (Elian Van Cutsem, 19/03, payant)
  • Workshop Hands-on React Server Components, Server Functions, and Forms in the Next.js App Router (Aurora Scharff, 19/03, payant)
  • Meetup Remix Paris avec Kent C. Dodds (18/03) et meetup Fork It! & React Paris (19/03)

Sources