943: Modern React with Ricky Hanlon (React Core Dev)

Scott and Wes sit down with Ricky Hanlon from the React core team at Facebook to dive into the latest features and APIs shaping modern React development. From transitions and Suspense to fetching strategies and future directions, this episode breaks down what’s next for React and how developers can take advantage of it. Show Notes 00:00 Welcome to Syntax! 01:20 Who is Ricky Hanlon. 02:10 Setting the Stage: Modern React APIs 02:48 Brought to you by Sentry.io. 03:12 Defining Transitions in React 05:08 Practical Examples of Scheduling. 08:23 useDeferredValue. 09:30 Suspense. 11:13 Fallbacks and animations. 12:35 How do you get psychological performance data? 13:39 Are these considerations reasonable for the average dev? 15:37 useOptimistic. 17:35 Removing delayMs (referred to as maxDuration in later iterations). 19:49 How to fetch data in React. 21:58 Is React now just Nextjs? 23:23 Will React give us a Signals-based state management? 24:44 The challenges of building in public. 30:12 Making LLMs cooperate with React. 32:05 The lifting will happen at framework level. 32:59 This is not time slicing. 35:47 Sick Pick + Shameless Plug. Sick Picks Ricky: iPhone 17 Pro Shameless Plugs Ricky: https://conf.react.dev/ Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Wes Bos?

  Welcome to Syntax. We got Ricky Hanlon on today. He is one of the core devs behind React. And we got him on today to talk about some of the new stuff in React, what's going on with it. Some of like the more, I'm going to say like modern React, you know, maybe talking about transitions and view transitions, maybe some suspense and hopefully some of the new performance stuff that they've been been cooking on, the dev tool stuff he was showing me earlier. I'm not sure if he's going to show us that or not, but I'm pinning him till right now. Some really cool stuff. So, welcome Ricky. Thanks for coming on.

• 0:34Speaker 01

  Yeah, thanks for having me. I'm real excited.

• 0:36Scott Tolinski?

  Yeah. And also I gotta say, before we start getting into anything technical, I am going to say you're going to have to leave the show because you have a bunch of Ohio State stuff behind you. And I am wearing an Ann Arbor, Michigan t-shirt today. So unfortunately, we're sworn enemies just because of college football.

• 0:54Speaker 01

  Yeah. Well, we are the national champions. So.

• 0:57Scott Tolinski?

  Yeah, I should not have said anything. Yes.

• 1:02Speaker 01

  Yeah, especially this season.

• 1:03Wes Bos?

  Yeah, I went to a CFL game, like Canadian football game this weekend. And like, there was like 20,000 people there and like, like, I'm pretty sure your high Americans high school games have more people come to it. It was kind of sad.

• 1:20Wes Bos?

  Cool. Give us a rundown of who you are and what you do.

• 1:24Speaker 01

  Yeah, so I'm Ricky. I work on the core team on React. Basically just think about user interfaces all day and user experience. Right now, I'm just planning for React Conf, which is coming up in a couple of weeks. I have a talk that I'm planning that I'm really excited about, but a little nervous about. There's a lot going on that it's really hard to get the messaging right. So I've been talking and a lot of the theme for that talk is going to be transitions and a lot of the like modern React features and what it looks like to build a modern React app. And so I've been doing, talking a lot about transitions and seeing what people understand about them and don't understand about them or how we can kind of clarify it. So that's kind of my main focus right now.

• 2:10Wes Bos?

  Sweet. Well, I would love to talk about that as well because I think like most people who use React, like you can make a component, you can throw some state in there, you could probably make a mess with the use effect. But there's this like whole, I dare I say like new or advanced API, which is surrounds transitions, deferred suspense, all of that stuff. So what I was hoping to do is like, let's, let's understand what those things are. And then maybe we'll get into some foot guns and performance and like possible issues that people listening might have and how we can solve them.

• 2:46Speaker 01

  Yeah, for sure. Love to dive in.

• 2:48Scott Tolinski?

  And if you want to see all of the errors in your application, you'll want to check out Sentry at sentry.io forward slash syntax. You don't want a production application out there that, well, you have no visibility into in case something is blowing up and you might not even know it. So head on over to sentry.io forward slash syntax. Again, we've been using this tool for a long time and it totally rules. All right.

