TMiR 2025-10: Post-conf; React 19.2, React Foundation, React Native removing old architecture. Next.js has too many directives

Transcript from Thursday October 30th, 2025

This Month in React - October 2025 (SM)

Intro

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

I'm Carl. I'm a staff staff product developer and freelance community leader here at React Flux, where I run community programs like these events and build tools to help keep the community operating. [00:00:12]

Mark: Hi, I'm Mark. My day job is at Replay.io and in my copious amounts of spare time, I maintain Redux and rewrite Immer. [00:00:23]

Mo: I am Mo, I head the mobile team at Theo. I'm an active part of the React native ecosystem and community, and I organize the React Native London Meetups and conference, which is coming up in two weeks. [00:00:30]

Terrifyingly so. [00:00:42]

Carl: Coming right up. Yeah. And you got a shout out that we're gonna talk about. [00:00:43]

New releases

Carl: Let's start with some new releases. Mark, tell us about Immer. [00:00:46]

Immer 10.2

Mark: Okay, I can, I can do both these things. So I actually take very full credit for this one. So to be clear, I do not maintain the Immer immutable update library that is Michelle West Rate, who created it and has maintained it all the easier years. [00:00:49]

However, since the start of September, I have sunk a stupid amount of time, something like 120 plus hours into trying to rewrite the internals of Immer for faster performance after some re users filed complaints to the Redux repos, that it was kind of slow. So I filed a few different prs, one to make some relatively small tweaks, and then a couple larger architectural changes. [00:01:01]

And Michelle just merged and released Immer 10.2 with the small options. And we are hoping to land the larger architectural changes in the near future. And those will probably come out as Immer version 11, hopefully in the next few weeks or something. So I'm excited faster for performance free upgrades. [00:01:26]

Yeah, should be. [00:01:45]

Carl: Yeah, love some big core performance improvements of deep packages. That's awesome. [00:01:46]

Mark: And I will also hopefully turn this into a conference talk. Nice. [00:01:51]

ArkType ArkRegex (typed regex)

Mark: Along with that, I, I just saw the announcement, I think like yesterday, that the author of the ARC type validation Library, which is a, a competitor to Zod that takes a, a rather different API approach, just released a, a similar tool called ARC RegX. [00:01:55]

It's a function that is supposed to be a replacement for defining regular expressions in JavaScript, but it actually parses the RegX string into TypeScript types so that it can both. Interpret at the type level, what the regular expression is doing, and also even provide syntax errors if the reg itself is invalid. [00:02:12]

Just looking at the docs, my mind is blown. [00:02:38]

Main Content

Carl: Well, yeah, other than new releases, we have a bunch of main content this month. [00:02:41]

React Conf

Carl: The React conf happened, what, three weeks ago, and a bunch of new stuff came out of there. [00:02:45]

Official ReactConf 2025 Recap

Carl: They did put up an official recap blog post from it on the 16th, about a week after the event happened. [00:02:50]

Introducing the React Foundation (also from Linux Foundation, Meta engineering, and Seth Webster)

Carl: The big takeaway here, I think, well, I don't know, we got a couple of big takeaways, but one of the headlines is definitely the React Foundation. This is a pretty big change to, or this sounds like it will be a moderately large change to the governance of React. They're pretty light on details of the actual governance, so far. They have talked about like a new technical steering committee. But they also say that the governance of that is not finalized. The members are not finalized, but they do have the founding members of the founding sponsors basically of this foundation, which are Amazon Call Stack, Expo, Meta, Microsoft Software Mansion, and Vercel with Seth Webster. [00:02:57]

Seth Webster is executive director and he's the what manager of the React core team, [00:03:39]

Mark: Basically. Yes. [00:03:44]

Carl: Yeah, so that makes sense. He is basically already doing that role and expanding what the core team means to an intercompany organization. But yeah, it's a lot of the details that I was most curious about, like what does, what does this mean for governance? Like how will decisions be made are not yet answered right now from the, from the various posts on this. A quote is, the React team is actively working on this new technical governance structure, and we'll share more details in a future post. So this is an announcement of a future announcement in some ways, but it's pretty real. [00:03:46]

So this is in collaboration with the Open JS Foundation, which is a partner to the Linux Foundation. So like th these are very large, pretty well-founded organizations that the React team is glomming onto in support of like a neutral home for React, as they call it. [00:04:19]

It's sounds like they're in incorporating React Native into this as well, which I think is not necessarily a given. You know, if you're talking about the governance of React, what that means for React Native is not necessarily implied. But just looking at the founding members like Amazon, Call Stack, Software Mansion, and Expo, and I guess Microsoft too, like those are all heavy React native investors. [00:04:38]

Mo: I think it's quite surprising in that sense because it's more heavy on the React native side. Like Vercel is really the key sort of non-react native player. The rest are really heavy on React Native and there's like noticeably missing membership from like Shopify on the Remix side as an example. I, I actually find it's very skewed towards React Native, almost shockingly. [00:05:01]

Carl: Yeah, I'd agree with that. It's, it is almost shockingly skewed towards React. React Native, given that it was not really pitched as the React Native foundation. That's true. I guess Software Mansion does do a fair amount of web React work. But I, I believe Call Stack is predominantly a React native shop as well. [00:05:24]

Mark: So I'll do my usual thing where I, I step back and provide historical context and what matter at all. So React was invented at Facebook. It has always been a project owned by Facebook and Meta. The code has been open source, but. You know, for years the entire development team was Facebook meta employees paid by Meta to work on React. And I've said even in my conference talks this year about Meta, Vercel, React ownership, that the React team has had the freedom to work on what they want. And that's true, but I've, I was reminded in some conversations with React team members at React Con, how much their work is constrained by, like the fact that their performance reviews are, "what have you done to further meta's goals this year?" [00:05:42]

And so in some ways their ability to push React in the technical directions that they think are right, are limited by how much they can make the case for that. Inside Meta, even something like the Concurrent Stores work is essentially being pitched as, how can we make Facebook's Ads Manager app faster in a lot of ways? [00:06:38]

So we saw multiple React team members move over to Vercel. Like people used to complain that this is all a Facebook app, all the meetings are inside Meta. There's no public roadmap, it's only meta. And then we had team members move to Vercel, and then it became, well, now Vercel is applying too much ownership to React and all the stuff we've talked about with Next and server components and Vercel and how that's supposedly driving the roadmap, et cetera. [00:07:02]

And so the team itself has been split across two companies, and they're working together. It's one team, but it's kind of within these two companies. And so because of Reacts widespread usage, there's been calls for many, many years that there ought to be some kind of an independent foundation that would own the trademarks, the rights, the development process. [00:07:30]

To React itself. And it always seemed kinda like one of those pipe dreams. The calls on Twitter to build, React into the browser. And obviously there's no way that's going to happen. And, and this felt like much of the same kind of idea. And so they, they did the initial React and the initial keynote at React Con, and they were mostly focusing on technical things. [00:07:56]

Like last year we, we fixed the, the sibling preloading bug. That was the suspense gate problem that everyone was talking about last year. And 19.2 came out and the compiler is 1.0. And then Seth came out and he did the one more thing routine and as soon as he put the React Foundation slide up, my jaw dropped. [00:08:17]

And I think I even said out loud, oh my word, they actually did it. And my first reaction was, even without knowing. Any actual details about what the foundation is or how it's going to work or whether this is even going to work out in practice. The fact that they have taken the time to do the legal preparation work to try to make this happen and are actually attempting to execute on that is a huge deal for React and the ecosystem. [00:08:40]

It, it is a statement of good faith and intent for how they want React to proceed in the future. Like without any details, my immediate reaction is, yes, finally, this is a good step forward. We'll see what it means in practice, but this is a really big deal. [00:09:12]

