Frontend First

Ryan talks to Sam about reproducing iOS's new image background treatment for his Open Graph Preview tool, opengraph.ing. They talk about different approaches for generating gradients from images, including finding the vibrant color of an image, luminosity-weighted averages, k-means clustering, and more.Timestamps:0:00 - Intro3:07 - Apple's new OG image gradient10:06 - Luminosity-weighted average14:22 - Finding the vibrant color of an image21:41 - Contrast ratios on favicons32:21 - K-means clustering41:25 - Refactoring UI tip about rotating the hueLinks:Open Graph PreviewRefactoring UI

Sam and Ryan talk about React 19's useActionState hook. They discuss how adding async functions to a plain React app introduces lots of in-between states that developers must grapple with, and how useActionState allows React to collapse and eliminate these states, bringing the simplicity of React's sync mental model to our async code.Timestamps:0:00 - Intro1:51 - How React normally eliminates state in synchronous apps8:20 - How useActionState lets React eliminate state in asynchronous apps18:17 - Why you shouldn't just pass server actions into useActionState23:00 - TCP/IP and UDP analogy26:39 - Thinking of useActionState like enqueue34:55 - Why the term "reducer" is too loaded for best understanding useActionState51:07 - How useActionState helps you build a Todo app that stays responsive during pending actions

Sam and Ryan talk about using Cloudflare Tunnel for local development, the new React Compiler beta release, and why reading or writing refs during render violates the rules of React.Timestamps:0:00 - Intro1:42 - Cloudflare Tunnel7:06 - React Compiler14:21 - Reading or writing refs during renderLinks:Cloudflare TunnelReact Compiler Beta releaseReact Docs Pitfall on refs

Sam and Ryan talk about building a useAnimatedText hook that can animate streaming text. They also discuss how React code that uses state changes to approximate events can be simplified, and the benefits of having escape hatches when building UI with Catalyst.Timestamps:0:00 - Intro1:22 - Catalyst and escape hatches16:03 - Building a useAnimatedText hook (aka useBufferedText)54:10 - Avoiding using state changes to approximate eventsLinks:CatalystSam's Tweet about useBufferedText and AnimatedScrolleruseAnimatedText recipeIntl.Segmenter on MDNDavid K's Tweet on eventsRicky's Tweet on Intersection ObserverBuild UI's new course

