The podcast discusses abstractions in frontend and backend frameworks, the unique aspects of JavaScript, why frontend frameworks should have more backend features, the importance of standardized interfaces, and how the frontend should drive everything in the backend. They also touch on React Server Components and the concept of types flowing from the database to the frontend.

Sam and Ryan discuss the interactive study of queueing strategies in HTTP, covering FIFO, LIFO, priority queues, and active queue management. They compare different queues and explore the importance of efficient queuing in server technologies and the impact of serverless architecture.

Sam and Ryan discuss the new features in React 19 that will specifically benefit developers building single-page applications. They talk about how Suspense and Transitions let developers "teach" React about when their apps are in a loading or a pending state, how Client Actions improve upon using events in React 18 to handle data mutations, and how Actions enable React Components to automatically render and discard optimistic updates without any knowledge of the application's data layer. They also discuss several new Hooks like useOptimistic, useFormStatus, useActionState, and useOptimistic.Timestamps:0:00 - Intro2:19 - How SPAs are built in React 185:29 - How Suspense made loading a first-class concept in React7:48 - The problem with data writes in React 1810:37 - What are Client Actions?12:05 - What does it look like to use Actions?14:13 - What are the benefits of Actions?18:46 - How does React 19 change the Optimistic UI story?29:40 - Working with Transitions outside of Actions36:06 - The useActionState Hook37:51 - Using Transitions to keep the old UI rendered and responsive41:25 - How Transitions enable better composition patterns in third-party libraries43:55 - Building a SortableList that flips between being controlled and uncontrolledLinks:React Unpacked: A Roadmap to React 19

Sam tells Ryan about a recent talk he gave at BigSkyDevCon. They chat about how backend frameworks are raising the ceiling of what UIs they’re capable of delivering, how frontend frameworks are raising the floor of what backend features they come bundled with, and what each community can learn from the other.Timestamps:0:00 - Intro4:23 - Recap of Ryan Florence’s talk6:49 - Overview of "High floor, high ceiling"10:02 - Cohesion is the biggest strength of backend frameworks17:10 - Why doesn’t Rails for JavaScript exist?23:48 - Locality of behavior is the biggest strength of frontend frameworks33:14 - The use of lexical scope in React50:27 - Which community is raising both the floor and ceiling the most?Links:"High floor, high ceiling" talk

Sam and Ryan talk about the difference between the costs of building a feature and the benefits that feature brings to our end users. They discuss how libraries and frameworks can lower the technical cost of building a given feature, how Ryan Florence framed this calculation in his talk at Big Sky Dev Con, and how sometimes developers’ opinions and tastes about tech can smuggle their way from the cost side of the equation into the benefit side.Topics include:0:00 - Intro6:53 - How Ryan Florence framed the problem in his talk “Mind the Gap”14:38 - How frontend frameworks and backend frameworks both have their own ways of crossing the network gap19:11 - How Network-Sensitive Interactions force technologies to grapple with both server and client environments23:02 - How React is trying to lower the cost of moving interactions between the server and client with Server Components and Server Actions26:53 - Why “Use the right tool for the job” doesn’t capture the dynamic requirements of living software31:53 - How discussions about the product benefits of a feature and the technical costs of that feature are often conflated with each other34:08 - A thought experiment from economics that highlights how uncertainty plays a role in the estimation of product benefits56:54 - How to think about tech choice independently of the estimation of product benefitsLinks:"Mind the Gap" by Ryan FlorenceZero-JavaScript View Transitions in Astro

Ryan tells Sam about his experiments with using the new View Transitions API in a React photo gallery app. He talks about how he likes the flexibility of the API, how to think about integrating it into any client-rendered app regardless of the framework, and how he used a Promise with an Effect to tie a View Transition to a React Transition.Topics include:0:00 - Intro1:11 - What it’s like to integrate View Transitions with React7:30 - How View Transitions work16:09 - Building a gallery that animates photos across page navigations19:38 - How to use startViewTransition for enter/update/exit animations26:52 - Using a Promise to link a View Transition to a React Transition43:02 - Do View Transitions replace framework-specific animation libraries?45:17 - Using DevTools to preview and tweak transitionsLinks:easings.netIonic Framework's animation curvesShu’s next-view-transitions library

Sam and Ryan discuss setting up an in-browser code editor with CodeMirror for blog posts, using Radix Themes for styling, refactoring Tailwind to Radix Themes, and the challenges and benefits of theme integration in their projects.

Sam and Ryan discuss throw as a versatile JavaScript feature, not limited to error handling. They compare error handling to throw-try/catch, explore Next.js use of throw for control flow, and debate adding dynamic features to static sites.

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