TMiR 2025-04: React 19.1 helps debug owner stacks

Transcript from Thursday April 24th, 2025

Carl: Thank you for joining us for the April edition of this month in React, where we recap and digest the recent developments in the ever-evolving reactive web ecosystem. [00:00:07]

We are coming to you live from Reactiflux, the place for professional react developers, and we are supported by Infinite Red, a consultancy that works exclusively in React Native. I am Carl. I'm a staff product developer and freelance community manager here at Reactiflux, where I do community programs like these and build tools to help keep the community operating. And I might oversee a hackathon next month. So yeah, keep an eye out. [00:00:30]

Mark: I'm Mark. My day job is working at Replay io and in my free time I spend entirely too much stuff and time working on Redux and griping about the React docs. [00:00:39]

Mo: And I am Mo, I had the mobile team at Theodo. And I am an active member of the React Native ecosystem and organized the React Native London Meetup and the React Native London Conference. Happy to be here as always. [00:00:51]

Carl: Heck yeah. [00:00:52]

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

Carl: Very quick overview of job market stuff. I found a new data source that I don't know how I hadn't heard of it before 'cause it is not super new. trueup.io has a job trend page that looks pretty good. similar but distinct from layoffs.fyi. [00:01:05]

They are saying that there's been a little uptick of open tech jobs. But you know, there's also been a bunch of layoffs. Although this month most of the layoffs are coming from Intel, which yesterday had a bunch of reports filter out saying they're gonna lay off 20% of staff. [00:01:23]

But like 20% of staff in Intel probably means a lot of manufacturing jobs, not like software tech. So I don't know what that means, but yeah. I don't know. Vibes are still bad. One thing I like about TrueUp is that they have a, like remote index where it estimates what percentage of available jobs are remote friendly And that has been trending down, sadly. [00:01:45]

It's slightly sub 20% right now, which is, not great. Yeah. [00:01:50]

Conferences (React, Javascript)

Carl: So upcoming conferences in May! [00:01:53]

App.js Conf May 28-30 KrakĂłw, Poland

Carl: At the end of May, May 28th through 30th in Krakow Poland, we have App.Js conference [00:01:59]

CityJS Athens May 27-31 Athens, Greece

Carl: . There's also City JS Athens around the same time. May 27th through 31st. [00:02:04]

React Summit June 13-17 Amsterdam, NL

Carl: Then in June we've got a React Summit in Amsterdam. [00:02:09]

React Conf is back Oct 7-8

Carl: This is very early, but the React core team has announced that React Conf will be back this year. last year. It was when I was in May. this time last year I was in Vegas for that, but yeah, they're doing it you know, mid-October. So that's cool. [00:02:22]

SquiggleConf 2025 CFP closes May 23

Carl: there's an open CFP that closes one month from now for squiggle conf, which I am on staff for. if you would like to maybe speak at a conference. It's a great conference. I love it. It's organized by a, you know, a good buddy of mine. Yeah, definitely check that out. [00:02:37]

Carl: And of our sponsor read, we are sponsored solely right now by Infinite Red, which is an expert React native consultancy that's been around since 2015. [00:02:46]

They're our only sponsor, partly because very few companies do as much as they do for the whole React and React native ecosystem. They host podcasts. They run conferences, they sponsor all sorts of different organizations generally just seem like really great people. They're a team of about 30 people, mostly developers, mostly with more than 10 years of experience. [00:03:06]

And they will work with your team to help you develop react native expertise rather than just doing contract engineering and then saying, here you go, this is your problem now. So if your company is looking to start working on a React Native app in the near future, definitely reach out to them and give them a shout. Yeah. Cheers. [00:03:24]

New releases

Carl: Okay, running through some new releases. [00:03:27]

Anime.js v4

Carl: This is only tangentially react related, but anime js a animation library, or they describe it as an animation engine. Just had a V four release and the website is super slick. Definitely a phenomenal advertisement for what you can do with the tool. [00:03:46]

Very impressive. And animations are always, I don't know, doing high level animations with like a bunch, you know, interactive and different layers, and it, it's always complicated. So this looks like a pretty great tool. So wanted to give it a shout out. Yeah. Mo, can you tell us a bit about the latest React native. [00:04:03]

RN v79

Mo: react native version 0.79 has been released. There's. Sort of some small changes here. The big one is that the JavaScript engine, JSC that previously used to be the default is now actually being removed completely from react Native Core and being moved to a community package and is effectively really being deprecated. [00:04:21]

The few other changes some improvements to performance with Android, but all in all, as we'll see, and as we've seen in the past few months with React native releases, they're getting slimmer and a lot more frequent. So this whole idea of sort of continuously releasing React Native rather than having a few Big Bang releases, so good to see that it's chugging along. [00:04:40]

Carl: Yeah. Very cool. I saw this is their third release this year, whereas in the past , they've generally done like three releases in any given year, [00:04:48]

Mo: I think the trend is going towards doing a release every two months or so. [00:04:52]

Mark: That's a pretty solid cadence. [00:04:54]

Mo: Yeah. I think they've really taken a lot of steps over the last two years to try to bring down that release time and it's starting to pay off. [00:05:00]

Next.js 15.3

Mark: Next 15.3 is out. Biggest news for this one is they now have alpha level support for using the turbo pack bundler for production builds. Previously, it had only been available for dev mode. So it looks like there's alpha level version for that. they have it passing most of their tests, but it's apparently not ready yet. [00:05:20]

Rspack joins the Next.js ecosystem

