Modern React with Ricky Hanlon (React Core Dev)

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 to talk about some of the new stuff in in React, what's going on with it, some of, like, the more I'm gonna Sanity, like, modern React. You know? We're gonna be talking about transitions and and and view transitions, maybe some suspense, and, hopefully, some of the new performance stuff that they've been been cooking on, the dev tools stuff he was showing me earlier. I'm not sure if he's gonna show us that or not, but I'm pinning them to it right now. Nice. Some really cool stuff. So welcome, Ricky. Thanks for coming on. Yeah. Thanks for having me. I'm really excited. Yeah. And, also, I gotta say before we start getting into anything technical,

I am gonna say you're gonna 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.

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

I should not have said anything Wes.

Yeah. Especially this season. Yeah. I 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 the Americans' high school games have have more people come to it. It was kinda sad.

Yeah. Cool.

Give us a rundown of who you are and what you do. 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 ReactConf, which is coming up in a couple of weeks. I have a talk that I'm planning, that I'm 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 then a lot of the theme for that talk is gonna be transitions and a lot of the, like, modern React features and what it looks like to build a modern React app. So I've been Node, talking a lot about transitions and seeing what people understand about them and don't understand about them or what how we can kinda clarify it. So that's Yeah. Kind of my main focus right now.

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

But there's this, like, whole, dare I say, like, new or advanced API, which is surrounds transitions, deferred, suspense, all of all of that stuff.

So what I was hoping to do is, like, let's ex 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 and how we can solve them. Yeah. For sure. Node to dive in. And if you want to see all of the errors in your application, you'll want to check out Sentry at century.i0/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 century.i0/syntax.

Again, we've been using this tool for a long time, and it totally rules. Alright.

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

Yeah. You can think of a transition as a, I mean, as a UI transition. Fundamentally, it's kinda 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 conference talk for React Confident in 2017 when we first introduced fiber.

And that talk is really great because it talks about all of the problems for performance in apps and, kinda walks you through the conclusion that the core concern for UI libraries for 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 transition being like navigation or updating state or data on the server and then navigating or refreshing, pull to refresh. Right? These are all scheduling problems.

Mhmm. And so the fiber rewrite and all of the features that we've been working on with, like, the big Scott concurrent mode name, the concurrent features Yarn really just scheduling features. How can you prioritize user input and defer transitioning the result of that input to kinda like a background thread so that you can always handle user input as the highest priority?

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 Bos, 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 JS kinda weird to type into. But can you give us maybe a better example than that?

Yeah. That's a that's a good example. I think, like, historically, we've given that example maybe too focused on that example because 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 gonna 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. And then just as you go to, like, click the result, it changes in the order Yeah. Yeah. And 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 a table and you have different filters on the table.

Node 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 drop down. You click a filter. Like, filter out these items.

And then one of two things could happen. You you if you're syncing it to the URL state synchronously, then you, like, click one of the items, and then the drop down, like, closes with the old value, not the ones that you selected. And then the, there's some time, maybe a 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 kinda 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 Wes metrics for this with, like, INP.

A lot of these metrics are out 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 Yarn, for how fast your site is perceived.

If you click on something and nothing happens for two hundred milliseconds or in the word in in this example, like, until the entire request comes back, which could take, you know, five hundred or even a second to change. That's gonna feel it's gonna be slow in in that case, and it's also gonna feel slow.

You won't be able to have really quick user input, user feedback, and then transition to the result.

Okay. And how does deferred and suspense fit into these things, or how are they related to it? Use deferred value, I think of is kind of like

a way to defer at the read point instead of the write ESLint, 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 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 Scott transition. Router dot navigate should happen with as a transition, because router navigation events are always transitioning the UI.

Yeah. But a lot of times, you'll be at the read point, that you need to be able to defer some defer part of the UI so it doesn't block user pnpm. And that's when you would use, like, a used deferred value.

And then suspense has a lot of things to it. The thing that I really am trying to, help people appreciate about suspense, right now is the batching behavior.

So a lot of of other frameworks that are out there say, like, have suspense Node.

But I think they should have, like we have suspense asterisk, which is like we have a component that shows a loading state but doesn't do everything that React suspense does.