• 3:12Wes Bos?

  All right. So give us your, your best explanation. I'm sure you live and breathe this all day is like, what's a transition in React?

• 3:20Speaker 01

  Yeah, you can think of a transition as a, I mean, as a UI transition. Fundamentally, it's kind of like, you can think of it as a, maybe a little bit like a transaction or like a background thread. So in native apps, you have a problem where you handle input events on the UI thread and that can cause stuttering and laggy UI if you do everything on the main thread. So it's very common to offload expensive things to a background thread. In JavaScript, we don't have a background thread. Everything is main threaded, right? And if you go back to, I was actually just watching the

• 4:03Speaker 01

  conference talk for React Conf in 2017 when we first introduced Fiverr. And that talk is really great because it talks about all of the problems for performance in apps and kind of walks you through the conclusion that the core concern for UI libraries for

• 4:23Speaker 01

  Innovating in the future and being able to handle this problem, handle this problem is scheduling. Being able to schedule different types of work like transitioning and that transition being like navigation or updating state or data on the server and then navigating or refreshing, refreshing, pull to refresh, right? These are all scheduling problems. And so the fiber rewrite and all of the features that we've been working on with like the big scary concurrent mode name, the concurrent features are really just scheduling features. How can you prioritize user input and defer transitioning the result of that input to kind of like a background thread? So that you can always handle user input as the highest priority.

• 5:08Wes Bos?

  Okay. And can you give us an example of, of what that might look like? To me, I'm just thinking in my head right now where you, you have an input box, you know? And, and as the user is typing, you're doing some sort of work that could possibly block the main thread. And then it is kind of weird to type into, but can you give us maybe a better example than that?

• 5:28Speaker 01

  Yeah, that's a, that's a good example. I think like historically, we've given that example maybe too focused on that example. Cause that example is generally explained as being like CPU bound, right? If you're like filtering a really large array, then as you're typing, you don't want the filtering the array or rendering the items to take too long. But if you think about like a type ahead, the primary way that people would do that is with a request, like an async request, right? And so how do you coordinate all of the different requests that you're going to be firing off on like each keystroke? So that the, you're not showing old results. One of the things that drives me nuts about UIs is when you like are typing in a search bar or a type ahead.

• 6:14Speaker 01

  And then just as you go to like click the result, it changes in the order. You click the wrong one. Ideally, transitions will help, can help you fix this because you'll be able to batch all of the requests and only update the results once. I think another great example is like if you have a table and you have different filters on the table. One thing that's like very common to do, especially if you're syncing it to URL params, one of the things that's common to do is like you click a dropdown, you click a filter, like filter out these items. And then one or two things could happen. If you're syncing it to the URL state synchronously, then you like click one of the items and then

• 6:58Speaker 01

  the dropdown like closes with the old value, not the ones that you selected. And then the, um, there's some time, maybe a fetch or something, and then the results of the table update. So that's a bad experience. What you want is to immediately update that filter to show what you, what the user clicked, like show feedback for the user interaction immediately. And then you can transition the results to the new results. It's kind of like a fundamental property of like UI design is that those results are going to take longer than rendering the like user feedback. We even have core web metrics for this with like IMP.

• 7:43Speaker 01

  A lot of these metrics around that separate the difference between like showing user feedback and then seeing the result of that feedback. And users have different expectations for what those are, for how fast your site is perceived. If you click on something and nothing happens for 200 milliseconds or in the word, in, in this example, like until the entire request comes back, which could take, you know, 500 or even a second to change, that's going to feel, it's going to be slow in that case. It's also going to feel slow. You won't be able to have really quick user input, um, user feedback and then transition to the result.

• 8:23Wes Bos?

  Okay. And how does, um, deferred and suspense fit into these things or how are they related to it?

• 8:31Speaker 01

  Used deferred value, I think of as kind of like. A way to defer at the read point instead of the write point. Where a transition is like when you're at the write point, you're in the click handler. You want, you already, you know that you can defer this state update or defer this mutation. And, and most of the time, the, that write point is happening either in your data fetching layer or in your router, right? You, you shouldn't need to, if you're using a suspense enabled router or data fetching, you shouldn't need to wrap your like router dot navigate in start transition. Router that navigate should happen with, as a transition. Uh, cause router navigation events are always transitioning the UI. Yeah.

