Building app-like UX on the web has historically meant reaching for an SPA. You ship the data layer to the browser, manage a client cache, juggle loading states, coordinate mutations, and write a lot of code to keep the UI feeling fast and fresh. The result can be great, but the cost is high, and the model gets harder to maintain as your app grows.Next.js takes a different path. Since React Server Components first landed, we’ve been working toward a way to build where each piece of your app runs where it belongs, while the mental model stays the same: components.

How many times have you had to tell Claude Code to stop reaching for useEffect?React’s flexibility is a strength for developers, but it often leads AI tools in the wrong direction, introducing subtle bugs and drifting away from production-ready code without clear guidance.In this talk, Abhijeet Prasad, maintainer of Braintrust’s AI observability SDKs, shares practical ways to keep your agents on track and writing production-ready React. You will start with simple guardrails and skills that shape better behaviour, then move toward a more powerful setup: an eval pipeline that continuously improves your agents by driving updates to lint rules, skills, and agent instructions.

Ads Manager powers 84% of Meta's Ads Revenue, but its decade-old codebase was stuck on React class components — blocking modern patterns like hooks, Relay, and React Compiler. Manual migration of 10k+ components class to functional component was impractical. In this talk, I'll show how we built an AI codemod pipeline using Devmate that achieved a 5x speedup, migrating 3k+ components with a 99.6% success rate. I'll cover the tradeoffs between AST and AI codemods, how to classify components by complexity for targeted prompts, and the grading/eval strategies that made non-deterministic AI agents production-ready.

Agentic development feels like magic to some teams and overhyped to others. Harnesses like Claude Code or Codex have been built around the local loop, the way things have always been done: a single developer changing code before opening a PR. Inside real organizations, agents hit walls: repo boundaries that demand human attention, a lack of episodic memory across sessions and unresolved questions around trust and permissions.Fixing this requires a higher level of abstraction: the *meta-harness*. Just as meta-frameworks like Next.js or Remix let React stay simple while giving developers what they need to ship, a meta-harness keeps the agent CLI focused on its job while bringing the components teams need to be effective: cross-repo orchestration, testing, and change tracking for greater autonomy,session memory that understands decisions and extracts tribal knowledge,collaboration features for easier handoffs, reviews, shareable sessions andsecurity primitives like sandboxes, remote execution, and clearly scoped agent permissions.This talk argues that the meta-harness - a layer above any single lab or agent - is the missing piece for integrating agents into how we build software across the stack.

React developers (amongst others, ofc) know one golden rule: never use dangerouslySetInnerHtml on user input. Yet, as we're integrating Large Language Models (LLMs) into our applications, we often make a fatal mistake. We're treating AI output as a trusted source. This is fine.

Most React applications treat AI as a separate service: a backend calls an LLM, returns JSON, and a client component renders it. This works, but it misses something fundamental about how React Server Components actually model computation.RSCs do not just move rendering to the server. They make the server a first-class part of the React tree. And the server is exactly where AI inference belongs: close to data, streaming by design, and free from the browser's constraints.In this talk I'll show a concrete architecture where the AI call is the render.

React Server Components are often treated as a framework feature, but they make more sense as a serialization format and a runtime primitive. This talk presents how that mental model changes the way we think about rendering boundaries, composition, and system design in React. Drawing on real implementation experience, I'll show why this shift matters and what it makes possible beyond the assumptions of a single framework, especially for complex systems like a React CMS, where server-first composition and serialization directly shape how content, workflows, and UI are modeled.

