[Talk::Overflow #27] React Paris 26 Tech Talks

React Paris 26 (March 26–27, 2026, Paris) landed right as teams are reconciling AI-assisted coding, heavier client tooling, and renewed skepticism about whether popular patterns actually ship value. The single-track agenda reads less like a framework marketing tour and more like a pressure test: performance, architecture simplification, design systems and CSS, data-fetching ergonomics, and honest takes on micro-frontends and RSC. For frontend and full-stack engineers shipping React in production, the through-line is pragmatic: fewer abstractions that sound clever on paper, more systems you can observe, refactor, and teach to the next hire.

This lightning slot is about pushing visual polish without defaulting to a canvas/WebGL escape hatch. Chris Feijoo focuses on refraction-like effects using CSS and SVG, which matters because teams often over-buy complexity for “premium UI” moments. The talk stands out for treating the browser’s native graphics stack as a first-class design surface, not a limitation. Engineers can apply the mindset: prototype optical effects with declarative styling, measure paint and interaction cost, and reserve heavier stacks for cases that truly need them. If you own design systems or marketing surfaces, this is a useful reminder that perceived quality often comes from disciplined rendering choices, not bigger bundles.

TanStack Start sits in the crowded “what comes after SPA+router” conversation, and having it presented by Tanner Linsley matters because the ecosystem trusts TanStack’s bias toward explicit data contracts and predictable client behavior. The session frames a client-first architecture without pretending servers disappear, which is the realistic shape of many product teams. It stands out because it connects framework ergonomics to how teams actually iterate: loaders, caching, and navigation semantics that reduce accidental complexity. Engineers can walk away with sharper criteria for choosing primitives (what is route-owned state vs global state) and for evaluating frameworks by debuggability and migration cost, not feature lists.

Micro-frontends solve organizational boundaries more often than they solve user-facing problems; Nicolas Beaussart-Hatchuel’s talk is positioned as an experience report on undoing that split when it stopped paying rent. The standout angle is velocity as an outcome of boundary reduction: fewer independent deploy trains, less duplicated infrastructure, less “integration tax” between teams. For architects, it’s a prompt to separate true domain isolation from accidental distribution driven by hiring structure. Apply it by auditing where your runtime coupling actually lives (routing, design tokens, analytics, auth) and whether your deployment independence is worth the coordination overhead you pay every sprint.

This lightning talk lands where many teams already are: AI-generated React that compiles and ships, but quietly encodes anti-patterns that hurt readability, accessibility, and future refactors. Kawtar Choubari focuses on how “works on my machine” UI becomes a maintenance debt when generated code bypasses team conventions. It stands out because it reframes AI assistance as a code review problem, not a magic productivity lever. Engineers can apply a practical rule: treat generated UI like junior contributions—enforce linting, component boundaries, and accessibility checks in CI, and prefer small, reviewable diffs over bulk churn.

Daishi Kato’s libraries are widely used because each targets a different state modeling shape; this talk promises the “why” behind the API surfaces, not just usage snippets. It stands out as a rare maintainer-level view of state architecture tradeoffs: immutability versus signals and proxies, coarse stores versus atomic models, and how those choices ripple into React rendering behavior. Engineers can use it to pick tools intentionally—when you need minimal boilerplate, when you need fine-grained subscriptions, and when you should still reach for something more boring and centralized. Even if you standardize on one approach, understanding the design pressures makes you a better reviewer and debugger.

Una Kravets’s session is about modern CSS as a productivity multiplier for UX quality, not as a pile of novelty properties. It stands out because good CSS work reduces JavaScript budget and makes layout resilience cheaper to achieve across breakpoints. Engineers can apply it by investing in baseline layout primitives, typography systems, and interaction details that used to require JS. If your team still treats CSS as “styling after the fact,” this is the kind of talk that helps you argue for front-of-pipeline design systems work.

Gabriel Pichot’s title is deliberately confrontational: React is a UI runtime, not a substitute for product discipline, domain modeling, or operational maturity. The talk stands out as a culture checkpoint for teams that confuse framework churn with progress. Engineers can apply it by reframing roadmap debates around outcomes (latency, reliability, support burden) instead of stack identity. It’s a useful talk to share with stakeholders who think “rewrite to React” is a strategy.

Taylor Quinn-Bohmann covers federated UI at scale—how organizations share components and experiences across surfaces without cloning teams. It stands out because federation is easy to caricature as micro-frontend cosplay, but the real engineering problem is versioning, design consistency, and runtime isolation. Apply the lessons by defining what “share” means (tokens, primitives, data contracts) before debating module federation graphs.

Rody Gosset focuses on hybrid data fetching patterns that reduce the reflexive loading spinner UX teams fall back on. The lightning format matters here: it’s a tight argument for making latency explicit in UI design, not hidden behind generic placeholders. Engineers can apply stale-while-revalidate thinking, prefetch, and progressive disclosure where the product narrative supports it. If your app feels “fast but annoying,” this is the problem class.

Dan Neciu’s talk is a corrective for teams that adopt TanStack Query as a global cache hammer. It stands out because misuse shows up as stale UI, duplicated requests, and mysterious invalidation graphs. Engineers can apply it by treating queries as domain-scoped resources with explicit cache keys, ownership boundaries, and predictable mutation lifecycles. If your data layer feels magical, you probably need less magic and more conventions.

Elise Patrikainen connects Oxc, Rolldown, Vitest, and Vite as a coherent story about where JS tooling is heading: faster parsing and transform pipelines and tighter integration between build and test. It stands out because toolchain talks can be hypey; this one is grounded in the engineering reality of iteration speed and CI time. Teams can use it to plan upgrades without betting everything on a single tool—think incremental adoption and benchmark-driven decisions.

Mark Erikson’s session is a practitioner’s look at performance optimization on a library many teams rely on (Immer). It stands out because it’s not abstract Big-O theater; it’s about measuring, profiling, and shipping improvements that affect real apps. Engineers can apply the general pattern: establish hot paths, avoid accidental allocations, and validate changes with representative workloads. If you maintain shared utilities, this is the mindset you want your team to internalize.

Nicolas Dubien focuses on performance drift—how apps get slower not from one bad commit, but from thousands of small decisions that never trigger a crisis until they do. It stands out because it pushes observability and performance budgets into the frontend conversation beyond Lighthouse snapshots. Engineers can apply it by tying releases to regression budgets and making perf a reviewable property, not a postmortem hobby.

Ramona Schwering connects accessibility to authentication UX—flows that teams ship quickly and regret slowly. It stands out because login screens are “boring,” which is exactly why they accumulate keyboard traps, unclear errors, and screen reader hazards. Engineers can apply it by testing focus management, error semantics, and session edge cases as part of definition-of-done, not as an audit checkbox.

Bree Hall’s talk expands the definition of UI quality beyond pixels: motion, sound, haptics, and other sensory channels where React apps often underinvest. It stands out as a reminder that inclusive design includes people who benefit from multimodal feedback, and that “delight” is not the opposite of accessibility when done thoughtfully. Teams can apply it by pairing animation decisions with reduced-motion paths and by treating sensory design as systems work, not one-off polish.

Rom Brillout presents Vike as a framework aimed at advanced React apps that still want escape hatches and stability. It stands out in a market dominated by a few mega-frameworks, because it speaks to teams that need control over rendering modes and deployment targets. Engineers can use it as a comparison point when evaluating how much framework policy your org can tolerate versus how much you need custom routing and data integration.

Kitze’s title captures a timely shift: from “move fast with AI vibes” to engineering practices that keep software legible. It stands out because it addresses process and judgment—how teams review, test, and structure work when generation is cheap. Apply it by tightening definition of done, making traces from product intent to code changes, and refusing to let novelty become your quality strategy.

Nikhil Sharma discusses AI-powered reconciliation in a way that maps to real React problems: mismatched expectations between UI state and model output. It stands out because “AI in the UI” often ignores failure UX and user trust. Engineers can apply it by designing fallback paths, explicit confidence signaling, and human-in-the-loop corrections where errors are costly.

Ankita Kulkarni frames an agent toolkit as something you can assemble pragmatically rather than as a single vendor monolith. It stands out because it pushes teams to think in tools, guardrails, and evaluation loops—the boring parts that make agents usable. Engineers can apply it by standardizing prompt boundaries, tool permissions, and telemetry before scaling autonomous workflows.

Tejas Kumar hosts the ConTejas AI Panel, which is useful as a snapshot of how practitioners are reasoning about AI across tooling, ethics, and day-to-day delivery. Panels stand out when they surface disagreements; treat this as a way to compare mental models rather than a single prescription. Teams can apply panel-style insights by writing down principles your org agrees on, even when vendors disagree.

Susanna Wong connects Chrome MCP and AI workflows to frontend productivity—essentially using the browser context as a grounded tool surface for assistance. It stands out because “AI for devs” becomes more reliable when models can observe real DOM and performance signals instead of guessing. Engineers can apply the underlying idea cautiously: improve tooling integration and repeatable workflows before expecting magic.

Dominik Dorfmeister (Sentry) uses Knip as the anchor for a broader lesson: dead code is not harmless—it increases cognitive load, widens attack surface, and slows refactors. It stands out because large deletions are a leadership-visible form of engineering excellence. Teams can apply it by making dependency and export hygiene part of sprint hygiene, not a yearly cleanup.

Nadia Makarevich’s talk tackles RSC with a performance lens—exactly the question production teams should ask instead of treating RSC as doctrine. It stands out because the ecosystem needs more measurement-backed framing of server work, caching, and client navigation costs. Engineers can apply it by defining success metrics up front (TTFB, interaction readiness, server cost) and testing scenarios that matter to your product, not demo pages.

Stay curious. Stay kind.

— Talk::Overflow