• 9:16Speaker 01

  But a lot of times you'll be at the read point. Um, that you need to be able to defer some, defer part of the UI. So it doesn't block user input. And that's when you would use, like you use deferred value. And then suspense has a lot of things to it. The thing that really I'm trying to, uh, help people appreciate about suspense. Uh, right now is the batching behavior. So a lot of, of other frameworks that are out there say, like have suspense now. But I think they should have like, we have suspense asterisk, which is like, we have a, a component that shows a loading state, but doesn't do everything that React suspense does.

• 10:00Speaker 01

  So for example, we do a very controversial thing called throttling. Uh, which is if you, um, are loading a page and we show a fallback. We make sure the fallback is shown for at least 300 milliseconds. Because if you just flicker the fallback in as soon as the data is ready, say in 10, 50, 100 milliseconds, it feels slower than waiting 300 milliseconds to the user. Cause you, you wouldn't have a chance to see like the fallback content, right? All it looked like to you is just jank. And so we, we throttle, but the throttling gives us a lot of performance benefits.

• 10:41Speaker 01

  So for example, if you don't throttle and you're like doing something like reading layout in the DOM, well, then you're going to potentially have multiple updates. And that's multiple reads of the DOM and multiple layout computations. But if you were just to wait and batch everything and commit it all at once, then you'd only have one layout.

• 11:01Wes Bos?

  Oh, so that that 300 milliseconds gives you 300 milliseconds to wait around and see if hey, anybody else, anybody else want to update state or whatever in here?

• 11:13Speaker 01

  Yeah, and that's especially important when it comes to animations because for animations, you want to try to minimize the amount of fallbacks that you animate in, right? And so if you were to trigger an animation, if you let's say you have like two items in a feed and you are replacing those items with the content as fast as possible and those each one's triggering the animation of using document start view transition, you can only run one animation at a time. So that would result in like the if you had three items, it would result in three sequential 200 millisecond animations, which takes 600 milliseconds total. But if you can wait and batch them into one, then you have one, you have a 300 millisecond

• 11:57Speaker 01

  fallback and then you have one 200 millisecond animation and you're only have 500 milliseconds. So it's 100 milliseconds faster to wait a little bit longer until you can animate everything.

• 12:08Wes Bos?

  And you're saying that putting adding 300 milliseconds feels faster than having no like wait at all?

• 12:17Speaker 01

  Not the no wait at all. Showing the fallback, right? It'd be a like small amount of wait somewhere but somewhere between, you know, let's call it like 20 milliseconds and 300 milliseconds. Those just flicker, it's too fast for the user to perceive.

• 12:35Wes Bos?

  Okay, and where do you get this this data from? Like, are there people at Meta that are researching this and then they give you the scoop on on what they found?

• 12:45Speaker 01

  There are people at Meta, but there's people, there's like academic research in the UX and papers that you can look into and read up into like perceived performance. Skeletons in particular are very well researched and the research is basically like the faster you can show a skeleton, the so there's no like delay from user input to skeleton, that matters a lot. The amount of time that you show a skeleton, like a suspense placeholder, doesn't matter as much up to a certain point of like 500 milliseconds because the user's going to blame that on their network. They're not going to blame that on your app. If your app flickers, then that's a programming problem with the app. Like it feels.

• 13:30Speaker 01

  Like the user is accustomed to being able to like wait for server data. So showing the fallback, there's a certain amount of tolerance for showing it.

• 13:39Scott Tolinski?

  Yeah. So are these things that only very intense applications need to worry about? Like the average developer working on a React app? Like, how many of these features are they going to be working with on a daily basis?

• 13:53Speaker 01

  Yeah, I think a lot of the talk that I'm going to be doing at ReactConf is like, what I'm seeing a lot in the community is like a lot of product code that's like, needs to wire up the transitions correctly and use use optimistic correctly and use all these like new hooks in the product code and and you got to use it all correctly. But I think in the way that I I do a bunch of side projects and the way that I write my apps in the side projects is that the product code just has like an event handler. And in that event handler, I'll just call like a navigation or I'll add like a wait, save data to server and then navigate. I don't write all of the like transitions and the modern features and even like suspense.