After spending nearly a decade building Android and Flutter applications, I became used to workflows that made it easy to understand how an application was put together. Finding the source behind a widget, understanding runtime behaviour, and navigating a large codebase felt relatively straightforward.When I started working on large frontend applications, I found myself spending far more time searching than solving. Something as simple as identifying where a UI element was implemented could involve jumping between browser DevTools, source files, network panels, terminal windows, and multiple layers of abstraction.That experience led me to start building Inspectra.This talk is a case study on the engineering challenges involved in building a modern developer tooling platform from scratch.We'll explore:The challenges of understanding large frontend applicationsRuntime inspection and component introspectionMapping runtime elements back to source codeBrowser-to-editor communication and source navigationDebugging inside embedded runtime environmentsDesign decisions, trade-offs, and failed experimentsWhat developer tooling can do to reduce context switching and improve productivityThis isn't a product demo. It's a practical look at the engineering problems behind developer tooling and the lessons learned while trying to solve them.Attendees will leave with a better understanding of how modern DevTools work under the hood and what it takes to build tooling that developers genuinely want to use.

As React shifts from "Black Box" NPM packages to "Copy-Paste" components, we face a new crisis: How do we distribute complex state and security logic without locking down the UI?This talk breaks down the architecture of a multi-distribution system. We’ll explore using TanStack Query as a headless state machine to orchestrate multi-step authentication sequences and global error-handling patterns that bridge the gap between library and implementation. Learn how to ship "logic-heavy" components that give developers total UI freedom without sacrificing architectural integrity.

You know how to build client apps—but where do client developers fit in the new world of ChatGPT and MCP? If you’ve used GraphQL before, it turns out your knowledge translates directly. This talk demonstrates how to build MCP apps using Apollo Client’s new open source AI apps integration along with the open source Apollo MCP server with patterns you already use:Fragment colocation → Tool design: Structure MCP tools as component data requirementsQuery optimization → Tool call patterns: Minimize LLM roundtrips with the same performance thinkingType safety → Tool schemas: Apply GraphQL’s type discipline to MCP definitionsA live demo builds an MCP app querying a GraphQL API, showing how best practices from GraphQL client development apply to MCP apps.

Generative UI is currently one of the most explosive frontiers in frontend engineering. Modern UI frameworks like React are moving from static components to streaming, AI-generated micro-frontends.Andrey's talk explicitly references Google's A2UI protocol, which standardizes how agents emit declarative layout schemas that are safely interpreted and rendered by trusted client components. React component architecture, server actions, and client-side design patterns are exactly where this protocol must be implemented. Senior React developers are looking for ways to move past boring, messy chat-bubble boxes and build structural, design-compliant generative components.

React re‑renders components on every state change. Signals write directly to the DOM – no re‑renders, no reconciler. I built four npm packages that run unmodified React components on signals. Live demo: building a signal from 3 lines of code, then flipping a real React app onto the signal engine.

Browser-native AI video runtimes utilize technologies such as React, Web Workers, Web Codecs, Offscreen Canvas, and browser-compatible models to perform fully client-side video processing, thereby eliminating the need for large video files to be uploaded to the cloud before they can be processed.This talk will cover the technological challenges of dealing with thousands of video frames efficiently while conducting AI workloads on a large number of workers concurrently; how to handle browser memory constraints with respect to video frame processing, and how to create scalable video processing pipelines without relying on any back-end infrastructure.

Publishing a shared component library feels like a milestone, until a single change breaks multiple applications at once.While working on a monorepo at EPAM Systems powering 8 production applications for a global supply chain platform, we built a shared ecosystem of independently deployable frontend packages: authentication, navigation, app shell, user profile, and UI components. On paper, it promised consistency and speed. In reality, it introduced a new class of problems, subtle, cross-app, and often hard to debug.A mismatch in React versions led to duplicate instances and unpredictable behavior across apps. Small feature requests from different teams slowly turned shared components into overly flexible, inconsistent abstractions.

When you think of it, browsers can be the perfect containers for running all sorts of workloads - Everybody has them, each tab is an isolated environment and they have a very rich API. So why not use the browsers in your organizations to act as containers to run your workloads and save money on servers? In this session I’ll explain the concept and demonstrate it running javascript (of course!) tasks for AI, concurrent batching, PDFs creation and more. This is the new cloud native!

What happens when HTML steps inside the canvas? In this hands-on live coding session, we’ll explore the new HTML-in-Canvas API and the creative possibilities it unlocks. We’ll build from scratch, covering core concepts like pixel manipulation, simple effects, and basic shaders. The focus is on practical building blocks you can take and experiment with, no prior experience required.

