This Month in React

Carl: Hello everyone.

Thank you for joining us for the
July edition of this month in React,

where we recap and digest all of the
latest news and developments in React.

React Native, and across the web.

We're coming to you live from
Reactive Flux, the place for

professional developers using React.

I am a staff product developer and
freelance community leader here in

React Flux where I do community programs
like these events and build tools to

help keep the community operating.

May be making more
progress on one of those.

So maybe I'll do a product announcement in
the next couple of weeks or months maybe.

Mark: Hi, I'm Mark.

I maintain Redux.

My day job is at Replay where we've
built a time traveling debugger

and are currently trying to get
in on the AI app generating craze.

And other than that, I may moderate
things and read too many articles.

Mo: My name is Mo.

I head the mobile team at Theo.

I'm an active member of the React
Native community and I organize

the React Native London Meetup and
the React Native London Conference.

Excited to be here.

Carl: Excellent.

Yeah.

We missed you Last month there was
react native things to discuss.

Mark: We had no idea what
we were talking about.

Carl: Not even a little bit.

We basically just punted on it.

Great.

Cool.

I'm gonna skip job market stuff.

I don't think I'm gonna do that anymore.

'cause like who even
knows what's going on?

The jobs are wild and the indicators are.

Too fuzzy to really be
that useful, I think.

Mo, tell us about some
React native new releases.

Mo: Cool.

So we recently had React Native
Reanimated version four being released.

So for those of you who are sort
of avid React native developers,

you'll know that React Reanimated
is sort of the defacto way.

To be able to animate elements,
layouts and whatever you have inside

of your React native applications.

So the team's been hard at work.

Animates has been around as a package
for, for several years now, and

they've been iterating on it and
making it better and better over time.

There's a general push that you'll
sort of know from the previous episodes

over the last year or so towards
sort of unifying React native and

react in the web as much as possible.

And so CSS transitions and animations
are sort of becoming a key part of

Reanimated as well, so that the APIs and
the way that you can animate things in

Native world are as similar as possible.

Obviously there's some limitations that
can't make it one-to-one, but as similar

as possible between web and mobile.

And one of the other things is now that
we're in this world where you could use

React native on web and mobile, trying
to find a way to have performance.

Web-based animations and transitions
is quite important as well.

And Reanimated has been working on
this under the hood so that when

you do use reanimated in your React
Native universal app, it actually

has performant animations on the web
as well, not just on native devices.

One of the challenges in the past
has been that it's not quite great

on the web because it would use
JavaScript to orchestrate animations.

Not really great, and really,
really bogs down the performance

of your app on the web.

So some good work being done there.

A few other things to mention is that
Worklet is a part of Reanimated as well.

It's, it's a way to basically allow some
level of multithreading in your apps.

It kind of formed as a need of
reanimated itself, but they've

made it sort of an open public
API that you can access for other

multithreading needs that you may have.

So they're trying to move that.

Across into sort of a separate library and
start to separate that up because it's not

just useful for reanimated or animations.

It's useful for a whole bunch of other
stuff like background fetching and, and

you know, computationally heavy tasks
that you need to run behind the scenes.

Other things to mention is that
Reanimated used to be this huge package

and once you had, you know, imported
one thing and Reanimated, everything

was imported and so obviously that
affects things like your app bundle size.

They've now took an approach to make
it modular so that you can import.

And Bobs of Reanimated
rather than the whole thing.

Obviously it's not just a JavaScript
sort of tree shaking thing that matters

here because we're in Native World.

There's also sort of the native
compiled code and you need to be

able to modularize that as well.

So it, it's not necessarily a
straightforward process for the

team, and I appreciate that.

It was probably quite complex to decouple
a lot of this code and separate it up

into different packages, both on the
native layer and the JavaScript layer.

Carl: What does that affect on a native.

Package, I guess like app, total package
size, or does it affect like startup

performance and things like that?

Mo: It, it can affect both.

Mainly the app total size that you would
need to download is, is a key thing.

It can also affect, like you
say, the startup time, albeit

startup time is largely sort of.

Handled by Hermes, the engine that's been
created for React Native specifically

because it, it sort of optimizes to,
to avoid large startup times as a

result of having a big app bundle.

But it's really mainly
the, the, the bundle size.

And again, when we're going into this
sort of web and mobile world where

you use the same packages across the
board, modularizing as well on the

web, even though you'll have tree
shaking, is going to be good practice

so that you're not importing a whole
bunch of stuff that you don't need.

Lastly, and I, I think this is.

Something that everyone is quite
passionate about in the React native

ecosystem and has been a challenge
is shared element transitions.

So shared element transitions is sort
of the transitions that you might be

familiar with in the native world where
an element is is sort of present and

is animated from one screen to another.

So when you navigate from one
screen to another, there's

this sort of shared element.

So it might be like an image you
click on and you navigate to a sort

of detailed view of that image.

You have a navigation that
happens in the background.

But you want to have these on separate
screens, but you wanna kinda keep

that seamless expanding of the image
animation as an example or transition.

This is very difficult
to do in React Native.

You can kind of achieve it in some
hacky ways, but it's sort of on the

app developers to figure it out.

There's not been like a unified API that
you can use and it's usually quite hacky

and doesn't work most of the times.

They are working on this,

Carl: would that be stuff like
flip animations, like first,

last, interpolate, play?

Mo: No, I don't think it
would be flip animations.

The examples that I would give is, you
know, like in Instagram as an example,

if you're on the, the search page and
you see a set of posts that are sort

of laid out in a grid and you click
on one of those posts, it expands

out and takes over the whole screen.

Right.

Carl: I meant more like would the hacky
interpret in the hacky implementation of.

what should be a shared
element transition?

Would that be, is that the kind of
thing somebody might use flip for?

Mo: I'm not sure, I haven't actually
seen flip, but there are some

approaches where people have been
sort of tapping into the native layer

to be able to do that manually, but
it's not gonna be quite extensible

putting some tags and then using the
native layer to do those transitions.