Mark: Also 15.3 now has support for optional using the third party RS Pac Bundler. I. For builts RS Ppac is a rust based re-implementation of Webpac and basic compatible with web pack's configs. So given that the existing version of Next still uses Webpac under the hood, the next and web and RS Ppac teams were able to collaborate and figure out how to get a plugin that would essentially allow it to use RsPack instead of Webpack as one possible alternative way to try to speed things up. [00:05:55]

Carl: Yeah, I did see that the performance improvement from using RsPack and Next is like not that great and like in some circumstances could actually be worse than Webpac, which seems confusing to me. [00:06:07]

Mark: some of it was due to things like JS based plugins and, and some of the, the interrupt back and forth between. Uhland and JS land. [00:06:16]

Carl: Right. I mean, hey, similar problem is how React Native had with the, parsing data back and forth. kind of goes to show you how even once you have a tool that is written in native, it's, you know, it's not a silver bullet. It doesn't fix all the problems. [00:06:29]

React Aria April 11th

Carl: Yeah, react Aria by Adobe had a release. [00:06:32]

They don't, I guess they don't do versions, they do just date releases. So this is the April 11th release. One thing that caught my eye that I thought was pretty interesting, so they have a calendar tool and they now allow custom calendar support. So it lets you implement your own like calendar schedule in re rendering this calendar thing, which, you know, they, they shout it out, for instance, using a 4 5, 4 fiscal calendar, which I had to Google because I'd never heard of it. [00:07:01]

So this seems like a very, like, deep in the weeds kind of feature edition for, I don't know that that goes to show how seriously they are exploring the problem space. And I, I take that as a pretty positive sign. [00:07:13]

Redux Toolkit 2.7

Mark: Last week I shipped Redux Toolkit 2.7 as I was on my flight to React Miami. [00:07:18]

the main feature outta this is that RTK query now supports use of standard schema definitions for both validating requests and responses and errors, as well as potentially inferring the TypeScript types for those errors so that you don't have to hand rate those when you're defining the endpoints. As well as a bunch of other, other bug fixes and improvements. [00:07:41]

Carl: That's super cool. I love generated types. [00:07:44]

Vitest 3.1

Mark: And then Vitest 3.1 is out. Doesn't look like there's a, a huge standout feature, but a, a bunch of, again, small fixes and performance improvements, obligatory. [00:07:55]

Main Content

Carl: Yeah, into our main content. [00:07:57]

React Labs: View Transitions, Activity, and more

Carl: So conveniently, like 35 minutes ago, the core team put out a new blog post a new React Labs post. React Labs are posts where they write about projects in active research and development. So this is like, definitely, this is like, you know, leading edge. What is the core team working on? [00:08:14]

They do like what, maybe two of these a year? [00:08:18]

a solid year since the actual React Labs post. They did have like the, the React 19 release announcements in that since then, I. [00:08:24]

Carl: dated React Labs, March, 2023, react Labs, February, 2024, and now April, 2025. [00:08:31]

Mark: So the headline out of this one is that they have been working over the last few in couple months on official support for the browser view transitions. API now. Going backwards. A lot of folks have asked over the years for some kind of official animation support in React itself. I know that people have compared, versus something like Svelte, which has apparently has the ability to declare some animations directly in your templates. And they've pointed at React and said like, why can't I do the same thing? Or like, you know, animating elements in and out is, is really, really difficult. And there's been lots of, you know, different animation libraries for React over the years, react Transition Group, react Spring, et cetera. But this is the first time we've ever had anything related to animations baked into the React core itself. Now as usual, I'm not actively ready in a lot of React myself these days. And when I have, I've never done anything animation related, so I'll be honest. I still don't even fully know what a view transition actually is, but I see a lot of people really, really excited about it. My, my vague understanding is that it's taking elements that are within the page and being able to move them back and forth. [00:09:46]

Carl: As far as I know, it's largely about like page transitions, like when you navigate it will let you emulate like the kind of a native style of like, oh, this new, you know, new pane slides in over top [00:09:57]

Mo: I mean, there, there's a few different types of transitions. There's like a fade transition that's native sort of there. But there's also the, the one that you're referring to, I think Carl, is the shared element transition, which is you have one element that exists on the first page and then the second, that element kind of persists, changes shape. [00:10:13]

So the best example of that is like Instagram when you open up a a post and it kind of expands to take up the whole screen. That's what we call shared element transition in the mobile world. [00:10:22]

Mark: Yeah, that, that makes sense. And I can definitely see how something like that would be difficult to do in React, where, you know, normally you stop rendering A and you start rendering B. [00:10:32]

So the React team has been working on an official actual view transition component which has a number of different. Pieces of functionality, being able to, to label the transitions animate navigations, do some customization of these behaviors. the blog post goes into some examples of what these different capabilities are and how you would actually try to use them in practice. So it is still experimental. You have to specifically switch over from a production stable build of react to using the latest experimental channel release. But it's gotten to the point where they think it's actually ready for folks to try out. [00:11:09]

on a similar note the React team has been working on and off for the last three or four years on a component that they originally called off screen. And the idea for this is that, as we all know, when you unmount a React component, everything about that component goes away. The effects are cleaned up. [00:11:27]

The state that was unique to that component instance goes away, and that's made some things like, you know, building tabbed UIs difficult because you either have to do some work to hide the other tab contents, you know, maybe using like display none in CSS. But, and or you actually have to unmount them. [00:11:49]

