(upbeat music)

- Good morning.

It's great to be here.

It's a lot of first time React Conf attendees.

That's awesome.

So again, my name is Joe Savona.

I'm on the React team at Meta.

We've got a lot of awesome things to share with you today.

But before we dive into the new stuff,

at last year's conference,

we announced the release of the release candidates

of React 19.

Things didn't quite go as we intended.

During the release candidate period,

we got feedback from several folks in the community

about one particular change included in the RC.

So the way that React handles rendering

when one sibling of a suspense boundary suspends.

In React 18, when one sibling suspended

because it was fetching data,

React wouldn't immediately show the fallback.

Instead, it would continue trying to render the other children,

which meant that if they were fetching data,

those fetches could be kicked off early.

And then at the end, we would finally show a fallback.

So this meant that we were fetching more data early,

which is good, but hurting the user experience

by delaying the fallback.

So for React 19, we wanted to show that fallback earlier.

But our initial approach meant that siblings

didn't re-render at all,

which could delay the loading of data.

So based on your feedback,

we've implemented something even better

than the original 18 behavior

or the original 19 RC behavior.

In React 19, when a component suspends,

we immediately show the fallback,

improving the user experience.

But rather than wait for that initial fetch

to resolve before we try other siblings,

we immediately schedule a pre-warming

of the remaining siblings.

So we're still showing the fallback,

but while that's happening,

we're starting to render pre-warm the other siblings

to fetch their data too.

So to summarize sibling pre-warming

allows React to show the fallbacks earlier

while continuing to prefetch as much data as possible early.

I'd like to give a huge shout out to Andrew Clark,

in particular,

who painstakingly implemented these optimizations.

Really incredible engineering work.

(audience applauds)

Yeah.

And I'd also like to thank those of you in the community

who flagged this to us and gave us this feedback

so we could improve React.

This is exactly why we released canaries

and why we have released candidates

to get this kind of feedback.

Now, another big change since the last conference

is to the React docs.

We've gotten a lot of feedback from many of you.

Appininated, passionate, sometimes angry,

rarely happy, feedback about the docs.

In particular about one aspect of the docs,

which is what do I do when a framework

isn't a good fit for my application?

So, we heard your feedback.

Maybe not as quickly as you might have liked.

Maybe it's somewhat begrudgingly,

but we heard it, we'd internalize it.

It took some time, we'd do like sit

and go on some long walks in process.

But based on your input,

we've added a new page to the docs

that walks through how to build a React app from scratch.

And this page highlights several great options,

including parcel, VIT and RS build.

So for both of these cases,

we'd like to thank everyone in the community

who gave us feedback.

And it helped make React our docs better for everyone.

So seriously, thank you.

Yeah, give yourselves a round of applause.

This is great.

This is exactly how open source is supposed to work.

So this is the process working, right?

So since 19, we released 19.1,

which includes support for owner stacks in development.

So this is a development only feature.

Now, you may be familiar with component stacks,

which kind of show you where in the UI tree

an issue occurred.

But often the issue might be occurring

because of a component created elsewhere.

And so owner stacks can give you

a bit more precise information about the source of an error.

So if you're debugging, definitely check out this API.

It's also been an exciting year for the community.

And I'd like to take a moment to celebrate.

Traditionally, when we look at, you know,

the community section of the keynote,

we share a whole bunch of download stats.

This year, by all accounts,

everything is looking really good.

And one number in particular stood out.

As of a few weeks ago,

React's lifetime download count on NPM has reached...

Wait for it.

I'll have to click.

Yeah.

Six billion lifetime downloads,

which is just a staggering number of downloads.

So thank you for continuing to use React.

Looking beyond React,

this year also saw a number of really exciting releases

in the community.

And in particular, this was the year

that server components became mainstream

and just achieved widespread support

throughout the ecosystem.

Expo, next, parcel, React Router, Redwood,

TANstack, VIT, Waku.

These are in alphabetical order

in case you have any questions around the prioritization.

Just keep it simple.

They all support server components.

So just really, really incredible to see this coming along.

Obviously, server components are not the right fit

for every application,

but it's incredible to see the level of support

this has throughout the ecosystem.

So we'd like to say thank you

to everyone working on these frameworks,

building libraries, creating tutorials,

teaching your colleagues,

answering questions and showing up here today.

React is nothing without the community.

So thank you all.

But in addition to those of us humans in the crowd,

we've also got some other folks showing up as colleagues today.

Since our last conference,

large language models and agents have dramatically improved

and are quickly becoming a common part of how we all work.

I'm sure many of you have different feelings about AI.

I certainly have mixed feelings.