• 14:36Speaker 01

  Suspense is, you know, behind some design component. I don't write all those features in the product code of the service itself. And so I think what I see shifting in like over the next few years is building these features in by default in three areas. The router, the data fetching later and the design components. And if you have them in those places, then you just get these experience, but for free by default. It's not extra work to have to add in a bunch of these features. Just the way that the way that it works, just able to take advantage of all these scheduling benefits and UX benefits without needing to do it all yourself.

• 15:17Scott Tolinski?

  Oh, hey.

• 15:18Speaker 01

  And you see this today, right? Even if you if you're just like writing a basic app needing to like. First thing you'll hit is like, oh, I gotta show a pending state. Okay, let me add use state is pending. And now let me make sure I re-set that in the right places.

• 15:32Wes Bos?

  That's a pain in the butt. Yeah, you shouldn't have to do any of that. I like that a lot. Talk to us about use optimistic as well. How does that fit into this?

• 15:42Speaker 01

  Yeah, so use optimistic, I think, is initially hard to wrap your head around. But I think it's a little, it's sounds more complicated than it is. Use optimistic is a hook that allows you to show some temporary state until the real state is available. And so the classic example, I think Instagram was one of the first apps that really like used optimistic state pretty heavily, like way back in the 2000s. And they would use it for like the like button. When you hit the like button, it would immediately show that it was liked. And then it would kick off a request in the background. Yeah, so it would feel really instant.

• 16:24Speaker 01

  You wouldn't like hit the like button, see a pending smitter or even worse, they even have a pending spinner. It's just doesn't do anything until it like hits the server. And so use optimistic is something similar. It's like, it's, it's part of that user feedback portion that I was talking about earlier, where you want to immediately show user feedback and then handle the result and transition to the UI to the result. And so actually, for the use transition hook, the is pending flag in use transition is implemented as use optimistic. So you really don't even need the is pending flag from use opt, uh, use transition, you can just use use optimistic. Although there are some benefits for error handling.

• 17:08Speaker 01

  Yeah, so use optimistic, you think about is like, if you think about it in terms of priorities, if you break down like the React scheduling into different priorities, where you have like the highest priority, which is like synchronous renders. And then you have the lower ish priority of transitions. Then the lowest being like things that are off screen, like activity. Optimistic is part of that high priority. It's part of that user feedback first. And then, once the transition finishes, then it's the transition value.

• 17:36Wes Bos?

  Okay. I want to go back to the thing you were saying about the 300 milliseconds. Basically, the opposite of that. So in the very early days of React Suspense, there was an API that allowed you to pass like a minimum time before the suspended state would show or before the fallback would show, right? That API was removed and they said, yeah, if you want to like, basically, it was like, I don't want to show a spinner if this is going to take less than 100 milliseconds. I'd rather show nothing. And then that was removed. Was that removed because of this 300 millisecond scheduling thing?

• 18:13Speaker 01

  So that was added in the like experimental phase even before React 18, which is before I joined the team. So I have a ton of context, which is kind of wild now, like the before I joined the team is getting longer and longer ago. I think that the reason that we removed that was that it was too hard to do it correctly. Like tinkering with all those settings and getting it to like work correctly was difficult. And we replaced it with heuristics. So for example, if you want to hold back the transition until the content is ready, don't use suspense boundary. If you transition to a part of the UI that doesn't suspend, then the transition will keep you on the previous page until the new page,

• 18:57Speaker 01

  all the data on the new page has loaded. But if you do specify a boundary, you're kind of saying like, this is not going to load fast enough. I need to like show something in its place. And that's where the user research comes in, where you want it to immediately show that fallback. It would be kind of like a perceived performance foot gun if you had that option and you were always setting it to 100 milliseconds. Because you'd be showing this delay that the user would start to notice between like 100 and 300 milliseconds where it's like I'm clicking, but it feels slow, it feels laggy. And the other thing is preloading, right? You can use preloading to warm the requests.

• 19:40Speaker 01

  And if you think they're going to happen fast enough, then you can preload them and then navigate to it. And then it wouldn't suspend.

