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.

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.

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.

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.

Sam and Ryan read and discuss the latest update from React Labs.

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.

Ryan and Sam discuss the purpose and usage of the useOptimistic() hook, a new experimental API from React.

Ryan and Sam discuss the purpose and usage of the cache() function, a new experimental API from React.

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.

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](https://mostlytechnical.com/).

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.

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.

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.

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.

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.

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.