LMs and agents are just clearly here to stay.

One early takeaway from experimenting with LMs and agents

is that what makes React great for humans

also makes it great for AI,

because it turns out our context window

is not that long either.

Thank you for those of you who laughed.

I appreciate it.

So React's declarative composable approach

helps us reason locally,

and this appears to work for AI as well.

So AI is new, it's scary, it's exciting,

it's a lot of things.

But ultimately, we see it as another tool

to help us deliver on our mission,

which is to make it easy for anyone

to build great user experiences.

It's just another tool like linters, auto-completion,

or developer tools.

All right.

So that's an update since last time.

Next, I would like to share what we've been working on

this year.

Our work this year has focused on two key themes

in service of that mission.

Reasing the bar for responsive user experiences.

We've got some really, really amazing stuff

to show you this year.

And yeah, this just continues to kind of push the ceiling

of the kind of user experience we can deliver.

And at the same time,

we've worked to lower the barrier to entry.

It isn't enough that we have these amazing features.

We want to make sure that everyone can take it full advantage

of them.

So with that, to talk through some of our latest features

on responsive UI, I'd like to hand things over to Mofe.

(upbeat music)

- Hey everyone.

I'm Mofe, I work on the React team at Meta.

Super excited to be here today.

Wow, that's a lot of people.

In case you haven't heard about the latest news in React,

I love to tell you.

We're actually, hang on.

Maybe it's easier if I just,

what's new in React?

React 19.2.

(audience applauding)

So we just released React 19.2 last week.

And as you see, everyone's talking about it.

This is own news to you and you've already upgraded.

Great, thank you.

Without let us know what you think.

If you haven't, well, I'll bet you want to after today.

React 19.2 has a ton of exciting new features.

First, we have two new APIs in the runtime,

activity and use effect of it.

We also added partial pre-rendering and performance tracks,

which are new capabilities for React servers and dev tools.

First, let's talk about activity.

This feature has a lot of depth,

so we're going to spend most of our time here.

Activity lets you hide and restore the UI

and internal state of its children.

You can pass it a mode hidden or visible,

and children which react to a hide for reveal.

Now, some of you may be wondering

if you can just do the same thing with CSS,

like setting display none.

I want to show you the most exciting part of this feature,

because activity is not just about setting visibility

in the DOM.

We're going to walk through it

by using it in a very simple movie app.

Well, first, look at how the app performs with that activity,

add activity, and then compare.

So without activity, this is the root component of my app.

I have a client-side router,

which lets you navigate between movie gallery

and a movie detail, depending on which route is selected.

We always return both movie gallery and a movie detail

and manually hide one of them with CSS.

We also have a theme provider,

which is shared between both views.

Since setting light or dark theme

should affect my entire app.

So this is the app.

Let's talk about why we're always returning both views,

both gallery and the detail view.

Because I want to have a single application

with Persisted State,

I want to be able to edit the search filter,

click into a movie detail,

got to wait for the load,

and then navigate back.

When I navigate back,

I want my changed search filters to still be there.

I could write my own resumption logic,

but I can get really complicated.

So with this, I don't have to wait.

I don't have to set the search filter.

I also don't have to wait for an entire page load

on every navigation.

Since the other page is always available,

they've navigating back and forth is super fast.

We can even re-render in the background,

like if the user hovers a VR movie card.

Okay, so now we'll walk through a user interaction,

and I want to see how this app performs.

We can reset the app to the details view,

declutters and visuals,

and also add a timeline at the bottom

to visualize when React is work.

So say the user clicks to toggle the theme.

A click event handler will run and do two things.

First, it runs a blocking render

to show immediate feedback to the user.

So on the right, we'll draw the work-in-progress component tree

for this render,

and that's the highlighted theme toggle button.

On the bottom, we can see time-submit rendering,

one time slice for each component.

This render finishes very quickly,

and the work-in-progress tree paints to the DOM.

So we're going to show time-submit

converting on purple on the bottom.

So the second thing that happens

is that React will schedule a full theme refresh

to change the entire app to light theme.

And that's a lot of work that runs, right?

We're painting both the hidden view,

the gallery view, and the detail view to light theme.

And when this render is finally done,

React can commit and paint.

So if we were to look at the performance of this theme toggle,

IMP is good because we're following React best practices,

we're placing expensive updates inside of transitions.

But if we looked at how long it took

to actually show my page in light theme,

well, that's not as good.

This had to wait for every component to update,

even ones that we know are not visible.

So can we do better?

Step one's done.

Let's change the app to add activity.

First, we'll import it,

then replace this manual stuff with activity,

and then, wait, that's all, we're done.

Moving on.