So there's a few different approaches
that I've seen people do some sort

of like third party libraries that
people have created as POCs more than

anything is how I've seen it done.

The, the, the gist of it is that there
isn't really like a. Standardized

well-defined and like well tested
API to do this in React Native.

And so that's what the Reanimated
team have been working on.

It's not out yet, but they've said
that they're gonna be releasing it

as part of this major release cycle.

So four dot something will have.

Some support for shared element
transition, still TBC, but keep

your eyes open for that one.

Mark: Cool.

Honestly, that whole discussion reinforces
how many things people are doing that

I have no experience with whatsoever.

Carl: Love that.

Yeah.

I guess just to close the loop a little
bit on like flip animations, like it

reminds me a lot of shared element here.

'cause I guess like shared element
means that it doesn't like vanish.

You know, it's one thing persists.

From this state to that state.

That's my general understanding of it.

And how I had done that in 2017 was, so
you've got the current state, you've just

rendered, you have something up and then
you re-render and you get the new state.

Then you have some abstraction that cracks
the old state after the new state shows

up and says, okay, this element is tagged
with this animation, you know, indicator.

And that indicator has now gone
to this element in this new state.

It used to be here.

Now it's here.

Let's measure it triple eight, you
know, the old size versus the new size.

And then do Aran smooth transition, you
know, generate a CSS animation to make

it look like it's the same element.

Mo: Yeah, it gets a little bit more
complicated in the native world

because these are different sort of
screens that are different view nodes

on the native layer, you'd need to
have a little bit more control over

how you do that on the native layer,
the native layer might override it.

If you write that JavaScript logic as
an example, it definitely needed some

native components to be able to handle it.

Under the hood, the algorithm and the
native layer will do something very

similar, which is first screen, screen
A has this size for this element.

Screen B has this size.

Let's look at the positions and
interpolate the values and the, the

zoom of it to match the target size
as we're migrate, as we're opening

up the new screen as an example.

Carl: Right.

Oh, interesting.

Okay.

Sure.

On native, there are things already
doing that for you, so you don't

need to hack into the, into that.

You just need to actually support it.

Cool.

Makes sense.

Okay.

Mark: Probably just as well.

We really didn't have all that many
new items and new release items

this month, given that we just
sort of deep dived on that one.

So one other thing from the React Native
world, the Infinite Red has a very

long running boilerplate toolkit called
Ignite, and they just put out version 11.

The big news for this one is it.

Only sports, the new architecture.

It's been bumped to E Expo, SDK
53, some changes to the theme

implementation and they've made it
bring your own state management.

They used to default to MobX State
Tree and now they've tweaked it.

So you can pick and choose
how you want your state to be

handled within the new app.

Mo: There's a little bit of context
here, which is that the maintainers of

this library, infinite Red, have been
very opinionated on Malbecs being the

best sort of tool for React Native.

State management there.

There's some some reasons behind that.

Like Mob State Tree is quite good in
terms of sort of heavy memorization

and that can really affect performance
if you don't have stuff like that and

React native or you're not careful.

So I think they were trying to set
some practices that they were used to.

Mark: And also I believe Jamon from
Infinite Red was the maintainer of

MobX State Tree for a number of years,
and he either still is or recently

handed it off to somebody I think.

Mo: Might be that he was
maintaining it to some degree.

Yeah.

Mark: So I mean there was, there was a
very understandable preference there.

Mo: So the main maintainer of MobX
and MobX State Tree as far as I'm

aware is Michelle West Streett.

From WHO, who works at Meta,

Mark: I think Michelle handed
off MobX State Tree to into

Jamon a number of years ago.

Okay, cool.

Didn't know about that really.

That's fair enough.

Carl: Oh, interesting.

I didn't know that

Mark: he spiked MobX State Tree.

And then it's like, okay, I've,
I've proven I can build this,

but I don't have time to maintain
it would someone else like to?

Cool.

Onto the main content for today?

The big news this month is that the
React team has written completely

brand new docs for the React compiler.

Not only did they put them up as
a PR this month, that PR has been

merged and the new docs are now live.

Previously there was just a single page
under the installation setup section

of the React Docs that gave some amount
of details, and now the React compiler

has its own top level section with
multiple pages under both the learn and

reference sections of the React docs.

These sections cover a lot of things.

What is the compiler?

What does it do?

How does it work?

Should I try it out?

What build tools do it?

Does it work with?

How do I install it?

How can I incrementally
adopt the compiler?

As well as some reference section
information, talking about configuring

it and some of the concepts it includes.

And even like if I'm a library author,
should I pre-compiled my library

bundle to make use of the compiler?

So it's very clear that they've been
looking at some of the discussion

threads where people have complained
that, you know, it doesn't feel

like it's ready for adoption yet.

I don't know if it, you know, I
don't know how to configure it.

And they've taken a lot of that
to heart and put together some

pretty good docs to try to actually
address a lot of those points.

We noted that the, if you look at
the expo docs, there is currently a

section that says that their integration
with the React compiler is on hold,

but that may be superseded because
I saw a tweet from Evan Bacon just

earlier today where he said that we
are actually going to enable the React

compiler by default in Expo version 54.

And along with that, the compiler docs
themselves in the introduction section.

Actually say like, should I try
the compiler and is it safe to use?

And they specifically say at this point,
we encourage everyone to start using it.

It's still optional, but
it's in release candidate.

It is safe to use.

It's been tested in production
and we really would like

people to actually try it out.

Of course they do.

Oh yeah.

But I mean it's, it's a pretty big vote of
confidence that this is not just a whim.

That it is something they're very serious
about, that it is basically ready for

release and that they would like to
see the ecosystem start adopting it.

Carl: Yeah, makes sense.

I am not super thrilled about seeing more
function directives being introduced here.

Like I'm on record for like the past
two years here, being frustrated with

introducing more and more directives,
and so seeing now basically a compiler

flag for memorize or don't memorize this.

As the, uh, incremental adoption method.

I just don't like it.

