TMiR 2025-01: Movement on CRA, Redwood.js dead?

Transcript from Thursday January 30th, 2025

[00:00:00] Carl: Hello! Thank you everyone for joining us for the January edition of This Month in React, where we recap and digest the recent developments in the ever evolving React and web ecosystem. We're coming to you live from Reactiflux. The place for professional React developers. We are supported by Infinite Red, a consultancy that exclusively works with React Native.

[00:00:19] I am Carl, I am a staff product developer and freelance community manager here at Reactaflux, where I run community programs like this and Star Helpers and some other stuff, and just generally try to keep the community humming nice and smoothly.

[00:00:32] Mark: Hi, I'm Mark. My day job is working at Replay, where we're building a time traveling debugger for JavaScript and other fancy uses of introspecting application behavior. Outside of that, I do Redux, and I apparently argue with people about the right way to use React.

[00:00:48] Mo: And I am Mo. I head the mobile team at Theodo. And I am involved in the React Native ecosystem, where I frequently jet off to some of the different conferences, meeting some lovely folks in the community and help organize the London community with the React Native London Conference and the meetups that we run monthly.

[00:01:04] Yeah, very excited to be here, as every month.

[00:01:07] Carl: Yeah I feel like There has been some stuff, just not like a wide range of libraries and whatever, but yeah, I think we'll definitely find a lot to talk about. Uh, Actually this month, Mark is not only a pundit, but active participant in the ecosystem,

[00:01:24] Mark: am making the news.

[00:01:26] Carl: making the news and then reporting on it. Cool.

[00:01:29] Job market: FRED data, Layoffs.fyi

[00:01:29] Carl: Yeah, let's start off briefly, overview of the job market tech. Man, you know what? I thought it was like recovering a little bit, but I'm looking at the metrics and like, okay, the FRED data, some Federal Reserve data source, it only shows job postings to Indeed, so like that's a pretty narrow slice.

[00:01:50] Who knows what other activity is happening, but like, presumably they're publishing it because they believe it's a reasonable proxy for the broader market. And it keeps going down! It just keeps going down. I don't know, hopefully that's just an indicative of Indeed, like, not being the place where people hire software engineers, which, you know It's probably, likely true?

[00:02:09] I don't know. But yeah, it's just lower and lower every month it looks like. It's lower in January than it was in December, and December was lower than November. So, that's not great. Layoffs are also trending down. There's not as many people getting laid off anymore. But there was a bit of a spike in January this month.

[00:02:26] Looks like 5, 200 people were laid off from 20 companies. Yeah, that's fewer companies than December, but like twice as many people, so that sucks. I think a lot of those are coming from a small number of companies. Yeah, Meta laid off 3, 600 employees two weeks ago. So yeah, job market is maybe not gonna be As improving as quickly as I hoped it might from some early indications towards the end of the year and in the first couple weeks of 2025.

[00:03:00] But conferences still don't have a ton of queued up ones. I think people are still getting their ducks in a row with planning and scheduling for 2025.

[00:03:09] Sponsored by Infinite Red

[00:03:09] Carl: like I said in the open, we are sponsored by Infinite Red. They are currently our only sponsor. But we don't communicate with them about, like, editorial or anything like that. They gave us some money, and I shot them out. Woo! They are an expert React Native consultancy that's been around since 2015.

[00:03:22] And they're our only sponsor in part because so few companies do as much as they do for the ecosystem. They, put out a newsletter. They host the largest React Native podcast. They run, I think, the largest US based conference. Specifically on React Native and generally they are just like great people who do good work.

[00:03:44] They have built over 75 apps for companies ranging from startups to the biggest in the world and they generally work with your team to help you develop expertise, not just build the app for you and get out of there. So yeah, if your company is looking at starting up a new React Native project, definitely consider reaching out to them.

[00:04:02] They are infinite. red.

[00:04:04] Mark: I've met Jamon a couple times and seen some of his discussions online. He's a good guy.

[00:04:09] Carl: I mean, they're our sponsor because I met him at a conference and just sort of chatted idly about what we were doing. He was like, yeah, that sounds good. Let's talk more. great dude.

[00:04:17] New Releases

[00:04:17] Carl: into some new releases. Not a ton this month, in part because I've been distracted with some other projects and have not paid quite as close an eye as I would have preferred.

[00:04:26] React query 5.63

[00:04:26] Carl: But React Query put out 5. 63 looks like, you know, I mean, it's a 63 point release, like there's, it's gonna be some fine tune and revisions, but uh, looks like they added an ability to unsubscribe an observer from the cache which should help in React Native. So, yeah, PanStack, great, great resource.

[00:04:45] Docusaurus 3.7

[00:04:45] Carl: Docusaurus also put out version 3. 7, so if you're using that, consider upgrading. Great

[00:04:52] Mark: actually updated the Redux Toolkit doc site from DocuSource 2 to DocuSource 3, and it's definitely some improvements. thing I think was in 3. 6, previously they've always used Webpack as their build tool. And with 3. 6, they introduced an experimental option to use the RS Pack, Webpack re implementation in Rust for faster builds, and it definitely did seem to speed things up,

[00:05:17] React Native Audio API

[00:05:17] Carl: Yeah Mo, you want to talk about the React Native Audio API?

[00:05:20] Mo: so this one is really, Interesting. Because for the longest time, obviously, like, the Web Audio API is incredibly mature. It gives you so much functionality, you can make some really cool stuff with it. So if you're trying to do anything with audio, like, I don't know get information about your audio sources, run it through effects Be able to generate audio graphs, you know, things like showing wave, waveforms and stuff like that. On the React Native side, it's a lot more difficult to achieve similar things because you're dealing with native level APIs, they're not standardized and you may end up having to just write some code yourself to be able to do that on the native layer per platform and to try to achieve similar things.

[00:06:07] So, the example that is quite common is generating wavelengths. I've tried to generate wavelengths on the client for certain files. Not a very easy task to do, it turns out. So some functionalities like that are just so much easier to do on the web.

[00:06:21] And so the folks at Software Mansion have recently started building out A React Native audio API, and so the whole idea is, let's try to bring over the Web Audio API, which is incredibly mature, very standardized, and high performance, into the React Native scene, so that you can have the same levels on control and playback as you do on the web, and standardize it.

[00:06:46] It fits quite well into the sort of universal app story where you want to standardize around web APIs because they're mature and allow native developers to ingest the same ones but delegate the implementation and the runtime of those APIs onto the native layer. So this is quite cool. It's still early days.