So what's the performance of the same theme toggle interaction

now that we're using activity?

To better understand what's going on,

we're actually going to sit at the bottom timeline view

to show different priority levels

used by the React Scheduler.

We'll first show time spent rendering visible content.

This is blocking renders, updates from transitions,

really anything that's affecting content on screen.

And also time spent working on activity hidden components.

Because React knows the activity hidden components

can never be seen by the user,

it would differ updates to that content.

So hidden is React's lowest priority level.

It runs when there's truly nothing else to do.

Okay, so let's get to it.

Again, we receive a click from the user

to toggle the color theme,

and the exact same event handler runs.

We first re-render and paint to show immediate feedback,

and then we actually start updating the app to light theme.

And this is where it starts to get interesting.

Because remember that we wrapped the gallery view

in an activity hidden component.

This work will get deferred until there's nothing better to do.

And React will also schedule a higher priority render

to update just the visible part of the screen.

And that's what immediately runs.

And commits.

So now this is a much better experience than before.

It took less time to change the light theme

because we didn't also have to update the hidden view.

Now that there's nothing better to do,

React will start rendering the gallery view

in the background.

First search bar, coloring the border.

But wait, React is fast,

but this user is like really good at clicking.

They move their mouse and we receive another click of it.

This click happened in the middle

of the hidden priority work.

So we'll defer that to prioritize showing

an optimistic rating update.

This finishes super fast.

And again, when there's nothing else left to do,

React will resume the activity hidden work that was interrupted.

This time it completes and finally commits

the hidden gallery view, now in the light theme.

So if we look at the performance of this interaction,

INP stays low and the total time to paint a theme toggle

is also much faster.

If I were to compare the activity version

of my app with the original one, it's much faster now.

So, activity is not just about visibility,

it's a lot more than that.

To summarize, activity hidden components

are visually hidden, update with the lowest priority,

persist, react, and DOM state,

and their effects are left unmounted

so the inactive parts of your app

don't need to pay for expensive synchronization.

And they're also not server rendered or hydrated.

Of course, activity visible components

are visually visible and rendered with the default priority.

So if you want to learn more about how to use activity

and how it integrates with newer features,

be sure to check out Chan Strickland's talk later today.

Okay, so let's talk about the other parts of React 19.

Use Effectivit is a new API we're releasing

to give users more fine-grained control over their effects.

It's a more advanced hook,

so be sure to read through the docs

if you're planning to use it.

19.2 also adds a new server feature

called partial pre-rendering.

This lets you render the static parts of your app

and serve it from a CDN.

Then later, when resolving a client request,

we can resume rendering the shell to fill it in

with dynamic content.

What this means is that server-side renders

can use cache resources to let the user see a shell much faster.

And finally, we're releasing a new profiling tool

called Performance Tracks.

This lives in the Chromium Performance Panel,

unless you see a timeline of all the work done in React.

The schedule of the track is a more detailed version

of the timeline view we just used to understand activity.

Blocking, transition, suspense, and idle,

those are all different priorities

used by the React Scheduler.

And the component track gives you a flame view graph

of component renders and effects.

If you want to understand how to use performance tracks better,

please check out Rustman's talk.

So this sums up what's new in React 19.2.

To tell you more about what's coming in React,

I hand you off to Jack Pope.

(upbeat music)

- Thank you, Mofe.

Let's give her one more round of applause.

(audience applauding)

Hey everyone, my name is Jack.

It's so great to be here today.

If you're wondering what the team's working on next,

it's a good question.

And frankly, as a new manager,

I wonder the same thing every morning when I wake up.

Are they actually working,

or just adding cabbies to my slides?

So I grilled them, and this is what they told me.

It's been a really ambitious year for our team,

and our work doesn't stop at React 19.2.

In fact, React uses multiple stages and release channels

to allow features to move from ideas into public APIs.

So as we begin running experiments,

we'll release features into experimental.

And after they're well tested there,

they may graduate into Canary.

Now, Canary is the last stop for a feature

before it could make itself into a somber stable release.

So I really encourage any framework

or library authors out there in particular

to keep an eye on Canary and provide feedback

when things land there.

Now, speaking of Canary,

I am thrilled to announce

that the team landed two new features here yesterday.

After many years of research

and some amazing feats of engineering

by Sebastian Markbage,

I'm thrilled to announce that view transition

is now ready for you to try.

(audience applauds)

And additionally, we've added rest of fragments

to power a new composition model for platform APIs.

(audience applauds)

So I'm gonna start with view transition,

but before we get into the specifics of the API,

let's take a moment to go over animated transitions.

So animated transitions visually connect

our changes in the UI.

