iiinova — where your digital self keeps evolving

The same is true of React right now. Many of the new features feel worse than before because they're not integrated into the things you need to use them. But once they are, they will unlock better user experiences with less code than was possible before.

190

It's going to take some time for libraries, frameworks, and apps to understand and implement these patterns. In a lot of ways we've taken a step backwards, so we can get even further. But that's the way innovations work - they're never linear.

270

The ideal is no more than 3 paints: - a busy state, local to the interaction - a loading state for new pages - the final content, animated in

170

Slow network should automatically reveal loading states:

130

This is the same when navigating to new pages. Fast network should feel instant:

140

As network slows, feedback should remain fast and well designed loading states should automatically kick in:

181

Ricky @ricky.fm · 08/10/2025

When network is fast, apps should feel synchronous:

151

Part 2 is on the schedule, I’m just going to start the demo over and finish the talk from there

3401

yeah the time slicing demo was a classic. it's so good that everyone still talks about it, but it over shadowed the second half of the talk for the I/O benefits and the vision for "async react"

120

Finally, since this example is using Activity (stable today) and ViewTransition (stable soon), React animates to the result. While that animation is in progress, React has nothing to do. So it does some more work on the hidden Activities, so they're ready to show next

170

After feedback is shown, React can begin working on the result of the click. It renders the DOM to and starts loading data. Then React commits it to the DOM and waits for things like images, fonts, or CSS to load:

170

When a user clicks, React prioritizes the updates needed to show feedback for their click. Things like active button states, pending spinners, or optimistic state, all other updates wait for that to finish:

2101

Ricky @ricky.fm · 25/09/2025

This is React Fiber:

3594

is the desirable behavior here to paint every async request that comes in as fast as possible so there are flashes of intermediate frames? or are you thinking you'll add batching to defer a bit and limiting the number of paints at some point?

100

Ricky @ricky.fm · 25/09/2025

60ms is what good INP looks like for almost a million DOM nodes

000

Ricky @ricky.fm · 25/09/2025

"the scan loses very little performance" bruh the INP is off the charts

200

Ricky @ricky.fm · 23/09/2025

tag yourself I’m

191

Ricky @ricky.fm · 23/09/2025

Are you specifically asking about how this directive for "use server" is used for defining a “sever component” which is meaningless since that directive is for sever functions?

@ Server Component
'use server'
export default async function Use
// This runs on the server
const user = await fetch /api/
return ( < div>
<h1>{user. name}</h1>
<p>{user. email}</p>
</div>

210

Ricky @ricky.fm · 15/09/2025

this happens because count triggers the fallback, not deferredCount. it's basically the same pitfall as useTransition, but useDeferredValue has a note about it

This optimization requires SlowList to be wrapped in memo. This is because whenever the text changes, React needs to be able to re-render the parent component quickly. During that re-render, deferredText still has its previous value, so SlowList is able to skip re-rendering (its props have not changed). Without memo, it would have to re-render anyway, defeating the point of the optimization.

150

Ricky @ricky.fm · 14/09/2025

Notice how this RSC example doesn’t call a React.render() function like you might be familiar with on the client or SSR. You call a Parcel.renderRSC function:

100

Is it react-navigation? It looks like a simple_push which is configurable?

120

Blue sky: slow animation, but fast and cached reply loads

150

Twitter: fast animation, slow and uncached reply loads

130

The “use client” page has some diagrams already

010

Here's a repro with react-query. Since resetQueries is the only API to re-suspend on refetch, and resetQueries immediately resets the cache, any sync updates into a boundary will force the fallback - including isPending stackblitz.com/edit/usetran...

330

I don't know who needs to hear this, but here are some alternatives to fetching data in useEffect:

What are good alternatives to data fetching in Effects?

Hide Details
Writing fetch calls inside Effects is a popular way to fetch data, especially in fully client-side apps. This is, however, a very manual approach and it has significant downsides:

Effects don’t run on the server. This means that the initial server-rendered HTML will only include a loading state with no data. The client computer will have to download all JavaScript and render your app only to discover that now it needs to load the data. This is not very efficient.
Fetching directly in Effects makes it easy to create “network waterfalls”. You render the parent component, it fetches some data, renders the child components, and then they start fetching their data. If the network is not very fast, this is significantly slower than fetching all data in parallel.
Fetching directly in Effects usually means you don’t preload or cache data. For example, if the component unmounts and then mounts again, it would have to fetch the data again.
It’s not very ergonomic. There’s quite a bit of boilerplate code involved when writing fetch calls in a way that doesn’t suffer from bugs like race conditions.
This list of downsides is not specific to React. It applies to fetching data on mount with any library. Like with routing, data fetching is not trivial to do well, so we recommend the following approaches:

If you use a framework, use its built-in data fetching mechanism. Modern React frameworks have integrated data fetching mechanisms that are efficient and don’t suffer from the above pitfalls.
Otherwise, consider using or building a client-side cache. Popular open source solutions include React Query, useSWR, and React Router 6.4+. You can build your own solution too, in which case you would use Effects under the hood, but add logic for deduplicating requests, caching responses, and avoiding network waterfalls (by preloading data or hoisting data requirements to routes).

2393