So for example, we do a very controversial thing called throttling, which is if you, are loading a page and we show a fallback.

We make sure the fallback is shown for at least three hundred milliseconds because if you just flicker the fallback in as soon as the data is ready, say, in ten, fifty, hundred milliseconds, it feels slower than waiting three hundred milliseconds to the user because 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.

So, for example, if you don't throttle and you're, like, doing something like reading layout in the DOM, well, then you're gonna 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.

Oh, so that that three hundred milliseconds gives you three hundred milliseconds to

wait around and see if it Yeah. Hey. Anybody else? Yeah. Anybody else want to update state or whatever in here? 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 Mhmm. And those each one's triggering the animation.

If you're 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 two hundred millisecond animations, which takes six hundred milliseconds total.

But if you can wait and batch them into one Mhmm. Then you have one you you have a three hundred millisecond fallback, and then you have one two hundred millisecond animation, and you're only at five hundred milliseconds. So it's a hundred milliseconds faster to wait a little bit longer until you can animate everything. And you're saying that

put adding three hundred milliseconds feels faster than

having no, like, wait at all? Not the Node wait at all. Showing the fallback. Right? It'd be a, like, small amount of weight. Somewhere somewhere between Mhmm. You know, let's call it, like, twenty milliseconds and three hundred milliseconds.

Those just flicker. It's too fast for the user to perceive. Okay. And where do you get this this data from? Like, are there people at Meta that are are researching this, and then they give you the scoop on on what they found? 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, five hundred milliseconds because the user's gonna blame that on their network. They're not gonna blame that on your app. If your app flickers, then that's a programming problem with the app. Like, the user feels 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. Yeah. 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're gonna be working with on a daily basis?

Yeah. I think, a lot of the talk that I'm gonna be doing at ReactConf JS, 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 Node, and and you gotta 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 ESLint 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, await save data to server and then navigate.

I don't write all of the, like, transitions and the modern features and and even, like, suspense. Suspenses, you know, behind some design component.

I don't write all those features in the product code of the surface 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 layer, 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. Oh, wait. 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 reset that in the right places. That's a pain in the butt. Yeah. You you shouldn't have to to do any of that. I like that a lot. Talk to us about useOptimistic

as well. How does that fit into this?

Yeah. So use optimistic, I think, is initially Yarn to wrap your head around, but I think it's a little it 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 February.

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. You wanna, like, hit the like button, see a pending smitter, or even worse, they even have a pending spinner. It just doesn't do anything until it, like, hits the server.

And so use optimistic JS something similar. It's like it's it's part of that user feedback portion that I was talking about earlier Wes you wanna 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 JS pending flag in use transition is implemented as use optimistic.

So you really don't even need the is pending flag from use transition. You can just use use optimistic. Well, there are some benefits for error handling. Yeah. So use optimistic, you think about it as, 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 it's the transition value. Okay.

I wanna go back to the thing you're saying about the the three hundred 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 the fallback would show. Right? That that API was removed when they said, yeah, you can if you want to, like basically, it was like, I don't wanna show a spinner if this is gonna take less than a hundred milliseconds. I'd rather show nothing.

And then that was removed. Was that removed because of this three hundred millisecond scheduling thing? So that was added in the, like, experimental phase even before,

React 18, which JS before I joined the team. So I don't have a ton of context, but which is kinda wild now. Like, the before I joined the team is getting longer and longer ago. I think that the 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 wanna hold back the transition until the content is ready, don't use suspense boundary. If so if you transition to a a part of the UI that doesn't suspend, then the transition will keep you on the previous page until the new page all the data on the new page has loaded.

But if you do specify a boundary, you're kind of saying, like, I this is not gonna load fast enough. I need to, like, show something in its place. And that's where the user research comes in Wes you want it to immediately show that fallback. Like, it it would be, kinda like a per perceived performance foot gun if you had that option and you were always setting it to a hundred milliseconds because you'd be showing the this delay that the user would start to notice between, like, a hundred and three hundred milliseconds Wes it's like, I'm clicking, but it feels slow. It feels laggy.

And the other thing is, is preloading.