They help the user understand what's happening

and where to focus their attention.

So page navigation animations like this one

can provide a sense of place in the application.

It's easier to understand where you're going

and where you've been.

And in another example,

this element can animate from one view into another.

And animations like these create a sense of continuity.

Rather than a large modal just flashing in

and taking over the page,

we can reduce some of the cognitive load

by anchoring that UI change.

One last example is the reordering of items in a list.

When your order changes instantly,

it might be hard to tell exactly what just happened.

But with animated reordering,

it's much easier to follow along.

Now historically, high quality animations like these

have been really difficult to achieve.

When I worked on Instagram.com,

I had designers all the time requesting features

just like these.

And I always wanted to build them.

But due to the complexity and some of the performance trade-offs,

they'd always just end up getting cut at the end of a project,

leaving me super frustrated.

And then in 2023, Chrome released the View Transition API.

And I was really excited by all the demos they showed

and all the promise of native browser support.

Finally, with just a few lines of JavaScript and CSS,

we can animate transitions on both single

and multi-page applications.

The browser creates snapshots of the UI, runs your callback,

and then animates to the new UI using CSS animations.

And this is a really powerful primitive,

but there can be a few problems

with using Star View Transition directly,

mainly with timing and scoping.

So it can be difficult to snapshot at the right time.

With React, if you use this directly,

you need to use React DOM/Sync API

so that the DOM can update immediately

with your new state applied.

And this would unfortunately just deopt any concurrent rendering

that may have been part of this update.

So if you're doing something async,

say a page navigation that has to load in new data,

you'll end up animating to force fallbacks

rather than your final content.

And to understand scoping,

let's take a look at this gallery interaction.

By default with Star View Transition,

the entire route will animate,

causing your page to be non-interactive in the meantime.

And you can get around this

by adding view transition name attributes

to the specific elements that you'd like to animate.

But if you leave these around,

they could get picked up by future,

potentially unrelated view transitions.

And so it's important to add them at the time of the update

and clean them up.

But what if React could just solve all of these problems for you?

So me view transition, a new component from React.

It's the first animations API built directly into React

and is deeply integrated with all of our features.

View transition is a declarative API

that uses a set of heuristics

to determine what and how to animate.

And here we can see the immediate difference in the programming model

when using the view transition component.

React handles applying the view transition name

as well as removing it.

And it will also call Star View Transition for us

at just the right time.

Additionally, it handles our scoping problem.

Because React manages all of the view transition names,

it can decide which elements to activate

when an update comes through.

And it will activate the smallest subset

of view transition components necessary based on that update.

So in our gallery here,

we'll only animate the movie poster in the center

and leave the rest of the page open for a responsive interaction.

So that's what to animate.

But how about when?

How would we trigger this view transition?

The triggers here are start transition,

use deferred value, and suspense.

And through these APIs,

React's concurrent rendering model

integrates seamlessly with your animations.

And that brings along all the benefits of bashed updates

and our async coordination.

So in the gallery example,

clicking the next button,

we'll call a start transition with an async action.

The router change would update the current movie index,

resulting in a dummy mutation

to switch out that movie poster.

The view transition component will detect the mutation

of its child and activate an update animation.

Now, without specifying any class names here,

the browser's default animation will be used

typically across fade.

And we could customize the effect further

by adding the update class name,

and then using CSS to style the view transition pseudo elements.

And additionally,

we might want to customize based on the type of interaction

that triggered our update.

So in the case of the gallery,

there's two possible interactions here.

We can click next or previous.

And if we wanted that element to slide to the right

or left just like this,

depending on which type of action we took,

we can do so by using a new API, add transition type.

So let's see what using add transition type looks like.

Within our action,

we'll just add the next movie poster type.

And then within our view transition component,

we can replace that update class name with an object.

Here, the keys align to transition types,

which then map to our class names.

And now we can use CSS to create that sliding effect

to the right or left, depending on each class name.

So far, I've been describing update animations,

but there are three other categories.

We also have enter animations,

which trigger when a component with view transition

at the top level is mounted,

revealed from suspense, or revealed from activity.

We have exit animations.

When a component with view transition at the top level

is unmounted or hidden with activity.

And finally, my favorite part,

we have share animations.

With share animations, we can implement magic move-like effects

with just a few lines of code.

These activate when you have a pair of view transition components

that have matching names, and one is hidden

while another one appears in the same update.

So with enter, exit, update, and share animations

powered by react transitions and suspense,

there is so much possibility.

And this truly raises a ceiling on UX for react applications.

(audience applauds)

So as Mothane mentioned,

chances gonna be speaking more about view transition

