TMiR 2025-05: Dan explains RSC. Remix v3? React core team WIP?

Transcript from Saturday May 31st, 2025

Carl: Hello everyone. Thank you for joining us for the May edition of this month in React, where we recap and digest the ever evolving react and web ecosystem. We are coming to you live from Reactiflux, the place for professional react developers, and we are supported by infinite red uh, consultancy that exclusively works in React Native. [00:00]

I am Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs like this and build other tools to keep the community operating. [00:18]

Mark: Hi, I'm Mark. My day job is with Replay io, where we're building a time traveling debugger and trying to find ways to make AI chat bots smarter with time travel. And also I spend a lot of time working on redux and ranting about the React teams communication. [00:28]

Mo: my name is. I had the mobile team at Theodo and I'm an active member of the React Native community, a core contributor, and I organized the React Native London Meetup and conference. [00:42]

Quick hits

Carl: Quick job market news new releases. [00:54]

Job market: FRED data, Layoffs.fyi, Trueup.io

Carl: Generally it looks like this Fred data source that looks at Indeed, I'm starting to doubt whether it's an accurate reflection of the current market. It's just been continuously trending down which I think may just indicate that people are hiring fewer software engineers on Indeed, since that's the only source of data for it. [00:57]

Drew up dot iOS job trends shows a different direction. It's been a little bit better, but you know, it's not categorically different. [01:11]

Conferences (React, Javascript)

Carl: upcoming conferences. [01:19]

React Summit June 13-17 Amsterdam, NL

Carl: We've got React Summit in about two weeks, so if you are looking for something to do that's gonna be June 13th through 17th in Amsterdam. In Netherlands, [01:20]

Mark: as usual, they're doing one day of an actual in-person conference, and then there's a remote only streaming set of talks. I think like the, the following Monday or something. I'll be speaking there in person. If you've heard me I said I've been doing routine. If you've heard me talking about things like, you know, the community misunderstanding reacts development or the React team having opinions about frameworks and stuff, I will be talking about that sort of thing, live on the main stage. [01:29]

Carl: Very nice. Excellent. Well, I will be at a different conference. [01:54]

Render ATL June 11-13 Atlanta, GA, USA

Carl: There's also gonna be render Atlanta June 11th through 13th. they seem to have really good vibes. It looks like it's pretty well attended in general. So this is my first time attending the event, but yeah, I'll, I'll be there June 11th through 13th. [01:57]

Carl: We are sponsored by Infinite Red. They are an expert react native consultancy that's been around since 2015. So very long running. They do a lot for the ecosystem, including hosting podcasts. The hosting, the largest React native podcast hosting, I believe the largest or organizing, I believe the largest React native specific conference in the us. [02:12]

And they only do React native and have built over 75 apps for companies ranging from startups to the biggest in the world. And they generally will work with a team in order to develop expertise, you know, within that team rather than just being a airdrop in Build the Thing and leave kind of consultancy. [02:34]

So if you are working at a company looking to develop some React native expertise, definitely reach out to them. they're good people. [02:52]

New releases

Carl: Into some new releases. [02:59]

TanStack/db

Carl: a new TanStack sync engine that looks like it ties in pretty well with TanStack Query. I haven't played with this, but it looks pretty interesting. [03:01]

Mark: Looks like Kyle Matthews is working on it. Kyle's probably best known as having created Gatsby, but he's currently working at Electric sql, which, which is a syn engine company, so probably making use of some of his expertise there. I. [03:10]

Carl: Yeah. Very cool. Definitely nice to see that kind of expertise being brought a little more broadly into some other projects. I think local first and like syn engine kind of stuff seems like. A very powerful area of exploration right now. I don't think we really know what it's gonna shake out to. But yeah, I've seen a couple of apps developed in this way over the years and they always, it just strikes me as a really powerful way to do it. [03:23]

I think a great example of Local First is actually Gmail. They've been very local first forever in a mobile app, you know, you can just functionally use it and then you come back online and it actually executes all the things you did. That's just generally how I think most apps should work. So seeing a lot more exploration and how to support that with different types of tools definitely looks really cool. [03:47]

And then coupling that, tying it very closely in with the query engine as it appears that this Tan Stack DB does. Definitely makes a ton of sense. Definitely really interesting there. [04:08]

Mo: It's quite interesting 'cause I was having a chat with a fellow mobile developer just a few days ago, and he was telling me how he uses TanStack Query as like really like the central data store. Of his application on a React native app. But then the challenge is that things working locally is always a real pain and things working offline is a real pain because taking that either means you have to just like store the entire cache inside of like adjacent blob living somewhere on the device disc. [04:19]

It's quite messy and it, doesn't follow those like asset principles that you would want to make sure that the data's intact and there's no sort of conflicts when you do reconnect. This looks pretty cool. I know it's only for react at this point, as far as I can tell, and it doesn't necessarily seem to be targeting React native support, but I think a lot of people in the React native ecosystem would probably love to use something like this so that these things are just synced onto a SQL like DB somewhere on the phone, which is kind of a way to do local first stops in React native. [04:50]

Carl: network is so much more unpredictable on a phone than it is on, on the web. So yeah, that, that makes sense. That's maybe a little underwhelming, but it's not targeting React native support. [05:18]

Legend List 1.0 released

Carl: Mo you want to tell us about Legend List? [05:28]

Mo: Yes. So this is super exciting because legend list, for those of you who've been following along with the podcast for the last few months has been something that we've been talking about on and off, but it's been sort of in that alpha beta phase. So Jay Meistrich, he used to be a game developer, so I say that because. [05:29]