Sam and Ryan talk about how frameworks and infrastructure evolve with each other, using Next.js as a representative example. They discuss how hosting providers like Heroku have always imposed certain constraints on apps, what features those constraints enable hosting providers to support, how burdensome those constraints are across different frameworks, and how frameworks that add infra-specific APIs can best communicate the costs of those APIs and benefits they enable.Timestamps:0:00 - Intro3:03 - Heroku and the Twelve-Factor App7:39 - GitHub Pages and static sites13:57 - Serverless and JAMstack17:30 - Vercel and CDNs, self-hosting, and Next.js19:00 - How framework APIs can nudge an app towards a particular hosting solution23:09 - What constraints does Next.js impose on your app (e.g. middleware doesn't run node), and what benefits do those constraints give you?36:13 - How Next.js APIs are motivated by wanting to tease apart static and dynamic code, in an attempt to support the needs of any web app with a single stack40:33 - What is the relationship between frameworks and infra?47:37 - How can frameworks that add infra-specific APIs best communicate the costs of those APIs and the benefits they enable?Links:The Twelve-Factor App

Tom Occhino, Chief Product Officer at Vercel and former Engineering Director at Facebook, joins Sam to talk about the pivotal moments in React's history. He talks about how React popularized the ideas of declarative rendering and unidirectional data flow, how GraphQL furthered React's goal of co-locating all the concerns of a particular piece of UI, the problems that GraphQL led to at Facebook and how Relay solved them, and how Suspense, Server Components, and PPR are the generalized spiritual successors to the stack used at Facebook.Timestamps:0:00 - Intro2:53 - Declarative rendering as React's legacy8:12 - How GraphQL enabled complex components to be fully self-contained20:12 - How React's goal has always been to co-locate all the concerns of a particular piece of UI22:58 - The problem with co-locating GraphQL with components, and how Relay solved it26:28 - How RSC is the generalized spiritual successor to BigPipe and GraphQL34:46 - What PPR is, and how it and Suspense fit into this story55:55 - The general paradigm shift of getting static code to the device as soon as possibleLinks:Tom Occhino with Ben DunphyReact: The DocumentaryReact Roundtable with Andrew Clark and Sebastian MarkbågeTom Occhino on Twitter

Sam and Ryan talk about render props in React. They discuss where they came from, how Hooks superseded them for sharing stateful logic, how data attributes compare to them for customizing styling, and how for certain complex components like forms they're still a great solution for accessing slices of internal state.Timestamps:0:00 - Intro3:40 - Where did render props come from?6:01 - How hooks replaced many use cases for render props8:14 - Using render props for custom styling10:32 - Data attributes vs. render props for custom styling16:43 - Using render props to peek into an uncontrolled component's internal state21:05 - Forms example and using render props for a smaller public API24:10 - React docs mention of render props25:48 - Where render props shineLinks:Headless UI MenuRadix FormsReact Aria FormsReact docs - Render propsOur upcoming course on React Component PatternsEmail SamEmail Ryan

Sam and Ryan discuss controlled and uncontrolled components in React. They talk about how uncontrolled components can be thought of as components that manage their own internal state, why you should model your complex React components after the simpler APIs of native HTML elements like inputs, why you shouldn't try to make components that are both controlled and uncontrolled, and why making a new component boundary is sometimes all you need to make your custom components behave more predictably.Timestamps:0:00 - Intro1:41 - What are controlled and uncontrolled components?6:11 - How to change a component from uncontrolled to controlled8:48 - How do you decide when to use a controlled or uncontrolled component?12:00 - Sortable table example and a single source of truth15:27 - Is it always either controlled or uncontrolled?21:09 - Color picker example and not exposing internal state28:46 - Sortable list example with Framer Motion39:45 - Component boundaries and wearing two hats: the library author vs. library consumer41:43 - How do you know if you are using the wrong approach?Links:New course: Advanced React Component PatternsReact docs: Controlled and uncontrolled componentsReact docs: Storing state from previous rendersEmail SamEmail RyanFrontend First on Twitter

Sam and Ryan talk about the pattern of building unstyled components with React. They discuss why unstyled components were created, how they improve upon composition patterns from UI libraries like Bootstrap, how they can be used to share behavior and logic without prescribing any styling opinions, and how they fit into a larger collection of React patterns that can be used to build more powerful components that avoid premature abstractions.Timestamps:0:00 - Intro1:36 - What are unstyled components?2:24 - How do unstyled components improve upon earlier patterns?6:44 - Why would you want to use an unstyled component?9:58 - How can you compose an unstyled component with a styled component?16:41 - How to decide which pattern is best suited for the code you want to share19:36 - Using patterns that preserve React's locality of behavior24:49 - How do you know if an abstraction is good?32:54 - Build UI's upcoming course on Advanced React Component PatternsLinks:Build UI's newest course: Advanced React Component PatternsSam's YouTube video on Recursive ComponentsEmail SamEmail Ryan

Sam and Ryan talk about what sorts of capabilities a tool should have to be considered a web framework. They discuss how frameworks tackle the complexity of getting different systems to communicate with each other, how good frameworks embrace the strengths and patterns of the language they're written in, and why frameworks and services are not in opposition to each other.Timestamps:0:00 - Intro3:58 - Adapter pattern and cohesive boundaries9:43 - Rails is Omakase13:47 - Configurable, but still cohesive17:04 - Frontend frameworks try to “work with everything”21:42 - Does composition mean a React framework will look different than Rails?29:29 - Why taste still matters34:20 - A framework is a shell of adapters and a brain that coordinates them35:16 - When using services, complexity still exists in the in-between37:59 - A fullstack dev is someone who acknowledges and understands how all the parts come together44:06 - Tweets about the hard problems that Laravel tackles, and the deep design it took to get there49:15 - Frameworks should embrace the strengths and patterns of their language and ecosystem50:35 - Why RSCs and Server Actions mean the “Rails for JS” may end up looking nothing like Rails52:11 - Why users of a “fullstack framework” shouldn't even care about where the code is running55:31 - Why libraries or services that are easy to install and set up are not a replacement for frameworksLinks:Sam's BigSkyDevCon talkRails is omakasePovilas' Laravel tweetMary's Laravel tweetBuild UI's upcoming React Component Patterns courseEmail SamEmail Ryan

Sam joins Lane Wagner in a crossover episode with the Backend Banter podcast. They talk about abstractions in frontend and backend frameworks, what JavaScript is doing differently from other languages and frameworks, why the frontend should drive the backend even if you're building in a server-side framework, and what's so special about React Server Components.Timestamps:0:00 - Intro2:12 - When abstractions leak6:37 - Recap of Sam's BigSky talk10:51 - What is JavaScript doing differently?19:10 - Why frontend frameworks should have more backend features24:04 - Strong opinions on a library level30:29 - Shipping more standardized interfaces37:06 - The frontend should be driving everything in the backend39:12 - Your types should flow from the database to the frontend, but not your product decisions46:53 - React Server ComponentsLink:Backend Banter

Sam and Ryan read and discuss a fantastic interactive blog post about queueing in HTTP written by Sam Rose.Timestamps:0:00 - Intro6:57 - Queueing: An interactive study of queueing strategies9:05 - Why do we need queues?13:16 - FIFO and timing out17:55 - LIFO20:58 - Priority queues25:21 - Active queue management29:08 - Comparing queues36:32 - ConclusionLinks:Queueing: An interactive study of queueing strategiesUp and Down the Ladder of Abstraction

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 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

Sam and Ryan share their learnings from working with Server Components in earnest over the past week. They talk about how Server Components can simplify client components by passing them props, why it makes sense for a component that can run everywhere to be a Server Component by default, whether RSC is causing unnecessary churn in the ecosystem, and how to think about choosing Server Components vs. client components for a given task.Topics include:0:00 - Intro0:48 - Lessons learned from building a D3 chart as a React Server Component22:04 - Are Server Components causing unnecessary churn in the JavaScript ecosystem?32:14 - Do Server Components replace Client Components?40:13 - Ryan's thoughts on rewriting some client-side data fetching code with Server ComponentsLinks:Ryan's Build UI course on Server ComponentsSam's D3 Chart video on YouTube

Sam shares some recent learnings around hydration mismatches when rendering time zoned dates on the server and the client. He talks about using the TZ environment variable to reproduce the issue locally, and how he solved his problem by avoiding impure format and transformation functions from date-fns.Topics include:0:00 - Intro0:50 - Sever vs. client time zone mismatches, and the TZ environment variable14:34 - Which date-fns functions are impure?23:56 - Using intervals and comparison to remove impuritiesLinks:date-fnsdate-fns-tz

Sam and Ryan talk about using MJML to design, build and send transactional emails with React directly in the browser. They also chat about how to use Framer Motion to get a CSS radial gradient to follow the mouse cursor and the differences between React state, refs, Motion Values, and external stores.Topics include:0:00 - Intro1:10 - Building in-browser email previews with MJML18:50 - Using radial gradients and Motion Values to build a moving spotlight treatmentLinks:MJMLReact EmailMaizzleSam's Spotlight video on YouTubeSpotlight code recipe

Sam and Ryan talk about building an animated tabs component with CSS's mix-blend-mode property and Framer Motion's layout animations. They also talk about how to use the URL constructor in JavaScript to help implement secure arbitrary redirects, as well as their initial reactions to new framework APIs that blur the lines between server and client code.Topics include:0:00 - Intro0:35 - Animated tabs with mix-blend-mode exclusion and Framer Motion's layoutId14:26 - Using the URL constructor for arbitrary redirects after login27:12 - Reacting to Rich Harris' discussion on how new framework APIs are exposing hidden API routesLinks:Dan Hollick's thread on blending modesAnimated Tabs recipeAnimated Tabs YouTube videoURL constructorRich Harris' talk

Sam tells Ryan about his experience building an animated toggle with React Aria Components. He gives his first impressions of the new library and discusses some of functionality included from the lower-level React Aria hooks. Ryan also talks about his recent use of GitHub Copilot.Topics include:0:00 - Intro1:15 - Using GitHub Copilot to keep you working at higher levels of abstraction8:15 - react aria components toggle. pressed state. When to use browser defaults vs headless for form inputs.Links:React Aria ComponentsSam's YouTube video on building an animated toggleBuild UI Recipe: iOS Animated Switch

Sam and Ryan talk about updating Build UI to support lifetime memberships. They chat about the site's current architecture, the strengths and weaknesses of objects vs. functions, how the full stack JavaScript community could benefit from a proper model layer like ActiveRecord, the challenges of using GraphQL on the backend, Prisma, and more.Topics include:0:00 - Intro1:09 - Current architecture + single purchase6:30 - Rails model layer. OOP vs functional13:55 - What are classes good at, what are functions good at23:53 - Composition vs. inheritance31:44 - graphql. overfetching is not a problem on the backend. prisma.Links:Go Ahead, Make a Mess by Sandi Metz

Ryan and Sam use some recent Twitter conversation to guide a discussion about the design and purpose of React Server Components. They talk about how client trees and rendered on the server today, why a server-side rendered prepass is wasteful in light of RSC, how hydration of a client tree works, why RSC are never hydrated, how RSC is a purely additive technology, how server and client components can be interleaved, how RSC can be refreshed in-place without loss of any client state, how RSC fits into the React paradigm despite having a unique syntax and set of capabilities, and other topics.Topics include:0:00 - Intro4:39 - How server-side rendering and hydration work today14:51 - How RSC works, and why they're never hydrated24:48 - What is the React paradigm, and how RSC fits into it27:54 - How RSC are revalidated33:52 - Why the goal is not to eliminate Client components38:53 - What it means for Server components and Client components to compose with each otherLinks:Dan Abramov's RSC AMA threadIllustration of server and client trees

Sam and Ryan share their thoughts on the latest server-centric developments taking place among React frameworks like Remix and Next.js. They discuss the declarative nature of HTML and HTTP, the evolution of frontend development from imperative libraries like jQuery to declarative libraries like React, why developers started creating SPAs in the first place, the power and limitations of server-side links and forms, whether the frontend community has overcomplicated web development, the problem with progressive enhancement, React Server Components, how server-centric approaches to building rich web experiences like Phoenix LiveView compare to the approaches in the React ecosystem, and other topics.Topics include:0:00 - Intro3:02 - The strengths of HTML and HTTP11:28 - Is frontend development overcomplicated?21:18 - Progressive enhancement33:33 - The nervous system of a web app46:00 - React Server Components53:46 - Server-side approachesLinks:My first Remix app on Build UI

Sam and Ryan have an open-ended conversation about different caching APIs and what kinds of benefits they might afford app developers. They discuss transparent caching layers, cache keys and surrogate keys in systems like Fastly, how SSG is effectively a high-level caching solution, Next.js 13.2's cache API, Russian doll caching in Rails, whether a fetch cache is too high-level of an abstraction, and other topics.They also have a retro on choosing to use Hygraph as Build UI's CMS, discussing some surprises they encountered including the fact that Hygraph favors high availability over consistency (stale reads, which can cause issues with serverless) and rate limits (which causes issues with SSG).Topics include:0:00 - Intro1:18 - Retro on Hygraph16:27 - Caching conversationLinks:Build UIHygraph

Sam and Ryan chat about their recent work migrating Build UI from a statically generated site to a run-time server-rendered app using Next.js. They talk about their past experience working on server-rendered apps, the problems that static sites were created to solve, and the tradeoffs involved within the static-to-dynamic continuum.Topics include:0:00 - Intro2:05 - How we built EmberMap with SSR + caching buckets with Redis8:36 - How we launched Build UI as a static site with dynamic workarounds13:15 - The problem with static-only sites14:50 - First potential solution: client-side rendering of dynamic data18:01 - Second potential solution: multiple versions of each page25:25 - Third potential solution: run-time server rendering35:44 - Why we left static39:55 - Details and challenges of moving to getServerSidePropsLinks:Build UI

Ryan talks about a demo he built in Next.js 13 with React Server Components. He explains how RSC driven by the URL eliminated client-side states, how he used React 18 Transitions to enhance the UI, and how he was able to fine-tune the experience differently for the initial render vs. subsequent client-side navigations.Topics include:0:00 - Intro1:37 - Overview of Ryan's user search page14:06 - React 18 Transitions and how RSC eliminates client states28:25 - How to change the UX for initial server navigations vs. in-app client navigations while still having one entry point for your data37:01 - Why Next.js 13 encourages you to learn about the Suspense and Transition primitives43:33 - What would a simple boilerplate for RSC look like?49:18 - Do the benefits of backends-as-a-service go away with RSC?Links:Ryan's demo on Twitter

Ryan and Sam read a recent article by Derrick Reimer called “Ship Small, Ship Fast” and offer their thoughts on it. They discuss how implementation details can lead to reductions in scope, the relationship between shipping small and agile, and why quickly getting the first steps of a user flow into production is a good protocol for software teams to follow.Topics include:0:00 - Intro2:06 - Ship Small, Ship Fast read-a-long7:22 - ReactionsLinks:Ship Small, Ship Fast by Derrick ReimerDerrick Reimer on SPA architecture with Elm and GraphQL

Sam and Ryan talk about seams in TypeScript programs where lies can sneak in. They chat about how API calls, form inputs, and URLs all relate to this problem, the similarity between drifting types and service mocks in testing, zod, and how type-safe languages like Elm eliminate this problem entirely.Topics include:0:00 - Intro2:41 - Lying in TypescriptLinks:ZodElm language

Ryan tells Sam about a side project of his that involves running the text-to-image deep learning model Stable Diffusion on his laptop in response to web requests. Ryan asks Sam questions about animating this UI, including how to animate indeterminate progress, how to avoid unintentional layout animation, and how to automatically repeat a set of items while scrolling rather than stopping at the end.Topics include:0:00 - Intro0:24 – Overview of Ryan's Stable Diffusion project -9:36 – Strategies for animating partially indeterminate progress -18:25 – Brainstorm of the API for the headless version of a partially indeterminate progress Hook -25:32 – Unintentional layout animation during window resize -28:29 – Infinite scrolling of a finite array of items -38:52 – Discussion of the need for more high-level Framer Motion examples -Links:Framer Motion docs

Ryan talks about the pros and cons of exposing Build UI's environment-independent CMS from Hasura via schema stitching. He also talks about writing a Postgres function to add a derived field to a database model. Sam shares a debugging story about fixing his personal website due to a breaking change in a minor version of npm.Topics include:0:00 - Intro1:50 - Debugging Sam's personal website due to a breaking change in npm related to peer dependencies18:00 - Pros and cons of using a Postgres function to derive the active status of a Build UI subscription28:42 - Exposing a Hygraph CMS through Hasura via schema stitching, and the fantastic TypeScript DX that came as a resultLinks:HasuraHygraph