But in that case, state that was there goes away. And so the intent of this offscreen component. Was that you could wrap it around a section of your UI and you could tell React to toggle the display, but it would keep those components around and preserve their state. And then when you make it visible again, everything's still there. So they have since renamed this to be called the activity component. And they've also, and so now that is all at a point where it's officially ready for trial in an experimental form as well. And I think this is actually gonna be kind of a big deal. , we've actually used the predecessor offscreen component in replays UI for a while, which is why we're stuck on an old experimental build of react. And it, it really does prove pretty useful. [00:12:37]

Carl: this like scratch an itch in the back of my brain because it, I, remember talking about this previously, so I was just googling like the, you know, offscreen and oh my God, like they've, they've been talking about this in both of the last two labs posts that we just mentioned. [00:12:50]

So like, you know, they've got a tab called offscreen Rendering in 2023. "Offscreen rendering is an upcoming capability and react for rendering screens in the background." Like, okay. Alright. So they've been looking at this for over two years, I guess. It does seem really useful. Like I have definitely used every trick in the book to make things, you know, deprioritized. But yeah, I'm a little surprised to see that this is still in progress [00:13:16]

Mark: The other two interesting bits out of the blog post about this, and they were not things that I, I had thought about in relation to this component. Another use for this is that if you start off with the activity labeled as Hidden, React will pre-render that content even before it's been displayed at all. But using concurrent capabilities, it'll be done in the background. So this can be useful for, you know, maybe you have like a more expensive piece of the UI that you know will be shown eventually, but maybe it doesn't need to be part of the initial render. And then that also ties into SSR capabilities as well. [00:13:54]

And based on the initial value, react might like, include it in the content and then hydrate it later, or, do it in the background. And they also mentioned the possibility of adding some additional modes to this. Right now, currently it's, it's an nu that is just hidden or visible and they may actually have some other alternative behaviors down the road as well, which is why it's not a bullion. [00:14:16]

Carl: Yep. Love flags rather than Boolean. That's great. Yeah. Interesting. I guess. I guess I'll keep an eye on it, but like, man, I guess I've been keeping an eye on it for two and a half years now. [00:14:24]

Mark: The post covers a few other things. There's some performance tracking stuff they're working on. They are talking about trying to have the compiler automatically insert dependencies into use effect dependency arrays. there was one phrase in there in the post that I thought was kind of understandable, but also slightly oddly phrased. They, they gave a classic example of like a, a chat room connection in a use effect. they had a sentence to the effect that " Some hooks can be hard to think of in function instead of life cycles, developers get confused," da da da. " We think one of the reasons for the confusion is that developers think of effects from the components perspective, like a life cycle instead of the effects point of view, what the effect does." [00:15:10]

And it basically what that's trying to say is. You know, the, the entire Rack React community looked at the use effect hook when it came out and we said, ah, this is the replacement for component. Did Mount and Component did update from class components to the point that, you know, often people even even create their own abstractions with those names. [00:15:28]

I. And the React team has been valiantly trained to get us to stop thinking in those terms for years. And so I think this paragraph is basically saying, we've been trying to convince people not to think this way and failed. But it also like, it's, phrased slightly, like they're almost surprised. [00:15:45]

People still think of it that way. [00:15:47]

Carl: Yeah. it feels like a documentation problem. I feel like so many people are learning, react from a mishmash of strange places that they're learning, not what the core team would like. And you fix that by writing really good docs. [00:16:00]

Mark: So anyway, the ul ultimately they're trying to work towards making the compiler be able to insert all those dependencies for you, and then maybe someday we get to stop thinking about this entirely. [00:16:08]

They are also working on an early version of a compiler ex or extension for IDs, which has the potential to act as maybe like a super winter or show you what the transformed component might look like or even like what dependencies it would insert into use effect array automatically. [00:16:29]

A couple other tidbits. And then one, the last item is very short, but as a library maintainer, it caught my eye. We all know that React has component-based state and that this has the strength that it's isolated to that component and the portion of the component tree, it has the weakness that you can't easily share it across different portions of the component tree. And we also know that Reacts concurrent behavior really only works with state that React owns, which is why external libraries like Redux and Zustand rely on the used sync external store hook, which works, but also kind of forces react to give up on doing things like transitions in the most optimized way. [00:17:13]

So they've talked on and off for years about what if we were to add some sort of like a reusable store primitive to react. there's discussions about this going back to like 2015 and the blog post hasn't mentioned that they are working on something called concurrent stores. And it gives sort of a one line example that you would pass this to the use hook, and it does say, our goal is to allow external state to be read during render without caring and to work seamlessly with all the concurrent features that React offers. There's no further details. It's something they're just starting to think about. But it sounds like maybe down the road, react-redux and Zustand could use this and still work the same way, but better without the limitations. I don't know. I'm interested. I. [00:18:05]

Carl: Right. I've never used used sync external store, partly because of the warnings they gave of like, this is gonna break stuff. So yeah. That's interesting. That's cool. [00:18:12]

I'll also shout out, they mentioned, two other things very tangentially, like, we are looking at this, or we intend to look at this. [00:18:21]

I'm curious about fragment refs. So like, you know, if you want to get a reference to the underlying dom node and react, you can do that with a ref. And you can use fragments to group elements, as a single top level rendered item rather than like wrapping it in a diviv or something like that. [00:18:35]

But you cannot grab a reference to that group of nodes. But now they're looking, they "intend to research" refs on node groups like that, which is definitely interesting. I could see that being valuable in something like rendering a table or a list of something else. [00:18:55]

Like especially if you're trying to do drag and drop kind of things. I could understand why being able to access a reference to a list of rendered nodes might be useful. But yeah, so I, I'm, I'm curious about that, but also given how long we've waited for some of these other things that are being researched with maybe clearer use cases, I will not be holding my breath on that. [00:19:17]

