Frontend First

Sam tells Ryan about his experience setting up an in-browser code editor with CodeMirror that he plans on using for blog posts and code recipes, as well as what he thought about using Radix Themes for the first time in earnest on a side project of his currently styled with Tailwind.Topics include:0:00 - Intro4:01 - Building an authoring tool with CodeMirror18:47 - Refactoring Tailwind to Radix ThemesLinks:CodeMirrorSam’s YouTube video on Radix ThemesRadix Themes docs

Sam and Ryan talk about why it’s better to think of throw as a general-purpose JavaScript language feature rather than something that should only be used for error handling. They discuss the ambiguity around the phrase “error handling”, situations that call for dealing with errors locally vs. globally, and how throw can be useful for non-error control flow. They also discuss the problems with trying to shoehorn dynamic features into a static site.Topics include:0:00 - Intro4:07 - Error handling vs. throw-try/catch23:34 - Errors vs. Exceptions31:52 - How Next.js uses throw for non-error control flow40:44 - Adding a dynamic feature to a static siteLinks:Global progress in Next.jsWhat color is your function

Sam and Ryan discuss the core values of the Next.js framework, and how those values motivate several of the framework’s design decisions. They talk about caching, why layouts don’t have access to the URL, and why the router doesn’t expose navigation events, as well as how developers should think about extending Next’s functionality with their own application code.Topics include:0:00 - Intro2:58 - Why don’t layouts re-render in Next.js?7:10 - Push-based vs. pull-based rendering8:56 - Thinking about re-renders in a pure React app11:07 - Why Server Actions need to call the revalidate* APIs12:26 - Why doesn’t Next.js pass the request to every page and layout?31:40 - Immediate-mode rendering vs. “Do the least amount of work possible”51:54 - Is opting-in to more re-renders framework fighting?53:44 - Helping users by communicating the philosophy56:25 - Why doesn’t Next.js expose global router events?1:00:17 - Why it’s important to understand Next’s design decisions when choosing it for your next project

Sam talks to Ryan about refactoring an MDX blog post to a React Server Component. They discuss how RSC’s ability to render server-side content with “client-side holes” turns out to replace MDX for many uses cases. They also talk about other tools that are (surprisingly) a conceptual subset of the RSC architecture, such as custom Webpack loaders.Topics include:0:00 - Intro5:05 - The Next.js happy path for MDX: Local files11:15 - Exploring remote MDX content with mdx-remote14:46 - Separating the serializable parts of MDX from the runtime imports17:13 - Realizing that RSC covers the same problem space, and ditching MDX26:50 - Exploring other APIs and plugin ecosystems that RSC could replace: Webpack loaders, next/image, and Liquid templates32:11 - React’s vision for RSCs35:18 - How RSCs could replace build-time plugin APIs44:51 - Replacing MDX with Markdoc, Shiki, and custom node code during renderLinks:MarkdocShiki

Sam and Ryan read and discuss the latest update from React Labs.Topics include:0:00 - Intro5:26 - Opening6:18 - React Compiler27:27 - Actions51:44 - Asset loading1:13:06 - Next Major Version of React1:15:42 - ActivityLinks:React Labs blog postSam’s video on Strict Mode

Sam and Ryan discuss the intuition behind React Transitions, and why React’s new useOptimistic hook is a good fit for building a URL-driven filter panel that stays fully responsive to client interactions.Topics include:0:00 - Intro1:12 - The problem: In a world of Server Components, URL updates are blocked by a server-side roundtrip10:44 - Attempted solution: Use the browser’s Native History API (history.pushState)15:03 - Realization: The source of truth flips from server to client during the transition – which is exactly what useOptimistic was designed for17:54 - Unwinding our mental model of client-first React apps by thinking about how HTML-only checkout forms work21:44 - The intuition behind React Transitions, and how they put our UI into a state of preparation30:39 - How Transitions improve upon default browser behavior by keeping our current UI 100% responsive, and how useOptimistic solves the checkbox filter panel37:46 - Ryan’s take: It’s a bonus when tools make you feel smart, but it’s more important for them to not make you feel dumb