right after the keynote, so be sure to stick around for that.

Now, that wraps up view transition.

As Joe told us earlier, we don't just wanna make it possible

to create great applications with React.

We also wanna make it easier to do so.

And that brings me to fragment refs.

With fragment refs, we're introducing a new way

to compose platform behavior that can significantly

lower the complexity of your product code.

Because as we review product code,

we observe a lot of friction

when it comes to working with platform APIs.

I'm talking about things like setting up event listeners,

attaching intersection observers,

maybe applying focus, et cetera.

And there are a handful of APIs and patterns

used to achieve this today.

But it can be difficult to compose this behavior.

We see a lot of different framework level abstractions,

doing things with custom hooks, render props,

higher order components, components that make you

wrap another div or other element around your children

to take a ref in the right place.

So let's take a look at an example.

Here we have a scrollable movie grid,

which needs a mon scroll behavior.

So in fairly typical fashion, we'll create a ref

and then use a use effect to call add event listener

and remove event listener,

and finally pass that ref down to the movie grid.

Now thanks to hooks, this type of behavior

can already be shared amongst components

and many apps are doing this today.

So here we've created a custom hook abstraction

called use event handler,

and this returns a ref that you can then pass to any element.

So if we go back to our component and refactor,

we can see that things are greatly simplified.

But what happens when we introduce additional behavior?

For example, here we're also adding a use impression hook

because we need to log an impression

whenever a movie grid enters a viewport.

And we're also taking a ref from the parent

and forwarding that down to movie grid as well.

So now we must merge the refs.

And in many examples we see in production apps today,

it's far more complicated than this.

We have a mix of patterns.

Many of them force you to wrap extra layout elements

around your children,

and we'll pass multiple refs around the tree

merging them at various levels.

Could there be a better way to handle this complexity?

Enter fragment refs.

We believe that when it comes to platform APIs,

the vast majority of logic and the effects and refs

that power them can live in shared abstractions.

And then product code should easily be able

to compose this behavior as needed.

Fragment refs make this possible

and offer a new way to compose platform capabilities.

The ref value in the case of a fragment

is called a fragment instance.

And a fragment instance exposes a series of operations

to help you leverage platform APIs

without breaking encapsulation.

So on the fragment instance,

we have a series of operations,

such as event operations, like add event listener,

remove event listener, dispatch event.

We have layout operations,

such as compare document position, get client racks.

We can do focus management with focus and blur.

And we can attach intersection or resize observers

to our children using observe using.

For a full list of these operations,

please check out the docs.

So let's go back to our scrollable movie grid

and now take advantage of fragment refs.

Here I've created two fragment based components

that implement the same behavior we saw earlier,

but under the hood, taking advantage of those fragment instances.

So we have a scroll handler fragment,

which we simply now pass an on scroll handler

and let it do the rest.

And we have an impression fragment

where we can pass a callback

that'll be triggered every time the movie grid

enters a viewport.

So we can achieve this functionality,

just like we started with,

without having to think about effects

or refs locally within the product code.

And additionally, since we remove find DOM node in React 19,

some apps have still had difficulty

interacting with components they don't own.

Maybe these components are user defined

or they might come from a design system

that you don't have full control over

to update to take a ref just where you need it.

But with fragment refs,

we can interact with the host nodes

rendered by any component.

In this example, we focus this input component

that came from a third-party library

just by wrapping in a fragment

and calling focus on that fragment instance.

So to summarize, fragment refs offer

a powerful new composition pattern in React.

And platform capabilities can be integrated

at the framework, library, or design system levels,

and then used throughout your product code.

And that's without requiring additional element wrappers

or even having control of your child components.

So as you can see,

we have a lot of exciting new features in React.

As Mofe shared, React 19.2 released last week with activity,

use effective and performance tracks

and partial pre-rendering.

And as of yesterday in Canary,

we now have view transition and fragment refs.

And additionally, we're still in early research

and development of a number of other features.

These are things like suspense lists, concurrent stores,

gesture animations, and much more.

And we'll be thrilled to share updates on those

as soon as we have more to share.

So I'm so excited to see what you build

with everything new in React.

And with that, I'm gonna hand it off to Lauren

for an update on React Compiler.

(upbeat music)

(upbeat music)

Hello.

Can I get a quick show of hands?

Who loves hydration?

Hydration there is great.

And that's why I'm gonna hydrate myself right now.

And we should all hydrate as well.

Stay hydrated.

Okay, thank you, Jack.

It's really great being back at React Comp.

And we have so much to share with you today

and not a whole lot of time.

So let's get right into it.

So the first thing I wanna talk about

is pretty serious, okay?