Carl: Yeah, I would agree with that. It's a really big deal that they're moving in this direction. [00:09:32]

I'm really curious about the details because I think there's a lot of, I don't know, like in the past they've done working groups and et cetera. And my understanding of the takeaway is generally, has generally been that they found it really difficult to manage participation in those like open access kind of arenas. [00:09:37]

So maybe the, this is kind of like adding a new layer of abstraction perhaps with administrative support from currently thriving independent foundations. Mm-hmm. So that, that definitely makes me think that this has a real chance of being something real and valuable that goes on for a long time. I'm curious what it means for things like, like in practice, it's not like anyone's employer is changing. [00:09:56]

No details have been shared yet. At least that anyone is being paid from this new foundation. I, I don't know whether to call it meta or Facebook 'cause it's on the fb.com domain. Mm-hmm. But in the Facebook engineering announcement here, they do say that Meta has committed to a five year partnership with over $3 million in funding. [00:10:23]

I don't know what other funding they might have. I don't know what other sources of funding they might have in the future, but like just looking at five years, $3 million, like that's 600,000 per year, which is like, you know, for meta engineers, that's like free engineers. So I don't know. I don't know what that means for people's incentives and where they will work and how their focus and performance will be evaluated. [00:10:42]

Yeah. [00:11:04]

Mo: What that rules out is that effectively the React Native or React and React Native Core teams will definitely not be unemployed by the React Foundation. Right. 'cause that would basically cover three salaries, which is far smaller than what the React teams are. [00:11:05]

Carl: I think the React core team has like 10 engineers. [00:11:19]

Mo: And RN is about the same. So you're talking 20 engineers. It's definitely not going to cover those employees to move them over, which is in some capacity. And then details are to be fleshed out. But in some capacity it is a bit disappointing because it would be great if they had more freedom as the React Native Core team to play around without the restrictions, like you mentioned, of the reviews that Meta has internally. [00:11:22]

And so it's gonna be interesting to see how that Dyna dynamic plays out effectively because there is still gonna be that same team. At Meta [00:11:44]

Mark: I, I have three sources of information that I'm piecing together for some of how the foundation is supposed to work. Seth Webster answered a few questions about this during the q and a session that was broadcast at React Conf. [00:11:51]

I had a conversation with a couple React team members and the topic came up about how things would be governed. And then there was an article on the new stack where Seth Perry was interviewed and was giving some further details about some of the governance. [00:12:05]

So as best I understand it, so you've got kind of the corporate level stuff that's Meta, Amazon, Callstack, Vercel, et cetera. They will then elect a technical steering committee. Which is, I guess sort of similar to how Node and other projects work, Seth said in the q and a, that meta will start with five votes on that corporate board, and then it will go down to one over the next five years. So you kind of a decreasing amount of influence in that sense. [00:12:21]

The technical steering committee, I assume, would be able to make decisions themselves, but obviously the fact that they are employees of the companies elected by those companies, et cetera, they would be taking their company's interests into account in the process. The article says that the technical governance will be in the open more than it once was. [00:12:53]

Request for comments, sets of stages, et cetera. But a lot of the process is still to be figured out. The article also talks about the foundation doing things like investing in React hubs, helping boot camps teach React better, possibly some things with conferences and alignment and such. So it sounds like the foundation is going to be doing more outreachy things. [00:13:17]

So there, there's a lot of this that is not clear what it means in practice yet, but certainly. React is not solely a meta owned thing at this point. There are multiple companies that are invested in it. There is a, a future for React independent of META'S ownership and goals. And this all feels like the people who care are trained to do the right thing. [00:13:43]

And [00:14:11]

Mo: on the conference side, I mean, I hope that's the case because one of the, as a conference organizer, one of the things that's perhaps challenging is that Meta doesn't necessarily sponsor any conferences beyond just React conf, right? And so, look, it's well known that that's sort of the case. And so maybe the React Foundations that is going to be able to sponsor those conferences, even if it's not a meta badge to speak, which would be very, very interesting if some of that is used for that. [00:14:11]

So I'm sure it's not just Meta who's investing, right? Like I, I suspect that there's funding coming in from. Amazon and Microsoft, at least from the bigger, bigger sort of established enterprises [00:14:38]

Carl: hopefully. And that's interesting. And the new Stack article interviewed Seth and has a bunch of poll quotes from him and they do talk about that, that like the foundation will look at expanding the annual React conf. [00:14:49]

I guess that's not sponsoring other conferences, but they're talking about conferences at least. But also something that caught my attention. They say while React Comp is one of the few conferences that actually makes a profit, it basically only paid for itself. And also it's a thousand dollars a ticket conference. [00:15:00]

So like hopefully the mode of making conferences self-sustaining is not making them cost a thousand dollars. [00:15:14]

Mo: Yeah. I mean conferences are from experience a very, very expensive endeavor. And if you don't have companies backing them, they will make a loss. [00:15:22]

Carl: I do wanna shout out, as we mentioned at the start, Seth says "We have lots of boot camps out there that are doing their best, but they're also sending people out into the world misinformed about how React works." [00:15:31]

This is interesting there. It's a, it's funny, they're actually hitting on a couple of points that I've investigated myself about how to do businesses in like a community since like I had previously connected with a bootcamp. Somebody was working there as the curriculum lead and they were doing a curriculum overhaul. [00:15:40]

'cause they hadn't changed what they were teaching in three or four years. And they were like, is this still relevant? Is this what the industry's using? And I was like, cool. I help run a community. I know lots of experts. I would be happy to facilitate some kind of professional review. And then the bootcamp curriculum lead got laid off because that was 2022 and lots of things were not happening. So it's interesting to see them talk about things that I've thought a lot about. [00:15:59]

And also a lovely shout out, Seth says there are also cohorts such as meetups and local groups that could be assisted. One meetup actually led to the creation of the conference React Native London. So that's super cool. Love that for you, Mo. [00:16:22]

Mo: Yeah, I didn't, I, I did not have that on my Bingo card to get a shout out from Seth Webster on an interview, which is awesome. Yeah, it was good to have him last year. [00:16:36]

Carl: Mo is the organizer of React Native London and that one meetup that led to the creation. So that, that's just fun. [00:16:44]

That's cool. We have actual players in the ecosystem in the podcast right now. [00:16:51]

Mo: Well, you got Mark. So I'm stepping up to very, very, very high standards. Pretending to. [00:16:55]

Carl: Cool though. Yeah. So I don't know. I don't know if there's more to say there. [00:17:00]

19.2 (Activity, useEffectEvent)

Mark: Some of the more technical stuff. So they, they talked about React 19.2 coming out, which if you've been paying attention to this podcast for the last several months, you would've known all the details already. Like the new activity component for being able to hide components while persisting state use effect event for hopefully fewer use effect related bugs, et cetera. React compiler hit 1.0 and then [00:17:03]

React Native news

Mark: Mo as like as usual, you wanna talk about the React Native-y things? [00:17:27]

New architecture only from v0.82

Mo: So a few updates that they did, one of which was quite surprising was that the next release of React native version 0.82 is going to be new architecture only. [00:17:32]

So obviously earlier on a few months ago, we talked about how they deprecated the old architecture than they froze the old architecture. Now they're dropping the old architecture. And so to me that was a much faster deprecation cycle than I, I would've expected. Specifically when it comes to the fact that there are still a fair few libraries that are using the old architecture and only support the old architecture. [00:17:44]

So to give you a very concrete example, we had our monthly meetup literally yesterday, and there was a talk about Arrive, which is this animation engine that a lot of people are using to animate websites and make really, really cool stuff. But what we learned surprisingly was that Rive only supports the old architecture. [00:18:06]