• 19:48Wes Bos?

  Last thing I want to get you to explain is, is like how somebody should, should be fetching data in React. So if you need to obviously send off a fetch request or something that is a promise, like what's, what's the blessed way? Is that the used way? And that, that, that fires off all these transitions for you?

• 20:11Speaker 01

  Yeah, I'd say do what works for you. But if I was writing an app, I would use suspense. I would use use promise, definitely preload the promise. So for example, if you're navigating on a click, then you want to start the request as soon as possible. Ideally, in a lot of cases, start prefetching in the hover event. So if the hover event takes 100, 200 milliseconds between hover and mouse down, a lot of your API requests have already finished fetching by the time the user even presses down. So why wait until they like press down?

• 20:48Wes Bos?

  Yeah.

• 20:48Speaker 01

  And then the next route like renders and then, and then start fetching you when you can

• 20:54Wes Bos?

  That's

• 20:56Speaker 01

  preload it.

• 20:56Wes Bos?

  One of my most popular YouTube videos was showing how McMaster Carr uses that one simple trick to make it seem faster. And everyone, he was like, yeah, and it's, it's such a, such a simple thing. Just fetch it on hover.

• 21:09Speaker 01

  Yeah, I think that there's, there are some struggles with, like, it's kind of hard today to, to like fetch with use because you have to use this like cached promise thing. And so if you don't do like preloading or use a data fetching library, like writing your own way to like suspend with use is kind of hard. It's been a hard problem for us to solve for years now. I think we're getting close with the cache API, but cache is hard. And caching validation is harder and creating a generic API that anybody could use is like the hardest.

• 21:46Wes Bos?

  Yeah. Yeah, we've seen next JS go through what like three APIs on it already and like cash ruined. I, I want to make a shirt that says cash ruins all my evenings because it's just

• 21:57Scott Tolinski?

  Yeah. I have a question in regards to next JS then. So is, is next, is React now just next JS? And does Vercel own control of React?

• 22:07Wes Bos?

  Guy out of here. Just what people are saying, that's what they say on Twitter, right?

• 22:13Speaker 01

  Well, first I'm gonna get a shirt that says cash rules everything around me.

• 22:17Wes Bos?

  Exactly, yeah, right.

• 22:20Speaker 01

  Um, yeah, no, I hate that question. Thanks for asking it.

• 22:23Wes Bos?

  Yeah, I love it. I knew you would. I'm sorry.

• 22:26Speaker 01

  No, I think Dan said a vest, like, we kind of still just work as the React team. And we build all the, all of the features. The thing is, if you imagine what that would look like of like, oh, they're taking it over and like they're built and they're making it for their own. Well, they wouldn't, we wouldn't have just let everybody use all of the features that they can use. Like, server components be completely locked down. We've just built them, we could build all these features only into next. And we put so much work into like, building them in the right way for anybody to be able to use. That it's almost like, why do we go through all this work? If it would be, have been way easier to do it.

• 23:11Speaker 01

  Like, not the hard way.

• 23:12Wes Bos?

  Yeah, yeah, they're almost pulling features out of next to, to put them in, in React Core, right? Like, like data fetching and suspending and state management. Wait, will React ever give us a signals based state management? Or, or something like that? Have you guys talked about signals at all?

• 23:33Speaker 01

  I don't know if it's gonna be signals based, uh, but we did share in our labs post that we're starting to think of concurrent store API. Right now you can only use, use sync external store, which drops you out of transitions. It is a hard problem.

• 23:49Wes Bos?

  Oh, yeah.

• 23:50Speaker 01

  Been thinking about it for a long time. Like, being able to sync something concurrently across multiple conceptual threads is, uh, is difficult. But I think we'll be able to do it. I don't want to share too much because I don't want to, you know, you make, you share too much and then it changes. Like, like as an example, uh, we were talking about the suspense, um, timeout option.

• 24:15Wes Bos?

  Yeah.

• 24:15Speaker 01

  I don't have to talk about that thing all the time.

• 24:21Speaker 01

  And so I would say that we're like five years from now, I'll have to be talking about this API that never shipped.

• 24:27Scott Tolinski?

  Yeah, right, yeah.

• 24:28Speaker 01

  So we have to like balance that.