It's, it feels like magic.

It feels gross.

I don't like it.

I don't like directives.

They scare me.

Mark: Couple other compiler bits of news.

There was some discussion on Twitter,
I believe, where Joseph from the

React compiler team gave a little bit
of background on who had worked on

the compiler, some of the timelines
and some of the influences, and then

the compiler right now has a couple
limitations in terms of tool support.

One is that while the 90% of the compiler
code is its own independent true compiler,

currently the only way to integrate
with that and actually use it is via

a babble plugin shell around it, which
also means you have to have babble.

In your build pipeline, and a lot
of people are not happy about that.

We got rid of babble.

We use, we use SWC, we use, you know,
whatever other, you know, ES build

something that's not babble anymore.

And so there's been lots of questions
about, you know, when will they get around

to offering a non babble integration?

No timeline on that yet.

But as a related part of that,
the lint rules that React

offers are also ES lint based.

And we now have other winters like
biome and oxalate that are not

ES lint and not esent compatible.

So there was a pretty good thread
between the React compiler team and

the oxalate team talking about like
what would it take to make React

compiler and the React ES lint rules.

Runnable inside oxalate, and there's
a bunch of low level technical details

about, you know, js rust interop
and, and some of the complexities

that might be needed there.

So the answer is probably not anytime
soon, but there's discussions about

what it might take to make that happen.

Carl: Yeah, and circling back to your,
you know, good thread with like some

timeline and influences and whatever
frustration I have, this is like such

a, this is exactly the same problem that
React and I guess web and like development

in general has had for a long time.

But like all of that happened
on Twitter and like that's great

knowledge and such good resource.

But the guy who asked the question
asked it on his private alt.

So like, if you are not one of
the, you know, 1100 approved people

that he has granted access to see
his thoughts, you can't see what

was asked, just the response.

So at least you can see the response.

That's nice.

But I wish they'd put something
like this in like, I don't know, an

introspective blog post or whatever.

So.

I'm just gonna keep shouting at clouds
throughout this episode, I think.

Cool.

Cool.

Let's move on though,

Mark: even before we get there.

I found the article I was looking
for, it was indeed in Tech

reads the news a few weeks ago.

This was in linking a post on directives,
prologues and JS Dark Matter, which

was an archeological explanation
of how things like JSX, pragmas and

function directives and magic comments.

Have all been used to indicate to build
tools, Hey, do something different with

this code than what you would expect.

Just reading it.

Carl: Love that.

That is actually really good.

And like basically this is all
just communicating with different

levels of abstraction between
like runtime and source code.

So it's like, I don't know, the linter
or the formatter or the, I don't know.

I guess you don't really do tests so
much there, you just do it elsewhere.

But the compiler, or transpiler
compiler is now a fuzzy, overloaded

term, and I guess they all make
sense for one reason or another, but

something about directives and the
way that they like persist through.

I prefer a magic comment, like at
least a magic comment is like very

clearly something like not runtime.

I don't know, something
about it feels wrong.

The

Mark: fact that a directive is
just a string hanging out there.

Carl: I dunno.

It seems weird.

And since it is just a string,
like why not a magic comment?

Ah, I don't know.

Maybe there was some kind of weird
esoteric, like the compiler, you

know, the, all the various compilers
and whatever, transpilers, and ASTs

transformers are all like, maybe they
muck with comments and whatever, but

also like the compiler requires that
you put it first in your Babel so it

gets the untransformed code anyway,
so that doesn't sound right to me.

I don't know.

Weird doesn't seem necessary.

I guess the root of my angst here is that
like when they introduced the "use strict"

directive, like when they introduced
the concept of a directive, they

said, we're never gonna do this again.

Like, don't do this.

This is bad.

We should, we shouldn't have had to do
this, but we did because weird legacy

concerns don't do any more of these.

Mark: And then the community
decided, okay, now we got a

new mechanism to play with.

Carl: We got like, how many
do we have for React now?

Like.

I can think of four
off the top of my head.

Mark: Client server memo.

No memo.

Carl: Yep.

Okay.

Maybe four, but like, come on.

That's 400% increase from one.

Come on.

Mo: Now you can have two at the top of
one file, which is gonna look weird.

It's gonna take some time
getting used to that one.

Wait,

Carl: can those even, are
the, is that even compatible?

'cause it's gotta be, the
directive has to be the first line.

I

Mo: don't know how that would even work.

Moving right along.

Alright, so back into React Native World.

The folks at call Stack have been
working on some other projects under

the, under the smoke screens, and it's
some cool stuff that they've released.

They've basically enabled Node API
support at a very basic, primitive level.

They're, they're working,
still working on this.

They've made some good headway with this.

So they're bringing Node API
support into React native.

Now, not to be confused with node
itself, node API is basically like a

mechanism by node js that allows you to
use C based languages to interact from

JavaScript code to call native code.

And so you can write native
add-ons in CC plus plus.

Even rust or swift.

And then they can be used and
ingested by JavaScript applications.

So there's a few reasons for doing
this and it, it really goes more

into the internals of React Native.

And you know what this means for library
maintainers, for built tool maintainers,

and for really meta itself as well.

But the two key things
here is faster build times.

And closer convergence with native
web libraries that may already exist

and be using the node API mechanism.

So at a first level build times, and
I think this is the bit that will

affect users more than anyone else is.

Basically in the rate of world
today, most native modules are

actually distributed a source.

So every time you make a build, you
actually have to compile it all and do

the build step, which is quite long.

Building a typical rec native app
somewhere around 10 to, if you've got

a massive scale app, it could takes
several tens of minutes to actually

do the full build of the app, right?

But it's a long, long time now.

You don't need to do this for like
your development workflow typically,

or that often, because you wouldn't
change native dependencies every day.

You would just do this when there's
a new native dependency that's

been introduced, but it's still
a significant amount of time.

Right?

And so the idea is if we can
get some of these prebuilt.

Using a mechanism like the node
APIs, then we can bring this

time down quite significantly.

