React Paris 2025
Site archivé (nouvel onglet) ↗Programme (nouvel onglet) ↗Chaîne YouTube (nouvel onglet) ↗Synthèse de mars 2025 →
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
- Réserver
useStateà l'état interne d'un composant : valeurs dérivées calculées au rendu,useRefpour ce qui ne s'affiche pas,useReducerou un store pour la logique contrainte (Khourshid). - 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).
- 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 ;useOptimisticetuseTransitionpour le retour immédiat (Scharff). - Avant d'écrire du JavaScript, vérifier ce que la plateforme offre :
<details name>, attributpopover,:has(),@starting-style, animations pilotées par le scroll (Abu). - Préférer le HTML sémantique à ARIA, relier labels, descriptions et erreurs par
useId, et tester avecgetByRole/getByLabelTextpuis avec un vrai lecteur d'écran (Porshnieva). - 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).
- 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). - 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).
- Tester les bêtas des librairies que vous utilisez : c'est le seul moment où leur API peut encore changer (Dorfmeister).
- 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'attributname), modale avec l'attributpopover(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-hiddensur l'icône, composantVisuallyHiddenplutôt qu'aria-label(non traduit) ;:focus-visible,:has()et@media (hover: hover)pour les actions au survol. - Formulaires : labels reliés explicitement,
aria-describedbypour aides et erreurs,useIdpour les identifiants,aria-requiredetaria-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 » :
useStaten'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 ;
useRefpour un état qui n'affecte pas l'UI. - Alternatives : l'URL pour l'état partageable (renvoi vers nuqs), Server Components,
Suspense,useTransitionou TanStack Query pour les données,FormDataetuseActionStatepour 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.
useReducerpour 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
useStateque 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 :
useQueryStatecompatible avec l'API deuseState, parseurs typés, adaptateurs Next.js et React Router, routage shallow par défaut,shallow: falsepour 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 sousSuspense, skeletons dimensionnés pour garder un CLS à zéro. - Promesses passées aux composants clients et lues avec
use(); formulairenext/form, recherche pilotée par l'URL,useTransitionpour l'indicateur d'attente, attributdata-pendinget:has()pour signaler le chargement sans état global. useOptimisticpour des filtres réactifs indépendants du réseau,cache()pour dédupliquer les appels,staleTimescô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 :
streamObjectdu 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.designModepour 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écorateurstepet à 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 :
useQuerydonne 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
useQueryen v5 (de 125 à 25 lignes de types). - Prendre son temps avant d'ajouter une option :
refetchPageétait une erreur, remplacée parmaxPages; l'inversion de contrôle (options en callbacks) plutôt que des options dédiées comme le debounce. - Pragmatisme (erreurs typées
Errorpar défaut), courage de retirer (callbacksonSuccesssupprimé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,clientActionvers 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
- Programme officiel React Paris 2025 (archive Wayback Machine, mars 2025) (nouvel onglet) ↗
- Playlist YouTube « React Paris 2025 » (chaîne BeJS, 18 talks + aftermovie) (nouvel onglet) ↗
- François Best : slides de « Type-Safe URL State Management in React with nuqs » (PDF) (nouvel onglet) ↗
- This Week in React #227 (Sébastien Lorber, présent le vendredi, signale la playlist) (nouvel onglet) ↗
- Posts LinkedIn, Bluesky, blogs : aucun retour participant trouvé (9 recherches web, octobre 2026)