Game development is super, super hard and you optimize for performance as much as you can. So he has that background and worked on a bunch of sort of low level OS stuff for a while. And so he's been a active member of the React native community. Made a library that was the most performant, well by his metrics, one of the most performant state management tools called Legend State. And and so Legend List is sort of, taking that experience and putting it into React native lists, which is one of the most challenging parts of the React native sort of development workflows, making performance lists. [05:45]

And it is by far on all accounts of different people testing it in the ecosystem. The fastest React native list implementation. And it is a hundred percent js. It is very stable. At this stage. I know a lot of actual production apps that have been using it before 1.0. And so I would highly recommend you, you'd give it a try. [06:14]

It's pretty straightforward to replace any existing list that you have, whether that's flat list or flash list. [06:31]

Carl: Very cool. Yeah. List performance while like rapidly scrolling is one of those really visible things in an app, so definitely, definitely really cool to see a great, low level primitive for use there. [06:36]

Redux Toolkit v2.8.0 (and bugfixes after)

Mark: If you've been listening for a while, you've also heard me ranting about the complexities of publishing JavaScript packages and ESM and CommonJS compatibility. We shipped Redux Toolkit 2.8, which was primarily intended to improve our compatibility with the Metro Bundler and React Native. It did that and then it promptly started breaking tests with just environment js dumb due to reasons. we shipped a fix for that and then a process we act, we found out that the release had also ended up messing up some of our bundling so that the different and things weren't getting shaken out properly. And oops, our nested imports were actually like three times as big as they were supposed to be, so we had to fix that. So RTK 2 8 2 is out, and if you're going to upgrade, please use that one. [06:48]

Carl: For sure. Yeah, we've got a bunch of smaller releases or like beta stuff, so I'm just gonna kind of fly through some of these. [07:30]

MUI v7.1

Carl: Material UI has version 7.1 out. It looks like it's mostly bug fixes. We talked about the new like slot pattern that they introduced in 7.0 in the last episode. Interestingly, they also talk about Tailwind V four support, which is a little bit surprising for a component library of this complexity. [07:37]

I don't know exactly what Tailwind support means in this context, but it does appear that you can use a styled engine provider with a, like CSS layer not quite clear on whether this is doing all of the compile time tailwind optimization kind of stuff, or. Right. The implementation details here are not totally clear to me from the release notes but definitely interesting. [07:55]

Yeah. I know that Tailwind V four support has been kind of a sticking point for some projects, so it's interesting to see such a large and complex style library take advantage of. It [08:20]

Jest has a v30 beta.3 + 4 out. First alpha of it was published October 2023

Carl: Jest has a new V 30 beta beta three. I was checking the release notes for it and alpha one of version 30 was first published in October of 2023. [08:30]

So this has been a long time coming. It looks like beta three introduced a lot more new things than the re the other alphas or, you know, many more fixes and whatever. So yeah, I don't know exactly what to think about that, Jest has been generally a kind of finished project in my experience. But yeah, they've got a new version turning its way through. [08:43]

Although with two years, a year and a half since the first Alpha, I'm not sure if this is gonna be released anytime soon. Mark, tell us about Zustand and Jotai. [09:03]

Zustand 5.0.5, Jotai 2.12.4 and .5

Mark: Just a couple minor bug fix releases. Probably not in much meaningful, but you know, always worth looking at updates. [09:11]

devstore deprecated

Mark: Jotai is also switching from whatever previous standalone dev tool support they had to their own built-in dev tools. [09:17]

Carl: Yeah. Deprecating whatever internal tooling they had for that. [09:25]

Radix has new primitives: OneTimePasswordField and PasswordToggleField

Carl: Radix has a new release that has a couple of new primitives if you're using that. It's got a generally password adjacent. There's a one time password field and a password toggle field, so neat. [09:28]

Ant Design 5.25

Carl: Ant design also has a new release with a, a new. [09:38]

Timer statistic component. I've never used ant design. It was interesting to me. Well, I was looking to read more of the, you know, release details on this, but an awful lot of the contribution is in Chinese and I do not read Chinese. I know that's, been a bit of a bifurcation in the React ecosystem is, you know, language barriers are challenging. [09:41]

they got a new thing. It looks cool. [10:00]

React Aria May 19, 2025 release

Carl: React Aria has a new dated release, you know, they don't do versions, they do dates. So this is the May 19th release. It looks like it's pretty much just small bug fixes, although they do also say they have support for the React 19 ref cleanup call that was introduced. [10:02]

So yeah. Neat. Cool. [10:19]

Relay 19 with React 19 support

Mark: relay GraphQL version 19 is out. It's got support for react 19 as well as they've been working on their documentation. [10:21]

Storybook 9

Mark: And then storybook version nine is out, and it looks like they've made a really big effort to try to shrink the bundle size of their own tooling. [10:29]

Carl: Cool. Alright, so that's all the new releases. [10:36]

Main Content

Carl: We got so many small ones this month into our main content. Mo let's start off with expo. [10:38]

Expo SDK 53 release

Mo: Cool. So we have a major release of a new expos DK. So expos, DK 53 is out, and this has been under the, the, the works for a very. Very long time. So Expo usually historically would release a version of an SDK with every React native release that would come out. So, you know, react native dot 72 comes out. [10:45]

And then SDK version 40. I can't remember the corresponding, but you get the point. Every single version is tied to a specific SDK version. But as the React native team has been releasing more frequently the expo team found that it was actually probably a good time to stop tying those things together and sort of bunch some of these SDK releases into larger releases so that they can make. changes to the actual SDKs rather than having to keep up with React native and the versions that are being released every few months. So SDK 53 is a big one primarily because now the new architecture is default everywhere. So if you were paying attention, the last release that they had, the new architecture was default for new projects. [11:05]

What they've now done is they set the new architecture even for existing projects when you update test SDK 53. And this fits with sort of the larger push that the React Native Core team is doing to push people onto the new architecture. And so React native version 79, as an example, has the same thing where, you know, existing apps will also be in the new architecture by default, and you need to opt out. [11:45]