And so one of the things that
they ran as a test was for a basic

sort of React Native core app
that you know is just having the

basics of React native within it.

They think that they could bring down.

The build time to close to seven
seconds, which would be insanely fast

in comparison to what it's today.

So this could be some really cool stuff
that's down that's coming down the line.

The other side is that there is already
an ecosystem of node API compatible

sort of applications and run times,
and so, so many sort of libraries.

Web API libraries like Web
RTC or Web Audio Canvas.

These are implemented with node API.

Now, they're not going to be direct
one-to-one mappings for native, but

there is already an initiative to try
to, to try to align on the web API spec.

And so this is sort of
another part of that puzzle.

And so if you bring these two together,
suddenly we can use sort of web APIs

and React native, and it could be a
really, really cool future to look into.

None of this is.

None of this is sort of like fully
there, and there's gonna be, this

is a long term effort, but it's
something that they announced this

month, and it's quite exciting.

Carl: I've had enough struggles with
native binaries on desktop where they're,

you know, like intended to be compiled
for just like, like mostly across,

like upgrading, upgrading a version
of that, or node versions or whatever.

But I, I've had enough struggles
and complications there to be wary.

Of what the actual experience
of using this will look like.

But this is, this is really cool.

This just even having made enough
progress at this to announce it and

like meaningfully talk about it as
a thing they desire is pretty cool.

Very hard, really hard problem.

I'm curious how they're implementing it.

Mo: It's definitely not trivial.

Carl: Cool.

Alright, moving on a bit.

So there's been a bunch of Vercel things
this week, a fair number of departures.

I'm sure people are coming and going
all the time and we just, you know, we

can't get a comprehensive list of that.

But they, they had a couple of relatively
high profile departures in the last

month, starting with the most notable
Lee Robinson, who has been there for.

Five years, a long time.

Was he there before COVID?

Mark: Not sure on the timeline.

Like it, it felt like he'd been
there much longer than that, but

apparently it has only been five years.

Carl: Yeah.

Okay.

No, you're right because
he, he put out a blog post.

Well, anyway, I'll, I'll stop
speculating on the timeline, but

to me, he is highly identified.

With Versel, like, you know, if I think
of Versel, I think of, uh, Guillermo,

Roush, and Leero, just like by volume
of activity and like prolificness in

content and social media interaction
and blog posts and example resources.

So just all of it.

So he has now left Versel and is
working at Cursor, which like.

That seems great, at least in terms
of like mind share and hype and

you know, alignment, potential,
alignment with future, whatever.

Cursors is definitely a
really hot company right now.

I've had some private conversations of
with like, can they keep doing that?

'cause at the end of the day they're a
fork of VS code and like fork of a large

project with 30 people working on it.

Which I think is in the ballpark of
how many employees Cursor has versus

like Anthropic, which is, you know, a
giant, huge beast with all of the money.

So like it's cool.

Great for him.

Definitely there's a lot more like
oxygen in the room in terms of

excitement and like potential at cursor.

I think so.

Cool.

I'll be keeping an eye on that.

I use cursor.

It's nice, so he'll still remain in
my, I don't know, professional spheres.

But yeah, he had a really good blog post
that he put up called, UH, five Things

I Learned From Five Years At Versa.

I appreciated it.

His number one was go hard at work,
then go home, and he closes it

with, when I'm offline, I'm offline.

I'm a hundred percent focused
on my wife and daughter.

To be clear, I still get
this wrong sometimes.

It's a never ending pursuit of
work, life, harmony, takeaway.

You can work really hard
and set clear boundaries.

I'll say That's hard.

I struggle with that.

I don't, I don't have a
wife, I don't have kids.

So like in that section he talks about
like responding to tweets from the beach

on his honeymoon and like, yes, I want
to believe that you can work really

hard and set clear boundaries to where
you're not working on vacation doing, you

know, social media comms work from the
beach, but also like if you're not there.

Like, people aren't gonna wait three days
for you to get back from vacation to,

you know, get the authoritative answer.

Like, if they ask a question, then like,
the person who is Johnny on the spot

answering it in their time of need, like
they are gonna get the, I don't know,

the kudos, the energy they're gonna, you
know, people are gonna start gravitating

towards them for future questions.

I'm like, that's.

This going so hard is how Leero
managed to get that level of

status, like in my own brain.

And so I wanna believe you can work
really hard and set clear boundaries.

I'm not always so sure about that.

I, I dunno.

I wrote, I actually wrote a
little blog post kind of on that

subject almost exactly a year ago.

I'll link it here.

I probably won't put it in the transcript.

Just kind of talking about that
general thing and like I, I had a

kind of similar experience to what he
describes here of like, going really

hard and like poor boundaries and
like burnout and all of the, a lot

of the benefits, a lot of the costs.

And what I kinda realized is that
like, I don't know that I could have

achieved the kind of success that I
got without that level of burnout and

I don't know, poor boundary setting
because like, it's because I gave.

All of my attention to maybe not just
work, like some of, a lot of my attention,

you know, the full-time work, but also
investing in things like reactive flex

or just learning new tools and staying on
top of the cutting edge outside of work.

Like that was really poorly boundaried
and like fully throughout my

twenties, I ignored a lot of myself.

I just really think that that is, I wanna
believe that you can succeed and achieve

big success without giving up that kind
of, I don't know, intimacy with yourself.

But I don't know that you can, I
don't know, it seems really hard.

And it, it just notable to me that
like the only people I see talking

about that and like saying things
like, you can work really hard and

set clear boundaries are the people
who had poor boundaries, achieved

success, and are now reflecting on it.

So, I don't know.

Mark: Yeah.

It, it is tough, but I, I have a, I have
a lot of respect for Lee Rob and that

the work and effort that he's put in,
when I just think of the word derel,

he is the first that comes to mind.

He, he's always, you know,
omnipresent in any kind of Reddit

or Hacker News or Twitter thread
that mentions Versel and Next.

And, you know, even if you maybe,
you know, at times disagreed with,