Need all of you to take this seriously,

put your phones down, put your laps up down,

put your water bottles down, we're done hydrating.

Are you all ready?

Very excited to announce.

(audience applauding)

Very excited to announce React Compiler is now available.

You can't NPM install yet.

We'll release that later today.

So don't take your laptops out.

But yes, very exciting milestone.

And so many people contributed to the compiler

over the past couple of years.

And we really appreciate all of your efforts

bringing their compiler to life.

So can we get a big round of applause for Joe, Mofe?

And of course, thanks to me as well.

(audience applauding)

So after the keynote and after I do the release,

you can get started using the compiler

and your applications by installing

Babel plugin React Compiler,

as well as the new ESLent plugin.

The plugin has new compiler powered rules,

which are independent of the compiler.

So even if you haven't adopted the compiler yet,

the linters new rules will work out of the box

to help you find a rule of React violations

that you should probably fix.

And an important note, if your ESLent config

previously only specified exhaustive depths

and rules of hooks, you wanna update your config

to reference the recommended rule preset

so that you get all of the new rules

as well, otherwise you might not actually see them.

Now, I don't know if there's anyone

who hasn't heard about the compiler,

but if you're seeing their confused,

like what is she talking about?

The compiler is a build tool that works

on every platform that can run React.

It auto-optimizes your components in hooks

and lets you focus on what really matters.

It's also designed to work out of the box

without any code rewrites, which is pretty cool.

And it works with the latest version of React 19

as well as 17 and 18.

So that's pretty cool, right?

(audience applauds)

Thank you.

So it's easy to think of the compiler

as something that just adds memorization for you,

but it's much more than that.

It also deeply understands your code

and helps you write better React.

So make sure you download the ESLint plugin

and check that out after the talk.

So one thing as well, I don't think is appreciated enough

is that you can use the compiler anywhere

where you can use React.

So for example, last year at React Conf,

I did a live demo of adding the compiler to BlueSky,

which is an Expo app.

So the same BlueSky product code

runs on both web and mobile.

And thankfully, after the talk,

I submitted a PR to BlueSky.

And thankfully, it got merged.

Thank you, Dan, for reviewing my code.

(audience applauds)

So BlueSky was actually the first application

outside of Meta to use the compiler in production

all the way back in May 2024.

So they were on the bleeding edge.

And I just think that's so exciting to see

the richness of the React ecosystem

where you see React running across

so many different types of screens,

like web, mobile, TVs, even your terminal

or your refrigerator.

And the exciting thing is that React compiler

can run on all of them as well.

But let's take a quick look at automatic memorization as well,

like what exactly does that mean?

So one of the core premises of React

is writing declarative code.

You write code that describes what your component does

and then React handles the rest.

And if you look at this code,

it's fairly simple to understand.

The component receives some data,

it processes it, then it renders each item

and then you can click on each item.

Now, while React is fast enough

in the vast majority of cases,

you do run into situations

where components just re-render too often

that it can hurt performance.

So for a moment, let's just all pretend

the compiler doesn't exist.

I haven't given this talk yet.

And you've profiled your application

and you found that this component

is just rendering way too much.

So if you wanted to solve this problem today,

you'd have to reach for our best friends,

use memo, use callback and React.mail.

But it's really easy to get wrong.

It's also difficult to maintain over time

and it just looks kind of ugly, right?

And if you look at the code,

look at the boxes that I drew,

you actually see that I forgot to memoize something.

Can anyone spot it?

Anyone?

See my bug?

It's hard, right?

It's over here.

Of course, you used an arrow function.

This recreates the function on every render.

So we missed the case.

But the really nice thing about the compiler

is that you can just forget what I just said,

like you don't have to remember that.

And it lets you go back to writing your code

in a very natural way

and the compiler just takes care of the rest.

And even, yeah.

(audience applauds)

And it even handles that arrow function for me.

So I don't have to change the way that I write my code.

We can just write our apps in the same declarative way

that makes React so intuitive

and let React and the compiler work behind the scenes

to keep our apps fast and responsive.

So automatic memoization.

Very nice win.

It's gonna save so much time,

let you delete a lot of code,

and you just get a performing app out of the box.

You don't have to rewrite anything.

And even if you're not on the latest version of React,

it gets to used to compiler.

But the thing I'm excited about

is that the compiler is more than just a tool

for adding memoization.

And later today, you'll see Cody from Sanity

share a case study of how he's been using the compiler's

linter to find some latent issues that were hiding

in their large and complex React application.

But let's take a look at some of them as well.

So the compiler uses a steep understanding of your code

and its knowledge of the rules of React

to provide detailed diagnostics