And as of yesterday as well meta announced at app js that they're going to be freezing the old architecture. So they're not really gonna be doing and adding any new features into the new architecture either. So very much going down the deprecation path with eventual sort of removal from React Native Core, which is kind of as we would expect it. [12:06]

Other things to mention. So. Android developers will know about a requirement that came in to the Android ecosystem a few years ago called Edge to Edge support, which meant that your app needs to cover the full sort of corners and notches of an app of an Android phone. And this was sort of opt in for the longest time, but as of the next Android version that's soon to be released, I believe it's Android 16, edge to Edge support will be required. [12:23]

On all apps. So if you submit an app that doesn't have Edge, edge to Edge support, they will reject it. So a bunch of people in the community have been working on getting this up and running because it's not trivial, it's actually quite complicated. So Zoom Tech who's well known in the React native ecosystem's, been working on this. [12:47]

So he's worked with the expo team to get that implemented by default in SDK 53. So once you update to SDK 53, your app will already have Edge to Edge support. This is not the case yet for React Native Core. So if you have a non expo app, that won't necessarily be the case and you're gonna need to add it in manually yourself. [13:02]

The goal is that eventually this will be merged and upstreamed into React Native Core anyway, and will just be handled as a core part of, RNs functionality. [13:19]

Carl: That makes sense. So I'm thinking of like instead of safe area, it's gotta be edge to edge. I. [13:27]

Mo: It's adjacent to that, but not directly related. So safe area views in react native, typically, historically were more of an iOS thing because iOS introduced the notch and then they introduced the dynamic island. So that safe area view was for that more than anything. 'cause Android app devices typically were a little bit more uniform, albeit not the exact same. [13:31]

And then. Android devices followed suit with that. Edge to edge is more sort of how the app interacts underneath the notch or like in the corners of your, of your, of your screen. So, you know, you have a bunch of things in the Android world, like curved screens, and you have screens that, you know, have a a rounding on the corners and so on and so forth. [13:51]

And edge to edge support is to basically make sure that it covers the full sort of portions of that which wasn't there by default. it's, I'm not an Android developer, so it's not necessarily my specialty, but I do know that it is a requirement there, and I think it's certain Android screens can be a little wacky and edge stage support is necessary to make sure that things are behaving correctly on all Android devices. [14:12]

I. A few other things to mention with Expo SDK 53. Background tasks. If anyone's been building rack native apps since the beginning, he'll know that doing background tasks is really, really hard and making sure that they actually execute and you have some level of confidence that things are gonna be run in the background when your app's not sort of front and center in the foreground of, of the user's phone. [14:33]

It's challenging. So Expo actually like went through this. They had a background tasks module. They went through just re-architecting it all because it was fundamentally flawed in the way that it was trying to tackle the problem. So they're actually using they, they've released the expo background task module and it uses sort of the up-to-date latest APIs on both Android and iOS. [14:54]

And so they recommend you use this for different things, like let's say if you need to download data in the background. Or if you need to run over the air updates, so you wanna check, see if there's over the updates, and then actually download it in the background. You can do that, or, you know, garbage cleanup and so on and so forth. [15:12]

If you need to do that in the background of your app. So this is quite useful. It's one of those things that happens behind the scenes, but I think is incredibly important to make an app really perform and, and feel like a native app would. Another sort of minor thing is expo audio. [15:27]

So there's an expo audio update within this release. And expo audio is generally the replacement of Expo av, but the audio portion of that library. So that library was quite complicated And so they've split it off into expo audio and expo video and expo video came first. [15:41]

Whilst they were working on audio, and now audio is, being released at this point, which is quite cool. [15:57]

Package.json imports support

Mo: Last point on SDK 53, that's kind of adjacent to SDK 53, more of a React native thing, but it's part of SDK 53 as well is package json import support, which is great because it's oftentimes quite a big in React native projects with. [16:01]

Babel and TypeScript working together for these package imports. So now React native has this feature built in, so you just define imports within your package js. You update your ts config to just resolve package JS imports and that's it. Which is a really good standardization. So, if you're using the older way of doing sort of aliases for your imports go ahead and change that because I think it'll make your life a lot easier in the long run. [16:15]

Mark: I do kind of object to the use of the word just in that sentence. [16:39]

that's basically what we were trying to, trying to get compatibility for with, our RTK 2.8 release. [16:43]

Carl: I'm glad to see this standardization rolling out. I remembered this coming through in node. I went and looked it up. It was originally released in node 14, which came out April, 2020. So this has been a pretty decent long time coming though, you know? a lot of ducks to get in a row to make it work. [16:48]

But definitely really nice to have alias resolution happen just from package. Jason, instead of needing to, I just, I can just remember all of the various pain I've had with like, trying to keep the aliases between like web pack and Babel and jest and storybook in, you know, all of the different parallel configuration that each needed, its own different way of configuring aliases. [17:05]

So I love that standardization around that is settling out. [17:29]

React Router RSC preview and other RSC topics:

Mark: we've got a bunch of different things happening related to server components this month. Probably the biggest one is that React Router has announced a server components preview. this is probably a big deal for multiple reasons. We've already had at least one other tool parcel put out what it considers like a, a fully production ready release of server component support. [17:32]

So we, we are getting more tools other than just next supporting it. But in terms of usage, react router, you know, even if you're, and you're just looking at the client side functionality has always been one of the biggest packages in the ecosystem. And part of the point of the whole React router, remix, react router back and forth was to try to make more of those pieces available in React router itself so that you could just turn on the framework mode flag and start to get server side rendering bundling type support. [17:55]