you know, what he was saying or
representing the company wine, he

absolutely like did a great job of
being there and answering questions

and, and being involved in reaching out.

It's definitely a loss for Versel
and when I wrote my React Community

article, you know, recently, I had
a line in there about Versal had

a large Dere team that updated the
next docs, and he corrected me.

It's like, no, there were
two of us at that point.

I was like, oh, whoops.

I got that wrong.

It seemed like you had a large team
because you were doing so much work.

Carl: Right?

So, yeah, I don't know.

From the comment, from the, from chat,
from re Sam, bit of taking advice from

lottery winners, vibe occasionally
like, yeah, that's, that's what it is.

It sounds like survivor
bias, things like that.

Anyway, this is, we're already like kind
of far afield from where we started here.

This was talking about Versel
and some of their updates.

This was a good piece.

Lee Rob, wish him the best at cursor.

I'll be paying attention still.

The, uh, creator of SWC also left Versal.

He's taken some time to, to rest and focus
back on, uh, SWC again, so that's great.

I'm not as familiar with him as
a, you know, individual human,

but I am familiar with s wc.

So cool.

Good luck to him.

Love that.

And another prolific react ecosystem
speaker and like educator, Sam

Selikoff joined Versal to do
content and some other things.

His Twitter feed is all like, all
about ramping up and like, you

know, spinning up on a new team.

So that's, that's a fun,
that's a fun moment in time.

Team transitions and gathering
context in a new spot.

Mark: And then overall, and
not, not react, but adjacent.

So next is the view ecosystem
equivalent to next Js.

And Versel had already picked up,
you know, rich Harris who builds

Svel, possibly one or two other
non-reactive framework authors as well.

And VL actually just acquired whatever
group or company has been behind N and is

hiring all of the developers, including
Daniel Grow, who I think is the, the lead.

Developer maintainer for N So you know,
Versal is not just about react like they,

they are sort of putting their money where
their mouth is and trying to back many

different tools that, you know, build
apps and of course can be run on versal.

That's

Carl: got me curious about what kind of
like corporate structure is behind Nuxt.

'cause like, you know, if it's
individual developers then like.

You can't acquire that,
you just hire them.

Mark: I think next Labs may be an actual
company, but I don't know how much of

a like profit seeking company it is
versus some kind of little holding thing.

Carl: Right.

I'm now, I'm on the next website.

I see next UI Pro, A
hub for managing apps.

So I guess like deployment
and then like a visual editor.

And I see some reference to
courses and stuff too, so like,

yeah, that sounds like a business.

That sounds like they're selling products.

Kind of a mishmash of various different
open source monetization techniques there.

So.

Cool.

Nice.

That's good to know.

I appreciate that.

Love someone who's trying to take a
project and turn it into a business Relat.

Another smaller update.

This is like barely an update, but
I've been tracking A an RFC, actually

an RFC that Lee Robb started back in
April on deployment adapters for next

from Versal, basically making it.

More robust and reliable, I guess, to
deploy next projects to infrastructure

that isn't hosted on Versal.

So the, a staff engineer from Netlify gave
a response that's pretty lengthy, pretty

serious, you know, it's got like, you
list six gaps and 10 questions and four

suggestions, mostly minor suggestions.

It's just cool to see that moving along
slowly and I question the momentum

now that Lee Robb is no longer there.

It's just really hard to hand
off major projects like that,

major initiatives like that.

But yeah, that's cool.

Neat.

Love to see it.

Mark: Okay.

Somewhat smaller item, but
definitely worth calling out.

So Ryan Carniato, the author of
Solid, is, you know, pretty much the

world's foremost expert on signals
as a state management mechanism.

And there was a lot of back and forth
and chatter, and I think we even

referred to some of it in our, in
our last talk about like Ryan for and

Michael Jackson from Remix were kind of
questioning like, why does Signals exist?

Why do you know?

Why do these different
frameworks look sort of the same?

And I think somewhat inspired by some
of those questions and discussion.

Ryan put together a 10 minute video
on React and Signals what every React

developer should know about signals.

And Ryan like me is very big on history
and context and explaining how we

got from past tools and decisions
to current tools and decisions.

He goes into some, some of the history
of signals, you know, they originated

with early JavaScript frameworks
like Knockout, but the concepts and

implementation of signals have evolved
significantly in the last 15 years ago.

And so he talks about some of the
actual technical advantages of signals.

And then he also does
some, some myth busting.

You know, he pushes back
and says they're not magic.

They do scale.

A lot of other frameworks like Angular and
View rely on signals to make them faster.

And he also talks about comparisons
between like, what's the difference

between three ACT compiler and signals
or reacts virtual dumb in signals.

And I think what a lot of that
sums down to is that in react.

The component is the smallest unit of
update granularity, like you set state,

at least one component will re-render
the whole component renders, and then

maybe only a few bit bits of it need to
be applied, but you had to run the whole

component to see what needed to change.

Whereas with signals, it's this
one value changed and it's more

directly attached to the output.

And so only the bits of the
output that actually relied

on that need to be calculated.

And it's not an earth shaking discussion,
but given that there's been a lot

of hype and discussion and arguing
back and forth, it's a good overview.

Looking at some of like.

Some of the pros, cons, concepts,
and myths around signals.

Carl: Yeah, I missed that.

I need to give that a watch because
I hold a number of myths and

misconceptions about signals, and I
would like to understand them better.

Yeah.

Mo: Nice.

Next up, we have another release.

So we've been talking about
this for a few months.

On and off because it's been sort
of an RC mode, but React Native Uni

Styles 3.0 has finally been released.

Now there's a few points
to sort of hit here.

Uni Styles came out as sort of like a
very performant, lightweight styling

option for React Native because there's
a lot of styling libraries that are

quite complex and have a lot of.

Stuff included within it.

But the challenge with a lot of those is
that it also comes with a little bit of a

performance hit because you've got a lot
more being bundled into your application.