[00:07:06] And it's, it's not, you know, ready and it doesn't have all the bells and whistles that you have in the web, but it is a very, very good step in the right direction. And so I, I'm super excited to see how this evolves over the next few months and years, I guess.

[00:07:21] Carl: Cool our main content. So this is our first episode of the year. I was thinking that we'd discuss a little bit about what we'd like to see, but,

[00:07:30] CRA deprecation, React team against recommending Vite

[00:07:30] Carl: Mark, you want to start us off talking about create react app and we we can springboard from there

[00:07:37] Mark: gladly. So, React 19 came out last month, in the culmination of, couple plus years worth of technical effort from the React team, and we've all been very excited about that huge jump forward for the ecosystem. Thanks But it also had some unexpected technical side effects, and the technical problems have then spiraled into drama.

[00:07:57] And I actually happen to be squarely in the middle of that. So I'm going to be describing things, I am both a participant and an observer. And we'll go from there. So Create React App came out in late 2016, early 2017, and it was designed for a couple of purposes. The whole point was make it really easy to start a new React project with a good default build config out of the box with one command.

[00:08:23] You know, previously you had to spend a lot of time configuring yourself. And so part of this was to make it easy for beginners to start a new project and be able to focus on trying and learning and using React. And it also, you know, had, you know, was perfectly fine for actual production projects as well.

[00:08:42] And so Create React app succeeded wonderfully. It became the default standard, you know, set up for tutorials. Lots of companies used it for actual apps, but over the next few years, you know, other build tools came out, things that were faster than Webpack CRA was having trouble kind of keeping up with, you know, some of the maintenance demands.

[00:09:03] They were very slow, you know, dealing with the, the Webpack upgrade.

[00:09:07] Carl: Right

[00:09:07] Mark: And by like 2022, Create React app was actually kind of basically unmaintained. Now, even though it was in the Facebook GitHub org the last people maintaining it were not even Facebook employees or, or part of the React team. And it basically like a ton of issues had piled up.

[00:09:28] Dan’s “why CRA exists, don’t use it, possible future options” comment from 2023

[00:09:28] Mark: So in, I think it was early 23 Theo Brown put up an issue saying we should mark create React app as deprecated and we should point people to use V instead. That's it. And, you know, he, the issue got, you know, went viral and it collected tons and tons of thumbs ups and eventually Dan Abramov responded and wrote a massive detailed reply saying, saying, here's why create React app exists.

[00:09:55] We see that the ecosystem has changed. We've also been changing some of our thinking about the right ways to use React. And here's five possible futures for the create React app tool, ranging from kill it completely to, modernize it, to change the CLI tool to be a multi launcher that would end up pointing to, creating a next app or uh, remix app or something. And that's where things kind of left off. You know, lots of people read that comment. The community just sort of absorbed the knowledge that you're not supposed to use Create React App anymore and everyone asking questions about how should I start a project was told, use something else. But Create React App itself never formally got deprecated.

[00:10:40] The CLI still ran, nothing changed in the docs, Dan's extensive comment was never turned into actual documentation. And so that brings us forward to, you know, this last month. React 19 came out and Create React app promptly started breaking. The Create React app CLI has always tried to install the latest version of React into whichever template package you specify.

[00:11:06] And the templates have some dependencies, including tools for linting and testing. And it turns out that The React Testing Library version had a peer dependency on React 18, and suddenly CRA was trying to install React 19. And since NPM throws errors anytime there's a peer dependency mismatch, what happened was you try to run create react app my app, and it promptly throws errors saying I was told to look for React 18, but there's React 19, these don't match. And so over the last month, I've seen dozens of people file issues or You know, Reddit threads or comments saying, Hey, I'm trying to start a new React project, and it throws an error. And a lot of these people are beginners. And so I was seeing so many of these threads pop up that I began to make a couple comments on social media saying, Hey, like, no one owns Create React app at this point.

[00:12:01] It's unmaintained. This is bad for the ecosystem. It's bad for beginners who don't know they're not supposed to be using it and are just trying to follow a tutorial. And that's actually part of the problem, is that a lot of older tutorials They'll reference create React app and no one's telling them you should be using something different.

[00:12:21] And if it breaks, they don't know what their other options are.

[00:12:24] Carl: the SEO for it is so strong. Like if you're just, if you don't know anything about the ecosystem and it's like, I want to make a new React app, like you search new React app or something like that in Google,

[00:12:35] 80 percent odd, you find create React app.

[00:12:38] Mark: I literally Googled that, and the, the top hit is the actual CRA docs. The third hit is the legacy React installation page. And like the second hit is the current React installation page. So I started griping about this on social media. And the second or third tweet that I put up about this actually is what really spawned the discussion and drama.

[00:13:03] So that thread went viral and took off. And a couple members of the React team, Dan and Ricky, began to reply. And Overall, my main goal was, I felt that number one, somebody, aka the React team, that had the right project permissions, should fix the Create React App templates so that it doesn't error when you create a new project.

[00:13:26] It's still a tool, it should work, it shouldn't break. But, both the CLI tool and the docs should be updated to say, Create React App is deprecated, don't use this anymore. Like, yeah, it'll work, but you shouldn't use this. Thanks. And that they should, you know, hopefully point to like some kind of a migration guide, like here's what you should use instead. that's where we also start to run into other problems. if we point people to the existing new React docs, start a new project page, that's the one that specifically says you should only use React with a framework like Next, Remix, Gatsby of all things, and Expo. And it actually specifically argues against Train to do things yourself. Now, the most direct equivalent to create React app today is Vite. And Vite works great. And in fact, Vite is being used by millions of React projects. But the React docs don't actually list Vite as a real option.

[00:14:30] They mention it a couple times. And it's buried down in, at the bottom of the React docs. Can I use React without a framework section where they sort of grudgingly say, well, if your project doesn't fit any of these constraints, I guess you can use something like Vite which I'll get, I'll touch on that a bit further later. So to me, the right thing to do to get people off create React app is to have Vite listed prominently on the setup page because it's the direct equivalent and say, this is good for someone who's beginning or has, you know, just doesn't need all the bells and whistles that come with a framework.

[00:15:10] So that turned into more arguments. The React team still insists that you should only ever use a framework and have generally refused to list V in that page. And a lot of other people besides myself find this to be a pretty ridiculous stance. So the good news is after, you know, a lot of debate online this weekend, the React team did say we will update Create React app so it doesn't break.

[00:15:35] Mark it is deprecated, and we will do some work to change the SEO on the old docs and the CRA docs to try to point them to the current SEO. Setup page. And so I've, I've seen Ricky doing the work in the PRs on that in the last couple of days. So it's been a lot of frustration and debate.