State management has traditionally focused on synchronizing user interactions, frontend state, and backend persistence. But AI agents introduce a new type of actor into modern applications: autonomous workflows that can read, execute, and modify application state alongside human users.In this session, we explore how familiar frontend state management concepts can evolve into shared full-stack architectures where both humans and AI agents collaborate on the same data model. Using examples from modern React applications, we will examine sandboxed agent execution with forked state snapshots, deterministic merge strategies, concurrent updates between users and agents, and techniques for making agent actions observable and debuggable.Rather than treating AI as an external API call, this talk presents agents as first-class participants in application state transitions. We will extend familiar concepts such as state stores, reducers, event streams, and optimistic updates beyond the frontend into backend orchestration systems that keep human and agent state consistent.Attendees will leave with practical architectural patterns for building collaborative human + AI applications using ideas they already know from modern frontend development.

React 19’s new use() API is often introduced through data fetching: pass a Promise, suspend while it’s pending, and render when the data is ready. But for many React apps, the bigger performance problem is not just waiting for data — it is shipping, executing, and hydrating too much JavaScript too early. Because use() can suspend on any Promise, it opens a bigger performance opportunity: what if a React app could wait not only for data, but for any resource that determines when different parts of the UI should load, render, or hydrate?In this talk, we’ll explore use() as a primitive for resource-driven performance. We’ll start with the familiar data-fetching pattern, then expand the model through several different use cases: selectively loading component code and remote modules, delaying hydration and interactivity based on viewport and user intent, prioritizing critical UI, and even creating SSR-only components.Through practical examples, we’ll see how these use()-driven patterns can help us avoid common performance problems in heavy React pages: too much JavaScript, too much hydration work, and too many components competing for network and CPU before the user actually needs them.By the end of the talk, you’ll see use() not just as a data-fetching API, but as a new way to control when React components should load, render, and hydrate — helping us build faster pages and more intentional user experiences.

We built a product fully on TanStack Query and skipped adding a state management layer. It worked for a while, then it broke in ways we didn’t expect.This talk dives into how TanStack Query works, what we got wrong, and how to use it properly. From missing optimistic updates to confusing server and client state, we’ll break down the lessons learned and what patterns actually scale when your app grows.

This talk is about an experiment I wanted to try and carried out. I wondered what if we gave React components self-healing properties? What if instead of developers checking Sentry for crashes and then fixing and sending it to prod, the component fixes the crash on its own at runtime? In this talk, we will discuss this exact possibility and whether we can really make it work and what the drawbacks are...

Last year I presented a brand new integration of React Native into Unreal Engine. This year I am taking it a step further, and to show the progress on this new approach I will show you how to create a real game UI in Unreal Engine using React Native.Gaming has long been lagging behind mobile and web in the ease of building a good UI , especially for data heavy games. The gaming world has long embraced the idea of web - games like Civilization 7 launch with fully Web UI by embedding a specialized browser. I think React & React Native are a great fit for revolutionizing how game UI are built.

Frontend apps morph at lightspeed, obliterating traditional test automation in their wake – CSS flips, components explode on re-render, and your test suite? Total carnage, half of it flaming red!Buckle up: I'm unleashing a game-changer – harnessing the browser's Accessibility Tree (the secret sauce powering screen readers) for AI-fueled, bulletproof tests. Forget fragile selectors; these bad boys are framework-agnostic, refactor-proof, and redesign-demolishing!Live demo + battle-tested examples incoming: Watch maintenance evaporate, flakiness vanish, and accessibility skyrocket as your ultimate sidekick. Who's ready to future-proof their tests?

