Managing state is complicated. Humans are even more complicated. As developers, it's our job to deliver seamless and intuitive user experiences, but the sheer complexity of human behavior and the real world can make this a daunting task. In this talk, we'll explore a radical new approach to app development where language models (LLMs) and reinforcement learning (RL) can be used to handle app logic in a more intelligent and human-centric way.

Everybody seems to be talking about "types" these days. From the TypeScript language to type description utilities such as prop-types and Zod, developers expect clear descriptions of the shapes of their React components, data, and hooks. Let's talk about the mindset shift that's happened over the last decade, and where types are taking us over the next one.Brief foundations: what is TypeScript, what "type safety" means, and setting up TypeScript in a React (Next.js) projectA history of how type safety has worked in React, starting with class componentsThinking in Type(s|Script): How modeling value shapes helps raise predictability and understandability, especially in the wildest and wackiest of React architectures.TypeScript's Limitations: By design, TypeScript can only act as a development-time type system and enforce what that system can represent. We'll want to go over what can't and/or shouldn't be represented in that type system.Raising the Runtime: Moving those type thoughts into your React runtime with programmatic frameworks or libraries such as tRPC and Zod - especially as they integrate with React metaframeworks like Next.js and Remix.React Specifics: How this "types-first" theory works helps improve common parts of projects in the React ecosystem: from prop-types back in the day to REST or RPC endpoints, testing, and documentation today.ESLint lint rules to catch common async and React code bugs - and why the language is designed to let you do those dangerous things in the first place.Ecosystem future: where the TC39 types-as-comments proposal will -and won't- take types at a language-level for JavaScript in general and React apps specifically.By allowing our types to be a reflection of the runtime reality, we embrace types-first thinking in designing code - making our code more clear to read and update.

The design-development gap hurts your React projects: slower timelines, compromised quality, and repetitive handoffs. This talk explores the origins of this problem, the differences in language and environment, and offers solutions through processes, tools, and collaboration. Discover how including designers throughout the implementation process helps developers reduce friction, speed updevelopment, and deliver exceptional UIs.

In this talk, I’d like to reflect on the performance changes React went through in the past years – and hypothesize about where we’re going. Key points:React reached maturity and can now push frontend forward without reinventing the same primitives (like how all frameworks were stuck reinventing vdom for the past 10 years)Performance (past): consistent performance push you didn’t even notice (componentDidMount → useEffect and how that avoids layout thrashing; React 18 update batching). Some stuff didn’t really work out (Prepack)Performance (current): features that are available, but we need to change our habits to adopt them: startTransition (needs a habit to separate interactions into urgent and non-urgent), RSC + Server Actions (needs new patterns and approaches to data loading etc) Performance (future): React Offscreen API, React ForgetPerformance (further future, subjective opinion) – where React and other frameworks are moving: intelligent progressive enhancement, with zero JS on the client unless necessaryWhat didn’t work out:Why we can’t put frameworks into workers (answer: latency, data copying, etc.)Why react didn’t go the svelte route (inlining js instead of a single bundle)Why react didn’t go the aggressive-code-splitting-and-chunks-on-demand route

Building end-to-end encrypted applications is exciting, but also intimidating. This talk is designed to lower the entry barrier, offering a clear roadmap for integrating end-to-end encryption in collaborative, real-time applications.We begin by unveiling a simple design with one shared encryption key, promptly addressing its inherent challenges. Progressively, we delve into tools like Opaque, Secsync and CRDTs to tackle the challenges we identified and enhance our application with the goal of offering a seamless user experience without compromising on security.Each segment of the talk starts with an accessible overview before diving into practical, code-based examples. This approach not only demystifies the intimidating theory and empowers attendees with the tools and knowledge to apply these principles effectively in their projects.

We’ve been hard at work to create a first-look at data fetching, server rendering, and streaming in universal Expo Router apps.

Labeled arrows are one of the most widely used features when it comes to whiteboard, isn't it? In this talk, I will be deep-diving into the internals of labeled arrows and how they work under the hood in Canvas and SVG and I will be also sharing my experience building labeled arrows in Excalidraw - A virtual free Open-Source collaborative end-to-end encrypted canvas-based editor for sketching hand-drawn diagrams.

Create React App (CRA) was a game changer in garnering React adoption. Prior to the release of CRA, the experience of setting up a React app was more about configuring webpack than it was actually writing React code.Now that the React docs no longer list CRA as a suggestion on the “Start a New React Project” page, and additionally recommend you pick a React-powered framework, the getting started experience is once again fragmented.CRA was never meant to be how you built a full-featured React app anyway. It was a starting point, and a really good one. Inevitably many developers (such as myself) used CRA to build websites, and lots of them.

I've always avoided trying to do sales pitches for Redux, and tbh most of my time has been spent telling people when they _shouldn't_ use Redux :) But I still see lots of folks asking "_when_ should I use Redux?", and "how does Redux compare to $OTHER_TOOL?". So, I figure it's worth actually doing a talk where I cover the actual benefits and reasons to consider using Redux today.

Twitter influencers would have you believe that if you just use the semantic html tag for elements instead of a div, your components will be accessible. but there’s a lot more that goes into it!Let’s zoom in on one component from GitHub (one that you’ve probably used before!) and look at all the accessibility considerations involved and interesting challenges in implementing them.