• 24:30Wes Bos?

  We need like a major warning, be like, this is just ideas, they're just thinking about it. Everyone says build in public and as soon as you build in public, everyone gets pissed that you didn't actually ship your first idea.

• 24:43Scott Tolinski?

  Yeah, yeah.

• 24:44Speaker 01

  Yeah, I think a little bit of that is just that it's like kind of, I've been thinking a lot about this. I think it's like self reinforcing. It's like because like we don't share a lot because if we share too early, then people create a lot of like in the information, like publish like courses or like here's this new thing coming to react and everybody needs to learn it. But even if it's just very like experimental and never ends up shipping. So we don't share a lot, but then that means that when we do share something, it does give that signal that this is coming. I think if we were to somehow be able to share like way more, then I think it would get like, it would kind of combat that.

• 25:26Speaker 01

  But we're in this like vicious cycle of like not being able to share as much, not able to be able to build in public as much, which means when something is shared, it is a big deal.

• 25:38Scott Tolinski?

  Yeah, yeah. Do you think like in regards to, I know like the whole React server components like rollout. I think to some people in the community, it felt like it was taking a long time to get to like other platforms. I know that a lot of that is like user library land and stuff. Were there like any lessons learned from that server components rollout? Or was that how kind of you all expected it to go?

• 26:01Speaker 01

  Yeah, I think, I think that there were a lot of lessons learned. Server components kind of overlapped with a change that we made to build more in public. So before server components, if you think back to like hooks or any of the features before that, we would just like build it almost secretly, it shipped it matter. And get a bunch of feedback from meta engineers and nobody else would outside would be able to use it. And then, once we felt it was pretty good, we'd cut an RC and then everybody would start like integrating with it. That wasn't great because it was like, we were only being able to kind of build to a small subset of the community.

• 26:39Speaker 01

  And so we changed to the Canary process where we would kind of like do a lot like what browsers do with like TC39 standards, where it's something like progresses. It gets to a point where it's like ready for implementation. It's not in the standards yet, but it's ready for browsers to start implementing it and running origin trials and stuff like that. And so that's kind of like what our Canary process is. I think that there was a lot of confusion. Because that was the first time we built something that way. It was like expected that like as we were sharing it, it was more like ready for like ready for like done. It's like, oh, it's done and only next has it.

• 27:23Speaker 01

  But it really, it wasn't like done until React 19. It was stable and ready to use in production and next was able to ship on it. And one thing that people also forget, uh, when they talk about server components, because they're like, oh, they only built it with next. It's not true. There was, you ever heard of like Shopify hydrogen? Hydrogen was built with server components. I don't remember the exact timing, but I think we built it in hydrogen first. Um, or at least at the same time, at the same time as next. And they gave us a ton of feedback. That was, they gave us feedback way back early in the day of the original server components like

• 28:04Speaker 01

  naming didn't use directives. They use file extensions where you'd have like dot client and dot server. And when hydrogen was shipping it and trying it, they gave feedback that it wasn't working and like the shared component thing wasn't really, didn't really make sense. And that's when we went with the directives model instead, but that was, they were directly. So we were trying and they even had a V integration for hydrogen. So there was V support for RSCs way back before.

• 28:32Wes Bos?

  Before there was even a use server directive?

• 28:34Speaker 01

  Yeah.

• 28:36Wes Bos?

  Man, yeah.

• 28:37Speaker 01

  Uh, and I think people don't have this context when they're, when they're thinking about this. Uh, and maybe, and that's, I think, one of the learnings you're asking, you were asking about learnings is like,

• 28:47Wes Bos?

  Yeah.

• 28:47Speaker 01

  We were so heads down building, we didn't have a lot of time to like communicate or like message. And so we were kind of like heads down for multiple years. And so a lot of this messaging just in, in context just wasn't out there.

• 29:03Wes Bos?

  Yeah, that's gotta be tough, right? I mean, you're building something that just a tremendous amount of people are using.

• 29:08Speaker 01

  So many people care and have opinions.

• 29:10Wes Bos?

  There's so many voices. Yeah, that's gotta be really difficult to keep a handle on. Yeah. Holy cow.

• 29:17Speaker 01

  Yeah, but it's kind of that's what you sign up for.

• 29:21Wes Bos?

  Yeah.

• 29:22Speaker 01

  Yeah.

