TMiR 2025-08: Nx compromised; no more throwing promises; Remix-ing new component models

Transcript from Thursday August 28th, 2025

Carl: Hello everyone. Thank you for joining us for the August edition of this Month in React. As we recap what's going on with React, react native in the web we're coming to you live from Reactive Flux, the place for professional developers using React. I'm Carl. [00:00:00]

I'm a staff product developer and freelance community leader here at Reactive Flux, where I do community programs like this event and write some code to help keep the community running. [00:00:13]

Mark: Hi, I'm Mark. I maintain Redux. I try to find time to maintain Redux. Life is busy these days and my day job is working at Replay where we've built a time traveling debugger for JavaScript and are also attempting to get in on the AI app generating craze. [00:00:22]

Carl: Mo is unfortunately out this month, he seems to have food poisoning or something similar. So he's gonna take a break and I'm gonna do my best on React Native news, which is only Okay. [00:00:37]

New releases

Carl: But yeah, let's start off with some new releases. Mark, tell us about new TypeScript. [00:00:47]

TS 5.9

Mark: The TypeScript release train keeps on rolling. They've just put out TypeScript 5.9. Few points of interest out of this one. They've updated some of the options for generating any new TypeScript project. They've simplified the initial TS config, JSON that gets generated. They also have support for the upcoming JavaScript import, defer syntax. This is a new thing. That is coming down the pipeline for JavaScript engines where you can use the defer keyword in an import statement and the JavaScript runtime will know that it needs to go read this file, but it won't try to actually load and execute that JavaScript right away. [00:00:51]

Right now, when you do imports, everything's imported and executed synchronously. This can have a lot of effect on startup time, and so the import, defer keyword is meant to la effectively lazy load some pieces of the JS system without having to use the the separate import statement. So TypeScript now at least has support for that syntax, but in a sense it won't do anything until JavaScript engines fully support actually doing something with that. One thing that I personally am excited for is that TS 5.9 now has support for expandable hover previews. If you, if you ever work with TypeScript, you have big type definitions, you know that TypeScript often cuts down the amount of information it shows about a type in the hover preview or, you know, the types are deeply nested and you, you don't already know like what is inside this field. So ts 5.9 now has support for actually being able to drill down into hover previews. you do need to have an updated version of VS code to make use of that as well. But as someone who has spent too much time fiddling with those settings, I'm actually very excited about that one. [00:01:37]

Carl: Yeah, that sounds great. [00:02:48]

