Channel
Interviewed Person
Rich Harris
Rich Harris joins the podcast to discuss his talk, fine-grained everything, exploring fine-grained reactivity, frontend performance, and the real costs of React Server Components and RSC payloads. Rich explains how Svelte and SvelteKit approach co-located data fetching, remote functions, and RPC to reduce server-side rendering costs, improve developer experience, and avoid unnecessary performance overhead on mobile networks. The conversation dives into async rendering, parallel async data fetching, type safety with schema validation, and why async-first frameworks may define the future of JavaScript frameworks and web performance. --- Links X: https://x.com/Rich_Harris Github: https://github.com/rich-harris Bluesky: https://bsky.app/profile/rich-harris.dev --- Resources Modern front-end frameworks like Svelte are astonishingly fast at rendering, thanks to techniques such as signal-based fine-grained reactivity. But there's more to performance than updating the screen at 60 frames per second. In this talk, we'll learn about new approaches that help you build fast, reliable, data-efficient apps. Slides: https://fine-grained-everything.vercel.app/1-1v --- Fill out our feedback form to help us improve PodRocket! https://forms.gle/xHm5PdAasfYqXYzT7 --- Chapters 00:00 Introduction with Rich Harris 01:00 Framing Frontend Performance and React Server Components 03:20 Choosing Frameworks vs Thinking About Performance 05:00 Why React Server Components Are a Brilliant Idea 06:45 The Mental Overhead of Server vs Client Components 08:40 Demo Explanation and RSC Payload Size 10:15 Why Servers Re Render More Than Necessary 12:00 Fine Grained Everything Explained 13:30 Asking Only for the Data That Changed 15:00 Introducing Remote Functions and RPC 17:00 Developer Experience Without Server Client Boundaries 18:45 Using Async Directly Inside Components 20:30 Parallelizing Async Work Automatically 22:45 Avoiding Waterfalls and Uncoordinated Updates 24:30 Comparing Load Functions vs Co Located Data 27:00 Type Safety, Inference, and Validation First APIs 29:30 Protecting Server Functions From Bad Data 31:45 Server Side Rendering Costs and Recomputing Data 34:00 Commands, Queries, and Explicit Data Invalidation 36:30 Forms, Mutations, and Re Fetching Everything 38:45 Performance Focused User Base and Framework Direction 41:00 Defaults, Tooling, and Discoverability 43:15 Agents, AI, and Framework Design 45:00 Is Fine Grained Reactivity the Future 47:00 What Developers Can Do Right Now 48:00 Closing Thoughts --- 🎙 Listen to PodRocket 🎧 Spotify: https://open.spotify.com/show/6oFuKu8... 🎧 Apple Podcasts: https://podcasts.apple.com/us/podcast... 📺 Subscribe on YouTube: @LogRocket Follow on Socials ➡️ Noel Minchow, Host ➡️ Michael Hladky, Guest ➡️ Elizabeth Becz, Producer ➡️ LogRocket, PodRocketPod --- What does LogRocket do? LogRocket provides AI-first session replay and analytics that surface the UX and technical issues impacting user experiences. Start understanding where your users are struggling by trying it for free at LogRocket.com.
Hello and welcome to Pod Rocket, a web development podcast brought to you by Log Rocket. I'm Null and today I'm joined once again by Rich Harris. Uh he's currently a software engineer at Verscell. You probably know him as the creator of Spelt. Uh we're here to talk about a talk he recently gave at the Performance Now conference um titled Fine Grain Everything. How's it going, Rich? It's going great. How are you? >> Uh I'm good. I'm good. I'm excited to jump in. It's always it's always a pleasure. you're uh a very knowledgeable guest to have on. So I always I always
appreciate these ones where we can we can get in a little bit deeper here. I was struggling a little bit with how to frame this one because in in the talk you kind of set up like you know uh a little React demo. Um you kind of talk about some of the shortcomings with uh React server components and why why it's kind of tricky to know what's going on there. Um and I think you kind of uh bring up a couple distinct problems. um one in is like the developer experience in using React server components and then like this the kind of performance
overhead of the RSC payloads and all this stuff you've got to worry about. I want to start there a little bit. Do you think those are the things that people are really like thinking about now when they're talking about front end frontend performance like that overhead of the exchange between the server and client and what that's going to cost in a given framework like is that what most people are thinking about when they're talking about this stuff? Some people certainly are. Honestly, I I think most people aren't really thinking in these terms at all when they're choosing a framework. They're just choosing the thing that is
going to enable them to be productive. And I I think it's more on us as the creators of these tools to be thinking deeply about about the impact of that. >> Yeah. Um, you know, are we designing primitives that are going to naturally result in robust and performant websites or are we going to create um primitives that, you know, inadvertently create extra work for our servers and and result in more data being transferred over, you know, our our fragile mobile
networks, >> right? >> And, you know, that that's that's really where um where that talk began. I think that there's going to be complexity overhead from the history where it was just ah single page app. We're going to make API calls, the data is going to come down, we're going to kind of update everything as necessary. Um, and like you know, at least feels to me like the dialogue is kind of one around like how does one mitigate that complexity the most effectively? Do you think we'll eventually get to a a a point where it
just it feels so kind of innate and the muscle memory is so there that it's not really a thing we have to think about kind of where we where we'd hit on in this maturity of you know like the single page apps of old or do you think there will always be a little bit of kind of um mental complexity? I mean it it it's certainly my hope that as as we go about this process of better understanding what problems we're facing and thinking deeply about what sort of
tools are best designed to address those problems that eventually you sort of you kind of just land on the things that feel the natural. >> Yeah. Yeah. And and like when you have the right tools in your tool belt, the complexity starts to kind of melt away. Like a lot of complexity that [clears throat] you see in code bases is really an artifact of >> people kind of fighting with their tools. Like there's a little bit of a mismatch between what they're trying to do and what the tool wants them to do.
Um and so yeah, I I you know, I think as a as a community we've learned a tremendous amount over the last decade. And I know it's sort of fashionable to decry some of the innovation that's happened over the last decade because you know the innovation is itself seen as a form of complexity. Um but really when you look at what we're able to build with the tools that we have today versus what we were able to build 10 years ago, it it truly is night and day. So I'm I'm just naturally inclined