Right? You can Yeah. Use preloading to warm the Wes. And if you think they're gonna happen fast enough, then you can preload them and then navigate to it, and then it wouldn't, suspend.

Mhmm. Last thing I wanna get you to explain is is, like, how somebody should should be fetching data in in React.

So if if you need to obviously send off a fetch request or 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?

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. Pre definitely preload the promise.

So for example, if you're navigating on a click, then you wanna start the request as soon as possible.

Ideally, in a lot of cases, start prefetching in the hover event so that if the hover event takes a hundred, two hundred milliseconds between hover and 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? Yeah. And then the next route, like, renders and then and then start fetching? You when you can That's

preload it. One of my most popular YouTube videos was showing how McMaster Carr uses that one simple trick to make it seem faster, and everyone, it was like

Yeah. You know? And it's it's such a such a simple thing. Just fetch it on hover. Yeah. I think that there's, there are some struggles with like, it's kinda 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 the data fetching library, like, writing your own way to, like, suspend with use is kinda 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 Yarn, and cache invalidation is harder. And creating a generic API that anybody could use,

is, like, the hardest. Yeah. Yeah. Yeah. We've seen Next. Js go through, what, like, three APIs on it already and, like, cache ruined I I wanna make a shirt that says cache ruins all my evenings because it's just Yeah.

Awful. I I have a Wes in regards to Next. Js then. So is is next is React Node just Next. JS, and does Vercel,

in control of React? Guy out of here.

Just what do what people are saying. That's what that's what they they say on Twitter. Right?

Well, first, I'm gonna get a shirt that says, Cash Rules Everything Around Me. Exactly. Yeah. Right.

Yeah. Deno. I hate that question. Thanks for asking it. Yeah. I love it. I knew you would. I'm sorry.

No. I think, Dan, Dan said of us, like, we kinda still just work as the React team, and we build all the all the features. The thing JS, 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 Yeah. Server components would be completely locked down. We've just build 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 it's almost like, why do we go through all this work if it would be have been way easier to do it, like, not the hard way. 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. What will React ever give us a, signals based state management or or something like that? Have you guys talked about signals at all? I don't know if it's gonna be signals Bos,

but we did share in our labs post that we're starting to think of a concurrent store API.

Right now, you can only use use sync external store, which drops you out of transitions.

It is a hard problem.

Oh, yeah. I've been thinking about it for a long time. Like, being able to sync something, concurrently across multiple conceptual threads is, is difficult, but I think we'll be able to do it. I don't wanna share too much because I don't wanna you know, you make you share too much, and then it changes. Like like, as an example, we were talking about the suspense time out option.

Yep. I have to talk about that thing all the time.

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

Yeah. Right. Yeah. So we have to, like, balance that.

Wes need, like, a major warning to 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.

Yeah. Yeah. Yeah. I think a little bit of that is just that, it's, like, kinda 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 Yeah. 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 Scott, but then that means that when we do share something, it 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 kinda, like, combat that. 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.

Yeah. Yeah. Do you think, like, in regards to I know, like, the whole React server components, like, rollout. It it 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. We're platforms. I know that a lot of that is in, like, user library land and stuff. Were there, like, any lessons learned from that server components rollout, or did was that how kind of you all expected it to go? Yeah. I think I think that there were a lot of lessons learned.

Server components kinda 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 and ship it at meta 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 Wes were only being able to kinda build to a small subset of the community. And so we changed to the canary process where we would kinda, like, do a lot like what browsers do with, like, TC 39 standards, whereas something, like, progresses, it gets to a point where it's, like, ready for implementation. It's not in the standard yet, but it's ready for browsers to start implementing it and running origin trials and stuff like that. And so that's kinda like what our canary process is.

I think that there Wes 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. But, 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, when they talk about server components because they're like, oh, they only built it with Next. That's not true. There JS this have 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, 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, naming didn't use directives. They used file extensions warp 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 Wes they were directly so we were trying, and they even had a Vite integration for Hydrogen. So there Wes Vite support for RFCs way back

before after. There was even a use server directive? Yeah.

Man. Yeah. Wes. And I think people don't have this context when they're when they're thinking about this.

