Schedule

React Server Components are powerful, but most implementations make them feel like a fixed, server-owned tree.TanStack Start takes a different approach: it treats RSC as data - server-rendered fragments the client can fetch, cache, and compose into its own UI tree.Because RSC fit into the same caching story as data, they can use TanStack Router’s built-in cache, TanStack Query, or other caches directly - without introducing a separate caching model just for components, while enabling fine-grained caching and invalidation.Built on TanStack Start’s existing primitives, the model also composes cleanly with middleware and with different rendering strategies, from streaming SSR to no SSR at all.

React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. The new React Compiler promises to "automatically optimize your React app"... but what is it actually _doing_ to your component? How does that complex compiler-written code actually make your app faster?

Over the past year, the way I build applications has changed dramatically. Projects that once took weeks now take days with the help of AI. But the biggest shift isn’t speed, it’s how I learn and how I teach.In this talk, I’ll share how I’ve started using AI not just as a coding assistant, but as a teaching layer inside my development workflow and content. I’ll walk through how I use AI to explore architectures, validate decisions, and iterate faster, and how I bring that same process into tutorials watched by millions of developers.This approach shifts learning from passive consumption to active collaboration.

It’s entirely possible to be a strong frontend engineer while remaining mostly oblivious to availability, SLAs, SLOs, and delivery metrics. Many teams are structured that way, and it works, until you want to increase your impact beyond the UI.This talk is about expanding the frontend perspective to include the system it lives in. Not to turn frontend engineers into SREs or platform specialists, but to build full-stack awareness that leads to better decisions, safer changes, and healthier delivery practices.We’ll look at resilience as a mindset across the software development lifecycle, and how practices like atomic changes, trunk-based development, feature flags, and automated rollbacks directly affect frontend work, even when the failures don’t originate in the UI. We’ll also connect these practices to availability targets, SLOs, and DORA metrics, and explain why failure tolerance is contextual, from highly regulated systems with near-zero tolerance to products where controlled failure is acceptable.The goal is to help frontend engineers understand how their work fits into the larger system, so they can ship faster, reduce risk, and increase their impact within a team without losing focus on frontend excellence.

SPAs were always based on contingent logic. For the benefits to materialise, users must spend a great deal of time in the same interface, updating state in-place. This never described the majority of experiences, where very little is persisted across screens and critical user journeys. As the industry moves away from SPAs and the frameworks they popularised, one of the largest hurdles for teams rethinking their approach is retaining the trust of managers who previously signed off on the very SPAs that now feel slow and shabby.

Every team building with AI faces the same tension: move fast and ship, or slow down and get it right. At Zed, we build an IDE obsessed with performance and quality. This means being brutally honest about where AI helps, where it hurts, and how we make decisions when the answer isn't obvious. This is the story of how we navigate that tension in practice — the tradeoffs, the mistakes, and the framework we've built for keeping quality alive when speed is the default.spectrum of dev workflows.

Web development has always moved in cycles of hype, from frameworks to tooling. With the rise of large language models, we're entering a new era of 'vibe coding,' where developers shape software through collaboration with AI rather than syntax. This talk explores what that means for the future of coding, especially in frontend development, and how it echoes the past while redefining what comes next.

Throughout history, empires rise and fall. Throughtout web development, frameworks rise and fall. In 2026, we are firmly in ""late stage React"", where young devs can't remember the world any other way, and older devs are keeping their eye on the horizon for what's next.What if I told you there was a TypeScript-first UI framework created by a member of both the React _and_ Svelte core teams focused on fine-grained reactivity and rendering speed that will look instantly familiar to you?I'd like to introduce you to Ripple, show you around its syntax and philosophy and stimulate your mind out of the Present and into the Future.

Observability isn’t just for backends anymore. As React applications grow more complex distributed across CDNs, APIs, and micro-frontends understanding what’s happening in production becomes a full-stack challenge. In this talk, we’ll explore what observability means for modern frontend architecture , how to design, instrument, and standardize telemetry for your React apps.

After 25 years building for the web, I built rari—a React Server Components framework on Rust that delivers 45x higher throughput than Next.js. This talk is about the architecture decisions that made it possible.I'll walk through the three-layer architecture: a Rust runtime with embedded V8, RSC-aware Vite transformations, and true streaming SSR. You'll see why using V8 directly through Rust (not Node.js) changes everything, how correct 'use client' and 'use server' semantics matter more than expected, and what I got fundamentally wrong in my first implementation.When I fixed three pieces—app router support, true SSR, and correct RSC semantics—performance jumped from 4x to 45x. Not because Rust is inherently fast, but because the architecture finally matched React's design intentions.You'll learn concrete patterns for RSC streaming at the runtime level, trade-offs between ecosystem compatibility and performance, and how React Server Components actually work under the hood.

ARIA, the Accessible Rich Internet Applications Suite, is a huge topic and full of hard concepts. Learning it becomes even more intimidating when you hear "the first rule of ARIA is don't use ARIA". This common adage doesn't mean ARIA will literally never make your webpage more accessible. Let's talk about what it really means.

Every modern app starts from the same truth: your website is built on data. Traditionally, developers define how that data turns into UI - the f in UI = f(data, state). But every user approaches your app with different goals, contexts, and focus, and a one-size-fits-all interface forces them to work around the UI instead of it working for them. In this talk, we’ll explore the Generative Front-End - a new paradigm where the logic that maps data to interface is itself generated by an LLM.

While tools like Jest, Jasmine, Karma, and Testing Library  were always there when we needed them for testing our web apps, it's time to move on. In this talk, we'll revisit the battle scars they left behind, and explore how Vitest isn't just trendier — it's the result of hard-earned lessons in speed, reliability, and developer experience.You'll leave with:- A sense of closure for the old stack.- A tour of the modern features Vitest brings to the table.- Clarity on "Partial" vs. "Full" Browser Mode.- The anatomy of a maintainable test: Fakes, Object Mothers, and patterns that future-proof your specs.- A look at Testronaut — a testing companion that takes these patterns further.Come for the nostalgia. Stay for the clarity.