• 29:22Wes Bos?

  Uncle Dan will keep them in, in check anyways, right?

• 29:26Speaker 01

  Yeah. I've been trying to, I've been trying to do a little bit of that too, uh, pushing back against the FUD. I think, um, docs really help, but docs are really hard to write, like writing a good doc. The only thing worse than no docs is bad docs. I'm not, like, it takes me forever to, to write, like, good docs. Uh, I think it takes everybody forever to write good docs. So.

• 29:48Wes Bos?

  Yeah.

• 29:50Speaker 01

  Especially if you're balancing like writing docs with like shipping more features. If, and if the story isn't fully complete, a lot of, a lot of the things that we were saying along the way was just like shipping solves problems. Uh, like even for some of the valid criticisms, it would be like, yeah. The solution to that is not to tell everyone what we're going to do. It's to actually do it.

• 30:12Wes Bos?

  I like that. And the docs thing, going back to that is it's even so much more important now that everybody's beat bopping in the AI text box and trying to kick out some more modern code. Like, have you guys, have you guys talked about that at all as well with these new React APIs? Like, how do you get these huge L L Ms to start kicking out more modern React code?

• 30:37Speaker 01

  Yeah, one thing that's really nice about React is what tends to be easy for users to understand is easy, which is like more declarative type APIs is makes it easier for LLMs and AI to understand and generate. I just saw some tweets going around about like how to like seed your prompts with the you might not need an effect guide, which is like a good first step. But I think like, again, if you go down to the into the future where like design components, routers, and data fetching library use these features out of the box, then you won't need to teach

• 31:18Speaker 01

  the AI how to do all these things, just like you will need to teach humans how to do all these things. Like the product code can just focus on, you know, here's where the button is inside of the button I want to navigate. And that's very like declarative way to do it. If you think about like wiring up all the use optimistics and all of the like start transitions and everything, that's kind of like in making it imperative again.

• 31:41Wes Bos?

  Yeah, and it will just it'll just hand it handle it because your I wrote it down here router, data fetching and design components, layers know about those things, right?

• 31:51Speaker 01

  Yeah. And hopefully that's where, you know, the humans can still keep their jobs as in those.

• 31:58Wes Bos?

  Well, I'll tell you, I'm writing a whole bunch of mess of React, so I can keep my job and fixing it. So that's good.

• 32:05Scott Tolinski?

  Man, these are tough problems that I'm so thankful that can just use the end results, right?

• 32:12Wes Bos?

  Especially a lot of these APIs will simply be like, well, I think like, like, end users will will have to know about them and know how to use them. But I think a lot of this like hard, heavy lifting will happen in, like you said, in a router, it's going to happen at framework level for a lot of this stuff. And we as a user will probably just be implementing it in like UI components. Is that fair to say?

• 32:38Speaker 01

  Yeah, that's the dream.

• 32:39Wes Bos?

  That's good.

• 32:41Speaker 01

  Yeah, it's, you know, you should be able to just tell your router which routes you want to prefetch, or like on hover, you might start rendering something in a hidden activity and then reveal that activity when it comes and then the router can just do all of that automatically for you. But I think this was a great demo because it kind of, one of the things that's interesting about this demo, a lot of people when they talk about transitions were like, oh, it's time slicing. It's like because React is slow for rendering, so they need to like split it up so that it feels, still feels responsive. All of the rendering chunks that were happening in that demo were like sub, like a couple milliseconds. The rendering

• 33:21Speaker 01

  itself is not the benefit. It's the priorities and the synchron, coordinating all of the async requests and coordinating all of the animations. Those are like the benefits of all the new features and those benefits are something that you would want in any UI library that you're using. You want to do things like batch stuff so that it animates together. You want to do stuff like defer stuff in the background so that you can still fire off network requests and still keep the DOM around. But like if you're using signals, your signal updates don't need to go and update, immediately update all of the DOM for stuff that's not visible on screen. You want to defer those updates. And that's

• 34:06Speaker 01

  why we built all these features. So we did fiber. So I did concurrent features. But it's been really hard to explain it. And I think that the, these new performance tracks really helped to see the parallel in the priorities.