Mark: will say that I've, I've watched them put up and merge several prs that are input, are trying to implement fragment refs. So it's, it's definitely not just a theoretical research project. They're actively trained to work out the implementation deals and details. At the moment, [00:19:33]

Carl: That makes sense. Yeah. [00:19:34]

Likewise for gesture animations gestures are generally just like a pain in the butt. I have never found anything that worked super well for that. So they say we're researching ways to enhance new transitions to support gesture animations, such as swiping to open a menu or scroll through a photo carousel. [00:19:50]

That's cool. I will be excited to see if they get something working there. Just 'cause gestures are always annoying and part of why they're annoying is because it's such a, I don't know, they're just very far from like the rendering model. The way you have to think about gestures is very far from the way that React asks you to think about rendering a tree of components with like, self-contained state. It's just like fundamentally outside of a component. It's at the level of the browser, the device. [00:20:17]

So, figuring out a way to, I don't know, reduce the distance between those is definitely interesting and sounds valuable and useful. But they also say for now we're focused on shipping view transition and we'll revisit gestures afterwards. So this definitely sounds a little bit more like intent to explore than active exploration. [00:20:34]

They say they, they also say, we believe we found an approach that works well and may introduce a new API. So cool. They've done some research, they've got an idea, but it's not their immediate focus right now. [00:20:44]

Mark: the other sort of big picture thing that I took away from this post. So there's been a lot of. Complaints and concerns from the community over the last couple years that the React team kind of stopped caring about the client side. That, you know, all their effort was going into building server components and pushing people towards frameworks and all this other stuff, which I. There's definitely been a push. The React team has noted that part of it is just how much, how hard everyone went in on single page apps over the last several years, and so there, there has been a swing back towards server-side rendering and ess, but even like React 19 had a bunch of client-centric features for, for forms and whatnot. it is interesting that basically all the things that they've got in this blog post are client side pieces, you know, view transitions, activities compiler stuff. Sort of there is a real focus on stuff that works on the client and adding like fairly meaningful core level functionality to the library itself. And so I think this actually kinda counterbalances some of the concerns people had that, you know, they were focusing on the server too much as well as noting that, okay, like, okay, now that the big React 19 push is done, now they've got some room to actually pick up with some of the features that they were trying to work on. [00:22:04]

React 19.1

Carl: Let's move on to React 19.1. [00:22:07]

literally the headline in the post itself is the owner stack. They're introducing development mode only stack trace to help identify what components are rendering, which. And this really brought the, the whole concept of the owner staff back to mind for me. [00:22:23]

Like this was something that I remember learning about and thinking about, thinking in terms of a lot in the first several years that I worked with React. And I think it's been slightly deprioritized in people's minds, like it's lost mind share. But it is super valuable for a ton of different things. [00:22:41]

So surfacing it better in the developer tools and such I think will be really powerful. I wanted to bring in a couple of like, old, old, old posts that I remember reading and remember being, you know, instructive for me. [00:22:53]

One React mistake that's slowing you down

Carl: Kent C Dodds, put out a, you know, one react mistake that's slowing you down blog post a while back and it talks about like component composition and like how you structure the tree and it doesn't name owner stack. [00:23:07]

I So it doesn't name the owner stack, but like really that's what it's talking about. It talks about like, you know, context and like prop drilling and how you can avoid it and why it's painful. And really what they're talking about, what Kent is talking about in this post is mindfully managing your owner stack. [00:23:23]

Because the reason you have to prop drill is because the owner stack is weird and you need to go through intermediate components between data source and data usage. But if you restructure that owner stack so that you're, instead of passing a prop through one component so that it gets rendered in another component rendered by that component, you can just render children and then you don't need to pass the prop through. You just render them all at the same level. [00:23:52]

Or, you know, you maybe not all at the same level, but you can collapse that you can make the tree broader and shallower. And prop drilling is like a developer experience, you know, convenience. It's nice to not have to remember, you know, if you think about it as like the length of a pipe, it makes the pipe a lot shorter and you, you know, there's fewer places for things to go wrong and you have to think about fewer twists and turns. [00:24:13]

So like, that's great. But also a flatter, broader owner stack is just naturally good for performance because when you have a deep tree, something at the top re rendering will cause like everything to re-render underneath it. Whereas when you have it flatter and broader, then just you can re-render in smaller batches, like smaller units of components will be forced to re-render when things [00:24:39]

Mark: I will caveat that one. [00:24:40]

So rendering does work at the direct parent child level. So like if I have parent component, I. Inside of its own JSX, it renders a child of A, and then it inserts B as children inside of A. So like both the tag A and the tag B are inside of parent. There is still a three component level parent-child relationship tree. So root is the parent of of A, A is the parent of B. But the root is the owner of both A and B. [00:25:19]

There's still three levels of components that have to get rendered, but it does flatten , the logic needed to generate those. And that's kind of like , the distinction that a lot of people haven't quite seen as they're learning. [00:25:31]

Carl: Right, right. I guess let, yeah, maybe I'll, I'll revise that a little bit. So it's at that root level, if the root level component is re rendering, sure. All of the children still need to re-render, but the deeper the tree, the more parents that're in the loop there are. So this has been like moving components so that it's, the owner tree is flatter, has been like the number one, general approach I've done when there are performance problems in a code base, , which generally comes from, like, you can think in smaller units. I don't know. feel like I'm going deep in the weeds and not stating anything clearly. [00:26:07]

Mark: generally speaking Composition is a good thing that more developers would benefit from taking advantage of. [00:26:12]

Advanced React Component Patterns