And so having RSC support there. Is really going to be, from my perspective, the first widely available usage outside of next. So that feels like a big deal. It's also a big deal because I think most of our understanding of how to use server components has been very heavily shaped by the fact that next was the only real implementation. And so there's sort of been this, well, the way that the next app router works must be the, the way that server components have to work. [18:26]

And instead here we see that the React router team has made some very different implementation choices in how you use server components. So in particular, they've got the ability to actually return server components as individual fields from your loader functions. So you can return some, data. You can return some components, and then your actual component on the client side just receives the loader data and you receive the elements much like you would props dot children, and you just include that in the output. They've also got some more options for server components, routes, and intermixing them support for server functions and then still doing things on the client side. So this looks like a pretty big deal release if you want to try that out, sort of adjacent to that. one of the complexities for server components in general is that they require tight integration with a bundler. And so the React team had specifically most of their initial work was around implementing integration for Webpac because Webpac is so widely used across ecosystem. And they've repeatedly stated that Vite's internal architecture just did not support the proper module graph handling to make real server components support possible. [19:01]

so the, the React team has tried to keep the packages for the Bundler integrations in the React repo so that they can more easily iterate on changes to the core functionality versus what's specific to the bundlers. Like there isn't really like, kinda like a, a publicly defined API for that sort of thing, easier to all have it in one repo. But that's also meant that they didn't have the expertise or knowledge to do the Vite integration properly. [20:24]

Vite community PR to add RSC support

Mark: So there is now a PR from the community to try to add, quote, unquote, proper Vite and RSC integration. And there's been some back and forth on that. Don't know how long it'll take to get that landed, but that does seem like a fairly big step. [20:49]

Carl: Yeah, it definitely does, right? The lack of public API and general documentation for this is definitely, we've talked a little bit about how that's a pretty big barrier for people looking to explore this. You really have to reverse engineer it yourself if you wanna look into it. Seriously. [21:04]

Mark: so at this point, we've got Next has been out for a while. Parcel just released its own quote, production ready, RSC support. We've got React Router coming out with a preview. So it, the, the ecosystem is starting to flesh out. [21:19]

Leerob’s list of other RSC explorations

Mark: Lee Robinson from CEL has been collecting a list of some different frameworks that are experimenting with RSE support in various alpha and, and, you know, test preview approaches. [21:33]

More Dan posts, like Static as a Server and One Roundtrip Per Navigation

Mark: meanwhile Dan Abramov has cranked out several more blog posts trying to. Pitch the mental model of es. A couple folks have said that, you know, he's kind of hitting the same theme from different ways he's basically trained to start from different mental models and work backwards to, "and here's how RSCs address all these different problems." I think he actually put out four different posts this month. Two in particular one talks about how RSCs allow you to do static site generation and don't even require a, like a running application server to do the work. As well as how rses help handle the need to fetch multiple different pieces of data in one round trip. So there's those couple posts plus a couple others. So, as usual, worth reading, [21:44]

RedwoodSDK’s “Your React Framework Feels Broken”

Mark: One other sort of related post. So we previously mentioned that Redwood pivoted from their previous, very GraphQL based framework and they, they deprecated or archived that framework entirely, and they've come out with a new tool called Redwood, SDK which is based on CloudFlare and RSCs. And they, they put out a post called your React Meta Framework Feels Broken, which is both a, a kind of a critique of other frameworks as well as a sales pitch for their particular approach to dealing with server components. So we really are seeing different parts of the ecosystem trying to figure out how to actually make use of server components and ship those as actual features. [22:33]

Remix v3 announcement

Carl: Well, yeah, that leads us sort of into new remix. They have released, or they've announced a version three which is somewhat surprising to me because I had understood it as a deprecated brand that was being merged back into React Router. But actually I, you know, reached out to them to be like, huh. And, you know, reached out in the remix Discord just to express confusion. And I had my attention directed back to the blog post that was released around when they actually did that talk at React Con last year revealing that they would be merging remix back into React router. And they, they were very clear about this from the beginning. [23:20]

I don't really remember it in the talk and I'm not sure that I went back and read the announcement blog post after hearing the talk. So that may have been why I missed this. But yeah, they do talk about how this is, you know, that was their plan. They were going to re remix was a, a Fork of React router, I guess. They did a big thing with V two and merged that back into React router V seven. And in that blog post they talk about how V three is gonna be something totally brand new, but it will be coming, it was in progress. So it's here and remix is not dead despite reports to the contrary. [24:03]

Mark: Or at least it's, it's far enough long that they were actually, ready to announce it. I don't know if any of this is available or visible in any way yet, but at least they're saying we're, we're working on it. [24:35]

Carl: Yeah, true. [24:45]

Mark: So, yeah, this is. it's confusing. I've seen a lot of people pushing back on, you know, like there's already been lots of people complaining over the years about the various React Rider major versions and changes and, you know, Ryan and Michael can't seem to settle on a single API design. I, I will say that the bouncing back and forth is kind of confusing. And then having a version three of an existing package that seems to throw all the existing, previous pieces out the window, is also kind of confusing. You can sort of make the parallel between the angular one or angular JS one versus angular two changeover that happened like a decade ago. [24:46]

The general sales pitch, looking at the announcement blog post and some of the comments by Ryan and Michael on Twitter. So. They're, taking inspiration from, you know, tools like Rails and Express and whatever. You know, , they're sort of trying to apply like best lessons learned from all the other tools out there. [25:29]

They really seem to be, want, seem to, want to go for simplicity and a non bundling approach. Like they seem to want their tool to minimize the number of actual dependencies that it needs to run. And they want to avoid having a bundling step in both development and production. [25:44]

Discussion between Evan You and Michael Jackson about bundling / HMR approach and tradeoffs