Ryan and Sam discuss the purpose and usage of the useOptimistic() hook, a new experimental API from React.Topics include:0:00 - Intro2:18 - Problem: RSCs require a server roundtrip before the UI can be updated10:13 - Solution: useOptimistic() lets you merge ephemeral client-side state with server-side data so you can update the UI during a Server Action or Transition14:03 - How useOptimistic() avoids the notion of identity by discarding the ephemeral state after the app settles21:17 - How useOptimistic() lets you safely “fork” state that eventually syncs with the server27:32 - Handling error states29:26 - Differences between useOptimistic() and Remix fetchers34:57 - How useOptimistic() lets you avoid managing a long-lived client-side cacheLinks:Ryan’s useOptimistic tweetRyan’s video on React Cache: Part 2

Ryan and Sam discuss the purpose and usage of the cache() function, a new experimental API from React.Topics include:0:00 - Intro2:29 - Caching in Next.js vs. React cache()8:11 - Why React invalidates the cache for each server request14:43 - How cache() enables colocation of data-fetching code16:14 - Using cache() to share CPU-heavy or I/O-bound tasks between components19:31 - Why cache() obviates the need for context in Server Components23:19 - The danger of module scope on the server27:54 - Why cache() is implemented with AsyncLocalStorage41:04 - Why cache() is part of React48:27 - Why Server Components don’t support cache()53:04 - How cache() eliminates waterfallsLinks:Ryan’s YouTube video on React Cache

Sam and Ryan talk about Advanced Radix UI, Build UI’s newest course. They also read and discuss a blog post that describes the RSC architecture in terms of two processes: React Server and React Client.Topics include:0:00 - Intro0:49 - Ceilingless libraries + Advanced Radix UI21:02 - Read and discuss: “RSC is React Server + Component”Links:Advanced Radix UI courseRadix UIRSC is React Server + Component

Ian Landsman & Aaron Francis join Sam to discuss React Server Actions & Server Components, why it's important to have one set of opinions, and yes, the infamous SQL Injection Slide at NextConf.This is a crossover episode with the excellent podcast Mostly Technical.Topics include:0:00 - The Most Memed Man on the Internet09:06 - High Floor vs. High Ceiling19:20 - What the Hell Is Next?23:22 - The Third Phase of React29:09 - Your App Is Not Unique35:23 - Server Actions & Server Components51:33 - CallYourMom.Com01:00:56 - Fat Models, Skinny Controllers01:14:16 - One Set of OpinionsLinks:Sam’s Next.js Conf talkReact is a programming language for UIs

Sam and Ryan talk about the key parts of Remix’s architecture in the context of the Work Journal app from Build UI’s latest course. They discuss how Remix’s conventions around Links, Forms, Actions, and Loaders allow developers to eliminate boilerplate and take advantage of the best HTTP has to offer, while still providing a seamless way to enhance their UIs using the full power of client-side React.Topics include:0:00 - Intro0:31 - The Work Journal app2:20 - Making dynamic pages with Loaders8:00 - How Remix relies on HTTP for routing12:30 - Making backend changes using Forms and Actions19:41 - How Remix’s comprehension of Loaders and Actions eliminates boilerplate25:20 - How Remix layers the full power of React on top of web fundamentalsLinks:Sign up for the Build UI NewsletterVideo on HTTP Session Cookies

Ryan continues to share the details behind his custom RSC implementation. He talks with Sam about how Server Actions allow the client to reference server-side code (in the same way client components allow the server to reference client-side code), how Server Actions are bundled and invoked, and the security concerns associated with blurring the lines between the server and the client.Topics include:0:00 - Intro0:52 - Ryan’s course on React Server Components3:06 - Motivating Server Actions, how to bundle them, and how to invoke them27:38 - Sending arguments via hidden inputs or closures, and security concernsLinks:Ryan’s React Server Components course

Ryan shares how building his own RSC implementation from scratch helped him better understand React’s new paradigm. He and Sam talk about how a client React app can fetch an RSC Payload from a server endpoint to update the UI, how an RSC server renders and bundles Client code that’s part of a Server Component tree, and how a client-side Router can be used to fetch new RSC trees based on the URL.Topics include:0:00 - Intro2:48 - Making a server endpoint that a client React app can use to re-render the UI15:42 - How the bundling step shims Client Components during a server render with a reference that the client app can later use to execute browser code35:16 - How the React Component API unifies server and client functionality in a single composable interface38:54 - How a client-side router can render different server trees based on the URL49:09 - Reference projects usedLinks:Simple RSCTangleVite RSCNext.js