Uni styles is, is sort of since then
being this sort of lightweight JavaScript

only implementation has has dug into this
sort of performance space a bit more.

And this newest release is really digging
into the new architecture with with

Fabric, which is the new render and
it uses native code and c plus plus.

To basically bypass the JavaScript
layer when possible and keeps us

track of the styling dependencies in
c plus plus, and we'll only update

affected styles and components on
the native layer as much as possible.

Again, this is like some things
are possible on the native layer.

Some things aren't.

In terms of styling and, and the
visuals of it, but as much as it

can possibly do, it does that in the
native layer and avoids re-render.

The maintainer kind likens this
to CSS on the web in that it's not

handled by JavaScript, but it's a
different layer that that handles it.

On top of that, added a bunch of extra
functionality through a babble plug

plugin to handle things like theming,
break points, orientation, font

scale, and maybe even right to left
styling if you need that for your app.

And so the by and large, the biggest thing
here is that there is a performance boost

and they've done some measurements to,
to show how much of a performance boost

you can get because of these safe three
renders that would've previously been

happening because of styling changes.

Other noteworthy things to mention
are that there's some new features

around sort of variance or scoped
themes and so on and so forth.

You can go read through the blog
post in more details to understand

what are the sort of more
granular new features that exist.

But also given that this is sort
of a universal library that works

on web and native, there is a
new web functionality as well.

Some web only styles, some pseudo
classes that they've introduced

and some support for class names
that would be targeting the web.

So there's some stuff around web support
as well, which is quite interesting.

But yeah, that's Uni Cells 3.0.

Give it a give it, give it a quick look.

Cool.

Love that.

Mark: Finally, we have a couple different,
uh, react server component updates.

The React Router team has been iterating
for a while on their work in progress

server component implementation,
and they've put together a blog post

describing a path forward, so they go
through some details talking about the,

and ways you would handle things like
streaming UI or in lighting data in

existing React router framework mode
versus how you might handle it with

their server component implementation.

And so there the summary is that.

apparently they're going to revamp
the framework mode to be built on top

of their server component support.

They are still labeling the server
component support as unstable,

but they do want people to
try it out and give it a shot.

So looking at some of these examples, it
looks pretty significantly different usage

wise than say like the next app router.

It maybe looks even a little more
similar to how Parcel had almost

like a pick and choose your own
server component usage approach.

So it is very cool to see
additional frameworks providing

support for server components.

As well as that we're starting to
finally see some variation in how

they might get used and not just.

The way next does it is
the only way to do it.

Along with that, Devin Govett from
parcel put together a pretty good

article where he was talking about
how parcel bundles, server components,

and he goes into some background
detail about like, you know, what is

a bundle even do in the first place?

How does it.

You know, follow the, the module graph.

How does it handle dynamic loading?

How do the pieces fit together?

And then talks about, okay, and since
React server components is really a

bundler driven feature, here's how
server components actually rely and make

use of some of those bundler aspects.

And along with that, I think
we've previously mentioned that

there's been an in progress.

Attempt to build RSC support
directly into Vite's React plugin.

And there's one person who appears
to be steadily cranking away on

trying to make that support possible.

And I'm seeing a number of the to-do list
items in the roadmap being checked off.

So I don't know how far along that is.

But it seems like a pretty serious
effort to make that happen.

So the server component
ecosystem is slowly filling out.

Carl: Yeah.

Interesting.

I see one of the to-do list items in
that is moving waku to VJS plugin, RSC.

That's interesting.

'cause I, I had understood,
I mean, Waku was like.

A proof of concept implementation of
like how to do a framework on RSC.

So it's interesting to see that move from
like custom one-off implementation to

relying on a, you know, kind of delegating
RSC support back into, back into Ved.

Love to see that.

That's cool.

Mark: Okay, moving on
to the lightning round.

Lightning round.

Corbin Crutchley, author of the Framework
Field Guide ebook, put together a very

lengthy deep dive, which I highly approve
of, called the History of React through

Code, where he goes back and looks at a
whole bunch of different react features

that were added over time and kind
of argues that you know what these,

the, these actually have sort of a.

Intellectual cohesiveness a like
a design cohesiveness to them and

that they, they all, it makes sense
when you look at the sequence of,

of features and how they were added.

Meanwhile, TK Dodo, Dominic Dorf, Meister
maintainer of React query, just put up a

post today where he has some thoughts on
when use callback is actually useless.

And I think his argument is actually,
it's useless in a, in a lot more

cases and you probably don't
actually need it all that often.

Carl: Cool.

There was a NPM supply chain
attack that was pretty interesting.

I believe.

The issue was that a couple of relatively
high profile maintainers got phished,

and yes, there's a phishing campaign on a
typo, squatted, URL, which is NPN js.com.

So it's a couple of major.

Maintainers got successfully phished
through that, which then, uh, stole

their NPM credentials and published
malicious versions of packages.

Yeah, so, uh, malicious releases
included lin config, prettier.

That's big Lin plugin, prettier.

Think kit packager, core
and nappy post install.

So the, like, most of those not so big.

I, I haven't really heard of,
heard about 'em, but yeah.

Esly config, prettier, that's big.

And they got version,
they got major versions.

8, 9, 10. Eight, nine, and 10.

Okay, so make sure you're not
using version 10.1, 9.1 0.1.

Anyway, if you're using those, check it.

If you're using ES link config,
prettier or ES link plugin prettier.

Make sure it's not a vulnerable version.

Check your lock files.

Yeah, that's not great.

Mark: I know one of the other
redix maintainers got the

phishing email and avoided it.

It's definitely semi widespread campaign.

Carl: Wild.

They must have hit so many people to get
a couple of major vulnerabilities in.

Cool.

Mo: So next up, very quick one.

You might've remembered the old expo
router demo from last year's react conf,

where they showed RSCs in the world
of expo router for building an AI app.

Something very similar to that is
now an open source project that

you can clone and play around with.

So Evan Bacon has released a demo
of an AI app that can generate.