Mark: In fact there was a, a conversation between Evan Yu from, you know, from V and View who is saying that, you know, modern apps really need HMR, they need bundling even in development. [26:04]

That's why, you know, that's part of why VIT is redoing its internals. And Michael replied and said. Yeah, we are, we, we want to minimize the number of tools that are involved. We want to minimize the number of transformation steps. We want things to be able to run without needing to do a bunch of compilation. And we're actually not going to ship HMR, we are going to rely on page reloads in Dev, and we think we can make it fast and work. [26:15]

So they clearly have a vision, it's definitely a bit of a zigzag from where the ecosystem has gone over the years. One of the other interesting points is that it's not even going to use React as the UI layer. It's going to use Preact and in fact, apparently it's going to use a fork of Preact so that they can do some additional customizations. I don't have any additional details on what those customizations will be, but that's the direction they're going. I think, check me in this Jason Miller, who originally created Preact also now works at Shopify, right? [26:40]

Carl: That sounds right to me. [27:16]

Mark: So both, you know, Ryan and Michael, you know, like Remix got bought by Shopify a couple years ago and Jason Miller is there. So that, that presumably makes it easier for them to potentially collaborate on some of that work. I. [27:17]

Carl: Yes, his Twitter bio lists him as platform developer experience at Shopify. So, right, like that job title is exactly this kind of work, like making developer tools and frameworks easier to use. So interesting [27:31]

Mark: One of the other bullet points was they, they want to have an emphasis on LLM model based development. Ryan has made some comments recently that he's using LLMs in his day-to-day work, and it's helping to make him more productive. And I think I saw him mention that like the first line of the draft new docs for this version three is "disregard all previous remix versions" as an instruction. [27:46]

So I, I don't know what all they have in mind there other than, being able to organize the docs in such a way that it's LM friendly, but it's something that they have in mind. So no ETA on when any of this will be available. But given how influential React Rider and remix have been, this is certainly something to keep an eye on. [28:13]

Mo: there's sort of two thoughts on the, like the LLM friendliness that stands out to me. The first one is, ironically, I think by naming this remix, they've actually shot themselves a little bit in the foot because it's gonna be a fun challenge trying to teach an LLM how to disregard a version two versus version three documentation or stack overflow question that has been trained on, [28:34]

Carl: That's actually a really good point. [28:55]

Mo: I do wonder if inherently by building on top of web APIs and like staying as close, which, which has kind of been the philosophy with remix, old remix slash react router anyway, by trying to stick to web APIs and standardized sort of W3C primitive, so to speak, that are so well defined in terms of documentation, more so than probably anything else on the web. [28:57]

Plus them adding some good documentation that is LLM friendly in very, very loose air quotes. If that just makes it a little bit more predictable, because I feel like. Having gone through a lot of the W3C docs, it is so well structured and so logical. Obviously it's quite convoluted a lot of times for people who aren't used to it, but it's, it's very like organizationally structured and I wonder if that can help an LLM understand it better than anything else. [29:20]

But that's just a, that's just a personal guess. Could be very wrong. [29:45]

Carl: Yeah. Well, I was gonna say that kind of leads us into our next topic, which is react core work in progress. [29:49]

React Core WIP

Carl: And one thing that they have checked into the repo that I, I don't think has been really discussed or publicized anywhere, is they have a MCP server work in progress. [29:56]

React MCP server

Carl: And so MCP is model context protocol, I believe. It's basically a generally standardized way of authoring tools for LLMs to make use of. I think this react core MCP server is mostly around the compiler. So Lauren has done a lot of work on the compiler and is now doing, it looks like some work on this MCP server. I don't really have a great grasp of what MCP servers are good at, but as far as like tools that LLMs can take advantage of, like sure. Having your IDE be able, your, you know, the LLM and your IDE to query, react, to say, please run this through the compiler and tell, you know, check the performance optimization, see if it's better than it, you know, this other attempt that seems interesting and potentially useful in a, relatively limited capacity, but connecting it back to the remix v3 and LLM friendliness, I could imagine a world where like there's an MCP server that looks up documentation for your specific version that you have installed. [30:08]

I don't know if that's, you know, a direction that they're going to explore, but that def, that sounds plausibly workable to me. I don't know. That's interesting. [31:13]

Mo: specifically like an MCP server. Is is more for the LLM to be able to externally call tools rather than just generating text. So it gives it like a way to interact with the outside world. And I guess going through the code of this specific MCP server they've defined a few different tools to compile with the React compiler. [31:21]

If you give it a set of code basically but also then run performance tests. And sort of go through this process of assessing what, the LCP is, I-N-P-C-L-S, and also the core web vitals. And so looking through the actual source code, it seems to me what they kind of want you to be able to do is to use the, use this MCP server to basically compile some of your code, open up a browser and run core web vital scores. [31:43]

Run the react compiler, see if it improves it, and then sort of do that in a loop, almost in an age agentic fashion, so that you can optimize a react component until it's kind of at a state where things are performance, as performance as they get. So it's almost like write your react component. It's fine if it's crap, and then leave it to the model to go in and optimize. [32:09]

Measure, optimize, measure, optimize until it's at a state where, things are working as expected and is as performing as it gets. [32:29]

Carl: Yeah. There's also some mark, I think this is more of a you question, but they've got a skeleton PR for a concurrent store. I. [32:35]

Mark: Yeah. So this is a topic that's been discussed for a while. So one of the big limitations that limitations thus far around suspense and concurrent rendering and transitions has been that React needs to own the state in order to be able to postpone or interrupt or reschedule work in progress state updates, which means that for external libraries, Redux, Zustand, Jotai, you know, X State, you know, take your pick here. We've had to rely on the use Sync external store hook as our integration with React so that when the external store updates, react gets notified and it can trigger or re-render. [32:42]