and a cat arresting you for breaking the rules of React.

No, that's not actually a feature.

Not yet, at least.

And here you'll see that there's a pattern

that's actually really bad for performance

where you call set state inside of an effect.

Now, if you're not familiar with this pattern,

the reason it's bad is because the effect runs after

React commits the changes and then it schedules

another render through set state.

And that's really, really inefficient.

But the really great thing is that the compiler

and the linter can detect cases like this

and warn you and flag them to ahead of time.

So for example, here we can see that the linter

tells us that, hey, don't do this

and instead calculate the value of full name during render.

Let's look at another example.

If you've ever used a ref in React,

you'll know that it lets you remember some information

and whenever the information gets updated,

it doesn't re-render the component.

But since React doesn't know when the ref changes,

even reading it while rendering

can cause some unexpected behavior in your component.

And this is another case with the compiler

can detect this pattern and tell you

that, hey, you've accessed a ref during render

and that you probably shouldn't do that

or you'll be arrested by the cat.

So let's look at something a little more interesting.

So most people know, I hope,

that you shouldn't call set state in render

because set state doesn't run immediately.

It queues up an update for the next render,

which means that this code will lead to an infinite loop.

And you can see that the compiler will tell you

exactly that, that this code causes an infinite loop.

But the code we've been looking at

has been pretty simple so far.

What if we could trick the linter

by wrapping our set state in a function?

Like, can the linter still detect this?

And unfortunately, yes, it still can.

So we're all going to jail.

And this is where the compiler's deep understanding

of your code comes into play.

The compiler is built with an architecture,

so much as something you might see

and say the Chrome V8 engine.

And what that means is that the compiler's analysis

isn't just limited to syntactical problems.

It actually knows here in this example

that calling on click in render

is actually calling set state in render.

And it does this through very careful compiler passes

that track all of the different values

as they flow throughout your component.

Another pattern that we've seen

that's actually pretty dangerous and easy to make a mistake

is when you call set state during render,

but the setter comes from the parent.

So in addition to the compiler's analysis,

it can also make use of other shearistics

to determine if code is safe or not.

And here, we rely on the naming of the function

to infer that it might be calling set state

from a parent in render.

And in practice, we found this assumption to be really useful,

and this was actually inspired by a real self

or outage at meta, where someone accidentally called

a set state in render and crashed the application.

So that's been a lot, and there's a lot more rules

that I can show you as well, but we don't have a lot of time.

And, you know, make sure you download the ESM plugin.

And we can maybe find you some, you know,

some issues that are hiding in your application.

So that's a glimpse of what React compiler is.

It's what we think the future of how React apps are built.

It raises the floor for performance,

it makes your product code so much easier to write and maintain.

But again, the most exciting thing about the compiler, for me,

is that it's a platform for us to build

more and more intelligence and static analysis

to help humans and maybe even AIs write better React code.

And so our official recommendation is that all new applications

should start using the compiler from day one.

We recommend existing applications used to compiler

and adopt a compiler as well, but it's okay to take your time.

Just not too much time.

And again, for the eighth time, all apps should use the linter

because it's independent of the compiler.

And even if you're not quite ready to roll out the compiler

to, you know, get your production,

you can still use the linter and get all of those benefits

in your application.

For existing apps, we've written a new guide

on how to adopt the compiler incrementally.

So you can roll that out to your users with confidence.

And I highly recommend checking these docs out

because I wrote it, so please, please read it.

Thank you.

(audience applauds)

And okay, if you're sitting there, like, you know,

can I really trust, learn up here, refer jokes and all?

But if you watched React Con class here,

Mofe actually shared these numbers last year

about our experience using the compiler

on some meta applications.

So here, these numbers are from the meta quest store,

the store where you purchase apps for the meta quest.

And there, we saw initial load and cross page navigations

improved by up to 12%.

And some interactions were even more

than twice as fast as before.

And this all happened while memory usage stayed neutral.

While we definitely can't guarantee the same results

or similar results for your application,

this app was very carefully manually memorized.

So we do recommend trying out the compiler, you know,

and seeing if it actually gives you some nice wins,

even if you've already spent a lot of time

with manual memorization.

As part of the stable release,

we've also worked with the Expo, Vte, and Next.js teams

to either enable the compiler by default for new applications,

which is the case for Expo,

or expose an option for you to pick a React compiler

enabled template, which is the case for Vte and Next.js.

We highly encourage everyone to start your application

with the compiler so you can get all of those benefits

from day one and just really focus on building out,

you know, features that your users want

instead of just worrying about memorization.

And again, if you're not using one of those frameworks,

you can install the compiler packages directly.