With AI native components
and stream them in with RSCs.

It's pretty cool.

So clone the repo, play around with it.

It's an interesting little demo.

Mark: There was a Reddit thread
that was asking how does Facebook

slash meta actually build and
serve their React applications?

And some former meta engineers responded
with a few technical details talking about

how they do a bunch of dynamic bundling,
and they also use, I believe Hermes or

static Hermes on the back end to pre-build
some of the server rendering pieces.

So, you know, a little
peek behind the curtain.

Mo: Cool.

And we talked a little bit about Nitro
modules over the months, the past few

months, there is a new library that the
Margie folks folks have been working

on called React Native Nitro Image.

And so this is built on
top of Nitro modules.

I was actually talking with someone this
morning about some of the challenges

with images on the native layer when it
comes to loading them in React Native.

So this is very much welcome as a
change to hopefully improve performance

across the board for React native.

Mark: One of the weaknesses of
React Server components has been

that there hasn't been a good
testing story for them yet, or at

least not one that I've heard of.

Someone put up an article
with a way to test them.

However, it's incredibly hacky and relies
on overriding some of reacts internals,

so it's probably not a good way, but it
is a way to try to test them if you like.

And then there was a pretty good article
that gave, it went into a bit of a

technical dive and deep dive on how a
company improved the interaction to Next

Paint Web Vital Metric in their app, and
gave a bunch of very practical examples

of problems they found in their app and
ways that they, they addressed those.

Mo: Cool.

Next up, there are some new styling
properties that are being proposed

to be added to React Native.

So this is being done by Nishan Bede,
who has been doing a lot of work

in trying to bring some CSS styling
into React Native and better support.

This time there's a pr up that
adds support for background size,

position, and reply and, and repeat.

So this will be quite interesting to
see when and if it gets merged in.

Carl: Yeah.

Speaking of, I don't know, new CSS things.

Chrome 1 37 added an if to CSS.

There's a conditional flow, or I don't
know, there's a condition now in CCSS.

I have not seen that before.

So I guess it's a way of, you
know, you can consult the various

variables you've set up and evaluate
what the associated styles are or

associated values and conditionally.

Do one thing or another.

Yeah.

Mark: Yeah.

It, it, it looks like
it's a built-in function.

You pass in a very, like a, an existing
variable or property value as the

first, and then it's, if it matches,
then it's a, if it doesn't match,

then it's b like, almost like an
Excel function, like kind of a thing.

Mo: Reminded me exactly of that.

Are we finally at the stage
where CSS is turning complete?

Carl: I remember seeing a demo of
turning complete CSS like 15 years

ago if you include user input.

So yeah, it was like a grid of check
boxes and uh, I think the, the human

had to interact with stuff, but it was
turning complete, if you included that.

Mo: So I think we just need loops and
it'll technically be turn complete.

Carl: Yeah.

Wild.

Anyway, that, that seems
interesting and new.

This document that I'm reading is using
something else that I don't recognize.

The, the example they have here is if
style, you know, dash color, white, so I

guess that's using a different function
to read the styles of the current element.

Something.

That's what it looks like to
me, but that's also new to me.

So like between conditionals and
being able to read the current state

of element are, uh, interesting.

Mark: There was a discussion thread
on Blue Sky where someone, where one

of the React team members said that.

They were, they had tried to submit an
update to React Dev Tools extension in

Mozilla's, Firefox, add-on store, and it
was getting blocked because Mozilla has

some very specific and strict rules around
how code gets built into extensions,

and suddenly, all of a sudden, someone
on the Mozilla side is complaining that

the way React builds their extension
is hypothetically a security concern.

There were also some numbers thrown
around about how many Firefox users of

the dev tools extension actually exist.

And it was only like, maybe
like 120,000 or something.

Whereas I think the, the last time I
looked at the, the dev tools extension

for Chrome, it's like 4 million.

So the React team was actually
saying, you know, maybe we, we

won't even bother building the
extension for Firefox anymore.

It's, it's not worth the effort.

You can always add the, you know,
the unbundled version yourself.

I think they maybe managed to
get the attention of someone

from Mozilla to try to, you know,
bypass the stuck review process.

But clearly that's a pain point.

And

Carl: I gotta say, just side load
this extension that can read all

of your input on every site is the
dangerous thing to do at scale.

Like if you just tell millions of
people side load this application,

there's gonna be dozens of malicious
actors who spin up their own.

Side load version of the extension
that does malicious things.

So Oof.

Don't like that.

So yeah, hopefully they can
fix this, you know, correctly.

Mark: And so another item, so we've
previously mentioned that, you know,

biomes working on version two and they
had included some typed some support

for typed aware rules that normally
would've required integration with

the TypeScript DS went package and the
TypeScript compiler ENT came out with 1.0.

There, there's a bit of additional
information and updates on both of those.

So there was, there was an article.

Talking and comparing the different
approaches that Biome and Oxalate

are using to implement typed support.

And then we got a couple links
to some of the discussions where

those linters are doing it.

Biome appears to be building in like their
own, almost like a miniature version of.

Typed processing, whereas Oxalate
has taken the new TypeScript

written in Go compiler and sort
of hacked up an interop layer.

Then they're relying on the new TypeScript
go compiler to do the type checking work.

And that approach
appears to be working it.

They said they've implemented a number
of the different type to wear rules,

and it seems highly performant, so you
know that in addition to being able

to build our apps faster, we may be
able to lint our apps faster as well.

Cool.

We've been going on for a while about
how the remix team has been dropping

very, very vague hints about what
remix version three is going to be,

to the point that it's really getting
very, very annoying for those of us

reading their, their Twitter accounts,
and I still haven't seen any actual

code of what the framework itself.

Will be like, however, there they
did put up a development branch that

includes some of the support packages
that they're going to be using as part

of the implementation of version three.

So like it's not the full framework,
but there's a lot of individual

sub packages for various like tar
parsing and other sorts of things that

they want to be usable standalone,
but they're building them for the

purpose of usage in version three.