[00:15:53] The good news is the immediate problem appears to be getting solved. Doesn't touch on changing the docs to list Vite as a valid option. And then that ties into all kinds of other general complaints about how the React team runs things. So that's the general state of play.

[00:16:12] Carl: It does seem like the, this stems a lot of the worst of the bleeding, like, you know, the SEO issue of if you're trying to enter the React ecosystem as a newbie, then those PRs will address the worst of that in that, like, I think they realized that there was like a real legacy issue, legacy docs issue in that like, The SEO for those links are so good that it ranks above the current docs in a lot of cases.

[00:16:36] So I'm glad to see them looking at ways to manage that SEO, but like, I've also managed documentation sites before and done SEO for them, like it legitimately took six months for those SEO changes to like fully settle down. So it's just going to take a minute for these changes to fully be reflected in search results too.

[00:16:57] Mark: You know, I don't blame them for you know, taking a few weeks for this, you know, Create React app breakage to bubble up. You know, like I said, no one had really been maintaining Create React app through 21 and 22. It's been widely considered deprecated and no one's owning it for the last couple years.

[00:17:18] So, You know, no one's really looking over at the repo issues. I saw the issues being filed in the actual React repo and on Reddit and Reactaflux. But I can understand that, like, it wasn't bubbling up and, , really catching their attention. So, I'm not upset that it, you know, it took me, you know, raising this issue and pushing it and, kind of stirring up the drama in order to get their attention.

[00:17:43] I can also understand that, you know, with React 19 having just come out, like, they're still kind of trying to catch their breath from that. That said, like, obviously I'm overly invested in this because I was the one And Trying to make the point that it needed to be fixed, but I've spent so much of my time as a maintainer Trying to think about how beginners will, read my documentation or, Trying to make things easy to use or answering questions from beginners And so I, you know, I care deeply about, giving beginners a good, you know, Startup path.

[00:18:12] And so it kind of bothers me that, they didn't jump on this as, Oh yeah, this is an obvious problem and we should do something about it right away.

[00:18:20] Carl: yeah, Dan gave such a long and thoughtful reply, acknowledging the issues, but then, yeah, it's, it sat for two years.

[00:18:27] Mark: There was kind of like, like I said, kind of the spinoff of the, you know, CRA is broken part is that the insistence on using a framework has become. Such a stubborn ideological stance, and I understand the reasons why the React team feels it's better for people to use a framework, it's coming with all the pieces out of the box, those pieces are pre assembled to, you know, be guaranteed to try to work the right way You know, the React team has kind of shifted gears to where they feel that, you know, server rendering is an important capability, routing is an important capability.

[00:19:03] You know, obviously it ties into their vision for React server components, which can only work with a framework for technical reasons. for years I've felt that there is a pretty big disconnect between how the React team thinks that people are using React, And how people actually are using React in practice.

[00:19:23] And there's, there's, there's a lot of reasons for this. I experienced it myself with Redux. Like I, I don't even use Redux to build apps anymore. And so I'm, as a maintainer, I'm having to just kind of like take cues from issues people file or, well, a lot of people have asked for this feature.

[00:19:39] I think it's worth it. But it's, it's reactive and I'm sort of over in my corner doing things almost by guessing. So there is always that danger when you spend all your time building a library of not seeing and feeling the way it is to use something in the real world. And, you know, part of the issue is that the way Meta, Facebook uses React, is different from how everyone else does, just because Meta has all their own infrastructure for routing and serving and bundling and everything else.

[00:20:08] They don't need lots of third party libraries for that. But, given how huge React is, It is at least the job of the maintainers to be aware that it's used in a lot of other ways. And even if you don't necessarily want to focus on all those use cases, you still need to be able to be aware and support that.

[00:20:31] And a lot of the React team's decisions and statements over the last few years have been basically very focused on we sort of assume that everyone who's using React is using it to build a server rendered, data fetched, routed CRUD app. And we don't really seem to care about any of the other ways people use React.

[00:20:53] Carl: Yeah, having been paying attention to React since it was like, since relatively shortly after it was open sourced, there has always been a pretty clear, I don't know, like they came at developing React with a philosophy for how to do web development.

[00:21:09] And I think that like over the last 10 years of React, 12 years of React. I think that has borne out more often than it's, there's always been people saying like, What the, what the heck are you doing? Like, this doesn't make any sense, this isn't, how I want to use it, you should be doing this.

[00:21:25] And I have seen many cases where the naysayers were wrong. I am sympathetic to the, You know what the vibes that are I'm getting from the core team of like, this is our lane. Like, we understand what we're doing here. Like, " you'll understand one day" kind of vibe. but I, I think there are a couple of, I don't know, I guess they, they've always had this ideological stance that they were sort of.

[00:21:49] Putting out into the world like people talk about react brain and you have to like change the way you think in order to Really effectively develop with react and like coming out of react you have to sort of Drift back into a different way of thinking to use other tools again And I think that's real and I do think that it's One of the great things about React, but I don't know It's uh, we're definitely in a kind of weird spot here where I guess some of the specifics about it have gotten a little bit Divorced from the everyday usage.

[00:22:20] Yeah

[00:22:20] Mark: Yeah let me give three reasonably specific anecdotes that kind of tie into this. So, when the new React docs came out a couple years ago that's when they, they really made that shift from, you know, you, you can use create React app, the old React doc said, if you're learning or building a single page app, use CRA.

[00:22:42] If you need server rendering, use Next. If it's a static site, use Gatsby. The new doc site, when it came out, said, use a framework. Next, Remix, Expo. And then it had the Can I use React without a framework section with five paragraphs of explaining why they think it's a bad idea. And the original screen at the end of it was, if you feel you need to do something else go ahead, we can't stop you. Now they've said they didn't mean that to be sarcastic, But everybody I've talked to have said, like, that is just like the most passive aggressive, insulting way to phrase it.And it took over a year r for them to finally rewrite that paragraph to take out the passive aggressiveness.

[00:23:27] And, like, that is not a good way to treat your user base. Especially when using React without a framework had been the default way to do it. And it's what you were recommending in your docs up until you flipped the switch on the new ones. Second example, so the suspense gate thing last year, you know, the React team had made a code change to alter how nested suspense components in as siblings would load from in, in parallel to in sequence.

[00:23:58] and you know, they had a good reason to make a change. You know, they were trying to make facebook. com a little bit faster and I'm not expecting them to have gone out and like, you know, run hundreds of example apps just to see if this might alter anything. But it Later on, in some of the discussions, they were saying, Well, I mean, you really shouldn't even be doing this pattern anyway.