Carl: Yeah. Another, old, old old post that I'll just shout out. Uh, again had a phenomenal post from 2017 talking about advanced react component patterns and like, okay, some of these are no longer like super duper relevant anymore, like higher aortic components. [00:26:27]

Like, hmm, probably just use a hook. But these types back in this era of blogging about React stuff like owner stack was a little bit more, closer to the surface, it was still not on the surface. People are not referencing the owner stack. But yeah, just like when. I feel like owner stack is secretly the other option when people are talking about like prop drilling versus context like, well also what if you just restructured it so it's simpler? [00:26:52]

Mark: Yep. [00:26:52]

Carl: Anyway, super cool to see it surfaced. [00:26:54]

Improvements in Expo using owner stack

Mo: one of the things that this owner stack, change is actually powering is some updates to the expo CLI for when you run your app in dev mode because one of the challenges in the React native world is that you get these massive log, massive log spans. [00:27:10]

The stack trace is not at all discernible because it's kind of interacting in between the native world and, and the react world. but with this, the expo team actually ran a p and I think it's been actually merged now into hopefully the next release of, of Expo where they're actually showing you where in the react tree, the, the, the specific component is being rendered. [00:27:31]

So it makes discerning some of these error messages a lot simpler. So I think we'll start to see some, maybe some improvements on like the framework level as a result of this. [00:27:41]

Carl: Okay. That's all we got for React 19.1. Really. I don't know. There's just, there's not that much in 19.1. [00:27:48]

Dan Abramov is writing again

Carl: This is kind of small, this is maybe just like commenting on the ecosystem, but Dan Abramov is writing again, and That's nice. He was writing a lot. I don't know how many hours of text do you think he's written, mark? [00:28:00]

Mark: Many, many hours. Like I, I read fairly fast and there, there is a lot of content there. [00:28:06]

Carl: One of the newsletters I subscribed to that shared this out you know, does share estimated reading time. And it was, you know, one of the posts was estimated reading time of an hour. And like, that's just if you're scanning your eyes over the words, I think, not trying to digest and understand it, but like broadly what he's writing about is server components. [00:28:25]

Mark: Dan is fascinated with server components at like a technical concept, architectural. Where did this come from? How did we get here? What does this, how is this similar to old approaches? How is this different? What does it enable that you couldn't do before, kind of a level. [00:28:47]

And he's, not even officially on the React team anymore. Like, think of him as like a, private citizen expressing his own opinions at this point. But the different posts are going through different aspects of. Server components from like a, very conceptual level and trained to explain from first principles, how did we get here? [00:29:09]

React for Two Computers (Complement to his React Conf talk)

Mark: So like react for two computers is taking some of the concepts of, well, we have code that runs on the client and code that runs the server. How do we sort of figure out how to intermingle those? How can we shift pieces of that code back and forth and still have all this work together? [00:29:26]

JSX Over The Wire

Mark: JSX over the wire, I believe looks at, you know, if we, like we started with rest APIs, but rest APIs often end up growing special cases to handle data that the UI needs. And there's precedent for server driven UIs where you specify, here's a list of components in a JSON format. And then you know, the. All your different UI layers, you know, mobile, web, whatever, can just, you know, figure out on the fly what components you're talking about and render those and that RSCs take that sort of idea form a backend for front end pattern, but it's one that has more flexibility. And being able to send the list of components to render over the wire in a rather dynamic way. [00:30:11]

Impossible Components

Mark: I always skimmed the most recent one, impossible components, but it's, it's kind of expanding on some of this, like where can the logic live? What are some of the capabilities of things you could do, like having a server component read blog files off disk and estimate the reading time rather than like having to insert them into a database somewhere. So. The first couple were very, very abstract and you know, that was a complaint that a lot of people had. the last one was more concrete. He's also kind of trying to be careful to, I. Explain concepts without literally invoking the word react server component. So like think through the mindset without getting caught up in the trap of, well, this is like a thing I can only use with next, or whatever other complaints people have, [00:31:00]

Carl: funny, I just saw a meme that was like, name something that you can describe and people will agree with until you call it what it is called, and I was like, server components. [00:31:08]

Mark: Yeah. So. I've seen a number of reactions. You know, some folks are just saying like, look, Dan, your blog posts are too long. They need a table of content, or at least a, a summary upfront of what is the point I'm trying to make here? And Dan's like, that's not the way I write, and I'm sort of ready for myself at this point, which I totally get and good for him. I've, I've seen a number of comments where people have said like, well, I followed the train of thought and now I'm actually sort of getting. What the point of server components are, and I've seen a couple other folks say that like, you know, if, it's taking this much explanation to try to convince me of what server components do, maybe the React team really needs to like come up with like a 500 word summary, which are, which are all I think, are all very valid reactions. But it's , Dan loves explaining things from first principles. he's a very like, logical, think it through. Why does this exist kind of a person. On a personal level, I'm just very happy that he's gotten past his writer's block and feels good about writing the stuff he wants to say, the way he wants to say it. And also, there is some value in reading through these to try to understand like, what is the point of all this? [00:32:12]

Carl: And like at the end of the day, this is not, I think the, I think " feature in a JavaScript tool" is the wrong mental model for thinking about server components. I really do think that they are exploring a new. Compute paradigm, like it's a blending of the client server modes and they're constrained by, you know, technical aspects, everything in JavaScript in the browser is based around like batch and requests, it's hardcore based around a client server model. And they're trying to blur those lines and they do not really have platform support for doing it. So they are, you know, that's where things like the "use client" / "use server" directives, I think like they're kind of a hack fix because they don't have better primitives in the language, in the runtime to work with. [00:33:02]

