TMiR 2025-07: Vercel shakeups, new React Compiler docs

Transcript from Tuesday July 29th, 2025

This Month in React: July, 2025

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. [00:00]

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. [00:16]

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. [00:32]

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. [00:46]

Carl: Excellent. Yeah. We missed you Last month there was react native things to discuss. [00:58]

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

Carl: Not even a little bit. We basically just punted on it. Great. Cool. [01:03]

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. [01:07]

New Releases

Carl: Mo, tell us about some React native new releases. [01:17]

RN Reanimated v4

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. [01:20]

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. [01:40]

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. [01:59]

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. [02:18]

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. [02:41]

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. [02:59]

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. [03:21]

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. [03:38]

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. [03:54]

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? [04:04]

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. [04:11]

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. [04:33]

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. [04:49]

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. [05:08]

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, [05:26]

Carl: would that be stuff like flip animations, like first, last, interpolate, play? [05:38]

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. [05:43]

Right. [05:57]

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? [05:58]

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. [06:08]

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. [06:20]

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. [06:37]

Mark: Cool. [06:52]

Honestly, that whole discussion reinforces how many things people are doing that I have no experience with whatsoever. [06:53]

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. [06:58]

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. [07:09]

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. [07:37]

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. [07:54]

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. [08:07]

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. [08:29]

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. [08:40]

RN Ignite toolkit v11

Mark: 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. [08:46]

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. [09:06]

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. [09:14]

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. [09:25]

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. [09:41]

Mo: Might be that he was maintaining it to some degree. Yeah. [09:51]

Mark: So I mean there was, there was a very understandable preference there. [09:54]

Mo: So the main maintainer of MobX and MobX State Tree as far as I'm aware is Michelle West Streett. [09:56]

From WHO, who works at Meta, [10:00]

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. [10:02]

Carl: Oh, interesting. I didn't know that [10:08]

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? [10:10]

Cool. [10:17]

Main Content

Mark: Onto the main content for today? [10:18]

Compiler docs are merged! (live docs, and config API)

Mark: 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. [10:21]

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. [10:54]

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. [11:16]

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. [11:34]

Expo docs say it’s “on hold”, but Evan Bacon says Expo 54 may enable the Compiler by default

Mark: 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. [11:42]

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. [12:05]

Of course they do. [12:30]

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. [12:31]

Carl: Yeah, makes sense. [12:43]

Oh no — more function directives , “use memo” and “use no memo”

Carl: I am not super thrilled about seeing more function directives being introduced here. [12:45]

DIRECTIVES

Carl: 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. [12:51]

Good thread on some history

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. [13:13]

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. [13:33]

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. [13:55]

Some tech discussion on the complexities of making React Compiler work with Oxlint

Mark: 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. [14:19]

So the answer is probably not anytime soon, but there's discussions about what it might take to make that happen. [14:48]

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. [14:55]

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. [15:09]

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, [15:28]

Mark: even before we get there. [15:40]

Directive prologues and JavaScript dark matter

Mark: I found the article I was looking for, it was indeed in Tech reads the news a few weeks ago. [15:41]

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. [15:45]

Just reading it. [16:05]

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. [16:06]

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. [16:24]

I don't know, something about it feels wrong. The [16:41]

Mark: fact that a directive is just a string hanging out there. [16:44]

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. [16:47]

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. [17:13]

Mark: And then the community decided, okay, now we got a new mechanism to play with. [17:32]

Carl: We got like, how many do we have for React now? Like. I can think of four off the top of my head. [17:36]

Mark: Client server memo. No memo. [17:40]

Carl: Yep. Okay. Maybe four, but like, come on. That's 400% increase from one. Come on. [17:43]

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

It's gonna take some time getting used to that one. Wait, [17:52]

Carl: can those even, are the, is that even compatible? 'cause it's gotta be, the directive has to be the first line. I [17:54]

Mo: don't know how that would even work. Moving right along. [17:58]

Node API Support for React Native

Mo: 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. [18:01]

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. [18:12]

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. [18:38]

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. [18:59]

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. [19:22]

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. [19:41]

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. [19:59]

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. [20:21]

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. [20:42]

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. [21:02]

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. [21:11]

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. [21:25]

Very hard, really hard problem. I'm curious how they're implementing it. [21:43]

Mo: It's definitely not trivial. [21:48]

Vercel shaking things up

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. [21:49]

Leerob is at Cursor now — Five Things \[he\] Learned at Vercel

Carl: 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? [22:02]

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. [22:15]

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. [22:21]

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? [22:45]

'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. [23:05]

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. [23:24]

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. [23:46]

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. [24:03]

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. [24:27]

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. [24:47]

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. [25:06]

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. [25:23]

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. [25:50]

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. [26:09]

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. [26:22]

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. [26:33]

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. [26:55]

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. [27:21]

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. [27:35]

SWC creator leaves, focusing on SWC for a while

Carl: 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. [27:43]

So cool. Good luck to him. Love that. [27:59]

Sam Selikoff just joined to do content and stuff

Carl: 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. [28:01]

Team transitions and gathering context in a new spot. [28:20]

Nuxt acquired

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. [28:23]

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 [28:55]

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

'cause like, you know, if it's individual developers then like. You can't acquire that, you just hire them. [29:16]

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. [29:21]

Carl: Right. I'm now, I'm on the next website. I see next UI Pro, A hub for managing apps. [29:29]

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. [29:36]

I appreciate that. Love someone who's trying to take a project and turn it into a business Relat. Another smaller update. [29:50]