As React applications scale, asynchronous logic often turns into a source of fragility and frustration. Scattered useEffect hooks, ad-hoc retries, manual loading states, and inconsistent error handling create race conditions, memory leaks, and business logic that’s nearly impossible to test reliably.This talk introduces Effect-TS - a powerful, type-safe toolkit that brings clarity and control to async workflows in React. Instead of functional programming theory, we’ll focus on practical, battle-tested patterns that solve real production problems:Separating effects from execution for better composabilityTyped error channels that eliminate silent failures and runtime surprisesDeclarative retries, cancellation, and parallel executionBulletproof handling of component unmounts and stale requestsSmooth, incremental adoption in existing React or Expo codebasesAttendees will leave with concrete strategies to transform chaotic async code into logic that is predictable, testable, and maintainable - even in large, complex applications.

Styled-components lost against Tailwind, partly due to better performance while trading it for a unique API. Can’t you have both, a fast runtime and a familiar API?We replaced styled-components with a build-time compiler in next-yak without changing a single line of user code and saw surprising results: INP improved over 10%, our SSR latency and our pod count dropped significantly. But the path there wasn’t simple.This talk is about three problems that make compile-time CSS-in-JS genuinely hard: dynamic interpolations, cross-file references and build-time evaluation. I will show what we solved, how we solved it and what we couldn’t fully solve and why the remaining gap is a harder problem than it looks.

Component tests started in real browsers with Karma: high fidelity, but slow feedback and painful config. Jest + JSDOM made tests fast and easy, but emulation can miss rendering, layout, and browser APIs.Playwright and Vitest Browser Mode bring back browser-first testing with headless speed, parallel runs, and traces. We’ll compare the approaches and share migration tips for legacy code.

Let an AI model patch your accessibility tree live, and the first thing it will teach you is how it fails. Not occasionally, reliably, in specific, learnable ways: confident but wrong ARIA states, patches that compile but break keyboard flow, fixes that pass an automated audit while making the actual screen reader experience worse.This talk is not a victory lap for a clever pipeline. It's the failure modes first, then the architecture that exists specifically because of them. We'll look at why static linters structurally can't catch dynamic ARIA bugs, what it actually takes to make an AI-generated accessibility patch safe to apply automatically, and the much larger lesson underneath: the accessibility tree is downstream of component state, not of markup which means most AI-accessibility tooling is analyzing the wrong layer entirely.You'll leave with a concrete mental model for the gap between markup-level and state-level accessibility analysis, a typed validation pattern for constraining what an AI agent is allowed to touch in your UI, and an honest account of where this approach still falls short because if a talk about AI and accessibility doesn't tell you where it breaks, it hasn't been tested enough yet.

Every web app needs icons, and there are surprisingly many ways to load them: img tags, icon fonts, inline SVGs, SVG sprites, and Icon components. Most teams pick one by habit or choose what's easy. The choice affects bundle size, accessibility, caching, rendering quality, and developer experience.This talk walks through each approach, how it actually works under the hood, and what it costs you. We'll compare them, showing network requests, bundle impact, and loading speed.

For decades, frontend performance has been guided by the simple principle that faster is better. We optimize load times, reduce latency, and remove every unnecessary delay from the user journey.While building streaming AI interfaces with React, I discovered that traditional performance metrics do not tell the whole story. In AI products, users do not just experience a before and after. They experience a during.

What if your React app could understand users without sending their data anywhere?Modern browsers can now run meaningful machine learning locally. This talk shows how to use in-browser ML to build React interfaces that personalize, adapt, and respond in real time, while staying fast, private, and predictable in production.

This talk is about an experiment I wanted to try and carried out. I wondered what if we gave React components self-healing properties? What if instead of developers checking Sentry for crashes and then fixing and sending it to prod, the component fixes the crash on its own at runtime? In this talk, we will discuss this exact possibility and whether we can really make it work and what the drawbacks are...

“Open-source is dead”, according to X/Twitter. After all, why would we need to install tons of dependencies (with vulnerabilities and supply chain attacks ramping up), when our AI agents can re-implement everything for us?To be fair, rumours of its death have been strongly exaggerated: the world still needs open-source more than ever. But the role of OSS maintainers is changing. From floods of AI slop PRs to newfound superpowers with fine-tuned agentic workflows to help with triage and maintenance, what does the job of maintainers look like at the age of AI?