• 34:21Wes Bos?

  Yeah, absolutely. You can, you can talk to your blue in the face of some of these people. And I think a lot of people will be like, I don't have those problems. But you can just simply hit the record button and show them that like, that simple blank screen in between there being like, you do have these problems. You might just not be as attentive to it. Yeah, right.

• 34:42Speaker 01

  And a lot of, a lot of times people were not, uh, as engineers working on like a MacBook M4, we don't see those problems, especially developing on local host.

• 34:53Wes Bos?

  Yeah.

• 34:53Speaker 01

  But the use, users are feeling them. And what we've tried to do with all of these features is think about them from the UX standpoint for all of the users of the app. So it just works and is coordinated the best way by default without flashing, minimizing jank, having really good IMP without needing to write a bunch of extra code.

• 35:16Wes Bos?

  Beautiful. Um, awesome. Well, anything else you want to talk to us about React before we wrap this up? Anything else we missed?

• 35:24Speaker 01

  No, I just watched my talk at ReactConf. I'm gonna, uh, go into a lot more detail on this and kind of show, what code will look like, uh, if you're using all the modern features that are built

• 35:37Wes Bos?

  Yeah.

• 35:38Speaker 01

  into these three areas for you.

• 35:41Wes Bos?

  Cool.

• 35:41Scott Tolinski?

  Nice.

• 35:41Wes Bos?

  Um, I've got a little tape on my shirt there. Last thing we have here is, uh, shameless plugs and, sorry, sick pick and shameless plug. Taking a look at your background, I think you like stuff. A sick pick is something you pick that is sick, something that you love in your life. Could be a chocolate bar, could be a movie, could be an app, can be going for a walk in the park, anything that you appreciate. Football team that's better than wherever, wherever the, wherever it's from. Michigan State, I would screw that up.

• 36:15Scott Tolinski?

  Not Michigan State, you can't do that to me.

• 36:19Speaker 01

  Yeah, my, my sick pick is going to be the, uh, new iPhone 17. It is my favorite iPhone so far. It's really.

• 36:29Wes Bos?

  Which one did you get?

• 36:30Speaker 01

  A lot of people, I got the, uh, Pro, the 17 Pro, which is, I think I'm seeing a lot of hate for, but, uh, I really appreciate like how nice it, I don't use a case. And for, uh, people that don't use, uh, cases, it feels like very solid. Doesn't feel like, uh, very delicate. Although, which is, it's made of aluminum now, so it's

• 36:54Wes Bos?

  Yeah.

• 36:55Speaker 01

  More delicate, so I check back in like a week after I've scuffed it up.

• 36:59Scott Tolinski?

  Let me tell you, I was a no case for two, for two full years and I just got this big old crack on it the other day. So I had to throw a case on here sadly, but I'm a no case person too. I greatly prefer it.

• 37:09Speaker 01

  I had, my last phone was actually the same way is I had cracked the back of it. So I had a case for the last couple of months.

• 37:17Scott Tolinski?

  Right, yeah.

• 37:17Wes Bos?

  I've had my 17 Pro Max for like three days now and I already got a, I put a screen protector on it right away. And one of my kids was, was doing something with it and you're ready, chip the screen protector. I can't get enough of it, but I was, I saw that after he dropped it and I was like, hmm. And I got a huge case on it, but luckily it wasn't the actual screen itself. So I just, I simply cannot, I would love to go just, just raw dog it, but I, I simply cannot.

• 37:51Speaker 01

  And what was, what was the other one, the sick pick in the?

• 37:54Wes Bos?

  Shameless plug. What would you like to plug to our audience? Where can they find you online? What's your blue sky, et cetera, et cetera?

• 38:01Speaker 01

  Shameless plug is, uh, React Conf is in a couple of weeks. Tune in online, it's live streamed for free. Uh, I'll be there, well, people will be there. Uh, and you can find me at Ricky FM on Blue Sky.

• 38:14Wes Bos?

  Sick. Awesome. Well, thank you so much for your time. This was enlightening and, uh, I'm really excited to play with all these new features.

• 38:22Speaker 01

  Awesome. Yeah. Thanks for having me.

• 38:24Wes Bos?

  You're welcome.

• 38:25Scott Tolinski?

  Thanks Ricky.

• 38:26Wes Bos?

  Peace.