Ryan and Sam talk about how to invalidate Next.js’ client-side cache when a different session makes changes to backend data, and ultimately discuss whether clicking a link to a URL vs. hitting refresh on that same URL should render the same page if no backend data has changed.Topics include:0:00 - Intro1:00 - Suspense boundary identity and the Await component11:07 - How to refresh RSC using a Server Action27:17 - The difference between a navigation and a page refreshLinks:Ryan’s Data Fetching with RSC courseRefresh App Router code recipe

Tim joins Sam to talk about his work on the new app router in Next.js 13. He explains how the app router leverages Server Components and React’s new cache API to bring a new level of composability to server-side code, how Server Actions are being designed to enable partial revalidation in a single round trip to the server, and how to think about UI updates as a result of server-side state changes.Topics include:0:00 - Intro2:53 - Rendering Server Components and the RSC payload21:49 - Composition vs. top-down data flow and the React cache53:35 - Revalidation after a user event and Server Actions1:06:37 - Revalidation after a server-side state change1:14:02 - Back and forward navigation1:21:43 - Caching layers1:30:53 - Current focus on stability, performance, education, and TurboPackLinks:Tim’s deep dive on caching and revalidatingNext.js docs on Caching

Sam and Ryan discuss how TypeScript helped them understand the mechanics of how props get passed from Server Components to Client Components, and how to properly type client component props if the prop starts out as a rich data type on the server. They also clarify some points from last episode’s discussion about the RSC payload.Topics include:0:00 - Intro0:40 - Clarifying what the RSC Payload actually is10:12 - Understanding prop serialization when passing props from Server Components to Client Components23:38 - How to define TypeScript types for serialized props, and Remix’s SerializeFrom helperLinks:Ryan’s RSC course on Build UI

Sam and Ryan explore different ways to think about the RSC architecture, including what problems RSC solve, why RSC are valuable even in a world without server-side rendering, and how React’s reconciliation phase enables RSC to make partial updates to the UI as a result of server-side events.Topics include:0:00 - Intro5:45 - What if RSC were introduced before SSR?10:54 - What does it mean to render RSC?25:41 - Why SSR does not apply to Server Components35:31 - Server-driven UI updates

Ryan shares his thoughts on how Server Actions and the useFormStatus hook are letting him build reusable pending UI for any form in his Next.js side project. Sam talks about how TypeScript prevents an entire class of data-loading bugs that have plagued single-page applications built with a client-side cache.Topics include:0:00 - Tailwind Connect2:38 - Using TypeScript to prevent data-loading errors19:27 - Building reusable form UI with Server Actions and useFormStatusLinks:Server Actions in Next.jsStyling a Radix Dialog with Tailwind CSS

Sam and Ryan share their thoughts on the recent React Roundtable with core team members Sebastian Markbåge and Andrew Clark. They talk about the evolution of Server Components from the perspective of solving the problem of fetching data in React apps, how SPAs have a lower baseline but higher ceiling in terms of the user experience they can deliver, and what they’d like to see from frameworks that are built on the RSC architecture.Topics include:0:00 - Intro0:36 - Recap of Server Components as a solution to data fetching in React11:47 - How Server Components improve the baseline user experience of React apps while also letting us layer in SPA-like enhancements20:11 - What features we give up with server-driven data fetching, and how can we get them back?29:13 - How RSC and Actions bring the setState-and-diff model across the network31:59 - What opinions are left to frameworks that are built on the constraints of RSC, and what would we like to see from them?Links:React Roundtable with Sebastian and AndrewBuild UI Newsletter

Sam and Ryan use some recent Twitter discussion on copying + pasting code (instead of abstracting it for reuse) as a springboard for a discussion about how their thinking on low-level UI components and design systems has changed over the years.Topics include:0:00 - Intro2:16 - Copy-paste vs. creating abstractions11:43 - How we used to build shared UI components15:34 - How we use UI components today22:42 - Is copy-paste the easiest way for developers to implement consistent design?27:41 - When should we create abstractions?37:15 - Designing copy-pasteable APIsLinks:Dan’s tweetBuild UI NewsletterSam’s Server Actions video on YouTube