Netlify Staff Eng Philippe Serhal replies to the Vercel Deployment Adapters RFC from April

Carl: 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. [29:58]

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. [30:13]

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. [30:32]

Mark: Okay. Somewhat smaller item, but definitely worth calling out. [30:45]

Ryan Carniato’s “react and signals”

Mark: 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? [30:48]

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. [31:09]

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. [31:36]

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. [31:56]

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. [32:19]

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. [32:42]

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. [33:01]

React Native Unistyles 3.0 Released

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. [33:09]

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. [33:21]

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. [33:45]

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. [34:03]

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. [34:29]

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. [34:48]

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. [35:10]

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. [35:30]

React Router and RSCs: The Path Forward

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. [35:39]

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. [36:10]

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. [36:19]

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. [36:42]

Parcel writeup for Server Components

Mark: 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. [36:57]

WIP Vite RSC plugin support

Mark: 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. [37:26]

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. [37:50]

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. [38:02]

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.

⚡ Lightning round ⚡

Mark: Okay, moving on to the lightning round. [38:32]

Corbin’s “History of React Through Code” deep dive

Mark: 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. [38:35]

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. [38:56]

TkDodo’s thoughts on when useCallback is useless

Mark: 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. [39:06]

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. [39:18]

eslint-config-prettier compromised as part of an NPM supply chain attack

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. [39:26]

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. [39:45]

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. [40:06]

Make sure it's not a vulnerable version. Check your lock files. Yeah, that's not great. [40:29]

Mark: I know one of the other redix maintainers got the phishing email and avoided it. It's definitely semi widespread campaign. [40:34]

Carl: Wild. They must have hit so many people to get a couple of major vulnerabilities in. Cool. [40:41]

Expo Router demo by Evan Bacon AI + RSCs + Expo Router

Mo: So next up, very quick one. [40:48]

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. [40:50]

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. [41:08]

Some tech details on how Meta serves React pages

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. [41:16]

So, you know, a little peek behind the curtain. [41:38]

Nitro Image library for React Native

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. [41:40]

So this is very much welcome as a change to hopefully improve performance across the board for React native. [42:02]

A very hacky way to test RSC components

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. [42:08]

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. [42:20]

A good technical dive into improving INP in a Next app

Mark: 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. [42:31]

Extra CSS Properties in React Native

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. [42:51]

So this will be quite interesting to see when and if it gets merged in. [43:13]

Chrome 137 adds if support in CSS

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. [43:16]

Do one thing or another. Yeah. [43:43]

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. [43:44]

Mo: Reminded me exactly of that. [44:01]

Are we finally at the stage where CSS is turning complete? [44:03]

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. [44:06]

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

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. [44:23]

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. [44:41]

React Devtools for Firefox may not get updated due to review restrictions

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. [44:50]

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. [45:23]

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 [45:47]

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. [46:03]

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. [46:12]

Both oxlint and biome are investigating typed lint rule support (Biome v2, tsgolint)

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. [46:29]

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. [46:49]

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. [47:09]

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. [47:35]

Remix v3 dev branch containing support packages

Mark: 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. [47:49]

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. [48:07]

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. [48:35]

React Native Wallet

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. [48:40]

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. [48:58]

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. [49:19]

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. [49:37]

So curious to see how extensible and generic this is gonna be, but very cool. [49:56]

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. [49:59]

Deno v Oracle update

Carl: This is a very small update, but we've. I talked a bit in the past about Deno versus Oracle. [50:07]

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. [50:13]

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. [50:36]

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. [51:00]

“Content independence day” from Cloudflare (they’re blocking AI crawlers)

Carl: 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. [51:23]

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. [51:45]

Some updated Static Hermes perf numbers release available “soon”, being tested internally at Meta

Mark: All right, and last couple items. [52:04]

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. [52:06]

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. [52:29]

State of HTML Survey is open

Mark: Finally, the folks behind the various state of surveys have put out the state of HTML survey. [52:47]

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. [52:54]

Mo: I did not know them. State of HTML. Very interesting. [53:04]

Carl: Yeah, I think they started like two or three years ago. It's relatively newer. [53:07]

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. [53:10]

Conferences (React, Javascript)

Carl: Alright, before we close out, let's, uh, talk about some coming [53:26]

Big Sky Dev Con Aug 2 Bozeman, MT, USA

Carl: like four days, there's Big Sky devcon in Bozeman, Montana. [53:29]

Kansas City Developer Conference Aug 13-14 Kansas City, KS, USA

Carl: 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. [53:36]

React Universe Conf Sept 2-4, 2025. Wrocław, Poland

Carl: We also have React Universe September 2nd through fourth in Wroclaw [53:47]

Mo: I've been there enough times where I've been taught the pronunciation because butchered it several times, but it's, [53:52]

WaysConf Sept 16-17

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

I'm also probably butchering, but also in Poland. [54:04]

CascadiaJS Sept 18-19 Seattle, WA, USA

Carl: Cascadia js is September 18th, 19th in Seattle, Washington. [54:06]

Squiggle Conf Sept 17-18 Boston, MA, USA

Carl: And we've got Squi Squiggle conf in Boston, September 17th and 18th, which should be great and I should be there, I believe. [54:10]

React Conf is back, Oct 7-8

Carl: And of course, react Conf October 7th and 8th in Las Vegas, Nevada. [54:17]

Remix Jam Oct 10 Toronto, Canada

Carl: 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. [54:22]

Outro

Carl: 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. [54:33]

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. [54:46]

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. [54:53]

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. [55:07]

Thanks so much for listening. Talk to you later. [55:19]