[00:24:18] Like, if you want good perf, you should always be hoisting your data fetching up to a route or a page for best performance. Which, okay, like, it's a valid thing to do to improve perf, but it turns out that, like, React 3 Fiber people were using suspense to load 3D assets. And it's still a va and like, even ignoring that, nested suspense is a valid thing to do.

[00:24:44] So, it's a, you know, second example of, well, we, we really assume that you're gonna be doing things this one way that we recommend, and Not really following through of, but are there other people doing things a different way? And as a last example I even just ran some quick searches on GitHub in the last couple days, just querying for package.

[00:25:05] json files that reference either Next, the Vite React plugin, or the React scripts package from create react app. And it's, it's napkin math, I think it might have actually been, like, CRA was 1. 9, Vite was 1. 1, and NeXT was 1. 5. And so, mathematically, that means that there's 3 million projects that are You know, a basic single page app, and only one and a half million projects that are on Next. So the single page apps actually outweigh Next by two to one.

[00:25:38] And yet, the React docs don't even list Vite fairly compared to the other options. So it feels like they're cutting out an awful lot of the ecosystem compared to how people actually use it.

[00:25:50] Carl: Right, right. And like the, the recommendations they make around like best practices for performance and like whatever around loading and how to use suspense. Like, those are great. That's true. I don't disagree with it, but I also like most of my projects are like solo things. Or, you know, I'm collaborating with like one or two other people.

[00:26:10] And I'll skip a lot of that a lot of the time just because it introduces complexity. Like it's, it's an extra couple of days of like introducing scaffolding and, piping data around. And like then, especially when I'm just like iterating and exploring and I don't really know if I'm even following the right path yet.

[00:26:28] Like, I don't, I don't want to do that yet. I'll do it later once I know it's good, and I do want to care about performance, but that to say that like, I think a lot of development ignores those best practices because it is, because ignoring it is the right trade off for that bit of work, you know, the available, you know, it If you end up not shipping because you tried to follow all the best practices and blew out your budget for time or money or, you know, motivation from your contributors, then like, that's not great either.

[00:27:00] Yeah.

[00:27:01] Mark: So, in general I've seen a lot of frustrations about how, you know, the communications has been handled, about the React team's resistance to, you know, just adding a couple paragraphs in a header to one docs page. And I have a lot of thoughts about it that I'm working on writing a blog post on that will hopefully come out in the near future.

[00:27:19] But that's, that's been a pain point for myself, for a number of other prominent figures in the React community that I've talked to, and for a lot of other people that I've talked to as well.

[00:27:31] Carl: Well, so maybe, maybe let's try and bring it back. what do you think good relations from the core team to the ecosystem might look like over the next year? Like, just blank slate, what is, what does a good, I don't know, comms program look like?

[00:27:48] Mark: Yeah, so, I've actually, you know, mentioned this in a couple of my tweets, if I could magic wand things, we've fixed the CRA brokenness, that's great, we're marking as deprecated, great. You know, for CRA specifically, I would get the docs updated, so the CRA docs have migration guides, and they point to the setup page.

[00:28:07] And the setup page lists Vite as both a learning tool and a, if you just want a simple project. Because that both handles the, I'm a beginner, I just want to start a new project so I can write some components and learn aspect. But it also recognizes the breadth of ways that React is actually used.

[00:28:28] In practice, whether it's, I'm spinning up just a little sample project or, you know, an enterprise that has like a Python or Java backend and can't even run Node on their server. But just like, we're not even giving you details, we're just saying here's a valid way to do it and here's a pointer to where to go.

[00:28:45] Another thing that the React team has struggled with is general public updates on where they're going. And there's a lot of reasons for this. The React team has historically not had, a real full time paid devrel person. Historically, Dan Abramov did a lot of that work in an unofficial sense.

[00:29:04] Like, he was the public face of the React team, but it's just because he spent all his time answering questions on his, of his own volition. they've hired a couple devrels or announced that they had a devrel a couple times, and then those people always seem to just sort of and not really do anything within a couple months. I think Matt Carroll has been in that position for a while, but in all honesty, I couldn't tell you much of what he's done. I know I've seen some people say they've had conversations with him,

[00:29:36] Carl: I do know he put a lot of energy into the, into React Conf last year. But obviously a conference is not a like complete developer relations strategy, I don't know. But yeah, just to say, I do know that was a big effort.

[00:29:48] Mark: And especially since, you know, Dan shifted over and both left Twitter publicly and actually started working at Blue Sky. It generally feels like there's no one from the React team who is actively reaching out and looking to be involved in conversations.

[00:30:06] flip side of this is that a lot of that has come from Vercel and Next.

[00:30:12] You know, Lee Robinson has been incredibly active in terms of actually looking for discussion threads around Next. And popping in, but also the Vercel dev rels have written some really good content explaining things like how, you know, how does, you know, suspense or concurrent rendering work and, you know, how to use some of the new React 19 features.

[00:30:35] And some of that is in the next documentation and it's not at all in the core React docs. Some of it's on the Vercel or Next blogs and it's not in the core docs. Thanks. And frankly, a lot of that information feels like it should be in the core docs. Like, you know, the core docs describe the use server and use client directives.

[00:30:59] And they, they talk about some of where and, and when to use it, but they don't have any information on what are server components, how do they fit into the React architecture conceptually, when and why would I want to use server components in general? And so that, that feels like a documentation gap there.

[00:31:21] Carl: Yeah.

[00:31:24] Mark: docs are wonderful. Dan Port is heart and soul into this tutorial. It is excellently crafted, comprehensive. In page sandboxes, all kinds of other things, it's great, but if you were to follow the tutorial linearly, you get past the couple of, like, nah, never use useEffect pages, then it just sort of ends.

[00:31:47] And there's no direction on how to take this sort of theoretical knowledge of I'm writing some components in these sandboxes, and How to actually apply that to starting a real project. So like at a minimum I'd like to see a page at the end that says, Okay, you've finished the tutorial, great. Here are some active next steps.

[00:32:08] Here's how you can start a project. And by the way, if you're like using Next or Vita Remix. Here's how you would write components in the file structure in those actually give people a pathway. And then the last thing I'm, I guess, one other thing I'd like to see is more active communication on the blog.

[00:32:28] Historically, they've done announcement posts for big releases. And then they basically do like one. What we're working on post a year. That's about it. I realize that they, you know, they do a lot of prototyping. They're very reluctant to, you know, give early details on prototypes because everyone gets overexcited about them.