So it's not a full look at what,
what they're doing, but it's a little

bit of a peek behind the curtain.

Mo: Cool.

Next up, we've got another sort
of honorable mention of releases

that happened over the last month,
and this is React native wallets.

So there's a lot of sort of.

Wallet style libraries that have come and
go in the React native ecosystem, not one

that's really been maintained extensively.

And so the folks at Expensify and Software
Mansion have partnered together to

create the React Native Wallet library.

And so the idea is that.

It's firstly a cross-platform
way to add payment and credit

cards to Apple and Google Wallet.

Now, there's libraries that
like handle passes and tickets.

They're quite limited.

I've used a few of them in
the past, but this is more

specifically on payment cards.

And so the idea is that you can maybe.

Hopefully through this process avoid
needing to integrate a whole bunch

of different SDKs for different
cards and different and different

platforms, and you can kind of
just use this library to handle a

lot of that functionality for you.

Sounds quite complex because, you know,
payments are usually quite difficult

to get working, so I'm curious to
see how well this works in practice,

but I've not had the use case yet.

Typically payments and, and cards and
stuff like has so many different people

that you need to communicate with.

The card issuer, apple, and a whole
bunch of other people in the process.

So curious to see how extensible and
generic this is gonna be, but very cool.

Carl: Yeah.

Interesting.

Also, it's the first time I've seen a
wallet library that was not Web3 in a

long time, so additional wallets, right.

This is a very small update, but we've.

I talked a bit in the past
about Deno versus Oracle.

Deno has been suing Oracle for use of
the JavaScript trademark because did

you even know that Oracle owned it?

Oracle owns the JavaScript
word, the word JavaScript.

So basically the only content update
here is that in the past, at some

point previously in the litigation,
Deno filed a claim of fraud because.

Oracle filed supporting evidence of prior
use of the trademarked term JavaScript

by referencing the node JS project.

Generally as something that they
did and you know, who did not start

or maintain node js is Oracle.

So like basically they filed a just
wildly inaccurate claim supporting that.

They do in fact use JavaScripts.

So that unfortunately was dismissed.

The fraud claim was dismissed, which seems
strange to me because like if you say I

made this and you didn't, seems wrong.

But anyway, that's really the
only major update here, but

hopefully we will hear more.

Hopefully this will go
in a good direction.

I am not super confident of that,
but August and September have some

major court dates, so maybe there
will be more updates later this year.

There's also an update from
CloudFlare on AI crawlers.

They have declared
content independence stay.

No AI crawl without compensation,
which seems lovely, Cloudflare's in a

pretty good position to meaningfully
control traffic in that kind of a way.

Lots of real services are using
CloudFlare for that purpose.

So, yeah, seems good.

I've heard a couple of anecdotes of
people with smaller services getting

absolutely slammed with traffic from,
you know, poorly coded AI supporting

crawlers, trying to gather information
and doing it just greedily or excessively.

So, seems good.

Seems nice.

Mark: All right, and last couple items.

The folks at Meta have been working way on
static Hermes, which is an attempt to take

the existing Hermes JavaScript engine for
React Native and be able to pre-compiled

entire JavaScript apps to a native binary.

And they put up a tweet with some.

Performance numbers comparing
static hermes's output versus a

couple of other JavaScript runtimes.

The numbers seem higher,
which seems like a good thing.

And they also mentioned that they think
they will have a release available,

quote unquote soon, and that they
are using it internally at meta.

So, you know, that seems like
another potentially useful

tool to have in the ecosystem.

Finally, the folks behind the
various state of surveys have

put out the state of HTML survey.

So that's open.

You can fill it out, test out your
knowledge, answer some questions

about what various new H TM L features
you may or may not be familiar

with and what you think about them.

Mo: I did not know them.

State of HTML.

Very interesting.

Carl: Yeah, I think they started
like two or three years ago.

It's relatively newer.

I mean, the state of.

X has really exploded in
the last couple of years.

It's great.

I love that.

But I do worry about like survey
fatigue and a lot of these are

trying to solicit answers from
the same population of developers.

So I don't know, maybe, maybe.

We'll, we'll see how that plays out.

Cool.

Alright, before we close out,
let's, uh, talk about some

coming like four days, there's
Big Sky devcon in Bozeman, Montana.

Seems good.

Kansas City Developer
Conference, which is not KCD.

It's KCDC, but it's not Ken C
dos that's happening August 13th

and 14th in Kansas City, Kansas.

We also have React Universe September
2nd through fourth in Wroclaw

Mo: I've been there enough times where
I've been taught the pronunciation because

butchered it several times, but it's,

Carl: uh, we've also got Ways Conf coming
up September 16th and 17th in Krakow.

I'm also probably butchering,
but also in Poland.

Cascadia js is September 18th,
19th in Seattle, Washington.

And we've got Squi Squiggle conf
in Boston, September 17th and

18th, which should be great and
I should be there, I believe.

And of course, react Conf October
7th and 8th in Las Vegas, Nevada.

I also just heard about Remix Jam,
happening October 10th in Toronto, Canada.

Yeah, that's new.

I don't know that they've
done a conference like that

before, so that's interesting.

But yeah, that's all we
got for you this month.

Thanks so much for joining us.

We will be back probably on the last
Wednesday of August, but we've been.

Jumping around the last few months,
but we'll be back in your podcast

feed just as soon as we can.

Mark: Always fun.

Way too much to keep track of, but
hopefully this has been useful.

Lovely to be with you all
and see you all next month.

Carl: Great.

We gather sources from this week in React
Bites, dev Next JS Weekly, the React JS

subreddit, and here in React to Flux from
the E, the Tech Reads and News Channel.

If you see something that you think we
should talk about, definitely Sheridan.

Channel or send it to me
at hello@reactiflux.com.

If this is a show that you get value from
and want to support, one of the best ways

you can do so is by submitting a review on
whatever platform you listen to it on, or

tell your friends and coworkers about it.

Thanks so much for listening.

Talk to you later.