So, couldn't resist.

With this same release,

compiler is now a foundation for the future of React.

And over the coming years,

we expect to see more and more React features

that build upon both the compiler and the runtime

to just really raise the bar for developer

and user experience in writing React.

So I hope all of you get a chance to try the compiler

after the talk and maybe even ship it into production.

And if you run into any issues,

please look for any of us, Joe, Mofe, and myself,

or send us a DM on Twitter and we'll try to help you out.

And finally, be sure to check out both of these talk later.

Cody, again, is gonna talk about his experience

using the compiler as one of our earliest adopters.

And then Joe is gonna share some explorations

about performance that we've done.

And that's really exciting.

So thank you very much for listening

and tolerating my horrible jokes.

And I'd like to welcome Seth back to the stage.

(upbeat music)

- How's everybody doing?

And what do we think about those announcements?

(audience cheering)

It's pretty good, pretty good.

You know, last year when we had the conference,

we had five years of things to share,

but you can see the team has been hard at work anyway.

You know, at React Comp, we have a bit of a tradition.

We show you some of the most exciting, ambitious,

mind-bending demos across the ecosystem of our products.

And then just before we let you go,

we come out here and we're like, oh, there's one more thing.

Wait, what?

We don't do that.

Ah, Apple, September.

Got it.

Okay, last year I spoke to you guys from this stage

about the power of community.

The power of our community, the power of this community.

And it's true that since the beginning,

since we open source React, but in spirit before,

that the heart of what makes React React is our community.

React is your React.

Our community is the foundation of what makes React so cool,

so special, so capable.

And when I joined the team six years ago,

I knew I'd found something special.

Something bigger than technology, bigger than code.

I'd found a place to realize my lifelong North Star,

my lifelong ambition, which is to help others

bring their ideas to life.

I knew I had found a place to manifest.

In short, I had found something really special

long after many of you had discovered it.

After you'd been building for many years the bedrock,

the foundation of what makes React what it is today.

The most popular, declarative UI framework

in the history of software.

Huge.

You did that.

Google and Apple and Meta, not to mention the mobile

and web at large, have all been influenced by the ideas

that you have created.

That's a huge legacy to leave

when it comes to software history.

And I just wanna celebrate that you did that.

You know, otherwise React is nothing but a novel,

declarative, reconciling framework, a library.

And JSX is really cool, not to mention fast refresh

and code we just saw that optimizes itself,

but what the React community has built

is really some of the most amazing technology out there.

And without it, React is just basically some really cool,

really hard to read and impossible to understand code.

What brings it to life is you.

You are what gives us the energy every day to show up

and do everything we can with all of our hearts

and all of our blood and all of our sweat

and all of our tears to help other people

bring their ideas to life.

That React, this React, is bigger than us all.

And it is important to me and to you

and to the world that until something better

comes along, React is protected

and that it's bright, progressive, future is secured.

That it remains open, that it remains with our community.

So today, I am actually excited

and I do have one more thing to share with you.

I'm incredibly excited to announce

that we officially formed the React Foundation.

(audience applauds)

For nearly a decade, that has been

an incredible steward of React,

with love and sweat and no small amount of debate,

with incredible open source contributors, maintainers,

and the incredible community sitting in this room.

And around the world, of course,

but as React has grown into one of the most important

technologies in software history,

it needs a home built for the next 15 years and beyond.

The React Foundation will ensure

that React remains independent, community-driven

and built for everyone.

It gives React a structure that outlives

any one company person to or team.

It means that React's future is no longer just ours

to shape, it's yours.

This is a huge milestone for me personally.

I, in addition to so many others,

have been working on this for many years,

and the team has demonstrated incredible

internal adaptation to make this possible.

When we started on this path years ago,

we simply were not ready to operate as a foundation.

We'd been operating as a scrappy meta team, right?

With all the meta things that comes along with that.

And so over the past number of years,

as you've seen with the staging systems and the RFCs

and so forth, we've moved into a place

where we can now interface with the community

in a much more compatible way with the foundation.

This is a huge milestone for React.

It's also a huge milestone for open source as a whole.

It's a statement that the ideas that we develop

and build together deserve to last.

They deserve to grow and flourish,

and they deserve to belong to everyone.

So here is my invitation to you.

That alongside the generous support of Meta, Amazon, Expo,

Call Stack, Microsoft, Software Mansion and Vershales,

join us in shaping the vision and the future

of what it means to be a foundation with React.

React has always been about the people,

and now with you and the React Foundation,

it will always belong to you.

Crazy, intuitive, creative, beautiful people.

Thank you for getting us to this point.

(audience applauds)