[00:32:51] And, You know, also this goes back to the, you know, the lack of a formal devrel person to have the capacity to do the writing. But, you know, even, and just, you know, some more frequent updates on what direction we're headed, or the kinds of things we're experimenting with. Even if you have to plaster it with, with very loud, this is a proof of concept.

[00:33:11] Labels you know, the idea of using the TC 39 stages as descriptions of how far along things are has been kicked around a few times. But you just, some sense of like, what is the roadmap and where are we actually going would be nice.

[00:33:28] Carl: Or like, heck, like you said, there's lots of great blog posts that people like Lee Robb or other, you know, Next and Vercel people are putting out. Like, just reposting those to the official blog would probably be pretty good.

[00:33:41] Mark: another one that I saw was the uh, I think, Some of the, you know, the team folks did a lot of great work in fleshing out the API references in the docs. And the only indication that anything had changed was they made a post in the discussions section of a, of a working group repo. No one is reading that.

[00:34:03] Put up a blog post saying, Hey, we added five new docs pages covering these topics. Like that is a thing worth announcing.

[00:34:10] Carl: Absolutely, 100%. Yeah. Well, one other thing I want to chime in on. On the documentation side of things too, I just saw, I just caught some discussion from people looking to make their own frameworks, were expressing frustration, like, you know, they were reading the docs and it says like, this is best left to the framework authors, and they're like, that's me!

[00:34:30] How do I do this? yeah,

[00:34:32] Mark: or library authors. Yeah.

[00:34:34] Carl: right, and you know, then I'm seeing people talk about like, oh yeah, I was, I, I spent a week, three weeks, months reverse engineering this and understanding it so that I could write something on top of it, and it's like, yeah, you know what, that's, that's a pretty big documentation gap if like a half dozen people are all reverse engineering stuff in order to do what is being advised, you know, they're trying to own it,

[00:34:58] Mark: seen a couple framework author kind of behind the scenes discussion groups and there, there is chatter back and forth and asking questions, but I mean, again, like a lot of that stuff would have been nice to see covered in public documentation in the first place.

[00:35:15] Carl: I guess maybe, maybe to close this discussion out, this is all like refinement. Like, I also want to highlight that as far as frameworks for building web applications, The React documentation is absolutely world class, and like, you compare it to its peers in the, you know, ecosystem, and like, both what it's trying to do and how well it communicates it to someone trying to learn is actually quite good.

[00:35:45] in my opinion, like, I, I think that there are many things that it does really, really, really effectively, and As, you know, pundits opining, we're seeking out the rough edges to focus on. I do just want to bring that in.

[00:35:59] Mark: I have huge respect for the React team. I have a very good understanding of the constraints that they deal with, both from having watched and talked to And then, you know, as a, as a maintainer of a widely used library myself, I, I totally understand, like, I just don't have time to sit down and document this.

[00:36:15] it's both the, the success that they've had, And the work that they've put in that makes a lot of these gaps and pain points all the more frustrating. And so it's not that they're doing a bad job. It's that the pain points really stand out.

[00:36:32] And a lot of them feel like self inflicted wounds that could have been addressed fairly simply.

[00:36:37] Carl: And, perhaps, because it has had such a vibrant, thriving ecosystem for so long, and so many phenomenal, wonderful, generous, talented individuals who are filling some of these gaps, Like, now that the momentum, now that some of the heat has gone out, like, you know, there was a, there was probably a five year span where a lot of the hype in tech was focused on React and now, you know, then there was like a kind of like, ooh, should we focus on Web 3?

[00:37:08] Like, ooh, is blockchain interesting? And there's like, no, no, no, actually, no. And now, like, that, that laser has Fully focused away from tech like React and more onto AI things. So I think that a lot of those individuals who were driven and talented and motivated and ended up filling those gaps are now doing other things.

[00:37:27] makes sense and it's fair, but it means that those gaps are not getting filled anymore.

[00:37:31] Mark: I have a lot more thoughts on this topic. I will not go through them here. However, I am planning to put up a very, very, very long blog post explaining a lot of this stuff hopefully within the next few days.

[00:37:43] Carl: I've read half of it. It's good. Okay. Moving on.