TS 6.0 may enable \`strict\` by default and change other defaults

Mark: And then along with that, there are a couple bits about the future of TypeScript. So right now we're on 5.9. The TypeScript team has said that the go port of the TypeScript compiler will become a TypeScript 7.0. They've put out some news and plans on the roadmap for TypeScript 6.0. There's an issue in some discussion about making the strict flag the default, or maybe not the entire strict flag, but maybe graduating some of the specific settings, like strict null checks to be turned on by default. As a maintainer, that makes me very, very happy. I'm tired of seeing people post issues against my library saying, your library doesn't work. Right. And the problem is they didn't have TypeScript in strict mode in the first place. So. still to be worked out, but it's good to see that they are trying to figure out the transition plan for all this. [00:02:50]

Carl: Definitely super cool. [00:03:44]

React Native 0.81

Carl: We've also got React native releasing version uh, O 81. Obviously I am not anywhere near as deeply versed in React native as Mo would be. So, uh, hopefully we'll have him around to catch us up again later on. But we've talked a little bit about what's coming on, what's in this release in previous months. [00:03:46]

Nothing here struck me as super new. They're deprecating, the safe area view which they talked about as being originally an iOS specific. Component in order to support, you know, the safe area because of the notch. But now Android has notches too, and it doesn't work very well for that. So it's being deprecated and they're leaning on the, Safe Area Context. They recommend that you migrate to the React native safe Area context library for that. They are also defaulting to Android 16 now in React Native. They had an, a curious call out that seems strange to me. They say predictive back gesture is now enabled by default for apps targeting Android 16 and just , the phrase predictive back gesture. [00:04:07]

Is, I don't know, it seems like a lot to me. I know gestures, you have to predict them and whatever, and I guess everything is now gestures, but I have my phone sent to use buttons still, so I don't know what they're talking about, but that sounds complicated. It also talks like, you know, if you have overridden your, the back behavior of your app, then you may need to migrate or change how your app works. [00:04:50]

So man, if only you could reliably go back in Native apps isn't the web great. They also are introducing pre-compiled iOS builds, which they say cuts the compile time by up to You know, 10 x so like one 10th the compiled time. It used to be in projects where react native is a primary dependency. [00:05:11]

And they've got better error rendering in the dev tools as well, which is great. it now shows the original message in Stack trace of uncut JavaScript errors. So how, how lovely to know where your errors come from, [00:05:29]

Next 15.5

Mark: Next 15.5 came out. A couple things worth noting from this one. They now have turbo pack builds for production in beta. Turbo Pack had previously really only been used for local development, and so they've been cranking away on trying to get it to full compatibility for production builds. And it seems like that's getting close. They now have node support for middleware. They've got some TypeScript improvements, like actually having full typing for routes. So it'll catch things like mistyped link tags as well as trying to get rid of the old next lint command. [00:05:40]

Carl: Yeah, the middleware support for no JS also seems like a pretty big step. You know, one of the main complaints, a large complaint about next is how difficult it is to run yourself not on Vercel. So supporting a more generic runtime for your middleware seems really great. [00:06:16]

I haven't run into this with next specifically, but I have run into. Compatibility issues between edge runtimes and node JS code. it's such a constraint if you're trying to run on, edge runtime, which is, you know, okay, so next Vercel is they have their Edge Runtime, in title case. [00:06:33]

But also, you know, CloudFlare workers are also a very similar kind of runtime that offer a similar set of constraints. And man, you just can't use a lot of the node ecosystem when you're in one of those constrained environments. So this, this should open up compatibility quite a lot it sounds like to me. [00:06:51]

Preact 11 beta

Mark: Meanwhile, the Preact library, the, the longstanding smaller replacement for React just put out a beta for version 11. Preact has always been dom slash web only, not native. And the calling cards have been that it's much smaller than full-blown react, but maintains most API compatibility up to a certain point. [00:07:10]

I think they've stopped trying to, maintain compatibility for some of the newer React APIs in 18 and 19. [00:07:33]

Hydration 2.0

Mark: A couple of the big points this one they finally dropped IE 11 support and they've improved hydration and a number of other small tweaks. So it's always good to see that them making progress as well. [00:07:39]

Bun 1.2.21

Carl: Every so often it's nice to check in on what BUN and Dino and everything are doing. BUN has a 1.2 point 21 release out. A couple things that caught my eye on it were the bun sql, you know, standard library tool now supports MySQL, MariaDB, SQL Light, and Postgres, all from like one dependency. [00:07:52]

And that's pretty great. I don't know. Nice to have, nice to be able to swap those out. I wonder what the experience of actually trying to swap them out would be, because the different engines have slightly different constraints. I appreciate that. That's cool. I, I love, especially for like SQL light stuff, it just seems so simple as maybe overstating it, but it's really nice to be able to just spin up a database without installing dependencies. [00:08:12]

So, uh, kudos to BUN for adding that. They've also added native YAML support which is great. You know, it's lovely to not for parsing confi common configuration file formats again, seems like something that should be in the standard library. However, I am generally aware of YAML as like a very challenging format to parse. [00:08:35]

Native YAML support. Definitely not going to cause any problems

Carl: There's a, a blog post that lives in my brain about YAML from 2023 titled The YAML document from Hell Enumerates some of the complexities one of my favorites being sex decimal numbers. And so a, a, apparently a common older format quirk is that some, ranges of ports that you might try to map in, say a Docker file like Port 22, mapped to port 22 is not parsed as 22, colon 22. [00:08:54]

It's parsed as a sexagesimal, IE base 60, number. So then instead of the string 22:22, you get 1,342. Which is not a valid port mapping. So like things like there are like 30 different ways to put Booleans to encode Boolean in a YAML file. And so like yes and no are one of the valid formats. And so if you're trying to do a list of countries using standard country codes, apparently Norway will be interpreted. [00:09:24]

Mark: Is NO, [00:09:53]

Carl: So like, just hearing about that, those kind of like foot guns that exist in the format and apparently like variations in parser behavior is an existing problem throughout the YAML ecosystem. So, great. I [00:09:56]

Mark: let's add another parser. [00:10:09]

Carl: Right what? Great. One more parser there. Wonderful. I can't wait to hear about what weird, terrible, hellish bugs emerge from this new parser. [00:10:09]

Good luck to them. I hope it's good. [00:10:19]

Tanstack DB beta

Mark: Next up the folks over in the Tan Stack Collective have just put out a beta of the new Tan Stack database library. it's a little interesting to describe. It's a layer that's supposed to sit on top of your tan stack query setup, and it kind of acts as like a local in client database and sync engine. [00:10:21]

So you can still use 10 set query to do the fetching, but the database layer is supposed to provide a normalized view of the data, supposed to have very fast in client updates. I believe this has been worked on by Kyle Matthews, who you may know as the original creator of the Gatsby framework back in the day. He's been working on electric sql, which is itself a AYC engine layer, so he clearly now has some expertise over there. So, looks like a very potentially interesting tool for fast client side data management. [00:10:41]

Carl: it seems like hand stack throwing their hat in the ring on like sync engines at a slightly different level of abstraction than like where React query sits. Further to the backend, further to here's your internal store being managed, not just request caching. [00:11:12]

So that's cool. Yeah. Interesting. [00:11:28]

Ghost v6

Carl: A very small shout out, a little bit further away, but this is a tool that I evaluated for use in a professional setting on a React project. So I'm gonna shout out a new major version. Ghost version 6.0 has been released. Ghost is a, like CMS, an open I believe open source CMS. [00:11:30]

And they generally seem nice. They seem great. I, you know, as contrasting things like Contentful or Ghost or Substack or Medium or what have [00:11:47]

you, uh, Word, right? They sit in a good spot in the niche. They, so they're now, they're announcing as part of this version six that they have added distribution. [00:11:57]

So now you can automatically publish your posts from Ghost across social platforms. So like they, they call out Blue Sky Flipboard Threads, MAs it on WordPress, interestingly and Ghost, they can, so, okay, so you can publish the ghost and it will be distributed elsewhere on, in Ghost, I don't know, I don't know what that means. [00:12:09]

Or any other social web platform as well as like analytics. And they talk a lot about how much revenue they have passed along to publishers on their platform. So they show their earnings broken down into like. Hosting revenue and platform revenue, and it's like $38 million for their own company and like a hundred million dollars through, you know, distributed to people publishing on ghosts. [00:12:28]

So like that, I don't know. That's great. They, they shout out 4 0 4 Media, which is a site that I'm familiar with and did not realize hosted on this platform. So, you know, love that. That's great. I love a, love a open source media platform that's doing good work right now. [00:12:56]

Main Content

Carl: Cool. Uh, That's all the new releases we have for now, into the main content. [00:13:09]

React API changes / updates

Mark: All right, so we have a roundup of a number of topics related to changes in reacts APIs. So get your technical hats on for these. [00:13:13]

React deprecating the “throw a promise” Suspense trigger method

Mark: The first one is that Sebastian MarkbĂĄge put up a PR to officially deprecate the throw a promise technique for triggering suspense. So let's wind backwards and unpack a little bit, like what is that in the first place and why does it even exist? So. Currently up through React 17 and 18. The suspense component came out in I think like 16.6, but originally it was only used with React lazy for importing and deferring loading of components. There wasn't an official like react for data fetching method, but there was the unofficial experimental. [00:13:24]

This is never documented, but the code exists and works. If you wanted to trigger suspense in terms of like, you know, managing some data fetching yourself, the super secret technique was that you would throw a promise from within your component. And the reason the React team picked this was because we. It like, to a certain extent, it enabled them to reuse the existing infrastructure from catching errors within a component where, you know, it kind of conceptually, you have a catch block around the actual component call and then react knows, here's where I'm rendering in the tree, and then it can sort of bubble up the behavior to some ancestor component that was supposed to catch it for errors. [00:14:07]

It's a, you know, actual error handling with the component did catch. And for suspense it's, you know, where's the nearest suspense component in the tree? And so this was never officially documented, but, you know, library maintainers and people investigating the code saw that it was there. And so it's been known and used by the community and libraries for years. [00:14:57]

And so pretty much anything, any library that had suspense support built in was internally just throwing a promise. So with React 19, we now have the use hook built in, and that is the officially documented publicly, you know, described way to actually trigger suspense. If you look at the use hook, I think internally it does actually still end up throwing a promise last time I checked, but it's now an implementation detail. And it does some other things in there as well. So if you read a pr, they are officially going to get rid of the throwing a suspense, throwing a promise technique for a number of reasons. Some of it has to do with internal implementation details and optimizations. Some of it has to do with, well, we can have the lit rules look for uses of the use hook and flag any, any time you try to put that in a place that it's not legal to do so. [00:15:19]

Discussion between Dan, Dominik, and Ricky about how to support multiple React versions (if at all)

Mark: This did then lead to some discussion on Blue Sky amongst a couple of the maintainers like Dominic Dorf, Meister of React Query asking, well, if this comes out in like, you know, 19 3, 19 4, something like that, how are we supposed to manage having our own libraries work with both like React 18 and 19.1 and 19.4 at the same time when there's now three different variations of what is a legal way to trigger suspense. there was a bit of a back and forth on that. One partial answer was, your library can check if the use hook is exported from React and prefer that if it exists and fall back the promise if it doesn't. One of the React team members, Ricky said, well, you probably should just focus on supporting the latest version of React. I'll admit, I feel like that kind of hand waves the problem a little bit. [00:16:20]

Carl: How great if everyone could just rely on that. Yeah. [00:17:17]

Mark: yeah, because I mean that, that probably also means putting out new major versions of our own libraries, which is then an effort and also has a ripple effect on the ecosystem. I mean, I don't really want to publish a new version, a new major version of, you know, some of the Redux libraries just to support that. But it's good to see that there, that we are actually making headway on that now that 19 is out. [00:17:20]

Github discussion with Joe about why no context selectors API or signals, research into data modeling, and why “concurrent stores” are the current focus area

Mark: Another interesting point. So buried in a blue sky thread Joseph from the React team said that. They're planning to not actually implement an idea that they had discussed a few months ago where they'd said, we are going. [00:17:43]

They were thinking about allowing you to call use or use context inside of use memo as a way to optimize context. So backing up technical detail on this one, the weakness of context has always been that when you update the context value, every component that reads it will re-render. And then at that point, all the children inside of that will re-render as well, just because react defaults to when any component renders. [00:18:01]

It just keeps on going all the way down the tree unless you optimize it to stop. And so the problem is if you have, you know, fairly large objects with multiple fields as your context value, some of your components probably only care about one or two of those fields. But as soon as you update that object at all, every component that read the context will re-render. And so it ends up leading to, you know, potentially lots of components rendering slower render performance, et cetera. So years ago, like, I don't know, 20 18, 20 19 there was a user land RFC suggestion that react should add context selectors as an API. So, you know, kind of similar to like a, a react redux use selector, but optimize for context instead. [00:18:28]

And so that proposal has been around for a long time. Andrew Clark even briefly tried implementing a proof of concept of a context selector's API in like 2020, and then it didn't go anywhere. So a few months ago, the React team said we're, we're thinking about a. Use context in use memo as a alternative to actually writing a selector for context. And apparently their thinking has evolved and they're not going to do that at this point because the React compiler basically gives you 95% of the performance benefits that a context selector's API would have without them needing to design and ship a context selector's API, into React itself. If you think about it, the point of the compiler is that it not only optimizes like your used memos and whatever, it also optimizes the render output. And so if you have a component that reads from a context, it will, it will render because the context value changed. But if none of the data that it needs from the context has updated, it will end up skipping all of its children. And so that drastically cuts down on how many components would render when the context updates. So there was actually some very, very good discussion in the longstanding context, selectors RFC thread, just within the last two or three days where a few people were agitating for react should really add contact selectors. It'll get rid of all these other state management libraries. [00:19:18]

And I left a couple comments trying to explain how the compiler solves this problem and Joe Savona from the React team then went on and wrote some very extensive, detailed comments talking about how the React team has been doing research into these ideas of data flow analysis. And how do you manage large amounts of state and how does it compare with react context and signals and, you know, third party state management libraries. [00:20:57]

PR for “concurrent stores” skeleton

Mark: And so he confirmed that, they're not planning to add a context selector's, API and instead their thought process is actually now about this concept called concurrent stores. So as best as I understand it, the idea is that right now a third party library like Redux or Zeus stand relies on the use sink external store hook to be able to tell react that there's a subscription data changed. This component needs to update, but. That has the limitation that it doesn't play well with suspense and transitions because if something got updated in the middle, react has to throw away work in progress and do a full render. It can't do all the, you know, the performance optimizations and with transitions. So it sounds like this concurrent store idea is supposed to be like an improved, better version of use sync external store where you can still have some data living externally. You can still have selectors saying like, only these components need to update. But the concurrent store would wrap the updates in a concurrent transition compatible way. [00:21:25]

So he said that they're really trying to put some focus in API design onto figuring out what a concurrent store, API ought to look like. And it sounds like they've got some, some amount of progress on that design to talk about in the near future. They did put up a pull request a couple months ago with the skeleton for concurrent stores. It's just like defining some, some data types and adding some tests. There's no implementation code yet. [00:22:41]

Third-party \`react-concurrent-store\` ponyfill package

Mark: However a third party developer that I saw has actually looked at all the tests and then gone off and tried to implement a third party hacky polyfill version of what it looks like the concurrent stores are supposed to be and publish that as a React concurrent store package. I'm very excited about this and I have not had time to actually try it out yet. So the takeaways are a. Most developers probably won't need to use some of these things directly. A lot of this is going to be more library maintainer concerns but it's very good to see that the React team is actively thinking about how, how can we make React apps faster? What are the best ways to manage complex state? How can we better integrate with third party libraries and try to make all the react features like transitions work well in those cases? [00:23:13]

So there's your info dump for the day. [00:24:08]

Carl: Love that. I had said some stuff just before we started recording, just before we started the event about, I've been playing with effect effect ts lately, which we, we've mentioned once or twice now. And again and when you're talking about these concurrent stores and you know, like I'm reading the post from Joe Savona talking about context selectors. [00:24:10]

One of the things that I think effect solves well is dependency injection. it's focused on the backend, that actually says in the documentation like, effect is not meant for front end. They're, it may seem good, but it's not what it's meant for. And they're interested in exploring that, but they haven't yet. [00:24:30]

But I think the execution model is pretty similar. It's like, it's almost like componentized backend a little bit. But with type safe dependency injection and error generation and, and using effect pretty extensively for the last three or four weeks has really made me. Itch for some of those benefits in React. [00:24:44]

I'd be curious to see if they can, well, I've got a little bit more connections to make on that later on, so I guess I'll end it there. I don't know, just about dependency injection in effect and type safety and whatever in the context of selecting data on the front end, I think is interesting. [00:25:05]

I think there's still a lot of API design exploration to do there. [00:25:20]

Mark: I definitely recommend taking a few minutes to read some of Joe's comments in that context. Selector's, RFC thread, if you got some time, and then I, I expect there be, and to be at least some announcements, possibly about concurrent stores coming up at React Conf in October. [00:25:25]

Carl: Interesting. [00:25:41]

Mark: Then the last item out of the React related changes they merged a PR to add what looks like a new suspense timeline to the dev tools. They've got a demo video in there, and so it looks like it's actually now a, a third extra tab in the Chrome dev tools. So you've got the component tree, you've got the performance tab, and then there's a suspense timeline tab. And it looks like what it does is a mixture of , a rough rec out, like rectangle outline of the shapes of your components, but not showing like any of the HTML, just like , here's the structure of what your component tree looks like visually, and some highlighting for which ones have suspended, and then possibly some further details in a sidebar about which components suspended and when. So. as a dev tools type person, I'm always very, very excited to see new dev tools capabilities being added. [00:25:42]

Lee Robinsons’s “Reflections on the React Community” wrap-up post

Carl: Okay, let's go into. We talked a little bit about Lee Rob leaving Vercel recently and going to Cursor. He put out a really great blog post called Reflections on the React Community. This sort of summarizing his, his time at Next and in React. Yeah, I don't know. Mark, do you wanna start? [00:26:39]

I don't know if I have anything specific to start here. It's a really good overall hot, you know, 30,000 foot view of his time. [00:26:59]

Mark: So Lee Robinson was the primary developer relations person for Vercel for about five plus years. And even in my own head like. when I hear the word devel Lee is pretty much the first person that comes to mind. And Lee was always in a very tough position. You know, CEL is, you know, a somewhat divisive company in some ways. You know, it, it puts out some wonderful technology. They've genuinely done a lot to advance the React ecosystem makes, make apps, you know, easier to host, they build next, et cetera. But, you know, they've also been accused of, you know, the React team and pushing reacts direction and making changes just for profit. And you know, as I've discussed in some previous episodes and blog posts, like a lot of that is undeserved criticism or, you know, misinterpretation of the background. And so, as you know, the visible face of Vercel and the next team we was. Frequently the target of a lot of those criticisms, even though, you know, none of it was, you know, like he wasn't the one developing the tool set or, you know, making the businesses decisions. And one of the things I've always appreciated about Lee is that, you know, he was always very, very active in discussions on, you know, Reddit and Twitter and Hacker News. You know, like not just in like the next sub Reddit, but you know, the React Reddit hacker news discussions. Like anytime a discretion thread would happen, he would pop up and, you know, respond to comments, offer feedback, and, you know, yeah. [00:27:07]

Because of his position. Like occasionally people would interpret it as being like a corporate ish response, but he was always very, very active in being in there. And unfortunately that meant he was also the, you took the brunt of a lot of the criticism. So a lot of his blog post, you know, talks about, you know, react has, react has become stable, it's grown, the community's big. [00:28:48]

Working with any community is really, really hard and it can be very stressful and very frustrating. He talks a bit about some of the difference between, you know, a, you know, more broadly like projects like React versus Rails you know, dealing with some of the community management acts, aspects, how you get feedback. He even talks some about, incentives like the React team in some ways builds react for meta. And sometimes that means that, you know, issues slip through the cracks. You know, like Meta isn't trained to make money off React. Well, in some ways Vercel is. And he also talks about, you know, some of the, the server component development process, how that was marketed how it's been interpreted. And he talks about burnout. And boy can I understand and sympathize with this one on multiple levels. responding to issues and comments, even when they're positive, takes a lot of time and effort. And when a lot of those comrades are, you know, angry and critiquing and throwing around conspiracy theories, that wears away at you a lot. So I have a huge amount of respect for Lee and everything he's done for Vercel and next in the React community over the last several years. And so I appreciated him doing the writeup and I could totally identify with a lot of the points he was making in here. [00:29:13]

Carl: Yeah, definitely. And it's funny, I, you know, nobody, nobody's ever paid me to do reactive flux things, and it's a very different type of like community management. But I definitely, a lot of what he said resonated with me. But from that perspective, and also just like, I don't know. The burnout and, you know, thanklessness of wrangling a large group of people is is pretty real. [00:30:35]

Mark: So it's a post worth reading. And Lee, if you ever hear this, thank you for all your time and effort. [00:30:58]

Carl: Yeah. Thank you for all your time and effort. It's been a lot. It's been great. what you said about like Lee really being like you think Lee, Robb is definitely a canonical dev rel, like showed the world how dev rel happens. I think [00:31:04]

really, uh, personified it. [00:31:16]

Remix doing its own component model??

Carl: Maybe in two remix doing its own component model. [00:31:18]

Mark: we've been doing sort of a running observation of what in the world are Michael Jackson and Ryan Florence doing over in their corner. They, they continue to drop cryptic hints on Twitter about the directions of remix version three. And while this isn't, trying to keep this from being the, just repeat what they say on Twitter podcast, but, you know, so far all we have to go by is the cryptic hints that they're dropping. And so we've gone from, you know, just Remix v3 is its own thing to, it's going to use Preact to, well, actually, I guess now it's not using Preact. [00:31:22]

Carl: Yeah, so I, I, I guess they want to explore a similar kind of problem space as react and React are, I mean, I, you know, that's the signals that they're putting out here is that like, well, these existing tools do not solve the problem well enough, we believe. And so we're going to explore that. And, you know, I, fair enough, I, I think there is more room to explore there. [00:32:01]

I know some discussion in reactive flux on this, you know, on this link earlier Ricky had said like, you know, good luck to them. I think they may find some of the same constraints as React has, and I think that's pretty likely. But, you know, also there's a term coming to mind uh, path dependence, which is, you know, like what the options available to you going forward are dependent on the choices you made in the past. [00:32:26]

And so, like, you know, react is pretty far down, it's set of chosen decisions. So I think there is some value in backing out and saying like, well, hey, maybe we're in a local maximum. Let's explore some other possible paths here. And yeah, so let me pick up where I sat down earlier talking about effect. [00:32:49]

Right. So like, it, it feels to me like a componentized model for the backend. And it's really interesting because each, you know, backend component that you write, which I'm, they call 'EM Effects, but you know, this is a React chat, so I'm going to translate. So you write like a backend component and it has a type safe it uses TypeScript generics to describe its outputs, its possible errors emitted and what dependencies it requires to be passed in effects. [00:33:08]

These backend components can like, make their own dependencies available, you know, or they can say, you need to provide this at runtime. And so that's pretty, that feels very similar in use to me in like ideology to me as what React is trying to do. [00:33:37]

Mark: your props and your output. [00:33:54]

Carl: Right. Props, return value, boom. Like, okay, every return value is JSX and it doesn't really matter specifically what, but you know. Yeah. So it, it, it's really interesting having error safety as well as dependency type safety because like props are one thing. But you know that there's no way to describe that. [00:33:56]

This component being rendered relies on being nested underneath a context provider. Like you can do a runtime check for that, but you can't do a a compiled time type safety check for that. And that's the kind of thing that effect is enabling. It's that kind of dependency injection. Like what environment does this expect to be run in, not just what inputs does it expect to be provided. [00:34:16]

I. So like using that in a backend context, you know, in this, going all in on this in a backend space where it's intended to be used has really made me reflect on the experience of using React and what kind of, what some of its pain points are. And so I guess like the React core team has gone all in on the transition boundary between the client and the server with server components. [00:34:41]

Like they wanna really make that smooth and instead of this request response model, just have it be more fluid and you know, whatever. Yeah, streaming all that which is great and that's a very interesting direction to explore, but it does not address all of those kinds of things of how do we make a robust. [00:35:04]

Reliable application that can be statically verified, will run as expected. And that is more of where effect is coming at the problem space of code authoring from. And yeah, I think the, like both of those are really interesting viable problem spaces to explore. And if Remix is saying, we think the path that React is exploring is not the ideal user experience, maybe they're gonna go more in something like this. [00:35:23]

And if they do, this is wild, pure, rampant speculation on my part right now. But if they, you know, I can see a possible world where one thing that might interest them is the same kind of guarantees that effect is trying to provide. And that would be valuable. Like, so I, I, yeah, I'll still be paying attention to this. [00:35:51]

I do have a greater degree of skepticism it's a huge expansion of what scope of problem they're exploring. So that's challenging. But you know, they've taken on big challenges before. Shipped things. So yeah, we'll be paying attention and see what they see. What they come out with. [00:36:09]

Mark: Yeah, so basically where things stand at the moment are lots of cryptic hints on Twitter. It's not gonna be a React. It's a different component model. They want to make it LLM friendly. We still haven't seen any good examples, but I'm assuming they will do a big announcement at the Remix Jam conference, which I think is in [00:36:24]

October. [00:36:42]

Carl: Yeah. Oh, they had just done, just recently announced that. [00:36:43]

Remix 3 and the End of React-Centric Architectures

Mark: And then along with the rampant speculation bit I saw a blog post just earlier, earlier today, but it was from a month ago called Remix Three and the End of React Centric Architectures, which also does a bit of, you know, speculating, hypothesizing on the ways various frameworks have chosen to build things and says, you know, maybe it's a good thing that Remix three is supposedly going back to a more web native framework approach. [00:36:46]

Carl: Yeah, and they're doing Remix Jam right after React Conf in Toronto, so, yeah. We'll, we'll shot that out at the, in the conferences section at the end too. [00:37:13]

Carl: Yeah. Okay, moving on. our last main content subject for the month, there's another security vulnerability. I feel like we, you know, we, we, we talk about these somewhat regularly it feels like, but some pretty popular NX packages were compromised on NPM. So NX is a, [00:37:21]

Mark: Monorepo management and build tool [00:37:39]

Carl: yes. It's a competitor to turbo repo. I, I, I think I would [00:37:42]

Mark: to, to some extent. Yeah. [00:37:46]

Carl: it got wholesale compromised as in like everyone who installed it had a post install script run that swiped a bunch of configuration files like .env and .npmrc, anywhere you can think that credentials might be stored in your project workspace or elsewhere on your system. [00:37:47]

This script looked for and then uploaded to GitHub. So that's really bad. This is a, this is a, this is a theoretical exploit that I've been hearing about for the last 10 years. Like the vulnerabilities possible by NPM post install has been a subject that comes up every couple of years. And, oh boy, this is a bad one. [00:38:07]

The, this blog post discussing the vulnerability said that when they were, they were monitoring GitHub. 'cause the way the script worked is it would, if it found your GitHub credentials, if it found a valid SSH key for GitHub or I guess actually an API token, not an SSH token. But if it found a GitHub API token, then it would silently upload a new repo. [00:38:27]

So it, it, which is interesting because it was a public repo on GitHub created by this malware. So there was some kind of public metric that could be gathered for its scope of impact. And so there this blog post says that they saw at one point, 1,400 of these repos created by this malware script. [00:38:51]

So like, that's quite a number of people who got all of their secrets swiped off their system. One interesting thing that this malware did is if it found an LLM tool on your system, it would write a prompt to that LLM asking it to find all of the secrets on your system. So like if you, if you've got Claude, like suddenly Claude is maliciously gathering all of your tokens from your entire system that it can, you know, whatever it can access. [00:39:11]

Like, holy shit, that's bad. That's not, yeah, that's, that's pretty bad. [00:39:38]

Last month eslint-plugin-prettier maintainers were targeted, this is a much broader attack

Carl: you know, last month we discussed a, another vulnerability where the eslint-plugin-prettier package maintainers were targeted. So I guess this, this could be, this could be the same attackers perhaps, and they were just more successful in that, you know, instead of. Getting busted while trying to steal credentials for a major packages maintainers. [00:39:43]

They actually got it. And so now they have successfully executed on this broader attack that they were maybe trying to do earlier. Woo. That's bad. And it sucks 'cause like what do you, how do you even respond? What do, how can you keep yourself safe if just [00:40:02]

Mark: Monitor your, monitor your dependencies, actually look at lock files. I, I can say that there are some good tools out there that will watch PRS for, you know, like what packages are getting updated in this PR and, you know, warn you if any of them have known PO known problems. That's definitely a valuable thing to include in the CI process. [00:40:16]

Carl: Yeah. True. But man, one of the, one of the challenging parts about this particular vulnerability is the. I, I remember half of the discussion that I saw earlier, and I can't remember where I found it, so I can't quickly refresh my memory, but there, a, a popular tool uses NX at latest on like, you know, project Bootstrap. [00:40:39]

So like, you know, if you're just casually idly using whatever project generator this was to start something new oops. You got the latest NX that was compromised. So like that's not even, yeah, I don't know. Just like [00:40:59]

Mark: the comment was actually in the, the tech reads and news link and it was [00:41:13]

the NX vs. Code extension. [00:41:16]

Carl: Okay. Okay. That's a li that's at least a little bit different vs. Code extension is not as popularly used as a, you know, project bootstrap tool, but yeah, not great. [00:41:19]

⚡ Lightning round ⚡

Carl: Okay. Into the lightning round. [00:41:31]

Mark: Go for it. [00:41:33]

React Strict DOM vs React Native for Web in 2025

Carl: I saw this post from, it was a blog post summarizing a podcast from react Native Radio from Infinite Red. Great Folks. They spoke with the maintainers of React strict Dom and React native for web comparing and contrasting. We had discussed React strict dom a about a year and a half ago. [00:41:33]

It was like February of 2024. And a, a lot of what we did was compare and contrast it against React native for web. So this was like very precisely the type of conversation we had except with the maintainers who aren't just speculating and guessing and inferring, but like they, no, they made this like, they know how it works. [00:41:54]

They know what the trade-offs are. So it's got some really great architectural diagrams explaining the distinction and what the difference is. It lines up pretty well with what I recall us discussing and they have a really good little flow chart for making decisions about you know, TLDR should you adopt React strict dom. [00:42:13]

And they did a nice little handy visual, which I'm gonna go to the Happy Path through the Happy Path on, which is do you already have React native app? No. Will you need web support eventually? Yes. Use extract Dom. So like basically they're saying this is a great low level set of abstractions that will make it more feasible to reuse your code in more places. [00:42:30]

You know, like the benefit has always theoretically been that you could reuse much of the code between React native and web. But I've tried to do that a couple of times and the practical realities are challenging. Like, you know, just you need to use doing abstractions so that, that work in both places is really hard. [00:42:54]

So this acknowledge React native sorry, react strict. Dom sort of acknowledges that and says, rather than trying to make a brand new abstraction on top of both React Native and react dom, we are going to lean more heavily on the web platform as an existing stable abstraction. Which is cool. I like it. [00:43:12]

It seems cool. This is a really great blog post. Definitely recommend. [00:43:31]

Faster JSON.stringify()

Mark: The V8 JavaScript engine developers put up a post where they said they've spent a lot of time trying to optimize js, ON stringy. Think about how many times your code stringys stuff, whether it's sending back an H TT P response or you know, serializing things into an extension. they go, they go into a bunch of technical detail about how they've tried to make this faster. [00:43:34]

Carl: specifically that problem parsing Jason, Jason Parse performance is exact, like that was the reason for React native doing the new architecture, which they've spent like much of the last year communicating and executing on. So yeah, the massive problem for the entire ecosystem, [00:43:56]

Mark: You know, like other than actually executing the JavaScript code faster, like string finding stuff has to be [00:44:14]

one of the most common things your JavaScript code does. So I believe this is supposed to be out in, I think it was like V eight like 13.8 I think it said which is available in Chrome 1 38. And I don't know what node version will contain that, that version of V eight. But faster is good. [00:44:19]

Carl: Yeah, faster is so good, especially for stringifying. Yeah, man. Just the number of plate serializing and des serializing is one of the largest costs, you know, performance costs like everywhere. So yeah, it'll love that. That's great. [00:44:42]

Node 22.18 unflags TS type-stripping support

Carl: Node 22 point 18 flags TypeScript type stripping support. [00:44:56]

node has had experimental support for. Interpreting TypeScript code and stripping out the types. doesn't actually check them or anything, but it allows you to take a project authored natively in TypeScript and run it with node without a compilation step, without building it through the TypeScript compiler. [00:45:02]

Mark: Or, or using a tool like TS Node to execute it. [00:45:21]

Carl: Yes. Yeah. Right. More directly. This is a replacement for TS node. And that's great. It's no longer experimental. It's, they're now saying it works. it's officially blessed, it's released. Love that. Definitely the ecosystem has moved more from, you know, a long time ago it was very focused on you compile the code and then you take those built artifacts and you run them, and if the type checker fails, you don't get a built artifact and you know, the metagame here has shifted a little bit more into the. Type checking is one very valuable part of verifying your code statically, but it is not necessarily where the compilation step lives. So, many more projects in my experience have moved towards sort of a parallel model where you have a build step and there is type checking in the project, but it just kind of runs separately from that build step. [00:45:24]

So this is, this is a great tool enabling that kind of pattern. And it's released, it's done. Yay. [00:46:16]

Waku switches to Vite’s WIP RSC support

Mark: A couple RSC and project related updates. We've talked previously about how, vet itself has been missing some pieces in that would enable like full RSC support for vet based frameworks and that there has been a work in progress PR to try to add better RSC primitives into vet somehow. So the Waku RSE framework is now making use of vet's work in progress plugin rather than whatever layers they had built for themselves internally already. So it's good to see that that's coming together. [00:46:23]

Rari, a fast React framework with RSC support built with Rust

Mark: And then I saw an announcement for a new framework called rari, which is sort of an acronym for something, some, something faster rendering somehow. But it looks like a, it's supposed to be an RSC based framework that has a custom low level layer. Built with rust. And of course, as we all know, rust makes everything faster. But it sounds like someone looked at some benchmarks of, you know, like next RSC performance and said, I think I can do better myself. And has built their own full stack framework that has RSC support using a custom low level rust layer. [00:47:00]

Carl: Neat. Cool. Yeah, they do claim four, four times faster component rendering under load four milliseconds versus 17 milliseconds. And that's cool. I don't know that if your problematic performance is 17 milliseconds, that's maybe not the worst problem to have. [00:47:37]

Selecting values from query results, as well as The Useless useCallback

Mark: Then separate from all that the always wonderful Dominic Dome TK Dodo has put up a couple great blog posts. One is the latest in the series of posts on how to use React Query correctly in this case, how to use the ability to select values out of a query. So maybe like you have a, a list items query and you only want to grab one of 'em. And then you also put up a post talking about how a lot of time you don't actually need the used callback hook. There's a lot of cases that used callback is actually kinda useless. So excellent reading as always. [00:47:52]

TS+ postmortem (Effect-TS experimental TS fork)

Carl: Can you tell I've been using effect and it's just been living in my brain for a lot of the time. I, as part of reading it, I found this blog post that they wrote pretty recently beginning of July. Where they had done, they had actually forked the TypeScript compiler wholesale and tried to do what they called TypeScript plus TS plus. [00:48:26]

And I guess part of the idea, as you, as I've been using effect, I can feel very strongly the desire for JavaScript to support a couple of different tools that I, I I, I had remembered seeing as proposals many, many years ago and waited many, many years for them to land mo specifically the pipeline operator for composing functional, you know, programs together and pattern matching, which resembles a switch case, but lets you match on like properties and attributes and, you know, things like that in a different way, in a more flexible way. So. They tried to fork the compiler to make errors a little bit better. Basically, like they're really pushing the bounds of everything you can do in TypeScript and JavaScript. [00:48:45]

So the, as part of that, they explored fully forking, TypeScript and this, so this is a great postmortem of their design goals and what they were trying to achieve and why they have backed off of that. Yeah, how far we went and what went wrong, what we learned it's pretty good. Definitely very interesting like this. [00:49:35]

Just reading more about effect, I can just like, it just the amount of the number of different places where they're pushing the envelope and like iterating on the state of the art in web on the backend is just really palpable to me. So, definitely an interesting read here. [00:49:55]

Mark: I, I, I thought it was a good blog post. Honestly, I also partly appreciate it just because they said we spent like an entire year trying to build this thing and it didn't pan out. Here's what we tried and what we learned and what went wrong in the process. I, I, appreciate good art, good write-ups, like that. [00:50:12]

Carl: Yeah, right. I feel like this is good to read as an engineer because it's just a really good postmortem where you can really understand their thought process of why they tried to do this, what benefits they were hoping to get, and what challenges they ran into that made them say, okay, this is not achievable. [00:50:29]

Just really good, really good read. [00:50:46]

React useTransition update ordering details

Mark: I saw a good short post from Jordan Eldridge, who I believe created the web amp recreation of Winamp. Where gave some, gave some thoughts on what happens when you do a React used transition and you apply some other state updates while the transition is going on. Short but useful, especially since transitions are a newer part of the react rendering model. [00:50:48]

“A Clock that Doesn’t Snap”, Techniques for fixing hydration of values like dates

Mark: And then I also saw a post called A Clock That Doesn't Snap, which talks about some of the dealing with inconsistency problems between server rented values like dates, and then what happens when you try to actually hydrate that on the client. And a couple different techniques for trying to make it not be inconsistent. [00:51:13]

Carl: Interesting. [00:51:35]

React Cache: It’s about consistency

Mark: There was an article on React Cache. It's about consistency, so React added the cache, API for use on the server, and it's, it's a sort of memo function. The idea is that you can get, like if you need to make one fetch call in multiple places while doing server side rendering, you can try to ensure that it only happens once during that particular render pass on the server. And so the post goes into some detail on what the cache method is, why you want, would want to use it, and how it, you know, actually using that cashed value during the render can produce more consistent results during the render process. And then goes into a little bit more about like some of the conceptual behavior of React components and what is pure versus impure anyway. [00:51:36]

Self-hosting Next at scale

Mark: saw an article that gave some battle hardened details on the complete guide to self-hosting Next JS at scale. So next is commonly used with Vercel. You can deploy it yourself, but you sometimes have to fill in some of the missing hosting pieces. And so this was a good post that gave and that talked about, you know, what are, what happens when you try to use Next Cache? [00:52:26]

And it by default cache is values locally. But if you've got multiple copies of the server rendering, now you can have inconsistencies between different instances. So how would you break that out into using a Redis server or something? Instead, how can you handle image optimization and CDN configuration? So if you're trying to do any self host, you know, next, this looks like a very useful guide. [00:52:53]

Carl: Love that. Such a good, deep technical writeup of, I mean, right. Self-hosting next is such a big problem that people discuss regularly that I, I just love seeing, you know, a proper writeup about it. [00:53:14]

Server and Client Component Composition in Practice

Mark: Then finally we have a post from Aurora Scharf who spent a lot of time researching and writing about server components and various usage patterns, and she has an excellent post on server and client component composition in practice, which gives some examples of how you can intermingle server and client components to do some of the work on the server, some of the work on the client figure, and figure out where the boundaries ought to be. [00:53:26]

Carl: Yeah. figuring out where the boundaries are should lie in things that's uh, very challenging. [00:53:53]

Mark: And I think that's actually all we've got for this month, which is good 'cause we're right about at at time. [00:53:59]

Conferences (React, Javascript)

Carl: Cool. Let's wrap up here with some conferences. [00:54:04]

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

Carl: We got React, Universe coming up in just about a week in September 2nd through fourth in Wroclaw, Poland. [00:54:06]

WaysConf Sept 16-17

Carl: There's also Ways Conf September 16th and 17th. Krakow Great. Also in Poland. So yeah, Poland heavy uh, September. [00:54:14]

CascadiaJS Sept 18-19 Seattle, WA, USA

Carl: Then right after that, Cascadia Js, September 18th and 19th in Seattle. [00:54:21]

CascadiaJS Sept 18-19 Seattle, WA, USA

Carl: Coincident with Squiggle Con September 18th in Boston, which I will be at [00:54:26]

React Alicante Oct 2-4

Carl: Then in October we've got React Alicante, October 2nd through fourth in Spain. [00:54:32]

Mark: I will be speaking at that one. [00:54:37]

I was not going to be there originally, but I will be flying back from Spain and showing up at React Conf in Las Vegas. That's gonna be a trip. [00:54:39]

Carl: Yeah. Oh, wild. Yeah. [00:54:49]

React Conf is back, Oct 7-8 Las Vegas, NV, USA

Carl: 'cause we've got, you know, react conf in Las Vegas right. Then October 7th and eighth, [00:54:51]

Remix Jam, Oct 10, Toronto ON, CA

Carl: then, like we mentioned earlier, we've got Remix Jam October 10th in Toronto. So if you really, like, you could fly out to Vegas and then fly across the, well, I was gonna say across the country, but it's a different country. You can fly across the continent to Toronto. [00:54:56]

Outro

Carl: Cool. That's all we got for you today. Thanks so much for joining us. We will be back on the last Wednesday of the month here in the live stage or back in your podcast feed just as soon as we can after that. [00:55:10]

Mark: Thank you all for listening. Hopefully the list of links has been useful and informative. If you are going to be at either Squiggle Con, react Delicate, react Ante, or React conf please say hi. I will be running around possibly wearing my Simpsons picture as a name tag. [00:55:19]

Carl: great. Love that. Yeah, same. Likewise. If you see me in Boston or in Las Vegas say, Hey, We gather sources from this week in React Bites, dev the React JS subreddit, and here in Reactive Flux from the uh, tech News and Reads channel. If you see anything that you think we should discuss definitely send it over to us at hello@reactiveflux.com. [00:55:37]

if this is a show you get value from and wanna support, best way you can do so is by submitting a review on wherever you listen and tell your friends and coworkers about it. Thanks so much. you next month. [00:55:56]

Mark: Take care. [00:56:04]