to me, yes, it's taking a lot of words to explain this and to explore it and to try and make it digestible and comprehendible, but it was also really hard to convince people that like, like I, you know, I, I remember early in my career there were a lot of words written about like pets versus livestock servers because like, you should be able to like, kill and restart any server and it shouldn't cause a problem and that's a livestock server, rather than one that you like very gently take care of and, you know, evolve over, over time and love and dote on. [00:33:34]

And similarly when serverless became more of a thing, like these are different models for thinking about how your code executes and they're complicated and they're hard and I feel like this is cutting edge in so many different ways and so many, I dunno, I, I appreciate Dan really occupying this space at the bleeding edge, especially now that he's not, you know, professionally obligated to as a member of the core team. [00:33:59]

Mark: last thought real fast. when the new React Docs came out, there was nothing in there about server components, and for a while the only official docs about server components were over in the next framework documentation that Vercel's devrel team had written, I still thought there was absolutely nothing in the React docs all, about server components until about a week and a half ago. [00:34:21]

When I made that statement, after searching to try to confirm that there were nothing, and I missed that, there had been a page added about server components to the docs about a year ago, and I flat out missed that it existed. Having said that I do feel that the React docs would really benefit from having a much more concrete set of pages that describe server components. Ideally I would like to see an intro page, an overview, and in fact, there was actually a Versel blog post about server components that I think should just be literally copy pasted into the official React docs as the intro. I'd like to see kinda like a modest technical explanation. Like what are they architecturally, where do they fit in? [00:35:02]

What does running a server component output? Maybe some kind of an FAQ because there's an awful lot of questions people still have about them, including some pretty stupid ones. And then maybe even like some kind of like a adoption or migration page. Like I would like to start using them. [00:35:17]

I feel like having those pages would, it wouldn't solve all people's complaints, but it, it would at least centralize and make some of the information more official to reference. [00:35:28]

don’t 👏 ruin 👏 his 👏 process

Carl: Last thing I'll say on the subject of Dan writing again about server components. he posted on blue sky. "I kind of wanna write a dozen more posts about react server components. But I also feel like it's inviting endless takes about Dan trying to explain RSC means RSC is bad and it kind of ruins some of the process for me." [00:35:44]

So don't ruin the process. [00:35:45]

Mark: Be nice Dan, please. [00:35:47]

⚡ Lightning round ⚡

Carl: Okay. Lightning round. [00:35:48]

Next.js RFC: Deployment Adapters API

Carl: There is an RFC from next to do deployment adapters which is pretty cool. Like one of the big endless complaints about next is how hard it is to run anywhere other than versal. So they are meaningfully exploring what it would take to make that easier. [00:36:09]

Yeah, it was post put up three weeks ago. I, I haven't seen a ton of like movement yet on what exactly that means, but yeah, it's seems cool here for it. Interested. Very excited to see what comes out of that. [00:36:23]

flightcontrol.dev from last year: Secret knowledge to self-host Next.js

Carl: And I also wanted to shout out a blog post from October of last year from Brandon Bayer of Flight Control, secret Knowledge to Self-Host Next js. [00:36:33]

So that seems like a relevant read in, in conjunction with this new deployment adapters. [00:36:38]

Styled-Components in maintenance mode

Mark: I don't think we mentioned this last month. the style components CSS and JS library has announced that it is officially going into maintenance mode. Part of this is the amount of work needed to do it, and part of it is the shifts in the ecosystem such as relying on context when server components don't support context on the client. So that's both A FYI. This library is going into maintenance mode and also like more evidence that CSS and JS is sort of both falling out of favor and kind of being discouraged by technical changes in React itself. [00:37:15]

RIP Styled-Components. Now What?

Mo: One sort of interesting like experience from my side on this specific thing was we actually migrated on a project of mine that was on the web that was using Next js. They went into the app router and tried to embrace all things server components and part of that process was they had a styled component library, like a shared component library that they had internally, which was all in components and, immediately they hit a brick wall and they had like 80 plus components that were all styled components and they couldn't use any of that there. So to throw in a little bit of AI magic what we actually did was created a custom prompt in like two hours that took styled components and converted it into their choice SaaS modules. [00:37:54]

Which is going back to basics, but you know, a good technology choice nonetheless, if you want zero js runtime styles. And it worked shockingly well. So if you give it a good set of rules and you define the problem and you give it a nice workflow to follow, as if it was a developer did a shockingly good job, it reduced like the time for each component from like two hours to 15 minutes, 10, 15 minutes with a review process, like manually looking through the code it would generate. [00:38:22]

So if you're stuck in style components world and need a little bit of help, try to use gen AI and the reasoning models shockingly worked very well because. With CSS, things cascade and it needs to have an internal representation of how styles cascade down. So your four OS in chat, GPT wouldn't work very well, but your O ones and O threes would work quite well. bit of a weird guideline, but it was quite a fun experience and I think it's a good use case for it. Trying to play around with gen ai. [00:38:48]

Mark: I would not have thought about that. [00:38:50]

Redwood announces new Cloudflare-based RSC SDK, existing framework in community maintenance mode

Carl: Redwood has announced that they are now doing a CloudFlare based react server components, SDK. So like they used to be more of a framework and now they're like, it's kind of a reduced scope. I don't know. This connects back to, part of the headline of our January episode was "RedwoodJS, dead?" [00:39:12]

We caught word that like some other person who had been involved in the project early but hadn't been involved recently, came back out outta the woodwork and basically what Redwood JS has been for the last, I don't know, two years, it is not anymore and it is now something else. That's, strange. [00:39:31]

