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