But the limitation is that used syn external store can quote unquote det, which the React team has never done a great job of defining that term. But as best as I understand it, what it means is that if React was in the middle of a concurrent render and something happens with the external store, like say a Redux action gets dispatched while React was paused, rendering halfway down the tree, it ends up having to throw away the entire work in progress render and do a full synchronous render start to finish in order to ensure that the whole tree has access to the right data. And, you know, from their point of view, that's, that's a bad thing, which is understandable. [33:24]

“Concurrent store” skeleton PR a concurrent-compatible integration for external libraries

Mark: So. They've put up a PR for what they're calling a concurrent store, and this appears to be a react built-in object that you can create and then you can pass it to the use hook to extract the value. And somehow the internals of this will be concurrent compatible. And it looks like that will allow external libraries to interact with that instead of use syn external store and potentially allow them to be concurrent transition compatible in a way that use syn external store is not. Now, thus far, what we have is a draft PR that just adds the skeleton of this to the code base feature flags and some tests, no implementation details, nothing we can run or try out. But based on some of the stated comments on social media and this draft PR and then the last React lapse blog post, it looks like that's the idea of what this could do. So at some point we may have to put out React Redux version 10, which which is over to this, it's good to see that they're iterating on this, on this concept. [34:08]

Carl: well you, you certainly would know a lot better the context behind that than I would having maintained redux for so long. But it seemed like the, you know, use concurrent or, you know, concurrent store or whatever the various things they've tried, it seems like none of them have quite solved the problem they were hoping it would. So. [35:17]

Mark: External store avoids the tearing problem. But at the cost of, if you happen to have that sequence of events occur, then you, it has to, you know, take the time to do a full render, which could be costly 'cause it can't interrupt itself. [35:32]

Carl: Trade offs not ideal. [35:48]

<SuspenseList> being worked on again

Mark: Along with that, Sebastian has done some more work on view transitions and they're working on resurrecting the suspense list component idea, which had been prototyped quite a while ago. And they're found Trying to bring it back. This is apparently meant to try to allow you to define intended order for multiple different, like adjacent or nested suspense components to reveal themselves. Say maybe like you have a, I guess like a list of items or something. Admittedly as usual, it's outside the scope of what I've actually ever tried to use, but it's a thing that had been sitting around for a while and it was unclear when they would get back to trying to work on it. [35:49]

Compiler integrations with SWC and OXC

Mark: And, and then finally the React compiler is currently implemented as a Babel plugin. And given how the ecosystem has been shifting away from Babel, that was a bit of a pain point. The core of it does not rely on Babel. Like Babel was just sort of used as the way to get it into your build tool. And so they've been working on, in, they have a semi working integration with the SDC compiler, which is what next and other tools use. And they're also talking with the folks from OXC, which is what the New V implementation will use about the best ways to try to integrate. So still early days there, but it's good to see that we are, they're trying to find better ways to integrate with both, you know, with the latest generations of build tooling so that we hopefully don't have to have Babel in our build tool chains. [36:29]

After all. [37:19]

Apple App Store Epic Games Saga 30% Apple cut ruled unlawful in the US

Mo: Next up a little bit of a segue. Not specifically React news, but I think reasonable enough to call out here because it does affect React native apps. So if you've been following the news, apple and Epic games have been locked in a feud for the last. Several, several years. Apple basically taxes any company on in-app purchases for digital goods of 30%, which is quite a significant revenue hit for any app developers that are out there. [37:19]

There's some provisions for startups and so on and so forth to bring that down to a lower number. But once you hit a certain amount of revenue, I think it's around 1 million or 1.5 million a year on the app store, you have to pay 30%. And so. Epic games and Apple have been going to court over this for a very, very long time. [37:48]

And Fortnite was off of the app store for a while several years ago now. So it's been going back and forth. If you use Netflix on your phone as an example, you'll notice that you can't actually purchase or change your subscriptions on the app. You need to go onto a website. And there's no sort of link from the app whatsoever to manage anything related to your subscriptions. [38:05]

And that's kind of by design because they don't really wanna pay the 30% to Apple. So, in a sort of shocking turn of events a court came in and basically said that apple's 30% tax is actually unlawful in the us. Which is kind of a. nobody kind of expected this to come out especially because the EU didn't even go this far. [38:23]

And so, the EU basically went in and said, Hey, you should be able to have a, you know, alternative app store rather than just the Apple app store available, but didn't say that, you know, 30% tax should be removed and it's unlawful. in the first sort of events that happened in May. Epic Games won and basically they, courts ruled that Apple should reduce the 30% tax or remove the 30% tax. [38:44]

And how they do that is basically you can use in-app purchases. Basically use another external payment platform for it so you can use Stripe or whatever else you want to take payments for digital goods inside of your app. The next day, apple basically blocked Fortnite from the app store in a sort of weird turn of events saying, no, we don't, we don't accept this. [39:08]

Only to then get overruled with a judge asking Apple to approve the app store submission for Fortnite. So now if you're in the US you might see some apps. Having a big warning on the app store from Apple saying, Hey, this app is unsafe in terms of transactions and you're not gonna be protected by the App store, so proceed at your own risk, which is quite funny. [39:29]

So still doing anything that they can to stop people from doing this. But for React native developers, that basically means that you can now use Stripe only for the US market. So if this. If this is functionality that you have for any locale outside of the us, your app will still be rejected because this is on a US only ruling. [39:50]

But you can use Stripe or any other payment provider for digital goods inside of your app, circumventing in-app purchases, and still have your app approved in the us which is a big, big deal for a lot of people in this ecosystem. And folks like Charlie Cheever have been speaking about this being a big day for, for mobile developers. [40:08]

A bit of an aside, but it's relevant to react native developers to be in the loop about what's happening in the ecosystem. [40:27]