the SDK looks neat. I haven't played with it yet. I had been pretty interested in Redwood js because I thought they were trying to be like a Laravel for JavaScript and React Universe, and I thought that was cool. Something that is more narrowly like about doing the rendering is a lot less interesting to me. [00:39:48]

For me, the value of a framework like that is more like, when they were trying to be the Laravel of reactive, I was excited because I would love somebody to make things like authentication and toast messages and all those kinds of things. Easier to do, easier to build a product rather than, I dunno, a rendering model. So this is now kind of going back into rendering model. [00:40:13]

So it, it seems like an interesting, worthwhile exploration, but it's not what got me excited about Redwood in the first place. [00:40:18]

TC39 kills Records and Tuples proposal. Possible alternative is “Composites”

Mark: Yep. Meanwhile in, not directly react, but very related news, the TC 39 JavaScript Specification Committee has officially killed the records and two polls proposal. This was intended to add. Deeply comparable immutable objects directly into the JavaScript language, both in terms of runtime and specific syntax for declaring them. The idea was this would sort of like replace all your.dot object spreads and be able to have two objects and deeply compare them with the triple equals sign. [00:40:53]

And apparently there was pushback from JavaScript engine, you know, developers who were concerned about the impacts this would have on like internal performance. So that proposal's dead. There is a new proposal called composites, which is sort of lighter weight, like it looks like you would construct objects use, like using like a new composite class that could then have like a composite equals comparison, possibly. So sort of the same direction, but like less deeply embedded in the language itself. So I know a lot of folks had a lot of interest in records and tuples, and we're hoping that one would really come to pass and it didn't happen. [00:41:36]

React Compiler RC

Mark: React Compiler just came out, it was in beta and they've now gone rc. so number one, they, you know, they think it's, it's pretty good. It's almost ready. Number two, they've rearranged some of the lint rules previously. The React. The React compiler lint rules were in their own package, and I believe they're moving them into the existing rules of Hooks package. then they, they also announced experimental support for integrating the compiler with the SWC build tool, which is, you know, conveniently what's actually used by next. the compiler is primarily exposed as a babble plugin, even though the, all the implementation is not babble specific. they've found a way to integrate it into SWC, even if it's maybe not the most optimized way and are continuing to work on, you know, different approaches for configuring it as well. [00:42:27]

So it's getting fairly close. [00:42:29]

"Just use Vite”… with the Workers runtime (Vite on Cloudflare)

Carl: Nice. Yeah, CloudFlare has announced better support for Vite with the Workers' runtime while also throwing a little bit of shade, I think, at the React ecosystem by titling it quote, just use Vite dot dot dot, with the workers' runtime. I don't know. It just feels like they're throwing a little bit of shade out there. [00:42:47]

it looks pretty neat. I would like to play with this a little bit more, like yeah, they say "we're announcing release of the CloudFlare v plugin as well as official support for the React Router v7." So that's cool. I am currently running a React router v7 app. [00:43:01]

That would be interesting to connect to CloudFlare in that way. I guess like the big distinction here is that previously I. They say, "the V dev server would always run your server code in node js, even if you were deploying the CloudFlare workers." in local development. Previously if you were using workers it would just run in node and that's not the same. [00:43:21]

There are node APIs that are not available in the workers' time. So now taking advantage of the environment, API that we talked about a couple of months ago they are able to run your local development workers in an identical environment to what they will have in production. So that's cool. [00:43:40]

Definitely very neat. And I generally, I think workers are super cool and just like an interesting programming paradigm. Like talk about, you know, exploring new paradigms for executing code workers are the most exciting other than server components [00:43:54]

Mark: Last month we announced one of the major pieces of news was a vulnerability in Next's middleware implementation that could potentially have author related concerns. And there was a, you know, a major CVE vulnerability announced around that. This month it was react routers turn something was announced to have to do with some of the the path parsing definitions. [00:44:12]

There are fixes out for both React Rider and remix. Please upgrade appropriately. [00:44:17]

Carl: Yeah, this one looks a lot less major than the next one, but yeah, they did get a CVE. [00:44:21]

Silk Library - native-like swipeables for the web

Mo: So next up, I just a library that I saw floating about in the, blue Sky and Twitterverse. Silk is a pretty cool library that takes in sort of these like native swipeable sheets that you're used to in the native world and brings it to the web in a React library. [00:44:37]

So, you know, native feeling sidebars or bottom sheets or sort of like a, a, expandable bottom sheet for things like media players and stuff like that. All of that is quite difficult to do in the web world but very easy to do in the native world. And so they've created a React library and it works delightfully, like, it's very hard to tell that it's not native, which is really, really cool. [00:44:58]

The. I guess the, the caveat is that it's not open source for anything that's commercial. So any like hobby projects that you're using or open source projects that you're using, it's free. But you need to pay around 300 euros if you want to use it in any commercial projects [00:45:17]

Carl: reminds me of like sublime text, sublime merge, like the, the shareware. Please, please pay us. [00:45:22]

{transitions} = f(state)

Mark: Jordan Eldridge, who is possibly best known for having created the React reimplementation of the Winamp music player from the good old days. wrote a post a month or two ago about transitions, RA function of state. it's not talking about the new React transitions, API, but rather kinda that mindset of viewing the contents and the logic of your component as state machines. It's kinda short, but some good thoughts there that are useful to put into practice. [00:45:51]

Tailwind 4, Bun, and old Macs: A Supermarket Bag And a Truckload Of FOMO

Mark: And then tossing out one more There was a very interesting article from someone who is trying to switch from using Tailwind three to Tailwind four. [00:45:58]