So what that means is that this company who's a very popular healthcare company, really don't have a path to sort of migrate to the new architecture and hence version 0.82 until Rive starts to support the new architecture. So there are still libraries, albeit the majority of major libraries have been ported to the new architecture that are still hanging behind. [00:18:24]

So I'm quite surprised by this, but we'll see how it goes. It probably means that these library maintainers really need to like step up in the next month or two and get ready. [00:18:44]

Vega OS announcement

Mo: The second big thing, which I have a little bit about later on, but just a quick one, is that Amazon did the Vega Os announcement earlier. [00:18:52]

It was towards the end of September that they actually announced it, but [00:19:02]

Vega introduction at React Conf

Mo: they formally talked to the React and React native communities about it during React Conf. This is a completely new operating system that's fully built from scratch by Amazon folks and React Native is the UI layer. It's the only way that you can write apps for it, which is quite a big investment from Amazon's perspective into React Native as a technology. [00:19:04]

So Amazon makes a lot of devices. For a little bit of context, you might've seen their Fire TV devices, some of the Kindle fire devices that they had, but also like Echo dots and a whole slew of different devices that they manufacture. And previously a lot of these were running on Android or a variety of Android called Fire Os that they had adopted from the Android open source projects. [00:19:27]

And so now they've kind of completely ditched that and they're betting long term on React native now at our company at Theo and a bunch of other companies have been sort of working with Amazon behind the scenes on this. And we're aware of this but weren't really allowed to speak about it. So it's now out in the public. [00:19:47]

But it has been a good while, which I cannot specify how long that duration is that I have been aware of this, but just not able to talk about it and have been working with the Amazon folks to make sure that things are ready for their launch. So they have an introduction video at React Con, which I think is interesting because TV apps need to run on very, very limited specs. You're talking like a few gigs of Ram one or two gigs of ram and like very, very, very slow CPUs and some of them are even worse than that. So effectively they really had to optimize the living crap out of their operating system and make sure that React plays nice with it and is like the first class citizen when it comes to it. [00:20:02]

So it's, it's very interesting how they had to optimize it and it was a big undertaking for them. So. I guess congrats to the Amazon team, but beyond that, it's quite interesting for people that are interested in performance and React and React native. [00:20:38]

Carl: Yeah, I was just scanning this to see if I could find any details about what they built on top of, because like, I don't know, nobody builds a whole OS from scratch anymore. And this is on top of Linux? [00:20:48]

Mo: Yeah, it's c plus plus on top of Linux. Basically it's a Linux. Or is a Unix based system. [00:20:59]

Carl: Right, like, and so is Android. Like, I'm curious to what extent this is a locked down, stripped back version of Android that they're calling Vega. They don't say that anywhere, but like reading the tea leaves here, I, my assumption is that the, I don't know, Android was such a massive undertaking that Google then acquired and commercialized. [00:21:05]

Curious to hear more technical details about the OS layer here and how it… [00:21:28]

Mo: I can tell you a little bit about that because I've known about it for a while. It's not on top of Android in any capacity. It is fully, the Android open source project components of it are fully stripped out. It's built from scratch, which means that compatibility with old apps is. [00:21:32]

Limited and there's other solutions. It's not that you can run Android apps on it as an example that we're the old Fire OS apps. [00:21:47]

Carl: So wait, it sounds a little bit like you're saying there is a shared lineage with Android, but it's different enough that its own technically distinct thing. [00:21:54]

Mo: They share a technical lineage in the same capacity that like Mac Os and Androids here, which is, they are both unique systems and that's pretty much it. [00:22:02]

Like they serve the same kernel but like so does 90% of devices out there. So it's as Android, as IOS's, Android, if that kind of makes sense. [00:22:11]

Carl: The Tree of Life, kingdom Family order. Like this is not shared genus. This is shared order maybe? Yes. Okay, cool. Good to know. Thank you. [00:22:19]

Mark: I do wanna highlight a couple talks in particular, and again, you can look at the whole React con recap blog posts to get links to the different talks and the different portions of the live stream. [00:22:27]

Joe Savona’s “Exploring React Performance” talk

Mark: A lot of good talks that were worth watching, but two that I liked in particular, Joe Savona did a talk on some of the React team's performance experiments, and there's a bit of controversy because he showed a bunch of hypothetical, semi hypothetical benchmark numbers without any real details on the actual implementation of the benchmarks. [00:22:36]

And then some of them were like, versus we built NAP with signals and compared it with one with React and then ex a highly prototype React and a bunch of other stuff. And then people were saying, well, we tried to mimic this and we think you're probably using signals the wrong way. But it was still interesting to hear the discussion around, we agree that performance has been a problem and we've tried prototyping some different ideas to see what's possible and where bottlenecks might be. [00:22:56]

Ricky’s “Async React Part I” and “Part II” (repo)

Mark: The other one I really wanna point to though, Rick Hanlon did a talk called Async React and he had a few major, he had a couple different points out of this. [00:23:26]

One was that the React team has been talking about things like suspense and concurrency since 2018, and if it's been hard to follow where the React team is trained to go with this, it's 'cause the React team itself really didn't know where they were trained to go with this. He even pulled out meeting notes from a React team weekly meeting in like 2015 or 2016 where they started having the first initial ideas for, we think we want to go in this direction, but they really didn't know what the final result ought to look like or how they were going to get there. [00:23:36]

And so showed a diagram with a whole bunch of back and forth wavy lines like we, we don't know where we're going, but now it's 2025. We've gotten through the confusion. We've now built all the main concurrent pieces that we were trained to build. We are seeing the results of even like the React 16 fiber rerate. [00:24:15]

And now we can actually say, we've built these pieces and here's how they ought to fit together. And so the second half of his talk was a demo where he took a badly written but viable React app, which uses use effect for data fetching and manual setting, state for loading states and things like that. [00:24:37]

And he first refactored it to have a bunch of transitions for better loading animations, using suspense for the data fetching, and he showed the visible improvements in user experience. And then his point towards the end was that, yeah, the, so like this is how modern Async React code ought to work. But in fact, you shouldn't even have to write most of this code in your own app because the transitions and the loading states and everything else really ought to be embedded in your router and your data fetching library. [00:24:56]

Now, unfortunately, his actual talk got interrupted for stupid technical reasons. So he came back at the end of day two and picked up with his demo and actually had a chance to do a better version of it. [00:25:36]

And so I think the key points are, one, the React team has now built the concurrent async features that they've talked about for years. Two, a lot of us, including myself, are still kind of stuck in like a 20 16, 20 18 era mindset of how to use React three. These things make writing React apps better and better user experience. Four, we need to get these things embedded in component libraries and data fetching libraries so that a lot of this stuff just works outta the box. [00:25:48]

So I highly, highly recommend watching Ricky's talk. He also put up the demo code as well. [00:26:23]

Carl: That was a good talk. It was a good demo. I will say, while watching him write the code. I was like, man, this looks really complicated. [00:26:29]

Mark: Yeah. And that, and that's another point that we're going to touch on here with a couple of the, the other things as well. [00:26:37]

One other thing that really caught my attention, so if you've been listening to podcasts for a while, you've heard me agitating, saying that we really need is a new React working group where folks from the community can officially communicate to the React team for things like, Hey, we think there should be more docs to cover this topic. [00:26:41]

Or, oops, create React app just broke. I think you should fix it, and things like that. And Ricky was actually the person who drove most of the React eight team. Working group. [00:27:00]

Async React Working Group

Mark: And so at the end of his talk, Ricky actually announced that there is now a new Async React working group. And this is sort of a catchall, it's meant to cover discussions of things like how do we get async React features into major ecosystem libraries and, what kind of docs should we have to cover this stuff? [00:27:12]

First discussion of more docs ideas