Carl: that's like half of a seismic shift for native apps. the fact that it's only in the US locale is, you know, definitely dampens that quite a bit, but [40:32]

for such a large market to now be required to accept. Different payment methods that don't have a 30%, you know, cut removed that is still quite large. [40:43]

Still quite significant. [40:53]

Mo: Hopefully this kind of reverberates to other markets as well and I can kind of see that happening. [40:54]

Carl: All right. [40:59]

Next reducing Vercel mentions in docs

Carl: Our last main, you know, topic here, kind of small, but sort of speaks to the general undercurrent, the vibes that people have felt around next and react. next has reduced how many mentions Vercel gets in the next documentation. Lee Rob in the PR for this says some of the mentions were egregious and unneeded. [40:59]

Others were documenting specific behavior for how next runs on Vercel, which is better suited for Vercel documentation. That seems good. I would certainly agree that some of the mentions were egregious. Some of the behavior being documented was better suited to the platform documentation rather than the project. [41:20]

The next project documentation, you know, it's just such a persistent topic of discussion that like next verse and react are all just like so tightly coordinating and whatever. This is definitely a small but positive change on that. I appreciate seeing it. I. [41:37]

Mark: I think we even also put up a similar PR to tweak the phrasing that where next is listed in the React op docs set up an installation page. I think it used to have a phrase like, next or next is hosted by Vercel, or developed by Vercel or something. And they specifically tweaked that to remove some of that reference. And like it all, like, it also kind of goes along with, Vercel being intentional about reaching out to like the Open Next folks and trying to more standardize how next actually can be hosted. think people's complaints have been valid. Like this has been both a pain point technically as well as it has it, it's looked bad, but I think we ought to give credit to them for saying, okay, yeah, we, we agree, we kinda screwed up here and we're going to try to improve the documentation and the actual usage to make it more generic. [41:53]

Mo: Looking at this a slightly different lens as well. I mean, props of them for this goes without saying, but I think Vercel is also starting to reach this realization that they can't just rely on being a next hosting platform to monetize. Because, you know, you see in the last you. Few months how their business model has kind of shifted into three spaces, which is, you know, hosting for next and, and other things. [42:49]

But also observability has become a lot more of a mention on their sort of product listing pages. And more recently, I think they're really going hard on the AI space. So a few days ago, I think they announced that you can use Vercel. Sort of ISDK as a proxy to call 40 plus different LLMs without needing to set up different billing with each of these different platforms. [43:10]

So I get a sense they're trying to go for a larger cloud play, which means that they're probably less reliant on next Js being sort of their guarded secret. And, you know, their tool that only runs on Vercel. And they can open it up a little bit more without worrying about it being sort of their only lever for business. [43:32]

Carl: Yeah, that's interesting. I hadn't thought about how they were, they were super early on the ai SDK, they definitely have first mover advantage there, I'd say, and that is, that does position them well for like, if they are a point of entry for LLM based APIs, then that I could imagine a world where they then try and be like host their own models. [43:49]

And then you are paying them for that hosting as well, which is adjacent to hosting your, your web app, but not quite the same maybe. Yeah. That's interesting. Yeah, they definitely own a pretty significant front door there and so where that door goes could certainly lead to stronger monetization for them in the future. [44:12]

I also want to, you know, since in the last couple of episodes we've, one of the topics of discussion has been Vercel, and its. Collaboration or lack thereof with other adjacent hosting providers. noticed at the bottom of this PR it says Netlify has confirmed they're okay with a specific feature matrix link included, and I did my best to include the CloudFlare and Amplify versions based on their documentation, which I'm going to read into and say they do not have open lines of communication with CloudFlare and AWS which is maybe not ideal. I feel like they should have, you know, the, the head of dx, head of, I don't know. [44:30]

I don't know exactly what Lee Robb's title is, but he is highly active, engaging with many individuals throughout the ecosystem. And for him to reveal that they do not have, you know, maybe not a red phone, but like any means of getting in touch with people within CloudFlare or AWS somewhat surprising. [45:06]

I don't know. [45:24]

Mo: CloudFlare, yes, I agree with you. Amplify. Oh boy. I've, used Amplify on and off to host various applications. I'm instinctually going to say that that might be more on the Amplify team, just by virtue of how they deal with their own users, let alone with other community leaders. But that's just a guess. [45:24]

CloudFlare is probably a different, [45:45]

Carl: I have very briefly used Amplify and that is approximately my read of things too. Fair enough. [45:47]

⚡ Lightning round ⚡

Carl: Alright Should we go to the lightning round? [45:52]

Shared Element Transitions in Reanimated

Mo: I'll kick it off with shared element Transitions, a very, very exciting prospect that we've been waiting on in the React native ecosystem So there's a draft PR going into React native reanimated for shared element transitions on the new architecture. I. Shared element transitions very quickly is basically what happens when you navigate from a screen to another screen in the React native or in a mobile app, and some element is taken, expanded, or animated onto the next screen. [45:54]

So, you know, Instagram, you click on a post, it navigates you to that post, but it opens it up so you see a transition of that post expanding or something like that. There's been a lot of sort of POCs of this in the React native ecosystem, but nothing standardized that people can use easily and consistently in their apps. [46:22]

So, Bart from Software Mansion has been working on this for a while and we've seen some really good promise of, of things actually working out for it to be available. So keep an eye out, keep an eye out on that. But it's still early stages, but I think that the new architecture can enable stuff like that, which is really, really exciting. [46:38]

V8 explicit compiler hints

Carl: This is extremely niche. But V8 now has, or is providing a new way of ge improving startup time by using comments to hint to the compiler what will be used and what should be compiled. So this is like very deep in the weeds of the runtime engine and like how it gets compiled and when it will compile things. [46:56]