I. But they were doing it on an old Mac, and as usual, I haven't used Tailwind, tailwind much myself, but apparently the latest version of Tailwind now uses a customized version of the BUN runtime to do its build steps. BUN is distributed as a native binary, and apparently the bun binary requires some of the latest CPU instructions. So it wouldn't even run on this Mac, even though it was a perfectly valid functional laptop. And so this person kind of got stuck, like, how can I even use Tailwind on this laptop when the latest version of tailwind's, compiler won't run on the laptop? And so it's well written, but also it's, just interesting to see how upgrades can cause problems sometimes. [00:46:47]

Introducing Firebase Studio

Mo: if you are somewhat following the world of Gen AI and the whirlwind of different tools and stuff that comes up every day some of them good, some of them not so good. There's been these sort of app builders that have been appearing, right? So things like V zero is the, is the big one that you'll probably be familiar with because of Sha Cian and, you know, the Versal ecosystem. [00:47:08]

But you know, there's other ones like Repli lovable Dev Bolt and, and many, many more I'm sure. It's a problem that a lot of people are trying to solve, which is, you know, how can we enable non-technical people to build out apps or maybe accelerate developers to actually build them out in some sort of agent tech model. [00:47:25]

And so, Firebase. the classic sort of toolkit that was there for mobile and front-end devs to be able to create backends without being real backend developers and needing to worry about things like infrastructure and whatnot, has thrown its hat into the ring and created Firebase studio. [00:47:41]

So the whole idea with Firebase Studio is that it's it's kind of giving you the full stack. So, you know, Firebase already existed to help you build backends without really building backends. And so they're thinking of building on top of that. They've released this using sort of the Gemini models that Google has to allow you to also build the front end so you know, in one sort of prompt or set of prompts. [00:48:02]

So you can generate a screen and then that goes all the way back and creates the sort of the backend for you as well in, in Firebase world, which is an interesting approach because they already have sort of a backend as a service. That people love and use quite often. And I, I still see it being used on a lot of sort of passion projects and even on some production applications. [00:48:22]

One of the reasons I thought it was interesting to mention here was because if you look at some of the examples that they've released they don't actually, they have a lot of react examples and not as many angular examples, albeit you can use it to generate angular apps as well. And that makes me think that they're sort of coming around to this fact that it's, you know, there's a lot more react and next js open source code on the internet, which means gen AI is probably better at generating it than something like Angular. [00:48:49]

But that's just a, that's just a take that I have and it's not grounded on any reality. So take that with a grain of salt. But that's my thought process as to why they're, showing a lot of react examples. Of course, they're showing flutter and some angular as well. So it's not like it's just react, but it's definitely interesting. [00:49:05]

Gumroad is open source!

Carl: maybe further afield from React and such, but Gumroad, for their 14th anniversary of being a product in the world is going open source. So they are, I guess, open sourcing their entire product which is cool. I like that. I'm confused about why, because like, you know, like fundamentally, usually people guard their source code if they're a like, functioning business that like makes revenue, you know, having the source code is a decent moat. [00:49:34]

But yeah, it's cool. I, I like that. I like to see it. I love seeing real production code bases made open source because like, that's such a, that's such a common request that I see people asking for is like, okay, cool, I'm learning all of this, but how do I know if it's good, if it's real? [00:49:50]

Automattic laid off 16% of staff

Carl: And my last link also a little further afield, kind of at the intersection of our first job market section and our lightning rounds. But checking in on some of the WordPress drama that we had covered a couple months back; Automattic. The company that maintains WordPress and led by Matt of much drama, the last six months is laying off 16% of its staff. It's a little bit, this like restructuring announcement from earlier this month is a little bit goofy to me to read because it, it's, you know, it's just like why we're making changes. We've reached an important crossroads. While revenue continues to grow, we operate in a highly competitive market. It's like, well, yeah, and you also alienated your entire, like, product base and like open source ecosystem and customer base. [00:50:37]

so just like seeing them talk about laying off one, one out of every six people who works there without talking about how, like, this was a total self own where the CEO just like burned every bridge he could find is like, alright buddy, good luck. [00:50:51]

Mo: It's kind of poetic in some. [00:50:53]

Carl: it would feel more like poetic justice if Matt was the one losing his job. [00:50:56]

Not people unrelated, but Yes. Ugh. [00:50:59]

Mo: But you know, I, I, I hope that other tech executives think twice and it becomes a learning lesson before they try to take open source products and monetize it in their favor when they have control over an ecosystem. I hope that people uh, think twice after this. [00:51:15]

Carl: Yeah, right. I feel like this is gonna be some kind of business case study somewhere. So that's, you know, hopefully [00:51:20]

Mo: I hope he also loses any bonuses that he was banking on getting this year [00:51:24]

Carl: anyway, That's all we got for you this month. Thank you so much for joining us. We will be back on the last Wednesday of the month, next month here in the live stage or back in your podcast feed just as soon as we can. [00:51:34]

We gather sources from this we in React Bites, dev React status, next JS Weekly, the React JS subreddit here in Reactiflux, and those direct from those publishing articles. If you see anything newsworthy, definitely let us know in the Tech News and reads channel here in Reactiflux or shoot me an email at hello@reactiveflux.com. [00:51:52]

I read everything that comes in, so definitely send me something. This is a show that you value and would like to support. Best way to do so is by submitting a review. It would be cool if it was, you know, five stars, but whatever, any feedback is appreciated and definitely tell your friends and coworkers about it if you like. [00:52:09]

Cool. Thank you so much. See you next month. [00:52:11]

Mo: See you all next month.