Mark: And so the, even the first discussion thread is a lot of discussion between me, Ricky, Dan Aberman of Corbin Crutchley, about a whole bunch of possible docs, pages that we could add that would cover things like transitions and suspense and how to use them correctly. [00:27:35]

And getting people from the community to contribute those new docs pages rather than waiting on the React team. To write them. So I am actually genuinely, genuinely excited. Like I've done a lot of complaining and this is the answer to my complaints that we have working group and docs plans and an agreement that people outside the team can contribute. [00:27:53]

So like I am actually legitimately thrilled by this. [00:28:16]

Carl: Nice. I do appreciate more, I don't know, open participation more, more discussion. That's great. [00:28:21]

Remix v3 announcement

Carl: Should we get into Remix V three? [00:28:27]

Mark: Yes, we should. Alright, so usual caveat, I still have not had time to actually watch the announcement, but I, I think I can give a fair summary of it from having seen the discussion on Twitter and the articles afterwards. [00:28:29]

We have mentioned for the last several months that they were teasing Remix V three is going to be, not pre-ACT, its own component model, something with iframes, whatever. And our last comments on it were just show us some code already. Well, at the Remix Jam conference, they did actually show us the code. [00:28:43]

Announcement demo timestamped breakdown

Mark: There was a, a repo put together that did timestamped links to all the appropriate pieces of the announcement video. So if you'd like to be able to jump in and see the examples of what Remix V three code is supposed to look like, that should make it easier. My first impressions, again, just having seen screenshots of the code in following the discussions, is that Remix v three's component model is sort of a mixture between React, view and backbone. [00:29:03]

So it's kind of like React in that you have function components and they, and that uses JSX. It's kind of like view and the composition API, where you're given a closure as the setup. It's a little bit like backbone in that the function component you're rating still sort of is organized like as if it were a class. [00:29:35]

It passes in a reference to the instance rather than getting the props as an argument, and you're supposed to call it this. And part of that is to make use of a TypeScript typing trick that lets you declare the type of this as an argument to a function. But also you manually trigger updates by first mutating a variable in the setup closure, and then you manually call this update. [00:29:58]

And so Ryan Florence even said, this is basically old school React class component, this dot force update. Essentially, so I, I can see bits and pieces of parallels and influences between all three of those frameworks. When I look at the Remix code, it's also supposed to come with a bunch of utilities for being able to compose event handlers together. [00:30:29]

And yeah, so we, we have finally seen the code. I believe they also gave some demonstrations of what the server side loading story is supposed to look like. Some kind of an I frame alike component that has its own URL and can automatically re fetch HTML. I haven't looked into those pieces as much, so very big picture. [00:30:54]

I saw a lot of people arguing about having this dot update. A lot of people saying it feels like a step backwards, it's manual update code. [00:31:19]

Updates syntax can be customized?

Mark: But some people demonstrated that you can very quickly write your own wrappers that just call this DOT update internally. I have seen wrappers that mimic like the used state hook. [00:31:28]

I've seen wrappers for other state management libraries like Redux. So it's a primitive that can clearly be abstracted if you really want to. I saw some good posts and articles from James Long and a couple other people with thoughts on the ability to compose interactions together. Carl, to your point that modern React and all the new async features feel very complicated. [00:31:39]

Like there's good reasons why methods like transitions exist to try to give better user experiences, but it's just all these additional concepts and behaviors you have to keep track of in your head. And Remix is trying to go for a less magic, less abstraction approach. So we'll see what it means in terms of adoption. [00:32:06]

Again, this is non-reactive, so different framework, different ecosystem. Who knows what the actual adoption will look like, but I get the sense of what they're trying to go for and I, I think it will appeal to some number of users out there that want to have that kind of behavior. [00:32:31]

Carl: Yeah, I'll definitely keep paying attention to it 'cause they're thoughtful about things and historically have just done a lot. [00:32:49]

So I'm very curious to see where this goes. But my gut feeling here is that this is going to end up more as an API exploration and that any great ideas that come out of it will be a fresh exploration and then maybe validate some ideas that get brought into React or view or other big tools. But yeah, I, I could be wrong, could be, could be more independently successful than that. [00:32:58]

They, they did stress in the video that I watched, that this is all like prototype phase. So they, like right now apparently there's splitting it all up into a bunch of different packages. They can iterate independently and explore a bunch of different things. But the, the final intended usage would be from one package, not from 20 different packages. Just to throw that out there as a a thing that will change. Yeah, I don't know. We'll see. We'll see. I think the component model is just gonna be really hard to disrupt. [00:33:25]

One, one thing I did see in the video of Ryan Florence talking about just talking while he was demoing, he like compared and contrasted with like, here's how we do state changes and you just call the dispatch function instead of set state. [00:33:54]

And I was like, I dunno, you can do that in React. Like they've been encouraging people to do that for years, for like six years basically Ever since hooks came out and you could do a state reducer, they were like, please, except for trivial uses of state, all of your state should be in a reducer and you should use dispatch. Not set state. So just like calling that out as a point of comparison, like React has been trying to do that for a long time too. It's just nobody actually does, I dunno, just caught my attention. [00:34:08]

Mark: Well least we have an actual code to critique now and argue about instead of the vague teasing. True facts. [00:34:35]

Carl: I will happily continue reading code and critiquing. [00:34:41]

I built the same app 10 times (code)

Carl: Speaking of which , I love this project. I have thought about doing this so many different times and I never have because it's hard. Somebody built the same app 10 times in a variety of different frameworks and tools and benchmarked them and compared and contrasted their performance in a bunch of different metrics. [00:34:44]

It seemed like they focused pretty heavily on like bundle size to me, very wordy. I, I will say I got a little bit lost in the [00:35:05]

Mark: instruction. Very wordy and very, also, a lot of the article was very clearly AI generated. I saw some comments from the author saying he had written pieces of it in sections and used AI to help with it. [00:35:12]

So like there, there was clearly human involvement in it, but the, the AI generation of the article itself was a critique point. [00:35:22]

Carl: Yeah. Just like as I'm scrolling, it's got so many paragraphs in a row that are all like identically long. Just a little bit of a wall of text. I definitely skimmed this pretty hard. [00:35:30]

All that aside, like I just love the idea of doing the exact same thing with the exact same. Like, well, I don't know that they use the same test suite, but that, that was always my idea is build. You build an end-to-end test suite and then you get a passing app for that test suite in a bunch of different tools. [00:35:38]

I meant to do more of a deep code review on a couple of the different implementations. It's a CanBan board, it's, you know, a Trello clone type project where you're doing task management with cards and drag and drop. I guess it, it's a great and a parable comparison because drag and drop is really hard to do and so it's very frequently something people try to lean on libraries for. [00:35:54]

So if you are implementing it yourself, that's kind of cha, that makes it a little bit challenging to use as a point of comparison. But the tools that were used here, he built it analog, which I guess is vanilla js is what I'm assuming, or [00:36:15]

Mark: analog is actually a, a next like tool for Angular. [00:36:31]

Carl: Oh great. Okay. Okay. So you built it an analog, which is an angular type thing. [00:36:36]

And HTMX, Marco, which I'd never heard of. Next.JS, of course. Next. Sure. Qwik City, which is Qwik. I've heard of Qwik City I had not heard of. So this is I guess [00:36:41]

Mark: probably another solid versus solid start type thing. [00:36:53]

Carl: Qwik city to qwik Sure. Solid start spelt Kit Tan Stack with solid and then Tan Stack with React. [00:36:55]

Yeah, one of the first tables, one of the first actual like points of comparison of the output tables is just on bundle size and how much JavaScript was served in order to. Get this app running. They used Next.JS version 16 as the baseline and that was about 500 kilobytes gzipped, which is huge. It's big hand stack. [00:37:03]