And maybe and that's, I think, one of the learnings you're ask you were asking about learnings JS just like Yeah. We were so heads down building. We didn't have a lot of time to, like, communicate or, like, message. And so we were kinda, like, heads down for multiple Yarn. And so a lot of this messaging just in in context just

wasn't out there. Yeah. That's gotta be tough. Right? I mean, you're building something that just a tremendous amount of people are using and So many people

are using. Tone. Have opinions.

Voices. Yeah. That's gotta be really difficult to keep a handle on. Yeah. Holy cow. Yeah. But it's kinda

that's what you signed up for. Yeah. Yeah. Uncle Dan will keep him in in check anyways. Right?

Yeah.

I've been trying to I've been trying to do a little bit of that too, pushing back against the FUD. I think, 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.

I think it takes everybody forever to write good docs. So Yeah.

Especially if you're balancing, like, writing docs with, like, shipping more features if and if the story isn't fully complete, a lot a lot of the things that we were saying along the way was just, like, shipping solves problems.

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. I like that.

And the docs thing, going back to that, is it's even so much more important now that everybody's beep 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 LLMs to start kicking out more modern React code?

Yeah. One thing that's really nice about React is what tends to be easy for users to understand JS 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 the AI how to do all these things. Just like you won't 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 JS. Inside of the button, I wanna navigate.

And, that's a 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 kinda, like,

making it imperative again. Yeah. And it'll just it'll just hand it handle it because your I wrote it down here. Router, data fetching, and design components layers

Node about those things. Right? Yeah. Mhmm. And, hopefully, that's where, you know, the humans can still keep their jobs JS in those two years.

Well, I'm I 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.

Man, these are tough problems that I'm so thankful they can just use the end result. Right?

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

Yeah. That's the dream.

That's good. 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 Yeah. Reveal that activity Wes 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 kinda one of the things that's interesting about this demo, a lot of people, when they talk about transitions, warp 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 itself is not the benefit. It's the priorities and the sync coordinating all of the async requests, 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 wanna do things like batch stuff so that it animates together. You wanna 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 Scott, visible on screen. You wanna defer those updates, and that's why we built all these features. So we did fiber. So we did concurrent features. But it's been really hard to explain it, and I think that the these new performance tracks really help to, see the parallel, as well in in the priorities.

Yeah. Absolutely. Yeah. You can you can talk till you're 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. Yeah. And a lot of a lot of times, peep we're not,

as engineers working on, like, a MacBook m four. We don't see those problems, especially developing on local host.

Yeah. 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 INP without needing to write a bunch of extra code.

Beautiful.

Awesome. Well, anything else you wanna talk to us about React before we wrap this up? Anything else we missed? Node just watched my talk at ReactConf. I'm gonna,

go into a lot more detail on this and kinda show, what code will look like, if you're using all the modern features that are built Yeah. Into these three areas for you.

Cool. Nice.

Tape on my shirt there.

Last thing we have here is, 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 Bos, 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 Wes wherever spelled from. Michigan State say no. To screw that up. Football.

Not Michigan State. You can't do that to me.

Yeah. My my sick pick is gonna be the, new iPhone 17.

It is my favorite iPhone so far.

It's really Which ones you get? A lot of people I got the, Pro, the 17 Pro, which is I think I'm seeing a lot of hate for, but, I really appreciate, like, how nice it I don't use a case.

And for people that don't use cases, it feels, like, very solid.

It doesn't feel like, very delicate.

Although which is it's made of aluminum now. So it's Yeah. Which is more delicate. So check back into this brief after I've scuffed it up.

Let me tell you. I was in no 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 I greatly prefer it. I had my last phone was actually the same way as I had,

cracked the back of it, so I had a a case for the last couple of months.

Right. Yeah. 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 already chipped the screen protector. I can't get it from you. But I was I I saw that after he dropped it, and I was like and I got a huge case on it, screen protector. 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.

And what was what was the other one, the sick pick and the

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

Shameless plug is, ReactConf ESLint a couple weeks. Tune in online. It's live streamed for free.

I'll be there. A lot of people will be there.

And you can find me at Ricky FM on Blue Sky.

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

Awesome. Yeah. Thanks for helping me. You're welcome. Thanks, Ricky.