[00:37:46] [Revealed: React's experimental animations API - Motion Blog](https://motion.dev/blog/

[00:37:46] Carl: Somewhat small. We can maybe do this in lightning round, but too late. speaking of new developments in React, there is an experimental animations API taking advantage of the view transition, platform API On the web.

[00:37:59] Main PR

[00:37:59] Carl: Uh, It's currently unstable. It looks like it's going to be a view transition component that also comes with a little bit of ceremony around how to set state in order to make the transition aware that a change happened.

[00:38:12] But seems cool. I don't know if view transitions look great. And being able to easily tap into them when you're doing your react logic. Definitely here for that. Looks great.

[00:38:23] Mark: I still don't even know exactly what view transitions even are. I've been too occupied to have a chance to read about or learn them. Having said that, this also does feel like kind of a big deal. People have been griping about the lack of real animation support in React itself for years. There's been lots of, you know, community packages, Motion and React Transition Group, and A whole bunch of other things.

[00:38:48] and they've said that they wanted to get around to it eventually, but it really needed to be integrated into concurrent rendering behavior because you got to track multiple copies of the tree at once. So this does actually feel like a pretty big step forward.

[00:39:01] Carl: Yeah, and I used like React Motion Cheng Lu's library from many, many years ago which was great. I found that really cool and really powerful. I did some really fun, exciting things with that. the single most fun thing I did with that, I did a spotlight. Like onboarding tour for an app I built, where I did a custom SVG to cut a hole out of a, like, transparent, translucent overlay.

[00:39:26] And then I used React animation to, like, animate it, and so it would, like, do a, like, little springy animation around. And, like, it was performant. It was fast. It took me, like, three hours to do. So for me, user space implementations like that were like, cool, great, this is solved, I don't need to do this.

[00:39:44] And I don't need React to be more aware of this because this works great for me. I think that's part of the reason why they haven't brought anything in before this. And I think now there has been more of a, I don't know, general understanding of how animation should work at a platform level.

[00:40:01] And so They've been brought in as platform features to do like flip animations. First, last, interpolate, play. And so I think that's what view transitions are, but I'm in the same boat. I've read about them. I have not actually put them to practice in any real project yet.

[00:40:17] Static hermes update

[00:40:17] Mo: Let's jump into Static Hermes, because I think that one's quite interesting. So, we've talked about Static Hermes over the last few months a few times, but right before Christmas there was an update that went on by Tzvetan, who's basically really the person who's leading the efforts as far as I know, at Meta, and so people are kind of asking the question, like, when is Static Hermes actually going to come out?

[00:40:38] Because we saw it like years ago. It was super exciting. When is it coming out? And I think we got the first glimpses of hope in there. In the sense that in 2025, so in 2024, they say, next year they want to start to make it an opt in branch and maybe towards the end of the year, later in the year, at some point, make it the default React Native Engine.

[00:40:57] And one of the biggest hurdles that they face, which they seemingly have overcame now, is that There wasn't good support for un typed JavaScript and obviously there's gonna be a lot of un typed JavaScript in the world. Like the whole premise of static Hermes is that you use the types within TypeScript to be able to compile better typed code at a c plus plus level. And so this is a big step and it was one of the hardest sort of hurdles that they had and they've compared the performance. with different benchmarks and seemingly they are doing, you know, somewhere to the ranges of 20 to 60 percent better with a bunch of different benchmarks that they're trying.

[00:41:36] So it's quite cool and we'll see how it evolves, but I guess it's a very exciting update, whether or not that stays in practice and it'll be, you know, available at some point in 2025, we'll see, but you know, first glimpses of a supposed Timeline of delivery. So we'll, we'll see how that plays out.

[00:41:53] Carl: Yeah, definitely makes sense that untyped JavaScript is a major hurdle, like, yeah, it's a JIT compiled language. If you're trying to do a static compilation of it, that's gonna be tough.

[00:42:03] Mo: And it's honestly like super impressive what this team has been trying to achieve in itself. It's it's I don't think I have the capabilities to be able to, to dissect such hard problems. So kudos to them.

[00:42:14] Carl: And also, just to, like, carry in the tone from this, you know, Hermes update post, I love that it has this hero image of a, I'm gonna call

[00:42:21] it a flag that says "we do this not because it is easy, but because we thought it would be easy."

[00:42:27] Mo: I love that so much, yeah, that hero images. Tzvetan is a really funny guy, like a very like, specific sense of humor, I've met him a couple times at conferences, he's just, he's such a joy to be around.

[00:42:38] React Native Hosting with EAS

[00:42:38] Mo: I also want to quickly touch on Expo hosting, so this was announced a few weeks ago, and so, in sort of that light of, you know, there's Resell, which is the way that you host React applications or so called Next. js applications, I guess, mainly and you know, it's the framework that you use with the Expo world, obviously they are also kind of going into that footing of, we are the framework to use, and we also can host it because Expo is obviously going in this universal direction of, you can also use Expo and React native on the web and build full stack sort of across the board multi platform application on web and mobile and so obviously as part of that you're going to have to think about hosting where do you host the web applications and so they've launched EAS hosting which is their sort of first attempt at creating a hosting platform that will host your, you know, Web applications, but also your API routes, because if you remember from last year, we talked about Next.

[00:43:31] js's API routes that they had, and so very similar to Vercel's API routes, you've got Next. js's API routes now, I'm sorry, you've got Expo's API routes now. And so it's a very sort of basic hosting platform for now. It lets you keep a track of, you know, the requests coming in, your deployments, the crashes.

[00:43:48] And just some basic logging into your requests and so on and so forth. But I think it's, it's a, it's an interesting start and it's, you know, it's one of the pieces that they've been missing a little bit when it came to this universal story. So, we'll see how that expands, we'll see how it grows and evolves, but it's just the first and the early days of, you know, of EAS hosting.

[00:44:07] Carl: I wish I had more to say on Expo, because it does seem really cool, and I have really admired its development over the years, but man, I just, I don't, I don't need to make native apps. Maybe one day.

[00:44:17] as I'm charting my year in January I have a couple projects booked for the next couple of months, but back half of the year I might actually try and do like a fork of the Blue Sky plant, and that's Expo, so hey, maybe I'll get some real first hand knowledge

[00:44:32] Mo: very keen. I love the comment. Someone's saying, I wonder if Tanstack will launch their own hosting one day.

[00:44:37] Carl: That makes, yeah, that actually would not surprise me. Yeah, Mark you want to tell us everything we need to know about Node. js type stripping?

[00:44:44] Everything You Need to Know About Node.js Type Stripping

[00:44:44] Mark: Well, I won't, but I'll tell you about the post that does. So, like bun have TypeScript support built in, but it's basically been like, Okay, we read the TypeScript source code, don't bother type checking it, we just execute it. And so, you know, given TypeScript's popularity, Node has finally jumped on the bandwagon and some of the latest Node releases actually integrate some tools that will do the type stripping so that TypeScript syntax code can at least run directly in Node without needing an additional tool like the TS Node. And, the big thing about this is that because they're stripping the types, they're not doing type checking the output also needs to be, like, your TypeScript code needs to be just types. Now you might think, well, it's TypeScript. Of course, it's just types. The problem is that some early TypeScript features do also result in additional runtime code being generated.

[00:45:43] For example, when you use the enum keyword in TypeScript, it results in an object lookup table being added. And so because Node is just stripping the type syntax, if you try to use an enum with this new Node feature, it'll actually break things. So, I believe one of the upcoming TypeScript versions will actually have a flag that will enforce that you're only using type strippable syntax, but Big picture what this means is that it'll be easier to take, like, a node script that is written as a ts file with ts syntax and just say, like, node myscript.

[00:46:25] ts or whatever. I don't think you have to pass in any additional arguments. So overall, it's, it's basically like matching the feature set of other tools like Bunn and making it easier to use TypeScript code across the ecosystem.

[00:46:38] Carl: yeah, I am trying to quickly refresh my memory here, but I believe that I am actually using the strip types. No, I played with it but I found a different way around it. Yeah, I did, I did it. This is a feature I got to play with. I have first hand experience with strip types. It was pretty good. But yeah, there's still some weirdness around, like, type extensions, I think, in imports.

[00:47:02] Mark: That does not surprise me.

[00:47:04] Carl: I know, in trying to play with it, I had to do a code mod in order to add extensions, you know, like js extensions everywhere, and yeah, I know, I think a couple of episodes ago, we ended up talking, we talked a little bit about TypeScript, Faking what extensions it would use in order to make that work for compatibility reasons.

[00:47:25] And so yeah, I got some first hand experience and it's weird. It worked. I got it working, but it felt weird to have, you know, to be authoring a ts or tsx file and importing it as js. That's definitely unintuitive.

[00:47:41] Mark: complicated but valid technical reasons why they made that stance.

[00:47:45] All right, Mo, I know you need to drop off shortly. Any other points you want to cover before you head out?

[00:47:49] Mo: no, I think it's been a relatively quiet React Native month and I've been completely off the grid.

[00:47:57] Composable Caching with Next.js

[00:47:57] Mo: The only thing that I am quite keen to talk about actually is the caching with Next. js, our little composable caching. Because I've been dealing with Next. js caching for the last two weeks and oh boy, oh boy,

[00:48:10] I have been trying to, after dealing with the Pages router for a very long time I've been now dealing with Next. js caching for a little bit, and this use cache is obviously something that's more in canary at the moment. It's not published in, in sort of the, the stable versions, whatever that means in Next world these days, in terms of a stable version.

[00:48:32] But, Basically, the caching is a little bit complex with Next14, as we know, and currently, if you want to cache things like database responses in server components, or you want to cache fetching, you have to wrap it in an unstable cache function that takes in the function, a promise, some key, and then some revalidation time.

[00:48:56] And so, there's this really weird syntax to do this, and then of course there's also another level of caching when you have static pages, which means those static pages get cached after they're published. Built in whatever capacity. And there's just so many layers of caching at this point. It's hard to wrap your head around how your application is functioning.

[00:49:16] And to make matters more confusing now, there's this use cache directive that they're planning on introducing, which looks really cool, but I can just imagine this getting ever more and more complicated. And to me, a real symptom of this is the fact that they've 180'd on the defaults of caching with Next 15.

[00:49:36] Like, you've set some definitions on what is cached by default, what's not cached, and it went so poorly that you had to flip it 180 degrees. That does not give any semblance of stability to me as a consumer of the technology. And so I just look back at the days of the Pages router and wish we could just go back to the simplicity of having and getServerSideProps and just live life in that naivety of how simple that was.

[00:50:06] Carl: I was thinking in similar directions and I'm actually now in a position where I'm maintaining a React Router v7 project, which I upgraded all the way from Remix 1 to React Router v7 in one go, or in one go, sequentially all the way up. And the, the Reactaflux website is I think it's a Next 14 Pages router app, so that one I could probably play with a little bit more.

[00:50:35] But it's like, oh, I'm now actually maintaining apps on several of the largest frameworks And you know what? I like Remix the best. It's just got, like, the, the mental model is most familiar to me. It seems most predictable. And, like, I hate magic. I am someone who completely avoided the entire RWBY ecosystem because it's too magical.

[00:50:57] I'm just like, man, Remix hits right for me. not much there. Just yeah, it feels good. I don't know. I like it.

[00:51:03] Mo: I've used Remix as well, and I must say, like, It takes a little bit of adjusting from when you've just dealt with Next. js for several, months and years, but is just simpler. Like it feels more native webby, the bits of magic are really just like the loaders, the actions that you have, but like everything else just feels sort of you're dealing either with React or you're dealing with the web.

[00:51:24] And I quite like that as a concept.

[00:51:27] Carl: Right.

[00:51:28]

[00:51:28] Carl: it lets me think in terms of like, HTML, HTTP, and like, cookies. And like, yes please, let me think about the platform and not the toolchain. Yeah.

[00:51:39] Mo: And someone in the chat, one of our listeners, is actually pointing out that the app router is still defined as the bleeding edge of on the React install docs, basically, on start a new React project.

[00:51:51] Carl: definitely some bleeding happening.

[00:51:53] Mo: So yeah, that was my little, my rant.

[00:51:55] Carl: . Cool. Yeah,

[00:51:56] Thoughts on What RSC Means for SPAs

[00:51:56] Carl: Mark, next link up is like thoughts on what RSC means. did you read that? Can you talk about that?

[00:52:02] Mark: Yeah, I, I skimmed it a bit. So it's a, it's a post from Dedo who worked maintains Sten, created Jota and Tio and has been working on the, the Waku RSC based framework. So it's a couple different points. One is, can R RSCs actually relate to single page apps? And the answer is sort of maybe yes.

[00:52:25] Like, you know, for example, the RSC payload could be served statically. And not dynamically generated on a server. it's actually kind of a, kind of a short read, but you know, just like some, alternative thoughts from just like, RSCs are on the server and, you know, can only be used with Next, et cetera.

[00:52:42] So it's short, but worth reading.

[00:52:44] Chrome's 2024 recap for devs

[00:52:44] Carl: last main content article Chrome put out a 2024 recap. That was just pretty good. I don't know. Some of it, I'd call it like 30 to 40% marketing fluff.

[00:52:55] They spent a lot of time talking about how they added AI to the chrome dev tools, which I actually have heard some positive things about, like interpreting errors. Like okay, yeah. Neat. But yeah, I noted that it called out view transitions, which just 'cause we talked about it earlier in the episode.

[00:53:09] Like, hey, look at that. platform and react in unity in sync. I think we'd mentioned this before, but there's a CSS popover and like anchor positioning. So you can do popovers without JavaScript, which. I have implemented popovers in so many apps, and I hate it. I am so tired of it. Like, I do not use popovers anymore because I'm so tired of making them.

[00:53:33] So, being able to do it without crazy layout logic in JavaScript sounds great. Maybe I will actually use them again.

[00:53:39] Shoutout webstatus.dev

[00:53:40] Carl: And I also learned about a new site recently through reading that, webstatus. dev, which has a, like, annualized baseline browser feature summary, which looks neat. Although I'll note that, you know, we're into 2025.

[00:53:55] We're a month into 2025, and the 2024 baseline is not met. Like, yeah. Safari looks to be generally the worst offender, But, Firefox and Edge also, slipping behind a little bit. Well, no, maybe that's not fair, because Firefox is ahead in a couple of them, ahead of Chrome in a couple of them. So, anyway, this is neat.

[00:54:14] I love these kind of like, broad based what features Are being implemented. this is how I have always kept an eye on what's coming down the pike. So, didn't know this existed. Cool. Useful.

[00:54:26] Redwood.js shutting down?

[00:54:26] Carl: I don't have a link for this, but I've heard, through the grapevine, that there will be some impending announcements from Redwood.js generally the shape of what I've heard is that like an original found co founder of the project who had kind of left or like gone dormant came back and has decided that I I don't know what is going on I read some like Google translated slack messages from I believe Swedish and it sounds like a co founder has come back out of the woodwork and basically taken over and Just said like This is good SEO.

[00:55:01] This, there is value to this domain, this brand. It's mine now. I'm going to do something entirely different with it. So yeah, keep an eye out. Redwood.

[00:55:09] Mark: Another way to phrase it is it sounds like Redwood the framework is dead and the name and repo are going to be repurposed.

[00:55:19] Carl: that's the shape of what I've heard. I think I heard that they will be doing an announcement in the next month. So like, ooh, breaking story, our first one, but, ah, it's just such a shame because I, I've met them at a conference or two, they seemed really good, and I liked the general, like, like, I understood them as trying to do Laravel for the React ecosystem, and I thought that was a pretty good niche, so, just a shame.

[00:55:45] Shame to see it die to some drama like this. But yeah, there should be some more details, maybe we can talk about it maybe we will have some, you know, perspective to give

[00:55:55] this month.

[00:55:56] Mark: next month.

[00:55:56] Carl: Actual details, not screenshots of Slack.

[00:55:59] A checklist for your tsconfig.json

[00:55:59] Mark: Axel Rash Meyer has done a lot of articles over the years about like, what's new in this year's version of the, you know, the, the ES language spec. He's also been writing some articles recently about some TypeScript related things, like different ways to define a NUS or similar things. And he put up a post call a checklist for your TS config, JSON, which walks through and actually like, looks at a lot of the config options and what they do and when it makes sense to use a lot of them.

[00:56:27] pretty sure that Matt Pocock has done a similar post somewhere.

[00:56:30] Recoil repo archived

[00:56:30] Mark: completely different note We talked about Redwood maybe kind of going away. The recoil library repository has been officially archived. Now, it had been unmaintained for a while. I had read from people who had been involved that apparently both the people who had been maintaining it had gotten caught up in layoffs from meta.

[00:56:52] So, But, honestly, it also seemed as though the project had stagnated for quite a while. The thing that gets me, really, is that when Recoil was first announced whenever that was, like 2017, 18 ish there were just so many people who looked at the announcement and took it as Oh look, this is an official React State Management Library.

[00:57:19] When in reality it was just some other app team at Meta came up with their own solutions and decided to publish it. But, you know, the combination of Redux backlash, and like, It's from Facebook, it must be official! meant that a lot of people jumped on it, and then it sort of stalled, and then Jotai came out, and Recoil just sort of went away.

[00:57:45] Carl: Sad to see stuff drop

[00:57:47] Bun: first-class support for s3

[00:57:47] Carl: Alright Bun is shipping first class support for S3, which is interesting. So, first class support for S3 here means being able to use it as like a file system, I guess. standard library tool for implementing Or for interacting with file storage services that themselves implement the S3 API, which is pretty widely supported.

[00:58:11] So this is actually pretty interesting because, like, I don't know, I hate dealing with, stuff like the AWS SDK. I've, like, partially avoided learning AWS because it's just so complicated and annoying. So seeing some little details like S3 interactions being brought into the runtime is actually pretty neat.

[00:58:32] Yeah. I'm seeing in the chat, there's a lot in that 2 announcement. Sadly, I don't actually use bun in my day to day. So I am just kind of an observer here and I have not stayed super up to date. Just that caught my eye as like, Oh, interesting. What an opinionated stance.

[00:58:48] Interpolate auto height for animations

[00:58:48] Carl: There is now, I believe in the latest Chrome, there is an interpolate size CSS property you can set on like high up on your your page to allow interpolating allow animations to interpolate between Auto, like if you say height auto and height zero. Previously you couldn't animate between those two states.

[00:59:11] And now, You can in latest Chrome. That's super cool. I have always thought it was super weird that that extra step of just letting your size, letting the size of an element be automatically determined meant that you couldn't use CSS transitions. That just never made sense to me. So it's, it also doesn't make sense to me why it took 10 years from me feeling, oh, that's weird, to this actually shipping, but super cool.

[00:59:37] Neat. Love it. I believe it's currently Chrome only, but yeah, I mean, hopefully it'll, hopefully it'll filter out pretty quick. He says, after complaining about waiting 10 years.

[00:59:47] Free javascript; Oracle not voluntarily releasing

[00:59:47] Carl: And a small, extremely small update to something we discussed previously, the Deno organization's campaign to get Oracle to free the JavaScript trademark.

[01:00:00] Oracle has Declined to voluntarily withdraw the trademark. So Dino is doing legal things to advance the process. This is a legal drama. So this is probably going to be something we're still talking about in like 2026. And I would not surprise me if it's like 2030 before the trademark actually, like before this case settles, let's say.

[01:00:23] But yeah, neat. Maybe I'll stop giving updates, but Oh God, it would be so nice if Oracle did not own JavaScript.

[01:00:31] Understanding React Server Components | Tony Alicea

[01:00:31] Mark: All right, and last one Tony Alicea is an educator who has written some very, very good deep dive blog posts into some things like React rendering, which is a topic I care deeply about, so I appreciate that and he recently put up a post on understanding React server components.

[01:00:48] Now we've, we've mentioned a lot of different dive into server components type posts over the last couple years. This one walks through a lot of how server components fit into the rendering process, looks at some of the actual JSX related data that is serialized and sent back and forth, and talks about how it then fits into things like streaming and bundlers and hydration.

[01:01:12] So it's not something you would read to understand, like, how do I use a server component? But it's a really good explainer that, you know, how digs through a lot of the technical aspects and talks about why server components work the way they do.

[01:01:26] Carl: Yeah. Oh man. Wouldn't it be cool if this was put out as like a guest post on the React blog?

[01:01:32] Cool. Okay. That's all of the links we have for you this month. Thank you for our persistent listeners who stuck with us all the way to the end. Yeah, we'll be back on the last Wednesday of February next month or in this episode, we'll be back in your podcast feed just as soon as we can. Thanks so much for listening.

[01:01:50] Mo: Lovely to be here with you all again every single month. it's always a pleasure. Thank you, Mark. Thank you, Carl Thank you to everyone who's listening in and see you all in February

[01:01:59] Mark: Yep, thank you, appreciate it. And if you want to stay up on the current drama that I am involved in in the React ecosystem, please follow me on BlueSky or watch for my upcoming blog post within the next few days.

[01:02:13] Follow us on Bluesky!

[01:02:13] Carl: Oh yeah, we can follow, you can actually follow this podcast on BlueSky too. We are tmir. reactiveflex. com and I'm going to put a link in here. Cause you know what? I should do that.

[01:02:23] We gather sources from thismonthinreact, bytes. dev, reactstatus, nextjsweekly, the reactjs subreddit, here in Reactaflux from the techreadsandnews channel, and sometimes even directly from people publishing content.

[01:02:38] If you see anything that would be useful for us to discuss or just that you want to share with the community. Definitely pop it in the Tech Reads the News channel, or if you like, you can send it to hello at reactiflux. com. I will read literally anything you send to that. So, yep, go ahead. If this is a show that you get value from and want to support, best way to do so is by submitting a review, wherever you listen, or tell people about it.

[01:03:02] It's great. Help us grow. Woo!