Start with React. Clocked in at about 300 kilobytes a little bit more with solid was a half of that hand stack. Start with solid was 150 ish kilobytes. The smallest was Marco. 12. At 12 kilobytes followed by quick city at 88. Oh, I just realized there's parenthesized compressed. I thought I was reading the compressed and I was not. [00:37:25]

Mark: There's also the board page versus the homepage sizes. [00:37:49]

Carl: Yeah. Okay. Alright. This is more confusingly presented than I realized. [00:37:53]

Same author as React Won by Default and It’s Killing Innovation

Mark: I think the biggest picture takeaways, number one, it's worth noting that the author of this article previously put up a post a month or two ago saying that React by is the default choice and it's killing innovation in the ecosystem. [00:37:57]

So that kind of to where they're coming from. But I do think they did. They were legitimately trying to do a real meaningful comparison, even if the results were sort of what they were hoping they would be. IE reacted big and bad. So yeah, the big takeaways are like React itself is huge and so any React app is going to be very large bundle size wise. [00:38:08]

And look, if we do like Tan Stack with Solid instead of Tan Stack with React, it gets smaller. But also if you do these other frameworks, it gets even better smaller and then it kind of ends with a bit of a, another rant about React is a bad choice. [00:38:32]

Carl: Yeah, I, I will validate that. To me it also looked like they really tried to give React a fair shake here. [00:38:49]

Like, you know, if you wanted to, if you were wanting to complain about bundle size, if React apps, like there are so many easy ways to bloat this up to a couple of megabytes. So like the fact that they didn't do that is indicative enough to me that they tried to give this a fair shot. It's cool. I love this. [00:38:55]

This is a great project, great effort. I don't know that, to me, at the end of the day, this is interesting and fascinating and a great point of comparison, and also like not that meaningful because the performance metrics that you measure here that are easily measured by comparing the outputs of identically functional applications, that's really only like maybe a third of the reason why you would choose to build an app with any particular set of tools. [00:39:11]

Like really, if you're starting a company and hiring engineers and doing a greenfield project. Like some of the most important things are how much will this cost? [00:39:41]

Mark: How well is everything? How well is everything documented? How easily can we spin up engineers who know these things? I mean, the, the ecosystem argument is a real thing. [00:39:52]

Carl: And like, you know, if it takes you two months to find a developer, you know, a senior developer who can build your app in Marco, you know, you could do that in a week. I don't know. The hiring for React is much easier than hiring for some niche tool. And I have seen writeups of people saying like, yeah, we built our startup on this niche framework and we couldn't hire for it. And that ended up contributing to the death of the company. [00:39:59]

So like, you know, these performance metrics are important, they're really useful, it's great to have them. So we know where opportunities to improve are like tying this back mark to your Immer work. Like if somebody hadn't complained about performance, you wouldn't know that it needed to get better. [00:40:23]

Pretty [00:40:37]

Mark: much. Yeah. [00:40:37]

Carl: So this is great and I love it, but it's also not the end all, be all of like decision making for, things. Yeah. It's also, man, this, it's just so hard to read because of how long it is. I wish they'd stripped this down a bit more. [00:40:38]

Mo: And if we take like a step back out of our like web ecosystem bubble for a second, like you go to like the backend world and like enterprise business companies or finance or whatever, and like they employ a lot of developers, right? [00:40:49]

Like thousands, thousands and thousands of developers. And like there's a reason they're all on Java and .Net is because like they can hire for those and it's pretty easy to build a team around. That's the top priority. Even like this stuff is quite minuscule when people are, companies are hiring at a large scale. [00:41:04]

And then the second thing, which is like not accounted for, I think in this like approach of looking at like just the bundle size that's outputted is the fact that like your productivity with the fact that most of the AI tools are really like optimized around React is not something that you should not look at and consider when you're choosing something. [00:41:21]

There's so much training data and so much like tooling around building React apps quickly and prototyping React features or React apps that with AI that is just a bit, it feels a bit moot some of some of these conversations. It feels. [00:41:41]

Mark: To be clear, like React has got itself has gotten much bigger over the years. [00:41:55]

In fact, even just 18 to 19 it got notice will be bigger. Bigger bundle sizes are not a good thing. We are not sitting here saying Your bundle size does not matter. Alex Russell, as much as I disagree with his communication style is right to point to the technical receipts saying that big bundle sizes are bad, but also it's not the only single metric you should care about. [00:41:59]

Carl: Yeah, right. Yep. And also, last thing I'll shout out here. I think the author of this blog post also mentions that he tried not to pull in too many dependencies. So like did not pull in fetch wrappers or data fetch tools like React Query and. [00:42:21]

Axios, the data fetch thing, which many people still use, I don't know. They still have a fair amount of utility just for things like observability and security and various guarantees like that. Like Axios itself is 36 kilobytes ified like 14 compressed. React Query is 55 kilobytes. I guess to say that the way he did it is actually better quote unquote for React in terms of the bundle size argument, but it's also not representative of how people actually build apps. [00:42:40]

It's a challenge of these types of articles is that by necessity it has to be the level of scope that a single developer can execute on their own, and that's just not how most apps are built. Like most apps are not passion projects by one person. So yeah. Super cool. Love this post. It's interesting more than it is authoritative, I think. [00:43:11]

Mark: Good way to put it. Mo, tell us about Solito. [00:43:30]

Solito 5

Mo: Yes, Solito. So go back a few months. You'll remember that we said Fernando Rojo joined Vercel. And he joined as the head of mobile firm Vercel. This was significant because he's the author of this library called Solito and a few other libraries like Ziga. So he's really, for the last few years, has been focused on. [00:43:33]

Using React native on the web as well, especially with Next.JS. So he built his own startup in that sort of tech stack. It is from experience and having built with this tech stack quite a lot, it's a challenging approach because you are always balancing oversharing between your native components and your React native code and the web functionality that you import in. [00:43:53]

And oftentimes that comes at a detriment of performance or ux, depending on if you do it right. And the more that you share, the more chance there is that you're not, you're sharing something that you probably shouldn't share. And so there's a lot of libraries in the secret system, but Solito is probably one of the key ones where it lets you share navigation across Next.JS and React native apps. [00:44:16]

Now, we've talked a bit about Toledo in the past. One of the big limitations that any library in this space has is that it relies on React Native Web Now, React native web was made several, several years ago. I think it was back in 2015. And it was made by Nicholas Gallagher. Now, he also did a talk at React Conf, which I would recommend you watch about React strict dom. [00:44:39]

But the key thing with React Native Web is that it's not really receiving as much love because Nicholas is working more on React strict dom, which is sort of like the future path for sharing code across the web and mobile. And so React native web is, is a little bit bloated, and what that means is that any library that you really use, especially your, something like your navigation and routing library will import in large portions of React Native Web, even if you're not using all of the APIs. [00:45:00]

And so that means that your bundle size goes through the roof. And what the Vercel team slash Fernando Roho have now been able to do is actually remove React Native Web as a dependency from from Solito, which is pretty massive. It sets us up in a foundation where you can effectively get ready for React strict dom adoption more easily in the long run, but also means that if you pick and choose your libraries well, when you're building a UniVercel app and you really think about what you're using on the web platforms, you can really start to tackle that bundle size problem. [00:45:25]

It doesn't help if you're using libraries like let's say Reanimated, which has a pretty heavy reliance on React Native web. But if you're going really vanilla and you're very careful, it means that you can actually achieve much better performance on the web by using this new version of Solito, which is very exciting. [00:46:00]

So yeah, if you're already using Solito, give it a look and if you're thinking of building a uniVercel app, it's a really good candidate if you wanna build a highly performant web variant of your application. [00:46:16]

Carl: I love that. It definitely makes a lot of sense to start moving away from React Native Web, given that we've compared and contrasted React Native Web with like React strict dom. [00:46:25]