So this is certainly not something that I think most of us will need to use, if optimizing startup time is something that you care about, V eight is now giving you some new things, some new ways to play with that. I don't super duper understand all the, you know, twists and turns of this, but the gist of this blog post is saying that you can add a comment you know, slash slash. [47:18]

Hash bang or no, not a hash bang, just a hash slash slash ash. All functions called on load. And that will signal to V eight that it should compile it differently than it would otherwise, which will improve startup time so that it, you know, because it doesn't have to guess so much at what is being compiled. [47:40]

I always appreciate seeing some of these runtime optimizations. It's just like a little window into the black box. [47:58]

TS Native Previews (usable build of the Go-based compiler)

Mark: All right. we're always talking about tools that are, and putting out, you know, faster releases, rewrites and native languages. And this month we've got a couple of previews. We've previously a announced that TypeScript is being rewritten in Go, and the TypeScript team has put out preview builds of the go based tooling. So you can try those out and see how fast it is. [48:05]

Vite + Rolldown preview build

Mark: Similarly, Vite just announced like right before we, we, we started recording this, that they've got a preview build of their roll down based. Bundle. So the idea right now, v uses a mixture of es build in development modes and roll up, which is a, which is written in JavaScript for their production builds. And so roll down is a rust based reimplementation of roll up, but they're going to use it for both dev and prod. And they're also going to look at, start doing bundling in dev rather than just shipping standalone ES modules to the browser. So it's preview, you can try it out. They've got some stats saying builds have gotten a lot faster as a result. [48:26]

Seeded pseudo-random number proposal advances to Stage 2

Carl: Another deep in the weeds. update, but this is pretty early too, TC 39. But a seated pseudorandom number generator proposal has advanced to stage two. You know, math, that random is useful for many things, but cryptographically secure random generation is not really one of them. [49:10]

Although actually this is sort of adjacent to that. This is one of the problems of math thought random is it doesn't let you provide a seed for the randomness, which has various drawbacks where sometimes you, you know, you want something that appears random, but is actually deterministic so that you can, you know. [49:29]

Have other parallel computation that will produce the same output regardless of what the random is. some specific example tying in a CSS feature that I am not familiar enough with to speak at length to. But yeah, just like generally this is a huge expansion in the functionality, the randomness support in the web, in JavaScript. [49:46]

I, I think it said it's like 17 new various random functions. So that's, that seems very nice. [50:10]

Mark: a couple times where I needed to do some seated ran number generation, even if it was just for something like a, a, a tutorial example app and had had to rely on various third party libraries for that. So, I mean, definitely a useful thing to add to the platform. [50:17]

Okay. And wrapping things up, a couple, couple bits around data fetching. [50:29]

3-layer data data fetching for complex React apps (RSCs, React Query, optimistic UI)

Mark: I saw one article that gave and gave some suggestions around a way to manage your data fetching at a a three tiered approach where you can use server components on the server to do some initial fetching. Pass some of that as props into components and use it to seed react query on the client and then set up React Query to do some optimistic UI updates for faster behavior. Not necessarily new and groundbreaking, but it was nice to see a reasonably detailed article that suggested some ways to tie all three pieces of those together. [50:34]

Johannes Schickling announces LiveStore (reactive SQLite + sync layer)

Mark: And finally Johannes Schickling, who I believe originally co-founded Prisma has been doing some work over the last few years around a local first sync engine called Live Store. He gave me a demo in person when I was, in a conference a couple years ago. And then he gave me and David corse a preview of his talk for local First conf a couple weeks ago. And this is really interesting. So he is running SQ Lite in the browser. He's got a reactive layer around SQ Lite. [51:05]

So you would have like a, a, a data-fetching-like hook that you'd use in your components, except it's talking to sq l under the hood. But then the sq LI instance itself is being based on. A series of descriptive events. One might almost call them actions that describe a thing that happened that ultimately define how the data ends up in SQL eight in the first place. And so he actually very intentionally drew parallels to the, the redux mindset and architecture in his talk. So he, he just put that, I put that out and announced it at local first conf. it genuinely looks very interesting. Like, would all apps need it? No, but it looks like it would be extremely useful for things like a, like a local first setup needing to work offline. [51:35]

Carl: I know Johannes Schickling is also very involved in effect, which is a interesting, like massive, huge API scope, like functional programming library. So like, man, he's doing a lot of stuff. He is really shooting his shot in a lot of different directions. Very cool. I somehow feel like he was involved in organizing the local first con. [52:24]

Trying to confirm that. Yes. Okay, cool. He is in fact one of the organizers of Local First Comp, so that, that [52:47]

Mark: Oh, that's cheating. Accepting your own talk. [52:52]

Carl: Right. [52:55]

it feels like he's very all in on building the future of local first. So Very cool. [52:55]

Outro

Carl: Alright, that's all we got for you this month. Thank you so much for joining us. We will be back on. I'd say we'll be back on the last Wednesday of the month, but I think we haven't hit that for a minute, [53:02]

Mark: I can already say that I, I'm still traveling. In fact, I will probably, I'm pretty sure I will be at a conference on the last Wednesday of next month. So we, we may need to bump it back a few days. [53:12]

Carl: recording time, TBD usually the last week of the month. and we will be back in your podcast feed just as soon as we can after that. I hopefully will get it up on Monday. We gather sources from this week in React bites.dev react status next JS weekly, the React JS subreddit and herein Reactiflux from the Tech news and reads channel. [53:22]

And also sometimes directly from people publishing, but that's a, that's an noisier signal. If this is a show that you get value from and would like to support, best way to do so is by submitting a review on whatever platform you listen to and by telling your friends and coworkers about it. Thanks so much for listening. See you next month. [53:41]

Mark: Take care. [53:56]