I guess it makes sense to move away from React native web, 'cause the guy who made it is now doing a different thing in the exact same space from a very different angle. So yeah, that's a pretty strong argument for changing. [00:46:35]

Next 16 and Directives debate

Mark: Okay, the last major topic for the day next 16 and directives. [00:46:49]

Next 16 released

Mark: So next 16 came out. The headline feature is they now have what they're calling cash components. This is the, I don't know, second, third, fourth iteration on how to do caching in next, across the last couple major versions. I'm not gonna pretend that I understand what, how this works. [00:46:56]

No one does, but thing is that they introduced. Another new directive. Now to recap a directive is these little strings that you just put in your code. Originally we had use strict back in the ES 2015 days and then React server components introduced, use server and use client, and now we have 'use cache'. [00:47:15]

And the idea is that by slapping this directive on certain components, that tells the next bundler and compiler that, Hey, this is the output of this component is supposed to be cached. I don't understand the details. From there, go read the documentation long. With that, they also announced a new long-lived workflow product, kind of similar to what the temporal company. [00:47:40]

Has built where you can have a function, for example, that implements a billing workflow by sweeping for 30 days and you've written what looks like one function, but under the hood it's actually like saving its status to a database and then a time job wakes it up and continues executing the code, that sort of thing. [00:48:03]

And I believe they opted to implement this also with a use workflow directive and like a use step directive. And I think there may have even been one or two others related to variations on caching, like use Cache, remote, something like that. And meanwhile, we've also got the React compiler has opted to use directives for a couple things. [00:48:23]

So there's a use no memo directive. If you want to tell the compiler, don't try to auto optimize this component. And so all of a sudden we've gone from the JavaScript language specifying. One directive. There was also the unofficial, oh, was it use a SM directive that was part of a SM js, the precursor to web assembly, but like one official directive in the language. [00:48:48]

And now we have a couple for bundlers, and now we have more for workflows and the compiler and all these other things. And so the Twitter discourse over the last couple weeks has been our directives, good or bad. And they're so confusing and they are changing the language. And you have all this bundler defined behavior that is not part of the language spec. [00:49:18]

Directives and the Platform Boundary

Mark: And so Tanner Linsley, again, creator of all the different Tan Stack libraries, put out a blog post where he expressed his opinion that he does not think directives are a good idea. Because they are unofficial, because they're not standardized, because make it not clear what the actual intended behavior ought to be, as opposed to like explicitly importing a function that says, turn this into a client server function or something like that. [00:49:41]

So there there's been a lot of arguing about directives and are they understandable? Are they good or bad? Are they too much magic? So that's been happening. [00:50:11]

Carl: I'll say it. They're bad. It's too much magic. I hate it. I'm not a fan. [00:50:22]

Mark: I understand the thought process. I, I can't say I'm thrilled. And so on that note, two article articles that are related enough to throw them into this section. [00:50:26]

Technical critique of Next App Router: Everyone Hates Next.js

Mark: I've seen lots of different article articles upset at Next or critiquing next. Most of them are frankly very badly written, but I saw one come out last week that I thought was very well written and focused strictly on the technical pros and cons of using the App Router. The title is Clickbait, everyone Hates Next, but the article itself is actually very well written. [00:50:34]

It discusses technical aspects of using Next, some of the problems his team went in, ran into, and how and why they ended up migrating from the App Router over to 10 Stack Start. And then Nadia Vic, who has done a bunch of very excellent articles on React rendering behavior, put together a very data-driven look into do server components actually help with things like First Contentual Paint and various other White House style metrics. [00:50:57]

So very worth reading. [00:51:26]

Carl: As I'm trying to think about how you might solve problems of caching and runtime things without directives. And I'm thinking about, you know, my experiences using like CloudFlare workers or other runtimes where it's not a traditional process scope. And I don't know, I guess like it is a really challenging question of like, how do you signal to a developer that the file they're editing runs in a certain type of context? [00:51:27]

And I guess I understand why directives are an appealing thing to reach for, but man, just the state we're in right now is really a lot. I found the Next.JS docs page with directives and it lists 'use cache', 'use client', 'use server', and then two sub variants of 'use cache'. And that's not all of 'em that, so there's missing ones here and. [00:51:56]

I don't know. When you start getting into like many different contexts, just naming them at the top of the file doesn't really seem like enough for me. I don't know. And then like the implication for that code can import other code that will not have it flagged what context it's running in via a directive at the top of the file. [00:52:20]

And I don't know. It's a tough problem. It's a weird unanswered question in the industry, like not even the ecosystem, but like the industry. How do you flag code that might run on your browser, a real server, serverless environment, and yeah, I don't know. It's a challenge. [00:52:40]

Mark: I think it really does speak to the overhead and mental complexity of trying to juggle all these things. [00:52:58]

We said earlier that React 19 has, 18, 19 have introduced a whole lot of things like transitions and other pieces to try to let you write better user experiences. But now you're having to juggle in your head like, here's the current version of my app in its display state versus a work in progress rendered version versus a future output rendered version. [00:53:04]

On the server side we're having to deal with, this is server code, this is client code, sometimes they're mixed together in the same file, sometimes they're mixed together in the same component. Which code is running? In which context do I have to worry about accidentally leaking security tokens or something like that. [00:53:28]

We're building tools to solve real problems, but there's more and more to juggle in your head as you go. [00:53:46]

Carl: Well, I'm gonna plug effect one more time because I saw it come up in the chat. Oh, man. It just like talking about different ways of signaling facts about the code. The code you're writing has certain dependencies. [00:53:53]

Certain dependencies is too loaded. That's, that carries too much context with it, but the code you write has a certain amount of assumption baked into it about what will be available and what it can rely on. The thing I love about a fact is that it makes that more explicit and brings it into the type system. [00:54:06]

So I think the challenge right now is that we are missing a like platform and language level abstraction to express information like this. And yeah, I don't think we're gonna get it anytime soon. And I think these explorations will lead to something like that and hopefully converge into something. But I think this is gonna be like a real state-of-the-art problem for a couple of years and still, which I hate, but it'll get better. [00:54:26]

⚡ Lightning round ⚡

Mark: Alright, moving on to the lightning round. [00:54:56]

ViteConf roundup

Mark: In addition to React Con and Remix Jam, we also had Vite Conf and the V team gave a bunch of updates on all the different tools they've been working on. Some of the highlights to me were that OX LT now supports ES lint and JS plugins via some really awesome tricks for interop between js and rust without the the cost of serial serialization. [00:54:58]

They announced a combined tool chain called v plus, which basically pulls all the different tools, VIOX lint, OX format, Vitest, everything else together. That'll be their enterprise sales targeted tool set. And then Vitest four is out with browser mode support. You basically just put a flag in your Vitest config and suddenly your tests are running in a real browser instead of a node plus js. [00:55:21]

AWS Outage Postmortem

Mark: Last week, AWS east went down and the internet died and they put out the postmortem and it was DNS apparently they, their internal DNS system for dynamo DB had like three different instances of the DNS updater running and one of them got stuck and was taking a long time to complete, and the other one came along and updated and then said, well, these, some of these plans look out of date, let's delete them. [00:55:49]

And next thing you know, DNS goes down, dynamo DB goes down and the internet goes down. So, oops. [00:56:19]

Mo: It's funny that the, uh, internet is backed by Dynamo db. [00:56:28]

Mark: A lot of people like us East One is the default. A lot of people have tried to get away from US East one, but when a lot of Amazon's own stuff depends on US. [00:56:31]

East one. Yep. You all [00:56:39]

Mo: of your certificates can only be issued in US East one, so that doesn't really help much. Side note, if you end up working in a consultancy one day, just hope nothing like this happens because the morning of was fascinating reaching out and getting reached out to by a bunch of clients being like, my site is down. [00:56:40]

And then having to figure out what's going wrong, which is US East one on AWS. So it was a fun Monday, [00:56:57]

Carl: but at least the uh, at the end of it was a vendor is out. This is not our fault. [00:57:02]

Mo: At least it was that, which was great. Cool. Moving on. [00:57:07]

Voltra

Mo: So a couple of React native lightning route items. Firstly ra, which is really cool because we've talked a little bit about live activities on iOS and iOS extensions, all of the little widgets and stuff that you can now use on your iPhone. [00:57:10]

And you were able to use iOS extensions within a React native app. But the challenge was you had to write SWIFT code to be able to actually implement those. And so a independent developer named S has been working on building an MPM package that allows you to ship these custom widgets and extensions without needing to use Swift X code or extra js, which is so cool because he's basically had to like write a translation layer or a render that takes React UI code. [00:57:24]

And converted to Swift UI code, which is not trivial because many have tried before him and failed. So this is a really cool project and like it's one of those things that's like kind of mind blowing. So kudos to him for making this. [00:57:55]

Building fully native apps with EAS

Mo: Secondly, and I thought this was an interesting article to link to. On the expo blog, they publish an article about building fully native apps with EAS. So EAS is expo's application services. Typically, this is being used to build React native apps that are usually running on Expo, but actually a lesser known fact, and one that we've actually used on some of our apps is that you don't need to be on Expo and you don't even need to be on a React native app. [00:58:10]

And so EAS is really great and it's become super mature and it's a really just good build tool for building mobile apps. And so people have started to use it in the wider mobile community rather than it just being a React native thing, which is quite cool to see. [00:58:39]

React Native \<\> Imgui

Mo: And lastly, this was something that Tzveton from the Hermes team in Meta actually, uh, published a week or so ago. [00:58:52]

And this was actually something he linked me on a DM because we were chatting about interesting things that could be talked about at a conference by a Hermes team. And this was quite cool to see. So for those who don't know, Imgui is like a very light UI layer that is powering a lot of sort of debugging for video games. [00:59:00]

And it's used in a bunch of other places, but like the key thing is that it's just like a very, very lightweight UI layer. And so he made a puck of basically using React and then rendering it on Imgui, which is quite cool. And it runs obviously like fully natively. It's fully running on c plus plus. And all it really needed was some typed JavaScript and it's basically just React really, which is quite cool. [00:59:18]

So yeah, it's just a little cool fun POC, but it shows the power of using React and how it can be applied to different contexts, which I thought was quite cool to include. [00:59:43]

Lodash maintenance foundation

Mark: Okay, Lodash has powered much of the JavaScript ecosystem for years. Those of us who have been around for a while, remember its predecessor, but low, has also been relatively unmaintained for a while. [00:59:53]

The author John David Dalton, said there was going to be a low dash version five, and then that never really happened, and so some announcements came out in the last week or two. That low dash is being taken over by a new maintenance foundation, and they're going to be doing work to update the ci, put out some new maintenance releases, and then apparently when low dash V five happens, it'll be more about stripping out a lot of the internals that tried to polyfill platform behavior and try and make it lighter and make use of platform built-ins at this point. [01:00:05]

So Lodash is still around, it ain't going anywhere, and good to see it being maintained. [01:00:40]

Build Your Own Key-Value Database

Mark: And then there was a really good post unrelated to React, but cool on building your own key value database system that walks through a whole bunch of pieces on what a key value database actually has to track and how the internals would work. [01:00:45]

And I believe it's actually pretty interactive, which is cool. [01:01:01]

Carl: This build your own database post, I love, this is so good. I love when people rebuild foundational building blocks. And this is also something I've thought about a little bit because he talks about in a file, you know, if you need to store something, put it in a file. [01:01:04]

And this is something I've thought about a little bit because I have been using SQL Light pretty extensively in my own work the last couple of years. And at the end of the day, sequel light is a file. So like when I realized that like most of the time. If I want to store something in a file, like I should just use sql, you put something in a file and then the file gets too big and you need to optimize it, and you need a better way to access it and like, oh, maybe I could use a more descriptive query language to get things out of it. [01:01:18]

And like the end result is that you will recreate a shittier less performant version of SQLite that doesn't use sequel. And so, I don't know. I just like reading this that was very strongly on my mind and everyone should do SQLite if they start putting things in a file. 'cause it's just a file. [01:01:44]

It's cool. I like it. [01:02:02]

Mark: The SQL Light website even has a page that says why, why you should consider just using SQL L as your app's file format rather than inventing another new binary format from scratch. [01:02:03]

Carl: A hundred percent. If you start right, if you start thinking I should put this in a binary format on disc, like no, stop it. Use SQLite. It's great. [01:02:16]

Jared Palmer asking for GH PR suggestions and giving some technical details

Mark: Alright. Jared Palmer, the creator of the Formik Library, has had been at V at Vercel for years. He worked on turbo repo, v0. And he announced just a month or two ago he was leaving Vercel. He has then announced that he has joined Microsoft as a senior VP at GitHub. And the first thing he did was post on Twitter saying, how can we make the GitHub PR experience better? [01:02:24]

And he got like eight or 900 replies, and he was pretty actively engaging with a lot of 'em. A lot of them were people asking for things like Stacked Diff support, so you could have multiple PR branches that depend on each other and be able to automatically update them. He actually came back even just a couple days later and gave some technical details that he had found after internal discussions on here were some previous prototypes of stacked diffs at GitHub and how, like how far they got and what the blockers were. [01:02:53]

So I have no idea how long it'll take to roll out any of this stuff, but like he seems pretty serious about trying to improve the PR experience, whether it's paper cuts or new functionality and is trying to look into that stuff. So given that we all pretty much depend on the GitHub PR experience, I'm happy to see improvements. [01:03:25]

Carl: Yep. Love that. Wow. This is very jargon heavy. [01:03:45]

Mark: Yeah, I, I know, that's why I was happy to see it. Cool. [01:03:48]

Carl: Sounds like a technical roadmap. [01:03:51]

Node 25 with JSON.stringify improvements

Mark: Couple other bits, node 25 is out and so another development line branch for node and the biggest thing there is they've updated the version of V eight and that includes those faster js ON string of FI improvements that we, we talked about a couple months ago. [01:03:54]

So given how much everything depends on JSONs string offi, it's nice to see that being sped up. [01:04:09]

Cloudflare vs Vercel CPU benchmarks and perf optimizations

Mark: And speaking of more optimization work, I believe Theo put out a benchmark where he was comparing CloudFlare in Vercel in Building Next versus Vanilla versus a couple other things. And it pointed out places that both Vercel and CloudFlare were slow and CloudFlare jumped on this and they found a bunch of places in their system. [01:04:15]

Where things could be optimized. They did a excellent blog post detailing some of the improvements. They also went in and they looked at next itself and they found a bunch of places where Next is doing like useless request copying like 1500 or 1700 request streams per request or something like that. [01:04:36]

So basically everybody is getting faster as a result of this, which is a good thing. [01:04:57]

Mo: CloudFlare folks are just doing some great work recently, especially with the whole like workers rebrand as well is really cool. [01:05:02]

FF Interop Feature Request Rankings

Mark: So Interop is an attempt to get all the different browsers on the same page in terms of what features they're working on, especially around compatibility with each other each year. [01:05:07]

And so this year the Firefox folks put up a rather nifty interactive suggestions thing where they list dozens, like 50 or a hundred different potential features or technical areas of emphasis that they could spend time on. And it's got a neat drag and drop interface where you can basically use that as a way to vote for which features do you want browser manufacturers to work on? [01:05:19]

This year. [01:05:44]

Carl: Love that. Yeah. They say they're gonna publish the final selection of proposals in February, so I'll, I'll keep an eye out on that, I guess. Cool. [01:05:45]

Vjeux’s History of Prettier

Carl: Chris Chedeau, vjeux, he has been really prolific in the React ecosystem for many years. Was really influential in React becoming open source and was the original author of Prettier, which changed my professional experience significantly. He put out a blog post titled The Birth of Prettier earlier this month. I'd spent almost 10 years since Prettier was released. He says, which is wild. I like his introduction of this is the story of how the tabs first spaces Holy War ended, and yeah, it did. [01:05:53]

I appreciate that. I actually just did a little DX PR for a code base. I maintain to make better use of prettier because somebody created a plugin to sort imports and like, yes, I love that. I hate sorting my imports and I hate when of my imports are not sorted. The introduction of automated formatting into the JavaScript ecosystem was, oh, what a, what a blessing. [01:06:23]

Like what hours? The years of my life that have been saved from arguing over formatting is just really lovely and this is a great retrospective. Looking into just the whole process of how it came out. [01:06:46]

Mark: There's some fascinating details in there. [01:06:58]

Carl: Yeah, like one of the challenges of this that I remember in the moment a little bit, but like if you're gonna start formatting things, the format needs to be something relatively unobjectionable to the people who are evaluating whether they want to use it or not. Like, yeah, so, and then figuring out what options should be exposed, what is actually configurable, because if you make it too configurable, then it's not helpful. If it's too much manual thing, then it's not actually consistent enough to be valuable at its intended purpose. [01:07:00]

So lots of really interesting details throughout here. Definitely recommend it. I always love a great technical white paper, a writeup of implementation, and this is, oh boy, is this that. It's great. [01:07:37]

Mark: One of the most interesting bits I saw was he was talking about how they started rolling it out and like Prettier has some options, but they wanted to minimize them and he wanted everyone to basically agree on a single set of options. [01:07:49]

And so he said the strategy I used to figure out how to make this work was lining up incentives so that it took a ton more work to use a different set of options if you wanted to. It said Prettier is either in this, in CI or in your IDE. So I made it so that they read them from different places with a different rollout schedule to make it harder to choose one or the other. [01:08:02]

Carl: Oh, that's incredible. That's some good details. Reading this a little bit more is it's got lots of fun non-technical details that like they're not the engineering work, but they are absolutely essential for actually making a thing that is successful and sustainable and thriving. Like it also talks about money and like ongoing maintenance is a thing that you have to pay for. [01:08:24]

You don't have to, I guess most open source does not, but if you don't, then it has its own challenges. So like not only is this a great technical writeup, but it's also a great, I don't know, like entrepreneurial writeup. [01:08:45]

Mark: How do you do the, the real work to make stuff happen? [01:08:55]

Carl: People talk about the difference between like senior and staff engineering being, the difference between junior and senior is how much English you're asked to write. And the difference between senior and staff is like how much non-technical things you're asked to account for. And so this is a phenomenal, I would say, staff engineer writeup. Like, this is how you take an idea and you make it an industry level impact project. Yeah. Great Writeup. [01:08:58]

Mark: I can even point to a couple personal examples of how prettier has affected my work just within the last few days. [01:09:23]

One is that I'm jumping between the Redux repo, which is two spaces, single quotes, no semicolons. The Immer repo, which is four spaces, double quotes, and I can't, and may, maybe no single semicolons, Replay.io repo, which is four spaces, double quotes, semicolons, and I don't think about any of that anymore. [01:09:28]

And then also just yesterday, I was trying to tweak some of ER's exports and tried to put in an export type keyword, which I was pretty sure was a legit thing except that when I hit save, it didn't format. And I have learned that if it doesn't format, I have put in invalid syntax somewhere for a moment. [01:09:52]

It was like, oh, export type must not be a valid TS keyword. And then I finally realized, oh wait, this is on prettier 1.19. That must predate that syntax being added to TypeScript. And so I had to update prettier, but like that's how much I have learned to lean on. You hit save and it formats and it's valid. [01:10:16]

Carl: Yep, a hundred percent. I, I recognize that in myself as well. [01:10:37]

Conferences (React, Javascript)

Carl: Okay. Let's wrap it up with some conferences. [01:10:41]

React Native London Nov 13-14 London, UK

Mo: Let's jump into it. So we've hinted a few times and I can now say that we've got Seth Webster's endorsement. So the executive director of the React Foundations talks about my conference. I'm very happy today. [01:10:43]

We've been organizing this for the second year, so React Native London for anyone who's a React native enthusiast in London and beyond. We have people from Brazil and India last year, so that's like the furthest extent that we have people coming in from around the world. But if you are interested, we've got our conference on the 13th and 14th of November. [01:10:55]

In Central London, we've got a beautiful venue, some great talks from Meta, Amazon, Microsoft, and just a bunch of community people from expo and independent app developers who are gonna come and give some really, really phenomenal talks. [01:11:14]

Use code `TMIR10` to get 10% off

Mo: Use the code TMIR 10 and you should get a 10% discount on checking out, which will, if I'm doing my mental maths right, make the ticket price 330 ish pounds for a two day conference to be able to attend workshops and the conference day. [01:11:26]

Wey Wey Web Nov 17-18 Malaga, Spain

Carl: Um, other ones we've got coming up are Wey Wey Web November 17th and 18th in Malaga, Spain. [01:11:42]

React Summit Nov 18, 21 New York, NY, USA

Carl: We've also got React Summit November 18th through 21st in New York. [01:11:49]

Mark: There's JS Nation on the 17th. There's in-person React Summit in person on the 18th, and then they have an online day the next week. Okay. [01:11:54]

Carl: Oh, oh, oh yes. [01:12:02]

I see it's 18th and 20th, not through. Interesting. One day in person. One day online. Okay. Makes sense. [01:12:03]

React Advanced Nov 28, London, England

Carl: There's also React Advanced November 28th, also [01:12:10]

Mark: in London the day after Thanksgiving. Someone in England didn't think about that part. He, he, he, [01:12:13]

Carl: yeah. It's not for Americans. [01:12:19]

Mo: It's not just React Advance, it's also Tech Lead Conf, which is also organized by the Ation folks on the same day in London as well. So, no, I would doubt that there's gonna be a lot of people from the states there, unfortunately. [01:12:21]

Carl: For sure. [01:12:32]

React Paris CFP is open

Carl: Well, I'll, I'll also add, I just saw like two days ago, the organizer of React Paris posted in the events channel here that CFP is open, so we gotta React Paris if you want to submit a talk. But that's gonna be in like March though, so not anytime soon. [01:12:33]

Ending

Carl: That's all we got. Thanks so much for sticking around for a whole 90 minutes. [01:12:49]

Mark: It was a very busy month. Okay. [01:12:53]

Carl: Yeah. We'll be back next month, on the last Wednesday here in the live stage or back in your podcast feed just as soon as we can. Yeah. Thanks so much. Well, normally we gather sources from a variety of newsletters. We actually had so many things that Mark shared in the tech reads and news chat this month that I don't think any of us did. So that's cool. [01:12:55]

Mark: And I pasted a lot more links in the discussion threads too. [01:13:15]

Carl: That's something I should be better about. That would be lovely and helpful. But yeah, if you see anything newsworthy, definitely let us know in the Tech News and Reads channel, just like Mark has been doing. [01:13:18]

You can also email us at hello@reactiveflex.com. But you know it's a community like Join, participate. I do read every email though, so if you send something I, I will read it. 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 and by telling your friends and coworkers about it. [01:13:27]

And go to a meetup and say, Hey, there's this great podcast I love. [01:13:44]

Cheers. See you next month. [01:13:47]