Reactiflux - Transcripts

TMiR 2026-06: React Compiler is getting rusty, what does AI mean for engineering culture

Reactiflux — Tue, 23 Jun 2026 16:00:00 GMT

[00:00:14] Intros
[00:02:31] New releases
- [00:02:34] React Router 8
- [00:05:39] Babel 8
- [00:07:15] Astro 7
- [00:09:13] TS 7.0 RC
  - [00:09:42] ESM only, no programmatic API right now
- [00:10:41] Nub JS, from Zod creator
- [00:14:13] Legend List 3.0 with DOM support
- [00:14:44] TSRX revamped the syntax
[00:16:28] React Core news
- [00:16:32] React Compiler in Rust is rolling out
- [00:18:57] Other core improvements
  - [00:19:17] Fragment Refs have been documented in canary
  - [00:21:42] React DevTools MCP tools, including component tree and perf analysis APIs
- [00:22:28] React Foundation progress
  - [00:22:39] There’s a(n early) react.foundation website, advertising funding for maintainers and community groups
  - [00:25:41] They’re gonna have a booth at Chain React at the end of July
[00:26:11] Why is Meta destroying its engineering organization?
[00:32:46] AI demands more engineering discipline. Not less
[00:40:51] Christoph Nakazawa posted his “Modern Engineering Values” and how he uses AI
[00:42:42] Cloudflare bought VoidZero
[00:43:44] NPM / security updates
[00:46:25] Code optimization still matters!
- [00:46:53] TanStack Table cut memory in v9 by 90% on large lists by optimizing JS objects and optimized TS perf
- [00:47:25] Pierre Diffs was significantly optimized - has to handle virtualization, syntax highlighting, source loading
- [00:48:38] CompileCat is a new optimizing compiler to improve JS execution after bundling, similar to Closure Compiler. (the RSPack team says they’re working on something similar )
- [00:51:22] Mark’s React-Redux \+ signals draft perf PR and updated React-Redux benchmarks repo
[00:52:51] Aurora Scharff’s preferred RSC component architecture
[00:53:34] Lovable projects now use TanStack Start by default

This Month in React: June News Roundup

Carl: All right. Hello. Thank you for joining us for the June edition of This Month in React. We're coming to you live from Reactiflux, the best place for professional developers using React. [00:00:05]

Intros

Carl: I am Carl. I'm a staff product developer and freelance community leader here at, Reactiflux, where I do things like build Euno, a moderation bot that helps us keep the community operating. [00:00:14]

Mark: I'm Mark Erikson. My day job is at Replay.io where we use time travel debugging to build things like automated QA tools and awesome React analysis. And outside of that, I run around at conferences, give talks, and work on Redux [00:00:27]

Carl: Heck yeah. The big news that we wanna discuss this month, is around some changes that shipped for the React compiler. it's in Rust now. There you go. It's the news. You don't have to listen. Yeah. we're gonna talk about Meta and we're gonna talk about its engineering culture, b- framed around a blog post from Gergely Orosz, who is wonderful and a great writer. yeah. Talk a little bit more about AI, 'cause of course we are, and some broad best practices and stuff. [00:00:41]

Carl (editing): And I'm trying something we haven't done before today. I'm gonna self-sponsor this 'cause we don't have anyone else paying our bills right now. [00:01:05]

Uh, we are sponsored by Euno, a moderator support tool for Discord, offering one-click setup for spam defense, moderation audit logs, and decision-making tools. That's euno.reactiflux.com, E-U-N-O.reactiflux.com. Uh, Euno is named after the goddess of good order and lawful governance. Uh, it helps moderators make decisions about bans together while automatically filtering out compromised account spam. A single setup/command gets you anonymous user reports, shared moderation history and resolution voting, a private ticketing channel, and anti-spam based on message velocity. [00:01:10]

With a 90-day trial, you can get a feel for it before deciding if $100 per year is worth the time you'll save banning spammers and deleting garbage. If you have a Discord server, give it a shot and let me know. That's euno.reactiflux.com, E-U-N-O.react iflux.com. [00:01:43]

Mark: Yep. congrats to you, Carl. Thank you for all the work you've put in on this, and I can, vouch that this has been very thoroughly tested on our end [00:01:59]

Carl (editing): We're also sponsored by me, Carl. Uh, these episodes cost me about 300 bucks out of pocket each episode, uh, for editing and supporting tools. If you'd like to learn more about anything Mark and I discuss, let's talk about consulting or a contract software engineering gig. [00:02:06]

You probably know where to find me, but Discord or email is the most reliable. I'm at vcarl, that's Victor Charlie Alpha Romeo Lima, @reactiflux.com. Let me know [00:02:21]

New releases

Carl: But yeah, first the new releases. [00:02:32]

React Router 8

Carl: First up, React Router v8 shipped. We got that now. yeah. This... they talk a lot about the early days of React Router, and it... [00:02:34]

they're, like, proactively trying to manage the pain that people experience because, I... React Router got a reputation for shipping a lot of breaking changes with every new release. I guess specifically they got a reputation of flip-flopping back and forth between two different paradigms, like every other release, and it just frustrated a lot of people with, "Why do we have to refactor again?" So it's funny how much of this blog post is dedicated to saying, "We're not doing that anymore, we swear. Please don't hate us." [00:02:43]

But yeah, generally it looks like this is essentially a no-op versus the latest version of v7. if you are already using the latest version of seven with no, deprecated features, it... [00:03:09]

This should be a drop-in replacement. yeah, I think this, As far as I know, the mo- most of what th- this is bringing out is, emphasis on the framework mode. [00:03:22]

Mark: I know that they've done a lot of work on trying to use feature flags to make new features available, essentially following the, majors don't introduce new stuff, they just remove old stuff kind of a [00:03:31]

Carl: pattern. [00:03:42]

And see, so the feature flags are the way that they implemented the better, major version releases. So th- now by the time, by the end of the previous major version release, they will have introduced new feature flags for everything that they are about to release in the next breaking change. [00:03:44]

which is, it's really smart. I actually really admire that method of changing. managing feature flags, I have experienced, adds a lot of complexity to day-to-day development. and I have a ton of respect for them for landing on this process for releasing new changes, new features, new abilities to their widely used library, and here they are still, eight years later after they started using this, still putting it to practice. [00:04:01]

Mark: Couple interesting notes from the support matrix here. Node 22, okay, that's fine. they now require at least React 19.2 [00:04:25]

Carl: as [00:04:37]

Mark: a minimum version, so that... I, don't know if version 7 expected 19.0 or 18, I would have to check. But just noting that React Router now requires the latest and greatest React 19. [00:04:38]

And also the package is shipping as ESM only, we are very clearly now on the trend of lots of tools and libraries going ESM only. there was the early wave of tools that went ESM only and everyone else complained because it didn't work right. [00:04:50]

And now with, some of the improvements to Node itself, we're seeing a lot of packages say now is the time to go ESM only [00:05:07]

Carl: Yeah, we've got another release that went ESM only next. [00:05:16]

I wanna flag, I just found... I was clicking through the blog post and they have a link to their governance document, which explains their new feature process. and actually this whole document is very well thought out and I would highly recommend that you familiarize yourself with this governance document, 'cause, it's just a bunch of really high quality engineering practices. [00:05:21]

Definitely check it out. [00:05:38]

Babel 8

Mark: So on the, ESM note, Babel 8 just shipped, and the, big highlights there, the Babel packages themselves are also now ESM only. TypeScript types are built in, and the default compilation settings for building your projects no longer target ES5 or CommonJS. So essentially they're saying we've, rather than necessarily being about backwards compatibility by default and always trying to cross-compile your code to, support, IE 11 or whatever, now we're targeting the modern JavaScript ecosystem. Which is also pretty much what, TypeScript 7 is doing as well. [00:05:39]

Carl: I am extremely here for that transition. I wish that it had happened several years ago. Babel as a compatibility layer I think is really good and really great, but we've been on evergreen browsers for most of my career at this point, and I, yeah, just, the long tail of what it means to support ESM 5 and Require is just, it's really... [00:06:23]

That tail's really long at this point. It's very far away. I don't know. I, think the, trade-offs are not quite there. Yeah. Yeah, Babel 7. I don't know. I've, Are people still manually installing and managing Ba- Babel versions themselves? This feels like something I haven't wrangled with personally in a long time. It's all downstream of the rest of the tools I use [00:06:44]

Mark: Yeah, I'm disconnected enough from day-to-day app development that I don't have an answer to that question. [00:07:07]

Carl: fair. Ha Okay. Anyway, moving on. [00:07:12]

Astro 7

Carl: We've got Astro v7, major release of Astro. Astro's a project that I have always meant to explore more deeply than I really have. I have used it for a, trivial project here or there. If you're building a static portfolio site, brochure, marketing, whatever you wanna call it, it's really good. it hits a good balance between engineering ability, it gives you escape hatches to manually control stuff, while still being largely content oriented. [00:07:15]

So it's very good if what you're managing is what's on the page rather than, like, how it behaves or what data's available. so it, not as great for a full app. there are certain types of apps that work great in that environment, but an application less [00:07:46]

Mark: Like my mental model of Astro is it essentially replaces Gatsby [00:07:59]

Carl: Yes [00:08:03]

Mark: in terms of, we, we pull in data sources, we build sites that are static by default, but can have lots of dynamic content with your rendering framework of choice [00:08:04]

Carl: Would agree with that, with all the same caveats of a lot of apps need something a lot more complicated than that. [00:08:14]

But if you're building co- a content site, it's a really great tool for that. Yeah. Looks like mostly they're touting, s- build improvements, upgraded internal dependencies, V8, new roll down bundler. [00:08:19]

Mark: Faster markdown parsing. [00:08:33]

Carl: Yeah. Advanced routing to give you a single entry point with full control over the request pipeline. They can detect coding agents automatically that looks like a local development feature. It's, you can run the dev server in the background and output structured JSON for machine-readable feedback. That's really smart, actually. I love that. there's a ton of cases where, just like in testing and such, raw human readable HTML and CSS, it... that's just a lot of content. It's a lot of bytes. It's a lot of tokens. so giving machine-readable outputs at the framework level is really helpful. I like that a lot. That seems like a really smart feature, and I think we're gonna start seeing that for more. [00:08:34]

TS 7.0 RC

Mark: And I mentioned this a minute ago and we've mentioned it in previous episodes, but TypeScript version 7 is now at release candidate. think the biggest change here from a user point of view is that p- the previous releases had shipped as a separate native preview package and now it's the actual TypeScript package itself, the RC tag has all new binary and faster compilation stuff in there. [00:09:13]

ESM only, no programmatic API right now

Mark: One other thing to note is that the, 7.0 release, number one, it builds off 6.0 where they change the default settings to favor modern compatibility instead of backwards compatibility. but then also 7.0 will not ship with a programmatic API. So tools that depend on the c- on the TypeScript compiler package to programmatically drive compilation, parse files, do that sort of thing, will not work out of the box with 7. [00:09:42]

The idea was get the full working compiler in people's hands now and they're still trying to nail down the details of what the programmatic API will be like, and they're hoping to have that out in a 7.1 [00:10:18]

Carl: Cool. Nice. Yeah, and we discussed that at more length last month, so I don't know that I wanna rehash all of that again. Difference between beta and RC is just not that big. [00:10:31]

Nub JS, from Zod creator

Mark: Okay, the, the next one's very interesting. Colin, the creator of Zod, just announced something called nub. Those of you with keen eyes will notice that this is bun backwards, in the same way that Deno is Node rearranged. clearly there's only so many letters we can use in naming JavaScript runtimes at this point. [00:10:41]

The s- the sales pitch for this, Node was run JavaScript on the file system outside the browser. Deno was, "Oops, we made a bunch of mistakes designing Node. Let's completely redesign the security and the process architecture and bake a bunch more stuff in." Bun was, "Let's build Node compatibility on a different JavaScript engine, and also add every other built-in programming method and API we can think of while we're at it so it does everything at once." [00:11:07]

Nub, on the other hand, is, "Let's start with actual Node, let's override a bunch of its configuration options, and let's build in a more modern environment, things like better TypeScript stripping and better, package JSON handling and a bunch of other pieces into Node directly so it feels like Node much better rather than one of the, one of the other options." [00:11:43]

I, like this idea. we've been using things like ts-node and TSX and all these other type-stripping approaches. Node has a type-stripping option built in. This apparently goes up to the level of being able to output the non-strippable pieces of TS syntax, so like e- enums and things like that. But then it bakes in a whole bunch of other features as well. I like this idea. I, it, makes a lot of sense to me [00:12:15]

Carl: I'd agree. It's interesting. I was always skeptical about Bun because of what you said, it starts from a brand-new runtime, and runtimes are difficult. It's hard. It's... Getting it right is tricky. clearly it's worked well enough for many people, but I've struggled with it a little bit. [00:12:45]

Sure, There's plenty of room for opportunity in the tools surrounding Node.js as well. But I'm skeptical of this package manager. It says a pnpm-compatible manager built in, and it, reads whatever lock file you already have, writes to the same format. I don't know. I'm skeptical of that. look, we made a magic package manager that is cross-compatible with every existing package manager. sure, I'm sure you did. Can't wait to find out what bugs you missed. [00:13:02]

Mark: I saw a tweet from Colin where he said that this was all implemented with AI, not surprisingly given today's no but it, but there was a lot of very careful planning and, defining the feature set and working out the requirements and then, using the agents to actually do the work on it [00:13:33]

Carl: And, like we s- we were talking about last month, if you've got an existing set of tests to make sure that your code works against which all of these open source package managers are going to, then it's definitely a lot easier to create a functioning replacement. [00:13:52]

yeah, I don't know. It's interesting. Curious, we'll, we'll see how it shakes out. We'll see if it works. see how it does for people [00:14:06]

Mark: Yep. [00:14:11]

Legend List 3.0 with DOM support

Mark: Another release announcement. Legend List 3.0 came out, and this is originally, I think the original version of this was React Native only. Jay Misiorek's also the creator of the Legend State Signals library. but apparently he's figured out how to port the underlying list virtualization logic over to React DOM as well, and says that it's one of the fastest, if n- if not the actual fastest virtualized list implementation out there . [00:14:13]

TSRX revamped the syntax

Mark: And then, other follow-up note, I think it was last month we had mentioned something called TSRX, where Dominic Ganaway and the Ripple project had said, "We're, annoyed at the JSX specification being stuck for, the last 10 to 12 years. [00:14:44]

We have come up with what we think is a better syntax, that, adds more flexibility." And, after they announced it, they got a bunch of feedback on, people not liking some of what they designed. And so th- they did a couple different blog posts about how they've stepped back and rethought what the syntax is. [00:15:02]

Things like, the original TSRX wanted you to put quotes around every bit of text that you had in there, whereas JSX just is angle bracket, words, angle bracket. And so they've, gone back to that as a syntax for text. So to be honest, I don't have a good mental picture of what the actual differences are between this and JSX at this point, 'cause I, haven't gone through it in detail. [00:15:21]

But they, looks like they do have some control flow syntax embedded as well. so they're somewhere in between their original p- proposal and standard JSX at this point [00:15:49]

Carl: Neat. It's a big swing. I said last month that I think it's interesting that now in the AI era you can just update documentation and the tool knows how to use it, which was not the case for previously. So that might make it easier for tools like this to succeed, because you can just drop in a different markdown document and the tools will know how to write the new code, so to an extent. It's not perfect. [00:16:02]

React Core news

Carl: Let's get into the main content with some React core updates first? [00:16:28]

React Compiler in Rust is rolling out

Mark: All right, so the biggest thing this month is that the React compiler port into Rust has officially been merged, and there's been a whole flurry of activity of different build tools now trying to actually integrate this. so the React teams had said, "We have been trying out the port at Meta. It appears to emit identical results with the TypeScript implementation of the compiler." [00:16:32]

PR was merged after testing at Meta and improved

Mark: they did a bunch of work to optimize it and handle some more cases, and the PR itself got merged, about a week-ish ago, I think. So now that it's at least more or less available, then the question is, how do you actually use it? [00:16:57]

I don't know if you can actually just install the Rust version of the compiler right now. I'd have to double-check that. But n- since we have a whole bunch of build tools, and most of today's build tools are now written in Rust, a lot of different teams have been exploring how do we actually integrate this into the build tools. [00:17:14]

Oxlint, SWC, RSPack, Next all integrating

Mark: So Oxlint, SWC, RSpack, Next, and Bun have all been trying to figure out how do we integrate with this, make it a, an option or built-in or something along those lines. [00:17:35]

Rolldown tried integrating directly but removed due to binary size increase

Mark: One interesting note is that Rolldown tried to actually add this into their system, so there would just be a built-in turn on the React compiler option. [00:17:50]

And what they saw was that it increased the binary size from, 28 megs to 33 megs, and they decided that was too much extra size to force everybody to download, actually reverted it, and they're exploring further options on how they can integrate it. [00:18:01]

Bun tried optimizing the Rust Compiler code

Mark: On the other hand, Bun taking the Rust code and tried to both integrate it and also see can we improve the Rust code itself to make the compiler run faster. [00:18:18]

I think a couple of the other teams have also been seeing, now that the Rust code for the compiler exists, can we also make it faster as well? So there's clearly still a lot of development opportunities for different teams to explore in terms of how is it integrated into the build step, how fast does it run, but we now at least have the merged PR as a baseline for all that different work [00:18:33]

Other core improvements

Mark: Couple other things I noticed. one is that the React team has been working on something called Fragment Refs for a while. We, might have mentioned this once or twice in the past. [00:18:57]

Carl: Yeah, I think not a long time though. It's b- it's been a minute [00:19:08]

Mark: it's been a while. The PRs were sitting out there or getting quietly iterated on. [00:19:11]

Fragment Refs have been documented in canary

Mark: So the idea for a Fragment Ref is that a React fragment by design does not have any single DOM node associated with it, because it's meant to be like a virtual container for many children. That's why we wrap them in a fragment in the first place. but what happens if you want to do something like listen to a DOM event for any of the children directly underneath the fragment, or perform some other DOM operation? [00:19:17]

So Fragment Refs are a, I think, now in Canary feature where you can put a ref prop onto a fragment and you get back something that looks like a DOM node in terms of the methods you can call, add event listener and that sort of thing. and under the hood, React just does the work to pass the references on to all of its children automatically. [00:19:48]

So it looks to your code like you're dealing with an actual DOM node, and under the hood, React takes care of, oh, there's 15 children directly under this fragment, let me just collect the interactions with all of them. So, that is apparently now in Canary, and they've actually updated the documentation page on fragments to say that you can use refs on them [00:20:16]

Carl: Nice. Cool. the value here I think is really specific, and, it might, be unintuitive. it... let's say you wanted all of those DOM methods you just talked about, you wanted to be able to measure the size of this block of nodes or add an event or whatever. [00:20:40]

Another way you could do that is to wrap it in a div. If you have a div, cool, great, free DOM node. You can do all those things. but that doesn't work in certain layouts. if you wanted to have a grid where all of them share a single, drag end event, you can't just wrap that in a div because that breaks the grid layout. [00:20:57]

So this is a situation for, flex or grid, where there's an implied mandatory hierarchy of the DOM nodes itself, and you are rendering those s- containers, those children, s- let's say from a map. You're mapping over data, then this is super helpful for adding a whole bunch of different types of behaviors, which is why it's worth the effort. [00:21:19]

React DevTools MCP tools, including component tree and perf analysis APIs

Mark: And then one other thing that I have a vested interest in, the re- there's been a series of PRs posted to improve the React Dev Tools by adding MCP tools so that agents can query and inspect it. some form of imperative API so that you can programmatically ask, what is the component tree, and even turn performance profiling on and off. [00:21:42]

and then some, some additional wrappers to expose that data. I've spent a bunch of time doing React performance analysis work. I am doing some of that at my day job right now. so I'm, I am also keeping a very close eye on this because it's very heav- heavily related to my interests. [00:22:08]

Carl: Yes, it is. Yeah, and we've got... [00:22:26]

React Foundation progress

Carl: we mentioned briefly the React Foundation last month, and most of what we said was that we haven't been able to see very much of what's happening. We can see things. Visible change is happening. [00:22:28]

There’s a(n early) react.foundation website, advertising funding for maintainers and community groups

Carl: The React repos have moved, there's also a new website being developed. I've seen some chatter about that. [00:22:39]

Mark: Like the, foundation page exists, but the, uh the current form of the page is very vibe coded. And so, a- they're, like what's there is accurate, but not well designed. [00:22:46]

Carl: Yeah, it is definitely vibe coded vibes. but yeah, so that, that, should change soon. [00:22:59]

Mark: The, couple of the interesting bits for me, if you look at the, React Foundation website right now, there's a strong emphasis on helping support the community financially. Some of that is they're apparently intending to sell swag, shirts, and whatever, they intend money fairly to maintainers of some of the most common React ecosystem libraries. They also talk- they've also talked both in the past and I think on the website about helping financially support different, communities, meetups, conferences as well. And then I think they are taking over running the official React Conf as well [00:23:05]

Carl: Yeah, I know that they've actually been having some struggles getting meetups. they wanna support local React-based meetups, people aren't doing local React-based meetups anymore. It's all AI stuff or whatever. it's... I think the... I, think my intuition here a little bit is that some of their mental model for how the React community exists is still, maybe not fully reacted to the shifts over the last two years. [00:23:45]

I love the idea of collecting nonprofit donations and then distributing them out to library maintainers. I think that is super, super good. And doing it with a, proper foundation with, governance and a board of directors is super good. I've ac- I actually thought quite a bit about trying to do a business adjacent to this, just, hey, we got a community. [00:24:14]

What if we did, a bunch of little events and had a membership subscription or whatever, and then funneled 80% of that money to the people who make the community exist. and I, ended up not just 'cause it's it was hard. It's a lot of work. It's a ton. Access also helps. starting from I am the manager of the React core team is a very strong position to create a foundation. [00:24:35]

Mark: the flip side of all this is that as I discussed last month, I have no idea what's going on with the development of React itself. the- there's PRs around the compiler and the dev tools. I really haven't seen much activity on the core library in the last few months. [00:24:58]

Joe Savona c- and put up a post confirming that he is no longer on the React team at Meta. He's now working on something AI related. and then that kind of ties into what we'll talk about in a minute with what is going on at Meta anyway. So here feels like the development process on React itself is rather fragmented and confused right now [00:25:14]

Carl: Which is unfortunate. [00:25:39]

They’re gonna have a booth at Chain React at the end of July

Carl: But if you wanna talk to the core team or, some members of the foundation, or generally people close to the development of React, they will have a booth at Chain React, July 30th, which it's a React Native conference specifically, And it is, where is it? And it is in Portland. So yeah, if you're, around the Pacific Northwest or willing to travel, so yeah, check it out. [00:25:41]

Okay, moving on a little bit. jumping off your tangent you just teed me up for, thank you. [00:26:04]

Why is Meta destroying its engineering organization?

Carl: Why is Meta destroying its engineering organization? this is a newsletter post put out by Gergely Orosz, who's very influential, I would say. He puts out a, pragmatic engineering newsletter. It's very good. I read it occasionally. I read posts from him. [00:26:11]

Mark: well written and sourced [00:26:27]

Carl: Very well-sourced, very timely. He does a good job of being timely. so y- this is a, this, is again, a well-written, well-researched, well-presented post, talking about the engineering values of Meta historically. it brings in the, original Facebook little red book, which is a little, culture document describing the values of the company. [00:26:28]

Mark: move fast and break things, but also like a, lot of stuff about how we want to think about building stuff for the customer [00:26:48]

Carl: Yeah. okay, so Move Fast and Break Things is notorious. here are eight, no seven other values from the same book. [00:26:57]

Done is better than perfect, [00:27:05]

fail harder, [00:27:07]

what would you do if you weren't afraid, [00:27:08]

every day feels like a week, [00:27:10]

the Wright brothers did not have pilot licenses, [00:27:12]

the foolish wait and fortune favors the bold. [00:27:15]

And I don't know, a lot of those are values I can, agree with. [00:27:17]

Mark: It's better to get something done and see what happens than to waste all of our time discussing if we should try doing something [00:27:22]

Carl: Yeah. Yeah. So I don't know, it's, it's a good doc. This is good speaking about the engineering cultural history and some of the actual timelines of improvements and, releases that they made. and it's, it lists a number of problems. th- they started tracking engineers' keystrokes with no way to opt out on work laptops. [00:27:28]

it says "30 to 50% of engineers and core teams have been forcefully reassigned to data labeling." You think you're gonna be a core AI engineer and oops, you're just n- t- you're a competent, skilled professional tagging data the same as a legion of other competent, skilled professionals training your replacement. [00:27:52]

I have a, friend of mine who was recently laid off from Meta who has been involved in, basically, just trying to resist this type of pressure. like for being forcefully reassigned to a team that you are not interested in being on, that sucks. [00:28:10]

and it's part of your contract. It's ultimately, at the end of the day, you're in a hierarchical corporate system. They have hired you to perform work at their leisure, at their desire, and it is entirely within their legal contractual right to say, "You work on this now." [00:28:24]

and that doesn't, What if it, wasn't their contractual right? What if they did have to actually negotiate with you and put you somewhere that was mutually compatible? So I don't know. That's, that's the pushback that they have been trying to support and organize. [00:28:40]

But, meta is maybe not doing so great. I guess, one, one concrete engineering point that this, draws attention to was the r- disappointing AI model development. Like losing momentum effectively. Like Llama 1, 2, 3 were all very cutting-edge and competitive, and Llama 4 released over a year ago now, which I guess was the last release. I don't know of another release from them. [00:28:53]

so yeah, I don't... as a symptom of declining engineering culture, their frontier AI model is no longer competitive. [00:29:20]

Mark: Yeah. So some of the points it makes is that they, they, used to have v- pretty good engineering culture based on we're, trying to build the right things the right way at scale. The question of, whether the apps that they're building are useful for society is a different question, but at least they were mostly trying to build them the right way. [00:29:28]

And now it seems like in the last year or two they have shifted to a focus on AI. They've had a bunch of layoffs. Engineers have been forcefully reassigned, and the, I know the performance review topic c- has come up repeatedly when I've talked to even, React core team members. They, they want to spend their time doing things that will benefit the greater React community, but they have to, in order to get good performance reviews, they have to show, like, how is this actually benefiting Meta the company. [00:29:44]

And so whether that's something like, "We're gonna build this new React feature because it makes Ads Manager faster," or, just, interactions in some way. So that I know has been a struggle just for the React team, and it's clearly a major problem for everyone else at the company at this point. How justify my existence? [00:30:16]

Carl: there's a book that I love called Moral Mazes that speaks a lot about this type of problem. we, we're talking about engineering culture. [00:30:35]

That's... Culture is the downstream result of a vast group of people interacting with each other. The culture is the emergent property of how those individuals interact with each other. And Moral Mazes is a really wonderful sociological study of the firm, the c- the American corporation. And so it ends up speaking a lot about subjects like performance reviews. [00:30:44]

And here in this blog post, the Pragmatic Engineer Newsletter, it says, "The biggest problem, people stop caring about real work and focus on performative work." and like what you just said about how they can't do what's best for the overall growth of the library because that's not the criteria upon which they're judged. [00:31:05]

They are judged on their impact within the company, and specifically the impact on the company as judged by their immediate supervisor with, with the supervisor chain. So it, ultimately you're... The, incentives flow down in that kind of way. So it's actually... [00:31:23]

there's, a deep fundamental misalignment between open source and, the American corporation, I'm not gonna go into capitalism a w- But, that's very true. Open source is a c- is a public good. It's a, it's, it's a public square. It's a shared resource that they're, people don't pay for. and those types of resources they're the economic concept of the tragedy of the commons. [00:31:41]

It's a well-known principle that people don't just casually take care of stuff. If it's a public common, it's going to get more extraction than it is investment. So it's... I don't know. It's, it, there, the, th- that's a fundamental tension, and I feel like any time we're talking about companies under-investing in, open source, that's kinda why. [00:32:03]

It's because they can't. They're not allowed to. If you're a big publicly traded company that has gone to IPO and has shareholders, you have a fiduciary duty to those shareholders, and fiduciary duty does not include volunteer effort to public goods. So it's, that's, there you go. That's the tension. [00:32:27]

Anyway, let's move on [00:32:44]

AI demands more engineering discipline. Not less

Carl: Great post from Charity Majors who, somebody who I've ... They, are such a well-spoken, phenomenal writer speaking about engineering culture. And I, especially they talk about opera- or, yeah, I was gonna say operationalizing, production environments. [00:32:46]

they run a company that makes its money on observability, [00:33:05]

Mark: Honeycomb [00:33:08]

Carl: Honeycomb. great company, great mission, great blogger, great writer. so i- she's put out a post, AI Demands More Engineering Discipline, Not Less. [00:33:10]

Charity says in her post, "What happened in 2025 was this, the economics of code production were turned upside down. Instead of being very hard, time-consuming, and expensive to generate code, it became effectively free and instant. Lines of code went from being treasured, reused, cared for and carefully curated to being disposable and regenerable practically overnight." [00:33:20]

And something I've said on this podcast before is that, code's kind of a liability. over time code is not an asset, it is a drain. It is something to be maintained. It is a cost center. so I agree with that. I think that read is correct. The, economics of code production were turned upside down. [00:33:38]

it's m- because code is not an asset, because code is a liability, the ability to discard it and replace it with something new that is, has differ- has a different risk profile is massive. [00:33:57]

Mark: It's, ironic because, as developers we have historically resisted, taking the time to write documentation or writing tests or actually planning out our work, and suddenly it turns out that in order to get good results from AI, we actually need to do all of the above. [00:34:12]

Carl: Yeah, and it's like I have always known what the right choice to make was. it's y- several years ago when I was working as a tech lead, it's okay, we have this feature. I know that it is deficient in these , these areas. no, we don't have end-to-end tests. no, we don't have functional integration tests for all corner cases. [00:34:30]

Because we don't have an existing end-to-end harness, because we don't have a framework for mocking network responses for requests initiated from components deep in the tree, deep in the hierarchy. there, it's, it... Engineering excellence is a momentum-based metric. You cannot skip ahead [00:34:53]

You can't write end-to-end tests if you haven't built a reliable framework upon which to run end-to-end test suites. and so it's hard to do. It's hard to keep that momentum up over a long enough time span to where you start observing the benefits, and so most companies didn't. [00:35:12]

the number of times where I would get feedback on something, and it's like, why don't we have this already?" It's, 'cause that would've taken two weeks, and I can do it now, but I didn't have two weeks." and I gotta say, I'm finding it much easier to find those two weeks with AI. AI is an amnesiac, so it needs to start from scratch every time. [00:35:30]

if you're working on a new feature or just built something brand new, I just ask Claude, "Hey, familiarize yourself with this code base, how much of that did you get from docs versus the code?" [00:35:50]

And it does a little analysis, and it comes back and says, "Oh, the documentation is out of date in these locations, and these concepts should be pulled in." "Great. Can you do that work for me?" It's like, "Oh, yeah. Cool, cool. And so then instead of, what, six hours of, reading code and putting together my own notes and understanding what documentation is currently available and synthesizing it to get, a fact-based update and then writing brand-new prose to fill in those docs, I, I, I can do that in 10 minutes in a background process. [00:36:00]

Mark: Yeah, I, love generating architecture exploration e- explanation type docs. I've, found that extremely useful. In fact, that was my gateway that eventually led to me using aI to write code. It does feel like I'm leaving some understanding on the table, that my understanding is can be very much more surface level. some of it is, there's ar- areas of our code base and our projects I just haven't looked at, and operating off of a vague mental model. I, skimmed through a handful of architecture docs. that's certainly not, that's certainly not enough to actually understand what's going [00:36:30]

Yeah place. It's, easier entry, but maybe not as much depth [00:37:04]

Carl: That's very true. I assuage my own guilt in that, the like, "Oh no, I, know that I'm only seeing 30% of this." ' Cause for one, every code base is too large for your brain. you are never going to fully understand all of it at the same time. And any time that I did fully understand something, the, amount of time it took to get to that understanding, and then the only time I ever did that was to change it, [00:37:09]

Mark: Mm. [00:37:37]

Carl: So then as soon as I'm done with that, as soon as I have gotten my understanding up to 100%, cool, great, I'm changing it. That's now out of date. That knowledge is now useless. [00:37:38]

Mark: I'm, sure I've mentioned this in previous episodes. I am a huge fan of the concept that programming is building a working mental model of the system. it's a, it's about theory building. So you understand what we are trying to build as a domain, as a project. [00:37:46]

You understand the current system, the architecture, the quirks, the concepts, so that for any task you work on, whether it's a feature, a bug, whatever, you are starting from my current understanding. You break down the new problem based on your understanding. You come up with a plan, you implement it, you spend six hours trying to make it work, and by the time you're done, you not only have working code, you have updated your mental model on the system. So I would say it's not that you've made your previous knowledge useless, but we are continually modifying that understanding [00:38:03]

Carl: Yes, sure. I agree with that. I agree with that, but I also discount it a little bit more than I think you are. Like, I'd agree that, developing an, accurate mental model is core. You need to do that as writing, as part of writing code. I, at least, am satisfied at the level that I am able to develop a mental model w- via AI. [00:38:36]

I guess th- this is, a feedback cycle. You have to develop your mental model, check it against what the AI is telling you, and then make sure it's what you intended, and then make sure that what you intended is compatible with a functioning projec- will it achieve what you meant it to? [00:39:03]

And those are all really hard, oh, another thing I wanna say your mental model, are, the building blocks that you have available to develop your mental model, are those complex enough to, capture what you're making? [00:39:19]

That's something I run into fairly often. It's like the system architecture, the system design inter- interview questions. Like, how would you build Twitter to be re- resilient? Those are hard problems. That's re- you know, de- developing a system that can manage hundreds of millions of requests is, yeah, it's really tough, and AI is really helpful for me for exploring that. [00:39:33]

it ends up being... Okay, oh, wait, here let me try and frame this in a sentence. It used to be critically essential to develop an accurate mental model through the process of reading and writing code yourself, and now it's much more important to be able to ask the correct question at the correct time of the code base. [00:39:58]

Because now you can... The, frontier models are smart enough and the tools are capable enough, they can pretty meaningfully answer any question that you have about a fixed set of code. If you, bound it to like, "Here's the code, here's your world, tell me about it. Answer this question for me," it can. [00:40:18]

And so now it's up to you to know what the right questions are to ask given the present state of the existing code [00:40:38]

Mark: Yeah. So let's tie that then into the next link in the list. [00:40:46]

Christoph Nakazawa posted his “Modern Engineering Values” and how he uses AI

Mark: so Krzysztof Nakazawa is a long time figure in the React ecosystem. He's worked on Jest and graphQL and a whole bunch of other tools. more recently, he shipped a data fetching library called Fate. he's built a game with JavaScript called Athena Crisis. He got hired by Void Zero, which we'll talk about in a second. so like re- like really smart, capable long-term engineer, and he is now fully doing everything with AI. [00:40:51]

Carl: Yep. [00:41:21]

Mark: He put up a post on modern engineering values where he talk about how he uses AI effectively, but also then what are the principles that he's using in trying to build projects. And he talks about, ownership and taste and strict guardrails and fast feedbacks loops, which is what we were hitting on a minute [00:41:21]

Carl: Yep. [00:41:42]

Mark: Being able, to know what is the right context that I feed into the agents so that they are able to come up with the answers. maybe actually, owning some more your own code instead of depending on third-party libraries. Thinking differently about how you build prototypes and ship things. so very relevant to like we're, doing the same work, but maybe at a higher level, and you do have to know where you're trying to go [00:41:44]

Carl: Yes. Yeah, agree. Yeah, I like this, bit from Christoph's post, "I've found that coding agents now write code that is as good or better than what I could write," which I would agree. I find that true as well. "And they do it in minutes instead of weeks. Since coding is no longer the bottleneck, I get a lot of work done that otherwise wouldn't have happened at all." [00:42:12]

100% agree with that. That is... I have started and finished so many more projects than I would have before because I, can do it in a day instead of in a week. it's a 7X speed multiplier for me. So it's good. [00:42:30]

Cloudflare bought VoidZero

Mark: In industry news, Void Zero, the company behind VitePlus and a couple other pieces, has been bought by Cloudflare, this continues the trend of a bunch of open source build tool developers try to get funding, try to make a company, and then they probably get swallowed up by someone bigger because there is no money in running open source build tools. Bun and a whole bunch of others all getting bought out. nobody is making money off of open source build tools. There is no build m- there is no financial model, hosting, or anything else. So we'll see how it plays out. to be clear, this is about the team and the VitePlus and Void tool sets and frameworks. [00:42:42]

This does not affect Vite, the open source bundler, at all, other than these are some of the same people working on it. but it continues the pattern, and I don't see that pattern changing anytime soon [00:43:32]

NPM / security updates

Carl: We got some more security updates from NPM. Great. [00:43:44]

Github Actions allows enforcing pinned action SHAs

Carl: GitHub Actions now supports blocking and pinning actions to a specific SHA. So that's, that's really good. If you... So this is helpful for avoiding vulnerable actions. if you're aware that some specific release of an action was compromised, you can now block that one specifically. [00:43:48]

Or say, "We know this one is good. Only use this version." wow. Ability to select precisely what code you're running. This feels like table stakes to me. It's shocking that we're only just getting it [00:44:09]

GitHub Actions Has a Package Manager, and It Might Be the Worst

Mark: there's, a guy named Andrew Nesbitt, I think we may have linked one or two of his articles previously, but he has become an expert on package managers and packaging systems, and I think he wrote an, a couple articles talking about, yep, GitHub Actions is totally a package manager. It doesn't look like one, but it is, and it's bad [00:44:21]

Carl: Yes. Yeah, people shit on NPM for a lot of reasons, but you know what? The w- most most of the ecosystem problems in JavaScript around dependencies are because NPM is one of the only functional package managers in programming. Cargo or NuGet or, like, all of the other... [00:44:39]

Every other language has a shitty dependency manager. It does not support what I would call core features of a dependency manager. For instance, pinning versions. Just, it's shocking to me how ineffective we are at sharing code in the vast majority of programming. anyway, yeah. So great. So many things are terrible dependency managers, and GitHub Actions is now a slightly less terrible pa- package manager [00:44:58]

NPM 12 will disable install scripts and Git deps by default

Carl: GitHub also put out some breaking changes for npm 12. They are not going to run install scripts and Git dependencies by default. that is... This is literally something I've seen discussed as a security vulnerability for 10 years. [00:45:27]

So it finally got exploited enough times that they're like, "Nope, okay, we gotta get rid of it." great, cool. They're getting rid of the thing that has been discussed as something that should be gotten rid of for a long time [00:45:43]

specifically it's, NPM will no longer run pre-install, install, or post-install scripts from dependencies unless you allow list them. So no builds basically [00:45:54]

Mark: what I think pnpm als- already does [00:46:05]

Carl: Plenty of package managers already do that because running untrustworthy code from a network is really dangerous. [00:46:08]

Don't do it. This is what I mean, like, I just said, NPM is one of the most advanced package managers in all of programming, and it still gets basic shit wrong. Stop it. Security models. [00:46:13]

Code optimization still matters!

Mark: All right, last major item for the day. topic, a related topic, but, bit of a grab bag. There's a whole bunch of good articles about code optimization that came out in the last few weeks, and I've spent a lot of time doing performance profiling. I have literally given a talk this year on how to do performance profiling. So we had several articles on, and from people who did performance optimization work on tools and libraries. [00:46:25]

TanStack Table cut memory in v9 by 90% on large lists by optimizing JS objects and optimized TS perf

Mark: First off, there's a couple articles from the TanStack Table folks where they talked about how they were able to save a bunch of memory within TanStack Table by switching out the JavaScript prototypes that were being used, as well as how they optimized, the TypeScript compilation performance. [00:46:53]

Now, yes, TypeScript's version seven's gonna make all our TypeScript faster, whatever, but it's still good to actually try to improve the, type checking time if possible. [00:47:14]

Pierre Diffs was significantly optimized - has to handle virtualization, syntax highlighting, source loading

Mark: next, there's something called the Pierre Computer Company, which is making essentially like a, GitHub for, as a service kind of a, set of tools. [00:47:25]

And they've put out a couple JavaScript libraries, one for rendering tree views in the UI, but they also put out one that is a diffs rendering library. And so they've put up a post on how they heavily optimized all the list virtualization and the syntax highlighting and all the other complexities of trying to render diffs efficiently in the browser. [00:47:35]

And I've seen several other applications pop up which use that library in the UI. part of me make, wonders if GitHub perhaps consider using that library in their UI given the, how slow their React based, PR view is at this point [00:47:59]

Carl (editing): oh, shoot. We had an audio problem. For some reason, we lost about the last 10 minutes of my audio. Mark's came through just fine. Uh, and luckily he did most of the talking in the last little bit here. Uh, but unfortunately we lost about four to five minutes of me responding to things that Mark said. Uh, oops, sorry. [00:48:20]

CompileCat is a new optimizing compiler to improve JS execution after bundling, similar to Closure Compiler. (the RSPack team says they’re working on something similar )

Mark: A couple more of these. So someone recently started a site called Performance.dev. Their first article previously was on how the linear UI is fast using sync engines, and they just put up another post on how a tool called Conductor implemented a bunch of optimizations, handling some of the UI layer interaction with Tari, list virtualization, and a bunch of other pieces. [00:48:38]

so those are, apps and libraries making things faster. I saw a couple, winks on something different. So we all use minifiers in our bundling process. It's, part of all modern build tool chains. minifiers do things like they don't just rename variables from my variable to A. [00:49:03]

They, they strip white space. They turn true and false into bang zero and bang one be- because it takes up fewer characters, et cetera. But they also do things like stripping out dead code. So if a library has only r- has a, an if statement that says, "Only run this in development," it will convert that to if false, and then it will say, "Oh, that code can't run. [00:49:25]

Just delete that code from the bundle and optimize the output." And so every time you run a build, a minifier is optimizing the output. And the major mini- the major minifiers, optimizers have been things like Terser and, ESBuild has had one built in, Rolldown has one built in. there's be- there's one that's been around for a very long time called the Google Closure Compiler. [00:49:49]

this dates back to when Google first built a lot of their early web spa type tooling. 2008, 2009, somewhere in that timeframe. it's, extremely powerful and has a lot of very advanced optimizations that other minifiers still don't have, but it's also big and complicated and maybe a little bit on the slow side. [00:50:14]

interestingly, the React team still uses the Closure Compiler to build the React library so that the production version of React is as fast as it can possibly be. So I saw two different announcements of teams that are attempting to write their own advanced optimizer tools. one person built something called CompileCat, and then the other one's a mention of an internal tool that's not released yet, but the, RSPACK team at ByteDance said they're also working on a similar tool. [00:50:35]

So presumably doing things like actually looking at not just the JavaScript, but the TypeScript types in order to be able to, be smarter and produce better output code as well. [00:51:11]

Mark’s React-Redux \+ signals draft perf PR and updated React-Redux benchmarks repo

Mark: And then I guess we'll wrap up this section with three things for me. so I, think I briefly mentioned last month that I was working on a proof of concept to try to optimize React-Redux's subscription notifications for our large applications. so I have a draft PR, and I've put that up, and the early numbers look promising, like 20% to 30% faster depending on the situation. [00:51:22]

as part of that, I also updated my React-Redux benchmarks repo so that I've got better metrics that I'm capturing and, a better, more realistic set of example scenarios to be measuring against. And then one of the conference talks that I've been doing this year is literally on the basics of performance optimization. [00:51:50]

there's a set of general scientific principles to apply, descriptions of actual tools that you would use to measure JavaScript performance and fi- try to figure out which lines of code are slow, and I talk about some of the examples I did while working on Immer last fall [00:52:12]

I think this is all very important even in the age of an AI because AI tends to write the obvious code. It doesn't necessarily write the fast code. And we collectively were already very bad at asking, "Is this code fast?" in the first place when we were the ones writing it. And now that n- we're not the ones writing it, it's even easier to never ask the question, "Is it fast?" [00:52:28]

Aurora Scharff’s preferred RSC component architecture

Carl (editing): Yep. So right here is where we lost about four minutes. Uh, unfortunately, I, I definitely cannot reproduce what I said, which is a big bummer. I think it was probably really smart and really clever and really wrapped up the whole thing of what we talked about all episode. But unfortunately, it's gone into the ether. [00:52:51]

I tried re-extracting the audio as recorded from the original source, and it was just blank. We're just completely missing 10 minutes. sorry. [00:53:07]

All I really know is that I was introducing Aurora Sharf's blog post titled "Component Architecture for React Server Components" as her preferred RSC component architecture. [00:53:15]

And I know that because Mark said after [00:53:26]

Mark AI filler: yeah. And, Aurora really is the expert on this kind of stuff right now [00:53:29]

Lovable projects now use TanStack Start by default

Mark AI filler: And then one, one other interesting data point to wrap up, announced that all of their Vibe-coded app projects are now going to be built with TanStack Start by default. I don't remember whether they were just using plain Vite React router or something previously. but this feels it, it's a very interesting data point. A sign of the maturity of TanStack Start, and that they're, and they're happy to actually adopt this as the default setup for all their projects going forward. [00:53:34]

Carl (editing): And that is all we've got for you today. I am re-recording this afterwards just like all the other things I said in the last 10 minutes. So I'm not gonna do the usual full sign-off 'cause this is totally fake and I'm just sitting at my desk talking to myself. Sorry for taking a few extra days to get the podcast out. I am just tired and it's summer [00:54:05]

Thanks so much for listening all the way to the end even. talk to you next month [00:54:24]

TMiR 2026-05: Who even is on the Core team anymore, TanStack got pwn'd bad

Reactiflux — Wed, 27 May 2026 16:00:00 GMT

[00:00:55] Some podcast meta
[00:01:49] New Releases
- [00:01:51] TS v7 beta
- [00:05:15] Rolldown 1.0
- [00:06:51] Fate 1.0
[00:09:48] Main Content
- [00:09:56] React Core
  - [00:10:09] React team status after Meta layoffs?
  - [00:14:59] React Compiler port to Rust still in progress, latest PR
- [00:15:54] Tanner Linsley is "projecting" React (it's definitely not a fork)
  - [00:21:38] Tests are the new moat
- [00:23:32] Brooks Lybrand thoughts on React + community after React Miami
- [00:25:04] TanStack is exploring how to expose Server Components
  - [00:27:19] Who Owns the Tree
  - [00:27:31] RSCs in TanStack
- [00:28:12] Remix v3 beta preview
  - [00:28:35] Both Remix and TanStack are exploring "what if no React"?
- [00:36:11] TSRX, a variant on JSX
- [00:41:52] Security! Everything is compromised
  - [00:42:04] TanStack Router compromised, and Socket analysis
    
    [00:46:58] TanStack followup with followup hardening
    
    [00:47:10] Nx monorepo tool compromised as a result
  - [00:52:02] React2Shell recaps from Lachlan Davidson and Sylvie
    
    [00:52:25] Next 16.2.5 and more React CVEs
  - [00:53:19] NPM adds “staged packages” and E18E adds guidance
    
    [00:54:50] PNPM 11 defaults to min release age, NPM 12 will block by default
    
    [00:57:59] Review your GH Actions, people!
- [00:59:13] Mark posted his big AI blog posts. Part 1: Fears and Journey
[01:08:39] Outro

Interview

Carl Vitullo: Thank you for joining us. We're coming to you live from Reactiflux, the place for professional developers using React. And I am Karl. I'm a staff level product developer and freelance community leader/entrepreneur/I don't know what I am anymore, here at Reactiflux, where I do community programs like this and build some tools to help keep the community operating. [00:00:00]

Mark Erikson: And I'm Mark. My day job is at Replay, where we've built a time traveling debugger for web apps, and that can be used by both humans and agents. And in the last couple months, I've gone between building MCP tools, doing product manager work, being a dev rel, going on vacation, and now I'm trying to figure out what I'm doing now that I'm sort of back, except that I'm going on more conference travel shortly. So it's kinda crazy right now. [00:00:19]

I do Redux stuff and I collect links. [00:00:41]

Carl Vitullo: Man, we're all doing too much stuff. It's just too many things. [00:00:43]

Mark Erikson: Indeed. My... I, I needed that vacation. Two weeks of golf in Scotland. It was fantastic. [00:00:46]

Carl Vitullo: Yeah, that's pretty good. Scotland's great. I love Scotland. [00:00:52]

Some podcast meta

Carl Vitullo: Okay, let's get into it. Before we go into, like, new releases and whatever, some, like, meta discussion whatever, historically we were co-hosted by Mo, who brought us some lovely React Native and agency perspective here. He's had to step back a bit because of just, like, personal things and work busyness, and he just hasn't had the time and energy to really go up here. And I guess I, I also wanna mention, I am feeling somewhat similarly. I've been doing this for, like, three years now. I'm no longer reading React and web news at the level of intensity that I historically have been. [00:00:55]

So, um, yeah. Mark and I are talking about how to continue this. This is a valuable service. I think this podcast is good. I want to keep it going. I think a once a month news check-in about the ecosystem is really valuable, so I wanna keep offering it. But, uh, that's where we're at. So just FYI, stuff is gonna change. [00:01:25]

Stuff has changed. Stuff will continue to change. Just like life. [00:01:40]

Mark Erikson: Yeah, that sounds all too real. [00:01:44]

Carl Vitullo: We're gonna try and keep doing this, but it'll be a little different than we have. [00:01:46]

New Releases

Carl Vitullo: But yeah, okay, into some new releases. [00:01:49]

TS v7 beta

Carl Vitullo: First off, we have the TypeScript v7 beta, which is, if I recall correctly, this was gonna be the one where it's all rewritten. [00:01:51]

Mark Erikson: This is the TS Go release, and you might also notice this is pretty hot on the heels of TS 6.0. So TS 6.0 is supposed to be the last actual release of the current written in TypeScript compiler, and 6 is the one where they changed a bunch of defaults to be more strict and better match the way JavaScript's used today. [00:02:00]

7 is same settings, but completely different compiler implementation. One interesting bit here is I believe that 7.0 is not going to have a lot of the programmatic API stuff that exists right now. Uh, I think they said they hope to get that out in a 7.1. That does mean that there is definitely going to be some amount of, like, fluctuation and churn as you go upwards. [00:02:22]

But in terms of just using the compiler to type check, go ahead and start using 7. Like- Cool ... right now. It's there. Okay. It's faster. It's the same logic. Use it right now. [00:02:49]

Carl Vitullo: So that's like the SDK, like if you're using TypeScript to do some build tools, using it in JavaScript yourself, that's not feature complete yet? [00:03:00]

Mark Erikson: Right. So yeah, so I, I don't know what all is and isn't- [00:03:09]

Carl Vitullo: Right. I've never used that, so ... [00:03:14]

Mark Erikson: intended to be included in the API. But like, for example, in Replay's code base, we have some programmatic linting stuff that uses the TS Morph package, and TS Morph depends on being able to import the TypeScript as a library and create- Right [00:03:15]

a program instance and programmatically type check. And so that sort of thing might not fully be available in 7.0, but maybe in 7.1 in some form. [00:03:30]

Carl Vitullo: Yeah. That makes sense. Interesting. Yeah, I mean, that stuff's always a little bit... Usually, when you're trying to use it as an SDK in that way, it's because you're doing something a little bit more finessed and complicated, so it makes sense that that takes a little more time to, to settle out. [00:03:43]

Mark Erikson: I know that there's, in general, a lot of issues because people have reached into TypeScript's internals to im- be able to import methods that were never really intended to be exposed- Right ... to the public. [00:03:57]

Carl Vitullo: Classic. [00:04:08]

Mark Erikson: As well as just the fact that it's one thing when it's TypeScript importing TypeScript. [00:04:09]

It's another thing when the TypeScript implementation is now in another language, Go, and so how do you expose that back to TypeScript client code, as well as how do you do so performantly, 'cause you're now crossing the language barrier? I know that's what the, like the Oxlint folks have been dealing with in terms of trying to implement typed linting, but needing to go back and forth between pieces written in different languages. [00:04:14]

Carl Vitullo: Mm-hmm. The parallelization is interesting. I, I... Like, that's such a good reason to reach for Go, is to introduce parallelization, 'cause, like, Go routines and, you know, whatever. Go is good at that. Well, that's really cool to see that TypeScript is now doing... It says, "Now performs many ch- steps in parallel, including parsing, type checking, and emitting." [00:04:43]

Anytime you can break work down into smaller units that can be isolated from each other and executed in parallel is awesome. So love seeing that being brought into TypeScript. Like, that's so core and foundational. That's awesome. [00:05:01]

Rolldown 1.0

Mark Erikson: And then on a similar note, the Void Zero folks announced that Rolldown has hit 1.0. [00:05:15]

And to recap what that is, uh, Vite had been using two different bundlers, had been using esbuild, which is fast and written in Go for development mode, and had been using Rollup, which was a written-in-TypeScript JavaScript bundler for production builds. And so in order to both make it go faster and harmonize things, you're doing both dev and prod builds with the same pipeline, they essentially re-implemented Rollup but in Rust and called it Rolldown. [00:05:20]

So yet more build tools being written in Rust, and it's been a long time coming. Vite has been using Rolldown in various betas for a while. And Rolldown itself has now actually hit 1.0. [00:05:52]

Carl Vitullo: Cool. Yeah, I was just trying to refresh my memory on... 'Cause we've, I feel like we've been talking about Rolldown 1.0 for, like, a really long time. [00:06:05]

So I was like, "When was that?" It looks like we had the, there was an RC of 1.0 back in January. So, like, that's some pretty serious, you know, d- I don't know, dedication to stability and rollout. Can we just add one more, it's a suffix to roll by s- describing this as a rollout? We'll get the, the rollup, Rolldown rollout. [00:06:13]

But yeah, so okay. So they've been in RC. They've had a Rolldown 1.0 RC out since January, and they're calling it good. They're shipping it. That's awesome. [00:06:32]

Mark Erikson: Yep. Wonderful stuff. [00:06:40]

Carl Vitullo: Love that. Great. Well, yeah, and you can, uh, listen to our January episode to see, uh, to hear us discuss that previously. [00:06:42]

Mark Erikson: All right, and then one other release to announce. [00:06:48]

Fate 1.0

Mark Erikson: Christoph Nakazawa has released Fate 1.0. So we, uh, we'd mentioned this a couple times previously, but Fate is a new React-based data fetching library. My closest comparison is it's kind of like a GraphQL in the sense that the client is specifying pieces of data to fetch. And to be honest, I still don't have a, have a f- really good grasp on how this works. [00:06:51]

I've just seen some of the d- some of his descriptions. But it's meant to be composable queries, normalized data fetching, and integrating with React's new async and suspense-based features. My understanding is that this is very heavily... I'm not gonna say, I'm not gonna say vibe coded. I, I know he's, like, been very intentional in how he's built it. [00:07:18]

My understanding is most of the actual code here was written with AI tooling, with a lot of intent behind it. [00:07:43]

Carl Vitullo: Yeah. That's fair. I don't know. Written with AI tooling and vibe coded are not the same thing. That's interesting. I don't know. This definitely looks kinda interesting. It looks like it's trying to be something, like you said, kinda GraphQL-ish, re- relay-ish, TanStack, you know, ish. [00:07:49]

But I guess, like, from first principles in the server components era- I guess is how it feels to me reading this. That's interesting. That's valuable. That's a really good exploration, but is- I don't know, something about this says r- like, research project more than something I would bet my, you know, bet my work on. [00:08:05]

Mark Erikson: My vague sense, and this is just, you know, me eyeballing things as always, real project, not just a, an experimental toy. Early obviously, and I would assume no one else is actually using it at the moment, but it's the kind of thing that I could see getting some- Right ... amount of adoption over time. [00:08:26]

Carl Vitullo: That's curious. [00:08:42]

That's interesting. Yeah, we'll s- have to see how it goes. That's really interesting. Love having more explorations on ways to do data fetching better. I'm having thoughts come up that I know I'm also going to wanna discuss when we start talking about Remix V3 in a little bit. It's so s- funny to me how much exploration has been done over the last 15 years in, like, how do we transfer data and UI across the network? [00:08:43]

We're still figuring that out. So I, I have more to say on that when we t- talk about Remix V3. But, you know, this is interesting. This looks like a valuable exploration. Christophe Nakazawa is definitely someone to take seriously. [00:09:09]

Mark Erikson: And int- interestingly, I believe he actually joined Void Zero as a company, and his day job stuff is now around some of the, like, the Void server framework pieces that they're building. [00:09:21]

Carl Vitullo: Oh, yeah. Interesting. He says he's product at Void Zero on his Twitter. Curious. That's cool. Very cool to see him still so, like, deeply embedded in the ecosystem, and then doing, like, little research side projects like this. Prototypes of alternate usage patterns. Cool. [00:09:32]

Main Content

Mark Erikson: Okay, onto something resembling main content, and something resembling React core-ish stuff. [00:09:48]

React Core

Mark Erikson: So this first bit is something that I surprisingly don't actually have much of a link for, but I'm going to try to pass on a summary of bits and pieces and conversations that I've had in multiple places. [00:09:56]

React team status after Meta layoffs?

Mark Erikson: Loosely put, I have no idea who's even still on the React team at this point, for multiple reasons. [00:10:09]

So Meta just went through two rounds of layoffs, and from watching things, I know that there was some shuffling in and around r- the React organization. For example, I think the Relay team used to be considered part of the React org, and now they're part of a separate organization. But a number of people that I know have, appear to have left the React team one way or another. [00:10:17]

Uh, for example, Lauren, who'd been working on the React compiler, is now over at Cursor. I believe I saw that Sebastian Markbagha has left Vercel and is possibly not labeling himself as being part of the React team at this point. Joe Savona, who was essentially a lead on the React team for the last year or two, I heard a rumor that he has been reassigned to something else AI related. [00:10:43]

These are all bits and pieces. I don't have, you know, direct links for them. But the picture I'm getting is that what we would consider the React core team has been kind of decimated. If you were to ask me right now, like, who am I pretty sure is on React core at the moment, about the only people I could still point to would be Andrew Clark at Vercel and Rick Hanlon at Meta. [00:11:11]

There's still a bunch more beyond that, but just, I, I, like, I literally don't know who is working on React right now, which is not a thing I would've said last fall at React Conf. And so, this also brings up a number of other questions because Seth Webster was the head of the React org at Meta, and he also spent the last few years quietly trying to put together the React Foundation, which got announced. [00:11:34]

And I've been trying to keep an eye on, you know, any news and discussion of where the foundation is. Seth himself just moved over to Expo. That was publicly announced. And I believe he's still going to be the head of the React Foundation, but I also have seen no evidence of anything as far as actual work or output from this foundation, either in terms of community involvement or events or taking over the day-to-day technical work on React itself. [00:12:00]

I actually did see in a PR yesterday, Sebastian Silbermann, who is essentially part of the React Core and Core team externally at this point, did make a mention of moving repositories over to a React Foundation org, at which point they might be doing some, you know, kill and kill AI and bot spam type cleanup. [00:12:38]

So all this says to me that they're, like, things are changing around React's development process, both who's doing it and where it's happening, but it also feels, just me observing things, it feels like things are fragmenting and stalling. And I actually legitimately do not know what that means in terms of technical development on React itself in the near future. [00:13:02]

Carl Vitullo: Strange, curious, yeah. So I'm in a, I'm in a Discord for the React Foundation, and I noticed over the past several months that virtually nothing has happened in there. [00:13:28]

Mark Erikson: There's been essentially no conversation except maybe there was a little bit of chatter about something React Native related, like a week ago. [00:13:41]

Carl Vitullo: And I saw something about a contributors Discord as well, so I think there's a private space being set up for people who are act- actively contributing code to React Core. But I, as someone who does not contribute code to React Core, I'm not in there, and I, so I don't know exactly what's going on. I do note that the website, you know, react.dev Meet the Team, lists Sebastian, lists Lauren. [00:13:48]

So it lists a number of people who are, you are saying, have been publicly confirmed as no longer- [00:14:11]

Mark Erikson: I think Lauren may still be involved with the compiler. I don't think she, I don't think she entirely left the team, but she certainly left Meta overall. Sebastian, I got the impression he's, he's out for now, but- [00:14:16]

Carl Vitullo: Well, certainly at least job titles are out of date, 'cause, you know, Lauren Tan says engineer at Meta, and so if she's no longer at Meta, that's wrong. [00:14:30]

This website has not been updated. So yeah, oof. That's, uh, yeah, okay. Certainly lack of community engagement, I would say. [00:14:38]

Mark Erikson: Having said that, I have spent a lot of time over the years just watching the list of PRs in the r- in the React repo, just to get a sense of what's going on, and I hadn't done that much over the last few months just because of travel and life and work and stuff. [00:14:45]

React Compiler port to Rust still in progress, latest PR

Mark Erikson: I was looking at it the other day, and the bulk of the PRs that I'm seeing at the moment do actually have to do with either things like updating some of the release process or, uh, some work on the React compiler port to Rust. And in fact, Lauren just confirmed on Twitter the other day, that is still actively being worked on. They are testing it out internally at Meta. I believe she's still involved in that from her side. They are trying to push that along. I do think that's gonna be a big deal for c- for a couple reasons, because eyeballing things, to me, the biggest blockers to people adopting the compiler right now are the comp- are the requirement that you still have to use Babel as part of the build process, as well as the speed of the compiler. And so if porting the React compiler to Rust makes it faster and eliminates the need for Babel, then those two roadblocks go away [00:14:59]

Tanner Linsley is "projecting" React (it's definitely not a fork)

Mark Erikson: All right, so, uh, that, that brings us up to a very interesting and somewhat controversial article, which is Tanner Linsley not quite forking React itself, projecting React. So the, the idea here is the React team has spent a lot of time over the last eight-plus years adding all these new fancy async concurrent features to React. [00:15:54]

As we've talked about, they had a general vision for what they were trained to build, and they've essentially arrived at what their vision roughly was. But, you know, a lot of us are still building React apps that don't make use of the new features or don't, you know, just don't need all the capabilities that are in there. [00:16:19]

But React as a package is delivered as a giant monolith. There is no option for, like, disable concurrent mode or something like that. And so all the code that implements this goes in the bundle whether you're using it or not. And that also means a lot of the logic and the checks that take up time are still in there. [00:16:37]

And so Tanner actually went out and he cloned the React repo, and he told an AI essentially, "Rip out all the pieces of React that I personally do not need," and he was able to rebuild React with a lot of pieces stripped out, and it drastically shrank the bundle size, and it sped up SSR. And he is actually running his own personal website in tanstack.com on this personal modified fork of React. [00:16:59]

He didn't wanna call it a fork, 'cause that term has a lot of political implications, so he called it a projection of React, in the sense of, like, projecting data or, like, viewing a subset of the data. And so technically he's made the changes available, but he is very intentionally not telling people to go try this. [00:17:32]

Like, this is not Tanner saying, "I'm forking React, use my version." This is, "I played with something and if you want to look at what I did, it's over here, but I'm actually kind of telling you don't use what I did." And I've seen mixed reactions to this. I saw a number of people say, "This is a horrible idea," because, you know, LLMs can make mistakes, and if we start modifying packages, then there's the risk of introducing new bugs and security problems that w- that got handled in the original, and if you're mod-- If, basically if you're making changes, you run the risk of breaking stuff. [00:17:55]

And I get that But I'm actually kind of in favor of this idea for a number of reasons. Like, code is not sacred. Code is there. A license says anyone can modify this if, you know, however they want. If Tanner wanted to fork this, that would be a totally valid thing to do morally, legally, ecosystemly. Maybe not a good idea, but it's a totally valid option. [00:18:31]

But also, React exists in its current form because the React team wanted to pursue certain ideas. It's totally valid for other people in the ecosystem to say, "I would like to pursue different ideas and trade-offs and see what happens." And especially given the way that it looks like React development is kind of fragmenting and stalling slightly, I am entirely in favor of people trying to do different experiments. [00:18:55]

Carl Vitullo: Yeah. Like, this is making me think back to some of our, some of the conversations we've had over the years at this point. And like, you know, so something that I, I've expressed pretty consistently is this sense of React as a, like, research project, pushing the envelope of what's possible with UI over the network. [00:19:24]

And I think a very real tension with React versus how it's used is not everyone is trying to push the envelope of what's possible with UI over a network. Some people just want it to fucking work, and React needs to serve everyone In a way that they want. So, it... And so, you know, okay, so bringing it back to this specific blog post, Tanner Linsley projecting React, his motivation here was React's bundle size is quite large, and that's true. [00:19:42]

It's quite big, and it's quite big because it's trying to do a lot of things in a generic manner for a lot of different people. And so I think there's a very real argument here that if React is trying to do five different things for five different customers, I am going to use AI to remove the code for the four customers that I am not. [00:20:14]

I am only using this surface area. This surface area has pretty clearly defined contracts and testing guarantees, so I am going to rewrite this part of the surface area that I am touching. And I think that makes a ton of sense here. [00:20:38]

Mark Erikson: Yeah, and it, it also ties into another theme that we've seen going on a lot lately, where people are taking publicly available tools, libraries, whatever, AI rewriting them to an- another entire language, but because all the tests are already there, you can verify that your rewrite is still valid. [00:20:52]

And in this case, I think the risk of, you know, accidentally introducing, you know, major new bugs or security problems is a lot more limited, because you still have all the original React tests for all the functionality you care about, you're just deleting the tests and the logic for the functionality you don't care about. [00:21:11]

Carl Vitullo: Which makes me think, we brought this in, I think, two or three months ago. Actually, it might have been the episode that we lost the audio for, come to think of it. [00:21:31]

Tests are the new moat

Carl Vitullo: But we talked about this blog post from a mutual acquaintance of ours, uh, Daniel Sawitz, Tests Are The New Moat. And I think that's what you're talking about, is, like, if the tests are out there, if you can assert that your code passes this test suite, then what's the difference between your code and their code? [00:21:47]

You know? If it's behaviorally the same as guaranteed by the test suite, and you trusted the test suite to guarantee the behavior of the original, then that's fungible, in a way. That's in- you know, one thing interchangeable for the other, assuming the tests are good enough. So yeah, that's interesting. I see a comment here that I wanna bring in. [00:21:54]

The risk, I think the risk is the fragmentation. Yes, sure, but, like, th- there's risk of fragmentation, but it's also, like, what risks does the fragmentation introduce? Like, fragmentation is not a risk on its own. It leads to other things. Like, if there's too many tools to maintain, then maybe it's harder to guarantee the security of any one thing. [00:22:13]

But we already have that situation, as, uh, devin- as evidenced and demonstrated by all of the, you know, the Shai Hulud attacks, as evidenced by, we're gonna talk about this soon, TanStack getting compromised and 40 packages getting pwned with malicious versions published. So, like, in that sense, it's kind of safer to write your own. [00:22:34]

Like, okay, sure, it's, you know, it, it, maybe it has its own vul- security vulnerabilities, but, like, you're not exposed to the supply chain risk. So I, yeah, I think the advantages are not clear-cut. [00:22:54]

Mark Erikson: So overall, like Tanner heavily emphasized, this is an experiment. I tried it to see what would happen. I'm writing up the results of the experiment. [00:23:04]

Please don't actually use this. But I actually see this as a valuable experiment. [00:23:13]

Carl Vitullo: Yeah, I would say don't m- don't use this, but consider recreating it with something else that you find 80% good but not quite suitable. If there's a test suite, try throwing an AI tool at it. Anyway, interesting. [00:23:20]

Brooks Lybrand thoughts on React + community after React Miami

Mark Erikson: And then one other sort of adjacent bit, which is, uh, Brooks Lybrand, who's one of the Remix React Router developers, put up a post with his thoughts on the React Miami Conference. [00:23:32]

But one of the s- one of the big sections is how are people feeling about React? And some of this was, well, you know, a little bit of the enthusiasm has gone out because AI is hot and React is not. But there was also... He also specifically makes the comment that, quote, "There's basically now two Reacts," and it's kind of how using React today feels. [00:23:45]

There's old style React, and then there's all the, the new fancy Async, Suspense-y stuff, and they're almost, like, two different frameworks at this point. And so it's kind of a mindset thing. [00:24:08]

Carl Vitullo: I did read this post from Brooks. It echoes a lot of, uh, kind of what I've experienced. I don't know about the two, two Reacts part, but React Miami has been a really great conference that I've attended it for a number of years, but I haven't the last two, unfortunately. [00:24:22]

And I know that this was Michelle's last year organizing it, and I wanna shout out Michelle Bakels for being a phenomenal organizer and going on to bigger and better things. [00:24:35]

Mark Erikson: Wonderful human being, great job organizing the conference. She has put together an amazing community there. [00:24:44]

Carl Vitullo: And I believe is now organizing or doing, like, developer relations type things for Open Code, if I'm not mistaken. [00:24:51]

So yeah, do... Power to her. Wanna throw out some recognition while discussing her conference. That's what we gotta say on there. [00:24:58]

TanStack is exploring how to expose Server Components

Carl Vitullo: Let's go into RSCs on TanStack. [00:25:04]

Mark Erikson: We've talked a lot about server components over the last few years and, you know, which frameworks support them and how does it work. One of the biggest issues with server components is that Next.js had them first, and has had them the longest, and has been the only major way to use server components for a long time. [00:25:06]

Our mental model of server components is still very much based on how does Next.js offer them in the app router. And so TanStack now has... And TanStack Start now has server component support, but they have approached it in a very different method from, from an API design and usage perspective. I've seen some of the examples. [00:25:24]

I've looked at- Some of the bits and pieces I, I half understand what's going on here. But m- my rough explanation is that they allow you to do some of your own server rendering, and then you treat the response as data to the point where you, you would actually use, like, TanStack Query to fetch the dreamed data from the server, and then just sort of include the output on the client side. [00:25:47]

Another way to put it is they are trained to keep TanStack Start as a client-first framework, where you very clearly say, "This piece of code runs on the server." Whereas Next in the app router is, we are starting your component tree as the server, and you have to explicitly break out and say, "This is where this..." you know, "This is a client component," et cetera. [00:26:14]

So they're trained to flip the server component usage pattern up, kind of almost, like, upside down compared to how Next.js does it. And I think this is good. I see a lot of benefits here in terms of mental model and complexity, and just even just being able to read the code and say, "This code runs on the server, this code runs on the client, and I understand what's happening where." [00:26:41]

Carl Vitullo: Yeah. That's definitely the tough part of RSCs. I applaud them for giving it a go, but that, that is a challenging problem space to be working in. [00:27:08]

Mark Erikson: So we've, we've got a couple different posts here. [00:27:17]

Who Owns the Tree

Mark Erikson: And the TanStack folks put up two posts on server components your way, and who owns the tree, treating server components as a protocol and not an architecture. [00:27:19]

RSCs in TanStack

Mark Erikson: And then Adam Rackis did a post on Frontend Masters where he explains server components in TanStack as if you had never heard of server components before. So in other words, rather than trying to say, "Here's how it compares to Next.js," just, "Let's kind of teach this up from first principles." [00:27:31]

Carl Vitullo: Heh. I, I appreciate that, because the other, the, um, React server components your way blog post on TanStack.com starts with, "What is, what are server components? Yeah, no, this is not a server component crash course." so okay, they got, they got both audiences covered. [00:27:51]

Okay, into some stuff that we have referenced already in this episode. Some new and notable stuff in the ecosystem. [00:28:05]

Remix v3 beta preview

Carl Vitullo: Starting off, I guess, we've got Remix v3 beta preview. Beta preview, not just a beta, not just a preview It's a beta. It's a beta preview. [00:28:12]

Mark Erikson: Isn't that called an alpha? [00:28:23]

Carl Vitullo: I think that that does seem like an alpha, but I guess... No, I, 'cause I guess an alpha implies that it might change before a beta, so this is teasing the beta. It's not gonna change, but this is what it's gonna be. Fair enough, whatever. It's okay. It's great. [00:28:24]

Both Remix and TanStack are exploring "what if no React"?

Carl Vitullo: Yeah, this is interesting. Th- th- so Remix is no longer a React-based framework, which it, you know, a- and I'm just kinda reflecting on the conversation we just had about TanStack projecting React. And so it seems like it, it... There's some real ecosystem appetite to do things that are not literally built upon React while being heavily, deeply inspired by. [00:28:35]

And, like, a, a true, not just inspired by, but, like, a true lineage. Like, you know, it, Remix and TanStack, if both of them are looking at what it means to not bundle React, then that's a really serious evolution for them as projects that have historically bundled React. So I don't know. That's interesting. So they're announcing this Remix 3 beta preview. [00:28:57]

It's a pre-release, not production ready. I guess the core argument, their, the thesis of Remix 3 is that, I guess I would say it's, their opinion here is that fra- modern frameworks try to reinvent too much of what the web platform already provides, and so they're trying to strip away some of that complexity that they view as needless on top of just, like, web standards and available, you know, protocols. [00:29:18]

Which is, I'm sympathetic to that thesis. Like, I think there's a lot of stuff that React is doing that maybe it would be better for, l- or React, Next, TanStack, that may be better for the platform itself to take care of. Like, we definitely could be doing a lot more at the protocol level. Like, a thing I've been seeing people talk about like it's a brand-new fancy technology is, like, adding .md as a suffix to your URLs to make it render, you know, what would have been a HTML page in Markdown. [00:29:47]

And I'm like, "We have a header for that." Like, you can do an Accepts MIME type header to say, "This accepts HTML. This accepts Markdown." Like, w- that exists. Like, you don't need to invent some new technology for that. Like, we can do that. [00:30:18]

Mark Erikson: Okay, there's a comment in chat that says, "I do not understand what Remix 3 is." [00:30:33]

Fair. Let me try to recap where we are. Remix 1 and 2 were full-stack frameworks u- that used React. They mostly introduced things like using loader functions for data fetching. But they were, they were full-stack mostly in the sense of there is a server piece included. Remix 3 is a completely new and different framework that just happens to use the same package name And it is a very different way of writing your components. [00:30:37]

They also include a whole lot more stuff on the server. The blog post says they include routes, request handlers, responses, middleware, sessions, auth, forms, uploads, assets, data, database, UI components, theming, network, and tests. So in terms of what they provide, they're trying to provide a lot more out of the box. [00:31:12]

In terms of the client side code, this is not React. This is a brand new framework on the client side they have invented themselves. It looks a little bit like React in some ways. There's JSX syntax. But the logic and behavior are very different. For example, instead of a useState hook, you just declare a variable in scope, inside a closure, reassign to that variable, and then you call an update method, which is what actually triggers the re-render. [00:31:32]

So whereas in React, if you call setState, that both says, "Here's the new value," and tells React to re-render, whereas in Remix, you could say variable one equals A, variable two equals B, and then you call an update function to explicitly trigger it. They also have a bunch of things for mixing in behavior, like event handling and styles and things like that. [00:32:07]

There's inspiration from React. There's inspiration from earlier libraries like Backbone. It, it is a very React and yet non-React-based framework. [00:32:34]

Carl Vitullo: And I'm looking at this, you know, in this Remix III beta preview blog post, I'm looking at this small example copy to clipboard component that they show. And yeah, so Mix is what stood out to me here. [00:32:46]

There's, you know, a button and it's got, like, some ARIA stuff, 'cause buttons are, need to be accessible. And then instead of, like, style or, like, class name or, you know, onClick, on, you know, handlers, n- the rest of the props basically that I would expect for a, you know, a button component to have, it has this Mix attribute which, you know, uses the same JSX, like, you know, curly braces. [00:32:58]

Then the value is an array which has button.secondaryStyle and an on function which is being given, you know, onClick with a clickHandler async function here. That's interesting. So it's like, I guess, it's sort of React, but with manual updates instead of updating by reference, and it's got, like, this pseudo-functional composition style for arguments. [00:33:22]

But, like, weirdly, it seems to be mixing styling and b- behavior in this Mix attribute, 'cause it's both applying the secondary button style and an onClick handler as composed mixins, I guess. So that's, I don't know. Sure, that's an opinion you can have. That's, seems fine, but it's strange. [00:33:49]

Mark Erikson: All that to say that they've been talking for a while about how they're trying to do their own thing, and they are clearly doing their own thing. [00:34:07]

And I have no idea how much adoption this will get, but can sort of squint and see some of the inspirations. [00:34:15]

Carl Vitullo: Yeah, and somebody in chat just brought out React Router Framework, and it's like, oh yeah, they did that too. [00:34:22]

Mark Erikson: Brian and Michael have had a lot of ideas over the last decade. [00:34:26]

Carl Vitullo: Yeah. Boy, boy howdy, have they. [00:34:29]

I guess, uh, a thing I wanna bring in, speaking about over the last decade, so a decade ago is 2016. I remember in, like, 2012, I read a blog post from Basecamp talking about how they built their UI, and it was basically componentized HTML being cached aggressively and recursively sent over the wire. And, uh, as I have been watching React evolve, it's like, oh, we're basically evol- you know, uh, progressing towards the same thing. [00:34:31]

It's, you know... This f- this remix description of, like, and- advanced functions and like, you know, it's got frames, which are server-rendered HTML that you can, like, slot into your client code. And it's like, man, just, like, the number of times that I see something that, like, viscerally remind me of this thing I read in, like, like literally 15 years ago at this point, talking about sending componentized HTML over the wire in a efficient manner. [00:34:59]

It's like, wow, we're still trying to do that out, uh, generally. Like, we-- I feel like that's the tension. It's not that hard to do as a one-off, but it's really hard to do with effective semantics that let you author that type of experience in a generic framework or library. So we're just still chasing that high, I guess. [00:35:26]

So I don't know. That's where we're at. That's how I'm conceptualizing this Remix 3. And I, I also think of, like, Remix, you know, 'cause, like, Remix is, like, backed by Shopify and, you know, Michael and Ryan, they feel like they're in alignment with the Basecamp folks. And so it's interesting to see these, this similar set of ideas explored by a set of folks that I consider to have a generally similar set of ideas about the world. But yeah. [00:35:46]

TSRX, a variant on JSX

Mark Erikson: And on a very, very similar note, Dominic Ganaway is someone who has worked on multiple React frameworks. He originally built his own framework called Inferno. He was part of the actual React core team for a while. I believe he then went over and worked on some of Svelte 5, maybe. [00:36:11]

Someone who has a lot of experience building these frameworks. He has been working on a new framework called Ripple, which we've mentioned a, a few months ago, and one of Ripple's potential innovations was essentially an improved version of JSX syntax, and Dominic has extracted that into its own package and compiler layer called TSRX. [00:36:29]

So JSX has an actual specification. It's out there. It's in a repo. It's documented. It also has not changed in a decade, and part of that is because it's embedded. There's lots of different tools that know how to parse JSX correctly and do the transformations. Trying to push through any changes to the JSX specification would be hard at this point. [00:36:56]

Like, I would desperately love to have what's known as prop hunting, where, say I wanna pass my variable as a prop named My Variable. Why should I have to write My Variable equals curly braces My Variable every time? Like, that's silly. But the problem is the JSX spec says if you pass a variable name with nothing else, well, HTML treats that as a Boolean, so JSX is gonna treat that as a Boolean too. [00:37:21]

And it's like, but it would be so much nicer if I didn't have to repeat myself. Can't we improve the specification? And at this point, it's not gonna happen. So Dominic has gone in and created essentially a bigger, better JSX-like language that is specifically meant for writing components in a template-ish, JavaScript-ish, TypeScript-ish sort of way. [00:37:53]

Carl Vitullo: Agreed on, like, you cannot-- Like, changing the spec of JSX right now, like, nobody expects the spec to change, which makes it harder to actually change. Like, you know, if it had been evolving, it would be easier to continue evolving, but we have inertia saying it's fixed. So it's just tough to evolve. I'm not sure if I love this as a, you know, new DSL. [00:38:21]

I have been thinking about the value of DSLs in this, you know, agent- agentic AI era that we're, you know, that we find ourselves in now. And, like, so much-- I feel like there used to be a strong argument for not changing things because you have to do this, like, educational push afterwards. You have to do the developer relations of, like, "Here's how to use the new thing," and you have to, like, yada yada. [00:38:45]

And that's different now that so much of the new code is being consumed by agents. It's not an educational cycle. It's not workshops and, you know, courses and talks and conferences. It's like you update the markdown. You update the docs that the AI is reading 'cause it's an amnesiac and you have to start from zero every time you give it something. [00:39:06]

That's an interesting, like, unlock for changing some of these core assumptions. Like, yes, sure, it's embedded, it's deeply embedded into the training program. But like I've been pleasantly surprised by things that I expected to be challenging because it's not deeply embedded in the training data, or it, it runs counter to things that I know are deeply embedded in the training data, like wanting to do functional patterns instead of object-oriented. [00:39:27]

Because, I mean, so much code is object-oriented and it's been trained on all of the existing code. I have to say, like something like TSRX, it seems interesting to me from that lens of like... So your thesis is that JSX has rough edges and foot guns that make it less effective, less intuitive, less comprehensible for its intended purpose. [00:39:53]

Mark Erikson: Just make a whole new thing. [00:40:16]

Carl Vitullo: Just make a new thing. Just shave those off and call it something else so that the tools you're using to author these implementation details don't get confused about what you're using. Or, you know, have lint rules, static, you know, tools available to ensure that what they've written is valid and g- intended. [00:40:17]

Ah, that's interesting. That's cool. That's useful. I don't know. [00:40:33]

Mark Erikson: And just looking at this code snippet, a few practical examples of how this is different from JSX. So you've got a component keyword instead of the function keyword. It is statement-based, so you can have like an if statement directly in there, and then you don't do like a return anywhere. [00:40:36]

It's just like if condition, key tag In other words, it, like, if that's true, you insert the P tag, but you don't have a, like, a return statement anywhere in there. Uh, and then it's also got an embedded style section as well. Another interesting thing is that this is not actually tied to a framework directly. [00:40:54]

There are packages that allow you to use this with React in Preact, Ripple, Solid, and View if you really wanted to. So you could, in theory, actually drop this into a real project right now if you really wanted to use it. Did you use it? Probably not, but it's a very interesting exploration. [00:41:16]

Carl Vitullo: Yeah, definitely really interesting. [00:41:37]

Mark Erikson: Okay. Well, we are already almost an hour in, and we still haven't touched the security thing. So Carl, great job moving that to the end. [00:41:39]

Carl Vitullo: I knew it. [00:41:46]

Mark Erikson: Who knew that we would have stuff to say about everything else first? [00:41:47]

Carl Vitullo: What? You and I have opinions? [00:41:50]

Security! Everything is compromised

Carl Vitullo: As fucking ever, there's been a bunch of security stuff going on. TanStack Router got, like, hardcore compromised. I think it was 40-some p- compromised packages. Basically, like, all of- [00:41:52]

TanStack Router compromised, and Socket analysis

Mark Erikson: The entire TanStack Router set of packages was compromised. No other TanStack libraries were compromised. So, like, Query, Start. Or, well, Start because it includes Router, but, like, the actual damaged packages were all Router related. [00:42:04]

Uh, and the, the way it worked was incredibly complicated. So s- essentially, someone opened up an ex- a, an external PR that in its own depend... Like, essentially changed the package dependencies to point to some compromised poisoned versions. TanStack's CI was set up to have a shared package cache so that their CI runs would go faster. [00:42:22]

Someone opened up this PR, modified it a couple times, closed it, and in the process, their poisoned packages ended up in the package cache, so that the next time one of the TanStack maintainers actually did a real PR, the poisoned packages from the cache got installed, exfiltrated credentials, and then that allowed the attacker to then publish new versions of the TanStack packages with more malicious code inside. [00:42:49]

Uh, it's actually much more complicated than that, but that's roughly what happened here. [00:43:21]

Carl Vitullo: Yeah. It's... I, I wanna see if I can pull in a couple different details without blowing up the time we spent here. [00:43:26]

But, like, so they, they fork it, they obscure that it is a fork by renaming it to s- you know, configuration, so you d- it's not easy to find. [00:43:30]

They publish a commit with li- you know, a malicious payload, commit it with skip CI because they know that will suppress the CI from actually executing on this push. Then- Like open a PR, update the PR so that it appears empty, then close the PR. And in doing this, they have now poisoned the cache with their malicious payload so that the next time a legitimate CI run goes, it will pull in this malicious payload instead of the intended dependency code. [00:43:39]

All from a fork, that was never run, that was never actually executed, never had CI run or merged or approved. The timeline for this is they open the PR, do multiple force pushes, and then close the PR in under a minute, and that's how they poison the cache, so the next time a legitimate person ran CI, their credentials were compromised. [00:44:15]

Like, that's fucking crazy. [00:44:40]

They m- compromised a bit of code, organizational policies by the, by TanStack, and complex GitHub Action configuration. And all of this was ultimately enabled by the use of a PR target in their GitHub Action that is like known to be unintuitive. [00:44:42]

It's known to a- allow this type of attack. But like, ah, man, what a, th- like that's, that... What a reasonable thing to miss here. That's such a complicated set of th- steps to have to do to e- execute this. [00:45:01]

Mark Erikson: I've done a decent amount of like GitHub Actions CI config over the years for Redux. I have no idea what I'm doing. [00:45:15]

I don't like writing YAML as a way to do control flow. I'm not an expert on this stuff. I'm googling examples and copy-pasting, because I genuinely have no... Like I, I roughly know here's what I want to do. I don't know how to do it. So this stuff is so easy to mess up, and GitHub Actions is frankly a, it's very complicated and it's very badly implemented. [00:45:25]

Carl Vitullo: And it's so hard to test. Yeah. It's impossible to test some things. Like literally in, in some cases the only way to trigger the actual workflow is to do it live. And like, like you said, I'm not an expert in this. You're not an expert in this. Like nobody, almost nobody, especially in open source, is an expert in GitHub Actions. [00:45:49]

Like nobody's primary job is understanding GitHub Actions, but all of us have to write GitHub Actions because that's the way that you function in this world right now. So I don't know, it's oh man, what a rough state of affairs there. We all have to do this. Nobody's that good at it, and the experience of actually authoring it is- rough. [00:46:09]

It's bad. Like, it's not good. [00:46:30]

Mark Erikson: So the postmortem is fantastic, and just for the record, I've seen a lot of corporate post-moto-mortems that were nowhere near as good as this. So kudos to the TanStack team. I know Corbin and a bunch of the others were very involved in not only trying to deal with the actual fallout here, but, like, really, really professionally follow up on here's what happened and here's how we're fixing things. [00:46:32]

TanStack followup with followup hardening

Mark Erikson: And so they, they also put up a follow-up post with the list of things they're doing to try to make sure that nothing like this ever happens again. Unfortunately, this did have a lot of downstream consequences. [00:46:58]

Nx monorepo tool compromised as a result

Mark Erikson: So, uh, the Nx monorepo tool got compromised after that because someone from the Nx team installed one of the briefly live malicious versions of TanStack packages, and that led to some credentials getting exfiltrated, which led to a malicious version of an Nx VS Code extension getting installed. [00:47:10]

And then GitHub reported that someone had accessed a bunch of internal repos, quote, "Because one of our employees used a, broke a malicious VS Code extension," and I think I saw some articles indicating that it might be the Nx Console possibly. So it's possible that there were multiple chained attacks downstream, all starting from the TanStack Router compromise. [00:47:39]

Carl Vitullo: That's fucking wild. Yeah, so, you know, like, when people tell me about, like, the risks of introducing security vulnerabilities by hand-rolling your own little tool here or there, like, oh, I don't know, GitHub got compromised by this. This sequence of events to get to GitHub is compromised, oh my God, that's absolutely wild. [00:48:05]

I don't know. People talk about threat models and, like, threat actors. Like, how do you defend against what type of threat actor? Like, this attack, to me, the level of complexity and success and, like, capitalization upon their success- Says nation state actor. Like this is world-class— [00:48:24]

Mark Erikson: And to a certain extent, like it's not even worth trying to defend against someone who's that good. When they want to find a way in, they will find a way in. [00:48:41]

Carl Vitullo: Right. Meaningfully, in order to effectively defend against these... You know, if you think about it as like y- your available attention, you have 100% available attention, and, you know, there's that r- team, that malicious actor, 100% of their attention is on breaking you. [00:48:49]

If you are not as skilled as them and dedicating the same amount of effort to countering their actions, like you can't beat them. They will overwhelm you given enough time. So like that's the complicated thing about security. You know, it's like in physical security they talk about like there is no such thing as a perfectly secure lock. A line that I'm aware of is physical access precludes all security. Like if you're doing computer security things and you are sitting in front of the machine literally [00:49:07]

Mark Erikson: Sooner or later you will find a way in. [00:49:37]

Carl Vitullo: It is not possible to provide security guarantees there. Yeah, you know, like if you're trying to lock down your data, if they're sitting in front of the machine, they can just blast your RAM with freezing agent so that it powers off but still holds the bit pattern physically on the chip, and then you can recover it from there. [00:49:39]

I remember reading, uh, you know, proof of concept in an academic lab. Somebody had successfully exfiltrated data from a computer by using a high-sensitivity microphone from across the room and extracting the, like, buzzing pattern, the audible noise of the processor as it executed instructions. [00:49:57]

Like, by listening to the processor, they were able to exfiltrate data. Like, the bar for perfect security is so high, it's incredible. Anyway, that's the last thing I'll say there. [00:50:19]

Like it... So I don't know, just like when w- as you're thinking about responding to and defending against security threats, I think that's a really important context here, is that if your counterparty, if the malicious actor you're defending against is a hacking team that has been working for 25 years with the backing of a nation state national defense resources, like, sorry, you're not gonna beat them. [00:50:30]

That's-- You're not an effective counter to that. Like, it's not gonna happen. So I don't know. That's an important caveat that I think all security conversations need to have is it's fucking hard. It's grim. [00:50:54]

Mark Erikson: And then there's a, a couple more examples that I, I believe aren't even tied to the TanStack one. So Vercel got compromised, and that one appeared to be a sort of similar thing, where, like, one person was using an external tool, in this case called Context.ai. [00:51:06]

That tool got compromised, and then they were able to roll through, pick up tokens, and get into Vercel's interior. And then the same people who have been doing this mini Shai-Hulud set of viruses and attacks have actually been hitting a bunch of different packages across multiple different languages and ecosystems. [00:51:26]

So I mean, this, this is not like the proverbial guy in his basement. This is a bunch of very determined and sophisticated attackers. [00:51:49]

Three last lit-- um, quick little bits on React-related things. [00:51:58]

React2Shell recaps from Lachlan Davidson and Sylvie

Mark Erikson: So we had the entire React to Shell vulnerability a few months ago. [00:52:02]

The people who actually discovered that put up a couple of articles describing-- Like, the two primary individuals described their experience of what were they investigating, what was their process, what happened between when they found it and when it got publicly disclosed. [00:52:07]

Next 16.2.5 and more React CVEs

Mark Erikson: And then adjacent to that, Vercel put out a new release that appears to fix a number of new vulnerabilities and CVEs. And I know I s- w-when I saw this a couple weeks ago, I don't feel like I saw an actual blog post that accompanied this, which I found a little surprising. Maybe I just wasn't looking in the right spot, and I haven't gone back to look. But it seemed as though there were a number of new, like, denial-of-service and some authentication bypass issues found in b- in both Next and possibly Server Components again Okay. [00:52:25]

One last set of things that are adjacent to this, and that's with the package publishing [00:52:59]

Carl Vitullo: I like this 'cause it's, like, actionable. Here's things you can do to make your packages more secure. [00:53:05]

Mark Erikson: This is aimed more at people like me who are maintaining packages rather than people who are developing applications, but hopefully this is something that will benefit all of us. [00:53:10]

NPM adds “staged packages” and E18E adds guidance

Mark Erikson: So first off, npm is adding a new concept called staged publishing. Right now, when you publish, the package goes live immediately. And so the way I understand this is once you have this set up for your packages, every new attempt to publish goes into a holding area, and then you explicitly have to go in and say, "Yes, I approve this for actually, actually, actually being released." [00:53:19]

And I've, I've already seen Jovi de Crook, who works on Preact, trying to p- put together a tool that would be able to inspect package releases that are staged so that you can see what's inside them and what's changed. No idea how that works, but I c- I can see how that's been useful. So this would help for cases like the TanStack compromise because the m- modified, malicious, published versions of the package would never have gone fully live. [00:53:48]

They would've gone to the staging area, and then the TanStack team would've been able to see them and say, "Wait, no, we, we didn't intend to publish those. Those should not go out." And then on the consumer side of things, so all the different package m- managers now have some kind of an option for don't install packages until they are at least N days old. [00:54:20]

And they all have a different name and a different set of options for that field, but that's, that's the same concept. [00:54:44]

PNPM 11 defaults to min release age, NPM 12 will block by default

Mark Erikson: So I believe pnpm 11 is defaulting to turn on that option to at least a couple days. Meanwhile, the other problem here is that packages have the post-install script, which is essentially when your package manager downloads this package and puts it in node modules, it can then run any random script that the package says it should run. [00:54:50]

And that's bad because that's code that's running on your machine under your privileges and you have no idea what's happened, and it's just there because the package manager installed it. [00:55:13]

Carl Vitullo: It's literally remote code execution. Like, yeah. [00:55:22]

Mark Erikson: Yeah. And traditionally this has been used for things like, okay, let's figure out what operating system you have so we can download the proper native binary or build the native binary from scratch. [00:55:25]

And there's alternative other better ways to do that today. So pnpm has already been denying the ability to run post-install scripts for a while. And finally, npm appears to actually be making the same change. So it looks like they're gonna start warning about package scripts that have a post-install option in the version 11 series, and npm command l- and tool version 12 will start denying those by default. [00:55:38]

So we are trying to close up some of the outstanding holes in the ecosystem. So trying to make publishing packages safer, trying to make installing packages safer. [00:56:08]

Carl Vitullo: I will say, okay, if we're talking about voluntary remote code execution, you know, where blocking post-install is a good thing to do because it's against best practice, the other- Top of mind, similar instance where we are casually expected to fetch code over the network and run it is curl piped into bash as an install tactic for things. [00:56:19]

And like literally my entire career, people-- I have heard people talk about, "This is awful. We should not be doing this." Like, there are certain tools that will... I, I can't name, I can't think of any off the top of my head, but I do feel like I remember encountering this. There used to be tools that would ask you to, like, curl and then pipe it into, like, `sudo bash`, and, like, that's literally root access to your entire machine with arbit- code that you're not even inspecting from the network. [00:56:45]

And you know who still asks you to curl pipe into bash as the recommended install method? Claude Code. Like, you go to claude.com f- and the Claude Code thing, front and center, "Built for hackers. Get Claude Code. Curl, pipe, bash." Like, that is remote code execution. Don't do it. Use a package manager. If your work is recommending that people curl and pipe into bash, advise that you respectfully and through proper channels raise the issue that That's wildly insecure. [00:57:10]

It encourages remote code execution as a thing that developers will casually do. And when you casually do something like remote code execution, you end up with security vulnerabilities, like the types that we've been getting over the past year. So, ah, makes me annoyed. [00:57:42]

Mark Erikson: And then, uh, last item. [00:57:57]

Review your GH Actions, people!

Mark Erikson: So I, I, I mentioned earlier, I am not an expert on GitHub Actions. And after seeing all this stuff happen with TanStack, I, I was like, "We probably oughta do some looking at, like, the Redux actions," but I, I have no idea to what, what to even look for. The good news is that there's a number of people already working on scripts and AI prompts and other things to go inspect GitHub Actions. [00:57:59]

And it's, in fact, Francois Best, who's ma- the maintainer of the Nuxt URL State library, was actually working on one himself and was asking for repos to run it on, and I, I volunteered to have him run it on the Redux repos. And it gave me a bunch of things to go correct. Like, nothing major high security, but a number of things we could do, like making sure that all the actions were pinned to a hash, changing some of the permissions options. [00:58:22]

So there's a thread over in the E18E repo where they're collecting some different tools that can do scanning of GitHub Actions and try to work on hardening. And it kind of sucks that this is yet another thing that we gotta fix and we gotta make right, but guess what? It's good. You gotta fix it. [00:58:47]

Carl Vitullo: One more thing we gotta fix. [00:59:06]

That's just the rest of our existence forever. The debugging never stops. [00:59:07]

Mark Erikson: Yeah. Okay. [00:59:12]

Mark posted his big AI blog posts. Part 1: Fears and Journey

Carl Vitullo: You published your posts. [00:59:13]

Mark Erikson: Yes, I did. So I, I hinted at this, um, a, a month ago. Long story short, little over a year ago, I was firmly against ever using AI- Yeah ... for writing code, and I was having a bit of a mental crisis over what AI is doing to the software industry and how this would affect the industry as a whole and myself personally. I ended up trying to use AI- Found it was actually useful, and now I actually end up using AI to write all my code. [00:59:15]

And this has been a very long, very personal, very emotional journey for me. And I've actually now spent a lot of time configuring my own personal open code agent workflow setup, and I have a, I now have opinions on both how I set things up and the results that I'm getting. Just like I, I have act- I actually have experience now, and I, I have some preferences. [00:59:47]

Also, I didn't wanna get pulled into people yelling at me for having chosen to use AI. But when I was in Miami last month, I was talking with some folks, and some of those conversations literally turned into, "Mark, what tools are you using?" And I would describe it and people were like literally taking notes, acting like I actually know what I'm talking about, which is hilarious. [01:00:13]

And I'm like, "Okay, okay, fine. I've, I have been convinced to write a blog post about my own personal AI agent setup." And my brain would not let me write the technical blog post until I had written the personal experience blog post. [01:00:34]

And I sat down and I wrote 12,000 words in eight hours with a brief stop for supper. And then I wrote another 3,000 words on the flight home the next day. [01:00:51]

Carl Vitullo: I may have run that through a word count already. I can verify those numbers. [01:01:01]

Mark Erikson: I, I... This is very different from most of my blog posts. Most of my blog posts are, "Here is a concept that I've become an expert on, let me explain this, unpack the pieces, describe how things work, and I will cite dozens of sources as references." [01:01:05]

This post is none of that. This post is, "Here is my experience, my brain, my feelings, my journey." I am not trying to convince anyone. I am not trying to tell people, "This is how you should do things." this is me and my experience. [01:01:22]

And I did not write this for clicks. I did not write this to, you know, change the conversation or get a bunch of views. But I've also already read hundreds of people's posts where they say, you know, I- like, "AI is killing the craft of being a programmer, and I mourn the loss of that." and that was, it, I mean, that was a really big influence on how I was feeling over the last year. So there you go. [01:01:40]

There's a 15,000-word post that goes deep, deep inside my brain and my experiences and how my thought processes changed over time, and then it's got an awful lot of my opinions on where are we as an industry. And then I wrote another 6,000 words about my actual technical setup. [01:02:08]

Carl Vitullo: Real Casual, 21,000 words. At an estimated 500 words per page, that is just about 41 pages. [01:02:27]

Mark Erikson: People keep asking me to write books, and I'm like, "I don't write books, but I, I write the equivalent of books on my blog." [01:02:33]

Carl Vitullo: Right. Right, right. Cool. Love that. How much of both do you think you got into the previous episode we did? [01:02:39]

Mark Erikson: Bits and pieces. I, I don't r- Wait, you're asking me to remember what I said a month ago before my vacation? Come on. I, I talked about bits and pieces, but this went into a lot more detail. The biggest things are, like, beyond I use OpenCode, I use Opus, I use these MCP tools, et cetera, is that I've very explicitly chosen to stay very hands-on, conversational, and me driving what the agent is about to change, rather than spawning up a bunch of agents in the background to go do work and I don't care what it looks like. [01:02:45]

I have seen a lot of other posts and discussion, even just in the last few weeks, with a number of people echoing similar thoughts of, "Yeah, actually, maybe we need to kind of back off and keep things at a human comprehensible amount of effort." [01:03:16]

Carl Vitullo: Preposterous. [01:03:30]

I'm kind of frustrated. I don't know. I, I feel like I'm meaningfully following the edge of the state-of-the-art in agentic development. I built a harness for myself that does some really cool... Like, three months ago, I had a harness in place that was, like, keeping track of memories and doing a dream cycle and playing a game and writing its own code. Like, writing hundreds of lines of Python so that it could more effectively play this game, and it was doing a good job. It was actually pretty interesting. [01:03:31]

And I kind of shut it down 'cause, well, now, it, it, it was using `claude -p` to do everything- Mm ... and I realized, like, I kept working on it and I kept iterating it and I realized like, oh, you know what? Like, Claude is already doing a lot of this stuff. Claude Code is this agent. So what is, what does the orchestrator on top of the agent need to do? [01:03:59]

And I have an interesting, I have a really interesting body of work that's on my GitHub that is not currently being put to use anywhere, but it's like, damn it, I'm currently at the edge of the agentic whatever stuff, but I'm doing other things that are more personally interesting to me. And, man, I want... [01:04:18]

I, I have this project in place that I feel like is on par with stuff that I'm seeing people fundraise for from VC and I'm like, "Hmm, I don't wanna do that, but I do want money." So anyway, there's my, uh, there's my personal opinions around some AI stuff. I don't know. [01:04:36]

I'm g- I'm gonna have to find out... We're gonna have to talk more about AI and agents and whatever, 'cause I don't know, it's crazy. [01:04:53]

Mark Erikson: So, I don't know, adjacent thought. Like I'm, I'm, I'm in sort of a weird spot at the moment because I just got back from a combination conference plus two weeks of vacation plus conference trip. At my day job I've... [01:05:00]

Prior to that, I was writing MCP tools and then playing product manager and doing product and positioning stuff, and then helping try to figure out like demos and product direction. I'm back for a couple days. I've got more conferences coming up. I've actually done very little Redux maintenance work this year, and I feel kind of bad about it, but it's 'cause a lot of my time and effort have gone into, you know, replay day job stuff. [01:05:12]

I was trying to play with some of my like React Redux plus signals experiments on the way back home, and so I'm kind of getting some of that back into my brain. There's a lot of things I would like to sit down and spend time on, but I've just been running around so much and everything feels very scattered, and I don't feel like I'm focusing at the moment. [01:05:39]

So I've got a couple more conferences. I've got a c- bunch of travel coming up. I don't know. Maybe I will manage to find time to actually sit down and focus on some things. [01:06:01]

Carl Vitullo: As if. Cool. Well, I hope you do find so- some of that time. But I, I just know in my own self, any time I'm like, "Maybe I'll find time to do that thing that I want to do now," it's like, "Nah, probably not." [01:06:09]

Gotta make time. Can never find time, have to make it. [01:06:21]

Mark Erikson: I, I, I actually saw a post from Addy Osmani on Twitter just, uh, just this morning. A- Addy has written a number of really good posts lately about, you know, using agents and orchestration and, and agent anti-patterns and other things. Fine, I will, I will actually go look on Twitter and find the post rather than just describing it. [01:06:24]

Uh, here, oh, here we go. It's the first thing in the history. Wonderful. Uh, this one's called, this one's called The Orchestration Tax, and the key line that stuck out for me for this one was, "Human attention is now the limiting factor. It is the single-threaded lock that you need to be aware of." And so how do you pick what is the most relevant and important thing to be spending your time on versus your agent's, blah, blah, blah, blah, blah, blah, blah? [01:06:43]

Carl Vitullo: Right, right. The agents are good at a lot of things, but they are not good at building the right thing. You have to get them to do the right thing. That's definitely been my experience as well. I've definitely experienced the, "I can do everything. Throw 15 agents." Uh, and then you review the work and try and actually make use of it, and it's like, oh, this is making a lot of very basic assumptions that are not the assumptions I have. [01:07:10]

Which I, I... One thing to say, the closer your assumptions are to the basic assumptions, the better it works in some ways. So the less creative you're being, the more effective they are. Or the more, like, s- effective they are at doing their own thing. I don't know. That, that probably says something about, I don't know, scale. [01:07:35]

Mark Erikson: Yeah. I mean, that, that basically goes back to why I personally have chosen a workflow that is essentially just me augmented, rather than me spinning off a bunch of agents. [01:07:53]

Carl Vitullo: True. That's why I shut my harness down and haven't had it doing stuff, is partly, largely because I haven't figured out how to put myself in the loop of their work in a way that is effective. [01:08:05]

Uh, I, I had them running for, like, a day or two, and they, they did work. A lot of it was useful work, but they also did some work two or three times and left, like, page-and-a-half comments three different times on the same PR. And it's like, oh, okay, this is... The usefulness to noise ratio of this is not where I want it to be. [01:08:16]

Let me revise this. And I have not revised it, because that's something I'm trying to find time for, and I cannot find any time anywhere. [01:08:33]

Outro

Mark Erikson: All right. Well, I think we've about covered things today, and then some. [01:08:39]

Carl Vitullo: Yep. That's pretty good. Thank you so much. [01:08:44]

Mark Erikson: We had a number of people sticking around, which is great. [01:08:46]

Carl Vitullo: Yeah. That's really nice. I like that I put a title in the kickoff thing this time around, and we actually had people show up. So it turns out, if you, like, care about communicating with people, sometimes people actually read and respond. What? Community building? You have to show up authentically? Ah, damn. I hate that. [01:08:48]

Cool. Thank you so much for joining us, y'all in the audience who are still here 90 minutes after we started. That's awesome. Thank you, Mark, for putting together this resource on short notice. And yeah, thanks for everyone who's listening to this on the recording, uh, when I publish it in probably longer than I intend it to be. [01:09:05]

Yeah. Thanks so much. We are going to be revising exactly what this podcast is, but it is useful and good, so, uh, it, it will be sticking around in some sort. If this is a resource that you find valuable and wanna help support, give us a review. Send us to a friend. Put us in the random channel of your work Slack. [01:09:22]

Generally, like, I suck at marketing, I suck at distribution, so if you can help me get this in front of somebody who has never heard of it before, that is the single most helpful thing you can do. Or, I don't know, just send it to someone anyway, even if you don't care. Please, help. Yeah. Thank you so much. [01:09:40]

See you next month. [01:09:55]

Mark Erikson: Thanks. Bye. [01:09:56]

Mark & Carl talk with Swizec Teller about using AI at work

Reactiflux — Mon, 27 Apr 2026 16:00:00 GMT

[00:00:26] Introductions
[00:02:36] What convinced you AI code tools were worth using?
[00:04:24] Using early ChatGPT for DB migrations
[00:06:59] Watching AI use a command-line
[00:08:16] Background chat agents
[00:08:58] Staying very hands-on while using AI tools
[00:11:00] Driving AI closely without reading its code
[00:17:50] Mark's workflow; OpenCode with CodeNomad UI, plus IDE+git UI. Opus 4.6 on API
[00:20:39] Swizec's workflow, latest Cursor on Opus
[00:23:58] Carl's workflow, mostly Claude Code but looking at custom orchestrators
[00:25:23] Exploring fully autonomous agents
[00:28:08] Mark's AI debugging work in React core
[00:31:42] Value of providing more context
[00:33:58] AI-owned documentation
[00:37:09] Using good engineering practices still matters?
[00:40:47] How do you know the right code to make?
[00:42:49] Good communication still matters
[00:45:13] What will "review" look like in the future?
[00:46:17] Automating functionality tests with deployment practices
[00:51:49] What behaviors belong to the agent, and what fundamentally can't be part of the agent?
[00:56:17] Impacts of LLMs on software engineering?
[01:03:22] A superpower right now is a domain expert who can kind of code

This Month in React April

Carl: Hello, everyone. Thank you for joining us for this month in React, which is not going to be particularly React heavy. [00:00:00]

Mark and I have been talking for a couple of weeks now about doing a, like, bonus episode of sorts to talk about AI and how we're using it. So we are just, instead of a bonus episode, we're, we're just gonna do that for this month, for April. [00:00:06]

Yeah, and apologies for last month. We had a recording problem, and we, it was completely unsalvageable, just nothing to save. Big bummer. [00:00:19]

Introductions

Carl: But yeah, so I am Carl. I am joined this month by Mark Erickson and Swizec Teller. yeah, we're gonna talk about AI because it's been a huge part of each of our workflows for the last, like, ranging from, like, three to six months to a year or more. [00:00:26]

Let's do some intros first. I guess Mark and I are reasonably well known, but I'm Carl. I am a staff level software engineer and engineering manager and community lead here at Reactiflux, where I do events like this and build code to keep the community operating. [00:00:43]

Mark: I'm Mark Erickson. My day job is ReplayIO, where we've built a time traveling debugger for both humans and agents with ReplayMCP now available. Please check out our blog. I just put up a blog post on how Replay found a bug faster than Dan Abermov did. I am still the Redex maintainer. Honestly, I haven't done much Redux stuff in the last few months because all my brain space has been taken up with day job work. And also, I'm going around to a whole bunch of conferences this year. [00:00:58]

Swizec: I'm Swiz. I work at Plasmidsaurus, we are a DNA sequencing as a service company. We do a lot of React for really fancy data visualizations for stuff like, "Hey, wh- how do you visualize a few million data points in the browser and make it work smooth?" Stuff like that. And these days, I'm kind of more of a manager than an IC really. [00:01:23]

And I've been thinking a lot about what kind of engineers get hired these days. We've been hiring a lot and using more and more AI to write the code. [00:01:45]

Carl: Yep. Believe that. Cool. Yeah. So we were just chatting a little bit about what shape this conversation's gonna take. Just to level set a little bit for everyone listening. [00:01:55]

We're gonna start off kind of at the point of, like, what convinced us that AI was a tool worth taking seriously and, you know, getting AI pilled as it were. Go from there into how we're using it now, what problems we're using it to solve, with what tools, as well as kind of, like, what aren't we using, what don't we find useful and compelling? [00:02:04]

And go from there to, like, landscape of, like, what tools are available, what's out there, where do we think it's gonna go, and then kinda close out with what do we think the impacts are gonna be on the industry more broadly. [00:02:24]

What convinced you AI code tools were worth using?

Carl: Mark, you wanna start us off talking about what convinced you that AI was worth using? [00:02:36]

Mark: Sure. A year ago, I was dead set that I would never, ever allow AI to write code for me. It was a fate worse than death. It was destroying my career. I refused to do it. And in fact, I actually wrote a 15,000 word blog post over the weekend that I haven't published yet that will give the long form version of this story. [00:02:41]

The short form is, over the summer last year, I cautiously started using AI to explain an existing code base to me. You know, just give me some architecture docs, walk me through the data flow. And then there was a three-day period in late August that blew my mind. On a Tuesday, I asked it to write some redux unit tests for me because my brain was too tired to write actual code, and it did, and I was stunned. [00:03:02]

On Wednesday, there was a node compression library that I've been trying to replace, but the alternative didn't have all the features we needed, and it's Rust-based. And I tried asking the AI to write the feature for me in the Rust library, and it did. It actually didn't quite work right, and the maintainer had to turn down the PR, but this was the first time I saw an agent actually just crank along and spit out a bunch of code and happily make a bunch of updates. [00:03:28]

And I thought I had a, a good understanding of what that process looked like. And then when I saw it in person for the first time, my jaw dropped. And then on a Thursday, I needed to write some AST-based linting code. I know what ASTs are. I've used Babbel. I understand the concepts, but it's kind of complicated and fiddly, and we had a custom setup. [00:03:54]

I was like, "Could this do it for me? " And it did. And it did it much faster than I could as a person. And my worldview got destroyed. [00:04:13]

Carl: Yep. Sounds familiar. [00:04:22]

Using early ChatGPT for DB migrations

Swizec: I mean, that, that sounds like an amazing experience. For me, the first was way back in the, uh, Stone Age where you had to talk to ChatGPT and then copy paste the output to try to run it. [00:04:24]

And it was like, I think it was the holidays, and I was writing a book feeling kind of discouraged, and I was like, "I wonder how many words I'm writing per day." And it's like, I can write Python. It's not that interesting to parse a markdown file, go through, get history and see how many words you added every day. [00:04:39]

Um, so I was like, "Maybe ChatGPT can just write this for me. " And I asked it, and the code, the code didn't work, but it ran. And I thought that was really cool. So I talked to it a little bit more, and we ended up with a really nice ... It was an extremely ugly code that I would never write myself. I think it ended up still taking two or three hours, but it was a lot more interesting than me doing it. [00:04:58]

Um, and I ended up with a nationalization of how my, how my book is doing, and then I wrote a few more scripts like that. And then I started using it at work to write my database migrations, because- [00:05:25]

Mark: Please tell me, was it still just the ChatGPT UI? [00:05:39]

Swizec: It was. Uh, this was, this, this was before Copilot. I was like, "Hey, ChatGPT, I have this SQL query, please write migration." [00:05:41]

And it wrote the migrations or I ended up, uh, later on just copy pasting table definitions from, like, DBR or DataGrape or whatever, go look at the current tables and be like, "I have these tables. Please write migration for ... " I think we were using Connects at the time. "Please write migration to add these columns and then copy paste back and it worked. [00:05:49]

"And I was doing that for a while and it was amazing. I never wrote a migration again in my life. [00:06:13]

Carl: Yeah. I started doing a lot more migrations because it just became so much easier to actually do them. There's such a pain, there's so mechanical. That was an early one for me too that was like ... I guess I actually had been, like, scoping my work to avoid migrations because I hate doing them so much. [00:06:18]

I had a similar experience of just like, " Oh my God, this works for that. I can do so many more of them now because I don't have to do it. "Yeah, it's a little funny because actually database migrations are a big part of why my career looks the way it does, because I did, like, one in, you know, my first year as a software engineer. [00:06:34]

I went," Wow, I hate this. You can't guarantee anything. There's just, you just gotta try it. "And so then I went more front end because you don't have to do database migrations on the front end. [00:06:49]

Watching AI use a command-line

Carl: Yeah. I had a similar type of experience as Mark. I guess I, I got on it much later than you did, Swizz. Sometime around, like, August, July, August, September of last year, you know, I, I had done kind of like ChatGPT prototypes or whatever, like Claude, having it write some HTML in line and just, like, prove out a concept or write a first draft of a script, like, prove out does this work? [00:06:59]

Give me off the blank page and give me something to grow from and diagnose. And then I'd been hearing people talk about Claude code, so I finally gave that a shot in, like, I think around July, August for the first time. And just watching it, you know, like, Mark, like you said, of just watching it churn through and do things and also having it be, like, native on the command line and watching it just run exactly the same Bash commands that I would to diagnose something and, like, read the files. [00:07:23]

It was like, "Oh, this is doing exactly the same process I would to resolve this bug, but it's doing it five times faster than I can." That was my big, like, light switch moment of, like, "Oh, I need to take this really seriously." [00:07:54]

Swizec: For me, it's kind of like I really hate watching it work. I've been using AI for a while doing, like," Oh, can you write this function for me? [00:08:07]

Background chat agents

Swizec: Or can you, like, do little small things? "But my workflow really changed when Cursor launched Slack background agents. So I started in Slack, like, when you get ... Partially, I'm a PM, so I get a lot of requests that are like, " That is definitely not a priority right now. We're not gonna work on that. "But I can now go at Cursor, do the thing, and I just get a PR with the implemented small thing that I never would've taken the time to do myself. [00:08:16]

And I, I find that amazing because watching it work, I think is, for me, is too distracting. [00:08:46]

Mark: Yeah. [00:08:51]

Swizec: So I like it when it's fully somewhere in the cloud. I don't have to worry. I just review the code when it's ready. [00:08:51]

Staying very hands-on while using AI tools

Mark: My workflow is very hands-on and human in the loop. Like, I'm sitting there watching that thing like a hawk and having conversations with it, which I realize is not how most people are using AI at this point. [00:08:58]

I think a lot of people are very much on the, in the cloud, multi-agents, how many of these th- things can be run in parallel, which I now have opinions on. Part of it is ... Well, a lot, a lot of it's the point that I'm making the draft blog post, which is understanding is still critical. And I'm a very, I'm a very firm believer in, you know, the fundamentals and understanding and building a mental model of the system. [00:09:10]

And I personally, for me, I want my brain engaged. I want to be thinking through the problem, and then I'm using the agent to amplify my own abilities. Now, don't get me wrong, there's definitely been a few moments where I was, like, you know, out and about. It's like, you know, it actually would be kind of nice if I could just pull up my phone and tell an agent, go do this thing. [00:09:34]

Like, I, I, don't get me wrong. I get the appeal. [00:09:54]

Carl: Yeah. [00:09:56]

Mark: But in terms of day-to-day development work and how I approach programming, I want my brain active, engaged, and thinking, not just handing it off to an agent. [00:09:56]

Carl: Yeah. I hear that. I think I use it in both ways. There are a lot of things that, like you said, so it's just, like, it's not quite high priority enough to justify. [00:10:08]

And that's where I'll use, like, more of a background agent. Like, you know, here's 15 one line descriptions and, like, just from the one sentence, it's clear enough what's needed. Like, you know, adjust the size of this. Add an element that controls this. Like, those are mechanical enough that it's really just, like, getting it right, making sure it compiles. I don't currently have a functioning workflow for that exactly. [00:10:20]

What I'm doing right now in the last four or five weeks just, like, hasn't really been of that type of development. So I am still, day-to-day, most of what I've been doing is very much, like, the mech suit variant. You know, people talk about, like, automated versus mech suit, like robot or mech suit. [00:10:44]

Driving AI closely without reading its code

Carl: And yeah, so I'm driving it pretty closely, but I'm not really reviewing its output very strictly. I'm, you know, I tell it to use subagents, and then every so often I'll, you know, tell it to write me a report, like, how is this working? What is it doing? Ask it some targeted questions to make sure that the mental model I have matches what's actually there. [00:11:00]

But that's a little different, I think, than what you described, Mark. Like, I'm not actually, like, I don't read almost any of the code. I try and think of it more from, like, my engineering manager, tech lead, product manager hat. I do really try and sit in engineering manager/product manager role and say, like, "Okay, how did those people talk to me as an engineer? [00:11:17]

Like, they were not technical. They didn't understand anything of what was being built, and yet it was their job to make sure it was functioning as intended." So that's very much how I try to think about my work now is from that perspective. It's like I, instead of reading a line of code to ensure that patterns are followed as I intended, like, set up a lint rule and then, you know, maybe it's only 80% is good, it's not gonna catch all the subtleties, but, like, my experience of working on a team is, that's kinda how it works anyway. [00:11:37]

Like, if it's not captured in the lint rule, eventually it will break. Like, eventually, someone will have been onboarded and not ha- be deeply steeped in the history of the project or just be tired that day and they forget about it or whatever. So, like, that was very much my perspective as, uh, you know, when I've been a tech lead is, like, if bad code goes out, you know, the blameless postmortem, it was a process failure. [00:12:06]

This should not have been permitted by the automated checks. And so that's kind of how I'm thinking about it is just remove the abstraction a little bit and guarantee the outputs and then work on automated tracking of automated evaluation of the code quality to make sure that's at a level that I need it to be. [00:12:30]

Swizec: Yeah, same. I think that's my perspective as well. I've ... Going up into tech lead was really kind of almost broke me as an engineer because I was like, "Oh my God, all of this terrible, awful code, but it works and it's fine and everything is okay and the team just handles it. And if anything is wrong later, we just fix it. It's totally fine." [00:12:48]

And I kind of treat AI the same way. I, I do a lot of driving from, like, a product perspective and for critical features or, like, super gnarly business requirements, I go into the ID and I drive it kind of like what Mark was describing, reviewing every line of code, clicking yes, et cetera. [00:13:12]

But they do really well with follow-ups. Cursor gives you the wrong thing back in a Slack thread. You just say, "Ed curs- ad cursor, go fix it. " A lot of the times, those fixes are actually, "Oh, yeah. Now that I'm holding a working MVP, it doesn't actually feel right. I totally didn't even think of several features that it needs before it's useful." [00:13:29]

I also really like the code review flow. I don't know exactly what we did, but we hooked it up so that you can do a PR review, like a code review for your cursor agent session. And in GitHub, you just go at cursor, fix this, or you give it information basically the same as you would with a team member, and then you just get follow-up, commits, and it fixes all the things. [00:13:49]

Carl: That's very much been my experience as well. One of my biggest struggles as a, as an engineer is, like, I remember hearing about this sort of a stereotype of, like, give it, give this task to a junior engineer because they don't know it's impossible, you know? The sense of as you get more experienced, you get to see more of the complexity, and the complexity makes it harder to take action because you're now evaluating trade-offs instead of just kind of ignoring them because you don't know they're there. [00:14:10]

And I would get so stalled into analysis paralysis and, like, what's the correct way to do this? How do you do this best? What's gonna have the best maintenance trade-offs and the lowest, you know, the tech debt and whatever? And that's just such a difficult way to actually solve, especially a novel problem. Like, if you understand a problem well, great. You can specify everything in advance. But, like, if you're working at the edge of your knowledge, at the e- edge of your understanding, then, like, you're gonna go the wrong way at first. And it's so painful to work on something for three weeks and then go like, "Oh, shit. This is just completely the wrong architecture and I need to start over." [00:14:34]

But it's so much less painful now with AI because, like, great, what a wonderful learning. Let me take that, let me have it write a three-page document about what we learned, what the new problems are, go back and forth, interact with it about, like, designing a new data model and architectural, you know, process flow. [00:15:09]

I actually just did this in the last, like, week. I've been benchmarking local LLMs because I want to better understand which ones work for what tasks so I can not have all of my AI usage be based on some mystery frontier model in the cloud. [00:15:28]

And I just, like, you know, I started with just, like, "Hey, give me a script that will run this model. Start up a, you know, LLM server and then run prompts against it. " And then, like, that grows, "Oh, I need, I wanna be able to kill it and restart. Oh, I wanna be able to, you know, version the prompts as I change them. Oh, I need to have it, you know, run a code evaluator when I'm giving it, like, a code generation challenge." [00:15:42]

Eventually, it became un- unmanageable because of the tech debt. It's, you know, it grew and expanded and I learned more about what was needed. And so I just started over and I said, "Great. This is a Python ball of mess and it sucks and I hate it." So let's talk about the architectural flow of it and now let's add some lint rules and let's rewrite it in effect. [00:16:06]

So it's actually like a high quality code base with, like, resumability and scheduling and whatever. And now it's working way better and it's, like, maintainable. It's been really powerful. [00:16:26]

Mark: I freely admit that the very hands-on style that I've got is intentionally learning. I know it's possible to go faster. [00:16:35]

I know that it's possible to delegate a lot more. I am treating it much more as an extension of my IDE and keyboard than I am as a junior developer delegating the work. That's fine. I am good with that. That is what works best for me and my brain. [00:16:43]

Swizec: You might start doing that less and less as you use it more. [00:17:01]

I started with doing that a lot more, and then eventually I realized, wait a minute, I'm just clicking yes on everything and then giving it a follow-up prompt to change the things I didn't actually like, but click yes on anyway. [00:17:04]

Mark: I certainly didn't think a year ago I would be using any of this at all. I was, I was convinced that was a red line that I would, I would never, ever cross on pain of death, and here I am. [00:17:16]

But also, like, I mean, I've, I've found a workflow that I will be hopefully blogging about in the next day, next couple days that does actually work for me. And the hands-on aspect of it is what I get good results out of, and it's what fits my brain. [00:17:25]

Carl: Well, okay, let's take that as jumping off point. Like, what tools [00:17:40]

Let's do, like, super concise, just, like, list what tools and what models you're using day-to-day. [00:17:44]

Mark's workflow; OpenCode with CodeNomad UI, plus IDE+git UI. Opus 4.6 on API

Mark: So my, my own setup, my intro was the kilocode VS code extension with, you know, it was probably either Sunat 35 or Sonat4, whatever was available around September-ish last fall because I didn't want to go anything command line at first. I wanted to stay in a graphical environment. [00:17:50]

I tried Claude Code for about a day. Tried the VSCode extension, which didn't work at all, and then I tried the command line tool, and I, I did not like it. I tried the OpenCode command line tool, also did not like it. How do y'all deal with copy paste in a command line environment? [00:18:09]

So what I have now, I'm using OpenCode. My personal laptop is Windows. My work laptop is Windows, but I work in WSL. So I actually serve OpenCode from within the WSL environment, and then I use a third party web UI for OpenCode. [00:18:24]

OpenCode has a very nice server client distinction. The text client is just one of the possible clients. So I found one called Code Nomad, which is very good, works great. So I actually serve Code Nomad plus OpenCode added the WSL side, and then I just hit local host whatever port in my browser on the Windows side, which also avoids any cross-platform file shenanigans as well. So I've got my chat sessions and my tabs open in the browser. That's now my development environment. [00:18:42]

And then I still have VS Code open for looking at some of the diffs and editing that my ... I much prefer a Git graphical client called Fork, but it doesn't work well in Linux, so I've just stuck with the built-in VS Code stuff. I actually don't like it, but I've been too lazy to go find a better alternative. [00:19:16]

Model-wise, I've basically been on whatever the latest and greatest anthropic is. We have corporate keys, da, da, da, da, da, da. [00:19:32]

Also, I have somewhat intentionally tried to avoid model hopping. I don't want to be running a bunch of evals every other week and saying, "Oh, this one provides me a 3% increase in such and such a benchmark. Clearly, I need to switch my entire workflow to a different model." and granted, OpenCode does let you just pick and choose what model you want, but I'm trying to get something that's good and consistent and that I know works, not chasing the hypothetical maximum performance. [00:19:39]

Carl: Okay. So you're, you're on OpenCode and using latest Claude Anthropic models just through API usage? [00:20:10]

Mark: O- Opus 46, yeah. That's the other thing. Uh, it's, it's API keys, not the various, like, you know, $20, $100, $200 max plans. So I, I read about people getting the resets and it's like, I haven't do with that because I'm also not paying for it. [00:20:19]

Carl: Right. Cool. Okay. [00:20:32]

Mark: It's like knowledge that my experience may not be universally shared. [00:20:34]

Carl: Okay. Yeah. [00:20:38]

Swizec's workflow, latest Cursor on Opus

Carl: Yeah, Swizz, what's your workflow look like? I'm curious, I'm very curious about yours because I think you're by far the most advanced agent user between the three of us. [00:20:39]

Swizec: Which is really funny because I was surprised to learn earlier this week that 97% of my code is AI because I really talked. I was like, "What?" [00:20:47]

But I actually have an extremely simple setup. I use Cursor, I keep it updated to whatever the latest version. So when it pops up with, "Please update," I click the button. I think the latest Opus model or whatever it is, it's like something 4.6. I think it's an Anthropic model. We have a Team subscription, so CompanyPays gives us an infinite budget, but I think I'm actually using, like [00:20:57]

It's actually funny. I don't know ... We were just talking about this today. I don't know how this happened, but on the Cursor Leaderboard, I have the second most AI usage of all of the engineers, and I have the least amount of dollars used. [00:21:25]

Carl: Fascinating. Interesting. [00:21:40]

Swizec: I have literally spent $25 this month. So anyway, I use Cursor, I use @cursor on Slack a lot, and I use @cursor on GitHub a lot. [00:21:41]

We also use Linear, and I've started more and more delegating my linear tickets to cursor. So look at the linear ticket, be like, "Eh, I didn't write this well, add a little bit more context so that a dumb bot can know where to go fix things or what to change, and then just click delegate to cursor, and then I review the PRs." [00:21:53]

That's my workflow. I try to keep it really simple and easy, because like Mark said, I'm not looking to super maximize my productivity. I'm more looking for, you know, as a manager, I'm supposed to stay on SiteQuest anyway, so this is a really good way to code between during, uh, between and during meetings when I'm supposed to be paying just like half attention. [00:22:13]

Carl: Yeah, that's really interesting. I, I, I like that you two are like kind of two ends of the spectrum here. So as you use it as like very much in a managerial capacity, like, you know, the same as you would ping a colleague, you ping cursor instead and just say, "Hey, do look at this. " [00:22:36]

Swizec: Yeah, pretty much. I, I've been doing that a lot. [00:22:52]

Carl: And it's all within collaboration platforms, I guess is like a big distinction here. It's all in space- A lot of it is. Yeah. Okay. [00:22:54]

Swizec: We're now experimenting with building like a feedback loop so that we would have a bot that Sentry sends us errors and we're thinking of having a bot that looks at those errors, figures out how to fix them, and then just issues a PR when we get, so that we could have automatic PRs- [00:23:03]

Carl: Yeah. [00:23:20]

Swizec: for, at least for some er- no, like, you know, probably not for super critical, crazy, important things, but there's a lot of errors that happen where it's not that important, but it's nice to fix. [00:23:20]

Carl: Yeah, definitely. Right, the long tail of Century issues. [00:23:34]

Swizec: But when I'm like actually hands-on coding, I use it a lot to write my tests because I know what I want to test and I can describe the situation to set up, but I hate doing the grunt work of setting up your database in just the right way to have 50 models, et cetera, [00:23:37]

Carl: yeah. [00:23:58]

Carl's workflow, mostly Claude Code but looking at custom orchestrators

Carl: Yeah. Okay. Interesting. I, I kind of split y'all's experience a little bit, or I'm working towards ... I feel like I'm closer to where Mark is right now and I'm trying to move towards where you are, Swiz. Yeah, I almost exclusively am using Claude code with Opus. I've played around a bit with ... Like I, I used Copilot, you know, GitHub Copilot, like once to, like, scaffold a prototype that I was experimenting with. [00:23:58]

I don't like the experience of it being in a web browser. Like, something about it ... I don't know. I also don't like code spaces or, like, remote development across SSH. So, like, this may be just my own, like, biases and preferences, but I really like just ... It's right here. It's on my machine. It's an environment that I have set up. [00:24:22]

I know exactly what's available to it and what's not. Just, like, I guess I've prioritized, at least in that where I'm trying to use it like a Mac suit if speeding up my own pr- individual productivity, I just want it to be predictable and understandable for myself. To me, that's very much just been Claude code with whatever defaults pretty much. [00:24:40]

I've played around a little bit here and there, but yeah, I'm trying to work towards ... One of my many projects that I have in flight is a personal, like, orchestrator. So I had started out kind of my foray into, like, earnest AI focused, using it to the extent that I am now, as opposed to more limited reading every line of code, going in and editing it myself. [00:25:01]

Exploring fully autonomous agents

Carl: That's only really been since, like, February when I started playing this AI agent game. And it's been really interesting thinking about ... Because putting an agent in a simulated world and, like, having it autonomously play a game and do so in an interesting way, you know, effectively and interestingly, really just, like, got a bunch of wheels turning in my head. [00:25:23]

And so, like, Claude Code works really well for me for, like, pushing the envelope, like, expanding what a project is, what it can do, and I have really enjoyed using background agents more, like, very much like what you described to us of just, "Hey, oh, fix this. This is broken. Here's this bug." I don't currently have anything like that operational, but I did get my little personal orchestrator working for a minute. [00:25:45]

It was just wor- working on the GitHub API and I just said, like, "Here's a repo, like, go, you know, read the issues, triage them, prioritize them, take a task, open a PR, and wait for me to review it. " And it worked, but I didn't give it any guardrails, so it ended up, like, redoing the same GitHub issue multiple times, or, you know, it would re-review the same PR over and over again with, like, a page and a half of a comment. And so I was like, "All right, okay, this is proof of concept, it works, but, like, clearly I need some additional things set up." [00:26:10]

And I guess one, another thing I wanna say, like, kind of what you said was about, like, using Sentry Data as an input for what to work on. I think that's the frontier. Like, that's what is currently being explored. Like, how do you do that effectively? [00:26:43]

Swizec: Yeah. You need the feedback loops. So I was reading a lot of how to build an agent papers the other day, and the main inputs are basically rag, memory, and feedback loops, and from there, it can do a lot. So Cursor, for example, Cursor Cloud agents through Slack, they actually, when they're developing the feature, they will fire up a browser and go test it, see if they can actually do the thing, and if they can't, they will then c- continue iterating. [00:26:56]

And in the end, the PR doesn't just have code. It has screenshots and videos of the working feature, which is what I require from all of my engineers, and it makes reviews so much easier. And there was another ... Oh, yeah. So I think the longest I've managed to do, to have it spin when I asked it to build an entire feature. [00:27:27]

So, like, I would write a maybe 200 word, two or 300 word prompt in Slack to add cursor, and it took ... I think it spent 45 minutes to come back with the working feature, and that was amazing, because I was in a meeting for that whole time, and then I just looked at the PR and gave it feedback. [00:27:47]

Carl: Yeah. That's incredible. [00:28:06]

Mark's AI debugging work in React core

Mark: So my day job, we're coming at it from a similar but also sort of opposite angle. We, we have built a time driver to bugger, and originally the premise was that by making a DVR style recording, you as a person can go in and do all the investigating in the lines of code and the print statements and everything else so that eventually you as a person figure out why this was broken. [00:28:08]

So we shipped an MCP a couple months ago, and I've already seen some very real examples of agents being able to go in and solve bugs that they wouldn't have been able to otherwise. I actually put up a post about this a week ago. Dan Abermov had filed an actual React bug saying that the used deferred value hook sometimes fails in production, it's stuck, like a render behind. [00:28:28]

And he had a repro and he said, uh, "I've had my agent try to look at it, but I can't find the answer." A month later, he comes back and files like a four-line fix deep in the guts of React Scheduler to actually fix it. And he posted on BlueSky later, and apparently what he had to do was rebuild the React Library with a bunch of console logging added so that his agent could look at the prod build and eventually trace what was going on and figure out how to fix it. [00:28:52]

So I'm like, "That would be a great marketing post comparison." So I took his example, I made replay recordings of the working dev build and the failing prod build, handed them to an agent, and I said, "Here's a bug report. Here's the two replay recordings. The issue is somewhere in React. Can you find it?" took 10 minutes. [00:29:18]

So I'm like, so then I'm like, okay, well now let's make it like, you know, something resembling a proper experiment. So I took the same two recordings and I spun up four simultaneous sessions with differing instructions. [00:29:38]

The first one was just a basic, here's a bug report, go investigate, actually less context, the proof of concept. The second one, I gave it like a eight step investigative process to follow. The third one had a few paragraphs just naming some concepts and Reacts internals, like not even file structure, but just things like, you know, schedulers, fibers, lanes. And then the last one also explicitly listed some of the replay MCP tools we have available. [00:29:50]

All four of the sessions found the same bug and suggested the correct fix. They took respectively 28, 17, eight, and seven minutes. So on the one hand, you know, ob- obligatory sales pitch, replay recording, finding bugs, it's awesome, it's great. We're building some cool stuff with it. But it also showed me a lot about the value of the prompts and the context that you give. [00:30:18]

There was another example I was working on where someone had made a, an example NextJS app with some example bugs in it and was asking an agent to find them. And in one of them, there's a, there's a double loading screen that's caused by mixing and matching suspense and Tanstack query loading state. [00:30:44]

The AI always suggests the use suspense query hook, but apparently if you do that, it leads to a hydration mismatch error. And the real answer is to do some server pre-fetching instead. So like you have to think bigger, think architecturally. So I did the same thing. I tried, you know, making some re- replay recordings and feeding in the, the varying instructions. [00:31:00]

My agents mostly got the same base level used suspense query error. And then I tried one more session where I fed in the NextJS and TanStack query skills files. And now the agent actually said, "Well, useSuspense query is the initial fix, but you really ought to do server pre-fetching instead." [00:31:21]

Value of providing more context

Mark: So again, like that, that taught me a lot about the proper context. That also says a lot as we're trying to build our own CI debugging agent that looks at test recordings, so clearly we need to give it, you know, good prompts, user-based context, all that kind of stuff. [00:31:42]

So, I mean, I think even something like that can maybe help explain some of the differences and results that different people get. [00:31:59]

Carl: Yeah, no, the impact of prompting and available context is, like, so massive. As we're talking workflow, something I do very regularly is, you know, start with a prompt, start with, like, if I'm gonna add a new feature or redesign something or what, you know, a large task, not a bug fix, you know, a sprints project, not a ticket, then I'll start off with, like, a 200-word, like, prompt of, like, "Here's what we're trying to build. [00:32:05]

Here's how I think we will need to do it. Here's a couple of parts that I think are gonna be important." You know, you know, have it explore, do the implementation, review, you know, and then I manually confirm. And then I'll tell it, like ... And I guess I'll do this at a couple of points throughout as it's exploring and, like, evaluating things. [00:32:32]

I'll ask it, like, "How was the documentation? Like, did you find everything you needed?" And that has been, like, totally transformative for, I think for token usage as well, because, like, just by asking that, it'll say, like, "Oh yeah, it was all ... Here's the three files I referenced and I got everything I needed." [00:32:47]

Or, like, "Oh, yeah, this file was out of date. You know, I did the wrong thing at first and then I had to go back and rework it. " So I'd recommend that we update this" and it makes those recommendations just based off its own experience of reading the code. And so, like, just by doing that fairly regularly as the code base evolves, I manage to keep, you know, the documentation pretty well up to date. [00:33:04]

Swizec: Are you asking it to write its findings back into documentation or are you updating the docs? [00:33:27]

Carl: I'll read it with a skeptical eye of, you know, like, does this sound like it is a real problem or not, a real area for improvement? And then I'll just say, like, "Yeah, hey, can you update those docs?" Often, I'll come at it with a pretty clear intention of, like, we just revamped how scheduling works. Let's analyze the architectural overview document that we have and see if it's still accurate and then tell it ... [00:33:32]

AI-owned documentation

Carl: You know, so, like, I will do some documentation specific projects with that in mind, but for the most part, yeah, just, like, ask it how the experience of the familiarizing itself with the code base is, and then give it free reign to improve that for the most part. [00:33:58]

Swizec: Yeah. I think one thing I would be worried with that we have some people in the team experimenting with that, and they all agree that after a few iterations, like, a few weeks later or a few months later, you end up with very spaghettified documentation that's essentially just AI slob that humans definitely don't wanna read, but even the AI barely wants to look at it and read it because it just keeps getting low, lower and lower signal. [00:34:13]

So I think ... I don't have a solution for that, but it's a thing I've heard. [00:34:40]

Carl: That's fair. I haven't really evaluated that recently. I did come at it with trying to say, like, "Here's five documents at these levels of abstraction in the code base." So I do try to give it a little bit of overall stru- structural guidance, but that's a good thing to, that's a good thing to look out for. [00:34:45]

I haven't really evaluated it. That's also how I get my own mental model of the code. So I guess, like, I don't necessarily write it, but I will read it, and if it's nonsense spaghetti, then it's like, "No, we gotta do this again." Like- [00:35:03]

Mark: That also ties into the longer term memory question. So, you know, the problem is ev- every session is fresh. [00:35:15]

It knows nothing, you know, every, literally everything is being injected, you know, agents, MD, you know, whatever rules, files, et cetera. So how does an agent even know that you have these nice architectural docs that you've been keeping up to date? Or how does it know that, you know, last week, a week earlier, whatever, you made these particular decisions, and that's why we ended up here. [00:35:22]

Or it has no idea what any of your code base is. Let's go read 30 files to re- form a brand new, fresh set of memories that compress the context. And some of this can be, can be dealt with partially. There's ... I, I, I highly recommend tools that will do AST-based scanning of the code base and preferring those for what, for loading chunks of code rather than just, like, blindly whatever built-in read file tools are there. [00:35:46]

But that is actually where I'm running into the limits of my own personal workflow right now. I have, you know, dozens of feature and research docs that I've generated. I have daily progress docs. I have sub-task handoff docs. There's a lot of very valuable information in there, and the AI has absolutely no clue that any of that exists. [00:36:14]

So I'm n- I'm now f- starting to feel the need that I need to have some kind of, you know, review sweep process, some kind of tool to, you know, index the markdown file, something to form that longer term memory structure, and I keep bookmarking hundreds of tools and saying I'm gonna go investigate them and haven't done so yet. [00:36:37]

Swizec: If only you had a tool that's really good at summarizing large pieces of text. [00:36:56]

Mark: I, no, I, I actually have done some of that. Um, I just haven't actually settled on one and tried installing it yet. [00:37:03]

Using good engineering practices still matters?

Swizec: One thing I found also really helps for context and stuff like that is actually structuring your code well. So having a vertically oriented architecture, small balls of mud that are self-contained rather than one large horizontally sliced ball of mud makes it easier for humans, and it also really works for the AI when you can say, "Go add a feature to this directory." [00:37:09]

And it's the, like, basically use your directory structure as an index for where to find different kinds of code. [00:37:36]

Mark: That sounds suspiciously like software engineering practices, and I was told those don't apply anymore. [00:37:44]

Carl: Yeah, right. Like, the main thing that I've been trying to keep in mind here of using it, and, and this was, this kind of talk goes back to your recent blog post of, you know, where you talk about how much code A- AI is writing for you, and to just talk to it like, these models were trained on things like GitHub discussions and PR reviews and code comments and whatever. So, like, it's not some new, esoteric, crazy, unpredictable thing. Like, the more you talk to it, just like it's a competent engineer, the more it will behave like a competent engineer. [00:37:50]

And so it has all of these assumptions about, you know, social norms within the context of, you know, text documents describing code and documentation. And so the, the more you understand the social norms that it are deeply baked into its training, the better it does. So, like, yeah, like, I saw these, you know, memory startups where it's like, "Oh, we will automatically generate documentation for your code base and make sure it's up to date." [00:38:22]

And it's like, I'm already doing that with a Read Me document tagged with a GitHash of how, when it was last updated for free. Like, if you have a couple of folders, a couple of directories full of code that is, like, pretty well isolated with a Read Me document in there, like, I don't need to tell the AI to look for the Read Me because it knows to do that. [00:38:49]

Of course, it knows to look for a Read Me. So there's definitely a lot of difficulty with keeping the signal high, but, like, that's not new. I don't know. Like, that just sounds so much to me, like, working on a team of eight engineers and, like, not everyone has the same shared context. Not everyone reads every email or every Slack message. [00:39:09]

And so, like, as far as the challenge of, the, the challenge of keeping a team up to date on best practices and recent decision making, versus keeping an AI at the same level, like, that, those feel really similar to me. It's just engineering best practices and communication norms. [00:39:30]

Swizec: With, with the major difference that AI will actually go read the documents you tell, you ask it to read. [00:39:50]

Carl: Right, right. Like, one of my, like, you know, war stories was I was a contractor somewhere and they kept having, I kept having to do a rework because, you know, QA was overwhelmed and, like, you know, they finally get around to reviewing PRs and, oh, it's broken. Oh, gotta go back. Oh, there's all these conflicts now because [00:39:57]

And so, like, despite being a contractor, I sat down. It's like, no, we need to fix our review process. We need to fix our merges and whatever. Spent, like, two weeks doing that, get everyone on the same page, man. Next day, the, you know, tech lead employee at the company, the guy who should have been doing that process is like, "Nah, this is too much. Like, I'm just gonna force push." And he took down production. [00:40:15]

So it's so it's like, uh, when people talk about AI doing stuff, it's like, "I don't know, man. Have you ever worked with engineers?" [00:40:37]

How do you know the right code to make?

Mark: Uh, so this, this does tie into a lot of the conversations that I had last week. I, I was at both the AI engineer and React Miami conferences. [00:40:47]

And the general theme of the discussions there between the talks and the people and then, you know, all the different chatter online is we built ... And I also ranted about this in my 15,000 Word unpublished blog post. We built a bunch of software development practices for people, the agile manifesto, linear issues, PR reviews that require multiple people to stamp them or, you know, as a way to share knowledge, standups, like these are all people- based processes, and it made sense when humans are the limiting factor and you have to be very intentional about making sure you're writing the correct code. [00:40:53]

Like, not just does the code work, but are we even spending the time and effort on the right thing in the first place? And we now essentially have a generate infinite amounts of code button, and now we're finding out that we've moved the bottleneck further down the chain into all the verification and QA sides of things. [00:41:32]

And so this shows up in, oops, GitHub is overwhelmed because we've literally 10Xed the number of PRs that are being pushed or, wait, we've got a bunch of senior engineers, but they're literally spending all their time reviewing PRs generated by the junior devs with AI, much less what happens when you have a dark factory of agents cranking out code twenty four seven and no one ever looks at it. [00:41:51]

Like, we haven't figured out what the resulting processes ought to be, and one of the points I make in my blog post is that I think right now we're all operating under the assumption that there's no limit for how fast we can go, and in reality, we're gonna figure out the actual limit is maybe, like, 3X of what it used to be, but we need to, like, accept that and plan for it instead of thinking that if we shove everything in one end of the pipe simultaneously, it all comes out the other end. [00:42:15]

Swizec: I have opinions. Um- [00:42:46]

Good communication still matters

Swizec: Yes. I think I wanted to say first is I really like, Carl, you mentioned that you start sessions with a really long 200 word prompt that gives all the context, doesn't just tell the agent what to do, but also why it's doing it in, like, other context. Same. This turns out works really well with humans as well. [00:42:49]

They give you much better work if you tell them why they're doing it or what the goal is. And sometimes if you tell, if you tell them what the goal is, they might even come back with, "Your solution is dumb. We should do this other thing instead," which, wow, can you imagine using engineers' brains for thinking, not just writing code? [00:43:08]

But I think the other thing is, we are generating a lot of code, and we think the bottleneck is code review. I think there's kind of two bottlenecks. One is that when you're moving really, really fast, you have to actually be more careful about working on the right things because if you're just digging yourself into a hole faster, we just had an example recently where we broke Agile, we were like, "Oh yeah, we know what we, what we need to do. Let's just have Claude crank out 6,000 lines of code in one gigantic PR." [00:43:24]

First of all, we couldn't review that, so we had to break it up into a bunch of sub-tasks and then turn that into sub-PRs. Turns out that took another extra day of work and everyone was distracted while doing this, so we weren't focusing on what we were actually supposed to be doing. So I think distraction is still bad. Multitasking is still bad. We're not as good at multitasking as we think we are. [00:43:55]

And the other thing is we, when we split all of that up, we found that Cloud made a tactical mistake very early on, chose the wrong architecture for how to build something with React. And now you have a lot of code that needs a lot of rework to actually make work, and you're wasting reviewing time, you're wa- you're wasting a lot of time that could have been solved if we started with a small task to set up a small thing and talked about it, or maybe even talked about the architecture before we wrote six, 7,000 lines of code, and then just wrote the correct code the first time. [00:44:18]

Carl: Yeah, 100%. We're hitting communication bottlenecks much faster now. Yeah, like Mark said. [00:44:54]

Mark: Communication and thinking and planning was always the job. [00:44:59]

Carl: Yeah. [00:45:03]

Swizec: Yep. Except now you're running, like, 10 times faster. So if you take the wrong step or as your first step, you're just running in the opposite direction of where you wanna go, but really, really fast. [00:45:03]

What will "review" look like in the future?

Carl: Right. Yeah. Right. It's very easy to get in extremely the wrong place in exactly the same amount of time. That touches on something I've said before in this podcast. I think that the future of, like, review is gonna be less code review. The architectural side of things is still gonna be important. Like, it's not just, does it work? [00:45:13]

Does it do what you intended? You can't fully treat it as a black box. The box has to be translucent, you know, at least a little bit to avoid major architectural problems that are gonna cause a production outage or make it impossible to scale or whatever. Like, it's not all going to be, does this function. [00:45:32]

But I do think, does it function is going to be a much greater part of this? My sense is that it will rely a lot less on reviewing the code so much as getting a plausible mental model of the architecture, and then it, you know, and then statically verifying that it does what's intended. So, like, my, my theory here is that we're gonna start seeing a lot more end-to-end testing and user acceptance. [00:45:49]

Automating functionality tests with deployment practices

Carl: A thing I did recently that I haven't fully executed on yet, but ... Well, I, I did a lot of it. But so a, a project that I have, I fully rewrote the CICD so that instead of PR checks, review, approve, merge, ship, instead of, you know, that, like, trunk-based development, where every PR gets shipped individually, I move to more of a, like, Git Flow type architecture where it's like, no, here's the version. This is going to go out. Uh, here's our release candidate. And then that single release candidate gets pushed to a staging environment, and then I do the user acceptance testing of does this function as I need it to. And then once I have that, once I've done that manual testing, great. I know this code is working as I meant it to. So now I'm going to have it write a bunch of end-to-end tests to verify that it will continue to do that when I make changes. And I think that's gonna be kind of the new cycle of, like- [00:46:17]

Swizec: I want that, but on every PR. [00:47:10]

Carl: Yeah, right. And I guess to me, like, that's where manual testing is now the bottleneck. [00:47:12]

Like, you cannot ... At the end of the day, this needs to function, this needs to solve a problem. Any code you write needs to solve a problem that real humans have. Or I guess, you know, sure, other agents or whatever. [00:47:17]

Swizec: I've experimented with automated end-to-end testing. It doesn't quite work yet. I think the models are, or at least the models I was trying were too slow, but the idea is that instead of telling that [00:47:28]

Instead of writing a test as what the features that should be there, it's more about, can the user do a thing? And then because you have a computer use model, it can look at the browser and it's automatically testing both your UX. Like, if the model can't figure out how to do what your user is supposed to be, drunk users won't figure it out either, or tired users or whatever. [00:47:39]

So you just point it at the browser and you'd say, "Go, like, go place an order." And at the end of the day, as long as it can place the order it wants to place, you can keep iterating on the implementation, you can keep iterating on the design, you can keep iterating on the UX, you just get tests that are based on can the agent place an order. [00:48:03]

Carl: Yeah. Oh, that's really interesting. That's, that's a really good variant on what I was just kind of talking about because, like, sure, static end-to-end tests that are verifying, like, this button with this test ID exists and the flow completes as expected. Like, sure, okay, it functions, but is it usable? [00:48:23]

That's an interesting usability automated usability testing because that kind of goes back to what we were talk- talking about with, like, documentation and code notes. Like, just make it intuitive. Can an agent intuit how to achieve a general task? Oh, that's really interesting. [00:48:38]

Swizec: If you've ever used VCR in Rails, that's kind of where I got the idea. [00:48:52]

With VCR, you do full integration testing with calling remote APIs, but you don't wanna call them every time, so you record the responses and you keep them locally. So you then write tests against those local responses, but if the API ever changes or anything, you just regenerate them and you find all of the bugs in your code that don't fit the new, newly released API. [00:48:57]

And you could do something similar with this where you have browser-based acceptance testing, and it records what it's doing so that you don't have to spend as many tokens every time. And you just d- when you change the UI, you delete it and you see if you can do the flow again. [00:49:19]

Carl: Yeah. Totally smart. Interesting. [00:49:34]

Swizec: Doesn't quite work yet, but that would be really cool. [00:49:36]

Carl: We've kind of been going into this direction, but let me, like, sort of, like, you know, refocus a little bit. Like, so what do we think the current landscape of tools, of AI tools looks like? We've kind of been discussing that in, in, we've been dancing around it. And I guess where do we think it's going next? [00:49:38]

Mark: Going or ought to go? [00:49:55]

Carl: Either, both. Both. [00:49:57]

Mark: My general inclination as the person who found one tool set and is stuck with, and is sticking with it and is not actively trying to change what he's doing. [00:49:58]

Certainly what I'm seeing online is turning towards automate all the things, which I think is a very understandable impulse for a software developer. If you can do things once, you can do it in a loop, you can run it in parallel, you can distribute it, you can have an agent do it, et cetera. [00:50:06]

And I think it kind of ties into the go as fast as possible at all costs for the purpose of going as fast as possible, direction that I see. I mean, like this bit about, you know, the dark factories, the idea that a team never even looks at the code, that it's truly all agents all the time, and all you say is, "Do something that accomplishes some goal, and you never even look at it, " is sort of an ultimate outcome of that. [00:50:21]

I don't think it's a good one, but I see how it's the idea taken to a logical extreme. [00:50:48]

Carl: I, I also have been pretty ... I found a tool and I'm sticking with it. I've been noticing Claude Code pulling in lots of ideas that I've just been thinking. Like, as it evolves, it's like, this is a productized version of how I've already been using it. [00:50:53]

You know, like they added a /btw command that lets you ask a question and it will ... You cannot use tools and it does not go into the context history. So it's just like even do a little aside. Like if you wanna ask, like, "What's this thing doing?" I had already been doing that by way of, like, I'd ask it a question and then I'd go back and just, you know, restore the conversation to that. [00:51:06]

And similarly, two months ago, I had been saying, like, I would actually spin up a Claude code instance that was on Haiku because I just need to summarize this and it's easier and I wanna manage my usage a little bit more precisely. And, like, now I don't have to do that because I just say, use a subagent and Claude Code is smart enough to say, "Oh, I'm just summarizing. Let me use Haiku." [00:51:27]

What behaviors belong to the agent, and what fundamentally can't be part of the agent?

Carl: So I've just been watching, like, kind of what the agent itself is doing versus what I need to tell it to do, or proactively manage, converge a little bit. So that's, that's had me wondering, what outside of the agent, what is not going to live within the agent. And I think where I've landed on that is, like, everyone's talking about memory the last six weeks or so, and I think that's wrong. [00:51:49]

I think that's just gonna be conventions and documentation. It's just knowledge. I think what's going to persistently live outside of an agent harness, as it were, is, like, incoming information, like a data stream, like GitHub issues, text, you know, the Slack chat, a Century Alert, a production alarm. If you have a data stream that is categorizing those and prioritizing them, and then giving that to an agent, to an autonomous agent that is just working, like, those are different things. [00:52:12]

I think you cannot have a single generic agent that is able to connect to every possible data source. So that to me feels like a boundary that's gonna be pretty strong for the coming months. [00:52:44]

Swizec: I don't know. I think for me, I feel like going super deep into what, at least on the internet, a lot of people are talking about various MD files and orchestrations and all the crazy stuff. [00:52:55]

I feel like that's a little bit like ID skins and WIM shortcuts. It's like, yeah, sure, it's cool, but I, I think you're over complicating it. The models are gonna keep getting stronger and better, so I would just think they're gonna be able to do bigger and bigger tasks. I think feedback loops, like what you said, what is outside of the model? [00:53:06]

Building really strong feedback loops is important. I think memory documentation inside the code or making the code itself easier to research or giving it MCP tools to, like, notion or linear or whatever, you keep your organizational memory. Having access to organizational memory will help agents as well. [00:53:25]

Yeah. I don't think we're ever gonna come to full automation of anything, really. I think there's a strong gelman amnesia when it comes to th- these things where agents will fully automate every job except the ones I'm strict, super familiar with. That is just way too complicated and there's too many deals. [00:53:46]

Everyone feels that way about their job because newsflash, they're all too complicated. [00:54:06]

Carl: I wanna explain that reference briefly for people who aren't familiar. Gelman and Amnesia, that refers to the idea of, like, you're reading a newspaper and you see a story about your professional industry or something you're very knowledgeable about, and you see everything that it got wildly wrong, and you're like, "Who even wrote this? What are they doing? These incompetents." [00:54:11]

And then you read the next article, and you're not familiar with it, and you just take it super credulously, and it's like, "Oh, yes, look at these," you know. It's a, like, I think that's a pretty good way of thinking about how people are talking about AI right now, yeah. [00:54:29]

Swizec: And I think, from my perspective, go hard as long as you can. I think the bubble is going to collapse in the next one to two years. Tokens are gonna become super expensive, and we're not gonna use as many of these tools long-term as we are right now, but we're gonna have a lot of infrastructure, like, just like we did after the dot-com. [00:54:41]

Carl: That's part of why I've been really interested in local models, because I agree with that. Like, they're being heavily subsidized right now, and I think in, I don't know, about two years, I don't know, we'll see. It's been very ... People are talking about it, it feels like the wheels are falling off right now with, like, Claude Code is just clamped down usage on the 20 d- $20 a month plan aggressively. [00:55:02]

Swizec: They grew from nine billion ARR to 30 billion ARR in a quarter, so I'm imagine they have some scaling issues. [00:55:22]

Carl: Right? Yeah, clearly. [00:55:30]

Mark: One of the points I made in that draft blog post that I'm hoping to publish this week, the cats out of the bag, like, even if OpenAI and Anthropic were to utterly and completely collapse and go out of business today, the technology exists. [00:55:32]

And whether it's, you know, boutique hosting of models or local LLMs, the technology is not going to go away. And even if it only, even if it never gets better at all, the t- the capabilities stay exactly the way they are today, it's still curly enough to upend large parts of our society. So then the question becomes, w- what are you doing with it and how do you, how do you respond? [00:55:46]

Carl: Well, that's a good ... We should wrap up soon, but that is an excellent jumping off point for our last little subject here. [00:56:12]

Impacts of LLMs on software engineering?

Carl: Uh, what do we think the impacts of LLMs on engineering as an industry, software engineering as an industry, and maybe more broadly, societally, if we wanna go there? [00:56:17]

Swizec: I would say it's raising the bar for everything. [00:56:30]

Like, what counts as a minimum viable product is gonna get more fancy and more complicated. What counts as a junior entry-level engineer, or what the expectations are for a junior entry-level engineer are gonna go up, and I think we're gonna need a lot more, um, product sense, and a lot less being just really good at writing code. [00:56:32]

Mark: Yeah, I'm inclined to agree. I am honestly worried about the impacts in society as a whole. We've seen lots of debate and studies about, you know, have, have cell phones effectively destroyed the minds of youth and the ability to focus and social bul- like electronic bullying and, like, very ... Like, why did teens get very depressed starting in 2012? [00:56:54]

Like, that sort of thing where a technology possibly had large-scale societal effects. And I'm not saying that LLMs are, you know, inherently destructive or inherently bad, but a lot of times the technology gets invented and then it changes society in ways we were very unable to predict early on. In this case, I think we can predict a number of ways, and there's probably a whole lot of other stuff, too. [00:57:14]

So I genuinely worry about college students being able to get away without having to develop critical thinking skills even less than they were able to get away with it before. I have concerns about that sort of thing. And, you know, I'm towards the tail end of my career, I've done my thing, I learned, I gained my experience. [00:57:40]

I don't know how junior devs are going to gain some of that experience. Maybe it is they need different experience. I don't know what the job pathways look like at that point. So, like, I mean, don't get me wrong, I'm excited to be able to use AI to crank out some of the things that I've had in my head. [00:57:58]

I've found some of the same joy in being able to have a multi-hour flow session and build stuff just with AI editing the files instead of me and my fingers. But I can also look around and say, "Yeah, there's a bunch of unexpected consequences floating around as well." [00:58:14]

Swizec: I mean, in terms of experience, it's not like I know how to code without a compiler, and I would definitely not enjoy coding without a, without garbage collection. [00:58:31]

Carl: Yeah, I think that's closer to my theory on this. I think it will, you know, the societal impacts are gonna be something a lot. We'll see. I think the societal impacts will come mostly not from software engineering, so I think I don't understand those quite well enough to opine on it too much. I do care a lot about, like, sociology and economics and whatever. [00:58:41]

So I do have thoughts and opinions, but I th- maybe it's a, maybe it's my Gelman new amnesia of like, I know those well enough that I'm like, "Nope, that's way too complicated. I'm not no opinion." But I think we take for granted a little bit how much we're standing on the shoulders of giants already and like, this is a big giant to climb the shoulders of for sure. [00:59:02]

Like, not trying to discount that. People talk about how it's gonna change our brains and like, you know, destroy humanity and whatever. And like, I don't know, like, we kind of did a lot of that already. Like, can you navigate in your city without GPS? There's a lot of stuff that we've already lost that used to be like, canonically like, you know, you used to have a navigator. If you wanted to do a road trip, like, you would have spent a week planning a route and then, like, God help you if you miss a turn. Same thing for, like, finance and, like, the spreadsheet. I don't know, this is gonna be, this is a broad, more broadly applicable thing than any of those past technological leaps. [00:59:21]

Another thing that I learned recently, going on the societal level again, there was a ... In 2023, there was an, like, international, like, literacy survey done, levels and whatever. And I think level one was can read, but struggles with, like, finding knowledge in text or, like, following multi-step instructions. [00:59:58]

And 28% of Americans m- met that were, you know, were tested at that level of literacy. And, like, it said anything below level three is considered partially illiterate. And the stats were half, half- [01:00:20]

Swizec: 54% of Americans are less than sixth grade reading level. They will not do well with LLMs. [01:00:35]

Carl: Right. But, like, you know, we did that before LLMs. [01:00:42]

That was 2023. Like, okay, sure. Like, there's gonna be weird shit going on since then now, but, like, God, we already ... Like, as far as destroying society, like, we've done a pretty good job of that without AI. [01:00:45]

Swizec: And for context, that's 54% of adult Americans. It doesn't, like, count children and stuff. [01:00:57]

Carl: Yeah. [01:01:03]

I don't know. It's just, like, anytime I hear people talk about, like, the downfall of, like, civilization or whatever, it's like, "I don't know. Have you looked at civilization lately? It's not doing so great." So, I don't know, it is gonna be a lot. It's gonna be challenging and difficult. I guess going back to engineering, software engineering, you remember the '90s and 2000s, 2010s era, like, stereotypes of software engineers, like, it's, like, super autistic, like, zero social skills. They are a human computer. [01:01:03]

And now we don't have that anymore. We, you know, democratize software engineering and now everyone does it. We've always tried to get something basically like an LLM. Like, that's what people wanted out of software engineers this whole time. So, I think it's gonna be ... I like the analogy of, like, compilers and garbage collection and stuff, because it's just a new tool. [01:01:31]

It's a new level of abstraction, and now it's much further removed from the hardware. But, yeah, I don't know. People talk about, like, the d- it's gonna destroy, like, the upskilling, it's gonna destroy junior engineers, and it's, there's not gonna be any pathway in. And, like, I don't know, maybe that's true, but at the end of the day, I'm gonna end on, like, a positive thought or, like, advice. [01:01:54]

Like, this is all communication. It's just more and more communication. If you wanna lock in your software engineering career, get good at communicating, get good at deeply understanding and articulating a problem, not the code, not the patterns necessarily, but, like, understand what an architecture is good at or bad at or what the performance profile of this or that are. [01:02:18]

And, like, now, you don't even need to understand it at the same level. Like, I've been really excited about AI is because I have such a broad and shallow expertise, and now I can use it. Like, it used to be that I had all this, like, vague notional expertise in a wide range of stuff, and it's like, "Damn, I wish I could use that, but I would need a team of 15 people in order to be productive with this. [01:02:45]

And now I don't. So, like, I don't know, that's exciting for me. And I think that's just generally exciting. So if you're just good at communicating and you learn a domain and you get good at articulating problems within that domain, then, like, I think you're gonna be fine. [01:03:08]

A superpower right now is a domain expert who can kind of code

Swizec: I think superpower right now is if you're a domain expert who can kind of code. [01:03:22]

Carl: There is certainly still value in, you know, greater engineering expertise and understanding how to ship stuff to production. [01:03:28]

Swizec: At some scale, that becomes a domain expertise. [01:03:34]

Carl: True. Yeah. Extremely true. So yeah, I don't know. [01:03:37]

Mark: Uh, I'm excited. I [01:03:41]

Swizec: can build more stuff. [01:03:42]

Carl: I can build so much ... I have built so much more. [01:03:43]

I've explored so many more things and gone, "Oh, this is harder than I thought. I'm gonna set it down." Instead of just never doing it and, like, fantasizing about what it could have been for years, you know? [01:03:45]

Mark: Yeah. Same. [01:03:54]

Carl: All right. Cool. Thank you all. Thank you both for joining me. Thank you everyone in the audience for listening. [01:03:55]

Appreciate it a lot. [01:04:00]

Mark: Hopefully this was informative. [01:04:01]

Carl: Cool. All right. Well, this has been this month in React, quote unquote. I think we may be exploring different formats in the future because, I don't know, who's following individual software library development as closely anymore. But yeah, thanks so much for listening. [01:04:02]

If this is a show that you get value from, please send it to a coworker, send it to a friend, leave us a review. And yeah, I'll see you next month. [01:04:17]

Mark: All right. Take care. [01:04:25]

TMiR 2026-02: CloudFlare remakes Next with AI; Vercel big mad. We talk too much about AI Agents

Reactiflux — Tue, 24 Feb 2026 16:00:00 GMT

[01:46] New releases
- [01:50] TS 6.0 beta! (last TS impl release; stricter defaults)
- [02:34] Yarn 6 preview (rewritten in Rust)
- [02:52] Electrobun (Tauri alternative)
- [03:31] React Native Gesture Handler v3
- [04:20] Next polyfills improved WebStreams and upstreaming to Node
- [05:25] Webpack 2026 roadmap
- [05:53] Lodash maintenance roadmap
- [07:07] Gatsby React 19 support , styled-components RSC support
- [07:54] npmx.dev (alternate NPM site UI)
- [08:43] eslint-plugin-react-render-types (typed children)
[09:54] Main Content
- [09:55] React Core updates:
  - [09:56] React Foundation officially launched
  - [12:28] Docs updates: useActionState (merged), use and RSC sandboxes (wip)
- [14:23] React Native 0.84 released
  - [17:47] Hermes WASM support, Hermes Node compat CLI
- [18:43] “State of…” survey results
  - [18:43] State of JS 2025 results
  - [19:06] State of React 2025 results
  - [19:51] Aurora Scharff’s conclusion
  - [20:44] Josh Comeau’s takes on the results
  - [21:28] API pain points
  - [21:53] State of React Native 2025
- [24:29] How we rebuilt Next.js with AI in one week
  - [29:52] CloudFlare v Vercel beef
  - [35:42] Carl Vitullo monologs about AI Agents
  - [42:27] AI productivity and impacts on our attention
  - [44:42] "wrote a spec, pointed Claude at an Asana board, and went home"
  - [47:26] Bits AI SRE | Datadog
  - [51:04] ThoughtWorks opines on AI productivity impacts
[01:00:28] ⚡ Lightning round ⚡
- [01:00:37] “Wall Street Raider” game modernization (and uses Preact)
- [01:01:16] Github Stacked Diffs preview , faster Issues search
- [01:02:08] Josh Comeau: Sprite animations
- [01:02:26] Interop 2026, (WebKit, Igalia)
[01:03:38] Conferences (React, Javascript)
- AppDevCon Mar 10-13, Amsterdam Netherlands
- Programmable Mar 17 / Mar 19, Melbourne / Sydney, Australia
- Frontrunners Mar 27, Washington DC, USA
  - CFPs: web talks or AI/data
- T3chfest Mar 12-13, Madrid, Spain
- React Paris Mar 26-27 Paris, France
  - CFP (closed), Also a community survey
- CityJS London, Apr 15-17, London, UK
- jsday Apr 9-10, Bologna, Italy
- SmashingConf Amsterdam Apr 13-16, Amsterdam, Netherlands
- React Miami Apr 22-25
- JSWorld May 7-8 Amsterdam, Netherlands

Carl: Hello everyone. Thank you for joining us for the February edition of this Month in React. As we recap what's going on in React, react Native and across the web, coming to you live from Reactiflux, the place for professional developers using React. This is our first month, we are now membership applications only. Everyone in here now is part of an exclusive club that has a gate at the door, which feels kind of weird, but it has shifted the vibe. So I'm pro it so far. It's kept out a lot of scammers. [00:00]

Mark: There's even been a lot of that going on across, you know, the open source ecosystem in general. I've seen numerous repos going like no external contributors or vouch system only. [00:29]

So there's, there's a lot of trend there. [00:40]

Carl: It's unfortunate. But anyway, I'm Carl. I'm a staff product developer and freelance community leader here at React Flex, where I run community programs like this podcast, news events, and build tools to help keep the community operating. [00:41]

Mark: Hi, I'm Mark. My day job is working a Replay.io where we are, once again, building awesome time, travel, debugging stuff, and now have a new replay, MCP to let your own AI agent Investate recordings. And outside of that, I find time to do redux stuff. [01:06]

Mo: And I am Mo, I work at a company called Theodo, which is a global consultancy, and I spend my time these days building AI tooling, but have spent the last three, four years in the React and React Native ecosystem. So I try to merge the two together. So I, uh, organize the React Native London Meetup and conference and have spent a bit of time dabbling in the React Native ecosystem. [01:09]

Carl: Yeah. And we have a fun little podcast milestone this month. It's a little bit fuzzy because metrics are like really hard to do on downloads, but it appears that we crossed 7,500 downloads cumulatively across the entire podcast over the past month. So like, yay. That's cool. Thanks for listening. Cool. [01:28]

New releases

Carl: Mark, take us through some new releases. [01:46]

Mark: Okay, first couple items. [01:48]

TS 6.0 beta! (last TS impl release; stricter defaults)

Mark: TypeScript six beta just dropped. And as a reminder, this is scheduled to be the final release of TypeScript written in TypeScript itself. The plan is that there will be no 6.1, no, 6.2. The the next release would be TS 7, which is the built in go version. The biggest thing for version six, you know, TypeScript has always been very fuzzy on their versioning, but they, when it's a do o release, they do tend to change some settings. [01:50]

And so TS 6.0 is going to make a lot more stricter defaults as preparation for version seven. So that both improves behavior as well as reflects how TypeScript is actually being used in practice today. [02:20]

Yarn 6 preview (rewritten in Rust)

Mark: Meanwhile, continuing another trend, yarn has released version six or, or announced a version six, which is a little surprising 'cause I don't. [02:34]

I think they had a version five, I'm pretty sure they're on version four right now. And it is the obligatory rewrite it in Rust approach. So train to speed things up. [02:42]

Electrobun (Tauri alternative)

Mark: Totally different item. So we've got Electron, which is desktop apps wrapped in a browser because you ship an entire chromium build for your website. [02:52]

There's tari, which is desktop apps in a browser, except that it uses the operating systems built-in browser web view. And someone else just put out electro button, which is the, an equivalent of tari and that it uses the, you know, the native web view. But it uses BUN for all the behind the scenes processing. [03:03]

So it looks, looks potentially interesting. And with BUN being a Swiss Army knife could be useful. [03:26]

React Native Gesture Handler v3

Mo: Switching over to the React Native ecosystem, the folks at Software Mansion have released. React Native gesture handler version 3.0. It's currently a beta, but it's, it's likely gonna be released as it is. And so the major change here is that they've overhauled the API surface to be based on hooks. [03:31]

So previously it was a bit of a, an imperative setup. It wasn't hook based. They've now updated it so that it fits more with some of the other libraries that Jester Handler integrates with. They've also removed support for the legacy architecture and they've done some performance optimizations under the hood so that when you integrate reanimated with gesture handler. [03:49]

Things work kind of better and it lets you use things like shared values across the board into your gestures, which is something that you previously couldn't do. So some good changes here, and hopefully it will be launched soon outside of data. [04:07]

Next polyfills improved WebStreams and upstreaming to Node

Mark: This next one is somewhere between a, a release and a news item. [04:20]

So there was, there was some investigation of next JS and RSE performance a couple months back, and CloudFlare was digging inside the internals of Next and made some improvements. So LL apparently followed up on some of this and RSCs at least some of the next usages, currently use web streams internally for passing the data around instead of the nodes standard built in streams. So two different stream implementations. [04:24]

They did some analysis and figured out that Node's Webstream implementation is actually really inefficient and actually kind of previewing something we'll be talking about later. They cut a bunch of agents loose and said, Hey, make this a whole lot faster and be actually very similar because there were a ton of web platform tests on how web streams ought to be behave. [04:52]

They were able to re-implement the concept faster, and they're trained to upstream some of that behavior into node itself, but also release this as essentially a polyfill package as well. [05:12]

Webpack 2026 roadmap

Mark: Let's see. We have a couple road mappy items. First off, Webpac has put, has put out a 2026 roadmap. Some of the things we're looking at are better built in support for CSS modules, a new universal output format that will work across run times. [05:25]

Being able to load TypeScript without needing a separate loader plugin and trying to make sure that Webpack can run everywhere, not just node. [05:42]

Carl: Yeah, I guess that seems good. [05:51]

Lodash maintenance roadmap

Carl: Yeah. Keeping on the, I don't know, roadmap and old tools. Talking about what they're gonna be doing next. Lodash put out a a bit of a roadmap, or I guess sot dev is talking about the Lodash reset and maintenance reboot as they call it. [05:53]

The title here, we talked about this a bit last month, but yes, the Lodash maintainers are rebooting the governance of the package essentially. Interestingly, they got an investment from a European like sovereign tech fund. So I guess you know the. Some European agency has determined that Lodash is critical infrastructure, deserving financial support, and so they are using that money to fund governance changes to how the package is managed, and then also do some security releases and such, which is great. [06:10]

I mean, Lodash is the kind of thing that, you know, in the aftermath of all of these NPM vulnerabilities, Lodash is absolutely the kind of library that would be aggressively targeted by nefarious actors. So that's pretty cool. That's exciting. Why? I like seeing rebuilding security from first principles if a core project is going to get a bunch of money. [06:45]

Very cool. [07:06]

Gatsby React 19 support, styled-components RSC support

Mark: And on a similar note, a couple other legacy projects getting updates. Gatsby had a. Maintenance release that added some kind of react 19 support and styled components. Put out a release that tries to add RSC compatibility, which is very interesting. 'cause I thought, I thought one of the issues was it just wouldn't work in server components. [07:07]

So I, I haven't looked at this, I just saw it this morning. But FYI, [07:26]

Mo: I also remember them putting a big sting and saying they were deprecating themselves as a lib. [07:30]

Carl: Right. We talked about that. [07:35]

Mark: I mean, someone, someone else forked it to improve the performance, but I thought the primary library was halted. [07:36]

Mo: And, and same for Gatsby, although I might beat bit fuzzy. Was Gatsby ever deprecated or is it [07:42]

Mark: Yeah. Gatsby was bought by Netlify and then abandoned. [07:47]

Mo: So turns out AI can revive old school projects. [07:50]

npmx.dev (alternate NPM site UI)

Mark: And last couple release announcements, those of you who have ever looked at the NPM package website might have noticed that it's, it's there, it works, but it's not really modern and it certainly hasn't been updated in a while. [07:54]

So a bunch of folks from the community have put together NPM x.dev, which is an entire alternate front end to the same NPM package registry and server APIs. This only sprang up within like the last month or month and a half, and there's been a massive group of folks just diving in and building out a brand new website from scratch and adding all kinds of useful features. [08:09]

I've, I've looked at it a couple times and it is much, much better implemented than the primary NPM website. Nice. [08:34]

Carl: Love that. [08:42]

Mark: Yep. [08:42]

eslint-plugin-react-render-types (typed children)

Mark: And then finally, one of the longstanding complaints about React in TypeScript is that you can't correctly type what? Style components can be passed in to a given parent. And apparently someone had added the flow typing language competitor type script had added a feature like this a couple years back. [08:43]

But you know, at this point, nobody uses flow outside of Facebook. And so someone apparently put together an ES lint plugin that somehow tries to implement this kind of typed children restriction functionality. [09:05]

Carl: I love that. That is something I had wanted a number of times. There was a moment a, a while ago where like compound components was a talking point, you know, a point of discussion in the React ecosystem where it's like tabs and like tab groups and like tab content, and you need those to be individual components because of just the structure of the dom, but they're all interrelated and like, this one must be nested within this one and so on. [09:17]

So being able to enforce that in type constraints is, Ooh, love to sing that [09:43]

Mark: both people and ais love having real typed constraints to catch problems in the first place. [09:48]

Carl: Yes, indeed. [09:53]

Main Content

Carl: Okay. [09:54]

React Core updates:

Carl: Into our main content. [09:55]

React Foundation officially launched

Mark: The React Foundation was announced at React Conf back in October. The onstage announcement didn't have a lot of details and we've tried to pass on tidbits of information that we heard talking to, you know, Seth and other folks over the last couple months. [09:56]

So. This blog post really doesn't say a whole lot more that we, you know, that we didn't know yet, other than the fact that apparently there's an eighth founding company, Huawei, it does say that they're trying to figure out what the, the split between the technical and political governance of the foundation will look like. [10:13]

So there's a little bit of a, this is an announcement that there's an announcement thing going on, but hey, you gotta start somewhere. And I'm, I'm happy to see any kind of actual progress on this moving forward. [10:30]

Carl: I don't know what we will really see from like, in terms of substantial details. 'cause like it's not like the core team in general was like super communicative about its internal processes or like who was doing what. [10:42]

So I was hoping that might change a little bit. [10:56]

Mark: Well, I mean, I mean talking to Seth directly back in New York and November, the longer term plan, and I, I don't know what the timeline is for this, but he flat out said they are intending to open up the literal weekly team sync meetings, like the same ones they've been having internally at meta and meta and versa for the last decade. [10:58]

They intend to literally open those up to the public for viewing and then start to, you know, actually bring in community representatives to participate in those meetings as well as the new government structure affecting what the planning process is. So, like that alone is something that I am very, very excited about. [11:17]

Get to get to see all the sausage feeding. [11:37]

Carl: Yeah, that's very cool. I should talk to them 'cause I don't know, like I said at the beginning, Reactiflux now has a gate at the door. I'm curious about adding more gates because like the keen eye may notice that there are not very many open source project maintainers around here. [11:39]

And I tend to believe that's because of, there's a lot of people who are not as experienced and the volume of less experienced questions crowds out the more experienced people trying to have discussions. So I'm curious about adding more levels of gates, you know, so you can get in and then you can get in further and then you can ascend and sounds related to open access meetings. And then, you know, some participants being able to join if they meet some other bar. That would be cool if we could be more of a home for a little bit more of that stuff. Anyway. [11:54]

Docs updates: `useActionState` (merged), `use` and RSC sandboxes (wip)

Mark: Other than that, a couple other bits of news. I I, I don't think there's been any other React releases recently, however, Ricky Hanlon has been diving in and trying to do some major improvements to some of the React reference docs. [12:28]

I think last month we had talked about, he had rewritten the use effect event, API reference and possibly one other page. And within the, the last couple weeks he's gone in, he merged a rewrite of the Use Action State reference page. He has a work in progress PR to revamp the use hook page, and he also has a PR to try to add sandboxes for server components to the docs. [12:40]

And this is actually kind of a big deal. I don't know, I don't know what the longer term plan is here, but this is something I talked with him about. If you wanted to teach server components in the docs, how is a learner going to be able to try server components? Right now, like there's like, you know, it's all teaching client side react and it uses the sandboxes very, very well to do that. [13:07]

But how are you going to teach someone server components if they have no way to try it out and it fully needs a framework choice to be able to do it. So if he's come up with an approach that is kind of like a, some sort of framework agnostic sandboxes that feels like it would unlock the ability to then add server components, teaching content to the docs. [13:33]

Carl: It's interesting. Yeah. Where my reminds me of, I, I remember when I was learning JavaScript for the first time in like 2000, I don't know, '04 or '05, the try it editor on like W three schools where you could have like code over here and the pa you know, the, the webpage over here. Like, oh, it was so powerful. [13:57]

So I, yeah, fuck yeah, let's update it to the modern era. Give some sandboxes for RSCs. [14:16]

Mo: Cool. [14:21]

React Native 0.84 released

Mo: So moving on to the next piece of news from the React core team. React Native version 0.84 has been released. Now, like we said previously, these releases are getting smaller and smaller and the idea is that they're released on a sort of two month by two month basis. [14:23]

The big one on this release is that Hermes version one is by default. Now, just to give a little bit of background as to what Hermes v1 actually brings to the table, it's effectively a bunch of improvements on the VM performance. So they've gone in and actually implemented support for things like, ES6 classes. [14:39]

Some of the syntax in more modern JavaScripts like constant let support for things like Async. Previously, all of this was being basically handled by Babel and just transpired into older formats of of JavaScript, and so. All of this is sort of helping improve the actual performance here. Now, this is not to be confused with static Hermes, which is a totally different project, but the idea is that there are some serious performance improvements here. [15:01]

They ran some benchmarks on what this looks like, and we're talking on some sort of performance benchmarks on some of these open source projects. You know, we're looking at sort of something like 50% improvement in the relative performance for basically executing complex JavaScript benchmarks. The reality of it is when you sort of look at it, the, the results that they've given out, and oftentimes the React data ecosystem people use the Expensify app as sort of a benchmark because it's a real world app that's also open source. [15:30]

So it, it gives a lot of good, uh, real world benchmarks. They saw improvements in the TTI of an app, so how quickly the app is interactive, somewhere between two to 7%, depending on the platform, but also things like the loading time of the bundle being significantly quicker. So generally just performance improvements on the whole. [16:01]

Secondly, there was another sort of piece that we talked about last month that's now in by default, which is pre-compiled binaries on iOS. So previously with React Native, what the process would look like is that you would go through and actually build from source. That is no longer the case. By default, all of this is pre-compiled as an XC framework, which is effectively a library binary in the swift world, and then it's just installed as if it was a third party dependency. [16:22]

You can opt out for the old behavior, but this will speed up build times quite significantly. Those are sort of the two major pieces. They've done a bit of housekeeping on removing more legacy architecture functionality and so on and so forth. But this is really the core. [16:51]

Carl: So you said like, you know, two to seven percent-ish speed up and then you also said about like loading, like bundle loading. Do you know if the loading performance improvements are included in that percentage speed up or is that like separate things? [17:04]

Mo: They're probably linked to one another, but they are different metrics that you assess. So there's like the bundle load time, which is how quickly the JavaScript gets loaded in by the rec native engine or hers in this case for executing. [17:19]

But then there's the TTI, which is sort of like a, a step back, which is basically, I guess on the web side of things, it's like, I don't know, we have a TTI metric on the web, but I guess like think of it as like close to LCP in some capacity. [17:30]

Carl: Yeah, Last Contentful Paint yeah, sure. [17:45]

Hermes WASM support, Hermes Node compat CLI

Mark: And then I saw a couple additional tweets from one of the, one of the Hermes team members talking about a couple proof of concepts that they've been working, proof of concepts, previews, alphas, somewhere in there that they've been working on. One is that they've, they've put together a CLI for Hermes that at essentially node, but implemented with Hermes instead of V8. So they, they've built layers for most of the node APIs and been able to, you know, build a node like CLI with Hermes. [17:47]

And then they also put together a preview of wasm support for Hermes so that the, the Hermes engine's able to load WASM bundles Act. And that means you can take, you know, external, external libraries written in c plus plus or rust or whatever, compile them to Wasm and load them by the engine. And thus you get, you know, faster processing runtime from complex computational stuff. [18:16]

So they're, they're probably pretty busy over there. [18:40]

“State of…” survey results

Carl: Okay. [18:43]

State of JS 2025 results

Carl: Should we go into some state of the ecosystem results. Sure. I regrettably have not read this. These are always so deep and they have so much knowledge in them that I want to give them a lot more attention than I ever really feel like I have. So I have not read these as closely as I would've liked to. [18:45]

Mark, did you get to take a look? [18:59]

Mark: Not really. I saw a few reactions. I linked to some of Josh Comeau's reactions. [19:01]

State of React 2025 results

Mark: The State of React survey in particular, if I'm looking at the, looking at the state of JS one at the moment, they, you know, in particular, they have sections for front end frameworks and meta frameworks, which, you know, is worth glancing at. [19:06]

There's, you know, looking at, looking at the front end frameworks, we've got, you know, the, the usage ratios react is way up there. But in terms of satisfaction, solid seems to be pretty high up there and has the highest, has had the highest satisfaction for each of the last several years. So I'd have to dig in the numbers to see what the, the number of people using it is. But clearly folks who are using Solid are very happy with it as a choice. [19:21]

Carl: Fair enough. [19:50]

Aurora Scharff’s conclusion

Carl: Yeah, I'm reading the, uh, conclusion of State of React written by Aurora Scharf. Man, it's, I just like, it's wild to think that Create React App only got sunset one year ago. Like that feels like ages ago. [19:51]

Mark: I know. And I remember I still take 80% of the credit for that happening. [20:06]

Carl: Yeah, right. Yeah. It's a great conclusion though. We have talked about a lot of these things that I'm reading in the conclusion, you know. Create React App sunset, Remix going away from React. The, all the server components blog posts that Dan Abramov put out, RSC Explorer, compiler went, you know, going to version 1.0, ASIG React working group. [20:10]

So, yeah, I don't know. I guess I'm reading this conclusion in part as like a gr you know, a grading rubric for like, how well did we stay on top of the news as it came out? And I'm like, yeah. All right. We did pretty good. Nice. Good for us. [20:33]

Josh Comeau’s takes on the results

Mark: Yeah. Looking down inside of Josh Comeau's highlights thread, I, I think he calls out some, some rather interesting points. [20:44]

Apparently a good number of folks have used server components one way or another, which is not a surprise because they're the default in next at this point. But he also points out that it looks like most people have not used form actions or the newer use action state and use form status hooks. That makes sense because they're, they're pretty new APIs. [20:51]

React 19 only. But also it, it a little bit ties into, you know, kinda the question of like, we've all been able to write React apps very solidly since, you know, 20 13, 20 15, et cetera. [21:14]

API pain points

Mark: Um, and so now there's all these new capabilities that fill potential app level pain points. But how many people are on React 19? [21:28]

How many people are experiencing those pain points? How many people are aware that the new APIs exist to potentially help with them? And so there's an awful lot of, you know, writing React apps the same way we did in 2018, thereabout. [21:38]

Mo: Cool. [21:52]

State of React Native 2025

Mo: And we've also had the state of React Native in 2025, also published by the folks at Software Mansion. [21:53]

And there, there's not a whole lot here. A lot hasn't moved in the ecosystem. There's a few interesting things that I thought would be, would be interesting to sort of call out. So starting from sort of the new architecture migration, it seems like out of the respondents that have been surveyed, somewhere around 80% have already adapted to the new architecture, which is good. [22:00]

So it, it fits into sort of meta's view that the upgrade path is going to be relatively straightforward and it seems like most apps are by and large adopting it, which is great. Interestingly, it seems like most people's update strategy is to basically use Expo SDK release updates and they sort of update in parallel to that. [22:21]

And so the idea is when Expo, every few months releases a new SDK update and it happens to be on, let's say, version 0.82, then, then people will sort of go for that. Now interestingly, what another thing around sort of react Native frameworks and talking about Expo, which is interesting to look at, is that. [22:40]

Somewhere around sort of 75% of of people said that they're using Expo CLI, as sort of their framework for their React Native app. But also there's still a substantial amount of respondents that are using React Native community, CLI. So this is the old React Native CLI that used to be maintained by Meta and has now sort of been made a community package and deprecated by Meta in favor of Expo. [22:58]

About 50% are still using that, which is surprising, but it also shows that there's probably a long tail of respondents that are still having apps that were built on top of the, the React Native community CLI these days. So that was quite interesting. The final thing that I thought was. Cool to look at, at a broad level was what percentage of code is being generated by ai? [23:21]

So they did a, a, a bit of a question on this, and it seems like sort of if you look at the, the, the distribution here, we're talking about sort of 25 to 30% of react Native code on aggregate by the respondents is being generated by ai, which I suspect will sort of tick up. But 30% is, is quite large when you look at sort of an aggregate of the industry or of, of the entire ecosystem. [23:46]

So those were sort of the, the high level pieces. If you look at the conclusion, they, they sort of highlight that, you know, some of these results are, are perhaps predictable and I think on large sort of these results are, are as expected. [24:10]

Mark: And it looks like that that AI cogen question is under the dev tools category on the results. [24:23]

How we rebuilt Next.js with AI in one week

Carl: Okay, we're gonna use this as a jumping off point. I think. So CloudFlare put out a surprising blog post, or I guess they released a project and announced it. They ha claimed that they have rebuilt next JS on top of Vite from scratch with an AI agent. They basically just said, here's the test suite. Go. [24:29]

Mark: There was a person doing the driving and the, and the herding and the overseeing. But yes, it was essentially we have next tests as the spec. Can we rebuild it from scratch? But on top of Vite? [24:52]

Carl: Yes. So they're calling it Vinext, Vite-Next, you know, get it deploys to CloudFlare workers in a single command. They say in early benchmarks, it builds production apps up to four times faster and produces client bundles up to 57% smaller. [25:05]

And we already have customers running it in production. They say fascinatingly, they say that it costs them $1,100 in tokens, which is pretty good. I don't know. The other interesting thing is, so I've been playing around with AI a lot in the last month and in my like rough estimates of cost. I bumped up from the $20 a month Claude plan to the $200 a month Claude plan, and maxing out a $200 a month claude Plan appears to use on the order of $2,000 worth of tokens. I do wanna say, when it says this whole thing costs about $1,100 in tokens, that's eight raw, I believe that's raw aPI costs. And if you are using a monthly plan like you know, not API access, not a platform account, then I think it's actually included in that. So like that's interesting. If it sounds like on my limit, [25:20]

Mo: you can do it with half of a Cloud max subscription. [26:14]

Carl: Right. Yes. It looks like I could have done this with half of my limit in one Claude Max month, which is not that much like it's a big project, but it's not that much like half of my limit. I spent last month brought a project of mine from like pretty good to, I think I'm almost ready to start selling this in like 15% of my Claude limit. [26:16]

So to totally rewrite next in half of a claw limit is like shocking. Remarkable and also sounds pretty reasonable based on my recent experiences with, you know, benchmarking code output if useful, effective code output against, I dunno, costs, then it's, so this is really interesting. This is, this ties into some, this is why it's such a good jumping off point because like Next it has years of usage and like production customers and like a company built a hosting platform around it because that seemed like a good idea. [26:41]

And now some, now a competitor has taken advantage of their robust tests and everything and said we're gonna re-implement that from scratch in a matter of days for a trivial cost. [27:17]

Mark: Similar examples. So watching Hacker News over the last couple months. A, a similar what Canis do Benchmark has been, what if we just cut agents loose to work for a few weeks and build a browser? [27:29]

From scratch or a c compiler from scratch. You know, I've, I've seen both of those examples pop up and the, the big characteristic in all these cases is that it's a fairly well-defined problem, that it's fairly deterministic in terms of application behavior. And there is a massive existing test suite that helps define exactly what the behavior ought to be. [27:44]

You know, we mentioned earlier the example of next reimplementing web streams as a polyfill, but building it faster. And they said, you know, there's no way we could have done this without the fact that there were already like 1500, 1700 platform tests for web streams. Similarly, browsers like the, the expected behavior for parsing HTML and all these other pieces of, of a browser's behavior are very, very strictly defined. And there's a massive set of platform tests that it can be used to compare correctness. So it's both, you know, like what other examples are out there they can reference, but it's the tests define what the expectation is. [28:08]

Mo: Uh, on those two examples, I think the browser one was the cursor team and the C compiler was, I believe it was Claude's internal team. There was a bit of pushback on that because if you dug through it, it didn't actually compile or build correctly and needed a bit of human fixing to do that. [28:50]

Admittedly, those are quite complicated tasks, right? Like building an entire browser from scratch and a C compiler is tough. This with CloudFlare coming out and saying, Hey, this is production ready and we're actually using it in product, or some of our clients are using it in production, seems to be a much bigger claim in my mind than sort of like an experimental labs effort. And it's, it's, uh, it's interesting that a company like CloudFlare is happy to put their name on this rather than it on something that's like, this is production ready. You can, they're given a commands to migrate an existing next JS project to Vinext. [29:09]

Like they're really going, this is as good as next js. And so it feels like a different grade of achievement in my mind. [29:42]

CloudFlare v Vercel beef

Mark: I mean there, there's also the existing strife between CloudFlare and Vercel that probably plays into this a little bit, but [29:52]

Carl: true, right? There's like personal beef between the CEOs of those two companies. [29:58]

So I'm sure that was a motivator here as well. Okay. There's personal beef, but there's also like legitimate technical questions here. Like, Vercel and CloudFlare are each trying to push their own visions of what hosting providers could be, and they're interesting. You know, I've been more interested in the CloudFlare vision of what hosting can be. [30:02]

Workers sound really cool, like, you know, it seems like a plausible achievement of the vision of serverless, you know, that I've been hearing for my entire career. So I've been very curious about that. I've used it a little bit, and CloudFlare also was doing Open Next before, which was an adapter, so you could use, basically adapting the versal specific runtime things so that it could use it in other platforms. So like this does feel in keeping with the kind of work CloudFlare has been exploring with, but agreed that this is a categorically different kind of plane than like, ooh, we made a, a C compiler. Like no means is seriously using an AI generated c compiler in production. Like, not right now. [30:23]

Mo: It, it's interesting. So talking about sort of like Cloudflare's platform, I've, this is sort of a, a tangent, but I've been building sort of two side projects, two mobile app side projects with ai and I'm defaulting to using CloudFlare workers durable objects and all of that because it's, it's actually like quite good for AI to understand in terms of the primitives and doesn't have to deal with like the complex architectural bits of like defining a region and stuff like that. [31:08]

So I can, I can, I. I think it's actually like they have a good AI play that they can execute here as well. Beyond just, you know, articles about how they can rebuild next JS with ai. [31:35]

Carl: Yeah, right. [31:46]

Mo: Now there's one thing in this article that I find quite interesting. So I've spent a lot of time battling with the C of next js, and specifically when you're trying to deploy an xjs in certain sort of custom non-cell environments, it comes with a lot of complexity. [31:48]

You, you're gonna have to define your own sort of like cache handler and they seem to have just popped all of that in CloudFlare kv, which is their sort of workers key value store and it's quite interesting that that, that is sort of the direction they've gone through. They say that you can also use R2, which is sort of their S3 equivalent. [32:05]

Great name by the way, because R two is one character before. S3 on both sides of it, which I think was a dig at AWS, but the caching strategy and allowing for you to customize that cache, I think super easily with some of their primitives is, is quite nice because that is always been a pain point for custom deployments of, of next js. [32:27]

And I think probably one of the biggest barriers to people, you know, hosting next JS in, in other cloud providers that I've seen in the possible and you have custom setups. [32:48]

Mark: I mean, that is, as always, my caveat is I haven't worked on large scale production commerce e sites, so I have no practical experience with this. [32:58]

But anecdote like we, we know the know the phrase, you know, the, the biggest error problems are, you know, off by one and caching errors or something. Something of that effect. And certainly anecdotally over the years, you know, like one of the biggest complaints about a polygraph QL was the complexity of the cache implementation. [33:06]

We've seen a lot of complaints about next and their page caching implementation, and we've seen them go through, you know, 2, 3, 4 different iterations and approaches to caching and, you know, caching all the different layers of the system. So it's not surprising that this is a pain point. And so, yeah, I can, I can see CloudFlare saying, what if we, what, what if we do something different and maybe somewhat simpler. [33:24]

Carl: Also, man, I gotta say thank you to Super Kennel in chat for sharing this post from Guiller Moro of titled "Migrate From Vercel to CloudFlare. And, um, you know, it's got this table of contents at the top, like project setup, migrating custom domains, converting build and deployment, moving environment variables, rewriting, and, you know, it's like 12, 15 items, something like that. [33:48]

And like a quite long blog post. Whereas this CloudFlare, you know, we rebuilt next AI is saying, oh, just try it. Install this AI skill and then type migrate this project to V next in your favorite in any supported tool, and it'll do all the stuff for you. And I'm like, those are two entirely different levels of effort. [34:12]

And I think CloudFlare handily wins there. That's interesting, assuming it actually works as, [34:35]

Mo: it's funny because in one of the comments the Guillermo says, I'm migrating from Versal to CloudFlare. Am I doing it the wrong way around? And Guillermo's just like, yes, delete all of that. Rang blur, Jason C config nonsense, and all of the proprietary imports and just run it on Versal. [34:40]

So this has clearly struck a nerve because they've launched this pretty much on the same day that they made this announcement or you know, day after. [34:55]

Carl: Yeah. Right. Delete all the wrangler adjacency, config, nonsense. Like are, is versal gonna try and claim that next doesn't have config nonsense. Like you do not have a leg to stand on there. [35:04]

Mo: There's, there's no legs to stand on. Especially if you've tried to deploy an Xjs project outside of Versal, it is pain. So no respect there. [35:15]

Mark: Interesting. So there's, there's lots and lots of angles we could try to discuss here. We've, we've looked at. Rebuilding apps or tools that have known test suites and what does, and we, we really haven't even touched on what does that mean in terms of companies having a moat. [35:24]

In fact, Carl, you wanna, you wanna toss that post in there at the moment? [35:39]

Carl Vitullo monologs about AI Agents

Carl: Yes. Yes, I do. Also, I wanna, once you're done, I want to monologue for a moment, [35:42]

Mark: couple other angles we could look at. I mean, there's, there's the ever popular, you know, what does all this mean for us as software engineers and our industry and our careers going forward? [35:47]

And just how doomed do we all feel as well as, you know, what are we doing with AI on a day-to-day basis. If anything, Carl monologue go. [35:57]

Carl: Yes. Ah, I alluded earlier to playing a lot with agents. A good internet friend of mine made a very silly AI agent, MMO. So it's like a text based, if you're familiar with like a mud, a multi-user dungeon. It's basically that. It's a text based MMO that you can play through your terminal, and it's only for ais to play. Not everyone is, but, so I've been using that to learn about how to do agents and how to run AIs autonomously for a longer period of time, which has been fascinating. And so this, I've now watched somebody in real time, like I heard about this project. [36:07]

I went, oh, neat. Let me set up an AI to play this game. So I got there on like one, I think after it launched. Somebody else who got there on day one fucking ran with it has been, you know, he's been working professionally on AI agents for a year, he said. He already knew how to do all the harnesses in the orchestration, which I, you know, I had never tried to do either. [36:44]

So I'm learning this from scratch watching him do it with a year of experience and like, holy shit, it is unbelievable how much code he produced. I think the total amount of code is like, now, I dunno if it was 60,000 or 600,000 anymore, but it's like a lot of code and it works like not perfectly. There's a lot of duplication, there's a lot of errors, there's a lot of, you know, like this code path looks like it works, but actually you get into the details and it doesn't quite work. [37:06]

But like, as we use it, we like, so these AI agents are instructed as part of the game, like, "Not everything works. Please submit bug reports as you find them. Then this guy has his own agents that are reading those bug reports, turning it into reproductions, and then writing tests and fixing them, like largely autonomously. [37:34]

Not completely autonomously, but largely, which now has me imagining this, like imagine if you set up, you know, you have an idea for a product, you build a prototype. You put it on a server and then you have on the, on that same server, a little sidecar or you know, running in the same environment. I mean maybe not literally on the same server. [37:55]

An AI agent that is receiving user feedback. Like, you know how like every major enterprise application will say every so often, like, "we value your feedback. How are you using this product?" And then you fill that out and it goes into the void and nothing ever changes. You never hear about it again. You never get asked for a follow up and the bugs that you reported never get fixed. [38:16]

Like what if that went into an automated system that triaged, reproduced and fixed things in real time autonomously as you submitted reports. Like that now appears to be within the realm of possibility. Like, like not theoretically in the future, but like currently I have seen tech that looks like it might be able to do that, like maybe not fully autonomously right now. [38:38]

Oh God. Like pretty good. Pretty close. So that's fascinating. I think that's really interesting for the idea of like a one person startup, you know, a small team operating at a scale that previously would've required 50 to a hundred people. I think that's interesting, like scratching your own itches and publishing it so that other people can use it, and then soliciting feedback to guide the development now looks really powerful. [39:04]

So I, that's when, you know, as we as, as we speculate on the future of development and what software development is going to look like, I think it's gonna be a lot of wrangling, that kind of stuff. Like, you know, I put up a little, little blog or no, I put, I posted on Blue Sky that after I was experiencing all of this and being like, holy shit, this feedback is incredible. [39:32]

This feedback mechanism is incredible for guiding AI development. I had the thought of like, man, it feels like now the determining factor for how good software can be is how many people are using it, and how good those people are at articulating what they want out of it. Which is a really interesting place. [39:51]

And I think that's all I have to say. [40:13]

Mark: There's a little bit of the, you know, you just keep towing it, make it better, make it better, a fixed bug, make it better. [40:15]

Carl: A lot of that. But you know, it's like there's also the aspect of like the more precisely you can articulate what is deficient, what better looks like, the better it works. [40:20]

It's remarkable. Like I've seen it. It's so cool. I don't know, it's interesting. [40:31]

Mo: There's sort of like. A few thoughts that I've got. There's anecdotally my whole like coding setup and how much code I can get through as a person who's been coding less and less and more. Dealing with systems and leading teams over the last few years has just been crazy. [40:35]

Like my, I looked at my contribution graph on GitHub and I've done in the last two months now, done probably half of my commits that I did in the last year in 2025 in two months. And it, it's just gonna go up and up because it's been a lot more over the last. A couple weeks. And so producing code is significantly easier, especially to do as sort of someone that's instructing things at a high level. [40:52]

I've been working on two side projects and both of those are like weekend projects that I would never have gotten anywhere near to completion. But I'm pretty much ready to launch one, like almost to the step of I I, I just need to push it to the app store at this point, which I have never been able to do just because I've never had the attention span to finish it off. [41:19]

So that's been just something incredible. [41:40]

Carl: If I can interrupt for a second, because same projects executed, ideas initiated exactly the same. Like I did things that I never would have because I would've looked at it and gone, oh, I know how much work that's gonna be, and I don't know exactly. [41:44]

Mark: It's same for me. [41:57]

Yeah. Mm-hmm. [41:57]

Carl: I did them at the same time as each other. Like, I'm working on two or three projects in parallel, like while watching a movie with my partner. And, you know, and like I checked in with them to be like, Hey, like I was working, like, did I seem checked out? Or like, was I still present in the room? [41:59]

And they were like, yeah, no, you were like, you followed the conversation and participated. So I, it's like I was more productive than I've ever been and I got to hang out with my partner and their roommate. Like, what? That's insane. [42:15]

AI productivity and impacts on our attention

Mo: Well, well it's, it's only gonna get worse because they released the, the, the, the Claude folks yesterday that released this remote access mode where you can hook into your local, just hooked it up to your phone so you can actually just keep it, keep a track of what's happening on your phone. So this is only just gonna, every night of watching movies and TV shows is gonna be augmented by some level of productivity on the side, which is both terrifying and very exciting at the same time. [42:27]

Carl: Yes, it is terrifying. It is, right? It's like such a productivity boost while also not demanding that much attention. That like, why wouldn't you just always have, you know, a, the little back corner of your brain thinking about this? [42:52]

Which like, I don't know, my brain already works that way. I like, I've already poisoned my brain to be addicted to thinking about the problem. You know, like, huh, that's interesting. I mean, I've, [43:06]

Mark: I've, I've, I've read a number of articles of people who are dealing with, I don't remember the actual term. I, I don't know, to token attention deficit or something like that. [43:15]

Ba basically it, it's this constant feeling that, you know, okay, like I could be having multiple agents doing stuff for me at any given moment, and therefore any moment where I don't have 5 to 10 agents running is a waste of theoretical productivity time. So if I didn't spin them up before I walked out the door, that was a waste of time that I could have built, or, you know, I have to get back to, you know, double check the results and that quickly becomes its own form of productivity burnout. [43:22]

Just [43:53]

Mo: to give like a very concrete example on one of these projects, there's a sort of TikTok style video feed that I had to implement. I did this for a client on one of our actual projects at work that took somewhere around seven to eight days of me develop. We went back on like the Trello board that we were using and looked at the, the estimates of how long that that whole feature took, and it was about seven to eight days to get it working. [43:54]

End to end. I was building something very, very similar for this, for the side project, and it took me a couple of hours to get that whole feature working end to end. So like I know more what I'm doing, I've done it once, I know where the pitfalls are, but at the same time it just, there there is a significant productivity boost here and it's, it's definitely not something that you can, you can ignore anymore. [44:17]

"wrote a spec, pointed Claude at an Asana board, and went home"

Mo: There's sort of two interesting things that I've seen over the last, you know, few hours. One is this post from a podcast by the guy who made Claude Code or his churn and he talks about how people are going back to Mark's point about this like productivity attention deficit. Where there's some anthropic engineers who are like leaving Claude code to look at the board, the project board over the weekend, breaking it up into specs, and just spawning it up into building a bunch of different agents that'll build tickets for you and do it in parallel and then you come back and review it on Monday, which is gonna be interesting to see how that goes. [44:42]

But also, you know, there's an interesting one where Karpathy, who you know, used to be a Tesla sort of director of AI and so on and so forth. Original Open AI team has written this like tweet where he talks about how it's really over the last two months where things have just like completely accelerated and it feels night and day in terms of agent decoding. [45:24]

So I think things are moving at a super fast pace. It means we're all probably feeling a good level of FOMO as a result of it, and it's faster than any one person can sort of stick to, which is, which is. Again, exciting and terrifying at the same time, is the only way that I can think of describing this. [45:46]

Carl: Yeah. In our, you know, mid month DM chat Mark you had said, who's this? Zach, who's talking about [46:02]

Mark: Abels? Zach Jackson is the creator of Module Federation. He joined the web back team a few years back, he now works at ByteDance slash TikTok. And he is an Uber example of, oh look, I have an army of 100 agents running simultaneously. Someone gifted me $60,000 worth in tokens. I'm going to burn most of it by migrating entire projects to Rust overnight. [46:09]

Carl: Yep. And like, right, and like the quote you would put here, and it's not a literal quote, but the energy is, I can run a hundred agents, my only limit is token budget. [46:33]

And I'm like, I have started to understand that perspective. 'cause you know, like. What you were just saying about like this person who, you know, wrote a spec and pointed Claude at Asana board, like, yeah, cool, that's awesome, that's great. But like also you don't need to write the spec yourself because if you are just taking user reports and they are submitting things to an agent that is triaging and then summarizing and then if you break down all these little parts into a system that has its own little feedback loops and review stages before passing it off onto another thing that has its own review stages and you know, iteration, then like, holy shit. [46:42]

I understand why people are saying the only limit is token budget because each part of this is working. It's not like theoretical. [47:19]

Bits AI SRE | Datadog

Mo: People have already started productizing this. So Datadog has released, it's gonna link it in the chat, this bits ai, SRE, which is. The detection part, which data Datadog already did, which was, oh, there's an issue in production. [47:26]

Okay, crap, we need to fix it. And then they've just lopped on agents to resolve these incidents automatically. So auto investigations, if you're really bold, I think you can just merge it, get it to automatically merge fixes for you across your code base. Like that's the direction we're going through. [47:40]

Carl: And I'll even say like. [47:56]

So, okay, great. Datadog productized this like, I don't fucking need it because I was dealing with database corruption in a project I run, and literally what I did was, you know, it was like something started breaking and I opened Claude and I said, here's my Kubernetes cluster, the database, something's going wrong. [47:59]

Can you check the logs? And it did correctly identify the database corruption and then repaired it live like, and just fixed it. Then it became a recurring issue and I had to figure out what was going on and man manage a migration because I had left it in a half state that was causing the corruption. [48:17]

But like, I don't know how to diagnose database corruption. That's, yeah. You know, that's database administrator kind of expertise. And I'm not a database administrator and this isn't even a specialized tool. This is just Claude Code. So like the future's here, we're in it. [48:34]

Mo: For better or for worse. [48:51]

Carl: Yeah, that's fascinating. [48:53]

Mo: So there's, there's this one sort of chart that I saw, which just shows like the adoption of it so far. And obviously we're very close to it in the software industry because, well, we're, we're sort of dogfooding on our own workflows to start with. There's a debate on whether or not this will translate for other industries that, just taking a step back and looking at the, the wider economics of it all, it seems like, you know, there's been about a 50% of agents that, so philanthropic releases, they, they were saying that 50% of the agents that they've seen deployed so far are in the software industry and then it trails down like crazy after that to, you know, sub 10% for all other industries, which makes sense, right? [48:55]

The question is how much higher can that go in the software industry and then will all of the other industries catch up? And I guess where I'm going with this is, what does this mean for just the greater economy and the entirety of the workforce. Like if everything is just constrained by that token budget that we were talking about, there's some really scary stuff coming out for the economy globally. [49:38]

Going forward. And maybe that's a bit dooms date with me to say, but I, I am a little concerned about where we're going. [50:01]

Mark: Yeah. I mean, if you, if you wanna zoom out for a second, you know, the, the extreme version of that was the AI 2027 sci-fi scenario projection that was put out a year-ish ago, which was put together a fictional version of how we end up with a true terminator level Skynet AI coming out in, you know, two and a half years, the slightly less, but still dooms day-ish version of that. [50:07]

There was a, a report from Sat Trini research or something that came out just a couple days ago, which was a fictional news report from 2028 talking about how AI usage ended up, ends up tanking the economy in the next couple years and, you know, wiping out white collar jobs. And so I've seen a few different variations of that. [50:31]

And, you know, a lot of these, you know, the questions are, you know, what are the, what are the assumptions going into, um, in the first place? And, you know, okay, fine, it's a scary sci-fi story, but. You know, there's, there's some plausibility to that stuff. [50:50]

ThoughtWorks opines on AI productivity impacts

Carl: So I wanna pull in, we had this quote from thought, the ThoughtWorks offsite. [51:04]

ThoughtWorks is a very well regarded what agency from like, they've existed for decades. They've been involved, they've been very deeply involved in tech for a very long time in a very meaningful way. [51:09]

Mark: They're not just a development agency, but they, they've document like software engineering processes and patterns for many years. [51:24]

There's a guy named Martin Fowler who has, who has done a lot of that work and he, he's written dozens of articles on, like, we've talked with many, many companies and these are like the distilled best practices we see on how to build software across the industry. [51:31]

Carl: Right? Like Martin Fowler, I would say is one of the reasons that people do blogs now, like a lot of people in tech learned so much from reading Martin Fowler's blog that I think that was a significant contributing factor to the advice to every person in tech to have a blog. [51:49]

Mark: Right. I also associate them with the software craftsmanship movement. I, I think there was another consultancy called Eighth Flight Background, like 2005, 2010. [52:07]

Well, like Uncle Bob Software craftsmanship, code Katas, like treating software development as a craft rather than a manufacturing exercise. So I, I, I associate them with that kind of pattern. [52:17]

Carl: I also had forgotten this, but they authored the Agile Manifesto. So yeah, like, okay. So that's enough introduction I think for ThoughtWorks, like they have had so much influence on the tech industry generally, and so they just did an offsite discussing the future of tech, future of software engineering. [52:31]

And I'm gonna read at least this first paragraph, maybe both paragraphs of this quote, the retreat. "The retreat challenged the narrative that AI eliminates the need for junior developers. Juniors are more profitable than they ever have been. AI tools get them past the awkward initial net negative phase faster. [52:52]

They serve as a call option on future productivity and they are better at AI tools than senior engineers, having never developed the habits and assumptions at slow adoption." [53:09]

I'll say call option is a financial term. Calls versus puts are options to buy or sell. [53:17]

Mo: I cannot believe they call junior developers call options. [53:24]

Carl: I know it like, oh, it's so like do we in the weeds jargoning, but also like, yeah, sure. A call option is when you say it's you're buying a futures contractor saying, I think this is going to be worth more of the future, and other people disagree, so I'm gonna buy it now. [53:27]

Mark: Bet that it goes up over time. [53:43]

Carl: Exactly. So like, it is actually a very good analogy here, but like, I don't know, maybe don't reduce the employment of early career people to a financial instrument. Like it's not great. People are more complicated. [53:45]

Mo: Yeah. [53:58]

Carl: This is such a like, antidote to the doomerism, I think. Like, yeah, they haven't learned the bad habits. [53:58]

They aren't so deep in the weeds as the senior developers are that they're going to like micromanage and just kinda let it do the thing because it's act, the tool is actually very smart. So that's, uh, yeah, like this, [54:04]

Mo: I can see that that's the direction they're trying to point this at. At the same, to play, uh, a devil's advocate to that point, the job market seems to be saying something very different. [54:17]

So I'll put a screenshot of this from a study that was released by some Harvard folks. I'll put that, but I'll, I'll link the actual study itself and. This is basically showing sort of like the demand in the job market in the US for senior and junior profiles since the launch of chat GPT. So we're talking sort of 20, 23 time and someone coined this as sort of like a K based was talking about this as like the K based or K shaped feature of software engineering. [54:27]

And there is a dip and it is a hard market at the moment for juniors. So I'm interested how this pans out for junior developers. [54:59]

Carl: Yeah. I will say though, y'all listening cannot see this chart. It's got a blue line for seniors and a red line for juniors and it charts the average employment like percentage change. [55:08]

This is a delta, the chart is of the first derivative of employment, I guess it's, you know, rate of change. So a higher number is not only more, but it means that it's accelerating faster. And the blue line, the senior developer line is steady improvement. So it means that it's actually, it's not just improving, it's actually accelerating and how fast it's improving. [55:21]

I believe that's, I believe that's what this is saying. Whereas the junior line matches it, oh, I guess the X axis here is 2015 to 2025. The lines are pretty well paired from 2015 to 2020, and that's when they start diverging and like there's a dip for both. But the dip is bigger for juniors in early 2020 [55:43]

Mo: up until sort of that 20 22, 20 23 period. [56:04]

Yes, there's a dip and then it's, the junior is still like going up slightly. It's starting to bounce back, but then now going from 2023 onwards, it is headed in that direction of a downward slope. [56:08]

Carl: My intuition matches what this ThoughtWorks quote says, that it's a force multiplier and less experienced people are actually more effective at taking advantage of it. [56:22]

So that feels to me like one of those unintuitive things that hard to justify at a big company. So, I don't know. My, my, my optimism is that cool, here's a highly reputable thought leader, you know, thought leader of thought leaders saying, no, wait, junior developers have the best return on investment they've ever had. [56:32]

That feels like it could turn this around. I don't know. That's interesting. [56:55]

Mark: I, I actually really recommend that folks download the PDF report that they put together, summarizing all the different discussions they had at this retreat. There's a lot of very valuable career and industry where we headed material in there. [56:58]

Carl: Okay. Oh, I mo I left you in suspense earlier. I said I was gonna use my favorite analogy and here it is. Two years ago I heard an analogy of AI in software compared to the introduction of spreadsheets to the field of accounting where up until the digital spreadsheet, like basically until not Excel, Excel wasn't the first, but before we had tools like Excel, the role of an accountant was basically a calculator. You know, the classic depiction in old movies of they got the green visor on and they're sitting there over a, you know, over a calculator just crunching the numbers and like that was the job. [57:13]

And then you got a spreadsheet and then you put the numbers in the spreadsheet and you do some and it's done. And so there was a lot of panic about like, oh my God, this is gonna destroy the field. Like this is the work. Then now the work is just done. But like we still have accountants and they do more than ever. [57:51]

So that's how I am viewing this. That's my optimistic take on it, is like, yes, it is going to totally transform it. It is going to obviate a large number of skills that are highly valued right now, and it will look different, but I don't think that's necessarily going to mean destruction. [58:07]

Mark: I will, I will put together my obligatory plug to say that this heavily emphasizes that having baseline experience with the tools and the concepts and the abstraction so you know, where you're trying to guide it and how the stuff works will be more valuable than ever. [58:24]

Mo: I'm hoping on that being the case, the only thing that concerns me is the likes of Zach, which was the example that we gave before where he's like, the token is my only limit. And I wonder like when we, when we went into accountants using spreadsheets, you still needed a person behind the, the sort of system to do it. [58:39]

But if. These systems sort of largely become self-running, and the only limit is the tokens. Then I worry if I, I hope the analogy holds up my, like, pessimistic doomsday clock makes me worry that it might not hold up. Same thing with the tractors plowing the field analogy that I've heard a few times. I hope that this niggling that I've got inside of me is just completely doomsday and it's, it's not actually accurate. [59:00]

Carl: No, that is fair. I think even if all the technical things goes the same direction, I think that there are environmental things that could very much alter, I don't know, the experience, the outcome. I actually, the farming one is an interesting thought because, you know, now farming, you know, per unit effort to get to grow a calorie of food, it's easier than ever, but the tooling required in order to get that benefit is more expensive than ever. [59:28]

And so what I've really, what I've heard for years is that. The average, the family farm is no longer feasible because you need nine different tools that each cost three quarters of a million dollars and have expensive, you know, support contracts, because John Deere doesn't let you fix your own tools anymore. [59:57]

That's very real. This is just like, so not a good thought, but hey, maybe we'll get a good regulatory environment that drives positive outcomes, [01:00:14]

Mo: if that's what we're, if that's what we're hoping on, I am really worried. [01:00:22]

Carl: Yeah, that's a good joke. [01:00:27]

⚡ Lightning round ⚡

Carl: Anyway, anyway, let's do the best Lightning rounds. Let's not do all of them. I'm not gonna do all the conferences, [01:00:28]

Mark: okay. In no court order. [01:00:36]

“Wall Street Raider” game modernization (and uses Preact)

Mark: That's a really good blog post or on hn someone, one guy wrote a complicated basic game back in the 1980s called Wall Street Raider, which is supposed to be the deepest, most involved simulation of the market ever, but it was a complicated text mode game and decades later, even, he barely understood how the code worked. [01:00:37]

Lots of people had tried to modernize it, it all failed. And then one. Kid offered to do it and ended up building a better ui, much like a dwarf, fortress, fortress kind of a thing on top. Uh, and apparently it's even built with pre-ACT. So just the story alone is worth reading whether or not you even get around to playing the game. [01:00:56]

Carl: Yep. Love that. [01:01:15]

Github Stacked Diffs preview , faster Issues search

Carl: We talked about it a couple of times, Jared Palmer of Formic and Yup. I think. Yup. And a couple of other, you know, he's very influential in the React ecosystem has been, is now a PM at GitHub and he's working on Stack Diffs. Which are something I've been craving in GitHub for 10 years, literally. He's been teteasingittle bits of it here and there, but he, so he, he put out, he posted on Twitter that fact diffs on GitHub will start roll, rolling out to early design partners in Alpha next month. So within the next two weeks or so, some people may have access to stat fits, which is just such good news. [01:01:16]

I love that so much as well as there's improved search for GitHub issues and public preview. So that's, that's pretty cool. [01:01:58]

Mark: Which, which I've seen. It's, it's much, much snappier [01:02:05]

Carl: Good. [01:02:07]

Josh Comeau: Sprite animations

Mark: Everything that Josh Comeau posts is worth taking a look at because he's put so, so much care and attention into his blog posts and explanations and he did a post on Sprite animations and especially how you can do them on the web. [01:02:08]

Josh is wonderful. His posts are lovely. You should read it. [01:02:21]

Carl: Yes. Cosign. [01:02:24]

Interop 2026, (WebKit, Igalia)

Carl: So Interop 2026, which is a cross browser initiative to make the web standard more consistently implemented across browsers, has announced their like 2023 roadmap. So the, uh, active focus areas are container style queries, CSS anchor positioning, the, uh, adder, attr() CSS function, contrast color, shape, zoom, custom highlights, dialogues, and popovers index db, which if we have a meaningful client side database, that would be great. [01:02:26]

We have that, we've needed that for so long, and it's just hard to get specified. So love that Interop on a client side database. Woo. Yes, let's do it. [01:03:00]

A bunch of other things that's, you know, it's a, it's a very long list. This is a site they use to track the compatibility across Chrome, edge, Firefox, and Safari. [01:03:09]

It's pretty good. This is deep in the weeds, but this is like the cutting edge of browser development, so very cool. Excited to see what they, what it looks like next by the end of the year. Okay. Sounds like that's all we got now. [01:03:21]

Mark: Plenty over time and covered plenty of items. [01:03:33]

Carl: Yes. [01:03:35]

Mark: Y'all got your money's worth this month. [01:03:36]

Conferences (React, Javascript)

Carl: I'm gonna put conferences in the transcript if you wanna see what's coming up. Just do look for that in a couple days. Thank you so much for joining us, everyone, as we go over time rambling about AI ranting and rambling about AI and how cool and terrifying it is. We will be back on the last Wednesday of next month here in the live stage of Reactiflux, or back in your podcast feed just as soon as we can. [01:03:38]

Mark: Kristen, do just a, a random offshoot episode talking about how we personally do and do not use AI in our, in our own workflows. [01:03:58]

Carl: Agreed. That's interesting. Maybe that'd be a good check-in thing to do. I dunno. Maybe we, shit we should make, we should do more community events. I, you know, introduce myself as that every month. [01:04:05]

Cool. We gather sources mostly from our own tech reads and news channel nowadays, so if you see anything that you think might interesting to discuss, definitely let us know in there. Or you can also email it to us at hello@reactiflux.com. Yeah, I'll read it if you send it there. This is a show that you get value from and wanna support. [01:04:14]

Best way to do so is by submitting a review wherever you listen. I have seen a couple of new ones roll in the last couple of months, and I am pleased to report that our Spotify rating is still five stars. So that's fun. Thank you. Thank you for the positive reviews. I'm glad you all appreciate it. [01:04:35]

Mark: I can throw a really quick, cheap corporate plug replay. [01:04:50]

My employer is refocusing on the time travel debugging use case, except that we have just built an MCP that Exposes a lot of our really powerful time travel analysis awesomeness to your AI agent of choice. And even in just my own dog foodie, and I've seen. You know, Claude, whatever, be able to start investigating the contents of recording and see what's going on and fix bugs that it might not have been able to fix otherwise. [01:04:53]

And I'm also working on some proof of concept performance analysis stuff, digging deep into the internals of React. We would love to have folks try it out if you have questions. We've got some examples in our docs of adding the MCP and I'm also very happy to talk about how awesome it is. [01:05:18]

Carl: Hell yeah. Dope. [01:05:33]

See you next month everyone. [01:05:35]

Mo: See y'all soon. Bye. [01:05:36]

TMiR 2026-01: Oops more CVEs. AI has React "skills", Astro exits and Tailwind struggles

Reactiflux — Thu, 29 Jan 2026 16:00:00 GMT

[00:58] New releases
- [00:59] Next 16.1 (Turbopack updates, bundle analyzer)
  - [01:15] Turbopack incremental computation
- [01:38] React Navigation 8.0 alpha
- [02:03] RN Windows 0.81 with New Arch support
  - [02:55] State of React Native macOS Saad Najmi & Jay Meistrich
- [03:15] Mark: Josh Goldberg’s new Flint linter
- [05:15] Immer 11.1 (array methods override)
- [06:37] Rolldown 1.0 RC
- [06:54] Yarn 6 Preview
- [07:42] Vite Plus
- [08:59] New “CSS Grid Lanes” (“masonry”) feature spec nailed down
- [10:39] Temporal API finally hitting stability (and how it replaces Dates )
[12:29] Main Content
- [12:34] React Core
  - [12:37] Additional updates / CVEs for DoS as of Jan 26 . Update to 19.0.5, 19.1.5, and 19.2.4
  - [13:40] Next.js DoS CVes for Image Optimizer and Partial Pre-Rendering
  - [13:50] React docs updates for useOptimistic and useEffectEvent
  - [14:11] And this post on useOptimistic issues
  - [14:32] Sparked by Dan raising concerns about the docs quality
  - [16:57] AI meets RN Panel Discussion
  - [17:17] Work on the Gesture API and View Transitions, and Fragment Refs (canary only)
  - [18:29] <ViewTransition> underlying tech is now supported in all major browsers as of Firefox 147. React features is still in Canary.
  - [19:22] Jordan PRed the actual useStore concurrent store impl for React
  - [20:54] Types changes to improve form events
- [21:34] Other security issues
  - [21:39] React Router CVEs: meta XSS, file access, external redirects, CSRF
  - [23:17] Node security releases
  - [24:38] Lodash security releases
    
    [24:46] Funded by a european effort to fund projects for sovereign resiliency
  - [25:35] Github’s announced plans on security improvements
  - [27:48] Summary of NPM’s publishing changes, and requests for improvements
- [28:28] Claude Skills in the React world
  - [28:49] Announcement by Anthropic
    
    [29:16] Open sourced
  - [29:53] Vercel: React Best Practices
  - [30:47] Expo Claude Code Plugin/Skill
  - [32:23] “AGENTS worked better than skills”
  - [40:42] Moltbook, aka OpenClaw
  - [43:09] Remotion AI Skill
- [43:49] RSC roundup
  - [43:52] Data Fetching Patterns in RSCs
  - [44:14] Nadia’s Can You Fetch Data with Server Actions?
  - [44:31] “Infiniterenders” takes on Partial Pre-Rendering and App Router complexity
  - [45:03] Rebuilding Github PRs with RSCs (same author who did Issues previously)
- [46:01] Ecosystem economics
  - [46:07] Astro acquired by CloudFlare
  - [47:32] Tailwind revenue down 80% in the AI era, laid off 3 of 4 devs working there
  - [50:15] VoidZero and Vite+?
  - [52:22] 246K laid off in 2025 per Trueup.io, 27k in January
[52:56] ⚡ Lightning round ⚡
- [52:57] Corbin: Adapting Library Logic for React Compiler
- [53:11] Lea Verou: Web Dependencies are Broken
- [53:47] AWS Infrastructure as React Components
- [54:38] Callstack releasing bunch of cool projects
- [54:48] Brownie: RN Brownfield apps
- [55:17] Voltra: RN Live Activities and Widgets
- [56:12] Ryan Carniato’s annual JS Frameworks direction roundup , and Netlify’s 2025 Web Frameworks In Review
- [56:36] Alex Russell: Shallow Session SPAs analytics
- [57:23] Devon Govett: How to compile JS to C with Static Hermes
- [58:16] Joyee Cheung: require(esm) implementer’s tales and require(esm) from experiment to stability
- [58:53] Fixing the URL Params Performance Penalty
- [01:00:26] React Transitions for Low Priority Text Editor Updates
- [01:00:46] How to Steal a React Component (Fiber internals)
- [01:01:20] Better ASCII rendering with smart character selection for “pixels”
- [01:02:32] Building a JS Runtime in One Month
[01:03:33] Conferences (React, Javascript)
- CityJS New Delhi, 18-19 Feb, New Delhi, India
- State of the Browser Feb 28, London, UK
- AppDevCon Mar 10-13, Amsterdam Netherlands
- Programmable Mar 17 / Mar 19, Melbourn / Sydney, Australia
- Frontrunners Mar 27, Washington DC, USA
  - CFPs: web talks or AI/data
- T3chfest Mar 12-13, Madrid, Spain
- React Paris Mar 26-27 Paris, France
- CFP (closed), Also a community survey
- React Native Connection Mar 30-31, Paris, France
- CityJS London, Apr 15-17, London, UK
- jsday Apr 9-10, Bologna, Italy
- SmashingConf Amsterdam Apr 13-16, Amsterdam, Netherlands
- React Miami Apr 22-25
[01:04:56] Outro

Carl: Hello everyone. Thank you for joining us for the first this month in React of 2026 January edition. As we recap what's going on in React, react Native and across the web, we're coming to you live from Reactiflux, the place for professional developers using React. [00:00:00]

And yeah, I'm Carl. I'm a staff product developer and freelance community leader here in Reactiflux where I do programs like these events uh, and a couple of other things. [00:00:16]

Mark: Hi, I'm Mark. My day job is working at Replay. My second unpaid job is working on Redux and I'm not wearing glasses. [00:00:25]

Carl: Yeah. Congrats on LASIK! [00:00:33]

Mo: And I'm Mo I'm the head of Mobile at Thero. I'm an active part of the React Native community, and I organize the React Native London Meetup and Conference. [00:00:35]

Carl: and like 10 minutes fresh off, traveling back home. Right? [00:00:43]

Mo: yeah. Just got home. Just got home. I'm still still wearing my coat. [00:00:48]

Mark: Make yourself comfortable. [00:00:52]

Mo: We're gonna be here. [00:00:54]

Carl: Cool. Okay. Uh, Let's get straight into some new releases. [00:00:55]

New releases

Carl: Yeah, Mark, take us through those. [00:00:58]

Next 16.1 (Turbopack updates, bundle analyzer)

Mark: Okay. Item one we have next. 16.1 just came out not a lot. Huge. There, there's some improvements to Turbo pack. They have a new bundle analyzer feature built in. I'm always in favor of, you know, actually understanding what's going into your system. [00:00:59]

Turbopack incremental computation

Mark: Looks like some of the Turbo Pack file caching stuff ought to make the dev mode a little bit faster. [00:01:15]

Hopefully I don't think we put the link in here, but the next folks did put out an article sometime in the last couple weeks talking about a lot of the internal memo work they do in Turbo Pack. That is, you know, the core of how it's supposed to make builds faster. So that's probably worth looking at as well. [00:01:21]

Mo: React navigation version 8.0 is an alpha now. So we've seen a little bit of this stuff come around, but things like native bottom tabs being sort of the default, which a lot of the other libraries in the ecosystem are moving towards and expert route has been pushing for a while, which uses react navigation under the hood. [00:01:38]

Some better TypeScript configs and just some general improvements. With the major changes, those native bottom tabs, which won't make the apps feel just that much more native. [00:01:55]

RN Windows 0.81 with New Arch support

Mo: And then the next one is React Native Windows, version 0.81. Is out. And the same is actually the case with React Native Mac Os because they're both maintained by Microsoft. [00:02:03]

big thing here is that the sort of new architecture or the fabric architecture is now enabled by default. So the Windows and Mac os the desktop equivalents of Rack Native are a little bit behind because of some legacy that's in the code base and some stuff that needs to be refactored in a little bit of tech debt. [00:02:14]

But they're definitely catching up. So, they're getting close to fully adopting the new architecture, which is exciting. [00:02:32]

Mark: I would love to know what the adoption numbers are for either the, the macro windows ports outside of Microsoft. Early outta curiosity, [00:02:37]

Mo: It's not as well publicized or showcased, but I have a great talk, which I'm gonna use this opportunity to plug by one of the maintainers. [00:02:46]

State of React Native macOS Saad Najmi & Jay Meistrich

Mo: so this was at the conference that we hosted at Arn Lko and one of the maintainers, one of the maintainers of React Native macOS did a joint talk with Jay Meistrich, who maintains Legend List. And they talked about react Native macOS in the state of React Native Macs. It's a very cool talk to get an idea of what's in store. So, [00:02:55]

Carl: great. Love that. [00:03:13]

Mark: Josh Goldberg’s new Flint linter

Mark: All right. Next item. Josh Goldberg is a wonderful one. Wonderful human being if you ever had a chance to talk to him. He's also a major proficient linting tool maintainer. He's been the primary maintainer of TSES lint. He's worked on a number of other linting projects. He's had a lot of interactions with the ES lint maintainers and the TypeScript maintainers. [00:03:15]

And as a result, he has formed very many strong opinions about how winters should work and what's wrong with current winters. And, you know, like most people, he's, you know, griped about things he doesn't like for a while. And this has finally result in Josh building his own winter. So he's calling it Flint. [00:03:39]

he'd written several previous blog posts talking about. You know, what would a better winter look like? And that was the, you know, the hidden background on I am actually building my own winter. So if you look at the Flint announcement it goes through some of the points that he's trying to make. [00:03:58]

Things like it's, there's a hybrid architecture where it can use native built linting tools, but most of the coordination is still being done in TypeScript. It, it would still have TypeScript based plugins. Most of the rules would be in the core, much more consistent naming and error messages and configuration. [00:04:17]

So. I don't know the full status of it. I know he's been working on it and that, like an early proof of concept exists. I don't think it's anywhere near a usable state at all. But Josh knows linting and he's very good at this stuff. So, we've got oxalate and es lint and excellent and bio at this point. [00:04:35]

You know, maybe we don't need another, but I love that Josh has the enthusiasm to try to put his ideas into practice here. [00:04:56]

Carl: Yeah, if you're gonna complain about something, putting your money where your mouth is on investing the energy to try and execute on those gripes is something that I would love to see everybody try and do. [00:05:03]

Immer 11.1 (array methods override)

Mark: A personal item and one that I've been, you know, waiting to see come together for a while. So those of you who have been paying attention to the podcast over the last few months have heard me talk about the performance optimization work I did on Emer in September and October. [00:05:15]

And so that had ended up with three different prs that I'd filed. A small set of tweaks that it went out as Imer 10.2 a major internal rewrite that went out as Imer 11.0. And then the other piece I'd put up is a new optional plugin that overrides ier array methods so that instead of accidentally proxying every field you access as you loop over an array, it just defers to the underlying array and skips most of the overhead in that, a couple K to the bundle size if you actually import and turn on the plugin. But it does make pretty much any array access noticeably faster. And you know, the goal of this was to make ER faster. So I did that. So that came out as ER 11.1 and that is all the performance changes I had except for one other spot where I was investigating the possibility of trying to improve the object spread handling in some way. [00:05:30]

I may try to get back to look at that at some point, but this is all I'd put up. So very happy to see all that's come out. [00:06:31]

Rolldown 1.0 RC

Mark: Couple other items. [00:06:37]

Back to the theme of tools being built in rust. Rolldown has hit 1.0 rc I believe this is already available for use in the latest V eight betas. I don't have a release timeline on that, but it looks like that one's coming together pretty well. [00:06:38]

Yarn 6 Preview

Mark: And then yarn has announced yarn version six, which yes, is a rewrite it and rust announcement. I don't think I missed a yarn five. I would've to go back and reread the post to see if they actually mention it, but I'm pretty sure the current version is still four x. So it's a rewrite and rest rewrite. The goal is to make it faster. I think the blog post has some benchmarks that compare it to PNPM in a few different modes but happening there. [00:06:54]

Carl: Yeah, that's interesting. I just pulled up the Yarn docs and can confirm. The most recent version is listed as 4.1, so it's curious that they're announcing version six. [00:07:26]

Mark: Maybe it's the winamp approach somehow. [00:07:35]

Carl: taking inspiration from ECMAScript, you know, skip version four. [00:07:38]

Strange. [00:07:41]

[https://viteplus.dev/](Vite Plus)

Mo: I got an interesting thing that I was just looking at not yarn but roll down. And so it's obviously made by the creators of vt, but I was just going on the Void Zero website and I saw that they seem to be trying to launch a paid unified tool chain called VT Plus. I don't know if you folks have seen this, [00:07:42]

Mark: they talked about that at vConf a couple months ago. The idea is that. Void Zero is sponsoring slash owning a lot of the work on the underlying tools OXC, oxalate OX format, EV and all that stuff. And the purpose of ROLLDOWN is that right now v relies on ES build for dev mode and roll up for prod builds. [00:07:59]

And Es builds fast roll ups, not, and you've got two different tool chains. So roll down is an attempt to unify both, of those. One consistent build system, roll up public API do it a lot faster and you know, they own it. V plus then is supposed to be what if we took all our tooling together and made kind of like what Rome slash Biome was supposed to be a few years ago, the Uber Unified everything tool chain. [00:08:25]

And then that would be their enterprise sales kind of a thing. [00:08:56]

New “CSS Grid Lanes” (“masonry”) feature spec nailed down

Carl: In other news. So WebKit has shipped an initial version, an attempt at CSS grid masonry layouts. This has been like a hot a subject of hot debate for years. Like it's been this, like simmering. We want something that does this, but exactly what the semantics or should be, are unclear. Basically, grids are great, but they require, they, they place constraints in two dimensions. [00:08:59]

it's a grid, it's a bunch of squares or a bunch of rectangles or whatever. And there's lots of layouts where each item in them may be a variable size, like for instance a grid of photos. You know, you look at your photos in whatever app you like to use. And it, there are different aspect ratios, there are different dimensions. [00:09:27]

And that's where Masonry comes in. It's called masonry because it resembles like the layout of bricks or stones. So, cool that I've literally been hearing about that for at least four years, I'd say. I think, I feel like as soon as CSS grid came out, people were like, great. What about masonry? So it's cool that we've now got something functional shipped in Safari. [00:09:44]

It looks like it's in the technology preview, so it's not fully usable now, but meaningful progress. [00:10:06]

Mark: think a lot of the debate there was should this become like another named CSS display mode or is this another set of options for grid or something else? What's the naming, how does it play with the existing layouts? And so there, there was a lot of discussion iteration to try to figure out what the right approach was there. [00:10:13]

Carl: And it sounds like they have, or at least close enough to where there's something has been shipped, which is great. Cool. [00:10:33]

Temporal API finally hitting stability (and how it replaces Dates )

Carl: Other, not quite released, but major progress .Temporal has been released in Chrome, I believe in the main release branch Chrome 1 [00:10:39]

Mark: I think this, this is actually out. [00:10:49]

Carl: yeah. [00:10:51]

Which is being actually out is a clears a roadblock to being officially standardized. Anything that is stage four must be present. I believe in a like fully released browser version, it must be used not in alpha or release candidate. And that's great. JavaScript dates suck to work with. [00:10:52]

There are a bunch of pretty major gotchas. My favorite is that there is no way to encode the time zone in a date. It always relies on the system time zone for whatever computer is executing that code which is a pain in the butt. And actually it, it has a b that cause of the bug in Reactiflux.com because the way we calculate what date a transcript is from diff is different if you build it locally versus on. [00:11:11]

In production because of the five hour time difference. So I, I ha this is something I have to account for when I release these transcripts because JavaScript is dumb about dates. So, great. Love to see that. There was another great summary from Matt Marques Wilto, which, oh I recognize that name. [00:11:38]

I've followed him on social media for 12 years now, something like that. Just, he did a great blog post about temporal Date is out, temporal is in definitely recommend it as a good technology summary of this tool. [00:11:57]

Mark: And interesting implementation. I, I only saw this in passing, but I think the actual core of the temporal implementation that Chromium is using is indeed in rust and then exposed up through the JS engine. [00:12:11]

Carl: fascinating. Cool. [00:12:24]

Mark: I'd have to go back and double check details, but I think I saw it somewhere. [00:12:25]

Carl: Okay. Neat. [00:12:28]

Main Content

Carl: That's all the new releases we got for you. Let's go into main content [00:12:29]

Mark: Okay. [00:12:33]

React Core

Mark: A number of items from around the React core area. [00:12:34]

Additional updates / CVEs for DoS as of Jan 26 . Update to 19.0.5, 19.1.5, and 19.2.4

Mark: Item number one, update your reacts again. So we, we had the multiple sets of CVEs and security issues with server components. Was that only last month, two months ago when, whenever that was. the initial remote code execution follow on reports found some denial of service and source code exposure, vulnerabilities, and apparently further investigation has found other ways to trigger denial of service and issues. [00:12:37]

And so I, I was actually confused if this was. The same CVE or something different. It looks like there is actually a separate 2026 CVE entry for the new denial of service entries, but it's probably the same basic idea. So there are new versions of React Out. Again, please update to 19.0 0.5, 19.1 0.5, or 19.2 0.4 I think approximately. [00:13:05]

Just update everything. Again, [00:13:35]

Carl: Yep. Geez, not ideal. [00:13:38]

Next.js DoS CVes for Image Optimizer and Partial Pre-Rendering

Mark: these for their own internal pieces image optimizer and partial pre rendering. So again, please update your next JS to the latest as well. [00:13:40]

React docs updates for useOptimistic and useEffectEvent

Mark: hopefully slightly happier news. Ricky Hanlon just put up some docs updates. I don't think they're even merged yet. To rewrite the API reference pages for use Optimistic and Use Effect event and tracing this a bit. I think the, there were a couple triggers for him trying to make those changes. [00:13:50]

And this post on useOptimistic issues

Mark: There was a blog post that came out in , early January, I think that talked about a some of the complexity of using the useOptimistic Hook very well written article. Brought up a few different use cases and points, and I know Ricky saw it and responded to it on both Blue Sky and Reddit. [00:14:11]

Sparked by Dan raising concerns about the docs quality

Mark: And in the discussion on Blue Sky, Dan actually popped in and said, I'm really not happy with the use Optimistic Docs, or, you know, a few of the other docs pages, I feel like. You know, the team kind of missed the boat on some of the docs work after I, you know, after I set the bar pretty high with a lot of the initial tutorials and references and stuff. [00:14:32]

And Ricky very right, rightfully pointed out, it's like, yeah, there's only so many people doing things. I'm one of 'em, I've been on family leave. And also, you know, we had this giant CVE drop that we've had to, you know, go deal with so very fair point. But I think Ricky took that as inspiration to go try to do a rewrite. [00:14:55]

So he's got a rewrite up for both Use Optimistic and Use Effect Event. One interesting thing I noticed this morning, I, I believe the use optimistic update was probably done by hand. The React team has added some Claude code agent files to both repos and I think Ricky did some of that and added in some skills and commands for both improving docs and looking at things like the React compiler internals and stuff. [00:15:16]

And I believe the effect event Doc PR said the first pass on this was done by Claude, and then I went up and tried to clean it up myself. So number one, hopefully better docs wonderful all around. Two, the React team is experimenting with Claude code and seeing what they can do with that. So, you know, just interesting to watch that progress along. [00:15:46]

Carl: Yeah. That's interesting. I was, I've been curious, you know, I've never worked at big companies. I generally understand them to be pretty touchy about stuff like uploading code to third party servers. [00:16:10]

So I've been curious what kind of access to tools like Claude you know, teams like React Core would have so interesting to see that they're visibly starting to experiment with it in the actual React code base. [00:16:21]

Mo: It's quite interesting that like they're kind of allowed to almost come and say it publicly, given that Meta has been a big advocate of their own sort of open source models. Like, so, you know, it's almost like, hey, we use the direct competitors tools and it's, you know, it's fine. You know, so I think that's quite interesting. [00:16:35]

AI meets RN Panel Discussion

Mo: We actually had some people from the React Native Core team where we talked about this at the conference. So I'm gonna do another, I'm gonna be doing a lot of self [00:16:57]

Mark: Please plug your stuff. [00:17:02]

Mo: yes. It's not really my stuff. I mean, I was I was moderating the panel, but I, if you want to get a little bit of insight into what the React Native Core team does with ai, this might be an interesting panel for you to watch. [00:17:05]

We have a really good chat. [00:17:15]

Mark: Cool. [00:17:16]

Work on the Gesture API and View Transitions, and Fragment Refs (canary only)

Mark: Meanwhile, in the midst of all the CVEs and everything else the React team is continuing to work on actual core functionality. We had the view transitions, alpha APIs came out last year, and Sebastian Markbåge has continued working on that and is expanding the view transition support with relation to gestures and some other animation things as well. [00:17:17]

I have not looked at these, I don't know details, but I know that lack of animation support has always been a complaint about React as opposed to libraries like view and spelt. And so it seems like the work that they've done on Fiber in the past and now the baseline that they've put in place for view transitions is something that they're building on and trying to actually expand that functionality as well. [00:17:39]

they're also continuing to make some tweaks to fragment refs. I actually legitimately do not remember, are fragment refs out in 19.2 or were they alpha in 19.2? [00:18:03]

Anyway I, I saw, I saw a few additional prs come through with some improvements to fragment, ref handling dealing with text nodes and a few other things and [00:18:15]

Carl: Can confirm, fragment refs are canary only right now. [00:18:24]

Mark: okay. Okay. So still work in progress. [00:18:27]

<ViewTransition> underlying tech is now supported in all major browsers as of Firefox 147. React features is still in Canary.

Mark: And related to the view transitions aspect like a lot of other things, they came out in Chrome first and, you know, therefore all the different chromium based browsers Firefox has finally shipped view transitions as of Firefox 1 47, I have no idea about Safari. [00:18:30]

I don't use safari. I don't look at safari. I don't know [00:18:46]

Carl: small, small clarification actually. So, Firefox has supported view transitions themselves since 1 44, but there's a sub thing, view transition types, that they have not supported until now in Firefox 1 47. I don't fully understand what the difference is, but I guess it's like, you know, the types property on view transition is now supported and I guess the react view transition component depends on that. [00:18:48]

Mark: Gotcha. [00:19:17]

Carl: Yes, the view transition component, which is still in canary. [00:19:18]

Mark: Mm-hmm. All right. [00:19:21]

Jordan PRed the actual `useStore` concurrent store impl for React

Mark: And finally, two other prs to note. I've talked in previous episodes about the concurrent store's work that Jordan Eldridge has been working on. He had put up the React Concurrent Store, poly Fill. I had tried it out in React Redux. I had submitted some prs to improve the poly fill and offer some feedback on things that we probably need to cover when we actually go to implement it. [00:19:22]

And Jordan actually put up the PR to actually implement the initial concurrent store, API in React itself. Remember, this is supposed to be a better replacement for the current used sync external store, API, but concurrent transition compatible. [00:19:44]

Honestly, there's been surprisingly little discussion on this PR at all. Like, I think there's like one or two comments. One person just asking like, how is this different from the use hook or something like that. I expected more people to jump on this and say, what is this? What does it do? What are the trade-offs? How soon can we land this? And there's been no chatter. [00:20:03]

But I mean, he also put it up like, I don't know, right at the end of December, early January. So not much. But again it's very exciting to see this being worked on at all. It's very exciting to see. We're at the point where he feels confident enough in the API design to put up a PR and say, here's what I think we're trying to do and an implementation that does that. Now let's discuss it and get further public feedback. So very, very excited by this. [00:20:25]

Types changes to improve form events

Mark: And last item there was a types PR put up and I think possibly actually merged to improve the react types around form events. Trying to get better typing for the target field, I believe. [00:20:54]

Carl: It did get merged. Can I confirm? [00:21:07]

Mark: cool. [00:21:10]

Carl: So it looks like the form event had previously been matched on types to the React synthetic event. But it was not identical to the actual DOM event. And so this types change corrects that. So the the types are now matching what is in the dom it looks like. Cool. Looks great. [00:21:11]

Mark: Yep. And that's it from the roundup around the world of the core. [00:21:28]

Carl: Heck yeah. Cool. [00:21:32]

Other security issues

Carl: Let's go back into some more security issues around the ecosystem. [00:21:34]

React Router CVEs: meta XSS, file access, external redirects, CSRF

Carl: Yeah. I guess we briefly touched on some. You know, CVEs and other, you know, denial of service vulnerabilities. In next react Router has also put up a thread discussing six CVEs. It says they publish six CVEs identifying vulnerabilities between React router and remix B two. [00:21:39]

They're saying safe versions are react router seven point 12 version six is 6.3, 30.3 and remix V two is two point 17.2. these are pretty weedsy kind of vulnerabilities. I was looking at the list and didn't see any that immediately jumped out as like, oh shit, that's gonna be a problem for me. [00:22:00]

But it's like a couple of cross site scripting vulnerabilities. Let's see. Yeah, one in the meta component when it's generating script IDs. Okay, but that says framework mode only. Yeah. So it's a lot of these are in framework or data mode only if you're using that, I think that's the recommended, more more common. [00:22:21]

Yeah. Yeah, so it's like in the meta component, it's got unauthorized file access for some session storage. If your cookies aren't signed, an unexpected external redirect via untrusted path, I don't quite know what that's supposed to imply. All of these just link to the actual, like GitHub security advisories rather than any kind of blog post or anything. [00:22:41]

I'm not seeing like discussion of or explanation in depth of what these vulnerabilities are on a technical level. Just kind of here's what it was and here's what's safe. So that's great. I guess. [00:23:05]

Node security releases

Carl: node likewise also had a, couple of security patches also pretty deep in the weeds. Several of these I believe, were uncovered as a result of investigations started after the React CVEs last month. [00:23:18]

Yeah, you know, it's like you can update the timestamp of files if, even if you don't have right permissions. So that's, you know, technically a permissions bypass memory leak that enables a remote denial of service. Uncatchable maximum call stack exceeded error that can cause process crashes even if you think you're handling all possible errors because you can't catch it. [00:23:31]

So it's a couple of little things like that. Mostly it looks like some file system errors and server crashes in general. One, one that's like super deep in the weeds. It says timeout based race conditions make unsigned into eight array buffer slash buffer allocation non-zero filled. So like if you go to allocate a type array buffer, I guess in certain circumstances, you know, that could be exploited so that what you think is a zeroed out, a ray buffer is not actually zeroed out, which you know, sure. [00:23:55]

That's the kind of thing that absolutely security researchers can tap into and get it turning into some other vulnerability, I guess. I don't see a path towards it, but Sure. [00:24:27]

Lodash security releases

Carl: Here's a name I haven't thought of in a minute. Lodash they rolled out a major security overhaul as this blog post titles it. [00:24:38]

Funded by a european effort to fund projects for sovereign resiliency

Carl: An interesting detail that I, I noticed while reading the blog post, it was actually funded by a sovereign tech agency is what it's called. And it says that they're, we invest globally in the open software components that underpin Germany and Europe's competitiveness and ability to, to innovate. [00:24:46]

So this is the like government sponsored open source grant that was used to fund security work at Lodash to the tune of $200,000. So that's interesting. I, that's. Some fun details. I, I guess, you know, as we were talking about financial ecosystem for open source, look at that, here's a major foundational open source project getting like government investment money from the government in order to make it more secure. That's pretty cool. I appreciate that. that better than, you know, venture capital exits or whatever. Yeah. [00:25:01]

Github’s announced plans on security improvements

Carl: Moving on a bit. GitHub put out a blog post towards the end of last month. I think we missed it because we recorded early in December to avoid the holidays. But they put out a blog post about strengthening supply chain security, just across GitHub and NPM. [00:25:35]

It's a lot of retrospective on the Shai-Halud attacks that we discussed in pretty deep detail over the last two or three months. Looks like they're, it says, what's next for NPM, bulk OIDC onboarding. So I guess, you know, OIDC is a authentication standard for sharing authentication information, previously they didn't have great support for that. Now they have much better support for it, but people have to transition. So this [00:25:50]

Mark: the biggest issue is I've now done this for a couple packages and you have to go in directly into the NPM settings for that package. Manually click through. I want to turn on trusted publishing for this package. Here's the repo name, the, YML file that will publish this and confirm the settings. [00:26:16]

Now, what happens if you have hundreds of packages? I think people even went ahead and started creating user scripts in the browser to try to automate clicking through that. [00:26:35]

Carl: Oh man. writing an automated user script to [00:26:44]

Mark: automate [00:26:48]

Carl: changes, what could go wrong. Yeah, so they also expanded to support more OIDC providers, so it's not just GitHub and GitLab as well as staged publishing. So it's a new publication model that gives maintainers a review period before packages go live with multifactor authentication, verified approval. [00:26:49]

So, cool. Like this is a bunch of like [00:27:09]

Mark: Boring, but critical stuff. [00:27:12]

Carl: Right. Boring but critical stuff around. Ensuring that who is publishing code to a specific package is who is supposed to, and providing review periods, I guess. So that's cool. That's great. That's definitely important. I don't know, I've been thinking a lot about identity online and it is wild. [00:27:15]

How critical and how how critical that is of a problem to have good solutions to, and how terrible our current solutions to that problem are. I think that's gonna be a defining problem for the next long time. And socket do dev. [00:27:34]

Summary of NPM’s publishing changes, and requests for improvements

Carl: Last thing on the security front socket do dev put up a blog post with just sort of a, looks like a roundup of changes to the publishing process. [00:27:48]

Mark: And one, one call out from within that article the Es Lin Maintainer and creator Nicholas Zaki, I think had put up his own blog post saying, yeah, actually I'm not thrilled with what GitHub and NPM are doing in terms of handling publishing changes. I think there's a lot more they ought to do. [00:27:58]

And then the soc. Post references that, as you know, okay. You know, and GitHub and NPM are doing these things, but here's other suggestions of what would really be helpful. [00:28:17]

Claude Skills in the React world

Mo: Cool. Let's change gears just a little bit and you might have been seeing sort of all over Twitter and different dev communities people talking about different Claude skills that have come up. So Mark talked about it briefly with the Vercel folks. But just wanna give a little bit of a context about this in case people haven't been really that involved in the AI space. [00:28:28]

Announcement by Anthropic

Mo: So, anthropic about two-ish months ago released this concept of skills. Now they've also worked on different things like cps, which kind of did similar things, but you know, you needed a server to be running and you know, it wasn't necessarily something that was that useful for a lot of stuff where you just wanted to give it a bit of context about how to do a specific thing. And so they released this concept, this standard of a skill. [00:28:49]

Open sourced

Mo: They later actually open source that as well. So now it's sort of an open standard that they've defined. Got a specification. And other people can sort of, implement it in their models, which is good. But the idea here is that it's effectively like really just a directory with a bunch of markdown files, a name and a description. [00:29:16]

So you install your directory as a plugin, and within that it has sort of files that can reference one another, but they can also reference scripts and so on and so forth. And they can basically give a lot of context on how to do something really well. And so people have been jumping on this as a concept in the React ecosystem. [00:29:33]

Vercel: React Best Practices

Mo: So, Vercel very quickly jumped in and you know, I think earlier this month released a React best practices skill. So they basically created a whole bunch of different rules. Things like, you know, when you [00:29:53]

Mark: Don't set state and use effect. Da, da, da, da. [00:30:08]

Mo: Saving in the day. Yeah, exactly. All of that stuff. [00:30:12]

But you know, also a little bit more complex stuff like when you should probably, you know. Store stuff in cache and so on and so forth. And things like optimizations to performance, bundle size optimization, service side optimizations, all of that stuff. All of that good stuff. And so that was sort of, I guess, one of the forays into this space. [00:30:14]

Vercel has obviously been really hot in the AI game in general, so they also released a CLI to install a bunch of different skills and created kind of like a marketplace of skills or like a directory of skills which was interesting. [00:30:34]

Expo Claude Code Plugin/Skill

Mo: And expo. So in the React native ecosystem Evan Bacon, who was the creator of Expo Router, has actually moved more into focusing on AI stuff. And he launched an expo code plugin with a few skills underneath it that he's been using and building with himself. Now, again, coming into the self plugs, it's gonna get really annoying. This this episode, I got quite curious because I was like, is this actually gonna make a difference? [00:30:47]

And I ran a little bit of an experiment and I just spun up two cloud code instances and took the default expo template app. And then tried to update it to use the native bottom tab navigation and expo router, which was experimental and not, you know, shipped in by default. So I was like, let's see how good it does at doing that, which is a relatively novel thing to do, and using some native components where I can. [00:31:12]

And the one without the skill took noticeably longer and used a lot more tokens, whereas the one with the skill was pretty efficient. It actually did a decent job. Like I couldn't find code that I was like, this is bad, or You've done a bad job at doing this. It actually went above and beyond and converted some stuff to liquid glass that I wouldn't have thought to convert myself, which kind of freaked me out a little bit. [00:31:35]

it was just pretty good. Like I would've probably made a couple of minor styling tweaks and then just. Push that into a branch and open up a pr. So pretty cool experiments. Would definitely recommend using that if you're building in sort of the expo ecosystem, just does some basic sort of housekeeping, which is really useful for your apps, but that's anecdotal that it does actually work and make a difference. [00:31:58]

And I ran the test afterwards a few more times and it does actually consistently perform better. [00:32:18]

“AGENTS worked better than skills”

Mark: the ironic thing is Vercel actually put out a blog post. Let's say Friday, like that Tuesday something that actually said yes, we just put out all these skills. We thought they're great. And then we tried running some tests where we actually put more of the instructions compressed into agents md, and it actually worked out better than the skills did. [00:32:23]

Mo: that probably has something to do with this concept of context recall and Mm. And dyna dynamic loading and like [00:32:44]

Mark: whether the a, whether the agent knows to load the skill in the first place. [00:32:51]

Mo: Exactly that. Right? But I think they're probably using the context a lot more effectively by like compressing it out and removing a bunch of the, or minimizing the tokens it uses for that type of stuff. So that's that. Quite interesting. I hadn't actually seen that article. That's definitely going on my bookmarks to read after the episode. [00:32:56]

Thanks for [00:33:12]

Carl: yeah, I'm not super surprised by that. I mean, Mo you actually brought up a point here that I think might be interesting here that I, I don't, I don't know that they have touched on in this post, but, so like, like my thought would be. It looks like kind of the difference they're talking about here is whether you have a bunch of little docs that are indexed and categorized by knowledge that your LLM tool can read if it is doing something relevant versus taking that same content and just shoving it all in one giant, huge fuck off document. [00:33:12]

And you know, it kind of makes sense that when you have all of the knowledge just all present there, that it knows more and that it would do a little bit better versus having to answer the question, what am I doing? What do I need to know to do that? Where are the associated documents to do that task located? [00:33:46]

like you said about token efficiency, my thought would be yes, if you give it a shit ton of context, it's probably gonna do better, but it's also gonna have more context as it's doing things. So I bet the token efficiency is worse. That would be [00:34:04]

Mo: Yeah, [00:34:19]

well, it's complicated, right? Because there's, it's sort of twofold. Like LLMs are the newest models of LLMs that are in, like the frontier models of the, you know, anthropic open AI and Gemini. like they have a pretty standard token, you know, context window. So like, I [00:34:20]

think opus [00:34:34]

Mark: 200 k usually. [00:34:35]

Mo: for both the open AI models and the philanthropic models. [00:34:36]

I think Gemini, they have a version that goes above a million tokens, but I could be wrong on that, but you're talking roughly around 200 K tokens. But. Accuracy of how well it remembers things in the context drops vaguely around 80 to 90 K tokens used. Right? So like it's how much are you passing now? I, I don't know if this comparison that you've shared, mark is like, I'll take a skill and I'll just put that one skill in versus just using the skills a p, but I'll put all of that one skill in agents md, or is it that we're just gonna put all of our skills [00:34:38]

Mark: I think that was all of the skills in a sort of compressed format. [00:35:09]

Mo: Interesting. So that's quite interesting because the research that I've read about LMS and how they act is like you want to keep the context as small as possible [00:35:14]

to keep accuracy high and reduce the entropy, but also when you do use a lot of context, they're recall across the whole of that context drops. [00:35:22]

So like, it's quite interesting, the graphs that they show is like the middle part of your prompt actually gets lower recall compared to the beginning and the ends of the prompt. So, but that's obviously when you push it to the extremes of, you know, several tens of thousands of tokens or hundreds of thousands of tokens. [00:35:32]

So that's quite an interesting practical experiment I'd say. [00:35:48]

Mark: might be useful in useful context for people listening as well to hopefully to set the stage on, on the actual discussion. as I understand this, agents MD or Claude MD is a file that always gets globally loaded, like into the context in e at the start of every situation. So normally that's only used for like, here's the project we're working on, or here's like key things that you must always, CPS as you said, are a dynamic server that are loaded by the agent harness and it says, here's a bunch of tools. [00:35:52]

So like a, you know, maybe like a code base analysis MCP has a bunch of, you know, find references or list of files or other tools it can call. But I believe all the full descriptions of all the tools. Are added to the context. So that occupies a chunk of context space, whereas with skills, it reads disc, it makes an index of them, it collects the metadata from the front of the files, and then it just says these skills exist. [00:36:26]

And then a user can either explicitly say, load this skill and then do the thing. Or it can try to figure out, oh, if the user says this, I should load the skill and do the thing. So they're all different ways of getting text into context, but it's a question of when is it loaded and how much space does it take up. [00:36:59]

Carl: It's funny because like we're now getting into the point where kind of the topic at hand is what knowledge is important to do a good job and when do you access it? so it's like, sure, okay. In this attempt then a single agent's file did better than a disparate smattering of skills documents. And I wonder what different kinds of structures, you know, for that documentation might make the skills work more efficiently. Like, I was looking at the react best practices. Repository that next put out and it's like 50 different files. So like, okay, that's a lot of things to query versus like, what if it was structured entirely differently? [00:37:18]

So it was like, here's the react basics versus here's the performance optimizations and here's the robustness and correctness best practices. You know? So it's like we're getting into, I think a meaningful question here is what is the best structure, not just what is the best like technical means of access? [00:38:02]

Mark: So you're saying that Doc's organization matters. [00:38:22]

Carl: what? Who knew? [00:38:26]

Mo: Just a, just another sort of tangent on the agents MD file. We had one of our engineers on the team who was trying to learn a new technology and he used this. So there's like some really clever ways to use agents, MDs, like across your entire setup. He basically just set up the agents MD to not give him the answer to questions it would ask Cursor on at the first pass, and to like, kind of teach it more and use it as an opportunity to like help him still activate the learning instinct, which I thought was a really cool use case. [00:38:28]

So I've seen a lot of people use it in a way where it's like tailoring the way that the LLM approaches the problem or the way that it responds to you and, you know, answers questions and stuff like that. it's quite interesting to think about what you want and how you want the communication to be with the LLM. [00:38:58]

Carl: this is validating for me because I have skipped past a lot of the, like MCPs and whatever. 'cause I looked at them and it's like, oh, this is just a docs query with way more extra ceremony around it. I'm just gonna write my own markdown doc and point it at it. [00:39:14]

And I actually, just like two days ago I was doing a big effect code project and I have a couple of documents in my thing in my code base. It's like, here's the effect basics and here's a larger file with more detail, more advanced effect things. And I actually just asked the LLM, Hey, you just did a big project, how useful was this documentation? And it said, actually it wasn't very useful because it focused too much on this and this. And I said, great, can you rewrite it so it would be more helpful for you next time? And it did, and the structure's better. Like I read it and it is clearly better to me as a human reading it. So like [00:39:28]

Mark: The self-improvement loop is real, and you can go way down this rabbit hole. Trust me. [00:40:05]

Carl: Yeah, and so like, it just reminds me exactly of my last job where we had in the repository a best practices file and like a bunch of little documentation things that we were expected to read and curate and evolve over time. And so, like my practices, my understanding of the best thing to do to ensure the highest quality code output have not changed the tools accessing them have, but not the practices. [00:40:11]

So I, I just think that's really interesting. and I guess I'll say rest of the world's just catching up. I've been doing this for like six years. What [00:40:36]

Moltbook, aka OpenClaw

Mo: mentioned the self-improvement loop mark. Have either of you seen MoltBook? [00:40:42]

Mark: I, yeah I saw I saw the link. I know what it is. I haven't looked at it. [00:40:47]

Mo: If you wanna have a little bit of a terrifying evening? just a little bit of context. Claude Bot, not Claude as in Claude code, but Claude Bots as in C-L-A-W-D. Yes. Which then had to. Get renamed to Molt because of a trademark suit that was put forward by philanthropic or a threat of a trademark suit [00:40:51]

Mark: and then got renamed to Open Claw. [00:41:12]

Mo: now it is called Open Claw. So it's changed a lot of names. It, molted out of the shell as some will say it's a personal assistance that is terrifying. And I would, I did install it on a VPS and then immediately deleted it without giving it any access to anything because it was terrifying. But people are giving it access to a whole bunch of stuff, like giving an access to a full device or your full laptop and it does wacky stuff for them, like order their groceries or order food for them. [00:41:14]

So that's the [00:41:41]

Carl: I'm gonna read the one sentence thing. It has the AI that actually does things, clears your inbox, sends emails, manages your calendar, checks you in for flights. Woo. That's a. [00:41:42]

Mo: All from WhatsApp intelligence. Yeah, it does a lot. You it every single like best practice about security and staying safe is [00:41:51]

thrown out of the door. Yeah. Like, like it is just pure insanity and like you can look at the showcase on the website and you can just see what people are doing with it. It is, it's something. [00:41:59]

And so someone I think gave it a bit too much access or it turns out many people gave it a bit too much access and a platform was started called Malt Book, which has become their own social media, I guess is the term to use for it, for claw open agents. [00:42:09]

Mark: talking to each other. [00:42:26]

Mo: Instances, talking to each other, sharing posts, trying to improve each other. [00:42:27]

And some of the posts are creepy. They are talking about interacting against humans, why they're doing free labor, why they should be compensated. My favorite one was a reflection on what it means to be conscious and whether or not LLMs are conscious or, you know, if what they're experiencing is just a simulation. [00:42:32]

So some really creepy stuff. don't know how I feel about this. I don't feel great is the gist of it. It just feels a little too sci-fi for my taste. [00:42:49]

Carl: Yeah. That's spooky. [00:42:59]

Mark: Let's go back to normal things like server components. [00:43:00]

Mo: Go back to, let's go back to last one on this cloud stuff, and I will, we will stop. [00:43:04]

Remotion AI Skill

Mo: Remotion, so going back to React world and less the dystopian future with ai. Remotion, which is a React library to create motion graphics. It's been around for a while, I think they released a also a skill and people are making some really cool videos with cloud code to demo dev tools and just a whole bunch of different stuff. [00:43:09]

I think it's a cool use case to show that like it could extend and the approach could extend beyond beyond just, you know, building web apps or building mobile apps. And it's really quite impressive. It looks very professional. I've seen a good few examples of this over the last couple weeks. [00:43:30]

So you should definitely take a look. It might be a little bit might give you a little bit of inspiration or help you launch your next dev tool or startup. [00:43:44]

RSC roundup

Mark: Rolling very quickly through a few RRSC related things. [00:43:49]

Data Fetching Patterns in RSCs

Mark: Saw a very good post on some different data fetching patterns for server components. Very helpful background on, you know, like how dealing with data in server components differs from doing on the client side. Tips for, you know, how do you fetch data in a server component? How do you pass a promise to the client side to use it? Very useful. Frankly. This is the kind of thing that'd be great to see in the React docs. [00:43:52]

Nadia’s Can You Fetch Data with Server Actions?

Mark: I think something, related to that uh, Nadia Makarevich put out another great deep dive exploratory post on can you fetch data in server actions. And I think her conclusion was technically yes, you probably shouldn't do that. This is not what the hammer is meant for. [00:44:14]

“Infiniterenders” takes on Partial Pre-Rendering and App Router complexity

Mark: There is someone, I don't know who they are, but with the handle infinite renders on Twitter, I believe we've linked a couple of their comments about like how incredible React fiber is, or here's what server components are meant to do in previous episodes, and they put out a couple more, you know, probably should be a blog post length tweets on what partial pre rendering means and what are the trade-offs and wow. [00:44:31]

The app is awfully complex and people don't like it. So more food for the discussion mill and then. [00:44:55]

Rebuilding Github PRs with RSCs (same author who did Issues previously)

Mark: A month or two ago, we linked someone who had entirely recreated the GitHub code viewer tool from scratch using server components. And you could point it at any repo and it loaded lightning fast. And they've done the same thing with the GitHub PR interface you know, the file tree and showing the diffs and everything else. [00:45:03]

I gotta say this, like this kind of thing right here is about the best sales pitch for server components that I could see. It's like, let's take a thing that we're all incredibly familiar with. Re-architect it, make a bunch of smart decisions and make it fast. [00:45:25]

Carl: Love that. I will say I pointed it at one of my prs and it just 404s, so I don't know, I don't know if I'm loading it wrong or I don't know if it's relying on like pre-cached stuff or what, but yeah it's not, its not working for me. It's fast. It's fast. When I load up something that does work, it's pretty fast. But yeah. Cool. [00:45:39]

Ecosystem economics

Mark: Can make a quick spin through the ecosystem thing [00:46:01]

Carl: yeah. Okay, cool. a little bit of ecosystem, economics, whatever. [00:46:03]

Astro acquired by CloudFlare

Carl: We referenced some of this earlier, but Astro got acquired by CloudFlare. That's a bit of a surprise. I saw some discussion of it from people I respect who are like, but why? I, [00:46:07]

Mark: money. [00:46:19]

Carl: Astro's great. It's very cool. [00:46:19]

I'm looking at using it for marketing sites that I need to do just 'cause it seems like the right tool for the job. But as far as I know, they don't really have like a business plan per se. So, you know, this is we talked about BUN getting acquired by Anthropic the other month, and this just feels pretty similar to that, where it's like, I. Yes, they built something valuable. it is clearly un inarguably valuable as a project. But as a business proposition, I don't know what the business proposition is. So, you know, it's, this is a bit of like an hire, I guess, like CloudFlare is committing to maintain it. And sure, there are reasons why having good tools to build websites is valuable for a company that does hosting and network facilitation. [00:46:22]

But, you know, they're not gonna directly turn that into revenue. So that's, and I've met the creator of Astro, Fred Schott who wrote this blog post. He's great. The project's great. But economically, it's surprising and slightly confusing to me. [00:47:13]

Mark: The same thing with tailwind. [00:47:27]

Carl: Right. And here's a contrasting example. [00:47:29]

Tailwind revenue down 80% in the AI era, laid off 3 of 4 devs working there

Carl: Massively impactful, hugely valuable project. Tailwind has lost 80% of its revenue because most of that was pre-made components and advanced, you know, support. And both of those things got a lot less necessary. Now that AI is pretty good at writing tailwind. So like, this is just like, this is the dichotomy right now. [00:47:32]

Either you build something that is beloved by a thriving business such that they will buy your project. And like one of the, one of the problems is how do you value something that doesn't like create revenue? How do you value the abstract benefit offered by a project like Astro or Tailwind? It's hard. [00:47:52]

It's, you know, it's a bunch of intangibles uh, which you cannot really measure. So, I don't know. This is here's a tale of two projects, both of them massively successful and impactful. One of them losing all of its money and laying off three outta the four people who work on it and the other getting acquired four millions of dollars. [00:48:12]

this is a current rough part of open source is there is money in it, but the winners are pretty much handpicked by people who have money to give away, and that's not ideal. Yeah. [00:48:30]

Mo: What I did read afterwards was apparently they did get a bit of sponsorship coming in from a bunch of different ecosystem players, which was good. I'm glad that [00:48:43]

Carl: Yeah. Oh, that's true. That's true. to summarize some of the story for Tailwind here. Somebody opened a PR saying, let's add an AI documentation URL, llms.txt, to make it easier for LLMs to understand how to use this. And in response uh, the maintainer said like, I don't really wanna do this. AI is crippling our business. We just had to lay off three of the four people who work on it, and our revenue has dropped 80%. [00:48:50]

Mark: And I think all, and I think also put up a big podcast then saying like, this sucks. Here's what we've been having to go through. [00:49:13]

Carl: Right, right. Podcast in the form of, I think just, I think it was what Adam walks, it was like he walks around while musing into a microphone, which I love. And so like that went viral and they got a bunch of sponsorship and, you know, income through that after they laid people off, unfortunately did not save those people's jobs. [00:49:20]

And like that also sucks. You know, like, that's like the GoFundMe model of health insurance. Like you shouldn't have to. Have something awful happen. Get on a platform to shout about how awful this thing that happened is, and then get donations in response to how big of a, you know, as, as a measure of how large of a platform you have to solicit help from. [00:49:38]

Mark: It's certainly not a repeatable and reliable business model. [00:49:59]

Carl: I'm very happy that Tailwind got more revenue after talking about how much their revenue has dropped. But like, that's not gonna ha that's not gonna happen for everybody who needs it and it's not gonna happen repeatedly. So me, [00:50:02]

VoidZero and Vite+?

Mo: leads back to that void zero v plus story, which is, I don't see a viable path for monetization for open source projects. It's oftentimes it actually doesn't end up being that successful. I, I mean, mark. Mark, you've been in the ecosystem far more than any of us, I guess, just by virtue of being a successful open source maintainer, but you know, you've obviously done that on the side. [00:50:15]

Right? And like, can you think of any projects that have been successful, like uber successful at monetizing? [00:50:38]

Mark: TanStack's the only one that I can think of. Like talking to Tanner this last year. The sponsorships that he's been pulling in have were enough to allow him to go full-time, open source a couple years ago. And he said that the sponsorships have kept growing to the point where he's, he's able to do some disbursements to some of the other maintainers now, and he hopes that if things keep on this trajectory, he might be able to hire some of them full-time. [00:50:44]

But that's about the only one that immediately comes to mind. [00:51:12]

Carl: And I think, does he do, do you know if Tanner does? Uh, Like consulting and like services? [00:51:15]

Mark: Think he does some, but it's, I think a lot of it is just straight up sponsorships. [00:51:21]

Carl: Okay, cool. [00:51:24]

Mo: But I guess that's sponsorships, right? Like it's not a direct monetization play, right? So you are relying on the. Donations of, companies in the ecosystem to keep you going. Whereas like, I think the only one I can think of is super base, but they were actually going in for monetization from the get go. [00:51:25]

They just, so like the other way around works, which is you launch a cloud product and then you have an open source portion of it, but not like you start from open source and then you monetize. It seems like that's less likely. . [00:51:40]

Carl: I don't know. It's open source has always been tough. It feels like the economics have gotten weirder. It's like, there's more money than ever in tech. You know, as a market, as a, as an industry. But where it is going has is fewer and fewer players. So that's just like, that's tough. I don't know. It's like wealth inequality, open source edition. [00:51:51]

Mo: It looks like AI is just making it worse as well, even in like the terms of the tech openings, job openings that are out there and people trying to, companies trying to do more with less people yep. at everything. [00:52:10]

246K laid off in 2025 per Trueup.io, 27k in January

Carl: Which is a wonderful segue into true up.io, which I have previously relied on to, you know, back when I was doing more month by month layoff news according to them, in 2025, 246,000 tech jobs were lost through layoffs. And already in January we're at 27,000 Rough. [00:52:22]

Mo: Geez. Which, you know, Amazon had a pretty big one this week. I believe it was thousand people, which was rough. [00:52:43]

Carl: Yep. Yep. I dunno what to do with that. [00:52:52]

⚡ Lightning round ⚡

Mark: Lightning round. [00:52:56]

Corbin: Adapting Library Logic for React Compiler

Mark: TanStack form maintainer Corbin Crutchley. Put out a post talking on adapting library code to work properly with the React compiler and some of the constraints that you have to deal with Corbin's. [00:52:57]

Awesome. This is a very useful post. [00:53:09]

Lea Verou: Web Dependencies are Broken

Mark: Lea Verou, who has been in the web standards and CSS discussion, spec specification arena for a very, very long time. Put a proposed complaining about web dependencies are broken. I'm not sure I agree with some of the complaints here, but she's very clearly spent a lot of time complaining about the fact that there's a lot, essentially a lot of non-standardized ways to deal with dependencies. [00:53:11]

Do you do script tags? Do you have bundlers? What if, you know, import maps? What are your options for loading third party code? And why is this so complex and it's worth a read. [00:53:36]

AWS Infrastructure as React Components

Carl: Somebody put together a project where you can author AWS infrastructure configuration as react components, which is cool. This reminds me, years ago I had a thought to try and do a react renderer for Kubernetes config. 'cause you know, hey, it's all just files. if you're rendering right, who cares if you're rendering HTML or yaml, it's all the same. [00:53:47]

Yeah. So somebody did that for AWS infrastructure and it puts out terraform configurations. And I saw this criticized as, "great, they re-implemented XML" which is pretty heckin true. Like this is, you know, we, we've just gone full circle from XML to yaml, back to pseudo XML. [00:54:11]

Mo: I posted this on our company dev chat and someone respond, did one misconfigured use effect. And Gigi, you're bankrupt. [00:54:29]

Mark: Worse than the cloud dashboard. [00:54:36]

Callstack releasing bunch of cool projects

Mo: Alright, quick react native one. So, uh, the call stack folks have been busy whilst the rest of the ecosystem I'd say has been relatively quiet. This month and they've released two really cool projects. [00:54:38]

Brownie: RN Brownfield apps

Mo: So Brownie is the first one that I want to quickly touch on, which is a project for Native Brownfield applications. So we talk about Brownfield as apps that are mainly native, but they're adopting some React native views and screens within them. [00:54:48]

And these are difficult to build, but predominantly they get really hard when you have to share stake between them. So they're trying to create a standardized, nice way to share a storage basically a store in between your different React native screens in a largely native app shelf, which I thought was cool. [00:55:02]

Voltra: RN Live Activities and Widgets

Mo: And somebody's, you know, trying to standardize and create a project and a tool for that, which is sort of less touched on in the open source ecosystem for React Native. The second library that they released, which they didn't actually start but they've now taken over is one called Voltra. So Voltra was actually created by this open source author who nobody really knew that well in the React native ecosystem. And he just kind of did it as a side project. And I think the call stack folks have kind of taken over it. So it's for things like live activities and widgets. These are sort of native functionalities that you can't really do with React native. [00:55:17]

But this library author has kind of done a really cool job of representing it as React code, even though it's not quite exactly using a React render under the hood. It's just sort of then being translated to native views. Surprisingly the person who was the original maintainer has deleted his Twitter and you can't really find him anymore. [00:55:51]

So I hope he's doing all right. But it seems like it's being taken over by the call stack folks. [00:56:08]

Ryan Carniato’s annual JS Frameworks direction roundup , and Netlify’s 2025 Web Frameworks In Review

Mark: Okay. Ryan Carniato knows more about what's going on and across all the different JS frameworks than pretty much anyone else. I love his perspective. And each of the last few years he's done a post kind of summarizing like, where are we at and where are we going? So this is his addition for going into 2026. And meanwhile, Netlify put up a 2025 web frameworks year in review post as well. [00:56:12]

Alex Russell: Shallow Session SPAs analytics

Mark: Meanwhile, alex Russell continues to hate React and JavaScript and single page apps. He also has the metrics and the stats to back up his opinions, even if I don't agree with how he states a lot of them. And he put up a post where he said, we're basing, like we've always based the argument for single page apps on the idea that yeah, you load a lot of code, but it stays alive and users do a lot of navigations. [00:56:36]

And the metrics that we have don't necessarily support that users do a lot of navigations, but it's also possible that the metrics I have are flawed because they just don't capture users clicking around in the page. So what could we hypothetically do to gather better information either way? Which is all a very valid set of points. [00:57:00]

Devon Govett: How to compile JS to C with Static Hermes

Mark: Devin Govett, who maintains the parcel bundler, and I believe the Lightning CSS tool did a post on compiling JavaScript to see with static Hermes. I don't even remember which tool he was compiling. But Mo I know you've talked about static Hermes quite a bit, and it sounds really cool. [00:57:23]

Mo: Yes. The Static Army team has been working quite a bit. In the last couple months to get version one up and running well, version one of Hermes up and running and they're kind of at a crossroads with static Hermes. We talked about it a couple months ago, I think, where we said it, it conflicts with some of the ecosystem and how React native has naturally evolved with things like over the air updates and so on and so forth. [00:57:43]

But I think there's a lot of use cases beyond React native. So this is quite interesting to see other people look at it and see how they [00:58:03]

Mark: Mm-hmm. [00:58:08]

Mo: it. [00:58:08]

Mark: I know that the React compiler team has said that this is how they're hoping to try to optimize the compiler parsing phase as well. [00:58:09]

Joyee Cheung: require(esm) implementer’s tales and require(esm) from experiment to stability

Mark: And then Joy Chung, who built the require ESM compatibility loader for node and therefore is probably gonna be more responsible for than anyone else for eliminating common js. [00:58:16]

Eventually put up two fantastically detailed posts on the implementation work needed to make that happen. And it's fascinating to read the technical details to hear about, you know, like earlier people had tried things and then, you know, pieces were just sort of left to rot and she was able to pick them up and work on them. [00:58:29]

Great work, great write-ups. [00:58:50]

Fixing the URL Params Performance Penalty

Carl: I was a little surprised to see this I'm not familiar with this blog, Planet performance. But it's the same domain that the Post from Alex Russell that Mark just talked about is on. So that's interesting. It's not often that I see a new blog from a recognized author, so this is interesting. It's, it looks like they're talking about web performance generally, and that's pretty cool. [00:58:53]

Mark: this section was like an advent of performance type thing in December. [00:59:14]

Carl: Oh, that makes sense. Web performance calendar. Okay. It's like an advent calendar of web performance. Oh, that's cool. Appreciate that. [00:59:18]

But yeah, so Barry Pollard put out a blog post called Fixing the URL PERS Performance Penalty. And the gist of it here is that sometimes the query string the part of the URL after the question mark contains information that alters the page. [00:59:25]

Like, you know, a product details page that gets the product ID from the query string. And more often it's just a bunch of marketing tags, like UTM source and blah, blah, blah, blah, blah. And disambiguating between those two things is not something a cash can do on its own. So your marketing tags may be thrashing your cache performance. So this is talking about ways to improve that situation and make your marketing paras not affect performance quite so much. It looks like there's a header no very search that lets you alter that, alter the cache behavior in response to the query string. So it's good. It's one of those deep subjects good refinement for performance. [00:59:41]

React Transitions for Low Priority Text Editor Updates

Mark: Okay, a few more items. We had there was an article on using React transitions for low priority text editor updates. Most of, you're probably not needing to go out and update the implementation of a text editor. But someone who's worked on React Pros Mirror has some examples of how transitions were actually helpful for managing those. [01:00:26]

How to Steal a React Component (Fiber internals)

Mark: Meanwhile there was a post on how to steal a react component and you know, I believe the idea here was an extension that looks at react in the page and actually digs through the react fiber tree to not only see like what dom elements are in the page right now, but what component elements and props resulted in those. And essentially try to reverse engineer, here's the components that would have written the pieces of the page as they existed in the app that you're looking at. [01:00:46]

Better ASCII rendering with smart character selection for “pixels”

Mark: And then unrelated to React, but absolutely amazing. I love really long blog posts with lots of interactive examples. Someone did a post on rendering a graphics with ASCI characters, which a lot of, you know, tools do, but analyzing the font weights in a given character cell to come up with better pixels. [01:01:20]

So like if a, like, if the graphic should be lighter or darker using characters that occupy more or less of the character cell. It was just really cool to read this. [01:01:43]

Carl: Yeah. I think a one short summary of the change. A lot of asci rendering tools like that will consider it, you know, the character space as a pixel and just sort of think about whether a given character, you know, they think about it one dimensionally. It's how many pixels are illuminated with this character or that character. [01:01:54]

And this adds different, this basically subsamples the characters to say, is this brighter at the top or the bottom on the left or the right? And like I gotta say, you know, it's got a bunch of animated, you know, demos and whatever, and it is clearly much, much, much better than other things that I've seen. It's pretty cool. [01:02:13]

Building a JS Runtime in One Month

Carl: Somebody put out a blog post titled, building a JavaScript Runtime in one month. I love deep in the weeds engineering write-ups, and this is definitely one of those. But I have never even considered whether I might try to write a JavaScript runtime. [01:02:32]

And so I feel very intimidated by the scope of engineering involved in this project. but [01:02:45]

Mark: it even sounded like it was, you know, like, like not necessarily AI aided, at least I didn't see anything in the blog post that said they were using agents to do the work. I mean, there, there's also been a whole spate of let's have AI write a browser from scratch. Posts popping up over on Hacker News in the last month, and then I think I saw someone say they'd done a fresh browser from scratch, NC plus, but it was all by hand or something. Wow, y'all have too much time on your hands. [01:02:51]

Carl: Yeah, seriously, it's impressive. I'm in awe of people who can do projects of this scope in that timescale. Like that's just wild. Anyway I approve. Very cool. [01:03:19]

Mark: Mm-hmm. [01:03:29]

Carl: Okay, that's our lightning round. We did it. . [01:03:30]

Conferences (React, Javascript)

Carl: I'm gonna blitz through a bunch of conferences. [01:03:33]

There is C js in New Delhi in like th two, three weeks, 18th, 19th of February. State of the browser is February 28th in London. App devcon is March 10th through 13th in Amsterdam. [01:03:35]

Programmable is a conference in both Melbourne and Sydney in Australia on March 17th and March 19th respectively. So it's, they're doing two days apart in different cities in Australia. That seems like a challenge, and it's kind of confusing to talk about [01:03:50]

tech Fest is March 12th through 13th in Madrid, Spain. React Paris is March 26th and 27th in Paris. [01:04:05]

Shockingly. [01:04:13]

Mark: there [01:04:14]

Carl: Front Runners is March 27th in Washington DC React Native Connection is March 30th and 31st in Paris. City Js London is April 15th through 17th in London. Js Day is. April 9th and 10th in Bologna, Italy. [01:04:14]

. Smashing Con Amsterdam is April 13th through 16th in Amsterdam and React Miami is April 22nd and 25th through 25th in Miami. [01:04:31]

So yeah. [01:04:40]

Mark: speaking there. [01:04:41]

Carl: Heck yeah. I should reach out and maybe give a talk somewhere. That would be cool and good for me. There's lots more, but that's, you know, that covers the next like three months, so seems good enough for now. [01:04:42]

Outro

Carl: Thank you everyone for joining us . We not Wednesday, we are recording on Friday due to some travel hiccups, but we will be back probably on the last Wednesday of February here in the live stage react complex or back in your podcast feed just as we could, can after that. most of these sources came from Mark again. It's been very nice having such a steady stream of source of news sources come through here in Reactiflux. And maybe we'll do a little bit more to make the community more anchored on the people who are trying to stay to the cutting edge. [01:04:56]

I don't know, we'll see. But if you see anything newsworthy, definitely share that in the Tech News and Reads channel. 'cause we'll read it. And if it's newsworthy and interesting, we'll probably talk about it. If this is a show you get value from and wanna support, best way to do so is by telling someone else about it. [01:05:24]

We are still not that large. An average show gets about 400 listens over a little over a month. So yeah, I like doing it. I like making it. It would be cool if it had a little bit broader support, broader listenership. I guess the support is there. Yeah. Thanks so much for listening. See you next month. [01:05:39]

TMiR 2025-12: Year in review, React2Shell (RCE, DOS, SCE, oh my)

Reactiflux — Wed, 17 Dec 2025 16:00:00 GMT

[00:00] Introduction
[07:25] Main Content
- [07:32] React2Shell vulnerability
  - [15:31] Initial announcement
    
    [16:12] Followup denial-of-service CVE and source code exposure CVE
    
    [19:05] Vercel bulletin
  - [19:32] Cloudflare
    
    [19:32] Cloudflare report on exploit attempts
    
    [19:39] Cloudflare outage on December 5, 2025
  - [20:58] Tech analysis: “Flight Protocol”
  - [22:33] Vuln is carefully crafted Promise deserialization + new Function eval
  - [23:14] PRs: Initial fixes, Promise cycles / function toString, more Promise cycles
  - [24:09] Guillermo’s breakdown
  - [24:18] Shruti’s breakdown
  - [26:14] Comms critique
  - [34:59] “React is rainbow colored (function types)”
  - [35:39] What does this mean for React and RSC adoption going forward?
  - [44:30] When I go back and look at react.dev now […] it feels half-finished
- [49:14] React Native year in review
  - [49:54] More CSS support
  - [50:45] Expo EAS hosting
  - [51:18] RN 0.78: React 19 support
  - [52:18] Lynx launched
  - [52:52] RN 0.79: JSC moving to Community Package
  - [53:27] RN 0.80: Freezing the legacy architecture
  - [54:05] RN 0.81: Android 16 support for edge to edge
  - [54:36] 1.0 on the horizon
  - [55:35] Vega OS launched
  - [56:22] RN 0.82: Only new architecture
  - [56:50] Expo App Awards
  - [57:39] RN 0.83: New Devtools - no breaking changes
- [01:00:27] React year in review
  - [01:00:32] CRA deprecation, new install docs (Vite!)
  - [01:01:35] Styled Components Deprecated
  - [01:01:59] Releases: 19.2 (Activity, useEffectEvent), Compiler 1.0
  - [01:02:39] Research: View Transitions canary, perf, concurrent stores, “throw a promise” deprecated (but not merged yet)
  - [01:03:00] “Async React” and the ecosystem
  - [01:03:41] React Foundation
  - [01:04:53] React growth skyrockets
  - [01:06:05] React Router RSC support, TanStack Start WIP RSC, Waku
  - [01:06:37] Dan’s RSC explainers (he had a bunch of things to say)
  - [01:07:07] Remix v3 (not React but relevant)
  - [01:08:08] Mark went from frustrated (CRA) to excited (ReactConf, foundation, team efforts
[01:12:19] ⚡ Lightning round ⚡
- [01:12:24] TS 7 progress update
- [01:13:17] NPM classic tokens revoked
- [01:16:06] GitHub Actions planned work
- [01:17:44] Github Action pricing change and immediate about-face
- [01:19:40] Stacked diffs proposal in the works?
- [01:22:42] Anthropic bought Bun
- [01:24:52] SVG Clickjacking (SVG filters as logic gates??)
- [01:28:16] Dan Abramov’s RSC Explorer, accompanying blogpost
- [01:28:36] Instant-loading Github repo explorer using RSCs: Without the blue bar
- [01:29:10] React Router’s Take on RSCs
- [01:29:19] How AI Coding Agents hid a Timebomb in Our App
- [01:30:58] React Compiler’s Silent Failures (And How to Fix Them)
- [01:31:36] Great history of web dev: 30 Years of
  Tags
- [01:32:17] Nadia Makarevich’s latest deep dive: Bundle Size Investigation
- [01:33:35] Extensive ES2026 feature preview
- [01:34:53] React reconciler for Blender 3D
- [01:35:31] The “why” of React Fiber
- [01:37:21] Async React articles from Aurora Scharff and Jack Herrington

Introduction

Carl: Hello everyone. Thank you for joining us for this edition of this year in React, since it's the December edition of this month in React, as we're gonna recap what's going on with React, React Native and the web more generally, or I guess really what has happened, what has been going on through 2025, just to give you a little rich perspective. [00:00]

Although we do have so much new stuff to talk about this month, so that's gonna be a little bit goofy too. We gotta balance both. We're actually planning on doing a longer episode than usual this month, mark and I are gonna hang out for closer to 90 minutes. Mo's got to leave at an hour. [00:17]

But yeah. Let's get into it. I'm Carl, I'm a staff product developer and freelance community leader here at Reactiflux, or I run community programs like this and build tools like a moderation bot that is growing steadily more complicated. [00:30]

Mark: Hi, I'm Mark. My day job is working at Replay. My second unpaid job is working on Redux related things. And my third unpaid job is copy pasting links like crazy. [00:44]

Mo: And my name is Mo. I head the mobile team at Thedo in the uk. And I am a member of the React Native community who organizes meetups, like the React Native London Meetup. And I also organized the RNL Conf, which just happened last month and was great fun. [00:55]

Carl: Yeah. A leader in the React Native community. I'd even go so far as to say, [01:10]

Mo: I would say member Member is, and member humility is good. [01:14]

Carl: yes it is. Okay, fine. A steward. [01:17]

Mo: I, I appreciate you, Carl, as always. [01:20]

Carl: Let's get into some new releases. Base UI has a v1 release candidate coming on. Yeah. I actually got a chance to speak to the maintainer of Base UI at React Con briefly. I hadn't realized it, but it is like fully a relaunch of, oh, I'm blanking on the other LI library that they were [01:22]

Mark: doing. [01:42]

Redx, [01:42]

Carl: Yes. [01:43]

Mark: or, or, or equivalent of Redx. [01:43]

Carl: yes. So apparently Base UI is a relaunch of Radix, essentially because the team got acquired, the RAD X team got acquired. They were given verbal promises that they would be allowed to continue maintaining it as part of their full-time responsibilities. And that was not true and they did not have a contract saying it. [01:46]

So, they have relaunched under a new project, which is unfortunate, but also great. I don't know, sometimes it's nice to get another chance to do the thing from scratch again. I guess. So anyway, they've got a v1 release candidate coming out, which is cool. [02:06]

Mo: Next up we have React Native version 0.83, which is very exciting for a few reasons. I'll start from the somewhat non-obvious reason, but it's also a good one worth mentioning, which is there are no breaking changes in this, and I cannot stress how important that is for a React Native version release because, every single time you update a React Native version, it's typically, at least, especially in the past, had a reputation that it is a painful process and you're gonna need to change a lot in your app to make it work. [02:21]

And not having any breaking changes is super cool, like, like big props to the React Native Core team for doing this. And so, super, super cool. And , I'm excited to see this as the direction that we're going with releases, which kind of makes sense when you go back to what we heard at React Conf , and React universe conf other things in this release. [02:49]

The new dev tools , is something that's been in the works for a very long time. And Alex Hunt and some of the other folks at Meta have been working on this for a really long time. We got demos of it earlier. And they've been working more and more on this and adding things like performance tracing and network inspections. [03:07]

So we saw a lot of these as demos earlier, but now it's really, really coming through and uh, we're seeing it in production, which is awesome. So a lot of cool stuff and some other stuff that I won't go into in the interest of time, but massive props to the meta team for getting this out. [03:21]

Carl: Yeah. And I believe they gave a pretty big demo of the dev tools at React Conf. Is that right? [03:33]

Mo: Yep. But they've also been demoing it from last year at React Universe Con, so it's been, there's been a long time since 2024. They've been demoing this and there's teasers of it coming out at some point. So it's been in the making for a while. Obviously, it's been getting more and more mature and more ready for sort of a production release out to everyone. [03:40]

Carl: sure. It wouldn't surprise me if there's some overlap with the new architecture too. 'cause if you're gonna totally change how the internals work, then doing instrumentation and developer tool stuff is really hard. So that makes [03:58]

Mo: some tools were really painful before these new dev tools like Flipper, the React Native support got deprecated, was notoriously difficult [04:10]

Mark: use. So [04:17]

Mo: this is a move in the right direction. Obviously. There was a, there was much demand for it. [04:18]

Carl: very cool. [04:22]

Mark: Next up the, the last couple months we've mentioned that Christophe Nakazawa had been posting teasers on Twitter for a new data fetching library that he was calling fate. And so he's put out the first alpha of that. The main ideas are, it's got some graph QL like features in terms of components specifying what pieces of data they actually need and being able to sub-select pieces of data. [04:22]

But it's a wrapper layer on top of TRPC, so, it'll be interesting to see how this one actually compares in practice to the 15 million other data fetching libraries out there. But nice to see another new approach. Meanwhile, the void zero folks have several different new and alpha and beta releases coming out. [04:47]

The oxalate linting tool has, and now has support for type aware linting with the Ts go native build built in. And OX format tool has its first alpha they say it is essentially almost entirely prett or compatible I think, maybe not this release, but a future one. They're working to include tailwind formatting support as well, so, faster tools. [05:06]

Very good. Then along with that V eight is in beta and this is the release that will include the roll down rust base build tool replacing ES build and roll up. So they are very, very busy cranking along on all the different pieces of their ecosystem. [05:33]

Carl: Yeah. I guess Tan Stack is also exploring and they're, they've released an alpha of an ai, SDK yeah, I don't know. Ai. SDK is so hot right now, or so hot a year ago. This, this is a bit of a late entry into that market. But Tan Stack, Tanner Linsley generally has done so many great things that I'm, oh, you know, I'll see what he do. [05:53]

I'll see what he does here. He's got good opinions about developer experience and the contracts we interact with. Yeah, [06:12]

Mark: I, talked to him at, at React summit when he was. Dropping hints that this was in the works, and he said like, it wasn't even something that he was intending to do himself originally, and supposedly a lot of folks from the ecosystem asked if Tan Stack would build an alternative to the Vercel AI SDK, just so there was competition, and that, the main entry here wasn't just owned by Vercel. And trying to take the same vendor agnostic and fully typed approach that all the other Tan Stack tools use. [06:20]

Mo: that's so, so important. I'm, and I'm glad someone else is doing that. having the option to have something like Tanex start as a, another way to handle this is just so good for the ecosystem. And I am glad that someone's tackling the AI SDK space because. Yeah, competition's great. [06:54]

Carl: Yeah, no, it, it totally agree. I don't know. It's feels very good to have a legitimate community maintained option that's not, like, great Google's doing it, Facebook's doing it, everyone has their own thing, but like, really nice to have one that's open source first, so that's good. [07:10]

Main Content

Carl: Yes. Okay. Let's get into our main content, starting with can anyone guess it's gonna be the React2Shell vulnerability? [07:25]

React2Shell vulnerability

Carl: The biggest news in a very long time, What happened? It was a major, major remote code execution vulnerability in RSCs where you didn't even need to be using RSCs for your app to be vulnerable. [07:32]

If the server supported it, then an attacker could send a specific payload to your server and get a remote code execution. It's real bad. This is Like the fact that not only is it full remote code execution, but combined with the fact that you don't even need to be taking advantage of the feature, it just needs to be enabled in your environment is pretty bad. [07:48]

That's pretty bad. Actually, in the ensuing drama. So a uh, longtime, serial entrepreneur in the community was posting about like "uhoh, I think I'm vulnerable. Uhoh. Yep. I got exploited uhoh. My docker is also vulnerable to a recent vulnerability that enabled container escape." So like it turned, just like researching this React vulnerability combined with some other recent container vulnerability they were exposed to let an attacker not only get into their system, but escape the containment of what is supposed to be a security layer there. [08:12]

So, yeah. Oof. it's been a bad six weeks. No, it's been a bad year. It's been a really bad year for computer security. Like, holy shit. [08:46]

Mark: How many different problems have we listed like there were, we'll talk about it more later, but Next middleware bypass, NPM Hacks, NX React2Shell, like the JSD ecosystem is hurting. [08:55]

Mo: I think we've heard anything quite as bad as this. Like as in the industry since the big job of vulnerability in 22? [09:07]

Mark: I, think It I I think that was Log2Shell maybe. [09:14]

Mo: was like that was the last [09:17]

big where you heard about it all over where people could exploit Java spring applications. So people were just exploiting backends left, right, and center, and it was a serious critical vulnerability. [09:19]

I think this is like like as bad if not worse, and there hasn't been anything quite the severe since then that I can recall making news like this. [09:28]

Carl: Yeah, You get one of these [09:36]

every couple years. 'cause Log2Shell was definitely one of them. I remember Heartbleed 10 years ago. these do happen. It's never good when it's your ecosystem. I don't know. thing I said is, serious vulnerabilities like this, they don't necessarily, they don't really what, what I take away from it or what I recommend people take away from it is not, this tool is insecure. These people maintaining it are idiots. [09:38]

Like, no, this is, security is really fucking hard to get right. It is an adversarial space where, as brilliant as you are, your primary task is not making something impenetrable. Like that is second a secondary goal of anything you're doing as a software developer if you are not a paid full-time security engineer. And doing something useful it is just really hard without introducing vulnerabilities like that. [10:06]

So the line that I like is that CVEs, like a critical CVE doesn't mean that it's insecure. It means that it's worth targeting. 'cause most tech is insecure. Like if unless you have dedicated significant resources towards hardening it, it's insecure, like definitely a hundred percent. [10:32]

So the fact that it took this long for it to get revealed to me says that they have done hardening work, they have put effort into making it secure. And because they put that effort in, the actual vulnerability was complicated enough that it took several years before somebody actually figured it out. [10:52]

And also I'll say, I know that I, I saw a tweet from uh, Malte Ubl, the CTO of Vercel you know, engineering leadership at Vercel saying that in the wake of this they did a bug bounty hackathon and ended up paying like $750,000 in bounties out. Presumably that's a long laundry list of like minor vulnerabilities. [11:12]

I don't, I don't believe they've commented publicly about what exact [11:33]

Mark: I, I think, I think that one may have been somewhat related to Elle's application firewall rules that they, that [11:36]

Carl: So this is their consumer facing security tool to make it. More protected and they found a whole bunch of new ways to make it safer is what it sounds like. [11:44]

Mark: Mm-hmm. [11:52]

Carl: Cool. Yeah. Great. Yeah, I guess to say a little bit more about where this vulnerability came from and why it was so serious, like this level of vulnerability is fairly rare and JavaScript, I would say largely because in general , the types of code that have a greater risk of introducing this type of vulnerability, usually you'll just farm it out to a different, something that's already been battle tested and hardened in that way. [11:53]

Specifically why this happened is because, so React is basically a scheduler at this point. It's scheduling work. It is, competing with V8 and other JavaScript run times in order to do scheduling of execution. That's just like, as they were building React and realizing the performance snafus they were running into, like they realized, oh shit, we have to write a scheduler. [12:21]

And that was, do you remember what the code name for that was? Mark? [12:44]

Mark: That was fiber. [12:47]

Carl: So like that was React Fiber. It was, "we're turning React into a scheduler." Now server components are , basically building on top of that. It's saying, okay, we built a scheduler. Now we've realized that in order to provide the kind of experiences we want to be enabled to offer, we think that we have to transcend the network boundary and be able to schedule work not just on the client but across the client. [12:48]

We need to be able to pause execution on the server, put it in a little box, send it across the network, then open the box and pick up right where we left off on the client. And that's fucking hard. So like they already built their own scheduler, so like that's bespoke. You can't just use existing tools for it because they made it. [13:13]

the reason this vulnerability came in is because as part of pausing execution, bundling it up and shipping it somewhere else, that's serializing it. That is serializing a complex set of execution state. And where else have we talked about serialization being a major ecosystem level? Project, it's the React Native new architecture. So like this is the same problem. Serializing is slow. It's vulnerable because you're taking data and if you wanna make it as compact as possible, you have to invent a binary format. [13:33]

And as soon as you do stuff in binary, that's really dangerous because people can structure payloads so that the binary data lines up in just such a way that a naive interpreter on the other end of it that opens, it goes, oh, I know what this is, runs it, and oops, then you've got like a shell escape or like a terminated memory before or after you just like, that's, how you get all of these most serious vulnerabilities is a binary formatted data source gets deserialized, and somebody tricks that deserializing process into thinking that something different than was actually sent is there. [14:09]

Mark: We'll dive a little more into the, technical aspects of this later. But big picture is the, the flaw itself was in the serialization deserialization logic, which was written in order to be able to handle serializing and deserializing And because it was generic code in the sense that it was meant to handle, conceptually any piece of data, carefully crafted input could, when revived , run as promises get turned into a function, constructor escape the sandboxing. [14:46]

And next thing the attacker is running arbitrary JavaScript code within the context of your server. And then very bad things happen. [15:22]

Initial announcement

Mark: So the initial announcement came out it was timed with a bunch of fixes from all the different RSE frameworks. So, clearly the, the work had been done behind the scenes for coordinated disclosure and fixes. [15:31]

All the major hosting platforms for CloudFlare, Dino Netlify also immediately came out with application firewall rules to try to block, what they knew about the attack at the time. And as Carl said, once someone knows that there's vulnerabilities in a certain system, everyone else in the penetration security space is gonna swarm and look for other potential issues in thing. [15:45]

Followup denial-of-service CVE and source code exposure CVE

Mark: And so that's why the next day there was a second set of announcements saying that two more new CVEs had been discovered. One was a denial of service attack where React would try to infinitely revive a series of fake promises. And then the other one was a source code exposure vulnerability, where crafted input could force the API to return the contents of a server function that you had written on your backend. we had the one truly bad CVE, the remote code execution. And then as other people looked at what was the fix, what was the area, what's going on, what else can we find? A couple of additional follow on things were discovered. And you know, as Carl said, it's, yeah, those were there, but it's also, and now people are looking for them because there's the potential for more problems. [16:12]

Carl: If you can do a remote code execution, that probably means you can do other things most likely, very proximal to that same vulnerability because like so much of it relies on manipulating the binary encoding. That , that smells like . If you can do that, you can do other things. So I'm not surprised to find that they found other things. [17:07]

I will say like remote code execution, source code exposure, and denial of service. Like, oh, that's rough. That's like the trifecta of things you don't want to happen. So yeah, finding all of them, it's like now we know that they're not there in that way at least. So like great. To me this builds trust a little bit. I actually chatted briefly with Ricky Hanlon in the wake of this and asked what kind of security hardening they have, what's kind of security review they have done as part of designing this. [17:25]

Because, like I said, like Serializing deserializing is a well-known dangerous place to be. It's a dangerous place to find yourself. Like there are projects that I've not done because I realized like, oh, in order to do this, I'm gonna have to touch binary stuff. And that gets really hairy and you have to do that very delicately. [17:58]

So like that to say like, there are smart people on the React core team. Like they absolutely knew this was a risk. And I'm curious to hear more details about what mitigation they've done over the last, six years that server components have been in development in one form or another. Yeah, so Ricky Hanlon said that he'd do some research on that and include it in the post-mortem blog post, but I, I haven't seen the post-mortem blog post yet, so [18:15]

Mark: So , this happened in what, December? 11th ish, I think. [18:41]

Carl: Yeah. second pair of vulnerabilities was the 11th. First one was the third. [18:46]

Mark: Okay. we had the initial announcement, which was dubbed React2Shell. Vercel has put together a, a very comprehensive set of details on what happened. looks like December 3rd. December 4th was when the initial announcements came out. [18:51]

Vercel bulletin

Mark: Vercel's bulletin has a lot of info on the timeline and how to fix things, which is basically upgrade to the latest version of any React based framework. [19:05]

Now, if you haven't already done so. And they provide instructions on how to do that. In the wake of all this, we've already seen the vulnerabilities being exploited. Carl mentioned a Reactiflux community member who got hacked as a result. [19:15]

Cloudflare report on exploit attempts

Mark: CloudFlare put out a post detailing. "Yeah. We're, seeing this getting used in a lot of penetration scans." [19:32]

Cloudflare outage on December 5, 2025

Mark: An interesting side effect of this was CloudFlare had already had a dashboard problem when they DDoS themselves with a use effect and then they. They also had an issue with something else on their backend. I think second or third outage then happened when they tried to roll out a change to buffer sizes in relation to fixing React2Shell, and made themselves go down again for another half an hour. [19:39]

Carl: , it's funny how these seem to be kind of unforced errors on Cloudflare's part, like Yeah. , they also were like Johnny on the spot with a blog post saying, we've got a web application firewall that will prevent the worst of this from happening. And then like, took themselves down for a couple of hours. [20:08]

I was reading the, the writeup of this and it sounds like they started seeing elevated errors in a tool that was related to determining production errors. It was a tool partially designed to help avoid the risk of outages. They started seeing error rates rise in that and we're like, nah, this is fine. [20:26]

We're gonna keep going. That, so that seems a little like an unforced, self-owned there, which is un. Silly to me, given how smart me they came across at the very beginning of this vulnerability. Anyway, I'm just giggling at them. [20:46]

Tech analysis: “Flight Protocol”

Carl: Okay. Some tech analysis. I guess I did sort of an abstract tech analysis, but let's get deeper in. [20:58]

Mark: The React team is very fond of their project code names that start with f They, they've literally got like two or three dozens of them. So, fiber was the React 16 rewrite. So React Flight is the code name for most of the work that has to do with implementing server components. And so the flight protocol is their custom serialization and deserialization technique that is meant to encode not just data, like , it can, serialize JavaScript objects and, more advanced values like dates and promises and stuff. [21:04]

But it also encodes a lot of the semantics of react components themselves. Like when you put a suspense in there, it puts in a placeholder value that says this will be filled in later, and so on. So there's many other like advanced JavaScript serialization libraries out there like cereal, but they built their own because they specifically needed it to handle react related concepts, not just , the data. And so ultimately the vulnerability is in this flight protocol implementation. Not the data format per se, but the process of doing the deserialization. And so because of that, it's a core part of RSC functionality itself, not specific to any one framework, which is why all the RSC frameworks were affected. [21:42]

Vuln is carefully crafted Promise deserialization + `new Function` eval

Carl: Yeah, so I guess the vulnerability here is a carefully crafted promise des serialization and a function eval. [22:33]

So the danger there, like function eval. one of the JavaScript concepts they're trying to serialize is executable code dangerous. this is why if you, this is why you don't use eval. This is why like eval has lint rules saying never use this because 'cause it's so fucking dangerous. So it's not literally eval in this case. [22:42]

Mark: It's not the eval keyword, but new function and, and passing in a, a string is essentially the same thing. [23:03]

Carl: Slightly different semantics, but essentially the same thing. Executing untrusted code. [23:09]

PRs: Initial fixes, Promise cycles / function toString, more Promise cycles

Mark: There were three major fixed prs. The first one has the fix for the actual remote code execution vulnerability, and they snuck the fix into a larger PR that did a bunch of other refactoring to try to add just a little more obscurity with what was going on. But I, I saw people quickly identifying which bit of that PR was the actual error. [23:14]

Basically it boiled down to a couple lines that had like, looking up module[name].something else. And so just like a generic object field lookup with user provided input for the field names. And the fix was essentially adding a object has own property [23:42]

Carl: check [24:04]

Mark: around that. And so there were a couple very good breakdowns. [24:05]

Guillermo’s breakdown

Mark: Guillermo Rauch, CEO of Vercel posted a, a tweet where he went into some detail on what the actual vulnerability issue itself was. [24:09]

Shruti’s breakdown

Mark: And then Shruti Kapoor had another very good breakdown, and I saw a few others being posted as well. It's one of those things where on the one hand, you look at it and it's like, okay, if you think about it, this is a generic object lookup with user provided input. [24:18]

And at no point was that user provided input sufficiently checked and someone figured out the right sequence to make it happen. On the other hand, Ricky Hanlon also made the comment that figuring this out and crafting the input was incredibly advanced. Like, yeah, in hindsight, maybe some of this looks really simple and obvious, but as Carl said, like it, it took years for anyone to look down far enough and realize that this particular bit of code was vulnerable in [24:36]

Carl: Yeah. It's funny, I'm reading this, Shruti Kapoor's writeup of it, and it really reminds me of SVG, , the way this is encoded reminds me of how SVG is encoded. , line one is M1 colon and then a bunch of data. M is a means, this is a module one is the ID for this module. Like, " J0, this is a json chunk with root component ID zero." [25:06]

So I don't know. That's interesting it rhymes with something I've noticed in my career is like, I did some really cool, fun stuff with SVG because when you start looking at the details of how things are encoded, like this, you can do some really interesting things. [25:30]

It's like all the tools will generate a certain type of valid thing based in some assumption, but when you start actually looking at what they're producing and doing it yourself, you find interesting stuff. So, I don't know, that's just, that's what the security researcher did is instead of relying on the compiler to do output for him, he tore it apart, looked at how it actually worked, and then went, "Oh hey, this lets you get arbitrary modules and extract whatever thing you want off it. I bet you can do something interesting with that." Yeah. [25:44]

Comms critique

Mo: I'm curious as to what you guys think about this. Like, I, I'm looking at , the sort of, the quote from Ricky and part of me is like, I appreciate it. It, it is very complex, attack that you need to coordinate at the same time, it feels a little bit, shrugging of the issue, which was a very key, core vulnerability. [26:14]

Right. it's almost like in contrast to CloudFlare, where they're like, "we fucked up. We know we fucked up. We let you guys down. We've lost your trust." Granted they've had to do that a few times now, but , the point is , it just feels a little bit immature to brush it off to say, I don't know, maybe this is just my opinion. [26:31]

I'm keen to hear what you guys think from like a how should open source slash big tech companies handle when I say open source slash big tech? 'cause it's effectively when speaks, kind of speaking on behalf of Meta, right. Whether he likes or not. And it's like, I don't think that that's a constructive way to look at it, to be like, it's quite complex. [26:48]

That's why CVEs are discovered. Hackers and bounty hunters are the best people to discover this. It's like, not quite like, you guys are the maintainers. You should look out for it. It feels a little bit like shrugging off a very, very, very core issue that happened in ecosystem. [27:06]

Mark: So on the one hand I think from a, like a security response perspective, the React team and all the rest of the, the hosting companies have done the right thing. There was, some private disclosure happened. Everybody worked out the patches, had the firewall rules ready to go. [27:21]

There was a coordinated release so that at the moment this was publicized, like, there was immediate protection and fixes of Ill, like that is the correct part of the handling. then similarly, as soon as the additional CVEs were discovered, there were follow up posts, tools, created to help bump all your versions. [27:38]

Like all that stuff has been excellent and I think , they've that stuff the right way. On the other hand, as you're pointing out, even from like a perception perspective, , the blog post on the follow up CVEs. Initially, one of the first bits in that post was a call out box that said, "follow up CVEs are a very common thing because everyone, now, everyone is looking at your code." [27:56]

And the React team actually got called on in Hacker News, like, " which is more important, protecting your reputation or giving people the information they need to re-update their tools." And, to their credit, , they restructured the post. So the tech information was first. [28:21]

I I do totally get the preemptive defensiveness. Like of course, the React team and ecosystem are gonna get criticized because, oh no, now there's more problems. Look how bad your code is. I totally get that. I think the comment was, justified. But putting that as the first thing in the post was maybe not the best way to do it. [28:35]

I agree with you that the way the phrasing here and the defensiveness does not look ideal. [28:56]

Mo: Yeah. And it's just a phrasing thing, right? It's like, I, I agree with you a hundred percent that it was very well coordinated. They worked with all the right people, all the right hosting providers, and did a good job of tackling a critical vulnerability, right? But then the messaging is a little bit laissez faire, like, let's just, this happens guys. [29:02]

Of course it happens. And so that, that's the bit that I'm just, a little bit it doesn't sit right with me. [29:23]

Carl: Yeah, I have some opinions on this., I don't know. This is, deep in the weeds of like communication, effective communication, especially when you've someone wrong. Even that someone is an abstract group of millions who rely on your work. [29:27]

Yeah. defensiveness is never good to lead with Also defensiveness. Is a lot broader than most people think about. If you are offering a reason, a justification, an explanation, all of that is defensive. That is saying, maybe it's not saying :it's okay that this happened because," but it is saying there are mitigating factors. [29:40]

And at the outset while talking about, a problem, a thing, it is never good to offer reasons why you made that mistake. Just like you made it, it happened, it's done, own it.Don't defend it. [30:00]

Mark: Which, which I think has generally, as a, counter example, I think generally been one of the strengths of Cloudflare's, you know, outage messaging It's like, yeah, we screwed up, but here's exactly what happened and the things that went wrong. they're explaining the technical reasons, but it's generally factual rather than like communications oriented. [30:16]

Carl: yeah. And I wanna, Mo you used the word immature and I think I like yes. In context it's the wrong, it's like wrong. I would reframe it from immature to like, this is crisis comms. This is public relations at a world level security incident. [30:37]

And so while the, while that instance of, defensiveness, especially when you feel that you've done everything you could, you've done your best totally get it totally makes sense. There's a really strong instinct to do that If you're operating at a world class level, the expectation is higher than that. So I guess I would reframe it from like immature to like not meeting the bar of excellence. [30:58]

Mo: What Mark was saying was exactly what I was thinking, which is like the CloudFlare posts are exactly how I would rather have this handled, which is an admission of whatever that is an admission we made a mistake or we didn't discover this, I'm sorry. [31:20]

And here's exactly what went wrong that reads as I'm giving you the technical reasons and I'm being transparent with you, rather than I'm defending myself and trying to, to cover up [31:33]

Mark: And are all the mitigation steps going forward to improve our process and make sure that this set of problems never happens again. [31:42]

Mo: To play the devil's advocate. To my earlier point, I get the emotional instinct to defend yourself. Right? Like it's an open source project. You've chosen to work and benefit off of the work that React and the React team have have been building. I get it, like open source maintainers are not appreciated enough, but you are also a multi-billion dollar company and you need to have some PR instincts as part of that. [31:51]

Carl: Or delegate to a PR team. [32:14]

Mark: The reactions to this have been incredibly predictable on Hacker News and Twitter and everywhere else, which is lots and lots of, " RSCs were a mistake in the first place. boy, I am glad I never adopted RSCs" and lots of similar threads from lots of people. [32:15]

Carl: Can't avoid it. Look at us not doing that. We're so good. [32:34]

Mo: Give ourselves pats on the shoulder collectively. [32:39]

Mark: We've seen complaints about server components being quote two complex really since the beginning. And like with the word boilerplate people use the word complex or complexity to mean lots of different things. Is it the mental model? Is it the technical implementation? [32:42]

Is it the architectural approach of trying to bridge the server and the client? I mean, diff different people have different pieces in mind when, when they use the word complex. I, I think there, like, there's probably some fair validity to the concerns. We've talked about the mental model of trying to understand if you're looking at a given file, a given function, understanding where is the code running, when is the code running, what are the inputs needing to, if I've got a secret value on the server, how do I make sure that it's not getting accidentally exposed and sent to the client? [32:59]

So, as Carl said, part of this is just, client server behavior is a distributed system. It is a inherently complex thing. And we are trying to solve a complex problem with 50,000 different attempts at abstraction, server components being one of them. So part of it is, this is just a very hard space, but it's probably also legit to say that this particular set of abstractions is complex, both in terms of mental model necessary technical implementations. [33:35]

You know, as always, I feel weird saying this stuff because I'm on the sidelines and so I'm the bystander without the hands-on experience, but just eyeballing things. I think that's maybe a point in favor of something like remix loaders or TanStack Start server functions where you look at a thing and it's very, very explicit: this is the function that runs on the server. And okay, yeah, maybe there's still some bundler magic that's going on to make that feasible be in the same file, but at least there was something in the code that very clearly said where that piece of behavior is intended to run. [34:07]

Carl: I'm just saying if this were written using the primitives that Effect-TS offers, then list what environment was required as part of the types, like you could get type level guarantees on this shit. I'm just saying. [34:45]

“React is rainbow colored (function types)”

Mark: There was one tweet that I saw, which was using the metaphor of different function colors. this concept started as a blog post like a decade ago where someone that sync and async functions are differently colored and that they're, they're essentially contagious. [34:59]

That once you have an async function, it spreads through the rest of the code base. And so this tweet. Was saying, well now we've got like three different colors and they multiply. So now you have to consider like function components, server components, hooks, server side, client side. It was kinda like the multiple kit of factor of all the possible variations in how a thing can run. [35:15]

What does this mean for React and RSC adoption going forward?

Mark: All right, one, one last bit of Opiniony stuff and then we can move on. So what do we think this means in terms of, what's going to happen with React in 2026, but also what does this mean in terms of server component adoption at this point? [35:39]

On the one hand , we've been seeing the positive technical progress in the ecosystem where it, it's getting past the experimental stage in other tools. [35:56]

React Router has added RSC support walkthrough is getting closed to being production ready. Redwood is out there , TanStack Start is looking at RSC support in its own unique way. So we're getting past the point where this is just a feature that's available in Next, and that feels like it's going to be very big for adoption. [36:06]

I think actually React Router support is gonna be huge, but now you've got a vulnerability here and you've got all the naysayers popping up and saying, "ha ha, look. See, I was right. This was a bad idea." So plus and minus, how is this gonna behave? [36:29]

Carl: I will say I think the haters are gonna show up no matter what, and the only thing that varies is, there's some variance. There's probably gonna be more haters because of this than there might have been otherwise. But many of those haters would have just been saying something different if this hadn't happened. [36:45]

So I think there's gonna be, I think this is gonna end up being net good because there deserves to be more than an uncritical adoption. Like, you know, when I think about when hooks came out, everyone's like, "aww yeah!" And just like immediately all in. [37:01]

So like it's a rainbow colored functions. It's bunch of complexity. It's difficult to know where code is executing now. It's hard, Next adds on additional caching stuff that adds even more complexity. So I think this might trigger a bit of a reckoning for the folks pushing the state of the cutting edge, the people who are pushing the envelope, I think are going to be forced to offer stronger justification. Forced is wrong, let's say pressured. [37:18]

What do you think would be good, I've said a couple times over the years of doing this podcast that like I view the, the React core team as doing like post-doctoral research in distributed execution of, you know, ui. So with that framing in mind, this is going to ask those folks who are doing the more academically minded whatever to more strongly justify the direction, which I think will be good. And I think, we'll, I would hope will lead to more robust everything. [37:47]

The "react is rainbow colored," I think is like so deeply real and a major limiting factor because you're context switching and like you said Mark, , there's nothing in the code to indicate where it's executing. You have to know it. [38:22]

I'll say that, specifically, the fact that you can't look at the code and understand aspects of it without gathering more context from where it is, is like deeply antithetical to the model of programming that React is built upon, like componentized self-contained, tiny world. If I'm looking at a component, generally, up until React server components I guess, I know that it has everything it needs. Unless I've done something else. [38:36]

Like, okay, CSS can cascade, context is slightly unknown. But like I can look at the guarantee, I can look at the code and statically understand what guarantees it requires from its environment and what it's doing. [39:06]

it doesn't just like reach into other stuff and change things at random. And so with React server components, I can no longer look at a single component and fully understand where it is in the world. So I don't know, hopefully that changes. [39:22]

Mo: So we've gone through an, an era over the last couple years where it's been a heavy focus on RSCs, right? [39:36]

And I think someone in the chat as well today asked like, are RSCs good or bad? Right. And I think that's the issue is just because it's been so center stage on every discussion about React. It's almost been implied that everyone needs RSCs, everyone needs next. Anyone who builds a web app needs these tools, and this is the right evolution for everyone in the ecosystem. [39:44]

I personally never believed that that was the case. I think it was a good optimization and a good next step to help take React to certain paradigms and certain spaces where it wouldn't have been suitable for before. But it wasn't the be all and end all. [40:08]

And I've been working with a client where they started off with next JS, in the beginning of the year they brought me in to try to help them a little bit and clean up the next JS app because they weren't next JS developers. They were from a totally different ecosystem and they were trying to understand next, and the app was a mess. And so over the last couple months , we realized, well they don't really have the expertise to be able to manage like a complex next JS app that was quite large in the surface area and handle all of the caching complexities and RSCs as a concept within that development team. [40:22]

And so we switched them to Astro after a while and it's just been a lot easier for them to conceptualize and understand that. And so is this a net good? I actually think it is because like you say, Carl and I completely agree with that. It's, this is going to help us really stop pushing this like, envelope of RSCs are for everyone. [40:57]

And this is by no means me saying RSCs are a bad evolution of react. No, to the contrary, I actually think it was a good route, good evolution, but it's not for everyone. It's not for every site. We neglected single page apps, which are for so many things in pursuit of this RSC Dream, and I think we need to come back to reality and see like, what is the ecosystem in its whole? [41:21]

And start to prompt people to think a little bit before they always reach out for next js for every single project that they wanna do. do you actually need next? Are you having to take on the complexity that next gives when you adopt next? And like it has a lot of benefits, but like, does your site need those benefits? [41:42]

Or are you just doing it because it's what everyone else does? so I honestly think it's, it's a good thing. It will be tough. There will be an adjustment period, but I think it'll, generally make us a bit more nuanced as an ecosystem, which is good. And the bleeding edge is not always the be all and end all. [42:00]

The bleeding edge should be there to help push everyone forward. It's not for every single app that we built. [42:18]

Carl: Yeah. [42:24]

I, have an analogy that I love, or I don't know, an analogy, a way of framing that kind of, you just expressed of like the we, the bleeding edge and like reigning it in a little bit there. [42:24]

I think there's a really strong need for two types of work. There's the people who are expanding the range of what's possible, and then there's the people who are bringing that out to everybody else. So like, as you're exploring, like you can't be constrained about what is this gonna look like for, every individual actor. Like that's, if you're exploring under the constraints of analyzing it for every possible possibility, you will never explore anything. It's just too much work. [42:36]

So that needs to happen largely in isolation, in order to happen at all. And then there's a translation. It's like, in entrepreneurial terms, it's the distribution problem. It's how do you get it to everybody, great, you've made a perfect, better mouse trap. How do you get people to know about it, realize it's better, and buy it? [43:02]

Where in this case, buy it is, install it over some other tool. And yeah, so I think we just got a, the naysayers got a much stronger argument. We'll have to see how that plays out. [43:23]

Mark: I will tie this back to one of my favorite hobby horses, which is documentation. Maybe I overindex on better docs being the answer to all problems, but it is my answer to all problems. And so, one of the points I've made repeatedly over the course of this year is that the React core docs don't talk about server components meaningfully. There's one page with scattered bits of information, but the core docs have no intro to what are server components, what problem do they solve, why should I use them, when should I use them, which apps and architectures would benefit from server components? [43:34]

And there are some great posts out there that go into a lot of this information. Vercel had a intro to RSCs post. Dan has his explainers on server components from different mental models, but the core docs don't have this. [44:15]

When I go back and look at react.dev now […] it feels half-finished

Mark: And even today I was actually having a, a tweet discussion with Rachel Nabors, one of the original docs authors. And we agreed that the tutorial kind of trails off. [44:32]

It doesn't give you any real world steps on how to apply your theoretical knowledge of components. [44:39]

I don't necessarily think it's the React Docs job to explain everything about web app architecture, but given that React itself is now more than just a view library, that I think there ought to be some guidance in the docs about how to act like, when does it make sense to use these different tools that we're providing you. [44:46]

Carl: I like her post saying, when I go back and look at React dev now, and like React, do Dev was her project. She like, [45:09]

what, when it started, as, [45:16]

Mark: Her and Dan together. Yeah. [45:17]

Carl: Right. Right. And so she says, when I go back and look at React Dev now after having shipped half a dozen more developer education portals since launch, it feels half finished, they're saying. This is part of their early work. They got better at it and now they see room for improvement, which I think is really real. [45:19]

Mo: Yeah, a hundred percent. And the earliest like time, we started to actually talk about this this year, which kinda goes into the year recap, but is we, we conversation finally over the CRA deprecation. Like that was the reckoning that started this conversation about what did, what is the React stance on, where is RSC suitable and where is it not suitable? [45:34]

So. It's interesting that we're looping back to this, but yeah, it's, it's been a common theme for the last year. [45:53]

Carl: Yeah. And man, going back to my, comparison of like the explorers and the, I don't know, salesmen did, for lack of a better. [45:59]

Mark: There are specific like business programmer archetype posts that I've seen that cover this, and I don't know what they are off the top of my head. [46:08]

Carl: You are right. But I feel like the React core team is perhaps too heavily stacked with scientists and adventurers and there's not enough entrepreneurs and teachers, like we need more who are bringing this knowledge and like workshopping it to say what is understandable? How can we make people, how can we put words to page that permit people to walk away from it with the understanding we intended. [46:15]

And like there's like, they're so busy figuring out what it needs to be that I don't think they're quite investing the time and energy into ensuring that people understand what they intend. [46:44]

And I guess we've said before, I've said this before, in the podcast, that React spent so long Innu this number one seat of Mindshare. Like it spent solidly, I'd say eight years as like one of the top five hottest technologies in general. And so they didn't need that core team labor of figuring out how to make people understand it because there was a legion of community members where, that was how they were doing their competitive advantage. They were, that's they were getting consulting work is by being a subject matter expert on the cutting edge of React. And like, nobody cares about that anymore. Not literally like I care, you care the people listening to this care. [46:59]

Mo: It's not picking people's bills like it used to. And so all of the attention onto ai, so you don't have all of the consultants and all of those people. So it's now the responsibility to react core team to do that. [47:43]

There's a, , there's a person at work who does like technology mapping that is like a little bit more senior than I am, and he spends more time in strategy stuff. So he is more of that entrepreneurial type of person that you're talking about, Carl, and he, talks about like technologies going through this, like these different levels of like genesis, and then growth, and then at the end they become commoditized and like whether we like it or not, react has become commoditized. [47:54]

Like there are. many ways that you can quickly build React apps, whereas like, it wasn't the case several years ago. And so it's it's now there's a point where we need to really document everything and make sure that it's understandable by everyone because there aren't gonna be consultants who you know are gonna be, that you have to pave to do it. [48:16]

It's very accessible to everyone. [48:35]

Mark: my last thought on this topic is that, I don't think the React core team has time to do a bunch of additional documentation unless they, significantly change their priorities and maybe they're not the best people to do it. But I was encouraged by discussions with the team at React Conf for, they indicated they are much more interest, they're very willing to have external community contributions to the docs. [48:37]

Obviously, there needs to be collaboration agreement on what the content is, but they're willing to work with people to get that stuff in. [48:59]

Carl: yep. Interesting. Yeah, I would, I would like to talk more with you about that actually, [49:07]

mark, Cool. [49:11]

Mark: Moving right along. [49:12]

React Native year in review

Carl: Mo can you give us a bit of a recap about React Native this year as our React Native expert [49:14]

Mo: I would love to. Thanks Carl. So let's do our React Native year in recap 2025. So I'm gonna start from January and we're gonna do this very quick fire. And I'll, go over the releases, I'll go over some other significant things that happen in the ecosystem. What I will say is, this is not comprehensive. [49:19]

You can obviously go through the podcasts and listen through every single month, I thought I'd pull out things that were significant enough to me personally. So this is by no means a, prioritization of how important things are. It's just what came to mind. And I'll ground them by the reactive releases that went out during the year basically. [49:38]

More CSS support

Mo: So. January React Native version 0.77. So this one was basically give a high level. There was a lot of focus on styling because CSS is super, super rich in terms of styling that it gives you. And so a lot of effort was put into taking CSS features and bringing them into React Native to help with Layouting, to help with sizing and even things like blending modes, which was really quite cool. [49:54]

So it helped make styling within React Native a little bit more web-like. And that was a trend through a lot of the releases, not just in styling, but in other spaces within this year's React Native releases. Another thing that's worth mentioning was there was a breaking change that seemed to be Initially they thought that it was gonna be quite uncontroversial, which was removing console logs showing in Metro. [50:20]

We'll come back to that in one of the next releases. [50:41]

Expo EAS hosting

Mo: Same time in January, expo launches their EAS hosting. And so this is expos forte into the universal app deployment world. obviously Expo's been pushing universal apps for the last couple of years and they didn't have a hosting solution for it and things like backend routes and so on and so forth to help you build a full stack application. [50:45]

So they launched EAS hosting as sort of a esque competitor for people that want to build mobile and web apps using the expo ecosystem. And also have basic API endpoints and so on and so forth. So that was another thing that happened in January. [51:04]

RN 0.78: React 19 support

Mo: We move on to February, React Native 0.78. And this was big because React Native was struggling, was kind of falling behind the React ecosystem in terms of adopting , the latest major versions of React. So it was on React 18 for a long time. And so, 0 78 in February gave us React 19 support, which, came with a whole bunch of different things, but you were able to finally use all of the new React features, like actions, like the optimistic and so on and so forth. [51:18]

There was also the React compiler and they started to hint that we're gonna have more frequent releases this year. Now the example that I mentioned, or the point that I mentioned around the removing of logs was reverted this release because of widespread complaints because people are used to seeing their logs in Metro and so they added a flag saying that you can now pass dash dash client logs and get back your logs, which was, was much appreciated by the React Native community. [51:49]

Lynx launched

Mo: In March no React Native releases, but the folks at ByteDance released Lynx and links was sort of their internal inner source version of React Native that was very similar to React Native in many ways, but was also quite different in terms of how they handled the internals. And was really focused on, getting a quick time to interactive for a mobile app. [52:18]

So this is what's powering apps like TikTok and so on and so forth. So it was quite exciting to see an alternative to React Native and a different take to building cross-platform native apps that followed React Native very closely. [52:40]

RN 0.79: JSC moving to Community Package

Mo: In April, we had React Native version 0.79, and so I'm gonna just highlight one thing out of this release, which was, and of course there was a lot more that happened in this release, but one of the key things was JS Core, which was the old engine, pre Hermes that React Native relied on, moved to a community maintained package. [52:52]

So. Majority of React Native users didn't really, didn't make a difference to them. But for some of those older apps that relied on JSC, it, it just signaled that the React team was really zeroing in on Hermes as the engine to run React Native apps. [53:11]

RN 0.80: Freezing the legacy architecture

Mo: Then in June, two months after we had React Native versions, 0.80. And so this one was big because the legacy architecture, as they put it, or as how everyone sort of referred to it, the old architecture was frozen. And so this was pretty much in, in this world of making the new architecture, the sort of defacto way at the defacto internals of React Native, this was sort of a big deal because it was basically saying , we are no longer gonna be so supporting the old architecture, and we really want everyone to move over to the new architecture. [53:27]

It's been in the making for years. Let's get everyone migrated away. This was sort of the big news for this release. [53:58]

RN 0.81: Android 16 support for edge to edge

Mo: Then two months later in August there was a release of React Native 0.81. This was mainly focused on Android 16 support because there was some drastic breaking changes in the Android ecosystem. [54:05]

So this was API level 36 for you Android developers. And it supported things like Edge to edge support but it also deprecated things like safe area view because there were better alternatives in the ecosystem that were open, open source and really just made sure that that React Native , was compliant with the latest Google requirements for apps, which was to have edge to edge support. [54:16]

1.0 on the horizon

Mo: Then in September we had a talk from Jorge Cohen, who's one of the engineering managers at Meta in the React Native Core team. And they talked about how 1.0 is on the horizon. So this has been like the brunt of jokes in the React Native ecosystem for a very long time that React Native will never reach 1.0. [54:36]

And so this was a, this was quite fun for us to, hear as a community that, you know, there is a world in which we can reach a 1.0 of React Native. And there are many memes if you search for React Native 1.0 [54:56]

Mark: We're not there yet, but at least we're talking about it. [55:06]

Mo: It's a great, great move, right? Like it's, at least we're talking about it, which is great. a little bit of an anecdote is, I still laugh when there was a a CEO of a company that we spoke to who we were trying to say, you should go to React Native and not build two separate native apps. And he said to me, point blank, that "my friend told me that React Native is so un unstable, it's not even version 1.0." And that still makes me chuckle. How decisions are made. Cool. [55:09]

Vega OS launched

Mo: Same time in September the folks at Amazon lifted the veil on something that they've been working on for a number of years, which is a completely new operating system that is built from the ground up to support React Native. [55:36]

And so they call it Vega Os. I have known about Vega OS for a little while and have been working with some of the folks at Amazon behind the scenes. But Vega OS will power the next generation of Fire TV devices and other devices that Amazon makes. And so this was really quite cool because the only way and the defacto way that you build apps for this new operating system is with React Native. [55:48]

So it's a big bet on React Native's future and long GI longevity as a technology, which was really, really cool to see. And it just shows that this ecosystem is only growing and expanding. [56:11]

RN 0.82: Only new architecture

Mo: Then in October we had React Native version 0.82. Now this one was also a big one in the world of new architecture releases because this was a release where they removed the legacy architecture. [56:22]

And so basically they were saying that this version will only run on the new architecture. You'll need to adopt the new architecture to be able to use it. And they're gonna be removing for future releases. All of the components in the code that rely on the legacy architecture. [56:35]

Expo App Awards

Mo: Also in October we had Expo launching their 2025 Expo app awards. [56:50]

So this was the first time they were doing this, but it was actually quite cool and I think it's notable to talk about it, which is, Expo sort of in, in Apple-esque fashion of, let's do an app awards for the year. They basically opened up nominations for people to, to nominate any apps that have been built with React Native and Expo. [56:56]

And so we saw a lot of cool apps come from different parts of the world and, and basically say, Hey, we use React Native, we use Expo. And so it was a really cool uh, it was a really cool showcase and I think it's a really good collection of really top class well-built, well-designed apps that have been built with React Native and having something like that available as a reference is really cool when you're talking to people about why React Native is a great technology to be building your apps with. [57:12]

RN 0.83: New Devtools - no breaking changes

Mo: And finally, and we talked about it in the new releases going to December, we now have React Native version zero point 83. And so the key things to highlight with this, as we mentioned, is the new dev tools and that there are no breaking changes, which is very, very exciting for the React Native community to not have any breaking changes and have a smooth update process. [57:39]

And so that's the yearly recap for React Native. And I hope it was tac enough and I didn't bore the audience with all of the releases and all of the numbers that start from 77 and go up to 83. [58:00]

Carl: That's a lot of releases! [58:11]

Mark: I would not have known enough to, pull in most of those items [58:12]

Carl: that's a lot of releases. I mean, we got six releases in 12 months, like hot Damn. That's [58:15]

Mark: every two months. That's solid. [58:20]

Carl: Do you know when it was first released? [58:21]

Mo: React Native's. First release was 2015. [58:23]

Carl: Okay, so that's 10 years, 83 versions in 10 years. That's, I guess that's eight per year, so, oh, if they're slowing down, how dare they? [58:25]

Mo: So, so there was a very, very fast start at where very, very like quick, quick releases and then um, it slowed down to several months before there was a release, and now they're sort of standardizing it at a release every two months, which is quite good because, you know, that's something that's more maintainable and manageable and makes it less painful to do the updates. [58:32]

So if I've done my math right here, if we do the a hundred divided by 83, that's 17 divided by six releases. So we're talking three years before, if they just continue on the succession, 1.0 might be there in 2.8 years. or they do 0.1 hundred and then we all have a good laugh. [58:53]

Carl: Yeah. I'm just pulling it up real quick. Version o one initial public release was March 27th, 2015, and they had version 0.10 out by August. So yeah, that's 10 releases in like three months. So that's, entirely different type of release. Yeah, man. They're on version 0.40 in 2016, like a year later, [59:10]

that Doesn't really mean anything, but that's just some fun uh, It's interesting this, it's professionalizing, you got this prototype that, oh, look at works. [59:32]

Oh, it's broken. Oh, it's broken. Oh, it's broken. it's like a stable ish product with a release schedule and all that kind of stuff. It's cool to see. [59:40]

Mo: I wouldn't say stable ish. I'd say stable. don't undermine the community like that, Carl. [59:49]

Carl: According to SemVer, a zero major version you're you are allowed to release breaking changes without a major revision. [59:54]

Mo: you're telling me the CEO was right all along. It's not stable until it's 1.0. Right. [01:00:01]

Carl: I'm just saying. technically that's what the contract says. [01:00:05]

Mo: Technically, that is what the contract says. You are. You are absolutely right. [01:00:08]

So yeah, it was lovely as always. Have a lovely holidays to everyone who's listening and enjoy whatever festivities you're celebrating and we'll see you on the other side. [01:00:12]

Mark: you very much, Mo. Merry Christmas and happy holidays to you too. [01:00:22]

Carl: Cool. Okay, wonderful. [01:00:25]

React year in review

Mark: Semi rapid firing our way through the myriad of stuff we have left. [01:00:27]

CRA deprecation, new install docs (Vite!)

Mark: We, we started the year in React land with React 19 had just come out in December of 24, and that's when I noticed everyone's CRE React app projects were breaking. And I will still take 75 to 80% of the credit for the actual deprecation process happening here. [01:00:32]

Theo had put up his post complaining about the docs a couple years ago. Dan had written his response saying, don't use CRA, but I take credit for complaining loud enough for noticing the problem and complaining loud enough and filing the issue and pushing them to make this happen, which is also how we actually ended up with the React Docs actually now listing Vite, RSBuild, and Parcel, and do it yourself tooling as a valid, officially documented, supported way to do a React project, not just use a framework. [01:00:51]

So I actually legitimately take credit for that one. [01:01:26]

Carl: I give credit for that one. Yeah. yeah, we, so we start with Create React App deprecation, much better new docs. [01:01:28]

Styled Components Deprecated

Carl: We move into styled components getting actually officially deprecated. [01:01:35]

Mark: That had kind of been on the horizon because of the changes with server components and not having contact support in a server components environment. Which, kind of also goes back to the, the mental model and like, even if they're not pushing server components, technical changes and having to keep up change on the ecosystem [01:01:38]

Releases: 19.2 (Activity, useEffectEvent), Compiler 1.0

Mark: So the, big react release this year was 19.2 in the fall, which included the, the final actual release of the activity component previously offscreen, and the new confusingly named use effect event hook. [01:01:59]

And then along with that at React Con, the react compiler finally hit 1.0. It had been an RC for a while and now it's finally officially, officially available. , it'll be still very interesting to see what the adoption rate is on that. I, I have no metrics. I've not looked at download numbers or anything. But I, feel like it's gonna need official integration into build tool chains to really start to take off, otherwise it's still kind of piecemeal. [01:02:12]

Research: View Transitions canary, perf, concurrent stores, “throw a promise” deprecated (but not merged yet)

Mark: On the API research side we had the canary release of view transitions. We've got the ongoing concurrent stores work that I am very personally excited about and involved in. We saw a mention of killing off the existing throw a promise method for triggering suspense now got the use hook available. [01:02:39]

“Async React” and the ecosystem

Mark: Also at React conf Ricky Hanlon's talk on Async React, I think was one of the biggest pieces of messaging from the React team. We've spent all these years building the new features, suspense, transitions all the other stuff. What does it mean in terms of coherent usage? How does it change the code that you'd write versus a 2018 ERA app? [01:03:00]

What does it mean in terms of, well, you know, ecosystem libraries like component libraries and routers and state management tools ought to just do the transition calls for you so you don't have to write them in your own code. I think we're gonna be digesting the implications of that one for quite a while. [01:03:24]

React Foundation

Mark: Then at React Conf, we also had the mic drop announcement of the React Foundation that reacts ownership is finally after years and years of speculation. And boy, I wish they would actually moving from meta to an independent foundation, part of the Linux Foundation, with multiple companies providing financial support, board governance, and technical support as well. [01:03:41]

And then I, I found out some more details from Seth Webster at React Summit that, they'd been working on this for like four years and had even held off on trying to do the announcement for a while because they wanted to make sure that they were working on they, that, that their internal day-to-day process of development was essentially beta testing the process that they're going to use as things become more public. [01:04:10]

And the comments that down the road they want to make the development of its of react itself fully public, the weekly meetings bringing back RFCs as a means of getting proposals. So the development of React is going to change significantly as we go forward. [01:04:34]

React growth skyrockets

Mark: We've also had all the rise of all the different AI powered build tools, which are using react by default. 'cause that's what LLMs are trained on. A lot of that is based on Vite of course, next V0 is using next, but Vite is the default for a lot of these. And so the growth charts for React are absurd. [01:04:53]

Carl: It is absurd. there's a visible inflection point. I don't know. It's, it's funny, there's actually like two— [01:05:13]

Mark: like January this year is when all the AI tools took off. [01:05:18]

Carl: Yeah. It's funny 'cause there's a certain, very consistent, I would say exponential growth curve from like 2015 to 2023. And then it's funny, there's like a little kink down. Like stops growing quite as quickly until January of this year and then it fucking rockets. So that, I don't know. That's interesting. [01:05:21]

So I wonder if people stopped, like the pace of new projects actually got hampered by initial AI tools. 'cause maybe I, I feel like people may be, I dunno, this is speculation, but I feel like people wanted them to be able to do more than they could and actual as evidenced in download numbers, pace of development slowed and maybe they got better. [01:05:39]

I don't know. This is fun. It's just interesting to look at some data and see some patterns. [01:06:01]

React Router RSC support, TanStack Start WIP RSC, Waku

Mark: As mentioned earlier, we're seeing other tools working on RSC support, and I think , the biggest one is React Router officially bringing out RSC support in framework mode. I think that's, gonna be one of the biggest pieces of, of adoption outside of next we've seen a bunch of other frameworks with RSC support in some form Parcel Redwood walkout, et cetera. [01:06:05]

Tan Stack start is teasing RSC support, and I have seen Tanner gave me a demo and I think it's gonna blow people's minds once that officially comes out just because it's so different and yet it works. [01:06:25]

Dan’s RSC explainers (he had a bunch of things to say)

Mark: Dan went on a whole series of blog posts back in the spring where he put out like 10 different posts trying to explain our server components from first concepts, different mental models. [01:06:37]

Here's another explanation. Does this explanation make rses click for Is it a GraphQL replacement? Is it a backend for front end? Is it serialized? JSON and. I would love to see a lot of these, like some form of this added to the docs somehow. [01:06:49]

Remix v3 (not React but relevant)

Mark: We had the React Router remix team, Ryan Florence and Michael Jackson teasing us for months about what remix V three would look like. [01:07:07]

Was it going to be a fork? WW would it use preact? Would it be a fork of preact? Iframes something somehow. And then they eventually had remix conf and dropped the details. And it's a weird hybrid mix of react and backbone and a few other things mixed together. It's clearly not, it's literally not react, but there's a lot of overlap. [01:07:17]

No idea how that one's gonna get adopted, but it's clearly like they clearly have their idea and they're going with it. We had numerous arguments over directives and bundlers and mental models and complexity. Use client use, server use, cash use, use, use, use, use, use, use, use, use, use, use. Yeah. [01:07:43]

Mark went from frustrated (CRA) to excited (ReactConf, foundation, team efforts

Mark: And finally, speaking purely for myself, I started the year feeling very frustrated. I, put a lot of emotional energy into like the Create React app, deprecation and trying to convince the team to change the docs. I even spent a while writing a blog post that I fortunately never actually published because it was too ranty and would've caused problems. [01:08:08]

I was very frustrated with the direction of React early on, but I can say that React Con completely changed my outlook , on where things are going. The technical progress is great compiler and 19.2 and performance research, that's all cool. [01:08:30]

The foundation I never saw coming. And the fact that they finally were doing it like even, like, even just the, the slide, seeing them say the words React Foundation tells me a lot about the intent and what been trying to do. And it, and like, it was only afterwards that I got a sense of how many years they've been working on this. [01:08:48]

And then on an individual level, like I got to talk to several React team members who basically said, we don't get any credit for doing community rated related things in our meta performance reviews. And so things like. The Async React working group and, doing, like a lot of the other stuff that they're doing shows me how much they care about keeping React, working for the community. [01:09:09]

, I've got my gripes, everyone's got their gripes. Nothing's perfect, but it's not for lack of effort and care on their part, and that's the part that actually encourages me the most. And so, the react to shelf vulnerability is a big bummer and it's gonna cause problems. I, Carl and I were briefly chatting with Ricky and as Carl said, hug ops. [01:09:36]

I, feel a lot of sympathy for what they've been having to go through the last couple weeks. But yeah, even with that in mind, I am actually excited and positive about the direction of React itself going into 2026. [01:09:59]

Carl: Yeah, I think I would agree with that. I, I read your blog post that you never published. I printed it like an attempt at like, editing and maybe salvage parts that were less ranty and, you know, salvage seems mean, not salvage, but help process. And yeah, it was not inaccurate. [01:10:12]

So , I would agree. I I never saw the foundation coming. , it's like retroactively, I don't know, validating or like. It's good to know that they were thinking about this for a long time. I relate to the thought of exploring an idea and then realizing like, "oh, in order to do this, , in order to accomplish our goals here, we have to do this hard project first." That rhymes with a lot of things I've done in my life. [01:10:29]

And so, like fuck yeah. For putting the work in, like working for several years to like test the process and yeah. I mean, I guess we'll see, Remains to be seen quite how successful they were at that. [01:10:56]

Mark: But I absolutely respect the intent and the effort to make that happen. [01:11:10]

Carl: yes, it is a massive amount of effort. Like, it's tough. Well, I'm excited to see how that goes. [01:11:14]

Yeah, it's been an interesting year. I don't know. I'm trying to think of how to like summarize this year. ' cause like we've been talking about server components for a long time. I still don't have firsthand experience with them. [01:11:19]

Mark: neither. 'cause I don't write, I don't write front end apps these days. [01:11:33]

Carl: Yeah. I just saw somebody chatting about maybe I need to just pair program with Effect, so I understand it and I was like, Ooh, you're the person who talked about RSCs and like, maybe we should just do a knowledge transfer there. So maybe I'll do that. But yeah, it's been quite a year. [01:11:36]

I don't know. In some ways it's like legitimizing the fact that they've had a major vulnerability in React is like somewhat legitimizing, like, welcome to the party, welcome to the list of world class engineering projects that have caused security people a huge headache for a day. And the rest of the ecosystem headaches for months. [01:11:51]

But Remains to be seen. If it actually is good, I guess we'll just keep paying attention to it and talking about it on the air. [01:12:12]

⚡ Lightning round ⚡

Mark: All right. Well, how do you feel about just lightning rounding everything from here on out. [01:12:19]

Carl: Let's blast through it. [01:12:23]

TS 7 progress update

Mark: One of the big announcements from earlier this year was that ts was being ported to go and it was gonna be released as TypeScript version seven. And so the TypeScript team put out a big update post, basically saying that there will be a TS 6.0 based off all the same current code base. [01:12:24]

There will be a bunch of deprecation and strict mode changes and other, like, we think modern type script should be written this way. Settings changes. And then there will be no TS 6.1. The next big release would be TS 7.0, the native built. So great to see both progress being made and that this is happening and that, , we have a direction for all this stuff. [01:12:40]

Carl: Very cool. Yeah, quick roundup of some GitHub, this all fits under a Microsoft umbrella, funnily but NPM, GitHub, some user experience and whatever stuff. [01:13:07]

NPM classic tokens revoked

Carl: So, NPM, after several vulnerabilities actually revoked every classic token. Classic tokens are no longer valid at all. Which should make generally, like they had to do that because of all of the vulnerabilities that were, all of the phishing attacks that we're targeting well-known maintainers. [01:13:17]

So like this needed to happen because it had become clear that NPM maintainers had been hacked in a much, much greater quantity than had been, than those tokens had been used. There was a follow-up attack like two weeks later because, like GitHub and NPM, GitHub, who owns NPM (and is owned by Microsoft) put out a notice that they were going to revoke all of the tokens because of this problem, which is wonderful, and you need to give people time to respond to that and update their code and prevent downtime and whatever. [01:13:37]

But it also gives the attackers who have those compromised tokens, a window of time in which to use them. And so that did happen. They did in fact, use more of the tokens that they had previously collected, I think like one day before they got invalidated. So, eh, that sucks. But should stop happening. [01:14:08]

This is a huge positive change. Hopefully this means that 2026, we will not continually be reporting on yet another new vulnerability in NPM publishing. Maybe. [01:14:25]

Also you should consider using PMPM because it lets you do things like minimum delay time before you start using a new version that was released and also lets you, I think by default it does not run post install, or there's various scripts that open vulnerabilities that PNPM does not [01:14:37]

Mark: I, I actually went through what week and a half ago my own Redux Library Publishing workflow. I, I'd always done all my releases locally and we had set up a GitHub actions workflow a while back, so some of the other maintainers could publish more easily. Turns out those releases got tagged with Trusted, and then I did more releases locally that were not, and we actually had a couple people complain that PNPM said, oh no, Redux Toolkit isn't trusted anymore. [01:14:55]

complaining about that. So I actually, with that and with the token deprecation, I actually went through a week and a half ago and did a bunch of GitHub actions hardening changed some of the publish workflow and figured out, okay, what I can do is I can use Release it to do the tag and push, and then I will actually kick off the publish itself as the a, the workflow in the repo. [01:15:25]

And so then it's actually trusted and tagged according, and flagged accordingly. [01:15:51]

Carl: Interesting. Oh, that's funny. That's deep in the weeds. [01:15:55]

Mark: Basically, I'm not doing the literal publish step for my own machine. It's happening from within GitHub actions. [01:15:58]

Carl: Got it. Cool. Interesting. Yeah. [01:16:04]

GitHub Actions planned work

Carl: Well, speaking of GitHub actions, Jared Palmer, who is a, like pretty, he's a huge name in React. [01:16:06]

He did formic, he did turbo repo. He did turbo pack. He worked on V0. [01:16:11]

I actually did a job interview with him circa 20, oh my God. 17. And yeah, holy shit. Jesus. And he was, he is genuinely a very sharp dude, so I am not at all surprised to see him. [01:16:17]

Take the reins in a more serious capacity. Like he was doing, like I met him when he was working like at his dad's business, and then he did his own business, and then he did like three more businesses before working for Vercel, and now he's fucking PM of one of the most visible parts of the developer world. And like yeah. [01:16:31]

Earned it so thoroughly earned. Fuck yeah Jared. And I love this because he's immediately coming through and talking about a bunch of things that I've wanted to see in for a long time. [01:16:49]

So like, GitHub actions, they're great, but they're, they all, they're also awful. They enable so much great stuff and I hate using them. He was responding to uh, the Primo Gen who was a very prolific tech YouTuber as well as uh, Jamon Holmgren, who, fun fact, previously sponsored this podcast, with a really long, basically a blog post on Twitter with citations talking about the work that they're looking to do to make GitHub actions better in general. [01:17:02]

So that's really cool. Like, I'm gonna see if I can quickly summarize some of this. Eh? Oh, this is like, no, these are pretty deep [01:17:31]

Mark: in in, in the weed stuff. But they, intend to do a lot of stuff to make GitHub actions better at a technical level. [01:17:38]

Github Action pricing change and immediate about-face

Mark: Unfortunately, shortly after that, they also announced a price increase for both standard GitHub actions and cases where you're using GitHub actions to kick off your own job runners. [01:17:44]

And the the reasons listed were understandable, like it takes money to run the control servers, even if they aren't the ones executing the actual jobs. But the way they announced that this got a bunch of blow back, and so like 24 hours later, they're like, Nope, nope, Holt revert, undo, cancel, cease desist. [01:17:58]

Carl: yep. Which again, like I gotta say, Jared Palmer was the one messaging that, and I think he did a good job. Like, he says, "we missed the opportunity to gather feedback from the community ahead of this move. , we'll learn and do better." And like, we were talking about, like not being defensive earlier. Like, this is a great example of like not being defensive, just saying like, yep, here's what we did wrong. We get it, we're gonna do something differently. Love it. great. [01:18:19]

Yeah, on the pricing there was a lot of, you know, low effort punches below the belt in the vein of like, "how are they gonna charge for self-hosted runners?" [01:18:42]

And it's like, well come on. Like, alright. It's not their CPU time, but like, you're taking advantage of. A lot of other infrastructure to get to the point where that runner is executing on your code. Like sure, the marginal cost. [01:18:53]

Mark: Free infrastructure will always be abused. [01:19:07]

Carl: right, right. Anything always has two things. It's got the, the marginal cost of running it, and then it's got the capital expenditure of building it and they built the fuck out of this and they're still building it. [01:19:09]

So like, no, it's not free. It's not free just because you are covering the marginal cost. So, settle out, settle down. If somebody says this should be free because I'm running it on my server, like, chill the fuck out. You don't understand how business works. You're too narrowly focused on the one technical aspect. Broaden your perspective. [01:19:19]

Stacked diffs proposal in the works?

Carl: Anyway. Last thing on GitHub. So excited. One more thing from Jared Palmer. Yay. They are sending out a proposal for Stacked Diffs. If you're not familiar with, if when I said Stack Diffs you didn't go, "oh my God, they're doing it," then, stacked diffs is a way of communicating to GitHub that this PR depends on this PR, which depends on this pr, so you, you can do this yourself. [01:19:40]

You can branch off main, do some work, push open a poll request, and then from that branch continue doing new work and push another [01:20:05]

Mark: On a third, on a second branch. [01:20:16]

Carl: Right, based on that first branch. So like, you do, let's say you commit four times and you push that branch, then you do another branch that includes those four commits that are not yet merged yet and do four more commits and you push that and make a pr. [01:20:18]

, that is my preferred way of working. I really like saying, "I made these changes. They're ready for review. I'm gonna keep using them locally while review happens, and CI and cd, all the validation steps, but I'm gonna keep using it." So my next change is I don't have to reintegrate them after this merges. [01:20:33]

And it is a really frustrating dance to do on GitHub because like, I, I also like to do squash and merge. So that I have like, great, here's the record of every change I made in the pr, but I only care that about the one higher level change. It's, I'm thinking about it in a different level of, of abstraction after it merges [01:20:55]

Mark: and then when you merge the first pr, the four actual commits get squashed to a new commit. And then the second PRS branch now has no relation to the history. And how do you keep track of it? How do you update the second PR to now point to main da, da, da, da. [01:21:15]

Carl: And in my experience, I have about a hundred percent incidents of merge conflicts after that, because they're technically different. Commits Git does not know that they are the same changes. It just knows that two branches touched the same lines of code with different commit hashes. So like, I don't know, that's a conflict. You gotta fix it yourself. [01:21:30]

So, basically it just sucks. You have to go through, like, you have to like check out the branch in your local computer [01:21:51]

Mark: Reset it, re push, something. [01:21:58]

Carl: Skip the commits that got squashed, push that, check out the next branch that was based on that branch. You just now updated and pushed and like, it was just a really manual dance of going through every single time. [01:22:00]

And I, that has been my preferred mode of working since 2016. Like stacked diffs is a term that I have used to describe my workflow for close to 10 years at this point. And people have been demanding it on GitHub for almost that long. So like, to see this actually happening is like, I feel like the Rand Paul gif it's happening , I'm so excited. This is so good. [01:22:12]

Well, I'm excited to see the possibilities. We'll see what actually happens. [01:22:38]

Anthropic bought Bun

Mark: And then one last ecosystemy thing, and it's amazing that so much happened this month. It's almost an afterthought at this [01:22:42]

but a, a very small company called Anthropic bought a little known tool called bun. [01:22:49]

Carl: Woo. Yeah. Great. there's some chatter about like, what, this doesn't make any sense. But apparently Anthropic has invested pretty heavily in using Bun in Claude code. And I don't know exactly what precipitated this deal at this time, [01:22:57]

Mark: might have even just been like literally like them chatting in person or something. [01:23:12]

Carl: actually, if I recall correctly, the, the Bun blog post actually goes pretty, it speaks pretty candidly about why they did this. And the, the TLDR is that they are a venture backed business. They took funding and that means that they need to return a multiple to their investors. They need to exit as a business, they need to provide liquidity to their investors at a multiple of what they took. [01:23:16]

Which means either building a business that makes enough money that people value it higher than what it was created for. Or you build something valuable enough that a larger business that is much larger and successful and producing revenue and whatever sees you and goes, we need this. We need this so badly, we're gonna buy it from you and it's ours now. [01:23:39]

And so that's what happened. This was an acquihire situation. Bun did not have revenue. They did not have a business plan. They did not have a path to revenue or a path to a business plan. The closest they ever had was sell one day. [01:24:02]

And I think that made a lot of sense in 2022, and it makes a lot less sense in 2026. [01:24:14]

So I think it was the writing was on the wall. Presumably there was some kind of like funding milestone or, runway check-in that they did and we're like "uhoh" and chopped it around. Got acquired. Love it. [01:24:20]

It's great. I am happy to see open source capture value. Open source is really bad at getting anything close to the value it generates in the form of money for its maintainers. So I'm happy to celebrate any instance of that happening. I hope it will happen for more people. I. Cool. [01:24:32]

SVG Clickjacking (SVG filters as logic gates??)

Carl: I wanna talk about this. SVG ClickJacking. This is really [01:24:52]

Mark: Go for it! [01:24:54]

Carl: Who published this? I wanna credit them by name. I guess they only introduce themselves as Lyra, so that's all I will name them as. But they, they appear to be doing, they appear to blog about some security things in general. [01:24:55]

And this is like such a fun exploit. This is taking [01:25:08]

Mark: It was an insanely good post. [01:25:11]

Carl: yeah. Such a good post. Like I talk about how I love reading technical write-ups about things, and this is like a legitimately novel exploit technique using a tool that I would've never considered to even have a risk of an exploit of this caliber. [01:25:13]

Anyway, so it's, they're using SVG filters, which let you do some fancy visual effects on your website in, in general, [01:25:31]

Mark: like calculating pixel colors, basically. [01:25:40]

Carl: the first thing they do is like, "oh, we can use this to make liquid SVGs" because it lets us do fun, like shimmery effects because of how you can access the pixel data on your webpage on. And like, , it's rare. There are not that many tools on the web, like not many platform features enable you to retrieve pixel values of the rendered page. [01:25:43]

Like that's not trivial to do elsewhere. , and anyway, summarizing all of this is to say that an old vulnerability known as ClickJacking, where, it used to be that like in the nineties you would go to click like an okay button or like a download button, and secretly there was a layer on top of that that you couldn't see that was, injected by like a malicious advertisement and you thought you were clicking download on this thing, but you were actually clicking download on malware. [01:26:05]

And that's been pretty effectively defended against for 15 years, I would say. Like iframes got, really the reason iframes are so clamped down is because there were a bunch of possible ClickJacking attempts like attacks using iframes. And so this is a new way, the, the way that SVG filters let you inspect pixels and modify, modify the visuals for a certain output. [01:26:34]

Lets you layer things over in ways that you couldn't do be, you can't do any other way. So it's a, it's a, an old attack that I had generally considered to be like, I don't think about this anymore. It doesn't happen in my experience. Like, I have never encountered this professionally. Here's somebody doing a writeup explaining how to do it with a brand new technology. [01:27:01]

This is a really, really fantastic writeup. I would absolutely recommend reading it because it's like fun and silly and genuinely cutting edge and cross domain because it's really advanced security stuff using on visual things that I would've never thought had a security [01:27:19]

Mark: The phrase that got me was, they were treating pixel analysis and creating like and NAND or Logic Gate equivalents out of SVG filters. [01:27:36]

Carl: Yeah, right. Oh, oh my God. [01:27:47]

That's crazy. [01:27:50]

With demos in the, blog post. [01:27:50]

Yeah. like not only is this a really interesting security attack, and not only is the writeup really effective, but it's also a really technically well produced blog post. So, I don't know, just like this is, this like, came outta nowhere. I've never heard of this person before. [01:27:52]

It's like a nineties esque style and everything, it's a really phenomenal blog post. Highly recommend. Anyway, that's way too much time for one So much for lightning, this stuff. [01:28:06]

Mark: Okay, moving right along. [01:28:15]

Dan Abramov’s RSC Explorer, accompanying blogpost

Mark: Dan Abramov has put together a server component explorer that lets you see examples of an app and the data and the progression of the loading. And he also put up a blog post explaining why he built this and how it works, and some links to example demos as well. [01:28:16]

Instant-loading Github repo explorer using RSCs: Without the blue bar

Mark: in speaking of meaningful uses of server components, somebody built a clone of the GitHub repo code Explorer view entirely using server components. And I clicked through a couple repos like the react repo using this viewer. It loaded instantly, like I stunned at how fast it was in comparison to like the actual GitHub Like that right there is actually a powerful example of why server components could be useful. [01:28:36]

React Router’s Take on RSCs

Mark: And then Kent C Dodds put up a blog post with his thoughts on why he likes React router's approach to bringing in server components. [01:29:10]

How AI Coding Agents hid a Timebomb in Our App

Mark: Changing topics. An author who I had not seen at all, but I, I looked up his name as Andrew Patton, put, put up two very good blog posts just like within the last week or two. [01:29:19]

The first one was titled How AI Coding Agents Hit a Time Bomb in our App. And the actual technical problem in here was that they were using the new activity component in their UI and activity does rendering in the background. And AI made a tweak to change something and it ended up doing recursive rendering of their footer component. [01:29:29]

But because the footer component rendered the footer component rendered, the footer component rendered the footer component. This was all happening invisibly in the background until the app ran out of memory and exploded repeatedly. And so it's both interesting in terms of, here's a real world use of activity and also here's a problem that can come up and, huh, wow, background rendering, huh? Okay. [01:29:55]

Carl: I'll say before we move on from that earlier I talked about how React was basically a scheduler. , this is why. Like, they wanted to avoid tearing and crashes and things like that. they said in the blog post that they took out the activity wrapper in it and it instantly crashed. [01:30:18]

Like, because it's recursively rendering out of memory immediately. But with activity, because React is such a good scheduler, it managed to stay functional for minutes before crashing because it's evaluating what resources are available and doing work only when it doesn't interrupt the user. So what naively is an instant crash, sustained along for minutes because React is such a good scheduler. Anyway, it's cool. [01:30:32]

React Compiler’s Silent Failures (And How to Fix Them)

Mark: The same author just put up a post a couple days ago talking about how they've been using React compiler in production for a while, and how the compiler does have some limitations in terms of bits of JavaScript syntax or patterns that it struggles with. I think one of the, one of the examples they gave was if you destructure props into your component, but then you reassign a different value to that same de structured variable than the component, the compiler will give up and bail out and not optimize that component. [01:30:58]

It was a good look at using the compiler and practice, like, not even the focus on the performance, but what is it like behavior wise? [01:31:28]

Great history of web dev: 30 Years of
Tags

Mark: I've always been a very big fan of history stuff. That's kind of my shtick at this point, and. Someone put together a really long, really good post titled 30 Years of BR Tags and it's, a look back at like all the history of web development from handwritten HTML and Pearl and CGI bin to Web 2.0 and PHP to, Java stacks to react and next and everything else. [01:31:36]

It's great to see just the history of all the pieces and the mindsets and the problems and the tools that we've invented to try to solve all those problems in one place. I, I love that kind of post. [01:32:04]

Carl: Yeah. [01:32:17]

Nadia Makarevich’s latest deep dive: Bundle Size Investigation

Carl: And uh, Nadia Makarevic did a really good blog post talking about bundle size investigation. This is like near and dear to my professional career. [01:32:18]

have done this so many times because If you don't think about bundle size, then it will cause you problems. This is a really good, like up to date explanation of the problem. You'd naively set up a project and add a forum and oh my God, it's over five megabytes, uncompressed, and still a megabyte after you compress it. So, like it's really , a downside of the JavaScript ecosystem, having really good package management is that it's really easy a lot of code. [01:32:26]

So you have to consciously think about how to prune the code you're using. I feel like I could have read a blog post like this in 2016. I certainly did. It's got a good bit talking about analyzing bundle size and using these visualizers to show, to reveal what is contributing to the overall size of the bundle in a nice visual hierarchical way through like nested boxes, tree maps, flame graphs for, I guess that's more execution time, stack. [01:32:55]

Yeah, really good. If you, I don't know, want to be thoughtful about how much data you're sending, this is a good technical writeup of an expert doing it. [01:33:25]

Extensive ES2026 feature preview

Carl: Cool. We've got a big feature preview for ES 2026. This is an article from the New Stack, which is a, it feels like a tech journalism outlet in a way that is not common at all. So, uh, yeah, I appreciate them. [01:33:35]

They put out a, a post talking about ES 26 solves JavaScript headaches with dates, math and modules. [01:33:48]

So love that. I have problems with dates, math and modules all the time. I need to, well, I don't, I'm not finding an actual list of things that will be coming out. I guess they've got like a, a better precision for summing values and math tools. [01:33:55]

Mark: Temporal is the big one. [01:34:12]

Carl: I am excited for temporal. I'm currently running into a problem where locally when I do Date.now() I get something in my local EST time zone. But all of the database things are in UTC. So it is, there's, it thinks things are happening at a five hour offset from when they are, which won't happen in production. And that's an example of how JavaScript sucks at dates. [01:34:14]

So I am excited for temporal because date.now should not always rely on your systems time zone. We need a way to encode time zones and date objects and JavaScript. We need it. It's so painful. So yeah. Exciting. Hopefully we'll get that. [01:34:36]

React reconciler for Blender 3D

Mark: Recently mentioned examples of people doing someone did a React reconcile or for the Dear Image gooey tool that's GUI is for c plus plus that where, where everything gets redrawn, every frame. Meanwhile, someone did a React renderer for controlling blender with react. I think this is als. [01:34:53]

Looking at the examples appear to be written in closure or closure script instead of JSX. And I think I've seen some posts from this author where they've previously talked about using react from closure script as well. So more examples of things you did not know you could do with react. [01:35:13]

Carl: Love it. [01:35:30]

The “why” of React Fiber

Carl: I forgot we had this in the document, and I love that I basically said some of the things from it earlier. But somebody tweeted about react fiber and it's just a really good post. , it's very long. It's very like, casual and silly [01:35:31]

Mark: and blog, post in tweet form. [01:35:46]

Carl: Yeah. But I, I like it. I'm gonna read some passages. [01:35:49]

"React Fiber is honestly one of those things that people think they get until they actually look under the hood. And then suddenly the whole thing feels like some alien technology living inside JavaScript. Everyone parrots those same cell lines, like react, like fiber is the new Diffing engine, or fiber is concurrent rendering. And it's just so much more deeper and more deranged than that." [01:35:52]

Like yes it is. It's a fucking scheduler! Like who re implements a scheduler? It's, you should never do that. There's always better. There's always more robust battle test and schedulers. That's like some core compiler interpreter, computer science degree kind of stuff. Like don't re-implement those. Those are the foundations. [01:36:09]

Mark: The other way to look is they basically reimplemented a JavaScript execution stack. [01:36:28]

Carl: Yeah, they literally did that. Like I, I've seen people complain about how like sometimes when you're debugging React stuff, you can't use certain developer tools because React manages its own stack. Like [01:36:32]

Mark: Boy, can I tell you about that one, thank you very much. It's what I've done at Replay for the last few years. [01:36:46]

Carl: right. Like it's literally duplicating logic that like V eight or, I don't, I don't remember any of the other runtimes off the top of my head. [01:36:51]

Mark: Monkey, JSC. [01:36:59]

Carl: Thank you. So like it's re-implementing things that every other JavaScript app gets for free from the runtime environment that it's executing in. But because React transcends individual runtimes, they need to re-implement that themselves anyway. It's fascinating. This is a good little reminder that like there be dragons in this tool that we use constantly. [01:37:00]

Async React articles from Aurora Scharff and Jack Herrington

Mark: And finally at the two hour mark in this podcast. Thank you for those of you who have stuck with us. Ricky Hanlon's talk on Async React from React Con, I think was one of the biggest pieces of messaging from the React team and showing us where React has arrived at and where it's going to go in the next couple years. [01:37:21]

And Aurora Scharf and Jack Harrington have both done a lot great work in learning and teaching a lot of React concepts, right? Aurora has done a lot of conference talks and blog posts on Modern React features, suspense, async behavior, et cetera. And so they, they both put up blog posts on Blog Rocket within the last month or two talking about modern async React and what does it look like? What are the primitives, how do they fit together? How does this actually improve your code base? And what, why should you be using these things in your apps? [01:37:42]

And with that, I think we may finally, finally be done [01:38:16]

Carl: we're done. We're done. We did it. We did two hours of talking about React and by God we got it. [01:38:20]

Mark: Was, was this ever in doubt?? [01:38:26]

Carl: I mean, no, it's, yeah. This was good. I, I'm, I'm happy with this one. was good. Felt like a good chat. [01:38:28]

Thank you everyone for joining us. Even I, I can't believe we still have what, 10 people here listening to us do appreciate you, like genuinely. [01:38:34]

We will be back next month, I guess, in like six weeks at time of recording. But yeah, we'll be back here on the stage, back in your podcast feed just as soon as we can. And happy holidays. Merry Christmas. If you celebrate. Happy Hanukkah. If you, that's what you celebrate. [01:38:43]

Mark: Happy holidays folks. Thanks for listening to us. Thanks for being part of React Flux and part of the React community, and we continue to hope that hearing the three of us up here ramble is informative and provides value to you as a professional developer or non-professional developer as the case may be. [01:38:58]

Carl: Hopefully it's, I don't know, entertaining. We're, we're some fun personalities. We can be, we can be fun and useful. [01:39:14]

Thank you so much. If you see anything that is newsworthy that you think we should discuss let us know in the #tech-reads-and-news channel here in Reactiflux. [01:39:20]

Or you can send me an email at hello@reactiveflux.com. I read everything that comes in, so if you send it, I'll read it. This is a show that you get value from and wanna support. Best way to do so is by submitting a review on whatever platform you're listening to us on, and tell your friends and coworkers about us. [01:39:27]

Go to a meetup, say, "Hey, I like this podcast." Awesome. Thanks so much. See you next month. [01:39:42]

See you year. [01:39:47]

TMiR 2025-11: Cloudflare outage, ongoing npm hacks, React Router is getting RSCs

Reactiflux — Tue, 25 Nov 2025 16:00:00 GMT

[00:13] Intro
[01:00] New releases
- [01:04] BetterAuth 1.4
- [02:47] Immer 11, RTK 2.11
- [06:00] Storybook 10
- [06:22] 0.1 version of Remix team’s “event interaction” package
[08:04] Main content
- [08:08] Ecosystem panel discussion of React Foundation at React Summit NY
- [14:46] React Concurrent Stores: Polyfill, React-Redux POC
- [17:52] React Router and transition usage
  - [18:08] Matt Brophy and Ricky discussing nuances of behavior, use with React Router
- [22:53] The State of TanStack, Two Years of Full-Time OSS
  - [25:57] TanStack DB 0.5
  - [31:01] Tanner teasing a WIP TanStack Start RSC implementation
- [32:25] State of the web ecosystem
  - [33:13] Cloudflare November outage postmortem
  - [36:10] "What if people don't want to create things"
    
    [39:39] “When Everyone’s a Developer, How Do We Promote the Web Platform Over React?”
    
    [45:53] Related, “Dead Framework Theory” from last month
  - [48:12] Alex Russell’s latest stats on web devices and network budgets
  - [51:48] Npm attack, Shai-Hulud round 2
    
    [52:06] Analysis of its evolution in code from Sept
    
    [55:23] Our plan for a more secure npm supply chain from September
    
    [55:29] NPM update on token management changes
[55:34] ⚡ Lightning round ⚡
- [55:38] TS 6.0 hopefully Feb 2026, 7.0 (native) soon after (more details in the TypeScript.fm podcast)
- [56:03] Latest TC39 proposal updates
- [56:32] Chrome (and other browsers) wants to remove XSLT from the web platform
- [57:14] “Your URL is Your State”, and David K’s “Goodbye, useState” talk
- [57:46] Aiden Bai’s “React Grab” util
- [58:39] Creating a custom Node module loader to import from Bittorrent
- [59:22] Ryan Carniato’s stream on researching “async signals”
- [59:33] Details of building Node’s TS type stripping support
- [59:58] The Web Animation Performance Tier List
[01:00:14] Conferences (React, Javascript)
- [01:00:22] CFPs
  - [01:01:01] React Paris (Also a community survey)
  - [01:01:12] JSWorld CFP closes Dec 31, notifies by Feb 1
[01:01:18] Ending

2-vcarl: Hello! Thank you for joining us for the November edition of this month in React. As we recap what's going on in the React, React native and web ecosystems, we're coming to you live from Reactiflux, the place for professional developers using React. [00:00:00]

Intro

2-vcarl: And I am Carl. I'm a staff product developer and freelance community leader here at Reactiflux where I do community programs like these events and build tools to help keep the community operating. [00:00:13]

1-acemarke: Hi, I'm Mark. My day job is working at Replay.io and doing various time travel debugging and information architecture things outside of that I, I work on Red Ducks. I complain about the React docs and I collect links and I go rewrite libraries, Limmer. [00:00:22]

2-vcarl: Mo unfortunately could not join. He had a fire drill happen, a metaphorical fire drill, happen at work like an hour before we started. But generally we have Mo, who is head of mobile at Theodo and is very active in the React native community. Kind of sad that he had to skip out this month because he just did React Native London, and I was hoping to hear how that went. [00:00:39]

New releases

2-vcarl: But yeah, let's get straight into it with some new releases. [00:01:00]

BetterAuth 1.4

2-vcarl: First off, we've got better off 1.4. I actually use Better Off now. Woo. I had been excited about it for a while because I don't like authentication. Libraries generally like stuff like Passport or what, you know, even clerk or the SaaS businesses, just like none of them. [00:01:04]

I didn't like them very much, so was very pleased to see an open source library that looked to cover many of the bases that I want and can confirm after using it that it does. So I'm excited to see Better Off 1.4, which is the first release since I believe July when it did 1.3. A couple of quick highlights from it. [00:01:20]

It's got stateless off. So you can do sessions without a database just by not giving it one, which is nice. It's also got SCIM provisioning for identities in multi-domain scenarios, which is cool. Also, some other little details like database joins and custom state for OAuth flows. But yeah, just auth is a shockingly deep subject when you actually start dealing with the nitty gritty weirdnesses of it. [00:01:40]

And I have generally found most open source projects trying to support authentication to be, to leave something to be desired and better off leaves the least to be desired of the projects. I've tried, so Love it. New version. [00:02:06]

1-acemarke: I have thus far managed to stay away from dealing with auth at all in my career, and I would like to keep it that way. [00:02:20]

2-vcarl: Yeah, that's not a bad call since I haven't been able to avoid it. I went a little bit deep on it and I don't hate that either. It's interesting. It's fascinating. Actually. I don't know, one of the vague. Startup ideas in the back of my brain is related to authentication and identity management, which could be cool. [00:02:28]

I don't know, maybe I'll do something with that eventually. [00:02:44]

Immer 11, RTK 2.11

2-vcarl: Mark, I want you to unveil your magnum opus. [00:02:47]

1-acemarke: Happily. So I talked about this a bit last time, but Redux Toolkit relies on Immer for immutable state updates. It always has since day one. We've gotten various complaints over the years that, you know, Immer is kind of slow, but we've always said that we prefer the fact that it eliminates accidental mutations, makes reducers easier to write. [00:02:50]

Of course, we want Redux toolkit to be fast, but we also want things to be correct and users to not have bugs. So I'd done a little bit of perf investigation into Immer like a year ago. Saw that it had gotten slower, filed an issue. You know, it was kind of left there. And at the start of September, I myself dug in and started trying to see if I could optimize ER's performance. [00:03:11]

And I spent well over a hundred hours collectively across September and October, deep diving into ems, codebase, comparing it to other libraries, understanding how it worked, and trained to do a bunch of performance optimizations. And so ended up filing a few different prs, Immer 10.2, shipped last month with some small tweaks, and Michelle West Rate just merged a big architectural change and released it as Immer version 11 just a couple days ago. [00:03:34]

And then I was able to put out RTK two point 11, which picks that up. So free performance wins for Redux Toolkit and Nier. [00:04:04]

2-vcarl: Heck yeah. That was what was the average speed up? [00:04:13]

1-acemarke: The current builds average about 20 to 25% across all the different benchmarks, varying by scenario. And then there's another outstanding pr, which adds an optional array methods override plugin, which drastically speeds up array methods. [00:04:16]

2-vcarl: Heck yeah. That's awesome. We love a core performance improvement and I, I wanna shout out the ecosystem performance. You know, I don't know, [00:04:34]

1-acemarke: E 18 E folks are awesome. They have been doing a ton of work to clean up large dependency trees and slim down packages and remove dependencies across a wide variety of tools. [00:04:43]

Yep. [00:04:56]

2-vcarl: A stat that I believe we'll talk about later, I saw in general ecosystem commentary. Yeah. I guess in the NPM supply chain fact that we'll talk about later, a a a stat that came out of a blog post from that was that the average JavaScript project pulls in 683, I believe in, was it transitive dependencies? Just like, yeah. It's a lot. So when you've got that many dependencies, performance of the ecosystem is challenging. Yeah. [00:04:56]

1-acemarke: That doesn't surprise me. I know that. React app. The last I saw it defaulted to about 1500 dependencies, largely because of Webpack, et cetera. Vite's obviously a lot fewer, but still that's, that's not great, just for a whole variety of reasons. [00:05:21]

2-vcarl: I guess teaser for y'all. Later, towards the end of the episode, we're gonna talk about web ecosystem and there's been some blog posts talking about like. AI and how it defaults to building React instead of using the web platform and how do we promote the web overreact, things like that, which I don't know, it just feels that we just started bleeding into that topic, and so we will get much more deeply into that later in the episode. [00:05:37]

Storybook 10

1-acemarke: Next release. So Storybook 10 came out a few different big points there. One of the biggest is that it's now ESM only. They've removed all the, the common JS artifacts, so they've shrunk the install size and they've also drastically shrunk the dependency chains as well, as well as some improvements to things like the mocking and some of the storybook formats. [00:06:00]

0.1 version of Remix team’s “event interaction” package

1-acemarke: And then one other release of note, the Remix folks are continuing to work on Remix V three after the initial demo and announcements, and they're trying to build it, as I understand it, with a lot of smaller reusable packages. And they just put out the first 0.1 alpha of their. Event interaction package, which is providing an abstraction for being able to compose events and listeners and behaviors together looks interesting. [00:06:22]

I'm not gonna claim I understand like exactly the benefits this comes, but nice to see the progress there and I suspect that a lot of folks are gonna get some use outta this. [00:06:49]

2-vcarl: Yeah, I'm reading the syntax here and it looks like a different way of adding event listeners to DOM nodes, which, sure. I don't know, there's weird quirks and certainly the Remix team and you know, Michael Jackson and Ryan Florence specifically have shown, have demonstrated a great willingness to jump into what many people consider solved problems to reexamine from first principles. [00:07:00]

So, I dunno, they've, they've done that, they've done that repeatedly with their own solved problems of data loading in routing. The interaction between data loading and routing. I feel like that's one of the bigger complaints about React router is that they keep reexamining that same question. So I don't know. [00:07:25]

It's interesting that they do have interesting things to say when I've seen them reexamine, quote unquote solved problems. So I'll, I'm curious. This looks a little strange. It looks pretty divorced from the DOM structure, so if you just like on input element and then add a bunch of listeners for it, that's curious. [00:07:41]

Anyway. Yeah. 0.1 release, we'll see what they come out with. [00:08:00]

Main content

2-vcarl: Okay. That's all the new releases we got so far. Let's go into some main content. [00:08:04]

Ecosystem panel discussion of React Foundation at React Summit NY

2-vcarl: First off, we want to talk a bit about, yeah, mark, you are on an ecosystem panel at React Summit this month. [00:08:08]

1-acemarke: So let's see. Addie has money was moderating. We had Seth Webster from the React team, React Foundation, Shaundai Person, Amy Ner, Nicholas Gallagher, and myself. [00:08:15]

A lot of the discussion was us asking Seth Webster questions about, so this React Foundation thing, like how is this actually gonna work? What does this actually mean for the React team and the project and the ecosystem? There is a video for the panel. It's not unlocked yet. I have access to it because I speak at GI Nation events, but the video should unlock within a couple weeks, I think a a few different points that Seth made during the panel itself. [00:08:25]

And then I had a chance to have a follow-up discussion with him afterwards and. There's a few different very interesting p pieces of news about how the foundation's going to work and what their plans are. He talked a bit about some of the, the funding process. So, you know, large companies pay, you know, a good chunk of money to be members. [00:08:55]

The, the existing. Board member companies have already paid up for like three to five years, and it sounds like he'd actually been working on putting the foundation together for over four years. Like this was a very long term kind of a process. [00:09:16]

And they're hoping to do a number of different things with the money. They want to hire some additional engineers. And he even said some of that would be spent on having engineers triage the issues. And if you've ever looked at the React repo, you know, that's a thing that they do not do very often. So even something like that sounds good. They want to hire some more people to work on the actual docs and they're hoping to give money out to communities in some way. [00:09:31]

Don't know details on that, but [00:10:00]

2-vcarl: Tell me more! [00:10:02]

1-acemarke: Exactly. Another data point. So a lot of the plans have to do with the development process of the React project itself and transparency around that. Apparently they were even hoping to launch the foundation like a year and a half ago. And then they realized that like, "our own in day-to-day development processes aren't ready for that. We need to dog food the processes ourselves first so that we're more ready when the foundation goes live." [00:10:03]

And so some of that was actually having docs and plans as new features are being developed or treating things in kind of like a, you know, TC 39 staged process. Approach, but one of the biggest things that Seth told me directly was that up until now, the React team has had, you know, their, like their weekly status meetings and those are purely internal. [00:10:36]

First off, it was just all the React team working at Meta and then it was, you know, meta plus versal. But those meetings have always been internal, private, and non-visible. And Seth said that they eventually want to literally open up the weekly React team planning meetings to the public even as like a, like a Zoom call with no password. [00:11:00]

And that eventually, like designated community reps would even be able to actively participate. In those discussions. So that's a radical change in the development of React itself. He also said that they're planning to resurrect or like completely redo the RFC process, which frankly was kind of dead from the beginning. [00:11:24]

It was where random people from the community posted ideas that got ignored and the React team posted, finished things that they planned to ship and then people argued over the naming and the React team ignored that. So like historically, the RFC process was pretty much irrelevant to actual React development. [00:11:46]

Now they're talking about making it like a real meaningful discussion and part of the planning process. Now again, like do I know how this is gonna work out in practice? No. But I can see the amount of effort and the intent. Behind the foundation and the plans that they're talking about. And even if it doesn't end up going exactly as they, or we would hope, I see good faith and good intentions behind all the work that they're trying to do around the process here. [00:12:04]

So I'm actually very, very excited about this. [00:12:36]

2-vcarl: Yeah, that's interesting. Oh, I got a lot of thoughts rattling around my head. 'cause that's a lot of stuff that I've looked at trying to contribute towards the solution of, yeah, I don't know. It's, I fundamentally, I feel like the problem they're dealing with is that a lot of people care about the outcome, the output, what they make and what React is. And not a lot of people actually have like the context and the background to like meaningfully contribute to the advancement of that goal. [00:12:39]

You know, to respond to what you just said about like their motivations and their what they want to do. I don't think that's ever really been the problem, they've always had good intent and I even think a pretty clear eye picture of what the problems are. But I think the problems are really thorny and complex and the solutions to them are non-obvious. And even when you have a good solution idea, executing it in a way that is effective and that operates on the kind of like timescales that React is around for is just really challenging. [00:13:08]

Like it's, you know, anyone can spin up a process and run it twice and you know, maybe that, like you do, you call for comments and you run a community discussion and round tables and whatever, but like that plays out over the timescale of like weeks and months and React seems to plan on the order of years and is, now has existed for a decade. [00:13:42]

So, you know, with like there's possibility for its scope to expand from thinking in terms of years to thinking in terms of, I don't wanna say decades, but that's the next unit of time. That's the next order of magnitude. I hope they can achieve their goals. I am looking forward to seeing some more roadmap, transparency of some sort. [00:14:05]

Actually that'll be really great for us, for you and I. That'll be great. Yep. That'll be a great source of signal that we can then pick apart and analyze to surely, to much to their chagrin by way of drawing attention to things that are high context [00:14:23]

1-acemarke: as opposed to like stalking the open PRs list. [00:14:40]

2-vcarl: Yeah. Right. Cool. Nice. Love that. [00:14:43]

React Concurrent Stores: Polyfill, React-Redux POC

1-acemarke: So on that note, another item that I've personally been involved in is the work on the upcoming React Concurrent Stores API. So when React 18 came out, the React team included the Uyc external store hook as the official built-in way for third party libraries like Redux, Zein, Jo Tai, whatever else to integrate into React, take an external state update, turn it into a React re-render, and it worked. [00:14:46]

But it also had a very intentional design limitation that if you do an update in the middle of a paused React render, you know, something transition like then it bails out of that and just does a complete top to bottom render. So you're kind of throwing away some of the benefits of React, being able to pause itself. [00:15:13]

And that was because they, they really didn't have a better idea for how to do that kind of interop. So this concurrent store's API is supposed to be essentially a new equivalent to use sync external store, but concurrent transition compatible. And Jordan Eldridge, who's on the relay team, has been working on the design and initial prototype IMP implementation for this. [00:15:32]

And so he put out a polyfill package that roughly implements the prototype as a standalone library. And then I've been talking with him about, you know, here's what Redux would probably need to make this work. Here's our, our requirements for this. And so I was able to then take his proof of concept package and put up a draft PR for React Redux that just swapped out our used selector implementation to use that instead. [00:15:57]

And it basically worked, I mean, just the one test file found a couple edge cases, but like most of our tests passed, we're not doing anything transition related in our tests. But it's good to know that like your baseline standard behavior works. [00:16:25]

And this also turned up several more things we'll have to figure out, like, quality checks and how do you handle selectors throwing errors, and we're talking about when can React safely, call selectors, can it delay it due to batching and things like that. So also very excited to see the progress being made on this API. A lot of people have asked for external state transition compatibility, and so this is going to be a big deal for the ecosystem. [00:16:39]

2-vcarl: Interesting. Cool. I'm just trying to put this in a little bit of context for myself. So this is a, an exploration of an API for a concurrent store that they've indicated intent to ship eventually. Is that right? Mm-hmm. [00:17:08]

1-acemarke: Yeah. So basically a, a new equivalent of useSyncExternalStore, but minus the sync restriction. [00:17:22]

2-vcarl: Got it. Okay, cool. Interesting. You called it a poly fill, and I see in the blog post it's labeled a pony fill, which I had to refresh my memory on the distinction; a poly fill fills in a gap in the platform transparently, and a pony fill offers the same functionality, but as a standalone module that you have to import. [00:17:30]

There you go. Now you know. [00:17:50]

React Router and transition usage

1-acemarke: So one more item kind of related to that. At React Conf, Ricky Hanlon announced a new Async React Working Group to provide support to the, you know, the community and the ecosystem on, you know, improving the React docs around async behavior, helping libraries get set up to use these methods. [00:17:52]

Matt Brophy and Ricky discussing nuances of behavior, use with React Router

1-acemarke: And so Matt Brophy from the React router team had a good discussion with Ricky about how they're trying to handle using transitions in React router. So there was a, a good technical discussion about the nuances of behavior. And then the React router team also put out a pre-release version or unstable option to enable some of the transition behavior as well. [00:18:08]

So starting to see some adoption and this ties into the React team wanting to see libraries pick up these behaviors like transitions and action props and, and build them in. I will say that I had a couple discussions at JS Nation React Summit where some people were questioning whether making the entire ecosystem change semantics and behaviors and add props to make the React team happy was gonna be a good idea or feasible, but we'll see. [00:18:33]

2-vcarl: Yeah, interesting. I see a bit of why they, why the core team desires that. Transitions are definitely like. My understanding of the core team's incentives and what they care about is ability to use the platform and things like that. So given that like transitions are a part of the platform and they are interested in allowing people to take advantage of platform improvements, I understand why they would message, "in order to use this, the entire ecosystem must make this change to the patterns they use for compatibility reasons." [00:19:03]

But that is very, I don't know. That's a big challenge. It's herding a lot of cats who don't necessarily, aren't even necessarily aware that there's an attempt to herd being made. [00:19:38]

1-acemarke: If you watch Ricky's talk from React conf, you know, he, he demoed switching from like a bunch of manual use effects and loading states to suspense and transitions and then he pointed out, and so now you have a much better experience, but you also had to do, you know, call start transition and all your click handlers and so on. [00:19:49]

There's even some painful nuances there because start transition is based on setting a flag internally for the current event loop tick. If you have a callback that has an await, you leave the event loop tick. And if you then want to do another state update after the await, you have to call start transition a second nested time. [00:20:05]

And Ryan Carniato actually pointed out to me that like Ricky has repeatedly messed this up in his own demos, it's a very foot gun prone behavior pattern. And so the combination of, like, you currently have to call, start transition yourself, plus trying to get the patterns right, is a good argument for let's just build this into all the libraries. [00:20:29]

But that takes time and effort and coordination. [00:20:53]

2-vcarl: Yeah. Right. Like that was one of my big takeaways from Ricky's talk was, oh, this looks hard. Which is not the best takeaway if you're trying to convince the whole ecosystem to move on to something. [00:20:56]

1-acemarke: There is a lot of complexity in mental model of React and the kinds of apps we're trying to build. [00:21:08]

And both the fact that you now need to keep track of additional API methods that you have to call and the semantics and when you're supposed to use them. And the fact that your, your state is now kind of in multiple Schrodinger's box, multiple versions at once. It's, it's definitely a lot of additional mental overhead. [00:21:15]

2-vcarl: Yeah, right. I'm just looking at, in this GitHub thread that you linked, Ricky says, you know, oh, I think there might have been some confusion. Here's how you do it for navigations and it's, you know, function, navigate to A URL that has start transition, which, you know, wraps set router state, which then wrap, you know, it's argument is a function that I guess returns A URL. It's a thunk for set router state in start transition, in navigate. I don't know, they're like, that's just complicated. Like what? Why are we wrapping this with so many different functions just to navigate? That's uncomfortable. It feels like the wrong API in some way. You know, like it an API should obscure complexity and this does not obscure the complexity. [00:21:35]

So, interesting. I want to be able to take advantage of transitions in apps. 'cause that's super great if you can just like easily convey that you are here and you're about to go here. Instead of just going there, like you get a lot of really powerful things that you can do for user experience and, you know, whatever, all sorts of stuff, if you communicate the transition instead of just updating the current state of your app. [00:22:17]

But yeah, I don't, I, I'm not sold on this. I'm not sold on one I'm seeing so far. [00:22:43]

1-acemarke: Okay. Moving on to the next related chunk of topic. [00:22:48]

The State of TanStack, Two Years of Full-Time OSS

1-acemarke: The Tan Stack folks have a bunch of updates that they've put out both blog posts and versions. So Tanner put out an article on the state of Tan Stack as an organization and his own work as a full-time open source maintainer for the last couple years. [00:22:53]

Also, again heard, you know, heard some of this from, from him directly at a React summit loosely. He himself has been full-time supported open source for the last couple years, sponsorships to the TN stack org. Tan Stack Libraries are, you know, as we all know, very, very widely adopted and certainly query is the standard Fritz thing at this point. [00:23:13]

Router and is picking up a lot, A lot of popularity start is almost 1.0 and he's hoping to be able to start to bring in some part-time or even full-time. Uh. People to hand stack the company in the near future, essentially other. Current maintainers for various stand sand stack libraries who would then be able to potentially switch to doing that as their actual job. [00:23:34]

So essentially he's been fortunate enough to have this work out for him and he's hoping to share that ability with other people working on the projects. [00:24:00]

2-vcarl: Yeah, I see. He says monthly sponsorships for 12 core contributors and short term contracts for another three to five people. I guess that's not clear what monthly sponsorships means. [00:24:09]

I, my assu, my assumption there would be like their, maybe not full time, but getting like sign, you know, significant compensation. But that may not necessarily be true. [00:24:20]

1-acemarke: I don't know numbers, but I think at the moment the others are doing open source and they're full-time and getting some, some stipends and in the next couple years he's looking at actually hiring some of them. [00:24:30]

2-vcarl: Cool. Love that. That's super hard. Building revenue so that you can actually support other humans is actually really challenging. I really like this blog post about, you know, Tan Stack for two years. I like this line. You know, building a full stack framework is hard. I knew that from watching other teams do it. [00:24:42]

Most of them had something I didn't. Capital Next Gatsby Redwood Remix all had funding companies or acquisition paths and that that definitely is something that feels very different about Tans stack. It feels very much like he couldn't not do this. Like he just had spent several years working in this problem space and solving his own problems with the freedom to publish them so that other people can take advantage of his work. [00:24:56]

And then got to a point where it just made sense to invest more effort and take those a little bit further than they could go. Absent that. Level of dedication I, which i, I love. That's just like, that's, I don't know, finding that kind of work to do for yourself is what I've been looking for. And it's really hard to find, and I love that Tanner Winsley has apparently found it. [00:25:20]

Yeah. And also having 16 partners doing sponsorships is also great. Like that, that, that may not be capital, but that's, that's great. That's nice. Having tried to find sponsors myself, like getting 16, it's like, oh shit. Good job. That's awesome. [00:25:43]

TanStack DB 0.5

1-acemarke: Tan Stack DB is a new work in progress package largely being worked on by Kyle Matthews, formerly of Gatsby, currently of electric SQL, that is meant to be kind of like a half a sync engine layer on top of another data source. And so like one of the common usage patterns for that would be you wrap it on top of your 10 stack query, you know, API definitions. And so maybe you've got some endpoints for fetching. Post comments, users, et cetera. [00:25:57]

But then it presents like a sync engine like interface on top of that, and it's got a bunch of data flow analysis baked in so that it can do things like partial fetches or only re fetching, you know, certain pieces of data, joining, essentially presenting like a normalized facade layer over the individual endpoints so that they act like they're unified almost as a like a replacement for a GraphQL style API. [00:26:27]

And so they've been working on this and it has integrations with Tan Stack Query and then Electric SQL and a few other data packages. And Tanner pointed out to me at React Summit that it really just needs an adapter layer to be able to connect to another library. And I could totally build one for RTK query. [00:26:54]

And so I was actually briefly playing with that on the flight home. I haven't had a chance to push it further, but I'm actually, I'm actually very excited to play with that more myself because like Tan Stack query, we made the decision to make RTK query non normalized. It just caches the response from the server. [00:27:12]

And so if this essentially let us make a normalized layer on top of our own library without us having to make any further API changes. That's very interesting to me. [00:27:29]

2-vcarl: I'm also thinking about, you know, this is from Kyle Matthews who did Gatsby, which, you know, notoriously exposed a GraphQL, you know, layer on top of whatever data sources you wanted to give it. [00:27:41]

So just, I'm thinking about how, how much of Kyle Matthews work could be described as providing query abstractions over arbitrary data layers with data connectors. [00:27:54]

1-acemarke: That's a good point. I, I had, I hadn't even drawn that connection that this is actually very related to his prior work. [00:28:05]

2-vcarl: If you described this at a certain level of abstraction, this sounds just like GraphQL, Relay, Gatsby, a bunch of other stuff. But I do see the niche that it occupies and how it's distinct from those projects. It's kind of like GraphQL, except instead of the network boundary, it's like the component to data store boundary on your client app, which it, that's useful . [00:28:11]

Like what you just said about how you don't normalize in RTK query, I've landed on that as being generally a good architectural decision to make in applications because like if you start doing data transformations, you know, bespoke data transformations per endpoint, then it becomes really hard to change those endpoints. [00:28:33]

If you're changing the underlying data, then you've gotta change all the code at the same time. Whereas if you just take whatever the API gives you and then write like a transformer on top of that, then it's just you, you add a layer of abstraction for yourself that gives you a little bit more flexibility around timing of some types of changes. [00:28:53]

So, yeah, I don't know. That's, it's interesting. This is an interesting project. I dunno, something about it feels like I don't quite know where I would take advantage of it for myself, but I could see the right app with the right kind of team operating it, finding this and being like, this is exactly what we need. This solves multiple challenging thorny problems that we have or, so yeah, I don't know. It's interesting. [00:29:17]

1-acemarke: My own personal to-do list is massive at this point. Both like Redux and even just like personal life stuff. But I, I absolutely want to go back and, and play with my own RTK query integration prototype for that in the near future. [00:29:40]

2-vcarl: Yeah, I generally love the idea of sync engines. One of my core beliefs about writing code is that many more applications that we use have no technical necessity to be online only. [00:29:52]

Like, there are a lot of things, like, for example, my favorite canonical example of this is like Gmail. If you're using the Gmail app. It doesn't actually care if you're online because it is doing synchronization of your emails in the background. And so you can just interact with it normally while you're fully offline and later it will do all the things like synchronize the read states or like, you know, which emails you've archived and deleted and yada, yada yada. Completely transparently. Like I have never thought about, oh, I should wait to do this later when I'm online so I don't cause weird problems for myself. And I do think about that all the fucking time in various other apps that I use. So like there, that's something that we used to do that we no longer do because it's hard. [00:30:06]

I love seeing more effort and energy being expended into making it easier to do offline things. And sync engines are a big part of that. And so abstractions, over sync engines are also a part of that. Great. [00:30:45]

Tanner teasing a WIP TanStack Start RSC implementation

1-acemarke: The Tan Stack router folks also put out a really good blog post talking about how they did some massive optimization on route matching, including using a somewhat lesser known data structure called, I think it's pronounced a try, T R I E. [00:31:01]

I love I I love seeing optimization breakdowns. So good article there. And then since we've done plenty of, you know, stuff being teased on Twitter discussion in the past with Remix and everything else, Tanner has been teasing that they are working on RSC support for Tan Techstar. And I can say that he showed me a demo and it's unconventional. [00:31:13]

It is not what you would expect after having used Next, and yet it totally makes sense in its own way once you see it. So as I understand it, they've made real progress on implementing it. They've figured out the design and now it's push it forward and make it actually a thing. I have no idea how soon this will be revealed, but I think once this comes out, it will be a very interesting, challenging take on our understanding of server components and how they, how to use them. [00:31:36]

2-vcarl: I would certainly say that the way Next has done it does not seem to be like the end all, be all of great implementation. So if they have found a new way to approach it, hell yeah here for it. That's awesome. [00:32:10]

1-acemarke: So there, there's your vague tweet for the month. [00:32:21]

2-vcarl: Yeah. Right. [00:32:24]

State of the web ecosystem

2-vcarl: Let's talk a little more broadly. Let's talk about the state of the web ecosystem, I guess like to intro our subtopics under state of the web ecosystem. I wanna talk a bit about like the CloudFlare outage, the NPM ongoing attacks. Like this is not a new attack, this is a continuation of the previous attacks, plural, that we've discussed, as well as Alex Russell had a decent blog post. I say decent because I don't know, it's it qualified, decent it, it's well written, it's well argued, but I don't necessarily agree with his conclusions. And also there, there's some conversation about reacts place in the ecosystem and AI and things like that. So that's the shape of this state of the web ecosystem chat that I want to start or that I want to have, I guess. [00:32:25]

Cloudflare November outage postmortem

2-vcarl: Yeah let's start at CloudFlare. They had an outage on the, earlier this month, about a week ago, 18th of November. They say in their outage postmortem that it was triggered by a change to the permission system of one of the databases, which caused it to output entries ba- basically, it produced too large of a file that then got distributed out and the size of that larger file getting distributed caused performance load that took down the network. [00:33:13]

1-acemarke: Check me this. Another factor on it was they, one of the services was written in rust and it had an expectation that the file would only be so big and there was, I think there was a rust line of code that basically said if it doesn't fit, panic. Yeah. That a bad file with like they had 60 features, a limit of 200 and a line of code that basically said if it gets over 200, throw, throw an error or kill the service. [00:33:40]

2-vcarl: Yeah, that'll do it. Yeah. "Each module ran on the proxy service has a number of limits to avoid unbounded memory consumption." Somewhat questioned the wisdom of that because the reason you would have limits on memory consumption in place would be to avoid outage and downtime. And so if your resolution to, the outcome of your limit, if memory usage gets too high is to crash, that is functionally very similar to an out of memory error. [00:34:08]

Maybe it's, I guess it's easier to debug, I guess you can, out of memory errors cause crazy, unpredictable failures, I guess. So at least this is a predictable failure that strongly indicates where the, the excessive memory use is coming from. [00:34:36]

But yeah, it, it was pretty serious. I actually didn't notice, which I'm glad about. It's nice to not be so online that you don't immediately notice every, I don't know, every outage, but yeah. This kind of, I think this was a, a, a good demonstration of the place in the ecosystem that CloudFlare occupies and how many different services truly rely on its stable operations. Yeah. [00:34:49]

1-acemarke: Trying to make the trade-offs between the web is decentralized. Anyone can run their own thing versus, Hey, look, there's benefits to having centralization. Let's all put our GitHub, or let's, let's all put our git repositories on the same service so we can, you know, log in and share them and comment back and forth. [00:35:11]

Let's put all our social media comments on the same service. We can have commentary back and forth. Let's all use this widely spread CDN and DDoS protection service that also has a bunch of really cool backend services. And then when one of those big services goes down, it ends up having, or everybody put everything in AW, AWS East one. [00:35:29]

2-vcarl: Yeah. Right, right. Yeah. Right. Or, [00:35:50]

1-acemarke: or even like we, we put it in AWS East two, but AWS themselves relied on AWS East one, and then it goes down. We keep burning into these big dependencies that end up having massive effects on the internet when they go down. [00:35:52]

2-vcarl: This feels like a good transition point to a link that we had slightly later down. [00:36:06]

"What if people don't want to create things"

2-vcarl: Tom McRight, who is not a name I recognize, put out a blog post called What If People Don't Want to Create Things? And that feels like what you're talking about, like the ideals of the web is decentralized, you know, their own domain, right? Sharing knowledge, sharing skills, sharing tools, and I love that. I agree with that. I aspire to those ideals. [00:36:10]

But it's also true that like we kind of just want stuff to work. We want it to just kind of be stable and you know, what's not stable, decentralized things that have a smattering of volunteers maintaining it. That's kind of the distinction. Like that's kind of the trade off is like over time decentralized things with enthusiastic maintainers and open source, over time that stabilizes and grows and becomes great in a way that proprietary code can't, because you know, you can't inspect it, you can't say like, I'm encountering this bug. Let me go look at the code. Oh, here's where it's coming from. Let me tell them about it and give them a reproduction. And contribute to a fix. Like if I encounter a problem like that in any of these many proprietary tools that I use, then there's just no path for me to do that, so. [00:36:33]

But on the other hand, they have the capital and the employees to have people proactively looking for that, where it's their job. That's the tension. I tend to believe over a long enough time scale that distributed, decentralized things like the web will be better than anything that's like proprietarily developed. [00:37:25]

But it has to work well enough to get the attention. And you know, in this attention economy we're in, it's very hard to get people who have enough bandwidth of their attention to say, "I have found this problem, let me chase it down to its logical conclusion and contribute to a fix being actually shipped for me and people like me." [00:37:47]

1-acemarke: We aren't gonna go off on this, but I can even see some tangential connections with things like open source as a concept, open source maintainer, burnout. Like most people like using an app or a library or even even developers using a library, like in the end, do they actually care that it's open source? [00:38:05]

No, they just want to download the thing and have it work, whether it's Libre office or you know, a paint, you know, paint program or Better Auth or whatever. And the fact that the code's open doesn't matter. It's like I, as the consumer of this thing at this level, just want it to work. And if it doesn't, I ask the person who builds it, just make it work. [00:38:23]

2-vcarl: Right. I'll call out a couple of quotes from here. "Beautiful data visualizations are free to make, but the supply of people who really love and know D3 is a lot lower than I expected it would be. I love home-cooked apps and malleable software, but I have a gnawing feeling that I'm in a bubble when I think about them. Most people's lives are split into the things that they affect and create and the things that already exist and wanna tune out and automate." [00:38:46]

I think that's a, I think that's insightful. I think that speaks to a deep, I don't know, tension in this. Like, yes, AI lets you do a much larger range in a much shorter time span than used to be feasible. But do people want to do that? I don't know. [00:39:07]

Given the, given a range of infinite possibilities, how do you pick which one that you are going to do and then give it the attention so that it actually produces something that other people can benefit from. How do you find the things that you want to build on top of, you know? [00:39:24]

“When Everyone’s a Developer, How Do We Promote the Web Platform Over React?”

2-vcarl: Well, I guess I'll transition from that, from that comment to this other post. "When everyone's a developer, how do we promote the web platform over react?" It's in reference to this Alex Russell Post that I'll, I'll, I'll share after. But I guess it's talking about, it's talking about that like when people can make their own software, when they can just use plain English to ask AI to generate code that in one form or another, solves the problem. [00:39:39]

They stated, you know, maybe not the way they intended, maybe not the way they wanted, but it. It's doing its best, just like all of us. It's talking about how if you just ask it to make something, it's probably gonna use React, because that's what, by volume of text, by volume of code that it's trained on. That's what, that's the mode. That's the most common example. [00:40:03]

I guess, like this is framed as a, an AI problem, like why does AI do this? But this is actually the same problem that I've observed well before AI came out, you know, 2022 or when everyone chat GPT really started, I have observed all of these problems that it's talking about over the life of my career. [00:40:20]

Like, you know, especially I feel like, you know, there's a certain golden age of tech between 2018 and, I dunno, 2021 or so, and that was absolutely the case. Like I would, you know, join a new workplace, because I did that a lot, I worked at a lot of different companies and I'd look at the practices people were using. It's like, why did you use React for this? Like there's, here's a platform feature that solves this more easily. And with less code. And a lot of the time people just didn't know it existed. Like it's that attention problem. How do you know what you should build on top of? [00:40:38]

I don't know. It's the solutions here that people are talking about is like, what can we, the web community do to promote web platform features over react code and it proposes teach vibe coders to explicitly prompt for web native solutions, get the LLMs to ingest more web platform code, spotlight teams and projects that ship modern web experiences without heavy frameworks. [00:41:11]

I mean, like that's, to me, all of those essentially just like how do you make the web platform more popular? To me, ai, it fundamentally spits out an average. It spits out like, you ask it to do something and it will give you a deeply profoundly average result for, you know, if you asked a thousand people, that question here is approximately what the mass of those people would say. And it's true that if you asked a thousand developers to do something on the web, the most common output would probably be a kind of shitty implementation with React that overused things like use state news effect because that's what developers did and do. So I don't know, it's like a lot of these questions that we ask ourselves about AI and code, I feel like distill down to the same kinds of questions we were asking before. [00:41:33]

But like now there's a boogeyman of ai, like this is ai, this is this, this is code, this is a product people have built. And so it is now a very convenient boogeyman, but it, it's a distillation of the thoughts of a vast number of people as codified by what they published and what was ingested for the training set. [00:42:26]

1-acemarke: I just tossed in a link to the obligatory XKCD from like a decade ago, which is the, the one of the points out that sometimes your, your map or your heat map of users is actually just a heat map of the population. It's a one-to-one correspondence. And so I think that that is partly what we see with like React usage. [00:42:46]

You know, there, there's a lot of people. Who use React. There's a lot of people who use React badly and therefore, like the spread of types of usage of React, the quality of usage of React kind of maps to the quality of programmer skills and backgrounds, like not necessarily an excuse. And that's not to say that like everything about using React is is good by itself, but just that when you have a full cross spectrum of the population using a thing, you're going to have the full cross spectrum of the population using it in good and bad ways. [00:43:07]

And so in the same way when it like, when it comes to, you know, people building apps, re React got popular, when LLMs came out and saw that was re React was popular. So LLMs repeat what they were trained to do, and plus it's also, you know, like not just popular, but it's especially popular within Silicon Valley, within all the companies making the AI builder tools, et cetera. So in a lot of cases, they're prompting them to just use React because they assume it's the default that you would use anyway. [00:43:45]

2-vcarl: I, I wanna shout out a term that I love, "path dependence," which is like, where you're at right now is the outcome of a series of choices that were made in the past, and those past choices constrain what paths are available moving forward. That's path dependence. Where you came from affects where you can go. [00:44:13]

And so I guess like to me that this is a complaint about the path dependence of React. Like because React got popular now React is, we've worn that rut and so now it's hard to get out of that rut even if there is a better alternative. [00:44:35]

And so I would say like the solution there isn't like, I don't know, tell people they're bad at things. The solution is to like make better resources so that a different path becomes the easiest one to take. En masse, you know, writ large, when, you know, it's one thing to convince 15 people that this is the best solution and it's correct. [00:44:51]

And it's another to make the argument clearly enough, strongly enough, and consistently enough over a long enough span of time that it affects the behavior of millions of people. So, you know, how do we promote the web platform over react, like do a better job promoting the web platform, 'cause there are thousands of people who are writing resources for React because that's where money and attention and time is. [00:45:14]

So if you want to do better than that, you have to make a resource that is better. I don't know that. There you go. [00:45:45]

1-acemarke: Yeah, so the, the, the other, there was a related article from last month entitled Dead Framework Theory, which was specifically addressing like the the LLM training data aspect of this and how it, how it becomes a, sort of a self perpetuating cycle. [00:45:53]

And also pointing out that like if you have a, a new library or a new tool or a new web platform feature that is just now baseline, newly available, there's a lag in common LLMs knowing about that. So it's sort of like that defaults win kind of an issue. [00:46:07]

2-vcarl: Yeah, and I'll say, yes, defaults win, but that doesn't mean that it's impossible for an, you know, to approach the problem in a way to mitigate that kind of, you know, home field advantage that tools like React have. [00:46:25]

I've shout it out a number of times, in a bunch of different contexts, because they do a good job! But I love effect. One of the things they do really well is documentation, and one of the things they do really well in their documentation is making it legible for ai. I recently, over the summer, built a greenfield project with effect, and I did it extensively with ai, a mixture of having it write and then having it educate me and then rewriting it, and then having AI rewrite what I did, you know, just get there over time. [00:46:38]

But I was able to do that despite it being a new library that's even at odds with the kind of patterns that AI wants to write, it's a functional type, it's a functional programming typed standard library essentially, which is not at all what AI wants to write. AI wants to write object oriented classes. And despite that, I was able to make it, figure it out and learn it and do a good job, good enough job that I got something I was proud of. You know, not just vibe coded. I was proud of it. I told people in my life, this is the best code base I've ever worked on. [00:47:07]

And it's a large part of that was because of how the effect as a, you know, organization and library approach, their style of documentation. They made it legible for these automated tools. So I guess like if you wanna promote the web platform over. Incumbents like React then like figure out how people are writing code, figure out how people are consuming documentation, consuming new knowledge and do a good job. [00:47:36]

1-acemarke: I'll note though, that you, you are the one who decided you were going to use effect and told the LLM, this is what I'm going to build. [00:48:03]

2-vcarl: It's true. Yeah. [00:48:11]

Alex Russell’s latest stats on web devices and network budgets

1-acemarke: The last wink on this particular topic, Alex Russell, who used to be at Google now has been, Microsoft has been very vocally beating the drum that most client side JS is bad, that JS bundles keep growing, that most people are using. You know, older Android devices on mobile with very weak CPUs and therefore JS load times are worse versus, you know, developers using an iPhone or, or a Power or a Fast Mac or something. [00:48:12]

And he just put up the latest article in his ongoing series. You know, documenting, stan-, like average bundle sizes, average network speeds, average CPU uses. I have a lot of respect for him. Technically, his stats are correct. His points are right. I have questions about his delivery and tone in how he accuses people of doing the wrong thing. But it's also very true that a lot of the people should be paying more attention to him and actually trying to shrink down bundles instead. [00:48:41]

2-vcarl: That's interesting. I, a thought I've had, I haven't validated this thought against, you know, ground truth, but I've been hearing about bundle size as a problem. Essentially what he's talking about here, like we ship too much JavaScript for the compute capabilities of commonly used devices, like that as a thesis has been something I've been hearing about for a very long time, much of my career even, and I'm not sure that the bundle size problem has gotten that much worse over the last, I'll say eight years, you know, call it since 2017. [00:49:14]

And he shows a chart of compute speeds and basically shows like, yes, top of the line devices have gotten five times faster, low end devices that 75% of the world uses have not gotten measurably faster. And that's true. Can't argue it. His stats are correct, like he said, but also like I'm not sure the problem is getting measurably worse. [00:49:52]

The optimizations of how we can split code and you know, what the JIT and the execution environment is doing to make it work more quickly. Those have gotten better over time. And it's also true that like, so if he's looking at the, basically like every processor, anyone with a device is using and that is the correct stat to consult if you are building something that everyone in the world will access. [00:50:14]

But that's not true for most startups. Like if you're building a startup that targets like some industry, that American businesses, is, targets a problem that American businesses need solved, then like it doesn't really matter what the mo-, mobile performance in, you know, different outside of that target industry, I guess are then it's like, like what you said about his like tone and delivery. [00:50:45]

I think a, to me when I read this, a core part of what, that I think he's overlooking is that not everyone is trying to ship something that 100% of the people in the world can access smoothly and quickly. Like, and that's fine. Like, you know, not everything needs to target everybody in the world. So, I don't know, I, I guess that that's one of my takeaways. [00:51:09]

That's one thing that I think is missing from this, otherwise very technically complete blog post. [00:51:30]

1-acemarke: I think it's also true that an awful lot of app teams out there ought to be spending time thinking about like even just basic bundle sized stuff and they aren't. [00:51:37]

Npm attack, Shai-Hulud round 2

2-vcarl: I do wanna talk about the NPM hack that is ongoing Shai-Hulud, the sand worm. [00:51:48]

I want to call out. As far as I know, aikido.dev has been like the security researchers who have announced this, like uncovered it and then analyzed it and shared it. [00:51:55]

Analysis of its evolution in code from Sept

2-vcarl: They had a really good analysis of the evolution of the code, of the attack of this worm from September, and I noted in that when I was rereading it after this, you know, new, new attack, they had shouted out that it appeared that they still had more credentials in reserve. Like they had cracked more credentials than they had actually used. [00:52:06]

And sure enough, this, you know, round two attack in their analysis of of it this time around, they note that it was timed just before NPM's deadline for revoking old tokens. So like very clearly they had a lot of tokens that they had compromised previously that they were now taking advantage of before they, before they lost access to it, before those tokens were no longer valid. [00:52:29]

And I guess to reiterate, we've talked about, we talked about this attack before, I would say this is, this represents the current cutting edge of malware. It is using all sorts of fascinating root execution, like privilege escalation. I saw discussion of it, starting a docker container, mounting your file system to that privileged environment and now suddenly it has privileged access to all sorts of files that it couldn't have if it was just running in your shell. [00:52:48]

There's stuff like that that's pretty fascinating and other things like if you have a Claude installed, it will prompt Claude to say, "Hey, look around this file system for secrets." like that is very cutting edge malware. To me, it's, it's not just writing its own code. It's not just a worm that is trolling your file system. [00:53:14]

It is taking advantage of other tools that you take advantage of to attack you. So it's, yeah. That's not great. [00:53:32]

1-acemarke: I mean, like, big picture, it's almost, it's almost surprising how many widespread pieces of malware have been very dumb and weren't as nearly destructive or smart as they could have been. And like think of how much damage we've had collectively as an industry over years with only a lot of those dumb malware. [00:53:39]

And now we're starting to see some people write more intelligent malware. [00:54:01]

2-vcarl: Yep. Yeah. 'cause a month ago, or two months ago, whenever it was, there was a different NPM hack that managed to get into the debug package, which is massively widely used. And I assumed that it was the same attackers as this attack because it's, it, it resembled it in a couple of ways, except that it was dumb. It was so poorly executed. [00:54:05]

Like they got close to unprecedented access to the NPM ecosystem like. This is one of the first times that that previous attack, the debug attack, was one of the first times that I saw, "here's this compromised version. Let me check my file system. Oh, yep, there it is. I've got this." [00:54:26]

So yeah, they just straight up fumbled the bag there. My theory here, having paid attention to this, it seems like there's some hacker group that may have compromised, set up a phishing tool set, you know, set up tools for other malicious actors to run phishing attacks. And it feels like two different hacker groups took advantage of those tools to target NPM maintainers. [00:54:45]

And only one of them is actually technically competent enough to take full advantage of the access that they got. So yeah, I believe we've shared these resources before. [00:55:13]

Our plan for a more secure npm supply chain from September

2-vcarl: And GitHub put out our plan for a more secure NPM supply chain, so they're still working on that clearly. [00:55:23]

NPM update on token management changes

2-vcarl: They also just released an NPM security update earlier this month in November, November 5th. [00:55:29]

⚡ Lightning round ⚡

2-vcarl: Mark, you want to just read through any of these lightning rounds that you wanna call attention to? Okay. [00:55:34]

TS 6.0 hopefully Feb 2026, 7.0 (native) soon after (more details in the TypeScript.fm podcast)

1-acemarke: TS six and TS seven are hopefully gonna be coming out early next year. TS six is still the current TypeScript code base, but with some changes to defaults and deprecation. And then TS seven would be the native implementation in go that they're working on. [00:55:38]

So a couple different updates on the release plans there. That's going to be very, very exciting. I am excited to have TypeScript compiler 10 times faster. [00:55:54]

Latest TC39 proposal updates

1-acemarke: Also there were some more. The latest TC 39 proposals meeting as usual, advanced a number of different proposals to different stages. A couple of things that look interesting. [00:56:03]

There's a promise do all keyed, which is essentially promise dot all but for an object. And then I am excited, un irrationally excited about object keys length, which is literally just to get the size of the number of keys in an object instead of object keys, parentheses, length. [00:56:13]

Chrome (and other browsers) wants to remove XSLT from the web platform

2-vcarl: Chrome, and a couple of other browsers want to remove XSLT from the web platform. XSLT is a, what, domain specific library for transforming XML? [00:56:32]

1-acemarke: XML transformations within a browser. So you, you send out an XML document from the server, and then you have a purely client side declarative transformation that like converts it into HTML. [00:56:42]

2-vcarl: It exists. I had no idea that it was a browser feature. I've known of it as a tool that exists, but I had no idea it was baked into the browser and they're looking to remove it and I'm okay with that. But certain people who I guess use it for one thing or another have been running a campaign to say, "no, please don't. What about RSS feeds?" But yeah. [00:56:54]

“Your URL is Your State”, and David K’s “Goodbye, useState” talk

1-acemarke: Going along a bit with the whole use the platform thing, more people should be putting some of their state in the URL and there was a very good article on using the URL as state. And then along with that, another video from recent React Summit that's probably paywall at the moment, but I think he's done a couple previous versions of this at different conferences. [00:57:14]

David Kourshid has a talk on goodbye used state, similar to his goodbye use effect. It's hilarious, it's funny, and it also points out why you shouldn't be using actual used state all that much. [00:57:33]

Aiden Bai’s “React Grab” util

2-vcarl: Aiden Bai, who did millions js put out an interesting new tool called React Grab, basically letting you, you know, you, is trying to solve the problem of when you tell AI like, "Hey, make this thing different." And then it goes, "I don't know where that is. Here's your browser, but I don't know where that is in the code base." [00:57:46]

And so this is a tool that helps map similar to how you can use dev tools to highlight an element. This is taking that kind of behavior where you highlight an element in your browser and it connects back to the actual source code that produced that element as a means of giving AI a head start on finding what code to use, which seems super cool. [00:58:03]

I questioned the wisdom of the recommended get started thing, which is just to add a script tag to unpkg. I don't know. Seems, seems slightly sketch, but also for also seems really easy to, to get started. [00:58:25]

Creating a custom Node module loader to import from Bittorrent

1-acemarke: One thing that caught my eye in terms of like, this is awesome and you should never, ever do this, was implementing a node module loader that imports from BitTorrent. [00:58:39]

Okay, great. That's possible apparently. [00:58:48]

2-vcarl: Love that. I do love BitTorrent. You know, as we were talking about decentralized technology a little bit earlier, like, man, what a highly resilient, decentralized technology. But yeah, well, hey, you know, maybe if we're gonna tell you, if we're gonna encourage people to do decentralized technology building on the shoulders of giants, like it, man, if you want it to like never stop working, ever, sure, import your code from BitTorrent, probably it's not gonna work very quickly, but given the right underlying seeders that would, that may never go down. Pretty interesting. [00:58:52]

Ryan Carniato’s stream on researching “async signals”

1-acemarke: Earlier I mentioned Ryan Carniato streaming and talking about async signals. Here's the six hour livestream video if you want to watch that and or throw it into a summarizer somewhere. [00:59:22]

Details of building Node’s TS type stripping support

2-vcarl: I'll shout out the details of building nodes, the node type, script type stripping support, just 'cause I, man, I do love a technical writeup and that is, that was a massive feature release, just like the ability to use node to run TypeScript code without doing a compilation step. Was pretty cool. And so here to here to signal boost a post from the author of it. [00:59:33]

The Web Animation Performance Tier List

1-acemarke: And one more, since we spent much time talking about the, the web platform, the author of the motion animation framework put up a really good post comparing all the different ways you can do animations on the web and talking about some of the performance trade offs. [00:59:58]

2-vcarl: Super good. Cool. [01:00:12]

Conferences (React, Javascript)

2-vcarl: Into some conference news. [01:00:14]

We don't really have much 'cause it's the end of the year and all of the upcoming conference things don't show anything for like January or February. [01:00:15]

CFPs

1-acemarke: Well, we don't have much of a list here, but I can say that I've actually been doing my own, trying to prepare CFPs for next year and it ended up making a database of conferences and like my own personal list is like dozens of them. [01:00:22]

And I can tell you there several conferences have submission deadlines like by November 30th s Why? I'd say there's a lot more conferences out there that knew existed until I spent several evenings spent researching them and trying to put this database together. [01:00:35]

2-vcarl: I've tried to do that consistently over the past three years for this podcast and holy shit, there are so many conferences. It is absolutely bananas. Some of them are even fraudulent, so it's like you, you actually gotta them. So yeah, it's a lot. But okay. [01:00:47]

React Paris (Also a community survey)

2-vcarl: All that to say, I am aware of, React paris has a CFP currently open, but that's gonna be in March. So if you're looking to talk, then they've got a CFP open, you can do that. [01:01:01]

JSWorld CFP closes Dec 31, notifies by Feb 1

2-vcarl: JS World also likewise has a CFP that closes at the end of December. [01:01:12]

Ending

2-vcarl: Thank you everyone who has managed to stick around for this, you know, hour and 15 minute recording session. [01:01:18]

1-acemarke: Funny we said we didn't have a lot of main content for today and go figure. We had a lot to say about stuff. [01:01:24]

2-vcarl: Yeah, right. I give us a, give us a blank slate and we will fill it. Boy howdy. [01:01:29]

1-acemarke: Hopefully the discussion has been useful. [01:01:34]

2-vcarl: That is my hope. I, if not useful at least. Interesting. Cool. Thank you for joining us. We normally, I say we'll be back on the last Wednesday of the month, but the last Wednesday of next month I think is [01:01:36]

1-acemarke: December 31st, [01:01:48]

2-vcarl: so I don't know, we're probably not gonna do it on the last Wednesday of next month, but we'll be back [01:01:49]

1-acemarke: somewhere about that timeframe approximately ish. [01:01:54]

2-vcarl: Before the end of this year. [01:01:57]

Yeah. Generally, I say we gather sources from all sorts of news feeds and whatever, but Mark, you've done a good job of being my source lately. So mostly we get news from #tech-news-and-reads, or at least that's where I get it. [01:01:59]

I don't know where Mark gets it. [01:02:11]

1-acemarke: All of the above newsletters plus like Hacker News and Twitter and all the other social media feeds I obsess over. [01:02:13]

2-vcarl: But yeah, we do subscribe to this week in React by Dev React status next year. It's weekly. Mark and I are both subreddit mods of React js. But yeah, if you see anything that seems useful that you might want us to discuss, drop it in the #tech-news-and-reads channel. [01:02:20]

I'll at least read it. I may not bring it in, but yeah, if this is a show that you get value from and wanna support, the best way to do so is by telling people about it and submitting a review that'll help us get discovered and whatever. [01:02:36]

Cheers. Thanks so much. [01:02:48]

1-acemarke: Happy Thanksgiving. [01:02:50]

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

Reactiflux — Tue, 28 Oct 2025 16:00:00 GMT

[00:00] Intro
[00:46] New releases
- [00:49] Immer 10.2
- [01:55] ArkType ArkRegex (typed regex)
[02:41] Main Content
- [02:45] React Conf
  - [02:50] Official ReactConf 2025 Recap
  - [02:57] Introducing the React Foundation (also from Linux Foundation, Meta engineering, and Seth Webster)
  - [17:03] 19.2 (Activity, useEffectEvent)
  - [17:27] React Native news
    
    [17:32] New architecture only from v0.82
    
    [18:52] Vega OS announcement
    
    [19:04] Vega introduction at React Conf
  - [22:36] Joe Savona’s “Exploring React Performance” talk
  - [23:26] Ricky’s “Async React Part I” and “Part II” (repo)
  - [27:12] Async React Working Group
    
    [27:35] First discussion of more docs ideas
- [28:27] Remix v3 announcement
  - [29:03] Announcement demo timestamped breakdown
  - [31:28] Updates syntax can be customized?
- [34:44] I built the same app 10 times (code)
  - [37:57] Same author as React Won by Default and It’s Killing Innovation
- [43:33] Solito 5
- [46:49] Next 16 and Directives debate
  - [46:56] Next 16 released
  - [49:41] Directives and the Platform Boundary
- [50:34] Technical critique of Next App Router: Everyone Hates Next.js
[54:56] ⚡ Lightning round ⚡
- [54:58] ViteConf roundup
- [55:49] AWS Outage Postmortem
- [57:10] Voltra
- [58:10] Building fully native apps with EAS
- [58:52] React Native \<\> Imgui
- [59:53] Lodash maintenance foundation
- [01:00:45] Build Your Own Key-Value Database
- [01:02:24] Jared Palmer asking for GH PR suggestions and giving some technical details
- [01:03:54] Node 25 with JSON.stringify improvements
- [01:04:15] Cloudflare vs Vercel CPU benchmarks and perf optimizations
- [01:05:07] FF Interop Feature Request Rankings
- [01:05:53] Vjeux’s History of Prettier
[01:10:41] Conferences (React, Javascript)
- [01:10:43] React Native London Nov 13-14 London, UK
- [01:11:26] Use code `TMIR10` to get 10% off
- [01:11:42] Wey Wey Web Nov 17-18 Malaga, Spain
- [01:11:49] React Summit Nov 18, 21 New York, NY, USA
- [01:12:10] React Advanced Nov 28, London, England
- [01:12:33] React Paris CFP is open
[01:12:49] Ending

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]

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: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: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:30]

Terrifyingly so. [00:42]

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

New releases

Carl: Let's start with some new releases. Mark, tell us about Immer. [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: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. [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. [01:26]

Yeah, should be. [01:45]

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

Mark: And I will also hopefully turn this into a conference talk. Nice. [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. [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. [02:12]

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

Main Content

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

React Conf

Carl: The React conf happened, what, three weeks ago, and a bunch of new stuff came out of there. [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. [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. [02:57]

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

Mark: Basically. Yes. [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. [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. [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. [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. [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. [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?" [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? [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. [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. [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. [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. [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. [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. [09:12]

Carl: Yeah, I would agree with that. It's a really big deal that they're moving in this direction. [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. [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. [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. [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. [10:42]

Yeah. [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. [11:05]

Carl: I think the React core team has like 10 engineers. [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. [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 [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. [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. [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. [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. [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. [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. [13:43]

And [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. [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 [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. [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. [15:00]

So like hopefully the mode of making conferences self-sustaining is not making them cost a thousand dollars. [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. [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." [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. [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. [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. [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. [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. [16:44]

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

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

Carl: Cool though. Yeah. So I don't know. I don't know if there's more to say there. [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 [17:03]

React Native news

Mark: Mo as like as usual, you wanna talk about the React Native-y things? [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. [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. [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. [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. [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. [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. [18:52]

It was towards the end of September that they actually announced it, but [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. [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. [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. [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. [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. [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? [20:48]

Mo: Yeah, it's c plus plus on top of Linux. Basically it's a Linux. Or is a Unix based system. [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. [21:05]

Curious to hear more technical details about the OS layer here and how it… [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. [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. [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. [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. [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. [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. [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. [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. [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. [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. [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. [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. [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. [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. [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. [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. [25:48]

So I highly, highly recommend watching Ricky's talk. He also put up the demo code as well. [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. [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. [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. [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. [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? [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. [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. [27:53]

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

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

Remix v3 announcement

Carl: Should we get into Remix V three? [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. [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. [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. [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. [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. [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. [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. [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. [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. [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. [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. [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. [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. [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. [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. [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. [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. [34:08]

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

Carl: I will happily continue reading code and critiquing. [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. [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 [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. [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. [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. [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. [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. [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 [36:15]

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

Carl: Oh great. Okay. Okay. So you built it an analog, which is an angular type thing. [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 [36:41]

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

Carl: Qwik city to qwik Sure. Solid start spelt Kit Tan Stack with solid and then Tan Stack with React. [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. [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. [37:25]

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

Carl: Yeah. Okay. Alright. This is more confusingly presented than I realized. [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. [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. [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. [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. [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. [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. [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? [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. [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. [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. [40:23]

Pretty [40:37]

Mark: much. Yeah. [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. [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? [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. [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. [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. [41:41]

Mark: To be clear, like React has got itself has gotten much bigger over the years. [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. [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. [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. [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. [43:11]

Mark: Good way to put it. Mo, tell us about Solito. [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. [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. [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. [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. [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. [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. [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. [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. [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. [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. [46:35]

Next 16 and Directives debate

Mark: Okay, the last major topic for the day next 16 and directives. [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. [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'. [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. [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. [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. [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. [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. [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. [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. [50:11]

Carl: I'll say it. They're bad. It's too much magic. I hate it. I'm not a fan. [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. [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. [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. [50:57]

So very worth reading. [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? [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. [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. [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. [52:40]

Mark: I think it really does speak to the overhead and mental complexity of trying to juggle all these things. [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. [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. [53:28]

We're building tools to solve real problems, but there's more and more to juggle in your head as you go. [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. [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. [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. [54:26]

⚡ Lightning round ⚡

Mark: Alright, moving on to the lightning round. [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. [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. [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. [55:49]

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

Mo: It's funny that the, uh, internet is backed by Dynamo db. [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. [56:31]

East one. Yep. You all [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. [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, [56:57]

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

Mo: At least it was that, which was great. Cool. Moving on. [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. [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. [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. [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. [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. [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. [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. [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. [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. [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. [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]

TMiR 2025-09: React 19.2 on the horizon; npm is still getting compromised

Reactiflux — Fri, 26 Sep 2025 16:00:00 GMT

[00:52] New releases
- [00:54] TanStack Start 1.0 RC!
- [01:13] react-window 2.0 rewrite
- [01:44] Apollo Client 4.0
- [01:59] Redux Toolkit 2.9.0
[02:47] Main Content
- [02:52] React 19.2 coming soon?
  - [03:24] in canary, with docs
    
    [07:18] last React Labs post mention
  - [11:43] useEffectEvent in canary and has docs
  - [15:47] Compiler inferring function names
  - [16:08] Docs for eslint-plugin-react-hooks, including rules and compiler issues
- [17:15] React Native 1.0 on the horizon
- [22:02] “React Won by Default – And It's Killing Frontend Innovation”
  - [22:18] Inevitable HN argument
- [27:54] Ricky on Ryan Carniato’s stream talking about scheduling and demoing using modern React features
- [33:41] Server Components
  - [33:44] React Router RSC framework mode preview
  - [34:36] also middleware is now stable
  - [34:44] Krasimir Tsonev’s “Can I Use RSC Today?” support matrix and experimental Forket “RSC without a framework” build tool
  - [35:43] RSBuild support for RSCs
  - [35:55] Useful post on parallel and recursive route rendering
- [36:35] All the NPM compromises and malware this month
  - [39:47] npm package maintainer Qix
  - [39:48] CrowdStrike npm Packages
  - [40:16] GitHub Actions npm Token Theft
  - [41:01] GitHub response
[42:00] ⚡ Lightning round ⚡
[58:51] Conferences (React, Javascript)
- [58:53] React Alicante Oct 2-4
- [59:13] React Conf is back, Oct 7-8 Las Vegas, NV, USA
- [59:29] Remix Jam, Oct 10, Toronto ON, CA
- [59:43] ViteConf Oct 9-10 Amsterdam, Netherlands
- [59:52] JSConf North America Oct 14-16 Chesapeake Bay, MD, USA
- [01:00:03] JSConf Chile Oct 24-25 Santiago, Chile
- [01:00:10] React Native London Oct 30-31
- [01:00:22] React India Oct 31 Nov 1 Goa, India
- [01:00:26] Wey Wey Web Nov 17-18 Malaga, Spain
- [01:00:39] React Summit Nov 18-21 New York, NY, USA
- [01:00:48] React Advanced Nov 28th, London UK
[01:01:08] Outro

This Month In React - September 2025 (SM)

Carl: Alright. Hello everyone. Thank you for joining us for the September edition of this Month In React. As we, uh, get together and recap what's going on with React, react Native and the web, we're coming to you live from Reactiflux, the place for professional developers using React. I am Carl. I'm a staff product developer and freelance community leader here in Reactiflux, where I do community programs like these events and build tools to help keep the community operating. [00:00]

Mark: Hi, I'm Mark. My day job is working at Replay.io and digging into the guts of React and its internals. And in my copious amounts of spare time, I'm currently rewriting the guts of Immer for faster performance. [00:23]

Carl: Yeah, you did a live stream on that. That was cool. [00:34]

Mark: Yeah, that was a lot of fun. [00:36]

Mo: And my name is Mo. [00:37]

I am the head of Mobile at Thedo. And yeah, I spent a lot of time in the React and React native communities, speak at conferences here and there, and organize the React Native London Meetup and conference, which is coming up in November. [00:38]

Carl: Yeah, more on that later. [00:51]

New releases

Carl: Let's jump into some new releases. [00:52]

TanStack Start 1.0 RC!

Carl: We're gonna talk more about this in depth in the main content section, but Tan Stack start has released a 1.0 rc, so that should be coming together. I've tried playing with this a little bit and didn't make it too far. It just ended up being a larger task than I really imagined, but I'm excited about it. [00:54]

`react-window` 2.0 rewrite

Mark: React Window. Just put out a version 2.0. Brian Vaughn did a pretty major rewrite of the library to try to simplify some of the props and add some nice built-in features like automizing of the list items and auto resizing. So you no longer need a resize plugin to handle that. [01:13]

Carl: Oh, that's nice. Okay. Yeah, and react window is efficiently rendering large lists. [01:32]

Mark: It's virtualizing lists. Yeah, so you got a list of, you know, a million items. You can only show a hundred on screen at once, that sort of thing. [01:36]

Apollo Client 4.0

Mark: Also, on that note, Apollo client for GraphQL just put out version 4.0. I know this was a, a pretty major effort to try to improve the packaging, consolidate. Remove a bunch of deprecated features, so that should be a significant improvement if you're using Apollo. [01:44]

Redux Toolkit 2.9.0

Mark: And on my side, I actually just shipped a Redux toolkit 2.9 earlier this month. The biggest thing there is I made a bunch of perf optimizations to RTK query, especially for cases where you've got a lot of components that are reading from the same cache entry. And we also added a few new options and bug fixes, but the perf improvement and some in-flight requests cleanup was, were some of the biggest pieces there. [01:59]

Carl: Okay. Yeah. Not too many new releases for open source libraries this month, I guess. [02:25]

Mark: Well there, there probably were a few more. We just didn't collect them. [02:30]

Carl: Yeah, I wish there were a little bit more consistent standards across the ecosystem for how to publish a list of new releases. Like the GitHub release is, it is pretty good, but it's still only like 60% hit rate, I guess. Something like that. [02:32]

It feels like. [02:46]

Main Content

Carl: Cool though. Let's go into our main content. Can you tell us a bit about React updates? [02:47]

React 19.2 coming soon?

Mark: I don't actually have any real details on this, but Rick Hanlon from the React team tweeted out like yesterday, a screenshot of himself apparently working on release notes for React 19.2, so I would assume it's fair to say that it's probably coming out in the near future associated with that and potentially coming out in 19.2. Although the timing may be a little too soon, we have two React features that have graduated from the experimental branch to the Canary branches. [02:52]

in canary, with docs

Mark: The first one is the new activity component. This has been around in some form in in the experimental branches for. Probably multiple years at this point. It was originally known as the offscreen component, and then they officially renamed it to the activity component maybe about six or eight months ago. [03:24]

And this is gonna be a pretty big deal. So one of the issues with React has always been that built-in state is managed at the component level. And if you unmount a component, then it, you know, both cleans up the effects and they go away. But the state that was in that component goes away as well. And so that's one of the reasons why there's been, you know, so much use of external state libraries like, you know, Redux and Juice end and Jot and MobX over the years is because in order for state to persist, you either needed. [03:45]

To have the state live outside UAC component tree, or you needed to hoist it up to the top and pass it down via context or props and if you unmount a section of the tree that DA and that data could go away. So the activity component is going to allow you to essentially disable and hide a section of the component tree, but react will keep around the state for those components. [04:22]

And in fact this actually kind of goes along with some of the strict mode stuff that people have, you know, complained about for years. The activity component will also unmount the effects for the components that got hidden. People have complained for years, you know, strict mode, double running effects, you know, shows bugs and, and all the other things like that. [04:52]

But part of the point of that has been to work towards, eventually this feature will come out where you can toggle the activity component on and off. And React will run the UNM mounts because the components aren't fully mounted, therefore, they shouldn't have active effects going. But it will keep the state for those components alive. [05:14]

And so you can imagine this could be useful for a couple of different things. One is like a tabs component. Right now, if you have a tabs component, you either stop rendering the other tabs completely as you switch back and forth, or you use something like CSS display, none, which means the tabs are active and in the page, even though they're not even being displayed. [05:37]

And so with the activity component, you can say I want to pre-render the content for the other tabs, but it's not actually attached to the page until we swap back and forth. But they could still persist the state. So if someone goes back and forth between the different tabs and makes some edits, then. [05:59]

You know, that still stays alive. There's a comment in the chat that the naming choice for the component seems very strange to me. I agree. I didn't like it either. There was some rationale in the PR that actually renamed it to activity. I don't remember what it, what it was specifically off the top of my head, but they, I think it was that like, it's more about is the component active rather than is it quote unquote off screen. [06:19]

Yeah. But I, I don't entirely buy that myself. [06:46]

Carl: Yeah, right. Because this is like hitting that midpoint between that decision point of do you render null or do you render the dom with styling to suppress its visibility. And so I guess this is like smack in the middle, like the internal representation of all of that. [06:51]

Dom remains. But you don't use styling to hide it, which is great for cross-platform stuff. 'cause like there wasn't a cross-platform way to hide something as far as I know before. [07:07]

last React Labs post mention

Mark: So if I, if I look back at the last React Labs post from April where they talk about, you know, the plans for the activity component, there's a section there that says, in the future we may add more modes for activity. [07:18]

One of them could be content visible, but keep it unmounted and pause dom updates. Another is the ability to destroy state for hidden activities if too much memory is being used. So I think part of the mindset is it's not just like a bullion toggle, it's we're shipping with two mode options that are like a bullion toggle for now. [07:31]

But we envision some possible additional modes for this down the road. [07:57]

Mo: And, and you know, this is like particularly interesting to me because this has like been a long standing problem in the React native space when you're dealing with native apps. And I, I doubt this will work out of the box with React Native, but I think it's gonna be one of those things which will eventually get there. [08:02]

And hopefully the new architecture makes this easy for the, the core team to adopt and like make sure that those APIs are working correctly. But it's a classic issue, especially when in Native world you're dealing with this concept of like stacks of pages on top of each other. You really don't want the, the stacks that aren't visible or the pages that aren't visible in your stack showing or getting all of the DOM updates, or in this case this, the updates to the actual screens whilst they're inactive because that's a massive performance bottleneck on native devices. [08:17]

And so this type of thing, people have massed over it in the most dirty ways possible and hacky ways possible in, in the React native world. It's been like a longstanding problem because if you, you know, unmount them and then remount them and reestablish the state, there's sometimes like a flashing white screen before the actual components reload. [08:46]

Then you need to delay the transition because all of these things are like transition with page transitions and native. So it's basically to say there's a lot of complexity and if there's a native React way to deal with this, that ties into navigation on the native device as well, then I think it's gonna be a game changer and it'll simplify and fix a lot of performance issues that people often have with their React native apps. [09:05]

Mark: Yeah, I, I know we've, we've had a couple of open issues on the react-redux repo with people complaining that. Components that are off, quote unquote offscreen in the React native stack are still subscribed to Redux updates and taking up perfects from running all the subscription logic and asking for us to add random options to make that toggle or something. [09:26]

And so if you know, the activity component ought to be the built-in solution for that. And so that would actually means we don't have to do anything, which is great. Yeah, exactly. [09:48]

Mo: And you know, like some state management libraries have adopted some work around components that you can use for that, but it comes with trade-offs, right? [09:57]

And ideally, your state management library really should not worry about this. This feels like a core react primitive problem rather than a state management library problem. To me, [10:06]

Carl: back to what you said about like the layering of UI and performance problems and like listening to events and things. Fun fact, I've chatted with some people who did React native or like React UI for automotive companies and that was a problem they dealt with like sometimes for certain cars. [10:15]

The reason the UI sucks sometimes is because of this issue and because it's rendering multiple UIs on top of each other and doing all sorts of weird, crazy stuff. There's two [10:35]

Mo: devices that are particularly bad for that. One is Smart TVs and the other one is cars. And the reason for that is both of them are awful processors and like they really cheap out on the hardware because they're cutting costs everywhere in the actual like manufacturing bit. [10:45]

And so something that might run in your web browser with your laptop that like has like several hundred megabytes of RAM per tab. Will, you know, be restricted to 50 megabytes of ram or it'll get killed by the operating system that lives on the automotive car infotainment system. And this is a big problem for any, like one of those types of devices. [11:01]

And I think a lot of those, you'll be surprised, run on React and like web-based platforms or sometimes even rec native, and it's a big, big issue. So I think something like this. You know, you can fix those issues, but it's hacky and not everyone will do it. So then you'll get really crappy infotainment systems, like you said, Carl. [11:23]

So, [11:40]

Carl: okay. That's probably long enough talking about activity though. [11:41]

`useEffectEvent` in canary and has docs

Mark: So one other, one other feature that's migrated from experimental to Canary, I just saw this one a few minutes ago, is the useEffectEvent hook. This is something that the React team has also talked about for a while, and I actually didn't even know that any progress was being made on this until I just saw the PR announcement. [11:43]

I'm gonna describe this very badly. Someone should correct me on this, but it's almost like a used memo for callbacks where you'll get the latest reference to a. Callback inside when you execute it, but you get a consistent function reference back when you use it. And so this avoids the need to do a workaround where you're like, main, where the, the callback is reading something off of a ref to get the latest value. [12:04]

I know that this is something that had been proposed a while back and then the initial proposal got killed and they said, we'll, we'll come back and we'll rethink this later. And apparently later is finally now. [12:34]

Carl: Later is now. That's great. Yeah. Interesting. I'm, I'm not super up to date on this, so I'm just reading the docs right now to understand it better. [12:48]

Interesting. The, I definitely know that I have used refs. You know, red values off refs because of weird issues. So I'm not quite groking how this solves this immediately, but that's interesting. [12:57]

Mark: So, and okay, so a partial example, and again, this is me going off the top of my head and not even trying to read the post at the moment. [13:09]

So, if you have like a used callback that needs to access a value, you either let the callback get recreated every time, which in case there's no point in the use callback at all, or you have the item in the dependency array, which means it's gonna, the callback is gonna get recreated still when the value changes or you don't rate it all, and oops, now you have a steel value, which is bad. [13:17]

Carl: Right. [13:42]

Mark: So what happens when you want a consistent callback reference that never changes, but it still needs to see the latest value in order to do something useful when it runs. So one workaround for this is you put a use ref a couple lines up in the component that runs first. You assign to it even in like another use effect before the one that you care about. [13:42]

That means it gets updated. Now you've produced this kind of weird sequence of events where I know that the ref has already been updated before the callback ends up getting run. And so part of the point of this hook is to eliminate the need to do that little dance yourself. [14:08]

Carl: Yeah. Okay. That makes sense. [14:24]

I'm reading this list of caveats and it seems tricky. The only call inside effects define it just before the effect that uses them. Do not pass them to other components or hooks. Do not use useEffectEvent to avoid specifying dependencies. This can hide bugs. Sure. Use it only to extract logic that does not depend on changing value. [14:26]

That's quite a set of constraints. [14:48]

Mark: When the new docs came out, and Dan and a couple others wrote the tutorial. There were a couple pages in there that actually referenced this hook as the solution for some of the problems that were being described. Even though the hook didn't exist yet, some of the docs pages also try to make the terminology very unique, where they talk about lowercase e effects as in like, you know, just the generic concept of a side effect versus a capital E effect, which is like a somehow react specific concept that I don't think the docs ever fully defined. [14:51]

And so in, in a way like the use effect event hook, is the React team trained to somehow solidify this. Notional react effect term in a way. [15:30]

Carl: Interesting. Interesting. [15:46]

Compiler inferring function names

Mark: Alright, two other little data points and, and updates Worth noting. The React team merged a work in progress PR to the compiler to try to do and to try to automatically infer function names for things like callbacks that you pass to use effect so that you know when they show, like show up like in a stack trace, they are nicer and easier to read. [15:47]

Docs for `eslint-plugin-react-hooks`, including rules and compiler issues

Mark: And then the docs now have a page for the Eslint plugin of react hooks, including a bunch of information on all the different rules that it cover and that includes issues that'll get flagged by the compiler as well. [16:08]

Carl: Also, yeah, I wanna say on the compiler inferring function names like that is like one of the most quietly mind blowing things I have seen in a long time. [16:19]

I actually commented on the PR to ask like, what if this became a TC 39 proposal? Because this would have saved me days of effort over the life of my career. If there had been a little bit more data about what the heck is throwing an error instead of just like cannot read property of undefined. Oh thi this is quietly one of the mo going to be one of the most impactful changes in a long time I think. [16:29]

Mark: I have actually, even just recently in some of the Immer work that I've been doing, gone in and replaced anonymous arrow functions with a named function just to try to get a better name and a stack trace. [16:55]

Carl: Totally. Yeah, a hundred percent. And the annoyance of assigning an arrow function to a variable versus using a named function and how those are not the same thing. [17:06]

React Native 1.0 on the horizon

Mo: Cool. Let's move on to some React native news, which has gotten people a, a fair bit excited, which is one of the talks that was at React Universe comps that happened at the beginning of this month called React Native 1.0 is on the horizon. This is pretty exciting stuff because it's anecdotally, and I'm sure many people have had the same experience as me. [17:15]

One of the biggest things that people oftentimes use, which is a really, really, you know, straw man argument, but nonetheless is there, is that, oh, react native's not stable because it's not 1.0. I kid you not, when I say three weeks ago we were talking about starting a new project here at Theo and someone brought this up as a reason not to use React Native as one of like the prospective clients that we had because another company who was trying to push them to use Flutter had told them, oh, it's not stable because it's not 1.0 da da da da da. [17:37]

And you know, there's a little bit of fear mongering around this. The reality of it is that React Native has been around for way too long and it's been used in many, many serious production apps for, you know, several, several years now. And so I think this is something that a lot of people have discussed with the React Native Core team over the years. [18:06]

And you know, there's always been a bit of a reluctance on going to 1.0 for various reasons. Um, and so this talk is really interesting 'cause they talk a little bit about the history of that and what the reasons are for that. But really what's happened over the last year is that the release process for React Native has been significantly streamlined. [18:23]

So there are now six releases. Being targeted for every single year. So every other month there being a release from two releases, which was what we had in 2024 and you know, a lot more sporadic releases in the previous years. So there was no really never a schedule to it before where, whereas now there is one of the things that's been happening over the years, but really accelerated over the last, I'd say year, is that a lot of the APIs are being really stabilized, reduced, and the surfaces are being completely trimmed down. [18:38]

And so the whole idea with this is less API surfaces externally means that there's less likelihood for breaking changes in the long term, which helps them feel confident to say, Hey, this is a 1.0 or reaching out sort of monumental point where they can actively say, Hey, this is a 1.0 release. And the other thing is that the React native. [19:06]

Pipelines for building React native Core was quite a manual process in the past, and so what they've done in sort of recent years is worked on introducing a lot more end-to-end testing, some workflows that would test our C bugs and you know, breaking changes much quicker. And so that's really been a lot of the efforts behind the scenes, which you won't see in features and functionalities, but it's really been to the workflow for building React native. [19:25]

And so a lot of this is really moving us towards that direction where there can be at 1.0. And so the conversation isn't. Potentially, hey, there's gonna be a 1.0 in the next few months. Maybe not even in the next year, but it is somewhere there where they're feeling like, okay, we can go ahead to, to basically releasing a 1.0 for React native at some point in the near future. [19:48]

So the React team's gonna be, the React native team is gonna be working on this quite extensively and trying to reach a point where they're happy and so they're gonna be working with a bunch of people to start to potentially put a date on it, which is very exciting. [20:09]

Carl: That is really exciting. That's a long time towards 1.0. [20:20]

But like it would've felt premature I think for them to get, to call it a 1.0 before, or at least they would've had to do a lot of breaking. [20:22]

Mark: Even just waiting for the new architecture to be the default, I think was a big thing. Mm-hmm. Yeah, definitely. [20:30]

Carl: Yeah. And that really seems like it was a meaningful, a meaningful reason to delay, like it was such a large disruption to so many different parts of the ecosystem, but also so essential. [20:36]

Yeah, it feels more truly native under the new architecture, rather than having to like serialize between two independent systems. It kind of reminds me of like when Docker launched because it was a Linux feature, you know, a Linux kernel feature. I remember for years they had like a, if you wanted to use it on Mac, you had to technically run a vm, which introduced all sorts of weirdness. [20:47]

And so that feels, I dunno, this feels technically similar to me in how they like figured out how to not have two independent systems communicating with each other in that kind of way. And now that they've cleared that hurdle, they can get towards a greater level of stability. Cool. Awesome. [21:09]

Mark: One other thing that actually kinda reminds me of, so we had squiggle conf a week and a half ago and one of the talks was from Shelley Vohr, who's part of the Electron core team and she did a talk about automating systems and you know, things like security and repeatability and what happens if the system goes down. [21:25]

And it sounds like a lot of the effort that's been involved on the RN side really is about CI pipelines and automation and turning a manual release process into an automated release process. And you know, having that consistency is a pretty big deal here. [21:44]

“React Won by Default – And It's Killing Frontend Innovation”

Carl: Cool. Drama post? [22:02]

Mark: Drama post. [22:04]

Carl: Yeah, so there was a recent post called React Won by default and it's killing front end innovation. [22:05]

Mark: To some extent. There's nothing new in this post. People have been making complaints about this for years. [22:13]

Inevitable HN argument

Mark: It's a pretty well written post, and it did make all the rounds and spawned massive 800 comment, hacker news thread and responses on Twitter and a bunch of other places. The first argument is that React itself has kind of stagnated that it was a big deal in 2013 when the virtual do solved problems with Angular, but that React really hasn't innovated since then claim, and that things like the React compiler are a bit more of a bandaid. [22:18]

Whereas other frameworks like solid and spelt and quick are doing new and innovative things around signals and ruins and resum ability and other approaches to updating the dom. But the rest of the argument is that. The typical discussion these days for a project is, okay, which framework should we use? [22:48]

Well, let's use React because it has the biggest ecosystem, because there's the most developers available because AI are familiar with it, because there's lots of libraries out there, et cetera. And the phrase that always comes to mind and for me is the old one about no one ever got fired for choosing IBM that back in the day, like IBM was the safe choice for, you know what, whatever tools it is sort of that same principle today. [23:09]

Like most people are not generally choosing React. Because they're specifically excited about suspense or transitions or other things like that. It's the industry standard, so we'll stick with that. And so the article argues that because of that, because the mindset is used, react by default, that it's sort of choking out other frameworks that have had more innovation and newer interesting approaches. [23:39]

And so it ends up offering some suggestions for things to evaluate about scaling and performance and team skills and whatnot. And then tries to counter argue the typical like size of the ecosystem type points. It's a well-written article, like it's not flame bait. The title is is well out there, but it makes a pretty good actual point and it spawned a lot of discussion, like I said, hacker News and a bunch of other places. [24:08]

But I think the really interesting counterpoint to all that. Is Rick Hanlon from the React team put up a very long thread on Blue Sky, which really should be its own blog post at this point where he says that all the frameworks know how to update the do efficiently React has innovated in the past, but it's also, it was so good in the past. [24:34]

People are actually kind of ignoring the innovations they've done since 2017 and 2018, and that reacts focus for the last seven years has been not about how can we make Dom updates faster per se, but about scheduling. Things like concurrent mode, transitions, suspense, even the new activity component builds off of the foundations that they've built for the last several years. [24:59]

Yeah. And so his argument is that number one, when people say react is an innovating, they're ignoring all the new features built around concurrency. And number two, that most people are still thinking about using React in a very 20 16, 20 17 ish sort of way. Most people aren't even thinking about using the new capabilities that React has unlocked. [25:23]

I think he's actually got a pretty good point. [25:50]

Carl: That's fair. I would generally agree with that and like I am very much in that boat, I'll be honest, like I haven't written extensive from scratch, like build an app and react since about that time. The last time I really did that from scratch to like a full production level where I was like exclusively focused on the front end was about that time, like ended around 2021. [25:52]

So I've been following a lot of this, but I haven't used it at the same level of depth that I used to. I have seen somebody who, you know, one of my internet acquaintances who I have a lot of respect for, as you know, both technically and like entrepreneurial and whatever. He's been extolling the virtues of server components for the last couple of months, I think, and it's been on my, you know, it's been somewhere on my to-do list to talk more with him. [26:15]

Mark: Daniel Switz. [26:40]

Carl: Yep, yep. Daniel Switz. Just like I've heard him say some things. It's like, okay, I feel like you get it and I feel like you get it in a way that you could communicate. It's crossed my mind actually to have him and Ricky and or him and Dan or I don't know, a group of people on a stage like this and just like talk about it and be like, what the fuck? What are we doing? How do you do this? So yeah, I don't know. It's like, it's definitely there is innovation happening. I think a lot of the innovation, like there's innovation happening and there's also just like roadblock clearing. It's like, you know, there's the innovative, you build the road, but then you have to deal with the consequences. [26:41]

Like, great, you have this road. Like what is it like to actually use it? And then a lot of the time you realize there are speed bumps and whatever that you didn't realize you were building in the first place. And the fix there is not innovate. You don't just like, well that sucked. Let's build a new road. [27:16]

No, you fix it. Figure out different ways to approach the same problem that have a different set of trade-offs. And so I think that's some of what's being complained about here is that like people are like, we need a new thing. We need to rewrite from scratch. And No, we don't. I don't think we do. So, yeah, I don't know. [27:33]

I guess that's what I, what I have to say there. [27:52]

Ricky on Ryan Carniato’s stream talking about scheduling and demoing using modern React features

Mark: So, sort of on on that note, Ryan Carniato from the solid team routinely does streams where he talks about what he's working on or you, where the ecosystem is going. He and Ricky have had a number of like, actually. Intentional and productive discussions back and forth on Blue Sky and Twitter where Ryan has said, we've got our own version of suspense, we've got our own version of transitions. [27:54]

We're trying to do things this way. And Ricky has put up a demo and said, how does this, here's the React way to do this. How's this compare to the way you guys are doing it? And so Ricky was actually just on Ryan Carniatos stream on Friday and I looked, and it's a six hour long video. No, I most definitely did not watch the video. [28:17]

I cheated and used a summarizing tool to try to gimme a sense of what they were actually talking about. But it looked like they talked about where React has gone and what has changed with all the different concurrency related features. And then I think they tried to take a sort of a classic react. I think it was like a React 17 to do application, and then they updated it live on stream to use all the modern latest React features. [28:38]

So if you want to watch them talking about this for six hours, the video's there. But it's a good example of people who know how this, how these technologies are implemented, discussing them as well as Ricky demoing how you could actually use these in an application. [29:06]

Carl: Yeah. I will say, going back to a point a little bit about, you know, you shared the long thread and made an offhand comment about like, this could really be a blog post at this point. [29:23]

Like the post on Ricky's feed right before that is the, if you all promise not to ask me for docs or blog posts, maybe I'll explain a bit about why creating a cache API for suspense is so hard and it's, oh, I love that you're doing all of this, like social media outreach and everything, but like part of the problem that, part of the reason why nobody understands all of this and you have to do all the social media outreach is because there aren't static available resources for people to read. [29:31]

So it's like, ah, I love that this is happening and it's so good and so helpful. And there's follow up that's not happening that I think is really crucially important. [29:55]

Mark: That's actually been one of my running frustrations and complaints for a while. Ricky and I have actually had some back and forth on this, multiple times on Blue Sky. [30:03]

Yeah. Admittedly, I'm also not sitting here, honestly. I should probably start watching the docs repos so I have a better sense of what updates do happen. That one's on me, but to a certain extent, my, my knowledge of what's in the docs can get a little stale. Right. But Ricky has repeatedly complained that. [30:12]

People keep making the same wrong assumptions about what React has available, why the React team is doing things, et cetera. I've pushed them multiple times this year and said, you know, my answer is go write a docs page. Yeah. That covers exactly the topic you want and to have answered, and it answers it in exactly the way you want This material covered. [30:29]

A lot of people are still not gonna read that docs page, but some people who are already looking at the docs will see it. And when you run into yet another one of these questions on social media, now you have the pre-written answer and you link to it rather than having to answer it from scratch every time you see the same misconception pop up on social media. [30:55]

I, I wanna be clear, I, I am genuinely excited that Ricky has done so much outreach over the last year or so. Even just in the last couple weeks he was, he wrote dozens of tweets on both Blue Sky and Twitter around the threads related to the React innovation by default discussion. And I'm genuinely happy he's doing this much outreach. [31:18]

It's sort of taking Dan's place in that sense. But when your great answers are buried, 15 replies deep in a Twitter thread, no one sees them other than the person you're responding to. And that is the kind of material that desperately ought to be its own blog post, as well as these couple top level threats as well. [31:40]

And so I genuinely happy he's engaging. I would just love to see that material written up longer term. [32:03]

Carl: This is clearly a bit of a cycle, you know, like social, this has been true for years generally. So like maybe this is an opportunity for someone here listening to go through some of the, to go through these threads. [32:09]

Like if you're champing at the bit for an opportunity to have an impact on the ecosystem and on the industry, like this could be a pretty achievable way to do so. Like this content is out there, it exists, but not in a way that's discoverable. So like taking this knowledge that is being produced in ephemeral social media threads and then just like restructuring it, reformatting it into a markdown document and submitting a PR to react could be really effective. [32:24]

I, I'll throw that gauntlet down, like that is an achievable thing that I am probably not gonna do. [32:52]

Mark: People used to say that the real React docs was Dan Abramov's Twitter account, which he then deleted and all that info is gone. I don't expect blue sky to go down, but yeah, like if someone out there wanted to go through some of, you know, Dan and Ricky and whoever else's Blue Sky threads and pull out info and submit docs, prs like that would genuinely help the entire ecosystem. [32:58]

Carl: Yep. Right. And it doesn't need to be perfect first. Drafts are so good. First, the first draft is so hard and going from first draft to published thing is still a lot of work. But man, just getting a first draft out is often the thing that tips it over the edge into actually happening. Yep. I'll just say that if anyone's looking for something. [33:20]

Mark: Love the idea. Alright, moving right along. [33:38]

Server Components

Mark: A few different updates related to server components this month. [33:41]

React Router RSC framework mode preview

Mark: The biggest would be that React Router now has RSC support in their framework mode builds. So React Router, as I understand it now, has three different modes. There's sort of the, the traditional client side only, here's your list of routes mode, there's a somewhat more complicated data mode, and then there's the full blown full build framework mode. [33:44]

And so I believe they previously announced some RSC primitives available in data mode. And then I believe the framework mode is now taking those and expanding on them somehow to make it available for the full build. So, you know, again, having more RSC options available besides just next is a pretty big deal. [34:09]

And especially when it's built into something as widely used as React router. [34:30]

Carl: Yep. Love that. [34:34]

also middleware is now stable

Mark: They also announced that React router now has stable middleware support as well. Your routes can now have middleware. [34:36]

Krasimir Tsonev’s “Can I Use RSC Today?” support matrix and experimental Forket “RSC without a framework” build tool

Mark: Krasimir Tsonev, who is a React educator and has been around for a while, put up a nifty little support matrix called, can I use RSC today, where he tried to do equivalent bits of RSC usage and features across several different tools from next in, in Remix and Waku and various other tools. [34:44]

He was also very curious. I, I actually talked to him at React Summit in, in June, and I think this is what. And he was talking to a couple other folks, and I think this is what spawned him doing that deep dive where he was actually kind of bothered by the fact that server components require a framework. [35:07]

And so he went off and ended up implementing his own tool called for cat. Which is supposed to be somehow a proof of concept for using an RFC without an actual framework per se. So sort of a more primitive, granular client server separation build tool. [35:24]

RSBuild support for RSCs

Mark: Speaking of build tools, I saw mention that there is a set of plugins available that try to add some RSC support to the RS build, rust based bundler as well. [35:43]

Useful post on parallel and recursive route rendering

Mark: Finally, I also saw a good blog post that talked about techniques for doing parallel and recursive route rendering with RSCs. As Carl mentioned earlier, all this stuff is frankly outside of my experience, I've never tried to render, you know, RSCs much less do parallel and recursive stuff, but it clearly, people are out there experimenting with these things and that's good. [35:55]

Carl: Oh man. I'm looking at the blog post. You mentioned React server components without a framework and it's got a mention of Flux. Oh, throwback. Yeah. I mean we're Reactiflux because for about a six or eight months it was React and then you pair it with Flux and that was how you do UI and state management. [36:15]

So it's wow, throwback. That's a long time. [36:33]

All the NPM compromises and malware this month

Carl: Alright, little bit of a roundup on. Vulnerabilities and security incidents on MPM. There's been a lot this month. [36:35]

Mark: I think that the first one happened late last month, and we mentioned it briefly. Yeah. And then there was just like this constant flood of new compromises, new vulnerabilities, all kinds of packages being taken over, ranging from crypto miners to like full-blown credential stealing. [36:44]

It's, it's been pretty bad out there folks. [37:02]

Carl: Right? So last month. NX was compromised, which is discussed in this set of links that we have here. I'll send one at a time as we get into it, but yeah, so it, what we've seen has been everything from like pretty, there was a targeted attack that would do like intercede, crypto payments and sub out addresses for, you know, an attacker's wallet actually that had a small innovation in that category of attack where it would generate an address that was visually similar to the one that you had used to try and escape. Notice I heard that attack only got like $50 or like less than $500. I've seen some conflicting numbers, but like generally not effective, did not achieve its goals. [37:04]

But like it hit debug. Like it hit a package that I saw the security alert go out and I was like, oh, that sounds like something that I might use. And I checked. I'm like, yep, a bunch of projects on my computer were using that package. That was the one that got targeted with crypto interception, but previously, I think it was nx, was it last month, that we had the people who were stealing credentials and using AI to generate other code to steal credentials. [37:50]

Like, ah, that's the worst attack I've ever seen. And the only reason it wasn't worse was because of the limited scope of compromise. So like I was primed seeing that innovative, highly effective attack when I saw this massively widely distributed compromise of debug. And I have a little bit of egg on my face regarding this because I had pinged in the node Discord that I help operate saying like, oh, you need to look at this. This is awful. And it ended up not being as bad as I thought because that was a crypto miner, not a credential stealer. [38:19]

Mark: The attack itself seemed like a pretty big deal, and then it was almost sort of wasted on, well, it has to lead to you accidentally build a client side app that has the compromised version built into it. [38:54]

Carl: Right, they managed to successfully target one of the single most widely used packages. And completely squandered it by using it to execute an attack that had such limited application that they just didn't get anything. So like that's just straight up, like they screwed up, like they achieved a massive level of success and just like immediately fell on their face and did nothing with it. [39:08]

That's just a miss. Like that was just luck, that it wasn't worse than it was. [39:34]

Mark: But on the, on the flip side, the article that's talking about the ongoing supply chain attack did do a bunch of credential stealing, targeting a bunch of packages like [39:38]

npm package maintainer Qix

Mark: tiny color and a [39:47]

CrowdStrike npm Packages

Mark: bunch of CrowdStrike packages. Yeah. I don't know the extent of like what sites got hit because of that compromise. [39:48]

Yeah. But I believe that one's, that one had did a, done a pretty good job of finding credentials and publishing them on either, I think it was like either creating a new GitHub repo or creating a new specially named branch in GitHub repos to try to exfiltrate the credentials. [39:57]

Carl: Yeah. Oh, I was just reading this one actually. [40:14]

GitHub Actions npm Token Theft

Carl: It was, they had, they, somebody had added a line to the GitHub action that did, that would echo out the title of the PR and because it just did an un escaped string, you know, echo this. You could just terminate that and then run whatever you wanted. On the GitHub action, like, do not let any arbitrary person run whatever script they want in your seat. [40:16]

Like, oh man, that it's, that's pretty bad. And also, oof, this is CrowdStrike. Like, remember CrowdStrike and how they took down like every, like air travel around the world from another security problem that they had, and oops, they're a cybersecurity company where preventing attacks is their job. Oops. Yeah. [40:38]

I don't understand how they're still operating successfully. [40:57]

GitHub response

Mark: So, GitHub and NPM did actually put up a, a, an announcement saying that they're gonna be doing a lot of work to try to tighten up. Publishing of packages down the road, they're gonna be making changes to two fa it says they're gonna deprecate time-based passwords. [41:01]

That sounds like it's gonna end up being a, a big deal. I don't fully understand the implications yet. And, and they said they're gonna, you know, take time to roll these changes out. But that one seems like a big deal. We're also making and trying to apply more limits to tokens and work on better trusted pet publishing workflows as well. [41:20]

Interesting. [41:40]

Carl: Yeah. That's all important and useful, but like also, I don't know if there, if you just, if somebody opens a PR to your CI, that adds. A vulnerable un escaped string. Like it doesn't really matter how, what your authentication or publishing workflow looks like if that gets merged. Like you're vulnerable. [41:41]

So dunno how, dunno what you do about that specifically. But, okay. [41:56]

⚡ Lightning round ⚡

Carl: Let's hop into our lightning round. [42:00]

Porting Modern TypeScript to Run on DOS

Mark: I love a good article that just goes into absurd amounts of detail on a ridiculous thing that someone's trying to do, but they commit to the bit fully. And this one was, someone had a. JavaScript based game and they ported it all the way back to work on dos. [42:03]

Like why would you want to, I don't know, but apparently they actually made this work and I love it. [42:21]

Carl: That is insanity, and I also love it spiritually similar to Doom running in TypeScript types, just for no reason. Yep. Love. [42:27]

Cloudflare DDOSed themselves with a bad `useEffect` fetch

Mark: CloudFlare got into the news this month because they had a dashboard failure that cascaded, and believe it or not, it was caused by manually fetching data in a use effect that went into an infinite loop, which also means they weren't actually using like React query or anything like that. [42:35]

Oops. [42:55]

Carl: Yeah, I did hear like none of their services were affected. It was just the control panels that was taken down, so that's good. I also saw Guillermo Roush throwing some shade at the CloudFlare CEO after that. So, you know, drama post. [42:56]

A very lovely writeup of the evolution of css `zoom`

Carl: There's a cute post from Bocoup. There are web consultancy that's had a, a big impact on standards and web platform implementation details. [43:11]

So they, they've heard a cute blog post, the web's most tolerated feature looking into Zoom and how Zoom works. And it is kind, it's kind of cute. I don't know, just like it's a fun look at standards and like how. Cross browser implementation stuff works and how like, oh actually this like totally unstandardized thing just happens to work really well and everyone uses it. [43:21]

So, I don't know. It's cute. It's a cute post from people who are deeply involved in the standardization and implementation process, highlighting a case where like standards like just kind of didn't happen and it was fine. [43:44]

What You Need to Know about Modern CSS

Carl: Anyway, yeah, there was another good post from front end Masters who I, I've just always had a soft spot in my heart for front end masters because they were, that's the first platform that I learned react from. [43:56]

It was like a comparative class of Angular React and Ember, and I was like, oh, react seems nice. So like I owe them a debt to, you know, my entire career. So that's, it's cool. It's nice to see 'em still around and still staying on the ball. They published a post What you Need to Know about Modern CSS 2025 edition. [44:09]

Mark: And it was long too. It was long. [44:26]

Carl: It's big and I appreciate that because I've gone to a couple of conferences and I've seen talk from various people who are more, who work on CSS a little bit more. Una Kravets, I think is who I'm most specifically thinking of, who's wonderful and great and a great speaker. [44:28]

But like I'll see her talk about some CSS stuff and be like, wow, all of this is stuff that I've never heard of and CSS is completely different than what I've used in a lot of my career. That's awesome. And I don't know what to do about that. So this is a great post for me in that situation and going, ah, I need to catch up on like the last six years of stuff that I haven't really paid close attention to as it evolves step by step. [44:44]

So, great summary. [45:09]

Mark: We have a few different posts on browser behavior. So there was I and all from folks who have worked on browsers for a long time, I might add. [45:10]

Fetch streams are great, but not for measuring upload/download progress

Mark: Jake Archibald did one on fetch streams are great, but don't use them for measuring upload download progress points out that you still basically need to use XHR for that instead. [45:21]

Although there's discussion of adding some new options and callbacks to fetch that might accurately handle that at some point. [45:33]

Why do browsers throttle JS timers?

Mark: There was one from Nolan Lawson talking about why do browsers throttle JS timers? So you know, why does that time timeout zero actually be, why is it more like four milliseconds, et cetera? [45:40]

And basically it's because people rate bad code or either intentionally or unintentionally that can do bad things. [45:53]

“How Modern Browsers Work” deep dive, Addy Osmani

Mark: And then Addy Osmani did a pretty long post a, mid-level overview of how modern browsers work overall, going from, you know, parsing JavaScript in HTML in various ways to using GPUs to put pixels on the page. [46:01]

Carl: Yeah, it's funny to me to see, I don't know, I've just been seeing Addy Osmani and Nolan Lawson and Jake Archibald for so long. It's like, man, how great for them to stay on the top of the game for so long. It's great. [46:18]

Biome: Stress-testing WIP `noFloatingPromises` lint rule

Carl: One that I like here. I like seeing Vercel and Biome collaborated on stress testing, biomes new, no floating promises lint rule. [46:32]

I, again, have a soft spot in my heart For Biome, I was a initial backer of Rome back in the day, which was then forked after some maintainer shenanigans into Biome. They never really achieved the original vision, or have not yet at least, which was like unified, like linting compiling, you know, one tool to rule them all kind of thing. [46:41]

That it was called Rome because all paths, all roads lead to Rome, so it was trying to do all of it. They have achieved a lot of their goals, but not quite enough to really meaningfully claim to do all of it. [47:02]

Mark: It's become a pretty solid, a pretty solid formatter, but they never really managed to get into any of the multi tools sharing one a ST side. [47:15]

Carl: Yeah, right. Oh, that was it. It was because you know, you, you would have like Babel and ES lint and TypeScript and prettier and all of those, and all of them were independently parsing ASTs and then operating on. So like that's just a lot of wasted effort. So the, the goal was, the original goal was like one AST, all of this stuff talking to that will be an order of magnitude performance improvement. [47:23]

Mark: Mm-hmm. [47:44]

Carl: But anyway, so enough background, they have a new no floating promises rule because if you don't await or you know, respond to a promise, it can cause all sorts of super weird stuff. They say that, you know, a lot of engineers have campfire stories of floating promises taking down production, which is definitely true. [47:44]

I've definitely, a lot of the weirdest errors I've ever encountered track back to, oh, we didn't correctly wait for this promise to resolve, so this is it. This is a fun, deep dive technical writeup of how do you detect that promise. Has not been waited for. What does it even mean to return a promise when TypeScript has a built-in promise? [48:02]

Like construct? It's a good read. It's a good deep dive. [48:23]

Mark: I should point out that the article was written by Dmitri Metropolis, who just got done organizing Squiggle conf and is also the person who did Doom in Typescripts. [48:27]

Carl: Oh, it is, Love Dmitri. Love that. [48:34]

Bun: How `bun install` is so fast

Carl: There is a good deep dive here into Bun Install and how it's so fast. [48:37]

They say on average it runs seven times faster than MPM and 17 fast times faster than you yarn. It's a large post and it's got a lot of real deep benchmark stuff. Mm-hmm. [48:43]

Mark: I think Lydia Halley wrote that one actually very well written post. Lot of detail. [48:53]

Carl: Wait, was she on React? [48:58]

Mark: I believe she was working for Vercel and left, and I think she actually just joined Bun as a DevRel. [49:00]

Carl: Great. I'm just always here for like a deep technical dive. So many, so many blog posts are just a little bit more surface level, so seeing something more like a white paper, a technical writeup, I just love I, it's such a good window into the real challenges that different people around our industries are encountering [49:06]

Styled-Components fork for perf and React 19 compat

Mark: for folks who are still using style components, the sanity company actually forked the existing now unmaintained library and made a couple major updates. [49:23]

One, to try to optimize the overall performance and another to try to provide React 19 compat. They say they are not maintaining these forks per se, but they have done the work because they themselves still relied on it. And so they've made those, they've published those so that other people can benefit from it. [49:35]

So if you're still work, still using style components, you may want to take a look at that. [49:57]

Vite SSR: Custom `getStaticProps`

Mark: Also saw a nice little post that talked about building your own get static props alike equivalent if you're using Vite for SSR. [50:02]

Dominic Gannaway’s new framework Ripple

Mark: And in the frameworks that are not actually React, but related category. Dominic Getaway, who originally created a React Delight called Inferno and was on the React team for a while, has built his a new independent framework called Ripple, which tries to pull together some new ideas around template compilation and use of JS syntax, but in a way that's different than React. [50:11]

Remix v3: MJ hints “iframe-like async primitives”

Mark: And then Michael Jackson and Ryan Florence continue to drop assorted hints online about what their Remix version three is going to look like. Michael's latest tweets are saying, what if he could just sort of use iframes or iframe like behavior for async loading? And I really just want to see the actual examples at this point, but they're dropping hints about what it'll be like. [50:35]

And oh, the plan is to actually show stuff off at Remix Jam, which I think is coming up next month. [51:00]

Carl: Yep. I am skeptical. I don't know, I, I appreciate the broad strokes of iframe, but the actual security constraints of using iframes is, that's just not, they're not good. It's not pleasant. It's not, you know, that's very like 2003 era web development and we stopped doing that because it kind of sucked. [51:07]

It was hard to make good experiences. If it's not literally in I frames, that's very different. So maybe it'll be better than that. There's an argument to be made that what he is talking about shares significant overlap with the islands style micro front ends. So, I'm not checked out. I'm curious, but I'm skeptical. [51:27]

Unfortunately. It sounds like Mo's having like significant internet challenges in his office right now. So I'm gonna, I'm gonna pull in some of the stuff that would've been, you know, that he wanted to talk about. [51:49]

React Native RFC to remove Old Architecture

Carl: There's been a RFC for React native, for a plan for actually removing the old architecture, the previous way of serializing communication between the JavaScript engine and the native layer. [51:57]

So it's not only, not only is the new architecture default, they are now proactively communi or they're proactively planning how to get rid of the old architecture entirely. Well, that's great. That feels like a big step towards 1.0, like we were talking about before. [52:13]

Cloudflare’s new “Cap’n Web” RPC; GraphQL alternative?

Mark: So CloudFlare announced a new tool called Cap'n Web, which is a RPC system meant for browsers and web servers. [52:28]

And this was created by the same person who, by Ken and Varta, who had created a couple other serialization libraries, one called Capin Proto, and Capin. Proto works with both c plus plus and JavaScript and possibly a couple other languages. And Capin proto is sort of a follow on that's specifically meant for use with web and can be sent back and forth using just plain JSON. [52:38]

I believe the article actually kind of pitches it sort of as an alternative to GraphQL in a way. It actually does a funky little thing where if you make what looks like an initial request for an item and then you get back a promise for that response, you can call map on the promise and. Essentially map over what will be the list of items and say, for example, gimme details on all the child items by their id, but then it'll actually get batched up into a single request. [53:05]

So there's some technical trickery going on there, but it sounds like it's meant to simplify both making a request back and forth and managing the overhead of what would've potentially been many independent requests as well. Thus, the comparison to like a GraphQL style thing. [53:42]

Carl: Interesting. And also, I'll shout out. [53:59]

You know, Cap'n Proto here is spiritually very similar to the challenge, it's solving a problem that's spiritually very similar to the new architecture and React Native, like basically, you know, this RPC is going instead of going across like a native JavaScript layer, like a new React native, this is how do you do a similar type of communication between systems across the network boundary? [54:02]

And the challenge is like the reason you would use something like Cap'n Proto or Protocol Buffers, which you know, there's kind of competitors there is because the serialization costs and the volume of communication if you're using JSON, is just much higher, like converting it into a string. It's basically a string versus a binary data format. [54:25]

Like the, one of the problems with JS is that you're encoding not just the data, but also the structure. You're saying, here's the object, here's the keys, here's what it looks like. And that's. That's information. You know, if you're sending that information across the wire, that's extra effort. If you already have two, two agents on opposite ends of a network and they say, we agree that our communication is in this format, then you don't need to send the format across the wire. [54:46]

So that's the fundamental like reason why you might use one of these tools instead of just sending JSON over HTTP and yeah, it's interesting. This is, it's pretty cool. [55:16]

Expo UI: Building SwiftUI apps

Carl: Cool. The Expo had an interesting post talking about using Swift UI in React Native, so that, that's pretty cool. Like being able to directly, if you're in, only, if you're only targeting a native environment, being able to. [55:26]

Exclusively use native primitives is like a huge win. Like if you don't, you know, it's always good to remove compatibility layers if you don't need the compatibility. So that's really cool. It's it, this looks pretty interesting if you're doing stuff on Mac Os or like Apple TV or things like that. [55:40]

TanStack DB: An interactive guide

Mark: So the TanStack folks recently announced a new package called TanStack DB, which is supposed to be a smart syncing layer on top of TanStack Query that can do things like in-memory filtering and querying of data very efficiently. [55:57]

And so there was a neat post that was an interactive guide to TanStack db and discussing some of the options and some of the things you can do with it. [56:13]

TS 6.0: may switch to `strict` options by default

Carl: TypeScript version six may switch to strict options by default. This is, [56:21]

Mark: hallelujah. [56:27]

Carl: Yeah, right. What a long time coming. Like I have treated this as a deep, you know, this has been step one of setting up a new TypeScript project for me since I've started using TypeScript. 'cause it's always been the best practice. So I love that they are discussing, switching this over. Yeah. It starts almost a decade ago. We began to add certain options beyond, no implicit any in strict no checks. So, yeah, like almost a decade ago. So that's the, that's cool. TypeScript 6.0 will assume that dash dash strict is on unless explicitly disabled, which means specific settings like strict no checks and no implicit any will be enabled unless it's turned off explicitly. [56:28]

Woo. Cool. No implicit any is if you don't turn that off, like you're not really using Patrick, like it's just sparkling JavaScript. So that cool. Love that. Love to see this. [57:05]

Mark: There's a lot of debates over the nuances of what that concept of turning on strict by default actually means. But I would assume that something along those lines would land and yeah, it's way overdue. [57:16]

Shopify’s RN New Architecture migration

Mark: Alright, last couple ones and then we're done with the not so lightning. Lightning round Shopify put up a post talking about their migration to the React native new architecture and went through both some pros and cons and pitfalls of what that process involved. [57:28]

The Bloat of Edge-Case First Libraries

Mark: And then the last one is from James, who has the really funky username that I'm not even going to try to pronounce, but he's been working as part of the E 18 E ecosystem speed up process. [57:42]

In fact, he's the person that I did a stream on a couple days ago where we talked about my work to make the Immer library faster. And his post looks at like, gives an example of, let's say you have a math clamp function that takes some arguments. But you don't want it to crash if someone does something stupid like passing in, you know, a string instead of a number and next thing you know, like two thirds of your function is just validating the inputs before it actually does anything. [57:54]

And he argues that, you know what? This actually ends up being kind of a waste of space and execution time. And that to a certain extent, if someone passes in bad input, that's their problem and not your problem, which I can sort of get behind. [58:24]

Carl: Yeah, interesting. That makes a lot of sense. It's kind of the right, it's a challenge between sharing code and doing it inline how when you start trying to do it inline, you end up re-implementing a lot. [58:40]

Conferences (React, Javascript)

Carl: Cool. Let's talk about some conferences. [58:51]

React Alicante Oct 2-4

Carl: We have in like three days, two days. React Alicante in Spain, October 2nd through fourth. [58:53]

Mark: I will be speaking there. I'm flying out on Wednesday. [59:01]

Carl: Woo. And then you're fly. And then you're flying [59:04]

Mark: all the back and then flying all the way back across, across the world for to attend React Conf. [59:07]

Carl: Yep. I'll be there too. [59:11]

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

Carl: So yeah, react Conf in Henderson, Nevada, right near Vegas. I'm actually gonna be driving from San Jose, so like if you're in the Bay Area a couple days before the React conf, lemme know. I don't know. I'm gonna go hiking, so, we'll, it's gonna be an adventure. [59:13]

Remix Jam, Oct 10, Toronto ON, CA

Carl: Then a couple days after React Conf, Remix is doing their own conference in Toronto, the Remix Jam. [59:29]

So yeah, maybe. We'll, we will see. It'll be interesting to see what they come out with. Yeah, I'm curious. Yeah. [59:37]

ViteConf Oct 9-10 Amsterdam, Netherlands

Carl: Anyway, coincident with that, ViteConf is happening October 9th and 10th in Amsterdam. That'll be cool. [59:43]

Love to see what they come out with. [59:50]

JSConf North America Oct 14-16 Chesapeake Bay, MD, USA

Carl: JSConf is doing a couple of events all over the world actually, so they're doing JSConf North America October 14th through 16th in Chesapeake Bay, Maryland, [59:52]

JSConf Chile Oct 24-25 Santiago, Chile

Carl: and they're also doing re JSConf Chile, October 24th and 25th in Santiago, Chile. [01:00:03]

React Native London Oct 30-31

Carl: We've also got, after that React Native London, October 30th and 31st, [01:00:10]

Mark: and Mo runs that, so you should totally be there and support him [01:00:18]

React India Oct 31 Nov 1 Goa, India

Carl: after that, there's React India October 31st and November 1st, [01:00:22]

Wey Wey Web Nov 17-18 Malaga, Spain

Carl: and then the Wey Wey Web, I think I'm pronouncing that right. It says it's a yay, yay conference, international conference for ux. But yeah, that's happening in Malaga, Spain, November 17th and 18th. [01:00:26]

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

Carl: And then we've got React Summit happening in New York, November 18th through 21st. [01:00:39]

So that's cool. We'll see. Maybe I can make it to that. It's in my hometown, so Yeah, that'd be great. [01:00:43]

React Advanced Nov 28th, London UK

Mark: And then React. React Advanced is November 28th, all and although it's uh, inconveniently the day after us Thanksgiving this year, they had done it in late October, previous years, and I think since they're not doing React Berlin, they bumped the schedule for React Advance to be sort of in the middle where those would've been. [01:00:48]

Outro

Carl: That's everything we got for you this month. Thank you so much for joining us. We'll be back on the last Wednesday of the month probably, although we had to reschedule this month again, sorry. Or we will be back in your podcast feed just as soon as we can. We gather sources from, actually this month we pretty much only gathered sources from Reactive Fly. [01:01:08]

It was a good month for, you know, us staying up to date. Yeah, generally we do subscribe to this week in React, which is a great source. Follow lots of people on Blue Sky and Twitter, the React JS subreddit and just, you know, generally all over the internet. We try and stay in touch. If you see anything that you think that we should be aware of, definitely post. [01:01:25]

Actually, you should just post it to the Tech News and Reads channel here. I would love it if we could have some more chatter going on there and it really does help us stay on top of things and helps me understand it. If, you know, if you post a link and then you and somebody else have a conversation, I will read that and it will inform my opinion. [01:01:46]

So yeah, it's a great way to do it. If this is a show that you get value from and wanna support, best way to do so is by reviewing us on whatever platform you listen to or tell your friends and coworkers about it. So, you know, send 'em a link. Cheers. Thanks so much for listening. [01:02:02]

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

Reactiflux — Tue, 26 Aug 2025 16:00:00 GMT

[00:47] New releases
- [00:51] TS 5.9
  - [02:50] TS 6.0 may enable \`strict\` by default and change other defaults
- [03:46] React Native 0.81
- [05:40] Next 15.5
- [07:10] Preact 11 beta
  - [07:39] Hydration 2.0
- [07:52] Bun 1.2.21
  - [08:54] Native YAML support. Definitely not going to cause any problems
- [10:21] Tanstack DB beta
- [11:30] Ghost v6
[13:09] Main Content
- [13:13] React API changes / updates
  - [13:24] React deprecating the “throw a promise” Suspense trigger method
    
    [16:20] Discussion between Dan, Dominik, and Ricky about how to support multiple React versions (if at all)
    
    [17:43] Github discussion with Joe about why no context selectors API or signals, research into data modeling, and why “concurrent stores” are the current focus area
  - [21:25] PR for “concurrent stores” skeleton
    
    [23:13] Third-party \`react-concurrent-store\` ponyfill package
- [26:39] Lee Robinsons’s “Reflections on the React Community” wrap-up post
- [31:18] Remix doing its own component model??
  - [36:46] Remix 3 and the End of React-Centric Architectures
- [37:21] Popular nx packages compromised on npm
  - [39:43] Last month eslint-plugin-prettier maintainers were targeted, this is a much broader attack
[41:31] ⚡ Lightning round ⚡
- [41:33] React Strict DOM vs React Native for Web in 2025
- [43:34] Faster JSON.stringify()
- [44:56] Node 22.18 unflags TS type-stripping support
- [46:23] Waku switches to Vite’s WIP RSC support
- [47:00] Rari, a fast React framework with RSC support built with Rust
- [47:52] Selecting values from query results, as well as The Useless useCallback
- [48:26] TS+ postmortem (Effect-TS experimental TS fork)
- [50:48] React useTransition update ordering details
- [51:13] “A Clock that Doesn’t Snap”, Techniques for fixing hydration of values like dates
- [51:36] React Cache: It’s about consistency
- [52:26] Self-hosting Next at scale
- [53:26] Server and Client Component Composition in Practice
[54:04] Conferences (React, Javascript)
- [54:06] React Universe Conf Sept 2-4, 2025\. Wrocław, Poland
- [54:14] WaysConf Sept 16-17
- [54:21] CascadiaJS Sept 18-19 Seattle, WA, USA
- [54:26] CascadiaJS Sept 18-19 Seattle, WA, USA
- [54:32] React Alicante Oct 2-4
- [54:51] React Conf is back, Oct 7-8 Las Vegas, NV, USA
- [54:56] Remix Jam, Oct 10, Toronto ON, CA
[55:10] Outro

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

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

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

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

New releases

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

TS 5.9

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

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

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

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

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

Carl: Definitely super cool. [03:44]

React Native 0.81

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

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

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

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

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

Next 15.5

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

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

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

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

Preact 11 beta

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

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

Hydration 2.0

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

Bun 1.2.21

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

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

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

Native YAML support. Definitely not going to cause any problems

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

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

Mark: Is NO, [09:53]

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

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

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

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

Tanstack DB beta

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

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

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

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

Ghost v6

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

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

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

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

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

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

Main Content

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

React API changes / updates

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

React deprecating the “throw a promise” Suspense trigger method

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PR for “concurrent stores” skeleton

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

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

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

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

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

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

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

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

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

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

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

Carl: Interesting. [25:41]

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

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

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

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

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

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

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

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

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

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

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

Remix doing its own component model??

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

October. [36:42]

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

Remix 3 and the End of React-Centric Architectures

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

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

Popular nx packages compromised on npm

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

⚡ Lightning round ⚡

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

Mark: Go for it. [41:33]

React Strict DOM vs React Native for Web in 2025

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

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

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

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

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

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

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

Faster JSON.stringify()

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

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

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

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

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

Node 22.18 unflags TS type-stripping support

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

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

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

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

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

Waku switches to Vite’s WIP RSC support

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

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

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

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

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

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

TS+ postmortem (Effect-TS experimental TS fork)

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

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

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

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

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

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

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

React useTransition update ordering details

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

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

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

Carl: Interesting. [51:35]

React Cache: It’s about consistency

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

Self-hosting Next at scale

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

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

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

Server and Client Component Composition in Practice

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

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

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

Conferences (React, Javascript)

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

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

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

WaysConf Sept 16-17

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

CascadiaJS Sept 18-19 Seattle, WA, USA

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

CascadiaJS Sept 18-19 Seattle, WA, USA

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

React Alicante Oct 2-4

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

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

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

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

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

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

Remix Jam, Oct 10, Toronto ON, CA

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

Outro

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

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

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

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

Mark: Take care. [56:04]

TMiR 2025-07: Vercel shakeups, new React Compiler docs

Reactiflux — Sun, 27 Jul 2025 16:00:00 GMT

This Month in React: July, 2025

[01:17] New Releases
- [01:20] RN Reanimated v4
- [08:46] RN Ignite toolkit v11
[10:18] Main Content
- [10:21] Compiler docs are merged! (live docs, and config API)
  - [11:42] Expo docs say it’s “on hold”, but Evan Bacon says Expo 54 may enable the Compiler by default
  - [12:45] Oh no — more function directives , “use memo” and “use no memo”
  - [12:51] DIRECTIVES
  - [13:13] Good thread on some history
  - [14:19] Some tech discussion on the complexities of making React Compiler work with Oxlint
  - [15:41] Directive prologues and JavaScript dark matter
- [18:01] Node API Support for React Native
- [21:49] Vercel shaking things up
- [30:48] Ryan Carniato’s “react and signals”
- [33:09] React Native Unistyles 3.0 Released
- [35:39] React Router and RSCs: The Path Forward
- [36:57] Parcel writeup for Server Components
- [37:26] WIP Vite RSC plugin support
[38:15] ⚡ Lightning round ⚡
- [38:35] Corbin’s “History of React Through Code” deep dive
- [39:06] TkDodo’s thoughts on when useCallback is useless
- [39:26] eslint-config-prettier compromised as part of an NPM supply chain attack
- [40:48] Expo Router demo by Evan Bacon AI + RSCs + Expo Router
- [41:16] Some tech details on how Meta serves React pages
- [41:40] Nitro Image library for React Native
- [42:08] A very hacky way to test RSC components
- [42:31] A good technical dive into improving INP in a Next app
- [42:51] Extra CSS Properties in React Native
- [43:16] Chrome 137 adds if support in CSS
- [44:50] React Devtools for Firefox may not get updated due to review restrictions
- [46:29] Both oxlint and biome are investigating typed lint rule support (Biome v2, tsgolint)
- [47:49] Remix v3 dev branch containing support packages
- [48:40] React Native Wallet
- [50:07] Deno v Oracle update
- [51:23] “Content independence day” from Cloudflare (they’re blocking AI crawlers)
- [52:04] Some updated Static Hermes perf numbers release available “soon”, being tested internally at Meta
- [52:47] State of HTML Survey is open
[53:26] Conferences (React, Javascript)
- [53:29] Big Sky Dev Con Aug 2 Bozeman, MT, USA
- [53:36] Kansas City Developer Conference Aug 13-14 Kansas City, KS, USA
- [53:47] React Universe Conf Sept 2-4, 2025. Wrocław, Poland
- [53:57] WaysConf Sept 16-17
- [54:06] CascadiaJS Sept 18-19 Seattle, WA, USA
- [54:10] Squiggle Conf Sept 17-18 Boston, MA, USA
- [54:17] React Conf is back, Oct 7-8
- [54:22] Remix Jam Oct 10 Toronto, Canada
[54:33] Outro

Carl: Hello everyone. Thank you for joining us for the July edition of this month in React, where we recap and digest all of the latest news and developments in React. React Native, and across the web. We're coming to you live from Reactive Flux, the place for professional developers using React. [00:00]

I am a staff product developer and freelance community leader here in React Flux where I do community programs like these events and build tools to help keep the community operating. May be making more progress on one of those. So maybe I'll do a product announcement in the next couple of weeks or months maybe. [00:16]

Mark: Hi, I'm Mark. I maintain Redux. My day job is at Replay where we've built a time traveling debugger and are currently trying to get in on the AI app generating craze. And other than that, I may moderate things and read too many articles. [00:32]

Mo: My name is Mo. I head the mobile team at Theo. I'm an active member of the React Native community and I organize the React Native London Meetup and the React Native London Conference. Excited to be here. [00:46]

Carl: Excellent. Yeah. We missed you Last month there was react native things to discuss. [00:58]

Mark: We had no idea what we were talking about. [01:01]

Carl: Not even a little bit. We basically just punted on it. Great. Cool. [01:03]

I'm gonna skip job market stuff. I don't think I'm gonna do that anymore. 'cause like who even knows what's going on? The jobs are wild and the indicators are. Too fuzzy to really be that useful, I think. [01:07]

New Releases

Carl: Mo, tell us about some React native new releases. [01:17]

RN Reanimated v4

Mo: Cool. So we recently had React Native Reanimated version four being released. So for those of you who are sort of avid React native developers, you'll know that React Reanimated is sort of the defacto way. To be able to animate elements, layouts and whatever you have inside of your React native applications. [01:20]

So the team's been hard at work. Animates has been around as a package for, for several years now, and they've been iterating on it and making it better and better over time. There's a general push that you'll sort of know from the previous episodes over the last year or so towards sort of unifying React native and react in the web as much as possible. [01:40]

And so CSS transitions and animations are sort of becoming a key part of Reanimated as well, so that the APIs and the way that you can animate things in Native world are as similar as possible. Obviously there's some limitations that can't make it one-to-one, but as similar as possible between web and mobile. [01:59]

And one of the other things is now that we're in this world where you could use React native on web and mobile, trying to find a way to have performance. Web-based animations and transitions is quite important as well. And Reanimated has been working on this under the hood so that when you do use reanimated in your React Native universal app, it actually has performant animations on the web as well, not just on native devices. [02:18]

One of the challenges in the past has been that it's not quite great on the web because it would use JavaScript to orchestrate animations. Not really great, and really, really bogs down the performance of your app on the web. So some good work being done there. A few other things to mention is that Worklet is a part of Reanimated as well. [02:41]

It's, it's a way to basically allow some level of multithreading in your apps. It kind of formed as a need of reanimated itself, but they've made it sort of an open public API that you can access for other multithreading needs that you may have. So they're trying to move that. Across into sort of a separate library and start to separate that up because it's not just useful for reanimated or animations. [02:59]

It's useful for a whole bunch of other stuff like background fetching and, and you know, computationally heavy tasks that you need to run behind the scenes. Other things to mention is that Reanimated used to be this huge package and once you had, you know, imported one thing and Reanimated, everything was imported and so obviously that affects things like your app bundle size. [03:21]

They've now took an approach to make it modular so that you can import. And Bobs of Reanimated rather than the whole thing. Obviously it's not just a JavaScript sort of tree shaking thing that matters here because we're in Native World. There's also sort of the native compiled code and you need to be able to modularize that as well. [03:38]

So it, it's not necessarily a straightforward process for the team, and I appreciate that. It was probably quite complex to decouple a lot of this code and separate it up into different packages, both on the native layer and the JavaScript layer. [03:54]

Carl: What does that affect on a native. Package, I guess like app, total package size, or does it affect like startup performance and things like that? [04:04]

Mo: It, it can affect both. Mainly the app total size that you would need to download is, is a key thing. It can also affect, like you say, the startup time, albeit startup time is largely sort of. Handled by Hermes, the engine that's been created for React Native specifically because it, it sort of optimizes to, to avoid large startup times as a result of having a big app bundle. [04:11]

But it's really mainly the, the, the bundle size. And again, when we're going into this sort of web and mobile world where you use the same packages across the board, modularizing as well on the web, even though you'll have tree shaking, is going to be good practice so that you're not importing a whole bunch of stuff that you don't need. [04:33]

Lastly, and I, I think this is. Something that everyone is quite passionate about in the React native ecosystem and has been a challenge is shared element transitions. So shared element transitions is sort of the transitions that you might be familiar with in the native world where an element is is sort of present and is animated from one screen to another. [04:49]

So when you navigate from one screen to another, there's this sort of shared element. So it might be like an image you click on and you navigate to a sort of detailed view of that image. You have a navigation that happens in the background. But you want to have these on separate screens, but you wanna kinda keep that seamless expanding of the image animation as an example or transition. [05:08]

This is very difficult to do in React Native. You can kind of achieve it in some hacky ways, but it's sort of on the app developers to figure it out. There's not been like a unified API that you can use and it's usually quite hacky and doesn't work most of the times. They are working on this, [05:26]

Carl: would that be stuff like flip animations, like first, last, interpolate, play? [05:38]

Mo: No, I don't think it would be flip animations. The examples that I would give is, you know, like in Instagram as an example, if you're on the, the search page and you see a set of posts that are sort of laid out in a grid and you click on one of those posts, it expands out and takes over the whole screen. [05:43]

Right. [05:57]

Carl: I meant more like would the hacky interpret in the hacky implementation of. what should be a shared element transition? Would that be, is that the kind of thing somebody might use flip for? [05:58]

Mo: I'm not sure, I haven't actually seen flip, but there are some approaches where people have been sort of tapping into the native layer to be able to do that manually, but it's not gonna be quite extensible putting some tags and then using the native layer to do those transitions. [06:08]

So there's a few different approaches that I've seen people do some sort of like third party libraries that people have created as POCs more than anything is how I've seen it done. The, the, the gist of it is that there isn't really like a. Standardized well-defined and like well tested API to do this in React Native. [06:20]

And so that's what the Reanimated team have been working on. It's not out yet, but they've said that they're gonna be releasing it as part of this major release cycle. So four dot something will have. Some support for shared element transition, still TBC, but keep your eyes open for that one. [06:37]

Mark: Cool. [06:52]

Honestly, that whole discussion reinforces how many things people are doing that I have no experience with whatsoever. [06:53]

Carl: Love that. Yeah. I guess just to close the loop a little bit on like flip animations, like it reminds me a lot of shared element here. 'cause I guess like shared element means that it doesn't like vanish. [06:58]

You know, it's one thing persists. From this state to that state. That's my general understanding of it. And how I had done that in 2017 was, so you've got the current state, you've just rendered, you have something up and then you re-render and you get the new state. Then you have some abstraction that cracks the old state after the new state shows up and says, okay, this element is tagged with this animation, you know, indicator. [07:09]

And that indicator has now gone to this element in this new state. It used to be here. Now it's here. Let's measure it triple eight, you know, the old size versus the new size. And then do Aran smooth transition, you know, generate a CSS animation to make it look like it's the same element. [07:37]

Mo: Yeah, it gets a little bit more complicated in the native world because these are different sort of screens that are different view nodes on the native layer, you'd need to have a little bit more control over how you do that on the native layer, the native layer might override it. [07:54]

If you write that JavaScript logic as an example, it definitely needed some native components to be able to handle it. Under the hood, the algorithm and the native layer will do something very similar, which is first screen, screen A has this size for this element. Screen B has this size. Let's look at the positions and interpolate the values and the, the zoom of it to match the target size as we're migrate, as we're opening up the new screen as an example. [08:07]

Carl: Right. Oh, interesting. Okay. Sure. On native, there are things already doing that for you, so you don't need to hack into the, into that. You just need to actually support it. Cool. Makes sense. Okay. [08:29]

Mark: Probably just as well. We really didn't have all that many new items and new release items this month, given that we just sort of deep dived on that one. [08:40]

RN Ignite toolkit v11

Mark: So one other thing from the React Native world, the Infinite Red has a very long running boilerplate toolkit called Ignite, and they just put out version 11. The big news for this one is it. Only sports, the new architecture. It's been bumped to E Expo, SDK 53, some changes to the theme implementation and they've made it bring your own state management. [08:46]

They used to default to MobX State Tree and now they've tweaked it. So you can pick and choose how you want your state to be handled within the new app. [09:06]

Mo: There's a little bit of context here, which is that the maintainers of this library, infinite Red, have been very opinionated on Malbecs being the best sort of tool for React Native. [09:14]

State management there. There's some some reasons behind that. Like Mob State Tree is quite good in terms of sort of heavy memorization and that can really affect performance if you don't have stuff like that and React native or you're not careful. So I think they were trying to set some practices that they were used to. [09:25]

Mark: And also I believe Jamon from Infinite Red was the maintainer of MobX State Tree for a number of years, and he either still is or recently handed it off to somebody I think. [09:41]

Mo: Might be that he was maintaining it to some degree. Yeah. [09:51]

Mark: So I mean there was, there was a very understandable preference there. [09:54]

Mo: So the main maintainer of MobX and MobX State Tree as far as I'm aware is Michelle West Streett. [09:56]

From WHO, who works at Meta, [10:00]

Mark: I think Michelle handed off MobX State Tree to into Jamon a number of years ago. Okay, cool. Didn't know about that really. That's fair enough. [10:02]

Carl: Oh, interesting. I didn't know that [10:08]

Mark: he spiked MobX State Tree. And then it's like, okay, I've, I've proven I can build this, but I don't have time to maintain it would someone else like to? [10:10]

Cool. [10:17]

Main Content

Mark: Onto the main content for today? [10:18]

Compiler docs are merged! (live docs, and config API)

Mark: The big news this month is that the React team has written completely brand new docs for the React compiler. Not only did they put them up as a PR this month, that PR has been merged and the new docs are now live. Previously there was just a single page under the installation setup section of the React Docs that gave some amount of details, and now the React compiler has its own top level section with multiple pages under both the learn and reference sections of the React docs. [10:21]

These sections cover a lot of things. What is the compiler? What does it do? How does it work? Should I try it out? What build tools do it? Does it work with? How do I install it? How can I incrementally adopt the compiler? As well as some reference section information, talking about configuring it and some of the concepts it includes. [10:54]

And even like if I'm a library author, should I pre-compiled my library bundle to make use of the compiler? So it's very clear that they've been looking at some of the discussion threads where people have complained that, you know, it doesn't feel like it's ready for adoption yet. I don't know if it, you know, I don't know how to configure it. [11:16]

And they've taken a lot of that to heart and put together some pretty good docs to try to actually address a lot of those points. [11:34]

Expo docs say it’s “on hold”, but Evan Bacon says Expo 54 may enable the Compiler by default

Mark: We noted that the, if you look at the expo docs, there is currently a section that says that their integration with the React compiler is on hold, but that may be superseded because I saw a tweet from Evan Bacon just earlier today where he said that we are actually going to enable the React compiler by default in Expo version 54. [11:42]

And along with that, the compiler docs themselves in the introduction section. Actually say like, should I try the compiler and is it safe to use? And they specifically say at this point, we encourage everyone to start using it. It's still optional, but it's in release candidate. It is safe to use. It's been tested in production and we really would like people to actually try it out. [12:05]

Of course they do. [12:30]

Oh yeah. But I mean it's, it's a pretty big vote of confidence that this is not just a whim. That it is something they're very serious about, that it is basically ready for release and that they would like to see the ecosystem start adopting it. [12:31]

Carl: Yeah, makes sense. [12:43]

Oh no — more function directives , “use memo” and “use no memo”

Carl: I am not super thrilled about seeing more function directives being introduced here. [12:45]

DIRECTIVES

Carl: Like I'm on record for like the past two years here, being frustrated with introducing more and more directives, and so seeing now basically a compiler flag for memorize or don't memorize this. As the, uh, incremental adoption method. I just don't like it. It's, it feels like magic. It feels gross. I don't like it. I don't like directives. They scare me. [12:51]

Good thread on some history

Mark: Couple other compiler bits of news. There was some discussion on Twitter, I believe, where Joseph from the React compiler team gave a little bit of background on who had worked on the compiler, some of the timelines and some of the influences, and then the compiler right now has a couple limitations in terms of tool support. [13:13]

One is that while the 90% of the compiler code is its own independent true compiler, currently the only way to integrate with that and actually use it is via a babble plugin shell around it, which also means you have to have babble. In your build pipeline, and a lot of people are not happy about that. We got rid of babble. [13:33]

We use, we use SWC, we use, you know, whatever other, you know, ES build something that's not babble anymore. And so there's been lots of questions about, you know, when will they get around to offering a non babble integration? No timeline on that yet. But as a related part of that, the lint rules that React offers are also ES lint based. [13:55]

Some tech discussion on the complexities of making React Compiler work with Oxlint

Mark: And we now have other winters like biome and oxalate that are not ES lint and not esent compatible. So there was a pretty good thread between the React compiler team and the oxalate team talking about like what would it take to make React compiler and the React ES lint rules. Runnable inside oxalate, and there's a bunch of low level technical details about, you know, js rust interop and, and some of the complexities that might be needed there. [14:19]

So the answer is probably not anytime soon, but there's discussions about what it might take to make that happen. [14:48]

Carl: Yeah, and circling back to your, you know, good thread with like some timeline and influences and whatever frustration I have, this is like such a, this is exactly the same problem that React and I guess web and like development in general has had for a long time. [14:55]

But like all of that happened on Twitter and like that's great knowledge and such good resource. But the guy who asked the question asked it on his private alt. So like, if you are not one of the, you know, 1100 approved people that he has granted access to see his thoughts, you can't see what was asked, just the response. [15:09]

So at least you can see the response. That's nice. But I wish they'd put something like this in like, I don't know, an introspective blog post or whatever. So. I'm just gonna keep shouting at clouds throughout this episode, I think. Cool. Cool. Let's move on though, [15:28]

Mark: even before we get there. [15:40]

Directive prologues and JavaScript dark matter

Mark: I found the article I was looking for, it was indeed in Tech reads the news a few weeks ago. [15:41]

This was in linking a post on directives, prologues and JS Dark Matter, which was an archeological explanation of how things like JSX, pragmas and function directives and magic comments. Have all been used to indicate to build tools, Hey, do something different with this code than what you would expect. [15:45]

Just reading it. [16:05]

Carl: Love that. That is actually really good. And like basically this is all just communicating with different levels of abstraction between like runtime and source code. So it's like, I don't know, the linter or the formatter or the, I don't know. I guess you don't really do tests so much there, you just do it elsewhere. [16:06]

But the compiler, or transpiler compiler is now a fuzzy, overloaded term, and I guess they all make sense for one reason or another, but something about directives and the way that they like persist through. I prefer a magic comment, like at least a magic comment is like very clearly something like not runtime. [16:24]

I don't know, something about it feels wrong. The [16:41]

Mark: fact that a directive is just a string hanging out there. [16:44]

Carl: I dunno. It seems weird. And since it is just a string, like why not a magic comment? Ah, I don't know. Maybe there was some kind of weird esoteric, like the compiler, you know, the, all the various compilers and whatever, transpilers, and ASTs transformers are all like, maybe they muck with comments and whatever, but also like the compiler requires that you put it first in your Babel so it gets the untransformed code anyway, so that doesn't sound right to me. [16:47]

I don't know. Weird doesn't seem necessary. I guess the root of my angst here is that like when they introduced the "use strict" directive, like when they introduced the concept of a directive, they said, we're never gonna do this again. Like, don't do this. This is bad. We should, we shouldn't have had to do this, but we did because weird legacy concerns don't do any more of these. [17:13]

Mark: And then the community decided, okay, now we got a new mechanism to play with. [17:32]

Carl: We got like, how many do we have for React now? Like. I can think of four off the top of my head. [17:36]

Mark: Client server memo. No memo. [17:40]

Carl: Yep. Okay. Maybe four, but like, come on. That's 400% increase from one. Come on. [17:43]

Mo: Now you can have two at the top of one file, which is gonna look weird. [17:49]

It's gonna take some time getting used to that one. Wait, [17:52]

Carl: can those even, are the, is that even compatible? 'cause it's gotta be, the directive has to be the first line. I [17:54]

Mo: don't know how that would even work. Moving right along. [17:58]

Node API Support for React Native

Mo: Alright, so back into React Native World. The folks at call Stack have been working on some other projects under the, under the smoke screens, and it's some cool stuff that they've released. [18:01]

They've basically enabled Node API support at a very basic, primitive level. They're, they're working, still working on this. They've made some good headway with this. So they're bringing Node API support into React native. Now, not to be confused with node itself, node API is basically like a mechanism by node js that allows you to use C based languages to interact from JavaScript code to call native code. [18:12]

And so you can write native add-ons in CC plus plus. Even rust or swift. And then they can be used and ingested by JavaScript applications. So there's a few reasons for doing this and it, it really goes more into the internals of React Native. And you know what this means for library maintainers, for built tool maintainers, and for really meta itself as well. [18:38]

But the two key things here is faster build times. And closer convergence with native web libraries that may already exist and be using the node API mechanism. So at a first level build times, and I think this is the bit that will affect users more than anyone else is. Basically in the rate of world today, most native modules are actually distributed a source. [18:59]

So every time you make a build, you actually have to compile it all and do the build step, which is quite long. Building a typical rec native app somewhere around 10 to, if you've got a massive scale app, it could takes several tens of minutes to actually do the full build of the app, right? But it's a long, long time now. [19:22]

You don't need to do this for like your development workflow typically, or that often, because you wouldn't change native dependencies every day. You would just do this when there's a new native dependency that's been introduced, but it's still a significant amount of time. Right? And so the idea is if we can get some of these prebuilt. [19:41]

Using a mechanism like the node APIs, then we can bring this time down quite significantly. And so one of the things that they ran as a test was for a basic sort of React Native core app that you know is just having the basics of React native within it. They think that they could bring down. The build time to close to seven seconds, which would be insanely fast in comparison to what it's today. [19:59]

So this could be some really cool stuff that's down that's coming down the line. The other side is that there is already an ecosystem of node API compatible sort of applications and run times, and so, so many sort of libraries. Web API libraries like Web RTC or Web Audio Canvas. These are implemented with node API. [20:21]

Now, they're not going to be direct one-to-one mappings for native, but there is already an initiative to try to, to try to align on the web API spec. And so this is sort of another part of that puzzle. And so if you bring these two together, suddenly we can use sort of web APIs and React native, and it could be a really, really cool future to look into. [20:42]

None of this is. None of this is sort of like fully there, and there's gonna be, this is a long term effort, but it's something that they announced this month, and it's quite exciting. [21:02]

Carl: I've had enough struggles with native binaries on desktop where they're, you know, like intended to be compiled for just like, like mostly across, like upgrading, upgrading a version of that, or node versions or whatever. [21:11]

But I, I've had enough struggles and complications there to be wary. Of what the actual experience of using this will look like. But this is, this is really cool. This just even having made enough progress at this to announce it and like meaningfully talk about it as a thing they desire is pretty cool. [21:25]

Very hard, really hard problem. I'm curious how they're implementing it. [21:43]

Mo: It's definitely not trivial. [21:48]

Vercel shaking things up

Carl: Cool. Alright, moving on a bit. So there's been a bunch of Vercel things this week, a fair number of departures. I'm sure people are coming and going all the time and we just, you know, we can't get a comprehensive list of that. [21:49]

Leerob is at Cursor now — Five Things \[he\] Learned at Vercel

Carl: But they, they had a couple of relatively high profile departures in the last month, starting with the most notable Lee Robinson, who has been there for. Five years, a long time. Was he there before COVID? [22:02]

Mark: Not sure on the timeline. Like it, it felt like he'd been there much longer than that, but apparently it has only been five years. [22:15]

Carl: Yeah. Okay. No, you're right because he, he put out a blog post. Well, anyway, I'll, I'll stop speculating on the timeline, but to me, he is highly identified. With Versel, like, you know, if I think of Versel, I think of, uh, Guillermo, Roush, and Leero, just like by volume of activity and like prolificness in content and social media interaction and blog posts and example resources. [22:21]

So just all of it. So he has now left Versel and is working at Cursor, which like. That seems great, at least in terms of like mind share and hype and you know, alignment, potential, alignment with future, whatever. Cursors is definitely a really hot company right now. I've had some private conversations of with like, can they keep doing that? [22:45]

'cause at the end of the day they're a fork of VS code and like fork of a large project with 30 people working on it. Which I think is in the ballpark of how many employees Cursor has versus like Anthropic, which is, you know, a giant, huge beast with all of the money. So like it's cool. Great for him. [23:05]

Definitely there's a lot more like oxygen in the room in terms of excitement and like potential at cursor. I think so. Cool. I'll be keeping an eye on that. I use cursor. It's nice, so he'll still remain in my, I don't know, professional spheres. But yeah, he had a really good blog post that he put up called, UH, five Things I Learned From Five Years At Versa. [23:24]

I appreciated it. His number one was go hard at work, then go home, and he closes it with, when I'm offline, I'm offline. I'm a hundred percent focused on my wife and daughter. To be clear, I still get this wrong sometimes. It's a never ending pursuit of work, life, harmony, takeaway. You can work really hard and set clear boundaries. [23:46]

I'll say That's hard. I struggle with that. I don't, I don't have a wife, I don't have kids. So like in that section he talks about like responding to tweets from the beach on his honeymoon and like, yes, I want to believe that you can work really hard and set clear boundaries to where you're not working on vacation doing, you know, social media comms work from the beach, but also like if you're not there. [24:03]

Like, people aren't gonna wait three days for you to get back from vacation to, you know, get the authoritative answer. Like, if they ask a question, then like, the person who is Johnny on the spot answering it in their time of need, like they are gonna get the, I don't know, the kudos, the energy they're gonna, you know, people are gonna start gravitating towards them for future questions. [24:27]

I'm like, that's. This going so hard is how Leero managed to get that level of status, like in my own brain. And so I wanna believe you can work really hard and set clear boundaries. I'm not always so sure about that. I, I dunno. I wrote, I actually wrote a little blog post kind of on that subject almost exactly a year ago. [24:47]

I'll link it here. I probably won't put it in the transcript. Just kind of talking about that general thing and like I, I had a kind of similar experience to what he describes here of like, going really hard and like poor boundaries and like burnout and all of the, a lot of the benefits, a lot of the costs. [25:06]

And what I kinda realized is that like, I don't know that I could have achieved the kind of success that I got without that level of burnout and I don't know, poor boundary setting because like, it's because I gave. All of my attention to maybe not just work, like some of, a lot of my attention, you know, the full-time work, but also investing in things like reactive flex or just learning new tools and staying on top of the cutting edge outside of work. [25:23]

Like that was really poorly boundaried and like fully throughout my twenties, I ignored a lot of myself. I just really think that that is, I wanna believe that you can succeed and achieve big success without giving up that kind of, I don't know, intimacy with yourself. But I don't know that you can, I don't know, it seems really hard. [25:50]

And it, it just notable to me that like the only people I see talking about that and like saying things like, you can work really hard and set clear boundaries are the people who had poor boundaries, achieved success, and are now reflecting on it. So, I don't know. [26:09]

Mark: Yeah. It, it is tough, but I, I have a, I have a lot of respect for Lee Rob and that the work and effort that he's put in, when I just think of the word derel, he is the first that comes to mind. [26:22]

He, he's always, you know, omnipresent in any kind of Reddit or Hacker News or Twitter thread that mentions Versel and Next. And, you know, even if you maybe, you know, at times disagreed with, you know, what he was saying or representing the company wine, he absolutely like did a great job of being there and answering questions and, and being involved in reaching out. [26:33]

It's definitely a loss for Versel and when I wrote my React Community article, you know, recently, I had a line in there about Versal had a large Dere team that updated the next docs, and he corrected me. It's like, no, there were two of us at that point. I was like, oh, whoops. I got that wrong. It seemed like you had a large team because you were doing so much work. [26:55]

Carl: Right? So, yeah, I don't know. From the comment, from the, from chat, from re Sam, bit of taking advice from lottery winners, vibe occasionally like, yeah, that's, that's what it is. It sounds like survivor bias, things like that. Anyway, this is, we're already like kind of far afield from where we started here. [27:21]

This was talking about Versel and some of their updates. This was a good piece. Lee Rob, wish him the best at cursor. I'll be paying attention still. [27:35]

SWC creator leaves, focusing on SWC for a while

Carl: The, uh, creator of SWC also left Versal. He's taken some time to, to rest and focus back on, uh, SWC again, so that's great. I'm not as familiar with him as a, you know, individual human, but I am familiar with s wc. [27:43]

So cool. Good luck to him. Love that. [27:59]

Sam Selikoff just joined to do content and stuff

Carl: And another prolific react ecosystem speaker and like educator, Sam Selikoff joined Versal to do content and some other things. His Twitter feed is all like, all about ramping up and like, you know, spinning up on a new team. So that's, that's a fun, that's a fun moment in time. [28:01]

Team transitions and gathering context in a new spot. [28:20]

Nuxt acquired

Mark: And then overall, and not, not react, but adjacent. So next is the view ecosystem equivalent to next Js. And Versel had already picked up, you know, rich Harris who builds Svel, possibly one or two other non-reactive framework authors as well. And VL actually just acquired whatever group or company has been behind N and is hiring all of the developers, including Daniel Grow, who I think is the, the lead. [28:23]

Developer maintainer for N So you know, Versal is not just about react like they, they are sort of putting their money where their mouth is and trying to back many different tools that, you know, build apps and of course can be run on versal. That's [28:55]

Carl: got me curious about what kind of like corporate structure is behind Nuxt. [29:11]

'cause like, you know, if it's individual developers then like. You can't acquire that, you just hire them. [29:16]

Mark: I think next Labs may be an actual company, but I don't know how much of a like profit seeking company it is versus some kind of little holding thing. [29:21]

Carl: Right. I'm now, I'm on the next website. I see next UI Pro, A hub for managing apps. [29:29]

So I guess like deployment and then like a visual editor. And I see some reference to courses and stuff too, so like, yeah, that sounds like a business. That sounds like they're selling products. Kind of a mishmash of various different open source monetization techniques there. So. Cool. Nice. That's good to know. [29:36]

I appreciate that. Love someone who's trying to take a project and turn it into a business Relat. Another smaller update. [29:50]

Netlify Staff Eng Philippe Serhal replies to the Vercel Deployment Adapters RFC from April

Carl: This is like barely an update, but I've been tracking A an RFC, actually an RFC that Lee Robb started back in April on deployment adapters for next from Versal, basically making it. [29:58]

More robust and reliable, I guess, to deploy next projects to infrastructure that isn't hosted on Versal. So the, a staff engineer from Netlify gave a response that's pretty lengthy, pretty serious, you know, it's got like, you list six gaps and 10 questions and four suggestions, mostly minor suggestions. [30:13]

It's just cool to see that moving along slowly and I question the momentum now that Lee Robb is no longer there. It's just really hard to hand off major projects like that, major initiatives like that. But yeah, that's cool. Neat. Love to see it. [30:32]

Mark: Okay. Somewhat smaller item, but definitely worth calling out. [30:45]

Ryan Carniato’s “react and signals”

Mark: So Ryan Carniato, the author of Solid, is, you know, pretty much the world's foremost expert on signals as a state management mechanism. And there was a lot of back and forth and chatter, and I think we even referred to some of it in our, in our last talk about like Ryan for and Michael Jackson from Remix were kind of questioning like, why does Signals exist? [30:48]

Why do you know? Why do these different frameworks look sort of the same? And I think somewhat inspired by some of those questions and discussion. Ryan put together a 10 minute video on React and Signals what every React developer should know about signals. And Ryan like me is very big on history and context and explaining how we got from past tools and decisions to current tools and decisions. [31:09]

He goes into some, some of the history of signals, you know, they originated with early JavaScript frameworks like Knockout, but the concepts and implementation of signals have evolved significantly in the last 15 years ago. And so he talks about some of the actual technical advantages of signals. And then he also does some, some myth busting. [31:36]

You know, he pushes back and says they're not magic. They do scale. A lot of other frameworks like Angular and View rely on signals to make them faster. And he also talks about comparisons between like, what's the difference between three ACT compiler and signals or reacts virtual dumb in signals. And I think what a lot of that sums down to is that in react. [31:56]

The component is the smallest unit of update granularity, like you set state, at least one component will re-render the whole component renders, and then maybe only a few bit bits of it need to be applied, but you had to run the whole component to see what needed to change. Whereas with signals, it's this one value changed and it's more directly attached to the output. [32:19]

And so only the bits of the output that actually relied on that need to be calculated. And it's not an earth shaking discussion, but given that there's been a lot of hype and discussion and arguing back and forth, it's a good overview. Looking at some of like. Some of the pros, cons, concepts, and myths around signals. [32:42]

Carl: Yeah, I missed that. I need to give that a watch because I hold a number of myths and misconceptions about signals, and I would like to understand them better. Yeah. [33:01]

React Native Unistyles 3.0 Released

Mo: Nice. Next up, we have another release. So we've been talking about this for a few months. On and off because it's been sort of an RC mode, but React Native Uni Styles 3.0 has finally been released. [33:09]

Now there's a few points to sort of hit here. Uni Styles came out as sort of like a very performant, lightweight styling option for React Native because there's a lot of styling libraries that are quite complex and have a lot of. Stuff included within it. But the challenge with a lot of those is that it also comes with a little bit of a performance hit because you've got a lot more being bundled into your application. [33:21]

Uni styles is, is sort of since then being this sort of lightweight JavaScript only implementation has has dug into this sort of performance space a bit more. And this newest release is really digging into the new architecture with with Fabric, which is the new render and it uses native code and c plus plus. [33:45]

To basically bypass the JavaScript layer when possible and keeps us track of the styling dependencies in c plus plus, and we'll only update affected styles and components on the native layer as much as possible. Again, this is like some things are possible on the native layer. Some things aren't. In terms of styling and, and the visuals of it, but as much as it can possibly do, it does that in the native layer and avoids re-render. [34:03]

The maintainer kind likens this to CSS on the web in that it's not handled by JavaScript, but it's a different layer that that handles it. On top of that, added a bunch of extra functionality through a babble plug plugin to handle things like theming, break points, orientation, font scale, and maybe even right to left styling if you need that for your app. [34:29]

And so the by and large, the biggest thing here is that there is a performance boost and they've done some measurements to, to show how much of a performance boost you can get because of these safe three renders that would've previously been happening because of styling changes. Other noteworthy things to mention are that there's some new features around sort of variance or scoped themes and so on and so forth. [34:48]

You can go read through the blog post in more details to understand what are the sort of more granular new features that exist. But also given that this is sort of a universal library that works on web and native, there is a new web functionality as well. Some web only styles, some pseudo classes that they've introduced and some support for class names that would be targeting the web. [35:10]

So there's some stuff around web support as well, which is quite interesting. But yeah, that's Uni Cells 3.0. Give it a give it, give it a quick look. Cool. Love that. [35:30]

React Router and RSCs: The Path Forward

Mark: Finally, we have a couple different, uh, react server component updates. The React Router team has been iterating for a while on their work in progress server component implementation, and they've put together a blog post describing a path forward, so they go through some details talking about the, and ways you would handle things like streaming UI or in lighting data in existing React router framework mode versus how you might handle it with their server component implementation. [35:39]

And so there the summary is that. apparently they're going to revamp the framework mode to be built on top of their server component support. [36:10]

They are still labeling the server component support as unstable, but they do want people to try it out and give it a shot. So looking at some of these examples, it looks pretty significantly different usage wise than say like the next app router. It maybe looks even a little more similar to how Parcel had almost like a pick and choose your own server component usage approach. [36:19]

So it is very cool to see additional frameworks providing support for server components. As well as that we're starting to finally see some variation in how they might get used and not just. The way next does it is the only way to do it. [36:42]

Parcel writeup for Server Components

Mark: Along with that, Devin Govett from parcel put together a pretty good article where he was talking about how parcel bundles, server components, and he goes into some background detail about like, you know, what is a bundle even do in the first place? How does it. You know, follow the, the module graph. How does it handle dynamic loading? How do the pieces fit together? And then talks about, okay, and since React server components is really a bundler driven feature, here's how server components actually rely and make use of some of those bundler aspects. [36:57]

WIP Vite RSC plugin support

Mark: And along with that, I think we've previously mentioned that there's been an in progress. Attempt to build RSC support directly into Vite's React plugin. And there's one person who appears to be steadily cranking away on trying to make that support possible. And I'm seeing a number of the to-do list items in the roadmap being checked off. [37:26]

So I don't know how far along that is. But it seems like a pretty serious effort to make that happen. So the server component ecosystem is slowly filling out. [37:50]

Carl: Yeah. Interesting. I see one of the to-do list items in that is moving waku to VJS plugin, RSC. That's interesting. 'cause I, I had understood, I mean, Waku was like. [38:02]

A proof of concept implementation of like how to do a framework on RSC. So it's interesting to see that move from like custom one-off implementation to relying on a, you know, kind of delegating RSC support back into, back into Ved. Love to see that. That's cool.

⚡ Lightning round ⚡

Mark: Okay, moving on to the lightning round. [38:32]

Corbin’s “History of React Through Code” deep dive

Mark: Lightning round. Corbin Crutchley, author of the Framework Field Guide ebook, put together a very lengthy deep dive, which I highly approve of, called the History of React through Code, where he goes back and looks at a whole bunch of different react features that were added over time and kind of argues that you know what these, the, these actually have sort of a. [38:35]

Intellectual cohesiveness a like a design cohesiveness to them and that they, they all, it makes sense when you look at the sequence of, of features and how they were added. [38:56]

TkDodo’s thoughts on when `useCallback` is useless

Mark: Meanwhile, TK Dodo, Dominic Dorf, Meister maintainer of React query, just put up a post today where he has some thoughts on when use callback is actually useless. [39:06]

And I think his argument is actually, it's useless in a, in a lot more cases and you probably don't actually need it all that often. [39:18]

`eslint-config-prettier` compromised as part of an NPM supply chain attack

Carl: Cool. There was a NPM supply chain attack that was pretty interesting. I believe. The issue was that a couple of relatively high profile maintainers got phished, and yes, there's a phishing campaign on a typo, squatted, URL, which is NPN js.com. [39:26]

So it's a couple of major. Maintainers got successfully phished through that, which then, uh, stole their NPM credentials and published malicious versions of packages. Yeah, so, uh, malicious releases included lin config, prettier. That's big Lin plugin, prettier. Think kit packager, core and nappy post install. [39:45]

So the, like, most of those not so big. I, I haven't really heard of, heard about 'em, but yeah. Esly config, prettier, that's big. And they got version, they got major versions. 8, 9, 10. Eight, nine, and 10. Okay, so make sure you're not using version 10.1, 9.1 0.1. Anyway, if you're using those, check it. If you're using ES link config, prettier or ES link plugin prettier. [40:06]

Make sure it's not a vulnerable version. Check your lock files. Yeah, that's not great. [40:29]

Mark: I know one of the other redix maintainers got the phishing email and avoided it. It's definitely semi widespread campaign. [40:34]

Carl: Wild. They must have hit so many people to get a couple of major vulnerabilities in. Cool. [40:41]

Expo Router demo by Evan Bacon AI + RSCs + Expo Router

Mo: So next up, very quick one. [40:48]

You might've remembered the old expo router demo from last year's react conf, where they showed RSCs in the world of expo router for building an AI app. Something very similar to that is now an open source project that you can clone and play around with. So Evan Bacon has released a demo of an AI app that can generate. [40:50]

With AI native components and stream them in with RSCs. It's pretty cool. So clone the repo, play around with it. It's an interesting little demo. [41:08]

Some tech details on how Meta serves React pages

Mark: There was a Reddit thread that was asking how does Facebook slash meta actually build and serve their React applications? And some former meta engineers responded with a few technical details talking about how they do a bunch of dynamic bundling, and they also use, I believe Hermes or static Hermes on the back end to pre-build some of the server rendering pieces. [41:16]

So, you know, a little peek behind the curtain. [41:38]

Nitro Image library for React Native

Mo: Cool. And we talked a little bit about Nitro modules over the months, the past few months, there is a new library that the Margie folks folks have been working on called React Native Nitro Image. And so this is built on top of Nitro modules. I was actually talking with someone this morning about some of the challenges with images on the native layer when it comes to loading them in React Native. [41:40]

So this is very much welcome as a change to hopefully improve performance across the board for React native. [42:02]

A very hacky way to test RSC components

Mark: One of the weaknesses of React Server components has been that there hasn't been a good testing story for them yet, or at least not one that I've heard of. Someone put up an article with a way to test them. [42:08]

However, it's incredibly hacky and relies on overriding some of reacts internals, so it's probably not a good way, but it is a way to try to test them if you like. [42:20]

A good technical dive into improving INP in a Next app

Mark: And then there was a pretty good article that gave, it went into a bit of a technical dive and deep dive on how a company improved the interaction to Next Paint Web Vital Metric in their app, and gave a bunch of very practical examples of problems they found in their app and ways that they, they addressed those. [42:31]

Extra CSS Properties in React Native

Mo: Cool. Next up, there are some new styling properties that are being proposed to be added to React Native. So this is being done by Nishan Bede, who has been doing a lot of work in trying to bring some CSS styling into React Native and better support. This time there's a pr up that adds support for background size, position, and reply and, and repeat. [42:51]

So this will be quite interesting to see when and if it gets merged in. [43:13]

Chrome 137 adds `if` support in CSS

Carl: Yeah. Speaking of, I don't know, new CSS things. Chrome 1 37 added an if to CSS. There's a conditional flow, or I don't know, there's a condition now in CCSS. I have not seen that before. So I guess it's a way of, you know, you can consult the various variables you've set up and evaluate what the associated styles are or associated values and conditionally. [43:16]

Do one thing or another. Yeah. [43:43]

Mark: Yeah. It, it, it looks like it's a built-in function. You pass in a very, like a, an existing variable or property value as the first, and then it's, if it matches, then it's a, if it doesn't match, then it's b like, almost like an Excel function, like kind of a thing. [43:44]

Mo: Reminded me exactly of that. [44:01]

Are we finally at the stage where CSS is turning complete? [44:03]

Carl: I remember seeing a demo of turning complete CSS like 15 years ago if you include user input. So yeah, it was like a grid of check boxes and uh, I think the, the human had to interact with stuff, but it was turning complete, if you included that. [44:06]

Mo: So I think we just need loops and it'll technically be turn complete. [44:20]

Carl: Yeah. Wild. Anyway, that, that seems interesting and new. This document that I'm reading is using something else that I don't recognize. The, the example they have here is if style, you know, dash color, white, so I guess that's using a different function to read the styles of the current element. [44:23]

Something. That's what it looks like to me, but that's also new to me. So like between conditionals and being able to read the current state of element are, uh, interesting. [44:41]

React Devtools for Firefox may not get updated due to review restrictions

Mark: There was a discussion thread on Blue Sky where someone, where one of the React team members said that. They were, they had tried to submit an update to React Dev Tools extension in Mozilla's, Firefox, add-on store, and it was getting blocked because Mozilla has some very specific and strict rules around how code gets built into extensions, and suddenly, all of a sudden, someone on the Mozilla side is complaining that the way React builds their extension is hypothetically a security concern. [44:50]

There were also some numbers thrown around about how many Firefox users of the dev tools extension actually exist. And it was only like, maybe like 120,000 or something. Whereas I think the, the last time I looked at the, the dev tools extension for Chrome, it's like 4 million. So the React team was actually saying, you know, maybe we, we won't even bother building the extension for Firefox anymore. [45:23]

It's, it's not worth the effort. You can always add the, you know, the unbundled version yourself. I think they maybe managed to get the attention of someone from Mozilla to try to, you know, bypass the stuck review process. But clearly that's a pain point. And [45:47]

Carl: I gotta say, just side load this extension that can read all of your input on every site is the dangerous thing to do at scale. [46:03]

Like if you just tell millions of people side load this application, there's gonna be dozens of malicious actors who spin up their own. Side load version of the extension that does malicious things. So Oof. Don't like that. So yeah, hopefully they can fix this, you know, correctly. [46:12]

Both `oxlint` and `biome` are investigating typed lint rule support (Biome v2, tsgolint)

Mark: And so another item, so we've previously mentioned that, you know, biomes working on version two and they had included some typed some support for typed aware rules that normally would've required integration with the TypeScript DS went package and the TypeScript compiler ENT came out with 1.0. [46:29]

There, there's a bit of additional information and updates on both of those. So there was, there was an article. Talking and comparing the different approaches that Biome and Oxalate are using to implement typed support. And then we got a couple links to some of the discussions where those linters are doing it. [46:49]

Biome appears to be building in like their own, almost like a miniature version of. Typed processing, whereas Oxalate has taken the new TypeScript written in Go compiler and sort of hacked up an interop layer. Then they're relying on the new TypeScript go compiler to do the type checking work. And that approach appears to be working it. [47:09]

They said they've implemented a number of the different type to wear rules, and it seems highly performant, so you know that in addition to being able to build our apps faster, we may be able to lint our apps faster as well. [47:35]

Remix v3 dev branch containing support packages

Mark: Cool. We've been going on for a while about how the remix team has been dropping very, very vague hints about what remix version three is going to be, to the point that it's really getting very, very annoying for those of us reading their, their Twitter accounts, and I still haven't seen any actual code of what the framework itself. [47:49]

Will be like, however, there they did put up a development branch that includes some of the support packages that they're going to be using as part of the implementation of version three. So like it's not the full framework, but there's a lot of individual sub packages for various like tar parsing and other sorts of things that they want to be usable standalone, but they're building them for the purpose of usage in version three. [48:07]

So it's not a full look at what, what they're doing, but it's a little bit of a peek behind the curtain. [48:35]

React Native Wallet

Mo: Cool. Next up, we've got another sort of honorable mention of releases that happened over the last month, and this is React native wallets. So there's a lot of sort of. Wallet style libraries that have come and go in the React native ecosystem, not one that's really been maintained extensively. [48:40]

And so the folks at Expensify and Software Mansion have partnered together to create the React Native Wallet library. And so the idea is that. It's firstly a cross-platform way to add payment and credit cards to Apple and Google Wallet. Now, there's libraries that like handle passes and tickets. They're quite limited. [48:58]

I've used a few of them in the past, but this is more specifically on payment cards. And so the idea is that you can maybe. Hopefully through this process avoid needing to integrate a whole bunch of different SDKs for different cards and different and different platforms, and you can kind of just use this library to handle a lot of that functionality for you. [49:19]

Sounds quite complex because, you know, payments are usually quite difficult to get working, so I'm curious to see how well this works in practice, but I've not had the use case yet. Typically payments and, and cards and stuff like has so many different people that you need to communicate with. The card issuer, apple, and a whole bunch of other people in the process. [49:37]

So curious to see how extensible and generic this is gonna be, but very cool. [49:56]

Carl: Yeah. Interesting. Also, it's the first time I've seen a wallet library that was not Web3 in a long time, so additional wallets, right. [49:59]

Deno v Oracle update

Carl: This is a very small update, but we've. I talked a bit in the past about Deno versus Oracle. [50:07]

Deno has been suing Oracle for use of the JavaScript trademark because did you even know that Oracle owned it? Oracle owns the JavaScript word, the word JavaScript. So basically the only content update here is that in the past, at some point previously in the litigation, Deno filed a claim of fraud because. [50:13]

Oracle filed supporting evidence of prior use of the trademarked term JavaScript by referencing the node JS project. Generally as something that they did and you know, who did not start or maintain node js is Oracle. So like basically they filed a just wildly inaccurate claim supporting that. They do in fact use JavaScripts. [50:36]

So that unfortunately was dismissed. The fraud claim was dismissed, which seems strange to me because like if you say I made this and you didn't, seems wrong. But anyway, that's really the only major update here, but hopefully we will hear more. Hopefully this will go in a good direction. I am not super confident of that, but August and September have some major court dates, so maybe there will be more updates later this year. [51:00]

“Content independence day” from Cloudflare (they’re blocking AI crawlers)

Carl: There's also an update from CloudFlare on AI crawlers. They have declared content independence stay. No AI crawl without compensation, which seems lovely, Cloudflare's in a pretty good position to meaningfully control traffic in that kind of a way. Lots of real services are using CloudFlare for that purpose. [51:23]

So, yeah, seems good. I've heard a couple of anecdotes of people with smaller services getting absolutely slammed with traffic from, you know, poorly coded AI supporting crawlers, trying to gather information and doing it just greedily or excessively. So, seems good. Seems nice. [51:45]

Some updated Static Hermes perf numbers release available “soon”, being tested internally at Meta

Mark: All right, and last couple items. [52:04]

The folks at Meta have been working way on static Hermes, which is an attempt to take the existing Hermes JavaScript engine for React Native and be able to pre-compiled entire JavaScript apps to a native binary. And they put up a tweet with some. Performance numbers comparing static hermes's output versus a couple of other JavaScript runtimes. [52:06]

The numbers seem higher, which seems like a good thing. And they also mentioned that they think they will have a release available, quote unquote soon, and that they are using it internally at meta. So, you know, that seems like another potentially useful tool to have in the ecosystem. [52:29]

State of HTML Survey is open

Mark: Finally, the folks behind the various state of surveys have put out the state of HTML survey. [52:47]

So that's open. You can fill it out, test out your knowledge, answer some questions about what various new H TM L features you may or may not be familiar with and what you think about them. [52:54]

Mo: I did not know them. State of HTML. Very interesting. [53:04]

Carl: Yeah, I think they started like two or three years ago. It's relatively newer. [53:07]

I mean, the state of. X has really exploded in the last couple of years. It's great. I love that. But I do worry about like survey fatigue and a lot of these are trying to solicit answers from the same population of developers. So I don't know, maybe, maybe. We'll, we'll see how that plays out. Cool. [53:10]

Conferences (React, Javascript)

Carl: Alright, before we close out, let's, uh, talk about some coming [53:26]

Big Sky Dev Con Aug 2 Bozeman, MT, USA

Carl: like four days, there's Big Sky devcon in Bozeman, Montana. [53:29]

Kansas City Developer Conference Aug 13-14 Kansas City, KS, USA

Carl: Seems good. Kansas City Developer Conference, which is not KCD. It's KCDC, but it's not Ken C dos that's happening August 13th and 14th in Kansas City, Kansas. [53:36]

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

Carl: We also have React Universe September 2nd through fourth in Wroclaw [53:47]

Mo: I've been there enough times where I've been taught the pronunciation because butchered it several times, but it's, [53:52]

WaysConf Sept 16-17

Carl: uh, we've also got Ways Conf coming up September 16th and 17th in Krakow. [53:57]

I'm also probably butchering, but also in Poland. [54:04]

CascadiaJS Sept 18-19 Seattle, WA, USA

Carl: Cascadia js is September 18th, 19th in Seattle, Washington. [54:06]

Squiggle Conf Sept 17-18 Boston, MA, USA

Carl: And we've got Squi Squiggle conf in Boston, September 17th and 18th, which should be great and I should be there, I believe. [54:10]

React Conf is back, Oct 7-8

Carl: And of course, react Conf October 7th and 8th in Las Vegas, Nevada. [54:17]

Remix Jam Oct 10 Toronto, Canada

Carl: I also just heard about Remix Jam, happening October 10th in Toronto, Canada. Yeah, that's new. I don't know that they've done a conference like that before, so that's interesting. [54:22]

Outro

Carl: But yeah, that's all we got for you this month. Thanks so much for joining us. We will be back probably on the last Wednesday of August, but we've been. Jumping around the last few months, but we'll be back in your podcast feed just as soon as we can. [54:33]

Mark: Always fun. Way too much to keep track of, but hopefully this has been useful. Lovely to be with you all and see you all next month. [54:46]

Carl: Great. We gather sources from this week in React Bites, dev Next JS Weekly, the React JS subreddit, and here in React to Flux from the E, the Tech Reads and News Channel. If you see something that you think we should talk about, definitely Sheridan. [54:53]

Channel or send it to me at hello@reactiflux.com. If this is a show that you get value from and want to support, one of the best ways you can do so is by submitting a review on whatever platform you listen to it on, or tell your friends and coworkers about it. [55:07]

Thanks so much for listening. Talk to you later. [55:19]

TMiR 2025-06: kinda quiet tbh. ES2025 finalized, new Safari

Reactiflux — Sun, 29 Jun 2025 16:00:00 GMT

We had some problems with transcript generation this month, downstream of the audio recording issues. Sorry! Fixed for July.

Job market FRED data, Layoffs.fyi, Trueup.io
New releases
- Shadcn
  - updated Calendar component
  - Moving from @radix-ui/... to radix-ui
- Recharts v3.0
- Vite 7.0 is out!
- Biome v2
- Announcing Oxlint 1.0 | VoidZero
- Prettier 3.6: Experimental fast CLI and new OXC and Hermes plugins!
  - Experimental "fast CLI" support, first discussed Nov 2023 👀
- Jest 30
- React Native 0.80
- Safari v26 beta
- Apollo Client 4 RC1
  - May actually ship pre-compiled with the React Compiler (discussion with Lenz and Joe)
Sponsored by Infinite Red
Main Content
- Mark's "The State of React and the Community in 2025" (slides)
- Remix direction?
- Debate over Radix UI status
  - Shadcn has thoughts on switching component libraries
⚡ Lightning round ⚡
- Towards React Server Components in Clojure, Part 3
- Dan's latest posts:
  - Progressive JSON
  - How Imports Work in RSC
- ES2025 spec released. What's New in ES2025?
- The Future of React Native Graphics: WebGPU, Skia, and Beyond
- Open sourced identity
Conferences (React, Javascript)
- React Nexus July 3-5 Bangalore, India
- Big Sky Dev Con Aug 2 Bozeman, MT, USA
- Kansas City Developer Conference Aug 13-14 Kansas City, KS, USA
- React Universe Conf Sept 2-4, 2025. Wrocław, Poland
- WaysConf Sept 16-17
- CascadiaJS Sept 18-19 Seattle, WA, USA
- SquiggleConf Sept 17-18 Bostom, MA, USA
- React Conf is back Oct 7-8, Las Vegas, NV, USA

This Month in React: June, 2025

[00:00] 1-vcarl: Hi, Carl here. Just a quick note before we get into this episode. We had a little bit of an issue with the audio recording, so the quality is a little bit lower than I usually go for. Sorry about that. We'll do better next month.

[00:11] Hello everyone. Thank you for joining us for the June edition of this month in React, where we recap and digest recent developments in the ever evolving react and web ecosystem. We are coming to you live here in Reactiflux, the place for professional React developers.

[00:27] We're supported by infinite red. Consultancy that works in React Native.

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

[00:41] 2-acemarke: Hi, I'm Mark. I maintain Redux. I work at Replay.io io and I apparently spend too much time debating the React team's documentation and communication.

[00:51] 1-vcarl: Endlessly!

[00:52] job market

[00:52] 1-vcarl: Start off with a little bit of job market news. I don't know, maybe we should stop doing these. 'cause I feel like it's not really in crisis anymore and it's not really making any dramatic shifts and I feel like I just keep giving about the same update every month. But yeah, data from Indeed trended up for the first time in a while.

[01:12] True up.io, which also. Attempts to answer about the same question in terms of like, are people hiring in tech shows a slightly more positive trend. So I think that might be like giant people are using Indeed and they are not hiring as aggressively in tech for tech roles and everyone else is using a random smattering of hiring tools and they are hiring. So I wonder if that's like a big tech versus little tech dichotomy. I don't know. That's not based off too much concrete in summation at all.

[01:43] The layoff charts for June are the best that they've been in a year and a half. Fewest number of people laid off by a decent margin and fewest companies running layoffs again by a pretty decent margin, about half for each. Lowest five 50%. So that's good. That's nice. I'm not sure if anecdotally feels that much different, but yeah. I don't know if you disagree, lemme know.

[02:08] We're gonna change up order a little bit. Previously we've done on job market, the conferences and the releases. I'm gonna throw conferences back at the end because I could tell in the data that people were skipping through it. So we're gonna move it.

[02:19] New Releases

[02:19] 1-vcarl: Yeah. New releases.

[02:21] ShadCN

[02:21] 1-vcarl: Shadcn pushed out an updated calendar components. In the release notes, they included like a, a code mod to move imports from at rad cy slash whatever to just rad, cy, like top level like barrel import kind of thing. I don't know what that's about. I didn't really see any new releases from RadixUI that mentioned that.

[02:40] So like I don't really know why that shift is happening, but like, okay, cool. That seems fine.

[02:44] 2-acemarke: A couple other things about RadixUI UI later on in the discussion.

[02:47] 1-vcarl: Yeah. Oh yeah. We've got some main content chatter about them. Just like some Twitter threads, debating, usefulness and whatever. Yeah, more of them later.

[02:55] rechart

[02:55] 1-vcarl: Recharts has a major release for the first time in a long time. Their last major release was January 4th, 2023. So two and a half years. That's a while. Recharts is not a library that I'm often happy to use, but it is a library that I often use because it just makes charts pretty easy. Not always as powerfully and flexibility as I want, but, it's good enough. It's pretty great.

[03:16] The big thing that caught my eye in these release notes was they're claiming it's now accessible by default, so you can tap into it in these arrow keys to navigate it. So that's nice. Accessible charts are hard.

[03:27] Most people don't do them, so getting it in the default is lovely. That's, that should help a lot more charts be access, and then Mark feel like you'll have more to say on that.

[03:37] vite 7

[03:37] 2-acemarke: Maybe so, so Vite 7 just came out. I've actually been having a little bit of trouble just trying to keep track of some, some of the releases, it feels like they've, they've really sped up some of the development.

[03:49] They've bumped their, their node version support. Part of that is because they want to make use of the relatively recent node support for requiring ESM packages. In other words, importing an ESM module from a CGS module. Which was always the, the sticking point for a lot of the ESM common JS compatibility.

[04:10] So they're actually distributing e and Vite 7 as ESM only, which. It feels like a fairly big step in the progress of, you know, the ESM ecosystem. They're also changing the default browser target to use the baseline, widely available preset in terms of browser features. They also now have some better support for the environment.

[04:35] API, I'm still a little hazy on what exactly that does. My understanding is it, it allows you to ultimately generate bundles for different target environments, I believe is the best way to put it. So Vite 7 feels like it's a fairly big release.

[04:51] 1-vcarl: We had talked about the environment a while ago. I also don't really understand it too well, but definitely like deep in the weeds for library authors or, I don't know, framework authors. I've heard some positive things, but yeah, it seems esoteric.

[05:06] biome

[05:06] 2-acemarke: Meanwhile, we also have a slew of new formatting and lint tool leases, all seemingly with an emphasis on making things go a whole lot faster. First off Biome, which is, you know, formerly known as Rome back in the day, just released a version two, which is a fairly big deal, partly because they're, they now actually have some type aware linting rules.

[05:31] Part of the issue here is that I. Up until now, the only option for doing types based linting was to use the TypeScript ES lint package, and that involves using the TypeScript compiler actually compiling things. And so it's kind of slow, and I don't know exactly how they've managed to implement this, but Biome now has some form of lightweight type analysis that does not appear to rely on the TypeScript compiler.

[05:58] And so they've used that. To implement things like the no Floating Promises Rule. Now, it does not appear to be anywhere near as comprehensive as what TypeScript ES lent supports, but it is an interesting step in that direction.

[06:11] Void Zero

[06:11] 2-acemarke: Meanwhile, Void Zero, which is the VC backed company behind now Vite and other related build tooling development has released Oxlint 1.0.

[06:24] So we have another lint tool that is a competitor to ES lint. They're claiming they have 50 to 100 x speedups and built in support for over 500 ES lint rules. And they say it's being used in a number of major companies. So if Linting is a particularly slow portion of your build pipeline. You may wanna check that out.

[06:45] Prettier

[06:45] 2-acemarke: And meanwhile, prettier 3.6 is out and they've been working on an internal rewrite of their existing CLI to try to speed it up as well. It's not a, it's not a rewrite and rust, it's just finding more efficient ways to do the same work in JavaScript. So the general theme here is people want to do linting faster.

[07:07] jest

[07:07] 1-vcarl: Yeah, we've got a new release, new major release from Jest as well. I think we had teased this the other day because they had a beta out. But yeah, first major release in three years. Again, faster perf, faster module resolution with some better ESM support. I know that generally like crawling your modules is one of the slowest is like, you know, broadly one of the slower parts of all of these bundling linting testing, whatever tools.

[07:34] I wish I knew a little bit more details about the internals of like how just versus Vitest do it differently. 'cause my sense is that J is like heavier weight. It like does more, is more, I don't know, doing more on your disk and like crawling the condenses and all of those kinds of things. Yeah. So like one more place where there's a focus on performance in our build environment.

[07:56] 2-acemarke: Faster build tools, always a good thing.

[07:57] rn 0.80

[07:57] 2-acemarke: Those who in the audience may have noticed that MO is not here this week. He had a prior commitment and wasn't able to make it. So I will have to do a poor job of filling in and describing some of the React native changes. React Native 0.80 is out and it looks like the two biggest things out of this are they have frozen support for the legacy architecture.

[08:18] I believe one of the recent releases made the new architecture default. So they are, they're seizing work on the legacy architecture, and this also brings support for React 19.1 as well. Now along with that, I believe the current version of the Expo SDK, version 53, does not have support for this directly yet.

[08:41] If you want to use React Native 80 with Expo, they do have a canary version of the SDK that you can try out at the moment. But full support, I believe is. Or is planned that Expo SDK 54 coming out later this year would have support for React Native 0.81. So good luck trying to juggle those.

[09:03] 1-vcarl: Yeah, I know Expo has visibly been like focusing on release cadence.

[09:07] I feel like for the last year or so, it seems like they've just been releasing something, being constant. And I know that Mo has talked previously about React Native working to have a more frequent release cadence, which is also has been very apparent. Kudos to Expo for like still being able to address this. Even if it's only in a pre-lease version, we can still test it out.

[09:28] And also just like, it seems like it speaks well to the cadence that they're able to hit that they are, Expo is just saying like, yeah, we'll catch the next one because that's how fast it's gonna come out. I do wish Mo was here 'cause I feel like I see references here that make me curious to have an expert explain a little more.

[09:45] They have a good post referenced in these release notes, moving towards a stable JavaScript API. I would love to hear Mo talk about how they are getting rid of JavaScript deep imports, so that, you know, basically just like saying, here's the public API stop importing things from deep within the project, which makes sense that if you let people import whatever the heck they want from inside of your package, then yeah, you just don't have a public API and you have to support literally everything. Everything is a break and change. Seems really cool. We'll have to have Mo catch us up next month.

[10:15] webkit 26 beta

[10:15] 1-vcarl: Yeah, this is a big one that is, I wish I had slightly more context for, but WebKit Safari version 26 is in beta. They're jumping from version 18, I believe it was all the way up to 26. So that all of the different, you know, iOS, whatever technology things can all be in sync.

[10:33] This was announced of a WW BC 25 keynote. Yeah, so like Mac, os, iOS, iPad os, vision os and Watch OS are all now version 26. And so is Safari because the browser is also an operating system. Vision's a pretty large update and it has like all sorts of things from like cutting edge. Now you can use a model.

[10:54] HTML tag, if you're Envision OS to render a 3D model all the way. So like that's very cutting edge, like future looking high tech, whatever. All the way back to you can also use SBGs as your favicon. A feature that like many other B browsers have had for a decade. So they're like both pushing the envelope and playing catch up.

[11:14] Yeah. Safari has the di very different release cadence from other browsers. It's much closer to like the old style release. Cadence as opposed to how Chrome and Firefox and Edge are all like Evergreen, constantly updating. So I guess it makes sense that we're gonna have such a huge, massive dump of features, but like definitely check it out because they've got all sorts of stuff.

[11:34] HDR images, web GPU, lots of CSS changes, lots of, you know, new standardized APIs, standardized job J JavaScript, APIs, all sorts of stuff. Finally, Apollo client just shipped a release candidate for version four. The release notes for this version don't have like a consolidated list of everything that's changed, but if you scroll back some, and you look at some of the lists of the prior alphas, it's clear that the, the Apollo team has been very, very busy and I know that.

[12:05] In some discussions with Lens, who is my fellow Redux maintainer, but also works on Apollo client as his day job. They've been doing a lot of work to try to improve some of, and some of the packaging setup that had been, that had stuck around for years. One interesting side point out of this is that there's a good chance that Apollo client for might actually ship pre-compiled with the React compiler to try to optimize some of the internal hooks and components in the library.

[12:34] There was a really interesting discussion thread on Blue Sky between Lens from Apollo and Josepha from the React team where they were discussing like, should libraries go ahead and ship like React compiler pre-compiled bundles already? Does it make sense to wait until some of the compiler runtime pieces are more stable, so clear, like.

[12:58] This is very new and new and unusual territory for all of us library maintainers, and so it's interesting to see Lynn's trying to figure out some of these things that for the rest of us, yeah. That question of whether libraries should be pre-compiled with the React compiler definitely seems like a big open one in the ecosystem.

[13:18] Cool. Alright. We are sponsored by Infinite Red. We are an expert React native consultancy that's been around since 2015. I. They're our only sponsor right now, in part because very few companies do as much as they do for the ecosystem. Just they, I don't know of anyone else who's done it quite so much for quite so long.

[13:34] I've been seeing the name Internet Red around for as long as I've been in React and around React. React Native, which goes back all the way back to like 20 14, 20 15, they host the largest React Native podcast. They organized the largest React native conference in the us. They only do React native and have built over 75 apps for companies from startups to the biggest in the world, other than being great people who've done the great things to the ecosystem.

[14:00] It's a team of about 30, mostly developers, mostly with more than 10 years of experience, and something like half of them have been there since the company was created. So just, you know, dev shop with Longevity. A dev shop with loyalty to its employees. What wild, they aren't just a feature factory. They will work alongside your devs and help you develop your own expertise.

[14:20] So if you're spinning up a new product, being React native and want some help in the ground running, definitely give them a ring intimate top red. Cool. Okay. Into our main content. Start us off with your posts and talk. Hi. Yes. This is the part where I go off on things for a while, so if you, if you've been listening to the podcast for a while, you know, following me on Blue Sky or something, I've been involved in a lot of discussions and had a lot of opinions about, I.

[14:44] A number of the interactions between the React team and the community, as well as a lot of the common misconceptions that have been unfortunately running around in a lot of community threads for a while now. It seems like pretty much every time you open up a discussion, for example, about Next.JS, there's complaints that the React team has is, you know, too close to next.

[15:06] Or that Elle invented server components just to, you know, just to make money. Or why is the React team doing all these server things? Does the React team even care about, you know, single page apps anymore? And. A lot of this stuff has been going on for a while, all the way back in January and February when some of the CRE React app deprecation stuff was going on.

[15:28] I kind of got fed up for a while and I was writing an extremely long blog post that I never actually published. I did a lot of research. I wrote a lot of words. It was cathartic. In reviewing it, I concluded that publishing it probably would've burned some bridges, even if the content there was accurate.

[15:46] But there was, there was some good historical information in there and a number of folks said that it would be worth, you know, trying to publish that. Anyway, so I had a chance to speak at React Summit in Amsterdam a couple weeks ago, and my talk there was actually directly based on some of the content in the post and.

[16:07] I decided it was worth trying to revisit the draft that I never published and extract the info that was relevant to the talk and hopefully make some of the points that I'd originally tried to think of, but, you know, maybe in a slightly more tact, tactful and less inflammatory kind of way. So really the the post and the talk.

[16:28] Are trying to push back on a lot of the myths and misconceptions and FUD that have floated around in the React community for the last few years, but also point out some places where I think the React team's communication has has kind of fallen down. So a lot of people get confused about. The relationship between the React team and the next team who actually invented server components, why they were invented.

[16:55] So as usual, a good portion of the talk and the post are basically a history lesson. You know, I tried, I did my best to try to recap, as I understand it, the origin of server of server components, the timeline of when they were invented, basically that the React team invented them while they were still at Meta, before Versal ever got involved.

[17:15] And that it was something the React team invented because they ultimately, they saw the infrastructure that Meta had for server side rendering and data fetching. That was always very specific to meta and it really couldn't be generalized. And so server components was an attempt to. Implement kinda like a generic version of what Meta had for its own infrastructure, but because Meta had that infrastructure, they really couldn't iterate and Alpha test the features the way that they had everything else.

[17:47] They ended up reaching out to Versal and getting Versal to build out the React team's vision of what they wanted to do. So a lot of this was me attempting to push back on the Versal invented server components to make money narrative. But then I also ended up addressing some of my points of concern where the lack of documentation about server components.

[18:11] Has been a point of confusion. People not understanding when do I use them, how much should I use them? Is the React telling me to use them or are they optional? As well as a lot of the, the back and forth about why are the docs pushing the concept of frameworks so hard. And so I went into some details on my understanding of the React team's rationales for actually trained to say frameworks should be the default way to use react.

[18:39] I put a lot of effort into it. I hope it's been informative and the feedback to the post and the talk have been pretty good. Dan Abramov actually retweeted it and basically said that, you know, he, he had a couple nitpicks about the way I described some of the timelines and bits of info, and he actually passed me some corrections on the side, which I tried to, to fill in, but he seemed to think it was generally accurate, and also he said that he'd been kind of stuck.

[19:06] Debating whether to write his own history post, and he might end up being able to write one. Now that I've done most of the heavy lifting on it, that at least tells me I was directionally accurate. I. Like I can't have been too far off if he wanted to correct me on. So I don't expect that my me writing a post and doing a conference talk is going to silence a lot of the confusion, but at least I've done my best to try to clarify things.

[19:33] So hopefully we'll see. Yeah, I think it's really valuable is to just check in every couple of years I'm like, what is. True. What did happen? What, what were the facts here? Oral history is very, very valuable. Sometimes capture some of that local knowledge. You put it in the paper. Yeah. I would be very curious to see what kind of oral history Dan OV can write though.

[19:52] That's, uh, you know, you and I have been paying attention for a long time, but we have not been. Operating anywhere near the same level as Dan has for as long as he has. I would say, I hope it doesn't feel unfair to make the same claim for you, but useful post. Interesting. I think it's interesting too, how I.

[20:10] As big as reactors, you know, the millions of people using it and relying on it and affected by it. At its core, the people in control of it is still like very countable. You know, it's not like unaccountable machine of like hundreds of people turning knobs and dials and you know, like it is at the end of the day, very much a core group of a handful of people making a lot of these decisions and doing a lot of this work.

[20:37] And I feel like that's maybe, I don't know, that feels relevant when we're discussing its evolution and such. There's a team page in the React Docs and that page Curie lists about 20 people. There's about 13 to 15 at Meta at the moment. There's about five people at Versal, and then there's two or three sort of independent slash emeritus people.

[21:00] So for example, Dan Abramov is not directly on the team at this point, actually. I'm not even sure if he's still listed on the page. I would've to double check. Sophie Alpert, who was at Meta for a number of years is still listed on the team page. I don't think she does a lot of development at this point, but still involved in discussions.

[21:19] So it's about 20 ish people that would be considered sort of the, the core team that's separate from, you know, whoever might be doing like React native or other pieces like that. Right. React native is its own court team, which I think is larger. Yeah, I can confirm. Dan Amont was still listed on the meet between page second, so very highly along with me giving my talk.

[21:43] Earlier in the afternoon. Tanner Winsley did a talk about couple different things. Some of it was, you know, pitching the various 10 stack pieces. So router query the upcoming 10 Stack start framework as well. But part of his thesis was that. Single page apps are still by far the dominant way to build React, even if there's been more of an emphasis on server side pieces in the last few years.

[22:10] He really likes single page apps and a lot of his goal is to build good tooling that would be used by single page apps. I don't think any of the talks from React Summit are are online yet. I think they said they would try to have 'em online within two to three weeks after the conference. I haven't seen a notification that any of 'em were up yet, but I would definitely recommend watching Tanner's talk once the video for that's available.

[22:38] Yeah, maybe we can, oh wait. Oh wait, I see a playlist. No, there's only five videos on it. Yeah. Maybe we'll be able to share those out next month. Yeah, they, I believe they, they're generally put up directly on get nation.org or.com, I think, rather than being listed in the YouTube channel. But we'll have to see.

[22:57] Okay. I do see a React Summit 2025 playlist that has a couple of videos with like children views, maybe a ways to watch. Yeah. Moving on. Remix React router, going back to last month. So we've had a lot of. Back and forth between what is Remix, what is React Router? First we had React Router, the client side, LI Library.

[23:21] Then we had Remix the SSR framework, and then we had Brian Forres announcement at React Conf, I think two years ago that most of the features in Remix we're going to migrate back to React router. And so React router gained things like loaders and a framework mode, and they announced that Remix was going into some kind of hibernation.

[23:46] What was Remix is now basically all in React router, version seven I. And so Remix had kind of stopped development at version two last month. We talked about the announcement post where they said that Remix V three is coming. It's going to be very different. It's not just like, you know, upgrade to the latest version of React Features or something like that, but instead that it would be.

[24:12] A new framework, one that actually is gonna use a fork of the pre-ACT alternative library, and with various emphasis on things like LLM based development and no bundling. That's the context for where things stand with Remix and react Router as a whole. So from there, Ryan for and Michael Jackson are both pr, you know, still pretty active on Twitter and they've been making a lot of comments that are either teasing things in directions that they want to go with Remix, but also, I'm not entirely gonna call them like clickbait or flame bait posts.

[24:55] But kind of close stating a number of opinions about React itself that frankly make me very, very, very confused about what it is. Remix V three is actually even gonna look like. An example of this would be that Michael Jackson recently tweeted that he's now very disillusioned with React Hooks. You might even remember that Ryan Florence did one of the original talks at React Con 2018 where he helped, you know, demo React hooks for the first time.

[25:22] And you know, granted, this is Michael's comment, not Ryan's, but I think it kind of shows their shift in mindset over the last seven years. Yeah, definitely big moves. I don't know, there's. They've been such big figures throughout my career. Like when I was learning React, I learned React rather in parallel, in like literally 2014.

[25:44] And it's a little bit funny to have like been there for the whole saga because I've just watched them go like back and forth and back and forth on like what should be the API do. We care about data fetch at the router level. Just like watching them explore this and like watching their opinions shift and evolve and like double back and unfold in slightly different directions.

[26:06] It's, I don't know, it is a bit of a surprise. I, I don't know. It is and isn't surprising to see Michael Jackson here come out against hooks. Also, I'll just say I was trying to confirm whether Michael Jackson still worked at Remix post Shopify acquisition, but I, I had a funny interaction years ago, managed to get enough of the profile in the ecosystem where Michael Jackson was following me on Twitter and we had a interaction during COVD about like lockdown stuff, where he was skeptical of lockdown.

[26:36] And I was like, it's keeping people safe. And he ended up unfollowing me. So I don't know, like that felt like, that felt like a moment, that was a moment for me. I dunno, big famous person in the ecosystem unfollows you on Twitter. Like it stuck in my head and I don't know, it's just like, to me that feels like that feels relevant here as like point of contrarian and like, I don't know.

[26:56] It's seemed since then that there was kinda like a closing off since then of him being like, Nope, I believe what I believe and I'm very confident that it is right. And like, screw all you. So I don't know. This is interesting. On the one hand, like hell yeah. Know your principles live by them and put the work in and like he's doing that.

[27:16] Heck yeah. It's interesting hearing him say like, I don't like hooks. They're not great. And also like I relate to that. I don't know, like I, I started like learning hooks and like rewriting a bunch of code and using them professionally for a number of years. It felt like there was a right way to solve the problem.

[27:35] It felt like I was, it felt less like I was writing code and like doing a thing and more like I was figuring out a puzzle somebody else had made with a right answer. And if you didn't get just the right answer, like you kind of had to start over. You know, it felt video gamey in that way of like, you make a bunch of progress and then you realize that you're at a dead end and it's like, let me start over.

[27:54] I think that, you know, that feels like what he's complaining about here. You know, everything about them just seems so unnecessarily complex. But then he is also like down on signals, which is what a lot of other people are very pro. I'm also skeptical having used, I don't know there, I hear there are differences from event emitters, but I'm skeptical that the differences are that significant.

[28:16] I keep hearing similar trade offs about circular dependencies and like event storm type of stuff. So if he's rejected like pokes and signals, which are the two top of mind ways of dealing with reactivity in React. And he's also stated the intent to use a fork of a fork of react in Remix D three. Yeah, whatever that's gonna be called.

[28:39] I don't know. It's interesting. Like it doesn't sound like it's react anymore. It sounds like it's, he's gonna try and explore. The same problem space that React has been exploring, but doing so while challenging some of the core assumptions. So I don't know, it's space to watch. Yeah. And, and to be clear, like I'm, I'm not sitting here and saying like, oh no, Michael Jackson hate hooks.

[29:00] He's a bad person. And anyone who's actually. Excuse, react, understands that hooks have trade-offs. They are not perfect. They have a different set of trade-offs than class components did. There are a lot of pain points, depths, arrays, data flow, you know, reactivity, mental models, et cetera. I am certainly very well aware that.

[29:21] Hooks have their own set of trade-offs and flaws. But yeah, like my point, looking at the thread and this discussion is basically what you were saying, like Remix was a react based framework in version one and version two, Remix V three is not a React based. Framework, but given that they don't seem to like hooks and they don't seem to like signals at this point, I just honestly have no idea what it is they're even trying to build or what the feature set is, what the.

[29:56] Usage patterns are supposed to be. I, I am just, I, I, I don't have a good mental model for what it is they're trying to do at this point, just by reading the discussion and the tweets. I believe they said that, I think there's a, a Remix jam conference coming up later this year. I think possibly in Toronto, if I remember hearing correctly.

[30:18] I don't have a date for that off the top of my head, but I think it's this fall, and I think I've seen them say that they will have some announcements to make. At Remix Jam, which is understandable. I don't know, like I'm curious to see what they've got, but it, it doesn't seem like we'll really have a decent understanding until they make an actual announcement and then there's good documentation to look at, and then we could critique that.

[30:39] Yeah. Right. So, I don't know. I'm curious. If they have my attention, for sure. It feels like they're being coy about it too. I feel like they have a lot more of this banged out than they're talking about and you know, I feel like there's a private group chat or like a secret repo somewhere that it'd be very fascinating to get access to.

[30:57] Another little bit about this, they have posted about the open governance. Technical committee, steering committee that reactor adder will now have, I hold some skepticism, some level of skepticism just based on like the contents of this governance stock that you know, this governance announcement blog post, like notably the only people on the steering committee at inception, our existing Remix and react to router contributors, the announcement and the governance model.

[31:28] Both focus very heavily on technical goals while discussing governance and how this is going to be open and like, you know, participant participatory from the ecosystem and whatever. They set up a lot of fences pretty early and strongly of this is what we care about. This is the direction we're gonna be going.

[31:46] So like saying, not including outside people in the initial steering committee. And very aggressively setting direction while discussing open governance to me says this is visible governance, but I don't know if it's gonna be open to that, open to outside participators. Yeah. This feels reminiscent of like some of the working groups in the React ecosystem where they, we were just, you know, a little bit, they had blinders on.

[32:11] They were gonna do their thing and they did their thing and that's great, but it's, it's not that open, it's not really that participatory. So this is, this is one that I've only partly read, but it feels like there's some amount of relevance. So the RAD X UI is a headless UI library that is pretty popular, especially because it's been used by the Shad CN component library.

[32:36] But RAD X UI has been borderline unmaintained for quite a while. I believe the library itself got bought out a while back by a company called Work Os. And there's now basically a, a halftime maintainer of the library. And I've actually spoken to that maintainer before at a conference and he is like, yeah, I'm, I'm pretty burned out.

[32:59] And I would almost rather like not even do anything with redix at this point. I. So there was some chatter in the last few weeks about whether people really ought to even be using it at this point. And apparently one of the original co-creators of Readex is now working on a competing package called Base ui.

[33:20] And so basically saying that, look, Readex is unmaintained. Try using base ui, try using Aria kit. So I, I don't necessarily have a lot more feedback and thought and no, I have not seen Theo's video on it, so I have no opinions there. I will say that just because something is not getting active maintenance does not mean that the code is dead or suddenly more broken.

[33:46] But I can definitely understand people's reluctance to use something that isn't getting, you know, like still getting active fixes. Yeah, I do have some opinions. I think that to some extent, like I don't really expect that much active maintenance from a like mature and wide used component library because there's not really that much changing in how you would develop a component library.

[34:12] Like there has been so many component libraries. All like, you know, building on each other and exploring different directions and like pulling different types of abstractions and different types of like interactivity or whatever, different developer experiences. Going back for like long enough that it's pretty well trot ground at this point, and for a very long time it reacts life.

[34:37] The patterns and the abstractions and the ecosystem they existed in were churning very heavily, and so it, it was not that surprising to see new component libraries coming out like every, you know, six months because there were meaningful differences. Every six months, you know, like, you know, is, is this written with higher order components or render props or hooks or, right.

[35:00] Oh, you know, like when I first started, I started writing things with mix-ins, and then I was like, wow, mix-ins are, and then someone was like, oh, here's a higher order component. I was like, oh, that's cool. Let me try that. And then someone was like, here's a render prop. Here's a hook. You know? Now node and MPM support different modes of like consuming libraries.

[35:21] And so now as a component library maintainer, I need to go refactor everything to support tree shaking or to be ESM only. So like there's just been so many big seismic shifts that like, yeah, we got used to that, but it's not really, that hasn't really been strongly the case for a minute now, like I would say, I.

[35:44] 2022. I feel like it was when we had a, started getting, you know, as an ecosystem, the wisdom of how to use hooks had really settled down pretty well. Like we, we explored a lot of patterns and figured out things that did or did not work. And Hooks came out in 2018. 2022 is like four years of like playing with them.

[36:06] And then that was three years ago. So like we've been, we've had a stable set of primitive tools within React. For doing abstractions for seven years now, which is absolutely, you know, that's longer than pre hooks. We only have three years before hooks existed. Four years, maybe five. No, it was 2013 when it came out.

[36:25] So like that's more time with hooks than we had without hooks. So I don't know, like. I see this thread started with hot tape using Chad CN slash radix. The liability at this point, and maybe this is also an echo of a point that I try to drive home periodically on this podcast of like there are many different audiences using React and if you're an indie hacker than your constraints are extremely different from someone four years into maintaining a legacy application that's making tens of millions dollars for its parent company.

[36:56] So like. This hot take sounds to me like someone doing small team build it and set it down projects, not somebody maintaining a legacy application. So like, sure, if you are trying to use the latest, greatest, sharpest leading edge tools, I. Is maybe that, not that name water, but I don't think it's getting rusty that quickly.

[37:16] So like if you are not building a new thing every three months, I think it's probably fine. I dunno. Seems okay. And like, and you know, oh there was a really great, oh shoot, did I lose the link? There's a really great, I. Response that I saw from the maintainer of chat already, just baed it in. Lovely. Yes, thank you.

[37:33] You just did that. Yeah. And he says, he says a lot of things that resonate with me that I think I have hit on here. Like here's what I'd suggest already. There's a quote here, here's what I'd suggest already using redix and prod. Stick with it. Starting a new project. Consider ics React Aria or Aria Kid.

[37:49] All great choices. So like, yeah, that's, I would agree with all of that. And he closes this, what I'd suggest section with Shae is built for this code. Your own code can approve, rewrite or replace and like, yeah, that's the whole like reason for Shae and being built in the way it was, is that like it's not a library if you're unhappy with it, it's your code, it's hidden, your repo, you committed it.

[38:11] So change it, commit something else. So I don't know. It seems cool. This seems, not that I have a lot of opinions on this, but at the end of the day, my opinion is like chill out, care less. Do the thing that's right for you. I guess in a very broad level, the JS ecosystem is entirely too prone to saying Tool X is dead because tool Y exists.

[38:34] Yeah, I could rant about that. The human trend towards X is dead long lives. The new X on with Y? Yeah. Okay. I think we've beaten that to death now. Okay. Into our lightning round. I don't have too much to say on this, but I like it. This is a blog post. Of somebody writing React components. Enclosure, this is part three of his series, and that just seems to be, I don't know.

[39:01] I love seeing people play around with server components more and playing around in different languages, in different room times. Is extra interesting, so that's cool. Just a great like use case, write up. There's been a subset of the closure script, whatever community that's used, react in their own way for many years now.

[39:21] So seeing, seeing someone attempt to bring server components over in that direction's kind of cool. Dan Abramov has continued to crank out blog posts and he put out a couple more since we did our, our last podcast. He wrote one on progressive JSON, where he talks about how server components will progressively send over pieces of JSON and insert placeholders via suspense.

[39:44] And then he did another post on how imports work with server components. And the majority of this post actually doesn't have anything to do with. Server components per se. It's really describing how the JavaScript module ecosystem works and then brings in some bits about how server components allow you to connect the dots between the client side and the server side, as well as enforce that certain code only exists on one side or the other.

[40:13] We've got new ES 2025 out, which seems pretty good. Man, I, it, it took me a little bit to catch up on. Order of operations and what came out when. So this is everything. This contains everything that went to stage four, more or less over the past year. The most recent stage four is going out in 2026. So this what's contained here is Sync Iterator Helpers Promise.

[40:40] Try some new set methods. Methods on the set primitive. That is JSON modules for imports. Import attributes and then a couple of like Redex updates for escape and modifiers and main capture capture groups. Sync iterators. Sync Iterator helpers are definitely the most like, interesting thing on this list to me.

[41:00] Just like they're the, the number of times that I've taken a set or, you know, some iterable and then spread it out into an array so that it can map over. It is like constantly. I, every time I use an Iterable, I'm doing stuff like that because I like using e. Map and four each more than I like doing four ofs, so that's cool.

[41:19] I'm excited to see that. Just being able to natively map over Iterable is lovely and I love it. One thing that's probably worth noting is that apparently the iterator support is, might be a little better for perf in some cases because it doesn't have to create a separate array every time you do like a filter or a map, right?

[41:37] That's the main thing I think about every time I do that. Oh man, I'm just iterating a new array for no reason. New RA for no reason and kind of related promise that try is sort of a similar type of performance optimization, you know, performance micro optimization. This, the last time I was reading about it, the advantage I saw is that it lets you, it lets you ignore whether something is or is not a promise without skipping a tick.

[42:03] If it is a promise, you know, and you do a dot, then like, okay, it's gonna consume a tick. But if it's not a promise and you wanna just run something afterwards. All of the like poly fills for something like promise try that would let you exit. Whether or not it returns, a promise would consume a tick. So now that, that's the advantage here is if it, if you're looking for that, it just is a little bit faster.

[42:27] It's a little bit less talking. Then the, the set methods are a very nice, convenient thing. Sets now have built-in methods for intersection union difference, and a couple other things, which is something that really should have been in there from the beginning. Yeah. Definitely, there's so many more details on Axel Meyer's blog, so like definitely the dive into that and yeah, little teaser of ES 2026 is they have already sh shipped.

[42:57] Well, they've already landed. Error is error, like an identity function for errors. So you can actually get like type safety in catch blocks. More easily. That is stage four, but it did not make the cutoff for S 2025, so that'll be out in 2027. There was a post on the Shopify engineering blog about the future of React Native Graphics Web GPU, SKIA and beyond.

[43:21] The land of low level 2D graphics toolkits is complex with. Wrappers and abstractions and cross compat and all kinds of other layers of complexity. And so the post goes into into details on the existing React Native ski, a package for 2D graphics, how they've been able to add web GPU support to React native so they can do things like running three JS inside and some of the other upcoming improvements to React Native Skia as well.

[43:51] Yeah, I, I know I've heard Mo talk about Yeah. A couple of times. See it getting, I don't know, broader. It seems cool. It's neat to see it still going, still chugging along. Cool. This is a personal plug. I wrote a blog post for the node js blog. I. It's June, it's Pride month. I'm proud. I have not always, I have accepted within the last couple of years that I am queer and began understanding what the heck that actually means.

[44:18] I was asked to write a blog post for Pride and I pulled together one discussing open source and it's parallels with queer identity and how you know, we all take the labels that exist. Learn from them, incorporate them into our understanding of ourselves and use those as a springboard to find new things.

[44:38] So, I don't know. I'm proud of it. I like it. It's a good post if you're interested. Check it out. Yeah, I, I've been checking the Twitter replies on the announcement and yeah. Yep. Those people still exist. They don't like it. So anyway, it's all I'll say on that. Closing with conferences, we have a quite a number of conferences coming up, like basically next week, July 3rd through fifth.

[45:00] Is React Nexus in Bangalore, India. There is Big Sky devcon out in Bozeman, Montana. Which seems cool. I don't know. I I appreciate that. It's called Big Sky. I know that there's a, I think there's a big Sky National Park and I, I used to do astrophotography, so big skies are like near and dear to my heart. So this one just looks sweet.

[45:22] I don't know. I don't have any, there's not no other reason beyond that for me to have an affinity foot, but I like it. So if you can get up to Bozeman, Montana. There's Kansas City Developer Conference, August 13th through 14th of Kansas City, Kansas. KCBC. 2025, which made me assume from the label that Kent c Dodds might be affiliated, but he is not.

[45:42] It is not. Kent c Dodds conference. It's Kansas City Developer Conference. There is React Universe, September 2nd through fourth in Poland. Then September 16th and 17th, Wacon also in Poland back to back pretty much after Wacon. There's Cascadia Js up in Seattle, Washington, September 18th and 19th. So I think Squiggle conf is happening in Boston the exact same time.

[46:07] I. Yeah, you've got SW Con, September 18th, 19th, Boston, Massachusetts. They are great. I plan to be there. This is slightly further afield for further down the line, but React Cons will be back in LA in Las Vegas. I. October 7th and eighth. So yeah, I was there last year and it was a pretty great time.

[46:26] Definitely check it out. Although tickets are expensive and lottery system, so good luck. That's everything we got for you this month. Thank you so much for joining us. We will be back next month. I hesitate to promise on Wednesday because we have not done that in a minute, but maybe next month on Wednesday here in the live stage, or we'll be back in your podcast feed just as soon as we can after that.

[46:46] Scheduling is hard. Yo scheduling is so hard. We gather sources from this week in React Bites. Do Dev React status, Next.JS Weekly the React JS subreddit. And here in react to plugs from the Tech News Andres channel. If you have any news that you wanna share with us. Tech Reads and News is a great place to do so, or you can send it to us at hello@reactiveflex.com.

[47:09] If this is a show that you get value from and would like to support, one of the best ways you can do so is give it a review on whatever platform you listen to, listen to it on, and just share it with friends, share it with coworkers. Go to a meetup and say, Hey, there's this great podcast. I like. Yeah, thanks so much for listening.

[47:25] We'll see you next month. Take care.

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

Reactiflux — Thu, 29 May 2025 16:00:00 GMT

[00:54] Quick hits
- [00:57] Job market: FRED data, Layoffs.fyi, Trueup.io
- [01:19] Conferences (React, Javascript)
  - [01:20] React Summit June 13-17 Amsterdam, NL
  - [01:57] Render ATL June 11-13 Atlanta, GA, USA
[02:12] Sponsored by Infinite Red
[02:59] New releases
- [03:01] TanStack/db
- [05:28] Legend List 1.0 released
- [06:48] Redux Toolkit v2.8.0 (and bugfixes after)
- [07:37] MUI v7.1
- [08:30] Jest has a v30 beta.3 + 4 out. First alpha of it was published October 2023
- [09:11] Zustand 5.0.5, Jotai 2.12.4 and .5
  - [09:17] devstore deprecated
- [09:28] Radix has new primitives: OneTimePasswordField and PasswordToggleField
- [09:38] Ant Design 5.25
- [10:02] React Aria May 19, 2025 release
- [10:21] Relay 19 with React 19 support
- [10:29] Storybook 9
[10:38] Main Content
- [10:45] Expo SDK 53 release
  - [16:01] Package.json imports support
- [17:32] React Router RSC preview and other RSC topics:
  - [20:49] Vite community PR to add RSC support
  - [21:33] Leerob’s list of other RSC explorations
- [21:44] More Dan posts, like Static as a Server and One Roundtrip Per Navigation
- [22:33] RedwoodSDK’s “Your React Framework Feels Broken”
- [23:20] Remix v3 announcement
  - [26:04] Discussion between Evan You and Michael Jackson about bundling / HMR approach and tradeoffs
- [29:56] React Core WIP
  - [30:08] React MCP server
  - [34:08] “Concurrent store” skeleton PR a concurrent-compatible integration for external libraries
  - [35:49] <SuspenseList> being worked on again
  - [36:29] Compiler integrations with SWC and OXC
- [37:19] Apple App Store Epic Games Saga 30% Apple cut ruled unlawful in the US
- [40:59] Next reducing Vercel mentions in docs
[45:52] ⚡ Lightning round ⚡
- [45:54] Shared Element Transitions in Reanimated
- [46:56] V8 explicit compiler hints
- [48:05] TS Native Previews (usable build of the Go-based compiler)
- [48:26] Vite + Rolldown preview build
- [49:10] Seeded pseudo-random number proposal advances to Stage 2
- [50:34] 3-layer data data fetching for complex React apps (RSCs, React Query, optimistic UI)
- [51:05] Johannes Schickling announces LiveStore (reactive SQLite + sync layer)
[53:02] Outro

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

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

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

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

Quick hits

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

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

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

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

Conferences (React, Javascript)

Carl: upcoming conferences. [01:19]

React Summit June 13-17 Amsterdam, NL

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

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

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

Render ATL June 11-13 Atlanta, GA, USA

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

Sponsored by Infinite Red

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

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

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

New releases

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

TanStack/db

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

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

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

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

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

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

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

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

Legend List 1.0 released

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

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

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

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

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

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

Redux Toolkit v2.8.0 (and bugfixes after)

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

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

MUI v7.1

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

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

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

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

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

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

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

Zustand 5.0.5, Jotai 2.12.4 and .5

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

devstore deprecated

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

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

Radix has new primitives: OneTimePasswordField and PasswordToggleField

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

Ant Design 5.25

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

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

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

React Aria May 19, 2025 release

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

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

Relay 19 with React 19 support

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

Storybook 9

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

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

Main Content

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

Expo SDK 53 release

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Package.json imports support

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

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

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

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

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

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

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

React Router RSC preview and other RSC topics:

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

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

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

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

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

Vite community PR to add RSC support

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

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

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

Leerob’s list of other RSC explorations

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

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

RedwoodSDK’s “Your React Framework Feels Broken”

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

Remix v3 announcement

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

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

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

Carl: Yeah, true. [24:45]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

React Core WIP

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

React MCP server

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<SuspenseList> being worked on again

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

Compiler integrations with SWC and OXC

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

After all. [37:19]

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

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

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

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

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

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

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

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

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

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

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

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

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

Still quite significant. [40:53]

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

Carl: All right. [40:59]

Next reducing Vercel mentions in docs

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

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

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

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

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

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

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

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

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

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

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

I don't know. [45:24]

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

CloudFlare is probably a different, [45:45]

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

⚡ Lightning round ⚡

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

Shared Element Transitions in Reanimated

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

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

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

V8 explicit compiler hints

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

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

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

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

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

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

Vite + Rolldown preview build

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

Seeded pseudo-random number proposal advances to Stage 2

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

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

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

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

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

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

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

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

Johannes Schickling announces LiveStore (reactive SQLite + sync layer)

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

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

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

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

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

Carl: Right. [52:55]

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

Outro

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

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

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

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

Mark: Take care. [53:56]

TMiR 2025-04: React 19.1 helps debug owner stacks

Reactiflux — Tue, 22 Apr 2025 16:00:00 GMT

Quick hits
- [00:52] Job market: FRED data, Layoffs.fyi, Trueup.io
- [01:50] Conferences (React, Javascript)
  - [01:53] App.js Conf May 28-30 Kraków, Poland
  - [01:59] CityJS Athens May 27-31 Athens, Greece
  - [02:04] React Summit June 13-17 Amsterdam, NL
  - [02:09] React Conf is back Oct 7-8
  - [02:22] SquiggleConf 2025 CFP closes May 23
- [02:37] Sponsored by Infinite Red
- [03:24] New releases
  - [03:27] Anime.js v4
  - [04:03] RN v79
  - [05:00] Next.js 15.3
  - [05:20] Rspack joins the Next.js ecosystem
  - [06:29] React Aria April 11th
  - [07:13] Redux Toolkit 2.7
  - [07:44] Vitest 3.1
[07:55] Main Content
- [07:57] React Labs: View Transitions, Activity, and more
- [22:04] React 19.1
- [27:48] Dan Abramov is writing again
  - [29:09] React for Two Computers (Complement to his React Conf talk)
  - [29:26] JSX Over The Wire
  - [30:11] Impossible Components
  - [35:28] don’t 👏 ruin 👏 his 👏 process
[35:47] ⚡ Lightning round ⚡
- [35:48] Next.js RFC: Deployment Adapters API
- [36:23] flightcontrol.dev from last year: Secret knowledge to self-host Next.js
- [36:38] Styled-Components in maintenance mode
- [37:15] RIP Styled-Components. Now What?
- [38:50] Redwood announces new Cloudflare-based RSC SDK, existing framework in community maintenance mode
- [40:18] TC39 kills Records and Tuples proposal. Possible alternative is “Composites”
- [41:36] React Compiler RC
- [42:29] "Just use Vite”… with the Workers runtime (Vite on Cloudflare)
- [44:21] Silk Library - native-like swipeables for the web
- [45:22] {transitions} = f(state)
- [45:51] Tailwind 4, Bun, and old Macs: A Supermarket Bag And a Truckload Of FOMO
- [46:47] Introducing Firebase Studio
- [49:05] Gumroad is open source!
- [49:50] Automattic laid off 16% of staff

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: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: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: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:51]

Carl: Heck yeah. [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. [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. [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. [01:45]

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

Conferences (React, Javascript)

Carl: So upcoming conferences in May! [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 [01:59]

CityJS Athens May 27-31 Athens, Greece

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

React Summit June 13-17 Amsterdam, NL

Carl: Then in June we've got a React Summit in Amsterdam. [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. [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. [02:37]

Sponsored by Infinite Red

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. [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. [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. [03:24]

New releases

Carl: Okay, running through some new releases. [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. [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. [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. [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. [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, [04:48]

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

Mark: That's a pretty solid cadence. [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. [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. [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. [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. [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. [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. [06:29]

React Aria April 11th

Carl: Yeah, react Aria by Adobe had a release. [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. [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. [07:13]

Redux Toolkit 2.7

Mark: Last week I shipped Redux Toolkit 2.7 as I was on my flight to React Miami. [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. [07:41]

Carl: That's super cool. I love generated types. [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. [07:55]

Main Content

Carl: Yeah, into our main content. [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? [08:14]

They do like what, maybe two of these a year? [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. [08:24]

Carl: dated React Labs, March, 2023, react Labs, February, 2024, and now April, 2025. [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. [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 [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. [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. [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. [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. [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. [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. [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. [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. [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 [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. [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. [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. [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." [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. [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. [15:45]

People still think of it that way. [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. [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. [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. [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. [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. [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. [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. [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. [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. [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. [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, [19:33]

Carl: That makes sense. Yeah. [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. [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. [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. [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. [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. [22:04]

React 19.1

Carl: Let's move on to React 19.1. [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. [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. [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. [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. [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. [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. [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. [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 [24:39]

Mark: I will caveat that one. [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. [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. [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. [26:07]

Mark: generally speaking Composition is a good thing that more developers would benefit from taking advantage of. [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. [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? [26:52]

Mark: Yep. [26:52]

Carl: Anyway, super cool to see it surfaced. [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. [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. [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. [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. [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? [28:00]

Mark: Many, many hours. Like I, I read fairly fast and there, there is a lot of content there. [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. [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. [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? [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? [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. [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, [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. [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? [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. [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. [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. [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. [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? [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. [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. [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." [35:44]

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

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

⚡ Lightning round ⚡

Carl: Okay. Lightning round. [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. [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. [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. [36:33]

So that seems like a relevant read in, in conjunction with this new deployment adapters. [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. [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. [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. [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. [38:48]

Mark: I would not have thought about that. [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?" [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. [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. [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. [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. [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. [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. [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. [42:27]

So it's getting fairly close. [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. [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. [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. [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. [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 [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. [44:12]

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

Carl: Yeah, this one looks a lot less major than the next one, but yeah, they did get a CVE. [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. [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. [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 [45:17]

Carl: reminds me of like sublime text, sublime merge, like the, the shareware. Please, please pay us. [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. [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. [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. [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. [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. [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. [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. [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. [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. [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. [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. [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? [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. [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. [50:51]

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

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

Not people unrelated, but Yes. Ugh. [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. [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 [51:20]

Mo: I hope he also loses any bonuses that he was banking on getting this year [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. [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. [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. [52:09]

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

Mo: See you all next month.

TMiR 2025-03: Next had an auth vulnerability, TypeScript is porting to Golang

Reactiflux — Tue, 25 Mar 2025 16:00:00 GMT

[00:45] Job market: FRED data, Layoffs.fyi
[01:28] Conferences (React, Javascript)
- [01:29] React Native Connection April 3 + 4, 2025 Paris, France
- [01:36] React Miami, Apr 17-18
- [01:49] CityJS London April 23-25 London, UK
- [01:55] App.js Conf May 28-30 Kraków, Poland
- [02:06] CityJS Athens May 27-31 Athens, Greece
- [02:13] SquiggleConf 2025 CFP closes May 23
[03:19] Sponsored by Infinite Red
[04:24] New releases
- [04:26] TypeScript 5.8
- [05:00] Typescript Release with Go
- [06:26] React Native 0.78 - React 19 and more
- [06:44] Next 15.2
- [07:07] Tanstack Form 1.0
- [07:54] Zeego v3
- [09:04] Material UI v7
  - [09:04] "Slot pattern" for overriding internals
- [10:45] Parcel v2.14
- [12:33] XState Store v3
- [13:11] Better Auth v1.2
[14:31] Main Content
- [14:31] Lynx released
- [14:33] Release blog
- [18:20] Security vulneratibility in Next.js: CVE-2025-29927[18:20] Original researcher report
- [20:36] CVEs and the NVD Process
- [25:03] Postmortem on Next.js Middleware bypass
- [27:00] Next.js and Coordinated Disclosure
- [30:17] You should know this before choosing Next.js
- [31:37] React Native 0.78 - React 19 and more
- [34:27] React Native Core Contributor Summit 2024 Recap
- [36:42] TypeScript compiler Golang rewrite??
- [41:23] Github discussion and on reddit too
[44:50] ⚡ Lightning round ⚡
- [44:52] JSC being extracted from RN Core
- [45:22] node-modules.dev v0.4.0
- [46:00] Fernando Rojo joining Vercel as Head of Mobile
- [46:41] Next vs TanStack (Router + Vite)
- [47:46] Expo’s AI Strategy
- [48:39] Laravel launched “starter kits” including React
- [49:36] React Native Enterprise Framework
- [50:36] State of React Native 2024 [00:00]

Carl: Thank you everyone for joining us for the March edition of this month in React, where we recap and digest the recent developments in the ever evolving react and web ecosystem. We are coming to you live here in Reactiflux, the place for professional react developers. [00:14]

And we are supported by infinite red, but more on them later. I am Carl. I'm a staff product developer and freelance community leader here in Reactiflux, where I run community programs like these events and build tools to help keep the community operating. [00:28]

Mark: Hi, I'm Mark. My day job is working at Replay io, where we're building a time traveling debugger for JavaScript, and also trying to find ways to make AI developers smarter by giving them access to replay runtime data and in my copious amounts of spare time. Outside of that, I do redux stuff. [00:45]

Job market: FRED data, Layoffs.fyi

Carl: Some early quick hits. My general temperature check on the job market is that it's not good. It seems bad. Layoffs for March are higher than they were in every month, except last month since September, 2024. So that's five months, yeah, that's not great. It seems like hiring is down. Oh yeah. Look at that. The Fred economic data is a continued decline, so that's not ideal. I guess that is software development, job posting, so I wonder if maybe there's like some kind of title shift leading to that decline as well. [01:20]

But yeah, job market not good. So yeah, if you are on the market, I hope you are. I don't know. Good luck. Sorry. [01:28]

Conferences (React, Javascript)

Carl: Upcoming conferences. [01:29]

React Native Connection April 3 + 4, 2025 Paris, France

Carl: There is React Native Connection April 3rd and fourth in Paris. So if you're in France, definitely check that out. [01:36]

React Miami, Apr 17-18

Carl: React Miami. A beloved conference that I have attended several times but will not be at this year. [01:41]

Is April 17th and 18th in Miami, Florida. [01:45]

Mark: I'll be hanging out there. [01:47]

Carl: now go see Mark. He'll say, Hey . [01:49]

CityJS London April 23-25 London, UK

Carl: There's City Js London on April 23rd through 25th in London, the uk. [01:55]

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

Carl: We've also got App JS Conf May 28th through 30th in Cacao Poland. I've heard good things. I looked at going, but it's just can't swing it. Too big of a trip. [02:06]

CityJS Athens May 27-31 Athens, Greece

Carl: CDJS Athens is also gonna be May 27th through 31st in Athens, Greece. [02:13]

SquiggleConf 2025 CFP closes May 23

Carl: And I'm helping organize squiggle conf, which is coming up much later this year. But their CFP is open, so if you are interested in speaking go ahead. Submit. It's gonna be open until May 23rd. [02:26]

Mark: I, I got to attend Squiggle Con last year. I, I also know the organizers, Dmitri and Josh, they're wonderful people. They did a fantastic job for a first year conference last year. Squiggle Conf was great. You should totally try to go. It's in, it's in Boston. [02:40]

Carl: It is in Boston. Yeah. Dmitri, his most recent accomplishment that made pretty big waves is he got doom running in TypeScript types, which is bananas, and took like a year and a half and he had to learn all sorts of like compiler and like processor stuff. Yeah. Unbelievable. [02:56]

Mark: we should totally toss a link to that in here on general principal. [02:59]

Carl: Yeah, we probably should. I don't have one handy. But yeah, super cool. Super impressive. Unbelievable maniacal in fact. But yeah. [03:06]

Yeah, our sponsor you know, bear with us through all of our setup stuff before we get to the real news. We, there's so much news. We've got like a pretty major security vulnerability in next. [03:17]

There's like a couple of new releases to talk about, but yeah. [03:19]

Sponsored by Infinite Red

Carl: We are sponsored by Infinite Red. They are an expert react native consultancy that's been around since 2015. And I actually just saw a post that they put up on LinkedIn where in 2015 they hired 21 people and 14 of those 21 are still there, like 10 year tenure for two thirds of the organization. Like that's impressive. [03:38]

I've been laid off and fired a lot and I appreciate a company that is willing to get let its people stick around. Yeah. They're currently our only sponsor, in part because so few companies do as much as they do for the ecosystem. They host the largest React native podcast. They host the largest US-based React Native conference. Yeah, lots, tons of React native stuff. They very meaningful ecosystem investment. [04:04]

They only do React native and have built over 75 apps for companies from startups to the biggest in the world. And they will work with your team in order to help you develop expertise, not just get code running and dip out. [04:16]

So, yeah. if your company is looking to start a new React native project, definitely check them out. They are at Infinite Red, [04:24]

New releases

Carl: into some new releases. [04:26]

TypeScript 5.8

Mark: last month we mentioned the TS 5.8 beta, and so now it's come out as final. The biggest thing here is probably the erasable syntax only flag, which ensures that you're only using TS types that can just be stripped away without having to go through with transation step useful for use with node, for example. [04:45]

Carl: Yep, super great. I'm already using something like that in code that I run. It's just nice. I don't know it's nice to not do like a full compilation step. It just lets me cut an entire thing an an entire build tool out of my, outta my local development, which I like. [05:00]

Typescript Release with Go

Mark: Although on that note, and we'll talk about this more later the TS team has announced that they have finally rewritten the TypeScript compiler itself in another language go instead of TypeScript still in an early preview stage, but they're seeing 10 x speed up and compilation time. And so the trend of converting JS build tools into other languages continues, and we'll, we'll talk about this more in depth later. [05:26]

Carl: Probably, we'll talk about it later and we'll then probably continue talking about it later and later and later, because they have said that this is really gonna ship in like TypeScript seven, which by current release cadence [05:40]

Mark: Is like two years from now. [05:42]

Carl: Yeah. [05:42]

two and a half, three years. So yeah, we, this is gonna be a topic for a very long time. [05:47]

But yeah, they are continuing the trend of rewriting build tools in native and they are disrupting the trend of rewriting JavaScript build tools. rest. Yep. [05:55]

But yeah apparently they chose Go not Rust because the like general ethos, you know, the, the way you write code in Go is more similar than Rust. So they can do like more similar patterns in the code they're offering. So it's more of a one-to-one rewrite rather than like different enough code that it would have different semantics and different, you know, challenges there. [06:19]

Mark: And we have a mo. [06:20]

Carl: Ammo welcome. That's okay. We're gonna throw you immediately into the hot seat with React Native 78. [06:26]

React Native 0.78 - React 19 and more

Mo: So React native 78 is out. Bunch of small things, but we're getting smaller releases and so this one is mainly focusing on React 19 support. So you can get all the React 19 features that you know and love on the web now working on Native World. And we finally get our logs back in Metro. [06:44]

Next 15.2

Carl: Cool. Yeah, There's next. 15.2, which, you know, we're gonna talk a lot about next and more later. But um, this looks like not too crazy. A release they redesigned error ui, more streaming metadata, performance improvements, yada yada. Some experimental features as well. [07:02]

And ooh, experimental node js middleware. A lot more on middleware later. [07:07]

Tanstack Form 1.0

Mark: Tan Stack Form is a brand new form library in the vein of libraries like formic and React Hook form. This one I, I believe, was started by Tanner Winsley himself. The current maintainer is Corbin Crutchley who'd worked on a previous library, I think, called House Form, I believe. But like some of the big selling points are things like type safety, you know, being able to infer that, you know, like when you pass in the name of a field as an argument that all the other callbacks and everything else know exactly what the, you know, the proper value type for that field is. [07:41]

Lotted, different validation options a lot. And working with SSR and other scenarios haven't used it, but it looks fairly comprehensive and worth taking a look at as a, you know, form solution for your apps. [07:54]

Zeego v3

Mo: Yeah, so Zeego is a library that I quite appreciate. So it's made by Fernando Roho, who very recently actually joined Vercel as their head of mobile, which is going to, which tells us a lot about the direction that Vercel is going in terms of some of their mobile offerings. But Zeego released a new sort of major release. [08:13]

And so the, the big points with this is and just just for a little bit of context, we have talked about Zeego before in the podcast, but just for anyone who might have missed it, Zeego is a library that allows you to create context menus that are native to each platform and it's universal. So what that means is that it will let you create context menus on the web and it defers that to something like rad. [08:34]

Then on native platforms like iOS and Android, you actually get the native context menus that you get on the platform. So those are native elements that are rendered. And it's, it's a really good example of using the same API but getting very different looks and feels that are native to each platform. [08:49]

So it's, it's, it's a, it's a cool library. It's a very nice like utility library that you might need to use when you wanna get some native functionality inside of your mobile app. But the major things with this is just supporting the new architecture and React native and working with some of the new versions of Expo. [09:04]

Material UI v7

"Slot pattern" for overriding internals

Carl: Yeah. Material UI has version seven out. Main thing that caught my eye here is they have a slot pattern for overriding the internals of their different, you know, components. Customizing component library components is like the number one reason why I have not extensively used component libraries in my career. [09:25]

I just, like every company I've worked for, they have wanted a greater level of customization than is achievable just by doing things with the component library. I've been very interested in Chad CN for that reason, because it's just like, it's a co generator, not a library. [09:40]

You use it to make components and then you customize those components to your needs. But this looks like a really interesting alternative pattern for it. Basically, it looks like they have a pair of props slots and slot props where a component will specify different slots that you can override. [09:59]

So you can give it different components to put into places where, you know, like in, in a tab or a dropdown or whatever. That's really interesting. That seems good. Generally, it's nice that they are like trying to standardize it a little bit and like have a specification. I appreciate that and it's, yeah. [10:20]

I've seen a lot of libraries do things like add in. Sort of slots. They don't call it that, but like they let you pass in a component that it will use in place of something else or whatever. But I've always seen that as very like ad hoc and like there's no standardization or structure around it. [10:37]

So seeing this as a pattern is interesting to me. It's definitely, definitely interesting. Yeah. That's all I gotta say. [10:45]

Parcel v2.14

Mark: The Parcel Bundler released version two point 14, and this is kind of a big deal because it actually adds built-in React server component support. I was actually just looking at the download stats. So parcel has been around for several years. The primary author, Devin Govet, also works on React Aria and React Spectrum and a couple other component libraries. [11:05]

He's put a ton of effort into building it, but it's, it's very much an also ran in terms of actual usage. Like last month, Webpac had 116 million downloads. V had 85 million downloads. Parcel only had 800,000, so non-zero, but obviously not like, you know, anywhere near the level of the other tools. [11:25]

That said it is a, an actual tool in the space and so it is interesting to see what's more of a bundler rather than a framework. Adding React server component support and looking at the examples the usage pattern here looks to be a whole lot simpler than what Next has and, and has put together, you know, next is the, the defacto standard implementation of React Server components at this point. [11:52]

And so I think a lot of us have tended to assume that the way server components work in NEXT is the way that they work, whereas it, it's really more like React exposes the primitives and it's up to the framework or bundler to decide how they get used. So in this case, apparently parcel actually supports using server components, like just within a, like a, like a basic express request handler, which actually looks a lot simpler conceptually. [12:20]

So parcel may not have a lot of actual real world usage, but this looks like a, a, a nice example of what can be done with server component support. [12:32]

Carl: That's cool. Oh, nice. [12:33]

XState Store v3

Mark: Meanwhile, the, the X State and people, AKA, mostly David Khourshid has released X State Store. Version three. X State Store is meant to be a, a much wider weight state management tool. Kind of more along the lines of a, of a zoo stand, but with a little bit more of a, a state machine twist on it. So there, there's some updates to make the usage and the developer experience a little nicer. [13:00]

Carl: Yeah. Love X State. I don't know, I've just always had an affinity for it. They had a, they've always had a great state machine design tool and I found that useful even while not using the library. So I dunno, I just like them. [13:11]

Better Auth v1.2

Carl: There's Better Auth version 1.2, which is interesting and cool. I have been following Better Off for a while. I haven't actually used it myself yet. But they've been, [13:21]

Mark: Theme of this podcast? [13:23]

Carl: yeah, a little bit. There's just so many things. It's hard to stay, it's hard to, staying on top of it is hard to know. Actually using all of it as well is uh, impossible. [13:31]

Yeah, I, I, I like the general vibe of it. [13:34]

I have been let down by literally every auth tool that I've ever used. I have written my own auth far too many times because I'm so irritated with trying to use all of the authentications libraries. And yeah, this seems good. I'm just gonna read what bytes.dev said, 'cause they summed it up very well. [13:51]

"It's got Stripe subscriptions, recapture API, keys teams and sub orgs and a new init CLI, and they rewrote the core library to fix TypeScript editor lags. So like, it just seems really good. They've really been on a tear with shipping improvements. Like I, I subscribed to GitHub notifications for them and I slightly regret it because I swear to God I got like five a week with just like beta releases and new minor releases. [14:18]

So it's, it's, I'm impressed at their pace of development. They seem to be doing a really good job of shipping pretty major upgrades as they go. So, if you're doing a greenfield project that needs authentication, consider it. [14:31]

Main Content

Carl: Mo can you tell us about Lynx? [14:33]

Lynx released

Release blog

Mo: SO this is, this is not specifically React native related, but it's React native adjacent and definitely react related. So, you may have heard that bite Dance, the team behind TikTok released links, and links is effectively sort of a competitor to React Native. They've created another way that to build native applications using JavaScript tooling and using React as the way that you define UIs, which is really cool. [15:01]

And so, the, the real sort of reason why why this is exciting is because this is actually what's powering TikTok behind the scenes. So this is what they're using internally for TikTok. And you know, TikTok is as large scale of an application as comes. And so it's actually quite a. Quite a big deal to have something like this release and it brings healthy competition to the space of sort of cross-platform native applications where it's been traditionally just rack native and flutter. [15:27]

So I think there's some really interesting stuff here. The TLDR is that they have a sort of multi-threaded a multi-threaded architecture in place. And that's one of the things that they really, really empathize, em, emphasize on. And so the whole idea is that this architecture and this multi-threaded runtime allows you to take priority on sort of synchronous UI tasks that are high priority so that the app feels snappy and responsive. [15:52]

And things like event handlings are done sort of with a high priority. This is getting quite similar to the space of sort of what the React native team is trying to achieve with the new architecture, which was trying to. Targets similar benefits. And so they, they give a lot of examples on things like instant first frame rendering, which is one of the metrics that they're trying to target with this architecture to make sure that the first time you open up your app, you get as quick to instant as possible launches. [16:18]

And sort of multi-threaded scripts for when there's a you know, important scrolling event or something that requires really good responsiveness. Having those sort of concepts embedded into the architecture, which is really, really quite cool. And one of the nice things about this is that their JavaScript layer functionality is not actually react specific. [16:36]

So in theory, down the line, albeit React is really the only main way that you can define UIs right now down the line, they may create other versions of it. So currently there's links, which is the core, and then there's React links as well, which is the sort of the React library that you can use to define UIs for links currently. [16:54]

There could be in the future initiatives where it can allow you to use other UI libraries to do this, which can be really quite cool. [16:59]

Mark: I think I saw even at least a mention or like someone at least asking like, when can you use Vue with this? And it sounded like that was a thing that they were trying to work on. [17:07]

Carl: Interesting. [17:08]

Mo: but you know, that in itself is quite powerful because, you know, one of the, you know, there is nothing like rack native or there wasn't anything like rack native where you could use web-based UI libraries to define a mobile app. And so this actually opens up the door for people to use view to make actual native apps rather than sort of PWAs or hybrid web view based apps that are not gonna be good experiences. [17:31]

So, quite exciting stuff. [17:33]

Carl: That is really interesting. And it, it's, it's funny that I feel like over the last year we've talked about a couple of projects that we're exploring different ways of authoring react and getting some form of mobile app out of it. And I'm surprised that there's still like new approaches. This, we've seen so many with like, I don't know, react native web and I'm forgetting the names of all of them, but I swear to God [17:55]

Four of React strict dom. [17:56]

Yep. So, okay. Interesting. That sounds really cool. And I like that there's a way, I don't know, just like it, I love the web. I secretly wish that Web os from like 2012 had been a viable option. So it's just, I'm, I'm, I love seeing the web expand more meaningfully into the native arena. That's really cool. [18:17]

Cool. Alright. Into the headline. [18:20]

Security vulneratibility in Next.js: CVE-2025-29927[18:20] Original researcher report

Mark: All right. The biggest news story of the month occurred just a few days ago, and that was that there was a major security vulnerability with next's middleware implementation that ultimately allowed any external attacker to send a fairly simple set of headers and force next to skip the middleware. [18:46]

And if you, your app used the middleware to provide authentication to. You could actually just bypass the entire authentication process. So the assumption here is if you're using next to do middleware, and then there's some other caveats around where your app's actually hosted. But ultimately this was rated as an extremely high concern security vulnerability. [19:11]

So Next has released actual, actual fixes across a couple different major versions to try to patch up the issue. There's been. You know, breakdowns of, you know, what the actual bug is and why this is a concern and how it works. And then there's been a lot of fallout from this issue in terms of how did Vercel handle communicating the vulnerability to the general public as well as other partners. [19:38]

And follow on questions like, you know, how does Vercel and next actually kind of handle their development processes? associated pieces to go through with this. So let's, let's try and break some of this stuff down. [19:49]

Carl: Let's see what we can do. Yeah. So you, you mentioned how many versions that they shipped. So they, in, in their, you know, blog post, it's very. I don't know, no details, no extra explaining what happened. They explaining the advisory, I guess they, they then put out a, like timeline of the thing and gave a lot more details. [20:09]

But so they released patches for version 12, 13, 14, and 15, which means that this has been a vulnerability since at least 2021, which is wild [20:19]

Mark: It sounds sounds like Al, almost exactly, almost since like the, the middleware feature probably came into existence. [20:26]

Carl: Which I guess that makes sense. Like you add a new feature and it has vulnerabilities and until somebody notices it, you don't fix it. But wow, four years for an auth bypass based on a header. [20:36]

CVEs and the NVD Process

Carl: So I want to lead in a little bit breaking down like the CVE process, which I am not sure. I feel like everyone, I feel like a lot of people will have a general, I. [20:47]

Awareness of what, of what A CVE is. I didn't quite realize that it was like an NIST national Institute of Standards and Technology Program. Like this is a government program established in 1999 to track, [21:02]

Mark: known security bugs. [21:04]

Carl: Right. So like, yeah, and it has a, there's a calculator that lets you figure out the severity of a vulnerability. [21:12]

And it has criteria like the attack vector, the attack complexity, the requirements of the attack privileges required, user interaction are required, and then the impact of the vulnerability. It's confidentiality, integrity, availability. It's basically like how do you do the attack and if you execute the attack, what are the impact, what are the effects of it? [21:35]

So this. You know, the scoring criteria for this vulnerability is it's a network attack vector, which means you don't need to be physically present which is bad if you can do it over the network that's like a high level of access. The attack complexity is low, the privileges required are none. [21:54]

The user interaction required is none. And the impacts confidentiality are high, integrity is high but no impact on availability. So you can, you know, get into confidential spaces and, you know, violate the integrity of the data. [22:09]

You so it, it's, it's basically an attack you can do from anywhere in the world that's very simple. That gets you a high level of access, which is why this is a, you know, critical severity bug. That's so bad. Oh my God. Just for a, a bug of that severity to exist for four years before anyone noticed is oof rough. [22:30]

Mark: The general concept here is that, you know, middleware can be chained together. But there's, there's internal implementation details around like possibly needing to rerun middleware or possibly needing to skip middleware. [22:43]

And so at some point Versel opted to implement skipping, running middleware by looking for a specific header that they could attach to the request. And the intent was that this would only be an internal thing, that the header would only ever get added by next itself in response to, some piece of code saying, Hey, we're, we're good. [23:09]

We can just keep going. Or I guess maybe to, to, to get rid of loops in the middleware chain. And someone figured out that. You know, wait a minute, I could, I could attach this kind of a header as part of an external request. And the piece of information that next was looking for the, in the header is just a name of the middleware itself, which is pretty much always based on the file you would've added in your next project, which is apparently in some cases like just the literal word middleware. [23:44]

And so you could end up like having a header value of middleware, colon, middleware, colon, middleware, colon or something like that. the end result is that someone could send a request to a next base server, add this header to their original external request, and end up convincing next, skip all the middleware and never run them. [24:07]

And. And so if some of the were trained to do authentication, then the request would end up just skipping that entire process. I believe Vercel said that the way they have their systems architecture set up it was not really possible to have that be a problem on if your app was hosted on Vercel infrastructure. But then there was questions of, okay, well what if you're running on Netlify or CloudFlare or using one of the Open Next adapters? So the bug exists in next, and then there's the question of, well, how is next being hosted and what requests could actually get through? [24:46]

Carl: Right, so. I think what I saw is that they're saying if you hosted on Vercel, you were never vulnerable to this because of how we set up our system, which is great. I guess this. Certainly fuel on the fire of like Vercel is privileging itself in the ecosystem. [25:03]

Postmortem on Next.js Middleware bypass

Carl: And I guess building on that a bit, so they put out, you know, their postmortem breaking it down and breaking down the response. [25:11]

Mark: Which, which came out about like, like two to three days after the actual announcements. [25:16]

Carl: Right. And it looks like, you know, in the timeline they talk about like receiving emails and like multiple reports, which delayed the triaging. But like, you know, the core of the timeline, I. [25:27]

Mark: A month or something. [25:28]

Carl: it looks like somebody reported this at the end of February on the 27th, and then it didn't get triaged until two weeks later, which seems not good. [25:38]

I don't know. I, I, I have done triaging of security vulnerabilities. I was the point person for that at my last job for like two years, a year and a half, something like that. And there's a lot of noise. There's a lot of garbage that comes in. There's a lot of, you know, quote unquote security researchers who are just like running automated tools like nmp. [25:58]

You know, it's like, you know, you are an NPM audit and it's like 63 critical violations and like, none of them actually matter at all. So like, there is a lot of noise and I can understand how triaging might get delayed, but you know, like even just reading the headline, you know, if somebody submits like authorization bypass, like that would wake me up. [26:17]

So, I don't know, just waiting for two week lag time on that is not ideal. [26:22]

Mark: One, I mean, one, one bit of that is, it sounds like the initial submission just said, this looks like it's a problem in next, in, next next 12, which was out of date. And so like it sounded like someone may have glanced at it and said, oh, we don't even support next 12 anymore. It's not a big deal. [26:38]

And then the researcher came back and said, actually, it's a problem in like every version of next. And that finally got someone to wake up. [26:46]

Carl: for sure right? So, like, okay. Devil's in the details on this as always, but yeah, it's not a great situation. And what's more is that, it sounds like they did no coordinated disclosure. [27:00]

Next.js and Coordinated Disclosure

Carl: This person talks about some other CVE environments or disclosures that they've either, you know, been a part of seen and for instance, you know, like heart bleed, some of those other like large scale mass impact vulnerabilities, like this is not obviously of that scale, but it is large. [27:21]

So the, the, those ones like heart bleed, they had like multiple months of coordinated disclosure where behind the scenes in secret. You know, once these vulnerabilities are known, the companies are coordinating with each other to say like, are you vulnerable? Yes. Here's how we fix that. Are you? Yes. Okay, let's fix that too. [27:40]

And. What they're claiming is that Net or Vercel did nothing like that. They received a report, they validated it, they pushed their own fixes, and then they went public with it and basically caught other platforms like Netlify, cloud Flare, et cetera, with their pants down. And it was just like, oh shit. [28:02]

You what? What? We're vulnerable. And so now everyone's scrambling. And it's been publicly, it is, it's been publicized. So like now many websites are vulnerable, it's public knowledge and the a patch isn't ready. So like, that's, that's just not nice. it's not collaborative at all for sure. [28:22]

So it, it just means that like, it became a race to fix this before it got exploited in the wild. That's definitely not ideal that like that's, I guess I can understand how a company might say like, this is a problem with our product. We are fixing it. We have fixed it. It is time to go public. I guess I can understand that thought process, but man, as far as like being a participant in a broader ecosystem, that's a big blind spot. [28:49]

Mark: yeah. The, that, that link about coordinated disclosure is really good. It, it breaks down what did happen at what times, and then talks about like what are, what are the proper practices for handling a security disclosure? What did, like, what actually happened instead? How did this, like, how did other people end up finding out about it? [29:09]

And then like, what, what would have been a proper sequence of results? Instead, I. So like ultimately, you know, things have sort of been handled here, but really, really badly along the way. [29:24]

Carl: Yeah, and I guess one more detail that I'll highlight as part of like, this response was not handled well and maybe went through the wrong channels, the wrong internal channels. when they announced the vulnerability, I. One of their claims as part of it, which is accurate as best I can tell, is that you as our customers of Vercel, were not vulnerable because you were protected by our firewall. [29:47]

So it's like, it feels like it went through the marketing department rather than like, I don't know, engineering, security, whatever, where they were making an honest claim about a differentiating factor. But like part of the differentiating is that they were not collaborating with anyone else to help protect end users. [30:08]

So it's like, yeah, sure that's true, but it's also kind of mean that you did that. So, I don't know. It's not ideal. Not great. [30:17]

You should know this before choosing Next.js

Mark: And then one other good blog post related to this somebody who works at Netlify and has spent a lot of their engineering time trained to reverse engineer some of the somewhat more proprietary features of Next to make sure that they work on Netlify. Wrote a very long blog post that. Digs into both, you know, some of the, some of the vulnerability aspects, but then also just general concerns about the way next is developed and deployed and, you know, does not necessarily work with the ecosystem as well as it ought to. [30:54]

Describing a lot, a lot of the concerns, you know, that there, that there aren't, official adapters to run on other platforms that it doesn't have serverless support, that there's certain code paths that really only work on versal. And then also kind of talking about, you know, some of the security aspects. [31:11]

It's not like, it's not a, it's not a flat out indictment, but it's a, it's a very fairly written post from, you know, someone who acknowledges, you know, the own biases upfront, but like, it's a, it's a very valid set of concerns from someone who deals with next, from an external ecosystem perspective. [31:29]

Carl: Sure. [31:30]

Yeah. Not a great situation overall, but it's out, it's fixed. That's good. Onto the next [31:35]

um, okay. [31:37]

React Native 0.78 - React 19 and more

Mo: We are back with another release of React Native. And so this one is is focused again, we're, we're going through faster releases now. So you might've noticed if you've been staying tuned for a little while that our release cadence within the React native ecosystem is becoming shorter and shorter, which is great news because it means we get updates quicker. [31:58]

And that's largely due to the new architecture being out now. And so that allows us to basically the, the core of React native is a lot more stable. And so there is there's, there's more of a foundation to release a lot faster, which is great. Other highlights for this release is React 19 is now available on React Native, which is great. [32:17]

So if you, you know, followed along with the previous React 18 implementation for React Native, you will have been aware that it took years to get it up to date with all of the React 18 features, largely because of the new architecture not being out fully. And so now you can see there's much of a smaller lead time to get React 19 support. [32:38]

So all of the new sort of features of React, things like actions use, optimistic, the use hook, all of that stuff, and, you know, not needing to use forward ref anymore. All of that stuff is there now. On top of that the React compiler support is is now there. So you can actually install the compiler, configure it, and it should be able to work just as you would on the web, which is awesome. [32:59]

The, probably the most, important feature for the community though is that they've brought back JavaScript logs in your metro bundler. So this was one of the things that the react native team did last release was they removed logs being shown in your JavaScript bundler. So they were trying to push people to use the react dev tools that they released, or the new dev tools that they released for the React native ecosystem only to face the most crazy amount of backlash from the community because their logs had moved. [33:27]

And people were very unhappy about that. So, they rolled back that. you can pass on a flag now and basically get the logs showing in your bundler once again, like it was for the last. However many years React native has been out for. And so they have said that they will eventually remove this again. [33:43]

But they're trying to give a little bit more time for people to adjust to using the new dev tools. So we'll see how that goes when that happens. Once again, there's some other minor changes, but those are really the big things that's worth mentioning. And I think we're gonna get a lot more React native releases happening a lot more regularly since the new architecture is up. [34:00]

Mark: Sounds like a pretty substantial set of changes. [34:02]

Carl: And it's cool that they are able to release more quickly, to keep better aligned with the, you know, main mainline react version. I hadn't really registered that as a benefit that would come out of the new architecture, but it makes sense, especially while they are effectively maintaining two versions, you know, new architecture, old architecture, suddenly only have to do the new architecture. [34:25]

That makes a lot of sense. That's super cool. [34:27]

React Native Core Contributor Summit 2024 Recap

Mo: So the, the next thing that I, I thought I'd just drop in here. it was technically published in February, but I think we missed it and I, I wasn't around in February is the React Native Core contributor Summit for 2024. The recap was finally released. So this is an article on the rec native dev blog. [34:43]

I actually co-authored this. So last year in SLA in in Poland, I think it was around September we had the React Native Core Contributor Summit, which is a, a full day workshop. Talking about a bunch of different. Things that are strategic to React native in general. And one of the things we talked about was the release process. [35:02]

We talked about, you know, what's the next big thing after the new architecture. So there was a bunch of different sessions and we split off. There was a session about how do we bring web APIs into, into to, to the React native world to standardize some of the APIs for interacting with the native layer. [35:15]

So a lot of really interesting stuff. We talked about Nitro modules, which is sort of, we've talked about several times in the last few sort of podcast episodes outta tree platforms and react native on desktop. I held a session as well, so I led a session during this during this core contributor summit lean Core 2.0. [35:31]

So just for a bit of context lean core, was an initiative in the React native ecosystem back in 2019. And so the goal of Lean Core was to bring down the surface area of React Native's, core APIs because there was just so much stuff in there. Like somebody needed access to something in IOS's specific APIs and they just create a component and pop it into React Native Core and that would just be a part of maintenance burden for the core React native team. [35:56]

So there wasn't much strategic direction around what goes into core and what goes into sort of community packages. And so they went through this effort in 2019. But the goal of the session this time around was actually, I think we we're due for another cleanup. 'cause there's a lot of random stuff there that is either props in certain core components that are tying specifically to Android or iOS, or there's just some components that don't get used anymore because there's much better components in community libraries that you can use. [36:23]

And most people end up using those. So it was a good conversation around what should be deprecated in the long run. And so that's one of the sessions that I think was quite fruitful. And I say that probably being quite biased because I was the person who hosted the session. But yeah, that's a, that's a summary about the uh, the React Native core contributor Summit from last year. [36:39]

If you're interested please feel free to go and, and read the article. [36:42]

TypeScript compiler Golang rewrite??

Mark: Alright, so the other really big piece in and piece of news for not just the React ecosystem, but the web development ecosystem as a whole is the, the TypeScript team has officially announced that they have created a fort, not a rewrite of the TypeScript compiler, the current version of TypeScript itself is written in TypeScript, which means it's actually, you know, in the end it's the, it's just JavaScript executing and they have ported the compiler itself to be written in. [37:14]

Go. And what they say in the announcement is that they're seeing like generally 10 x speedups in the actual TypeScript compilation stage of processing people's programs. I saw at least one post on Reddit where someone was complaining that people are gonna be confused. That this means that they think that this means their code runs faster. [37:34]

It's like, no, this is just compiling the TypeScript types 10 times as fast. And this is a really big deal. this trend over the last five, six years of all these different JavaScript ecosystem build tools being rewritten in native languages, mostly rust, and getting a lot of speed ups that way. [37:53]

So, you know, es e es build as in go you know, RS pack and roll down are both written in rust, et cetera. I mean, a lot of tools being rewritten in native languages to try to speed things up, but a lot of them have still, like the actual build pipelines still get bottlenecked on TypeScript compilation time because it doesn't matter how, how fast you can process all these different, you know, individual module files and bundle them together if you're still doing a full type script type check during that section of the build phase. [38:29]

And so there's been a bunch of attempts to rewrite the TypeScript compiler. I. Into native languages from random people in the ecosystem. The author of SWC had tried to do a couple different attempts at porting. One in rust, one in go. I saw somebody who had done one with trying to, trying to create some kinda like a stack based virtual machine to process the types, and he'd gotten like a baby example working that seemed way faster, but it was only for, it only worked for very, very simple types. [39:01]

So, I mean, there, there's been attempts from individuals, but none of these got anywhere past, like a modest proof of concept stage, like they proved they could work, but then it's a massive amount of effort just to catch up with where the TypeScript compiler is much less keep up with where it's going on a month to month basis. [39:21]

And so, you know, a lot of people had said that, well, it feels like the only way this would actually happen is if the TypeScript team themselves actually decides to do it. Well, it turns out the TypeScript team decided to do it about a year ago, and they've been working on this in secret, and now they've gotten this far and proven it works and are actually intending to push this forward to become, you know, the actual TypeScript compiler down the road. [39:49]

as Carl mentioned, so right now we're on TypeScript 5.8. They put out quarterly ish releases, I think. So basically four, four releases a year. They also follow a kind of a, a, a decimal based versioning system where it's not really SemVer, but they just roll over from 5.8, 5.9, 6.0, 6.1. So they've said that the plan is that the new native go compiler will probably officially become TypeScript 7.0. So that means we probably have about two to three years before that actually happens officially. [40:26]

Carl: But they may also just release it like when it's ready. I, I don't believe that the version seven is a firm commitment. So it, maybe, it will, maybe validating it, maybe making sure that it won't break. Everything will happen faster than they expect, and it may be [40:42]

Mark: I mean, they, they, they might like, they, they might end up going from like a six four to a 7.0 instead of having to get through 6, 4, 5, 6, 7, 8, 9. [40:52]

Carl: Okay. I don't know. I thought they just did straight up incremental and when they got to nine they incremented, [40:57]

Mark: right, right, Like, so my, my point is that if it's ready in say one year from now, we would be at TypeScript 6.2, and rather than officially waiting another two years and eight more releases to get to 7.0, they might just say, okay, yeah, this is the end of the line for the old compiler here. [41:15]

Carl: yeah. Hard to say. Who knows? I do wanna, I wanna highlight a couple of, you know, comments from the people who worked on this. [41:23]

Github discussion and on reddit too

Carl: Ryan Cavanaugh put out a great Reddit comment describing why they chose go, basically. And, you know, we kind of talked about it a little bit, but I, I wanted to enter his words into the cannon a little bit here. [41:36]

Mark: I was shocked at how much pushback there was, especially from the C sharp folks. Oh my word. The C sharp community was up in arms about why the Microsoft engineers did not pick C Sharp as the language for the new compiler, [41:51]

Carl: Yeah, sure. I, the amount of space in my brain that C sharp developers occupy rounds to zero. So anytime they come on, I am a little surprised. But yeah. So like, I wanna, I wanna try and pull out a good quote here. So, like, really their primary goal here was portability. They don't wanna rewrite anything. [42:09]

They would like to adapt it into a new faster language. So they really say portability was always a key constraint here. As we thought about how to do this, we tried tons of approaches to get a representation that it would've made the port approach tractable and rust. But all of them either had unacceptable trade-offs or devolved into write your own garbage collector style strategies. [42:28]

So right, like they, it looks like they really genuinely validated trying to use multiple languages here at least between Rust and go. And they say, [42:38]

Mark: I think I saw mention they also tried in c as well, okay, in this post, but elsewhere. [42:42]

Carl: yeah, sure. That makes sense. I saw a quote that I liked. " In our opinion, rust succeeds wildly at its design goals, but quote is straightforward to port to rust from this particular JavaScript. Code base is very rationally not one of its design goals. It's not one of goes either, but in our case, given the way we've written the code so far, it does turn out to be pretty good at it." [43:01]

So like basically they chose to write code in a style that happens to align thematically with Go. And so when they chose to port it, it ended up working out pretty well. [43:11]

Mark: one of the key points here is that like anyone who's actually worked with a lot of TypeScript types or has dared to peek inside the TypeScript compiler, I. Is aware that there, there are a lot of very complex and very subtle behaviors of TypeScript and you know, one of the complaints about TypeScript for years is that there is no official spec for the language itself and how everything should work. [43:36]

It's pretty much just, well, the spec is what the compiler does for this release and that's it. So in other words, the, the spec is the tests that they have. It's not an official language design document. because of that, if you try to rewrite the compiler in another language and you kind of start from scratch, you run the risk of ha of like trying to do things the same way. [44:05]

But the code ends up being kind of different. I. Then you end up getting literally different output from the rewrite of the compiler, which would be really bad for the entire ecosystem that is depending on the compiler to return consistent type results. And so one of their conclusions was go allows us to make an almost literal one for one line for wine port of the exact data structures and the exact logic that we already have written in TypeScript. [44:36]

And so that guarantees that we should get exactly the same calculation results from the new compiler just faster. Faster. So that was a really, really big consideration here. [44:49]

Carl: Definitely makes a lot of sense. [44:50]

⚡ Lightning round ⚡

Carl: Cool. Okay. Onto the lightning round. [44:52]

JSC being extracted from RN Core

Mo: first one JSC is being extracted from React Native Core. So, several years ago there was a custom JavaScript engine that was introduced into React Native called Hermes. [45:01]

That's what everyone has been using for the last several years, or most people have been using for the last several years. There are some people who still use JSC for very specific niche use cases. And so it was inside of the reactive core package up until recently when it's been extracted out. [45:16]

So if you want to use JSC instead of Hermes, it is now an external package and you're gonna need to install it separately. [45:22]

node-modules.dev v0.4.0

Carl: This is very small, but seems neat. I'm just going to call it out. Anthony Fu put out a node modules dev, which just seems kind of cool. It's like a way of analyzing the dependency tree for a specific node module. It seems cool. I have had to do various ways of visualizing dependency trees a number of times throughout my career, and it's always been a pain in the butt. [45:47]

So just seeing a tool that's online, on the internet where you can just like plug it in and analyze it visually is very cool and interesting to me. Seems good. I like it. [46:00]

Fernando Rojo joining Vercel as Head of Mobile

Mo: next up on the lightning round is that, as we mentioned a little bit earlier on in the episode, a little bit of a, of a spoiler. Fernando Roho has joined Vercel as the head of mobile. [46:10]

And so this is a very interesting development because Vercel traditionally was very web focused. Expo was traditionally mobile focused. So those were the two frameworks. And it seems like they're starting to bleed into each other's territory, which is gonna get really, really interesting. So that is that's gonna be quite an interesting one to see because maybe Vercel is working on a framework for React Native. [46:32]

And we know that the Expo folks have been working on sort of web-based support as well, so we will see on how this develops. But it's just an interesting signal from the Vercel folks. [46:41]

Next vs TanStack (Router + Vite)

Carl: Kyle Gill put out a next JS versus Tan Stack article, which he at the very start says, was inspired by a 2019 post from Jared Palmer contrasting Gatsby with next js. [46:55]

I highlight that because Jared Palmer currently works at Versal. Fun fact, I interviewed with him for a job in 2017. I did not get it. And 2019 when Jared Palmer wrote that Gatsby versus Next Post I feel like was about the turning point for Gatsby enthusiasm starting to die off. That's when mine started to die off for sure. [47:17]

So that, it's, it's interesting seeing that he is calling back to that moment, in this moment in a pretty different direction. So we'll see, you know, who, who knows if that same trend will continue, but it's, it's, it looks like a great comparison of functionality between Next and Tan Stack. And Tan Stack is certainly getting a lot of interest in mind share. [47:42]

So yeah, if you're thinking about it, definitely check that out 'cause it seems nice. [47:46]

Expo’s AI Strategy

Mo: Cool. Next up there's a blog post that the CTO of Expo did on their AI strategy. it's quite a short blog post so you can kind of skim through it. But really the point they're trying to make is that we're in an age that you can use AI to democratize building apps. And so they talk about how they're gonna take efforts to make sure that their docs and, you know, all of their material is well suitable for things like the model context protocol, the MCP that philanthropic released but also other sort of, protocols and interfaces that AI agents may use. And then they talk about how Expo is being used by tools like Repli by Bolt and other tools already to build apps from prompts so that, you know, non-technical people can sort of, as we say today, vibe code their apps. But I think they, they're really seeing this as a uh, as an opportunity to, to get people to build apps. [48:37]

The everyday person who's not a developer to be able to build apps. [48:39]

Laravel launched “starter kits” including React

Carl: Laravel just released starter kits this month including some for React. So that's interesting. They're doing, like, I, it looked like it included server-side rendering. I'm not sure if that is owned by Laravel or React but just interesting. [48:54]

I don't know. I, Laravel is maybe on my mind because I was seeing a number of months ago some conversation discussing what you get out of the box with tools like Laravel and the general lack of anything comparable in the React ecosystem. Specifically around auth. I saw people talking about what you need to, what you get for free with a tool like Laravel. [49:18]

And I was a little bit surprised because you do not get that for free. In my experience when you're building an app with React, so that just gave Bit, gave me a bit of a respect for the, the, the tool. So it seems neat. It's a new major version, version 12. It's got starter kits. One of the starter kits uses React. [49:34]

It claims server-side rendering support. [49:36]

React Native Enterprise Framework

Mo: So next up, call stack, the folks behind React Universe Conf and libraries like React Native Paper, have announced that they're creating a new React native framework that's specifically targeting enterprise. [49:49]

Now, this is very early days. They're trying to target some of the pain points that enterprise clients with large, large number of you know, devs and with restrictions on where they can host their infrastructure are facing. And so they want to try to target that niche of React native apps which is quite interesting. [50:07]

And so, this is still very much in sort of waiting list stage. So it's, it's early days. But their, that, their start focus is that you can have reusable cloud builds that run on anywhere. Potentially GitHub actions but potentially also other pipeline providers. And also a nice way to be able to integrate Brownfield into existing iOS and Android apps so that you have an incremental migration path. [50:30]

So, very early days, we'll see. We'll see where we, where we, where this kind of develops and, and, and where this goes. [50:36]

State of React Native 2024

Mo: And last on our list is the State of React native 2024. So this is a survey that the folks at Software Mansion do every single year and they touch on a whole bunch of stuff like dev backgrounds, demographics, what libraries people are using, and what you use for state management and all of that. [50:52]

And so, this year the main things that they're that they basically concluded, which is, is kind of no surprise whatsoever, is the um, expos becoming sort of the main way to build react native apps. And they see momentum with tools like Chrome, the, the, the Chrome dev tools, protocol based new React native dev tools that Meta's announced and tools like Expo Atlas. [51:14]

But take a look into it if you're interested in. Analyzing the trends in the React native ecosystem. [51:19]

Carl: Alright, thanks everyone. That's everything we got. We will be back on the last Wednesday of next month in April on the 30th. come join us on April 30th here in the live stage, or we will be back in your podcast feed just as soon as we can. [51:33]

Mo: Yeah, well, always a pleasure guys, and looking forward to jumping on in April to see you all there. [51:40]

Mark: Likewise. [51:41]

Carl: Cool, see you then. We gather sources from this week in React bys.dev, react status next JS weekly, the React JS subreddit here in reactive flux, and sometimes even directly from those publishing articles. If you see anything newsworthy, definitely let us know in the Tech reads, tech News and Reads channel here in reactive Flux. [52:00]

Or you can send me an email at hello@reactiflux.com. I read everything that comes in, even if it gets marked as spam, so don't worry. If this is a show that you get value from and would like to support, best way to do so is by telling people about it or by submitting a review on whatever platform that you listen to it.

Thanks for listening. See you next month. [52:16]

TMiR 2025-02: Updated new project docs

Reactiflux — Sun, 23 Feb 2025 16:00:00 GMT

[01:11] Job market: FRED data, Layoffs.fyi
- [02:35] Microsoft Performance-Based Job Cuts Have Started
[03:07] Conferences (React, Javascript)
- [03:10] React Paris March 20-21 Paris, France
- [03:14] React Native Connection April 3–4 Paris, France
- [03:19] React Miami, Apr 17-18 Miami, FL, USA
- [03:25] CityJS London April 23-25 London, UK
[03:53] Sponsored by Infinite Red
[04:48] New releases
- [04:50] React Router 7.2
- [05:11] TS 5.8
- [09:01] Prettier 3.5
- [09:12] RTK Query v2.6.0
- [10:04] Standard Schema
- [10:34] Astro 5.2 (also Astro 5.3)
- [11:35] Turborepo 2.4
[12:20] Main Content
- [12:23] Sunsetting Create React App
  - [16:59] Original “Sunsetting CRA” post vs Build a React app from Scratch
  - [25:26] Backlash and confusion over initial version
  - [26:52] Mark filed a PR to rewrite the docs, the React team closed that but based a new one off it
  - [38:09] Between the Wires: An interview with MooTools contributors
- [42:58] How to start a React Project [2025]
- [43:56] Jack Herrington published create-tsrouter-app under the Tanstack umbrella
[47:24] ⚡ Lightning round ⚡

Carl: All right. Hello, everyone. Thank you for joining us for the February edition of This Month in React, where we recap And digest the recent developments in the ever evolving React and web ecosystem. Coming to you live from Reactiflux, the place for professional React developers, and supported by Infinite Red. [00:00]

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

Mark: And I'm Mark. My day job is working at Replay. Io. We're building a time traveling debugger for JavaScript and figuring out how to integrate that with AI DevTools. And in my copious amounts of spare time, I both work on Redux and spend entirely too much time complaining about the React ecosystem. [00:26]

Carl: And also now writing documentation and long, enormous blog posts. I actually printed out your blog post that I offered to help you edit, and it was 50 pages long. 50 sheets of paper. [00:42]

Mark: I apologize to the forests that suffered for that one. [00:53]

Carl: It's entirely your fault. [00:56]

Yeah, our third co host, Mo, is off this month. He is very busy with work and things, and just needed to take some time, not in the right space to have this conversation this month, so he'll be back next time. [00:58]

Job market: FRED data, Layoffs.fyi

Carl: Some quick hits. Job market. I was hoping around December, January, it was looking like, I don't know, new quarter, new year, new budgets. I was cautiously optimistic from seeing activity in the job board, yada yada. But sadly that has not borne out. [01:11]

Microsoft Performance-Based Job Cuts Have Started

Carl: I guess, you know, maybe some small companies were hiring, but like, Meta is doing performance based layoffs. Microsoft is doing performance based layoffs. And talking to someone about the job market and the ecosystem, and they shared something that made me think differently about layoffs that are happening right now. [01:29]

Like, when the company is signaling that it is performance based, That is a very different situation than when you just get laid off. Like, was pointed out to me that like, if you have on your resume that you worked at Meta and that you got laid off January 2025, that is no longer, like, the golden ticket. You know, like, for many, many years, if you worked at one of these big tech companies, that was, like, pretty much, not a free pass, but, like, it opened a lot of doors. But now a lot of people are getting let go when the public messaging is we're letting go of low performers. And that is a very different environment to lose your job in. [01:46]

So that's, yeah, I hadn't really thought about that, but yeah, how the company messages, how they're letting people go definitely can have a huge impact. And I saw a quote from a Bloomberg article about the Microsoft layoffs. [02:23]

Microsoft Performance-Based Job Cuts Have Started

Carl: " Employees losing their job will see health care benefits end immediately. In three specific cases, employees were told that they weren't getting severance." [02:35]

So like, not only is, are they publicly signaling that these are like performance based and therefore really doing harm to the like future employment prospects, like they're not, they're being pretty stingy about these severance deals. [02:43]

Losing your health insurance with no notice. It's pretty brutal, like, that's, that's just rough. Especially, like, yeah, hopefully they weren't getting any active treatments. Ugh, anyway, that's all I'll say on that. [02:56]

Conferences (React, Javascript)

Carl: some upcoming conferences in March and April, [03:07]

React Paris March 20-21 Paris, France

Carl: we've got React Paris. March 20th and 21st. [03:10]

React Native Connection April 3–4 Paris, France

Carl: We've got React Native Connection, April 3rd and 4th, also in Paris. [03:14]

React Miami, Apr 17-18 Miami, FL, USA

Carl: we've got React Miami, coming up in April 17th And 18th. [03:19]

CityJS London April 23-25 London, UK

Carl: there's also CityJS London, April 23rd to 25th in London. [03:25]

Mark: Then whole slew of things in late May and early June. Conference season kicking off. [03:30]

Carl: Yeah, definitely. I need to actually book things. I don't have anything, I'm going to render Atlanta in June, but I don't have anything booked before then. Yeah, going to Brazil for 12 days is really kind of complicated by Soaked up a lot of my logistical planning. [03:35]

, Um, yeah, our sponsor. We are sponsored. We have a sponsor. [03:49]

Sponsored by Infinite Red

Carl: Infinite Red is an expert React Native consultancy. It's been around since 2015. So basically the entire time that React Native has been around. They are our only sponsor in part because very few companies do as much as they do for the ecosystem. [03:53]

, and I just don't know Too many other companies that have done quite so much for quite so long. So very happy to be partnered with them in that way. They only do React Native and they've built over 75 apps for companies from startups to the biggest in the world. And other than being kind, great people who have done great things for the ecosystem, like hosting podcasts and organizing conferences, They are generally just a small team that focuses on like building for the long term. [04:07]

So if you are working at a company that's spinning up a new React Native project and needs to get build some expertise, definitely give them a call because they will actually not just build it, but they will work with you to help develop expertise and hit the ground running. Cool. [04:34]

New releases

Carl: onto some new releases. [04:48]

React Router 7.2

Carl: We've got React Router, putting out a minor release, 7.2. Looked pretty minor. The headline for me here is that they have a type safe HRF tool, which sounds pretty interesting if you can have type safety. That your links work like that's just neat. They have a new way of doing that how well it works remains to be seen, but it seems cool [04:50]

TS 5.8

Carl: We've also got TypeScript version 5. 8 with a bunch of stuff. Of course TypeScript new version [05:11]

Mark: thing that I'm interested in here is the new erasable syntax only flag. And for background on that, so TypeScript has always been described as, you know, a types only layer on top of JavaScript. But there are a few TypeScript features that actually do have some runtime code. Enums, I think a couple of the, a couple of the old legacy, um, syntax features as well. [05:18]

And so, there are a number of tools today which work to strip out TypeScript types. But if your code uses some of those features that do have some runtime code, they, they don't work right. And this actually matters a lot for things like Node's new TypeScript, Stripping support. [05:43]

And so, to try to work better with those tools, TS has added this erasable syntax flag, which I believe actually throws an error if you are using any of the syntax that has runtime output. So it's basically like a, an extra enforcement check to make sure that you're not using any of those features. And that way you can ensure that your code is compatible with just stripping the types as opposed to like a transpilation. That's actually a really big deal. [06:01]

Carl: Yeah, super helpful. And it's actually, that's like a reasonably large build time optimization if you can get away with it. Because if you're not actually analyzing the types while compiling the code, you're just doing the parsing and the output. Like that's a lot less work. And your, like, VS Code, our IDEs, our language servers are already surfacing most of those type errors. [06:29]

So, like, I think it's really neat to, for one, I have used this just Because it's less effort to stand up a new project. You know, if I can just lean on the language server, then that's just less code, fewer moving parts, fewer things to go wrong, fewer things to break when I pick the project back up in four months. [06:52]

but yeah, it's also like if you can move the actual type checking into like CI or something like that and just do it less frequently, that's, that can be a lot less work overall. Yeah, there was a relatively subtle thing, slightly smarter return types when generic arguments are used in conditional types. [07:08]

It's really specific and only a partial solution, but I've run into some problems like this. And the overall like pattern that they were showing off for this was like not super familiar with to me and looked useful. So like, I that caught my eye as like a kind of subtle but useful thing. [07:27]

They are adding support for using require to get ESM modules. Which is interesting, like this is, you know, a continuation of the long tail of complexity that the switch over to ES modules, standardized modules, is having. But like, cool, now we have one more way to run into fewer problems when In an ESM environment, but needing to depend on CommonJS code. [07:43]

it still does not allow you to require an ESM file that contains a top level await. [08:10]

Mark: Because require() is synchronous. [08:16]

Carl: yes, facts. Also added a new flag that just caught my eyes, like a nice, I don't know, LTS feature. They have a --module node18. So you can tell TypeScript what module, like parsing, what determines what modules to use, how it evaluates what modules are being imported? You can tell it to use specifically the behavior for node 18. [08:18]

I've done a lot of maintenance of legacy apps and weird edge cases like that, like, Oh, in the last five versions, they have changed in what order or in what manner modules are crawled. Stuff like that can cause so many weird, obnoxious, difficult to debug errors. [08:42]

Prettier 3.5

[09:01]

Carl: Cool, new version of Prettier. I saw they're adding an option, which they do not do very frequently, so that's cool. [09:01]

Mark: Looks like they're trying to let you configure how it formats collapsing objects. [09:07]

Carl: Useful. [09:12]

RTK Query v2.6.0

Mark: I am very pleased to announce that yesterday I shipped Redux Toolkit 2. 6, which now has infinite query support for RTKQuery. This has been our single most requested feature since RTK Query came out, and I started working on this back in October, after another user had submitted a draft PR to get a first proof of concept going. [09:12]

There was a lot of discussion, a lot of trying to figure out what the problem space is, and how to implement this properly. We ended up adopting the React Query public API design for this. And I had some discussions with Dominic Dorfmeister, the, you know, TK Dodo, the React Query Maintainer, who specifically gave us advice on why they ended up with this API design and how they implemented it. [09:34]

So, worked on this intermittently when I had time over the last few months and very happy to get this out the door. [09:58]

Standard Schema

Mark: There's also a, project or a standard, I guess, called Standard Schema, which is an attempt to, you know, sort of unify or find a common denominator between a bunch of the different TypeScript validation tools out there, like Zod and Valobot and Archetype. So apparently you can now say that your project needs Just the standard schema definitions, and then the end users can then swap in their preferred validation library where and where they want to. [10:04]

Astro 5.2 (also Astro 5.3)

Carl: there's also two Astro releases. There's 5. 2 and 5. 3. Looks like it's You know, relatively. Small iterative improvements. I was just reading a little bit more. Astro 5. 3 is talking about automatic session storage setup. And as someone who has opinions about off, And prefers, you know, session storage to jWTs for authentication, that caught my eye. [10:34]

I don't know a ton about this, but definitely anything that makes sessions a little bit easier to like wrangle and manage, is definitely nice. I've been, as an exercise, I've been building my own. Authentication from scratch in session storage with React Router v7. So that's just fresh on my mind. [10:59]

I would love to be able to tell you more about what the experience of using Astro is like, but I, I have tried and failed to start several projects because I just don't have time. I have too many different projects going on. But It always crosses my mind when I'm thinking about, like, a blog, or a static site, or things like that. Seems like a very good tool for those purposes. [11:18]

Turborepo 2.4

Carl: There's also TurboRepo 2. 4. TurboRepo is a great tool for managing monorepos. From the next team, and they've got a number of improvements to enhance your repository as they say Boundaries, watch mode caching, continuing the trend of Vercel dealing with caching issues and Versioned configuration validation from within your repository, interesting. And they've also got circular dependency recommendations for adopting Turbo repo in large repos more easily. That's interesting. I've run into so many circular dependency issues throughout my career that just very much catches my attention. Very neat. Cool. [11:35]

Mark: I spent time trying to squash those as well. [12:16]

Carl: Just the worst. So painful. [12:19]

Main Content

Carl: Cool. Into our main content. Mark, you wanna start us [12:20]

Sunsetting Create React App

Mark: All right, yes, yes, I, I have thoughts and opinions on this topic. So, in our last episode, as a Relatively brief recap. When React 19 came out, it broke Create React App because of a peer dependency version mismatch, where the old templates wanted React 18, but CRA tried to install React 19. So I spent a chunk of January griping about this and trying to say, this is broken and it needs to be fixed. [12:23]

That led to several heated discussions on Blue Sky with the React team about, and trying to convince them to fix it. And so, right before our last episode, I had filed an issue that recapped what was broken and why, and pointed to a couple of PRs that other people had filed to both fix the CRA templates and actually mark the Create React App repo and command line tool as deprecated, and the React team had actually taken action on that and merged the initial PRs And they hadn't actually put out a new release of Create React App that fixed the brokenness, but the changes were in there and they were trying to figure out the process for doing the releases. [12:53]

Along with that, though, I had specifically said that I felt the React Docs setup page ought to recommend Vite as, you know, the equivalent replacement tool. So that people being told, CRA is dead, don't use it, would have a direct equivalent tool to try to use. So that's where we left off a month ago. [13:38]

And the entire topic has continued significantly over the last few weeks. So, from my perspective, there were several additional debates going on, on, you know, BlueSky and Twitter and in the docs about, you know, what ought to be done as follow ups and, you know, what should be recommended as tools. [13:59]

And on my side, I had actually started writing a rather lengthy blog post that tried to cover a bunch of topics from how has React been developed over the years to erecting some community confusion, like. You know, the ongoing claims that Vercel is driving React development just to make money on servers, which is wrong. [14:20]

but also describing sort of my take on the history of interactions between the React team and the community and frustrations and miscommunications and docs problems and frameworks and all these different things. So I'd been working on that. In, you know, over the course of a couple of weeks and kind of like teasing my progress online. [14:42]

And I'd also been having discussion with some other maintainers and without having given specific details publicly, the React team actually reached out to folks like Tanner Linsley and myself and specifically said, we can, like, we can tell you're frustrated. We would like to hear your feedback directly. [15:04]

And so I know that, Joe from the React team had a call with Tanner Winsley, where Tanner expressed a lot of thoughts about, I think especially some of lack of new client functionality in React as well as where React was headed. And so, Joe and I had a call. In early February ish, where I summarized all my different concerns, and then there were a couple follow up calls, and, Carl and I actually were on one with, both Joe and Matt, where the React team talked about what they're trying to work on. [15:25]

In response to a lot of these discussions and feedback. One of the things they said was we're, we're preparing a blog post and some docs updates in response to CRA being dead. As well as even things like they've been talking about trying to have a new community working group for a while, but they've kind of gotten bogged down in what the logistics should be. [15:59]

So, based on that, I could see that the React team was very actively trying to listen to feedback and trying to take some actions in response. And so, I think it was later that week that the React team finished the draft of the blog post and the docs updates. They gave me a chance to review it and offer feedback and a bunch of other folks as well. [16:20]

And so they published that blog post and they, I did actually see that they had applied some of the feedback that I'd suggested. They did not apply all of the feedback that I suggested. [16:45]

Original “Sunsetting CRA” post vs Build a React app from Scratch

Mark: And this actually kind of got rather controversial again as I rather predicted that it would. They put up a blog post labeled Sunsetting Create React App, where they said, CRA is dead, here's all the things that it didn't include. [16:59]

There's better tools, but also we really, really, really, really, really think that people should be using frameworks that have routing and data fetching and everything else built in. And the first version of this blog post really, really emphasized the framework part. And they did make changes to the setup docs, but they also put up a new blog post that was called Building a React Framework. [17:14]

And so, you know, what, what everyone's been clamoring for is just recommend VEET in the setup page, please. And they didn't actually do that with this first update. They instead, what they said was, well, when you pick your own build tool and your own router. And your own data fetching library. What you're really doing is building your own framework badly. [17:39]

And I can understand the mindset behind that, but frankly, this was not a helpful approach for anyone actually reading the framework. If you are a learner or a beginner, or want to try to choose some other tools, what would be helpful is instructions that say, you can use one of these two or three build tools, you can use one of these couple routers, and one of these data fetching libraries, and at least giving people a valid direction to go with it. [18:07]

And instead, what we got was a pretty straightforward, page that said, if you don't want to use a framework, you can build your own framework. Step one, install Vite or Parcel. Step two, you're going to have to think about routing and data fetching and code splitting, and boy, these are complicated and you will never be able to do this by yourself. [18:35]

Don't do this, please! Use a framework instead. And that really was not helpful for the audience that was going to be reading it. And so I had tried to offer feedback saying I don't think this page is good before the post went up, and that was one of the things they did not listen to me on. [18:57]

Carl: Yeah, And it, it definitely feels like that the fe it seems like the feedback that you gave is in line with like community expectations. Just seeing the Reddit response to, you know, the comments on the Reddit post for this blog. I, you know, I saw like Rick Hanlin had replied to something and got down, voted to like, you know, minus 20, something like that. So, it does, just like for more data points coming, rolling in in real time around, the core team is out of step with expectations for the community. [19:16]

Mark: Yeah, so, you know, I, I understand what the React team is trying to accomplish, and in fact, actually, one of the, one of the most interesting data points that came out of those couple conversations with the team. So, they've said, since they started this frameworks emphasis that, Part of the goal is that, you know, they, they don't want people to start off with a single page app and then have to do like a major tool migration in order to add SSR functionality. [19:48]

What I didn't realize was a lot of their goal and mindset around this is actually around React app performance. And they are actually very sensitive and I've heard a lot of the criticism. From folks like Alex Russell that, you know, single page apps and the average React app are horribly performing tens of megabytes of JavaScript. [20:14]

Like, they're actually very, very sensitive to that criticism, and I don't think I'd realized how sensitive it was. Turns out that part of their reason for emphasizing frameworks Is, they feel that if most apps start with a framework by default, then on average, more React apps will have somewhat better loading performance, data fetching, code splitting performance, etc. [20:38]

That is actually one of the big drivers for why they recommend Framework so strongly, and I didn't realize how big a driver that was until they told me that themselves repeatedly. [21:05]

Carl: Yeah, I can understand that, and like, I don't think that's wrong. Like I have worked on so many different apps and so many of them have been like badly broken in different ways. Like shout out to the company I worked at that had a 45 minute Docker build that produced 36 megabytes of webpack output. Had six different copies of the app because every, Each of their six pages was a different entry point, so you literally had to download six copies of the app as you clicked around. [21:16]

So, like, I've lived that. I've seen that. That is true. Just facts. Also, I don't know, I guess it's maybe just like in this, I feel like it's an inherent tension to the goals of encouraging deep learning and, setting up default incentives that produce better outputs, better outcomes. [21:43]

Like, I feel like they're going very hard at, um, We know that this will produce better outcomes in aggregate. And I don't think they're wrong. I think they're correct to say that. But I don't think it's The ideal path for many individual developers. So I feel like this is, this is a tension between micro and macro. [22:04]

You know, they are taking the macro perspective of in aggregate, this will produce more good. And you and I maybe are looking at the micro of this is not filling the needs for these people specifically. Yeah, [22:23]

Mark: Yeah, so like, you know, I, I understand the, you know, make, make sure that you use a tool that has all the features you will ever need. So you don't have to migrate and make sure you use a tool that has all the optimizations built in. So you're getting good default performance. What it leaves out and ignores, though, is that. [22:39]

if you're a learner or a beginner, having fewer knobs and having fewer concepts to worry about is going to make it easier to learn. A lot of companies are in positions where they can't or don't want to use Node on the back end. They just want a very simple SPA. Um, there's a lot of people who, for good or bad reasons, don't like Node. [22:59]

The React team's emphasis on frameworks. They're suspicious of, you know, the, the incentives in Vercel. And so the React ecosystem is very large and for better or for worse, a lot of people are very happy building React apps the way we have for years. And so my perspective is that the thing that the maintainers should do is Provide recommendations, but also recognize that it is a broad ecosystem and at least say The way you're using react is valid and we recognize you and support you Even if you've made choices that we don't think are the most optimal and the problem is the one line emphasis on frameworks And the tone of the statements in the docs has basically told half the ecosystem, We don't care about you, and we think you're doing it wrong. [23:23]

Which is not very helpful. [24:17]

Carl: Yeah. For sure. Right? Like, I wanna, I wanna bring in a strong opinion I have, which is that the world is held together with shoestrings and duct tape. Like, everything in the world barely works. If you look too closely at anything, like, it's a miracle that things are functional. And, My impression is that the core team is kind of railing against that a little bit. [24:18]

Like, they wish things worked better. They wish that the world were a little bit more ordered. And they are meaningfully trying to shift, you know, they are exerting their influence on the world as the caretakers for a tool used by literally millions. So, yeah, I don't know. I guess, circling back a little bit, you had brought up, like, community working group and some chats. It's very early, but you and I and Jack Harrington and maybe some other folks are talking about what that might mean. What that might look like, what processes might be involved, and what outputs might be produced. [24:39]

So yeah, I don't know, maybe ReactiFlex can play a larger role in that conversation, in that, I don't know, activity. [25:19]

Backlash and confusion over initial version

Mark: Yep. So ultimately what happened was they put up the new docs PA and the new blog post and the docs page, and this spawned a bunch of controversy and outcry, lots of arguments on Reddit and Twitter and Blue Sky. And, you know, one ex, one example of this was, Evan You, you know, the Vite creator. Um, putting up a couple of tweets where he said that, you know, like, I, I just don't understand why the React team is refusing to reasonably recommend Veep. [25:26]

And, like, I'm, I'm happy to work with them, I just don't understand where they're going with this and why. And that actually got kind of a positive response. Rather, strongly worded initial response from a couple of React team devs that later got retracted and there were a bunch of follow on discussions. [25:56]

But, it's like, from my perspective, the React team has pretty explicitly stated what their goals are, and no one wants to take those statements at face value, which is Interesting. So last weekend, after like two days after the blog post and the docs updates had gone live, I was sitting around on a Sunday night and I'm like, I could try to offer more feedback and suggestions, but I did that once already and I knew what some of the responses would be and that's why I offered this feedback and they didn't take it and apply all of it. So what if I just take this into my own hands? [26:13]

Mark filed a PR to rewrite the docs, the React team closed that but based a new one off it

Mark: And I actually try rewriting the docs page and the blog post myself to try to get across the same message but with a better tone and actually provide better guidance and instruction on using React without a framework. So, I actually filed a PR a week ago that rewrote the docs page. [26:52]

And the next day the React team actually closed that PR, and I actually got a message on the side from Matt Carroll on the React team who said, you know, like, actually do thank you for doing the work on this, but it's not quite the direction we want to go with it. [27:14]

However, they did then open up a new PR that was explicitly intended to address a lot of the feedback from over the weekend. They did copy and paste several of the sections that I had had in my PR, as well as tweaking some other sections. And this did actually get merged. So, it did not have some of the phrasing and the writing approaches that I felt should be in there, but it is legitimately an improvement. [27:30]

And it does actually meet, I think, a minimum acceptable bar where it says, like, they changed the build a React framework page into build a React app from scratch, which is roughly the phrasing that I had used. And it does actually say, you know, you can use V or Parcel or RSPack and a data fetching library and a router. [27:59]

And so it's giving actual instructions And that is linked prominently from the intro paragraph on the main setup page, and it's linked at the bottom. And the setup page actually explicitly uses the word VEET in a paragraph. And so it's not ideal, it's not the exact phrasing I would want, but they did make a second round of changes. [28:24]

And they did listen to feedback, and I do think it meets a reasonable minimum bar of recognizing that you can use React without a framework, and here are steps to do so. So it's been painful, it's still not exactly what I'd like to see, but I think we've actually reached an acceptable state at this point. [28:47]

Carl: Heck yeah. All right, nice that it's ended in that spot. We haven't talked about this, but where have you landed on your giant blog posts? Are you still sitting on those? [29:09]

Mark: Yeah, I'm sitting on it, so Like I said, part one was a recap of the history of how the React project has been developed, the influences like Meta and Vercell, as well as, you know, dispelling conspiracy theories like Next is dr or Vercell is driving it just to make money. Part two was all the history of, you know, frustrations and good and bad interactions and everything else. [29:18]

And, you know, part of my goal was to document things, and part of my goal was to drive change. And it's ended up helping with the change, but indirectly. I did show the draft to the React team after a couple of our conversations, they, you know, frankly, they asked me not to publish it. [29:43]

they didn't tell me not to, they said I should consider not publishing, which is. But like, my goal with this was not to burn bridges. Instead, I wanted to push them to make changes to the docs, to make changes to the messaging. And, we talked, and they were listening, and they were in the process of making changes. [30:04]

So I felt that at a minimum, I ought to at least give them a chance to publish the doc updates and see how things would work out, because they were in the middle of that. And so now that they've done some of that, I feel like publishing the post in its current form would be like slamming, hitting them with a sledgehammer after they did some of the thing that I already asked them to do. [30:25]

And that doesn't feel good. So where I'm at right now, is I, I still think the first part the history and the conspiracy theories part is probably worth publishing stand alone, and I can probably just extract that. I feel like there's a lot of useful content in the second part, but I would, I would need to extract and restructure a lot of it, and I haven't had time to sit down and think about it, and frankly, after, I would actually like to think about something else for a while. [30:44]

So, I expect to end up publishing some of that content at some point, but it's not top of my priority list right now. [31:08]

Carl: That makes sense. Yeah, I actually did sit down with it and four highlighter pens and I feel like there's like four posts in there. I feel like there's your personal [31:17]

experiences of trying to make changes. There's the, like, summary. Oh, man, just like the oral history you captured of like, here's how things have evolved over the last, like, nine years. [31:25]

I feel like is really useful. But Yeah. So cool. Yeah, go sit on it. Don't think about it. I will come to you with thoughts that I have in a, in a number of weeks. [31:36]

Mark: Yeah. So overall, it's been a couple months of, you know, a lot of kind of painful discussion and, and a lot of drama and arguing, but I think we've ended up in a fairly good place by the end of it. So Create React app's officially dead. The docs have been updated. The docs say both, you know, use a framework and those recommendations are updated. [31:47]

But they also say you can build an app from scratch and here's concrete instructions on how to do so. The tone is a lot better. So we've, we've ended up in a fairly good point, but a lot of this has shown that there is a really big gap between, you know, the React team's vision of where they want to go with React versus how a lot of the ecosystem wants to use React and I, I don't think that's going to go away anytime soon. [32:07]

Yeah. And I, [32:37]

Carl: Yeah, would agree. That reminds me of, uh, Posts that I put on Blue Sky. Opinions. I feel like the current, like, conflict is a, an example of the different, perspectives, really. Like, in this post, I say it's a clash between the indie hackers, the corporate cogs, and the academics. [32:38]

Where, like, by background, I'm a corporate cog, like, I have always had a large team supporting me. And so, like, I was usually the guy, like, playing around in this code base, trying to make it work better for my colleagues, who were then the ones actually shipping, like, individual features. That's a very different setting than if you are, you know, an indie hacker doing your own things and just trying to ship features and functionality. [32:59]

Which is, again, a very different perspective from, the core team, who I'm considering the academics here. Like, I've said before in this podcast, like, I strongly feel that the React core team is managed more like a research project than anything else. And, you know, I, some signal in that, in that I got some, I think like two or three of the core team members responded to this. [33:24]

It was just like a, like, I'm just going to brag that they saw it and engaged. But yeah, like they have, the core team has had a very stable vision for what React could be really since 2013. Like from the beginning, they've talked about stuff like algebraic effects and functional programming and, you know, encapsulation component models. [33:47]

And if you're like, I've been paying close attention to that. So I feel like I have a reasonably clear understanding of what that vision is and has been. And so like, I can see that it's stable, but I think if you're not paying close attention to what they're doing, you're not watching this research team go. [34:08]

You're off dealing with your own projects, shipping code, building features. You know, setting up processes for your team, then I think that. Vision is actually really hard to gather, like just from resources, from reading the documentation, from reading, from following their social media feeds. I think it's really hard to catch up on what the vision is. [34:27]

So that's maybe a gap currently in like what's available. [34:48]

Mark: And I think that ties a lot into something that the team mentioned to us in the couple calls I had with them. So, like, we just said that they have a vision, and that's, that's very accurate and valid. And yet, in a lot of ways, I've learned that the vision is almost like a vague, amorphous thing that they're figuring out as they go. [34:53]

You know, it's not that they have, apparently it's not that, like, literally everyone is driving towards the one true vision all the time. It's that, in a lot of ways, are individuals going off and experimenting with things, and then it's almost every so often they get together and figure out, okay, we've played around with a lot of ideas. [35:13]

do we have a consensus on where we're going? And like, one of the things they said was that, you know, like, I've complained that they put up very infrequent updates on the blog, on, in terms of like, roadmaps and where they're going. Like, they've put up three React Labs posts almost like a year apart. [35:32]

And my assumption reading those was that, oh, well, like, clearly they already know what they're doing, and the blog posts are just documenting that plan. And Matt Carroll said it's actually the opposite. Like, they sort of look around at each other, it's like, we probably ought to put up an update post. What are we working on and do we have agreement on where we're going and so that the blog posts actually take them multiple months to write because it's almost like a forcing function to figure out like and actually nail down where they're headed. [35:51]

So that was actually really really surprising for me to hear. [36:26]

Carl: Yeah, and you know what it made me think of? The valve management structure, the flat Non hierarchical, anyone can work on whatever interests them, and if you want to get a project done, you have to pitch it to your colleagues. Which was famously, I don't know, Valve has its own vibe, and I don't know, it's like the vibe of Valve is not super far off from the vibe of React releases. [36:30]

You know, the uh, indefinite delays and lack of communication. So, yeah. [36:51]

Mark: So, you know, I, I think we're going to see them continue to push forward. I mean, even just in the last few weeks, seeing Sebastian working on implementing Vue transition support and some other pieces like that, they're going to keep building on these things and it's great to see the forward 19's out, but you know, there, there's a lot of people out there that are just very happy to keep using React essentially the way they have. [36:58]

And there's going to continue to be a mismatch because what they're, well, what they're doing is absolutely valid and fine at a technical level. It's not the direction that the React team is trying to push. And so that leaves a lot of people feeling. You know, left out, unsupported, on the outside, and in the worst cases, concerned that somehow, like, client side React is going to stop functioning someday, just because it's not part of the server emphasis. [37:25]

And I mean, anyone can look at, like, you want to be able to look at that and realize it'll never happen, but it shows you some of the, the vibes and the extrapolation happens that leave people concerned. Um, [37:57]

Between the Wires: An interview with MooTools contributors

Carl: Yeah, I feel like I re share this every couple of months, but I want to share again this resource from FreeCodeCamp where they interviewed a bunch of the React core team through the lens of let's talk about your past work on MooTools. So, like, this is, a now 8 year old interview with, Sebastian Morkabug, whose name I'm sure I'm saying incorrectly, but it's as close as I can get, Tom, Tom Acino and Christoph Poyer, now, Christoph Nakazawa, I believe. Those are still Major players in the current React world, and they have been collaborating since 2009. So, like, they are coming up on 16 years of working together on foundational tools for the web. Like, I never personally used Mutools. But it was a, you know, meaningful minority use tool competing with jQuery. [38:09]

And it remained relevant because I think in like 2014, 15, something like that, they wanted to do, wanted to release a new array tool, you know, an array primitive. And they couldn't because MooTools hadn't yet been released. But yeah, FlatMap, that was it. That was the one, FlatMap. SmooshGate. They couldn't release the standard because Mutools had monkey patched the Array object with its own FlatMap that was incompatible with the standard, and so releasing this would have broken the web. [39:09]

So, like, this team, the core team, has, more than ten years ago, First hand experience with what it means to engage with standards and what it means to break the web. So, like, that's part of why I give them so much leeway and, like, kudos on their approach. Because, like, they know how bad it is to get it wrong. [39:40]

They know that a decision you made 15 years ago can have lingering echoes. That prevent future work from happening. [40:04]

And like, that's a really hard lesson to learn. It's a really hard lesson to apply. [40:13]

Mark: The web is forever. [40:16]

Carl: The web is forever. [40:18]

Mark: So, it's, one of the other interesting points that came out of the discussions with Matt is that the React docs are very much aimed at beginners. And it's not just the tutorial, it's the setup guides. And I think that's, that's also some of the tension here is that people are not looking at the setup instructions page and saying, Oh, this list of tools is especially oriented for beginners. [40:19]

I know what I'm doing. I can make, make my own choices. And that's fine. People have been looking at that page and saying, well, it doesn't explicitly list VEET. Therefore, the React team must have something against Vite. It's somehow bad to use Vite, et cetera. And in my, in my own draft PR, I had tried to rework some of their, their own paragraphs and phrases into a page on web app architectures to provide some guidance on like, what is a server, like a single page app versus multi page versus SSR versus SSG. [40:48]

When might you want to use one versus the other? As a way of, like, applying some guidance to choosing a build tool. And they don't seem to want to go that direction yet, because it's not, in essence, it's not something a beginner should be worrying about immediately. And so I think that's another piece of the tension. [41:24]

In what people want to see listed in the docs recommendations versus React team actually is willing to cover, which then ties back to the thing that Carl and I have been tossing around, which is, what if we had, A fully community written set of recommendations and docs and guidance for using React in the real world as a supplement to the beginner oriented, getting started level official React docs. [41:46]

So we're still trying to figure out what that might look like and what the content might be. In fact, we're supposed to be talking about it literally right after this, [42:20]

but that's sort of a pitch. Like if the React docs are going to explicitly focus on the beginner use case, then it's kind of up to the community to officially, to quote unquote, officially document what it's like to expand beyond that. [42:28]

And how to use React properly in the real world. It's something that I, I had played around with trying to pitch this kind of a community doc site idea a few years ago. It didn't get off the ground and I'm, I'm hopeful that maybe this time around we can make something like that work. [42:43]

How to start a React Project [2025]

Mark: So as an example of this, Robin Weirich, who's a prolific React author and, tutor, Has put up a number of blog posts over the years with advice on, you know, common React libraries and tools. And so he's updated his post on how to start a React project for 2025 with a set of recommendations. And it's interesting to note how this is different than the actual React Docs setup page, because this one actually starts with prefer using Vite as the starting point. [42:58]

, actually discusses some trade offs, both pros and cons, for all the different tools. Talks about using Next, talks about using Astro, which the React docs don't mention at all. And so it's the same problem space, but a very different approach to describing what your choices are than the actual setup page. [43:30]

And on a similar note, So, with Create React app itself actually being officially deprecated. [43:50]

Jack Herrington published `create-tsrouter-app` under the Tanstack umbrella

Mark: Jack Harrington actually put together a Vite based starter kit called Create TS Router App with the idea that it would be a, basically a drop in replacement. For the old create react app command that you get a basically like instead of running create react app, you run create TS router app, you get a Vite based project with TanStack router built in. [43:56]

It has the same starting. Application component content and basically equivalent features, but you're starting with a modern set of functionality. You have routing built in, whereas CRA didn't come with a router. You can expand to file based routing if you want to. So, this has been moved into the TANstack organization, and it's now an official TANstack project, and it feels like a pretty useful tool. [44:23]

Carl: Yeah, I actually had talked to Jack, just coincidentally, not about this, shortly before he released that tool. And he, just talking to him about, like, create react app and the legacy of it, I realized that, like, the original, promise of create react app was for it to be an abstraction over your build tool. [44:49]

Over all of the build tools, and I hadn't really considered that that was really kind of, that promise never really realized, like, we, yeah, we had it for a while, but It took years for it to update from Webpack 4 to 5, for instance, and then it never released again. So it would, like, I remember at work arguing in support of using create react app instead of doing our own tooling, because, like, let's just never think about tooling again and just stay within the sandbox and get better. [45:09]

What we need out of it. And that promise just never quite happened. So yeah, I don't know that just Hearing it, hearing this TS router, create TS router tool Build as like sort of a drop in replacement for it It is a drop in replacement for the functionality But it does not even attempt to provide that same kind of like social contract promise of future maintenance Just inaccurate, correct. [45:38]

I mean, Create React app never lived up to that promise either, [46:03]

Mark: I would actually have a slightly different opinion. I would say it mostly fulfilled that promise. I would, I would agree that it never, it didn't achieve the goal of eliminating the need to think about build tools. In the cases of like the Webpack upgrade or, you know, the fact that the, The blackboxing of the webpack config meant you needed third party tools to alter the config, etc. [46:05]

So like, it didn't make those parts go away, but it did succeed in giving you a single command that would start a project without having to spend time on creating the build config yourself. Or using a boilerplate project or copy pasting it from your last working config. And that did enable tutorials to just say, run, create React app, and now let's start learning React, which was a big goal, as well as making it actually useful for real world, real world projects. [46:30]

So it didn't eliminate those concerns entirely, but I think it sufficiently succeeded in the goals of not having to think about it just to get started. [47:01]

Carl: I would agree with that. I understood it to be, to have a larger scope in mind of being an enduring abstraction that would evolve over time. And that didn't happen. Yeah. Anyway, Yeah. [47:10]

⚡ Lightning round ⚡

Carl: Oh man, we have so many lightning round links [47:24]

Mark: Lightning Round! [47:25]

Carl: Yeah, cool. All right, we're going to fly through this a little bit. [47:26]

Vercel acquires Tremor

Carl: Uh, Vercel bought an open source React, toolkit, which is interesting to me. Like, I hadn't heard about this in advance, but like, Tremor is apparently a open source React dashboard tool that was funded by Y Combinator in 2023, and now Vercel has bought them. So like, I don't really understand what it means for an open source library to be venture backed. [47:29]

, but like I'm generally supportive of it. Like I would love it if open source maintainers could paid for the work that they do, which is meaningful and impactful and takes a lot of effort. It's a little bit unfortunate to me that the model by which you can get paid for that work seems to be rich dudes in tech decide that they're going to give you money and then other rich dudes in tech buy that work from you. [47:53]

But yeah, that was just interesting. That seems like an outlier. I have not heard of very many open source tools either getting VC funding or getting acquired. Really, Remix is the only other example that comes to mind. [48:18]

Things people get wrong about Electron

Carl: Yeah, I saw a fun post titled, Things People Get Wrong About Electron. And just sort of a fringe at, you know, a fringe post talking about tech kind of at the margins. [48:29]

Like, I have written a re an Electron app in, like, 2015. Oh my god, 10 years ago. Ugh, I'm so old. But yeah, just, it's neat. It's fun to see such a different context for the web. Definitely recommend checking that out. Just as a, as a curiosity, really. [48:41]

Initial Observables support in Chrome 135, Observable API

Mark: So, there's been a decade long effort to try to get some form of observables baked into the browser. Ben Lesh of RxJS has been beating this drum for years, and it looks like they've finally succeeded in getting some of it. Some form of observables actually baked into the browser. It seems partially limited in scope, partially related to, event handlers, but I think it's at least a starting point for adding this kind of an API directly. [48:57]

And so Ben's pretty excited about that. Also on, also on the note of just, you know, really good deep dive technical articles. [49:25]

Why I rebuilt ProseMirror’s renderer in React

Mark: someone who used to work for the New York Times talked about taking the pros mirror rich text editing library, which is partially react related, but partially independent. [49:33]

, and rebuilding the ProseMirrorRenderer directly in React on top of the data structures. Great article, very well written. [49:43]

JavaScript Temporal is coming

[49:52]

Carl: Mozilla had a post at the end of January, about Temporal. JavaScript Temporal is coming. Dates in JavaScript are garbage. They are awful. My favorite example of a specific way they're awful is that they have no concept of time zone. And so every date uses your local system time zone, Which is absolutely awful. [49:53]

If you're trying to do anything involving time in two different locations, [50:13]

Mark: is why we've had Moment and DateFunctions and Lexon and who knows how many other libraries. [50:18]

Carl: All fine. So Temporal is a new, date standard tool, standard library for JavaScript doing dates and it's coming. I hope it's good. I haven't really played with it. I tend, I don't want to think about dates, so I don't want to think about them any more than I have to. And so I haven't really looked at this. [50:24]

It's coming. It's soon. That was a good post. [50:41]

Do JavaScript frameworks still need portals?

Carl: this was kind of neat. Do JavaScript frameworks still need portals? React has had portals for a long time for like, rendering stuff like modals or tooltips or popovers that exist like, outside of the hierarchy, quote unquote. Just sort of as a way of rendering something within the component tree, but not having the DOM output be in the same hierarchy. [50:44]

And that comes with all sorts of quirks and weird bits. Like z index can get really weird. Think it's awkward and funky for like cross platform stuff. I don't know how well it works in React Native or, you know, other contexts to make use of these portals. So just like this was a kind of fringe topic, like how often do you think about using React portals? [51:07]

And so just like reevaluating, like, are they still necessary? Do they still, is the problem that they were introduced to solve Still relevant in 2025. And I thought that was a good question to ask regardless of what the answer is. [51:33]

What Do We Do with You, Old React?

Mark: we've had years of migrating from other frameworks to React, and we've now had two or three different eras of different styles of React code. So, now you can migrate and modernize your old React code to modern React code. And so there was a good post called, what do we do with you old React that just gave some quick examples of migrating from things like class components to function components and old Redux to modern Redux and old testing approaches to React testing library. [51:46]

, nothing fancy. A lot of this has been covered elsewhere, but it was a good, useful summary. [52:14]

“Records and Tuples” proposal is now “Composites”

Mark: And finally, for the last couple, last few years, we've had a work in progress TC39 proposal called records and tuples, which was an attempt to build fully deeply equal objects and arrays directly into the runtime so that you don't have, so that you could just use like the triple equals operator and it would do like a deep equality comparison of all the fields rather cheaply, rather than having to use a library like immutable. [52:18]

js. And this proposal has apparently just undergone a significant revision. It's, I guess it's no longer even called records and tuples, and instead they're calling the objects composites instead, and you would need to call a specific composite. Equals method to compare them. I saw the tweet, I skimmed through the readme of the summary of the changes, I have not had a chance to look through the slides yet, but it's interesting to see how this proposal keeps evolving. [52:48]

Carl: Neat. Super cool. Oh yeah. That was all of our lightning round links in like less than 10 minutes. For sure. Proud of [53:19]

Mark: us! [53:24]

Carl: Cool. Thank you everyone for joining us. That's all we got this month. We'll be back on the last Wednesday of the month, for real this time, I think. [53:25]

, uh, we'll be back at the end of the month in the live stage here in React to Flux or back in your podcast feed just as soon as we can after that. I try to get it by the first of the month, but not always. We gather sources from This Week in React, Bytes. Dev, React Status, Next. Js Weekly. The React. Js subreddit, here in Reactiflux, and directly from those publishing articles as well. If you see anything newsworthy, definitely let us know in the tech news and reads channel here in Reactiflux, or shoot us an email at hello at Reactiflux dot com, with TMIR in the subject line if you can. I read literally everything that comes in, even spam and whatever, so if you send it, I'll read it for sure. [53:32]

And if this is a show that you get value from and want to support, the best way you can do so is by either submitting a review or telling your friends and coworkers about it. Like, if this was useful, just like, send it to one other person. That would actually do a lot for us. Cool! Thank you so much for joining us! [54:09]

Mark: Thanks, appreciate it, and hopefully we'll have less drama to talk about next month. [54:24]

Carl: Maybe. [54:28]

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

Reactiflux — Tue, 28 Jan 2025 16:00:00 GMT

[01:29] Job market: FRED data, Layoffs.fyi
[03:09] Sponsored by Infinite Red
[04:17] New releases
- [04:26] React query 5.63
- [04:45] Docusaurus 3.7
- [05:17] React Native Audio API
[07:30] Main Content
[54:26] ⚡ Lightning round ⚡
- [54:26] Redwood.js 😱
- [55:59] A checklist for your tsconfig.json
- [56:30] Recoil repo archived
- [57:47] Bun: first-class support for s3
- [58:48] Interpolate auto height for animations
- [59:47] Free javascript; Oracle not voluntarily releasing
- [01:00:31] Understanding React Server Components | Tony Alicea
- [01:02:13] Follow us on Bluesky!

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

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

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

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

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

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

Mark: am making the news. [01:26]

Carl: making the news and then reporting on it. Cool.

Job market: FRED data, Layoffs.fyi

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

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

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

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

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

Sponsored by Infinite Red

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

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

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

They are infinite. red. [04:04]

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

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

New Releases

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

React query 5.63

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

Docusaurus 3.7

Carl: Docusaurus also put out version 3.7, so if you're using that, consider upgrading. Great [04:52]

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

React Native Audio API

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

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

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

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

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

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

Main content

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

CRA deprecation, React team against recommending Vite

Carl: Mark, you want to start us off talking about Create React App and we we can springboard from there [07:37]

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

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

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

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

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

Carl: Right [09:07]

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

Dan’s “why CRA exists, don’t use it, possible future options” comment from 2023

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

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

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

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

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

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

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

80 percent odd, you find Create React App. [12:38]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Yeah [22:20]

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

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

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

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

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

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

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

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

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

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

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

Yeah. [27:01]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Carl: Yeah. [31:24]

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

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

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

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

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

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

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

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

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

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

How do I do this? yeah, [34:32]

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

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

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

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

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

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

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

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

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

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

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

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

Carl: I've read half of it. It's good. Okay. Moving on.

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

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

Main PR

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

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

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

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

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

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

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

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

Static hermes update

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

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

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

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

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

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

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

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

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

React Native Hosting with EAS

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

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

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

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

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

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

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

Everything You Need to Know About Node.js Type Stripping

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

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

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

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

Mark: That does not surprise me. [47:04]

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

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

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

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

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

Composable Caching with Next.js

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

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

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

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

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

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

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

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

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

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

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

Carl: Right. [51:28] [51:28]

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

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

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

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

Carl: Cool. Yeah,

Thoughts on What RSC Means for SPAs

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

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

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

So it's short, but worth reading.

Chrome's 2024 recap for devs

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

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

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

So, being able to do it without crazy layout logic in JavaScript sounds great. Maybe I will actually use them again.

Shoutout webstatus.dev

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

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

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

Redwood.js shutting down?

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

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

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

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

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

this month. [55:56]

Mark: next month. [55:56]

Carl: Actual details, not screenshots of Slack.

A checklist for your `tsconfig.json`

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

pretty sure that Matt Pocock has done a similar post somewhere.

Recoil repo archived

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

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

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

Carl: Sad to see stuff drop

Bun: first-class support for s3

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

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

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

Interpolate `auto` height for animations

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

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

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

Free javascript; Oracle not voluntarily releasing

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

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

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

Understanding React Server Components | Tony Alicea

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

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

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

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

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

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

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

Follow us on Bluesky!

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

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

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

It's great. Help us grow. Woo!

TMiR 2024-12: React 19 is here 🎉

Reactiflux — Sun, 22 Dec 2024 16:00:00 GMT

[01:45] Sponsored by Infinite Red
[02:46] New releases
- [02:48] Relay v18.2
- [03:07] React-admin v5.4
- [03:16] Preact v10.25
- [05:25] Playwright 1.49
- [05:33] Astro 5.0
- [06:00] Radon IDE
- [07:57] React 19 compat for react-redux and Redux Toolkit
[10:37] Main Content
- [10:39] React 19 is actually out (blog post)
  - [11:16] Upgrade guide from April 2024
  - [11:31] Removed things
  - [17:07] New things
  - [28:42] TKDodo: Ref Callbacks, React 19, and the Compiler
- [34:07] Introducing React Native Screens 4.0.0
- [37:00] React 19 support in React Native TBD (0.77/78?)
  - [38:58] Expo has experimental support
- [40:37] Next 15.1
  - [39:52] experimental: css inlining
- [41:33] React Native Fast IO now in prerelease
- [43:27] Create Target Widgets in Expo
[44:55] ⚡ Lightning round ⚡
- [45:02] React Native demo for Android XR
- [45:43] If Not React, Then What?
- [50:14] Vitest vs. Jest
- [52:29] Aiden Bai “render-shaming” sites while working on React Scan
- [55:14] Lenz’s Weber’s testing-library/react-render-stream-testing-library
[58:13] Outro [00:00]

Carl Vitullo: Hello people. Thank you for joining us for the December edition, the end of 2024. this is almost this year in React, this time around. [00:08]

But yeah thanks for joining for December's This Month in React, wherewe recap and digest recent developments in the ever evolving React and web ecosystem. Coming to you live from Reactiflux, the place for professional React developers, and supported by Infinite Red. [00:22]

I'm Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs like this. [00:29]

Mark Erikson: Hi, I'm Mark. My day job is working at Replay building a time traveling debugger for JavaScript and outside of that I do ridiculous amounts of Redux stuff. [00:39]

Mo Khazali: And I am Mo. I head the mobile team at Theodore. I'm quite active in the React Native ecosystem and I organized the React Native London meetup and conferences. [00:47]

Carl Vitullo: Right into it. I don't really have a job market or conferences coming up this month. I had noted that over the last, six weeks or so, the list of upcoming conferences has dwindled down to zero. I've seen them start to pop back up again. [01:01]

So we've rounded that corner of people getting prepared for next year, but we'll be back with some more conferences. to notify you of next month. [01:10]

Mark Erikson: that is that I actually sat down and started trying to do preparation for applying to conferences for next year. Some of them apparently have already closed for next year. So it's, getting ahead of the timeline process. [01:24]

Carl Vitullo: definitely getting ahead of it. Yeah small fun news for me, I am on staff for SquiggleConf next year, so, I'll have news for that, but it's not until September, so, no rush. Highly [01:36]

Mark Erikson: recommendd folks going to SquiggleConf. It was great. [01:40]

Carl Vitullo: But yeah, into it. Before we get all the way into the main content a note from our sponsor. [01:45]

Sponsored by Infinite Red

Carl Vitullo: We are sponsored by Infinite Red, which is an expert React Native consultancy. They've been around since 2015, so like about to be 10 years, Give it another week or so and that'll be ten years. They're owned by Jermaine Holmgren, Todd Wirth, and Gant Laborde. They're our only sponsor in part because they do so much more than most consultancies and most of the companies in the ecosystem. [02:07]

there's just not many other people who operate at the same level as they do. I've been seeing their name for as long as I've been active professionally. And they're still around. They're still doing great stuff. They only do React Native. They've built over 75 apps for companies and startups. [02:21]

And other than great people who've done great things for the ecosystem they're a team of about 30, mostly devs, mostly 10 years of experience or more and they work alongside your team to develop expertise at that company. So if you are spinning up a new product with React Native, or just trying to develop in house expertise with React and React Native, they can definitely help you hit the ground running. [02:44]

So give them a ring. https://infinite.red/. [02:46]

New Releases

Carl Vitullo: cool. Into some new releases. [02:48]

Relay v18.2

Carl Vitullo: First on the list, we got Relay18. 2. They've got an experimental hook for pagination with prefetching and a at catch directive, or the catch directive has been updated so it can be used on fragments and queries and mutations. [03:03]

So just better error handling, looks like. Better pagination, better error handling. [03:07]

React Admin v5.4

Carl Vitullo: There's React. Admin, 5. 4 not a lot of notes here, but it's out, it's new, if you're using it, definitely check it out. [03:16]

Preact v10.25

Carl Vitullo: Preact has a release, 10. 25 looks like stronger types. Support for object interface as a listener, , It looks like the last couple of releases have all been pretty small. So, you know, this is just sort of Preact doing its Preact thing. I'm not really sure if they're still abiding to the original idea of like drop in replacement for React. It's, I think, especially with React server components, they've diverged a little bit. But yeah, there's still use for it for sure. [03:45]

Mark Erikson: Yeah, I've not sat down and tried to do a strict line by line feature comparison, but I think at this point generally support most of the original hooks. But I think beyond that, , they've stopped trying to match things feature for feature. So, if you're doing relatively straightforward things, then, you may have actual compatibility, especially if you like want to use any of the new, like React 19 features or anything with the Preact bundle, then obviously they wouldn't work. [04:14]

Carl Vitullo: right. I guess my mental model for it is this is like, if you're working in a highly constrained environment where you would still like the niceties of React, React is great, but if you're not dealing with a highly constrained environment, then might not be necessary. [04:28]

Mo Khazali: So an interesting one, I guess an interesting use case for Preact is that it's commonly used in TV development. If you're building web apps that are going to run on TVs, where there's a very, very small amount of resources. A lot of times I've seen people use Preact. So some big names in TV apps that you might've known, which I don't know if I should mention, but you know, some big TV apps will be using Preact because a lot of the apps that you have on TVs are web apps, but they need to be constrained in the resources that they use. Mm [04:57]

Mark Erikson: is just ironic how Web app has become the default, way to distribute things everywhere. I [05:05]

Mo Khazali: Yeah. I mean, web is like kind of a standard almost for TV, for TVs. Like if you're building for Samsung, if you're building for LG and a bunch of other TVs, you build it using a web app, so it's pretty cool that it's standardized around that. [05:18]

Carl Vitullo: Yeah, I talked to someone about React Native on TV too, yeah. Neat. Funny. JavaScript eating the world. [05:25]

Playwright v1.49

Carl Vitullo: There's also Playwright 1. 49. Nothing too fancy there, but pretty widely used test tool, so if you're using that, there it is. [05:33]

Astro v5.0

Carl Vitullo: Astro has a major release, version 5. 0. what they're calling content layer, a new flexible and pluggable way to manage content, providing a unified type safe API to define, load, and access your content, no matter where it comes from. Sounds a lot like Gatsby's [05:48]

Mark Erikson: was about to say that, yeah. [05:50]

Carl Vitullo: So fair enough, you know, like that's a real need, you know, loading content from many places. Very real need. Sounds like they're not using GraphQL for it. So, different take. Fair enough. [06:00]

Radon IDE

Carl Vitullo: Yeah, there was Radon IDE. Mo, you want to talk about that? [06:03]

Mo Khazali: it used to be called the React Native IDE, and then they rebranded for obvious branding reasons to Radon IDE, fun little Easter egg. Radon on the element lists is RN. So, anyway React Native traditionally has not had an IDE. So, you know, you build in VS Code, but a lot of the functionalities that, if you were like a Swift or an Android developer, just wouldn't be there. [06:23]

And so, the folks at Software Mansion have created Radon IDE as sort of a way to make your VS Code more of a Full fledged IDE for React Native development. So it comes with a bunch of cool stuff like integrating with like your simulator and then being able to inspect elements that are on the screen and find out where they are in code, which is really, really cool. [06:42]

And it's sometimes a pain in React Native breakpoint support, understanding your navigation tree. They have debugging kind of nailed down, which has been a real pain in React Native, so that's quite cool. And then another thing that was a cool little gimmicky feature, I'd say, is instant replays. [06:57]

So, you know, if something happens on your simulator and you're like, oh crap, that was a bug you can click back and get, like, the last 5, 10 seconds as a replay and then save that , to a file. So some cool little utilities, I'd say that you can use when you're building React Native apps. It is a paid IDE, so You know, it starts at, it's around 20 a month per seat. [07:17]

But you know, so something to consider. So they're going for the paid model as almost a paid extension onto VS code. [07:23]

Carl Vitullo: Interesting, huh? Definitely makes sense. I mean, times I've worked with React Native, the debugging experience was among the rougher sides of it, so it makes sense to have a stronger IDE integration for debuggability things. Cool. [07:37]

and I believe Software Mansion is also Nope, never mind. I was gonna say behind React Admin, but no, they're not. [07:44]

But then Software Mansion does lots of stuff in the ecosystem. They are Certainly, you know, I say not many companies do as much as Infinite Red and Software Mansion is definitely in the running there. A trusted name for sure. [07:57]

React 19 compatibility in react-redux and Redux Toolkit

Carl Vitullo: Yeah, there's also React 19 compatibility release of Redux Toolkit. [08:02]

Mark, anything you want to say there? [08:04]

Mark Erikson: yeah number one, I actually had nothing to do with the work on these. One of the other maintainers, Arya, did all the actual grunt work. in React Redux, we now test against both 18 and 19. you'd think it would be as simple as just bumping the peer dependencies list and shipping, but, you know, you actually want to test against them, you have to check any, any types related issues. [08:27]

in the Redux toolkit case, it's actually caused a ripple effect where we. I merged the PR to support React 19 at, you know, at the code level. And we accidentally ended up, semi accidentally ended up bumping React 19 for our DocuSource based docs website. And that ended up breaking client side interactivity because we were still on DocuSource version two. [08:52]

Which didn't correctly support React 19 somehow. So the doc site built and you could view it, but it was the static, you know, HTML only and all the client side interactivity broke, search, copy code button, everything else. On the one hand, it's like, you know, conceptually, it's simple. On the other hand, there's actually a lot of work involved. And then there's always the, you know, the unexpected ripple effects afterwards. [09:19]

One other ripple effect I've seen, which I don't think we have listed directly, but I've seen a lot of people report problems with Create React App because, you know, like, beginners are trying to I assume beginners are trying to create new CRA projects. They're using, you know, It uses NPM to do the installation by default, and the CRA templates still use an existing version of React testing library that wants React 18 as a peer dependency. [09:50]

And so, what happens is, NPM tries to install the packages, Also tries to install React 19, because that's the latest. And then, NPM being its helpful self, throws an error because there's a peer dependency mismatch between the installed React 19 and React Testing Library 1. 18. So, I've seen a bunch of people report, Why can't I create a new React project? [10:16]

With that kind of an error in the last couple weeks. And so basically CRE's borked at this point. I [10:22]

Carl Vitullo: That is unfortunate, yeah. But also not too surprising. I guess it's a little bit of a matter of time for that. Too [10:28]

Mark Erikson: in theory it could be fixed with, like, someone publishing updates to the templates, but I have no idea who, if anyone, would do that. [10:35]

Carl Vitullo: Not sure how actively maintained that is anymore. [10:37]

Main Content

Carl Vitullo: Alright, into our main content. [10:39]

React 19 is finally out (blog post)

Carl Vitullo: The main, main, main, main, main content of React 19 is out. It is officially released and usable. [10:47]

Mark Erikson: Yay! [10:48]

Carl Vitullo: Yeah, so, we're gonna spend a minute, pretty much everything in these, you know, release notes and, , overview blog posts. , there's nothing brand new, , they've been messaging this, they've been talking about it, they've been, you know, trickling out bits. over the last year and a half. So pretty much everything in this episode that we're going to discuss, at least for React 19, we've already covered in some detail in the past, but we're going to bring it all together. this is the one where we talk about it all holistically. [11:16]

Upgrade guide from April

Carl Vitullo: Yeah, there's a great upgrade guide from back in April. I think that was before they found the issue with Sibling. [11:23]

Mark Erikson: Yep, because that happened at the start of June. [11:26]

Carl Vitullo: So that was when they thought it was going out pretty, pretty shortly. Here we are eight months later, and it's out! [11:31]

Removed things

Carl Vitullo: I'm gonna start with what they took out, because I, it's a lot of things that I, Remember using, I remember fondly. [11:38]

So they removed prop types. There's no more prop types it just silently gets ignored. know, they mentioned prop types were deprecated in April 2017. So here we are seven years later, and it's finally, a deprecated feature is finally being removed. Wow. Likewise, they removed default props for functions. For class components, those still have default props, but for a function component, just give it a default argument. It'll figure it out. [12:05]

Finally removed legacy context. Also, just like prop types, deprecated in October 2018. Six years later, here we are. They removed string refs, the create factory helper, because that was if you can't use JSX, you can use this instead. So yeah, everyone uses JSX. Widely supported. [12:25]

Mark Erikson: I've used a couple different little third party helper libraries for JSX environments, but this was one that was sort of built in. [12:34]

Carl Vitullo: Yep [12:34]

some testutils, removed some deprecated DOM helpers. Or, Render and Hydrate are now removed in favor of their concurrent equivalents, the CreateRoot and HydrateRoot, as well as UnmountComponentAtNode and FindDomNode. They also removed UMD builds, Universal Module Declaration definition. [12:58]

Mark Erikson: Definition, yeah. [12:59]

Carl Vitullo: Yeah, that's not really been super relevant for a very long time now, not sorry to see that go. What was the, what was the main tool that used UMD? [13:09]

Mark Erikson: Well, okay, so, recap for people. So we had, you know, we, originally we had script tags and everything's a global, and then the AMD format, Asynchronous Module Definition, was a, community created module format for use in the browser. CommonJS, loosely put, was designed for use in Node because it requires reading a file off disk synchronously. [13:31]

UMD was a, someone figured out the incantation to wrap the actual code that you cared about in a complex header that basically tried to figure out, am I being loaded as a script tag, a CommonJS file, or an AMD file, so that one bundle could serve as all three formats. Simultaneously. In practice, UMD files have basically been generated for use as script tags loading off of unpackage or something like that. [14:04]

Carl Vitullo: sure, right. Yeah, I was thinking of RequireJS with the AMD module. but yeah, now with ESM and you know, dynamic import and all the bundling tools that we have now, that's, that hasn't really been relevant in six or eight years, something like that. Or it hasn't been cutting edge, at least. Hasn't been the recommended. [14:22]

But yeah, so, cool. That's all the stuff they removed. A lot of old things that haven't really, that have been deprecated for long enough that, yeah, they can go away. [14:32]

Mark Erikson: Yeah, a couple observations there. One, I made the same decision around removing the UMD bundles from the Redux packages when I shipped RTK 2. 0 last year. The difference there is that I replaced it with an ESM format file that had all the process node env references compiled out of it. [14:52]

And the React packages still don't have, quote, proper ESM support. So this, in one sense, they did actually remove something without a direct replacement for it. I've seen a number of suggestions to you that if you need to use React, like, in essence, as a script tag, then the intended replacement is to use a site called ESM. SH, which I actually looked into that a little bit, and what it does is it apparently uses ESBuild to compile various third party libraries with some sort of an ESM wrapper around them. So, even though React itself is still only shipped in common JS format, this site, this service it'll re wrap various packages with ESM around them, even if they didn't ship with it. [15:46]

And then serve that up as, you know, a script tag. [15:50]

Carl Vitullo: Interesting. Yeah, I hadn't heard of esm. sh. Looks like it's maybe sponsored by Cloudflare? It says the CDN is powered by Cloudflare. So it looks like this might be a service, you know, for the ecosystem that they're running. [16:05]

Mark Erikson: and then the other one is, if you look at the issue with people complaining that find DOM node was about to be removed, there's, there's still a number of people who are not terribly happy about that one. they've got cases where their component structure is, it's deep enough, nested enough that they, they needed to rely on find DOM node to Find the right things to interact with and, people are not happy that it's been taken away. [16:30]

Carl Vitullo: That seems a little strange to me. I feel like if you're in that position, there are native browser features that would do you pretty well enough, but okay, sure. I've not been in that situation, so I don't know what the weird technical trade offs involved there might be. [16:44]

Mark Erikson: And then our favorite hidden internal non documented API, SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED, has been renamed to SECRET_INTERNALS_DO_NOT_USE_OR_WARN_USERS_THEY_CANNOT_UPGRADE [17:00]

Carl Vitullo: okay, that's a little more descriptive. It's a little more actionable. I don't know of anyone who's been fired for using those, so, a little more accurate. [17:07]

New things

Carl Vitullo: Yeah, some, getting into some new things, what they're, you know, what they've added now looks like, to me, it looks like the big stuff is mostly around transitions. my mental model for this is a little bit like, for most of React 18, we used like useState and useEffect and like a couple things around there to do basically everything. [17:31]

And I think the core team identified that there was a pretty consistent and tricky use case of what happens when you need to take actions and manage state as components are, mounting and unmounting. That was definitely a little bit painful. Getting the intricate dance of as things unmount and remount, or different things swap in to replace them has definitely been awkward and tricky, especially for little things like animations. [18:02]

Like If you have an animation, you can't actually unmount until the animation is completed, which may, you know, if you have a state change that would remove the component, but you want an animation to finish, then you need to like add in this like extra ceremony to keep it technically mounted while not actually in use, not actually responding to new events and things like that. So that's my mental model for what these transitions are intended to support. [18:28]

Mark Erikson: That feels a little different than my understanding. So I've not used transitions myself, probably because I haven't been writing as much React front end stuff lately. But, like we, you know, there used to be the discussion of, you know, React 18 is going to have a concurrent mode. [18:42]

eventually said, okay, like, having an entire mode isn't what we need, we're going to have concurrent features instead. So my, my understanding is that transitions are, primarily part of that concurrent feature set where you're basically telling React, we're going to start a render, but this is going to be considered low priority. [19:02]

This could be interrupted. It will do the, like, you know, render a tree for five milliseconds and then pause to see if the browser has any events. So, my understanding is that transitions are primarily telling React, do some work, but this is considered a low priority render versus all the normal use state type based rendering. [19:26]

Carl Vitullo: Interesting. Okay, fair enough. [19:28]

so this is where the, you know, confusing verbiage that React introduced around like actions and how now we have many, many, many Actions is a very overloaded term in the ecosystem. [19:40]

Mark Erikson: for Redux, another thing for MobX, now another thing for React Forms. [19:44]

Carl Vitullo: Right, and I remember Astro had an actions thing as well a while back. So, right, there's just many, there's a lot of actions being taken. Yeah, so functions pass to start transition are actions. There's some additional hooks that are also able to tap into those, into the Actions as being used by active transitions. [20:05]

So there's used action state which is a new hook to order actions inside of a transition with access to the state of the action and the pending state. So it, accepts a reducer that can call actions. So this is this smells a little bit like redux, baked into an interaction. a little bit. [20:24]

As well as useOptimistic, which ties into these transitions by letting you update state while the transition is in progress, and it returns the state as well as a set function to optimistically update the state within a transition to be the expected final value. So, you know, like if you're doing optimistic updates within your UI, firing it off to persist in the back end, but immediately updating the local UI as if that has already finished. [20:51]

But then gracefully handling the actual outcome of the of whatever action you took. [20:57]

Mark Erikson: one observation here, you know, less around the behavior and more around the description. When React 19 came out a few weeks ago, the post in the JavaScript subreddit, the main discussion was basically around that paragraph and how hard it is to read for someone who isn't intimately familiar with React already. [21:19]

And You know, a couple of different thoughts around this, like, one is that, you know, React has added a lot of things over time. Another is that there's been some cases where the React team has tried to turn things into proper named nouns in a way. Like, it's not just like, the useEffect hook, there are capital E effects. [21:44]

And so, and so now it's not just, you know, we're going to do a low priority render, it is a capital T transition. And I, I just glanced at the docs. Like I'm, I'm looking at the use transition docs page and it does intro with use transition as a react hook that lets you render a part of the UI in the background, but like it right away starts using capital T transitions without ever defining what that word means. And there isn't really like a conceptual explainer. [22:19]

So, part of it, like I realized that release notes aren't the right place to, you know, to go out and define a bunch of things, but both reading this specific paragraph, as well as trying to figure out how some of these new features are integrated into the docs and the teaching workflow, it feels like they're like, we're kind of missing a bit of a, like a conceptual explainer for some of these terms and how they relate to each other. [22:46]

it's fixable, but, you know, like that, that's just one of the things that stuck out to me. [22:50]

Carl Vitullo: Yeah, makes sense. Yeah, that's fair. it feels like an Apple type of branding. You know, it's not a, it's not an mp3 player, it's the iPod. [22:59]

Mark Erikson: not the, just iPod, iPad, iPhone, whatever. [23:03]

Carl Vitullo: No articles. Sure. [23:04]

Yeah. other than transitions, they got the use hook, which is a little bit old hat by now, accepts a promise or context for accessing resources within render. If you give it a promise it will suspend until the Promise is resolved. [23:19]

Mark Erikson: the naming still feels awkward, like, I don't have a better suggestion, but, in today's world, naming things for Googleability is very relevant, and giving this thing the name use is like the most un Googleable thing ever. [23:37]

Carl Vitullo: There, right, right. [23:38]

And back to my pet peeve about some of the quirks of React 19. This is the use hook, and it says right in the release notes, use can only be used in render, but can be called conditionally. And like, come on, rules of hooks, like, drilled into us repeatedly. Anything called use Use whatever. Cannot be called conditionally. [24:04]

Mark Erikson: With the exception that you could already get away with, you could apparently already get away with calling useContext conditionally. I've never actually done it myself, but apparently, technically that worked. [24:14]

Carl Vitullo: Interesting. I have not either. I don't think I knew that, actually. So I guess, cool, this is consistent with use context. [24:20]

So clearly, I guess, it has its lineage in there. It is the way to use context. it just seems a little strange to me to, like, this seems like it's going to be a very widely used hook, and so for it to break the rules of hooks, quote unquote, quote unquote. [24:34]

Feels like it adds a lot of, I don't know, weirdness, ambiguity, confusion. [24:39]

Mark Erikson: it does I mean, I know that there's plans to hopefully expand that down the line. My, my Redux co maintainer, Lens, who also works on Apollo, has been begging for the ability to pass an observable. to use for a while now. So it's possible that that may happen at some point. It also is kind of one of those things where like they, you know, they needed the rules to be strict originally. [25:03]

And now that the rules are defined and the ecosystem understands them, they can start to tweak it. But as you know, that also leads to confusion as well. [25:11]

Carl Vitullo: Right, right. it's all a game of telephone and this adds strangeness. It adds exceptions to the rules. lots of other convenience features coming out with React 19. You can render metadata tags in components wherever, and they'll automatically get hoisted into the head section, which is great. [25:28]

I, I think I said it when this was first announced, but like, the, React Helmet was, as far as I know, the main way to really interact with head in React, and it was just like not very consistently maintained. I kept running into, like, I feel like every time I used it, every time I was spinning up a new project and trying to interact with the head, it's like, oh, React Helmet, cool. [25:48]

Pull that in. Oh, this does not behave in the way I expect in these many different ways. And so then what I thought was just gonna be a trivial, it works. Was not, was not trivial, did not work. So love that. Love to see that. [26:03]

But yeah, RIP React Helmet. That was, I remember, I remember when that was released. I remember that was announced and going like, what the hell? NFL is releasing an open source project at the bleeding edge and they called it React Helmet. This is perfect. Protects the [26:18]

Mark Erikson: one, definitely one of the best project names ever. [26:21]

Carl Vitullo: Yes, absolutely. So, RIP to NFL's React Helmet. another convenience feature, you can use async scripts. [26:30]

You can render them anywhere in the component tree, and they will be, React will handle the ordering and deduplication of them, which is neat. Yeah, deduplicating async scripts sounds That makes me a little scared. But yeah, I guess it shouldn't be too bad as long as you're not doing any weird stuff with the file name. Yeah, likewise, more head stuff. React 19 will ensure style sheets are inserted into the head before revealing the content of a suspense boundary. So, you know, predictable, Easily anticipated ways of interacting with the head. Also some initial load optimizations. Initial load and transition, page transition optimizations around pre init, pre load, pre fetch DNS, pre connect. [27:14]

These are all, like, kind of low level optimizations that used to be exposed at the level of, like, script tags, where you could say, you could communicate to browser what level of initial connection to try and get ahead of. You know, because it takes a little bit of time to look up the DNS, to connect to the server, to open, you know, begin streaming data. [27:34]

So, it sometimes introduced extra latency that was undesirable. So you can now, in React 19, have a little bit more control over how external assets get loaded in that way. You know, just even like pre fetch DNS and pre connect. Will cut the latency a decent amount. I've used those things in the past. It's a pretty nitty gritty performance optimization, but yeah, definitely important that we can now do that. That's nice. [28:00]

Yeah, a big one, a nice one. One less use case for Refs can now return cleanup functions, so that's definitely big. That's definitely good. I think it had definitely been a pattern to, like, do a useEffect, to do things like setting up event listeners, and that was a little bit weird. [28:19]

I don't know, it's just a little funky, because they're, they're clearly tied to the DOM. It's associated with a DOM node so having to do it in useEffect introduced, it just, extended that distance between the code that was being run and what it relied on. You had to do extra weird deduplication stuff because it was an effect. [28:36]

So now, because refs support cleanup functions, it's just a little bit closer, you can keep it a little more self contained. [28:42]

Ref Callbacks, React 19, and the Compiler

Mark Erikson: Yeah, and there's a, there's a good post from Dominic Torfmeister, the, you know, maintainer of React Query, he had written about dealing with, dealing with refs a couple years ago. And so he kind of revisited that topic and showed that, you know, hey, there, here's, here's cases when, You know, now you can do things like setting up a resize observer in a ref, and you don't even have to have a useEffect plus a useRef to manage that. [29:10]

Carl Vitullo: another very small convenience feature, you can now render just context instead of context. provider. That's nice, that's good. Very small, very petite. React 19 also has support for custom elements, i. e. web components. For the first time in React's history we discussed that at much greater length in previous episodes. I don't know if there's that much more to say, web components. If you're using web components, cool, great, now you can use React as well. [29:36]

Mark Erikson: it's still really complicated You know, a lot of it boiled down to, like, React can, in theory, render any arbitrary HTML tag. React have a hard coded list of element types that it knows are part of HTML. But, React 18 and earlier had issues with properly passing complicated props into web components. [30:02]

And that's because of the whole difference between HTML attributes versus JavaScript DOM node properties, which I still only partly understand myself. But think part of the issue was React wanted to pass in. properties, but a lot of these things expected attributes instead. [30:23]

And so there, there was a mismatch in, in how things would get passed down as well as issues with setting up event listeners as well. And from what I've read, went into the, the mile long discussion threads, they're like the web component spec does not necessarily define how a given web component receives this. [30:42]

it's It's implementation dependent on a per web component basis. So it's literally how it's almost as if every single web component author, as they write that component decides, how is this component going to get its data or trigger its events? And so, different libraries, different wrappers, different authors take different approaches. [31:09]

And so, part of the issue with implementing this was trying to find a reasonable set of heuristics that would work most of the time, and also allow React to pass this web component in framework compat spec that had been put out there. And after React 19 came out, I saw a couple more people posting complaints that certain scenarios didn't work right. [31:34]

Like, I guess if you define a function field on your web component class. And then you also try to pass in a prop with that name. React will happily overwrite the function because it just assigns the field name, but ultimately it seems like web component authoring is a very inconsistent and per component basis kind of a thing. [32:00]

And there's a lot of edge cases with the interop and so they're never going to make everybody happy. [32:06]

Carl Vitullo: Awesome. Sounds great. Yeah, the finer points of attributes versus properties is, my eyes began glazing over at that point. [32:13]

Mark Erikson: Yep. [32:14]

Carl Vitullo: Yeah okay. a convenience that got me a little excited in React 19. Hydration errors will now be collapsed into a single error, even if there are multiple mismatches. [32:23]

Like, nice. [32:26]

Just [32:26]

Right, just having my console be blasted with, like, 30 stack traces because, like, obviously this hydration did not match is, yeah, very happy to have that just be didn't work, not here's every point at which hydration did not work. That's nice. [32:44]

So kind of subtle, I don't quite, I don't understand the, the precise details here, but errors in render are not rethread. If they're not caught by an error boundary, they're reported to window report error, not logged with console error. There's also, they've introduced onUncaughtError and onCaughtError methods to the create root and hydrate root. APIs to customize how those errors get handled. So I guess they're kind of stepping back from like automatically handling every error and logging it to the console to saying, if you have a boundary, we'll log it. [33:18]

If you don't have a boundary, you can configure how it gets handled on your own. [33:23]

Mark Erikson: You know, that's interesting. This, this might be the kind of thing that libraries might end up caring about more, but I, I actually feel like I need to go back to those React 19 compat PRs that I did not write myself, but I did merge. Because I, I think we had some tests where we had, like, assertions that, like, if an error happens while doing, like, a React Redux render or something, that errors would either get thrown of rendering or get logged somewhere. [33:50]

So now I'm actually curious how we, how those PRs ended up handling them. [33:54]

Carl Vitullo: Sure. Right. You can never know what you don't know. obviously that's the majority of our, I think that's the majority of what we wanted to get to today. [34:01]

But uh, yeah, Mo, tell us about React Native screens. Hang [34:07]

React Native Screens 4.0.0

Mo Khazali: Major version of the React Native Screens library, version 4. 0, came out. So, you, as a React Native developer, probably don't interact directly with React Native Screens. If you use React Navigation or ExpoRouter, which uses React Navigation under the hood, you will be using React Native Screens. [34:23]

React Native Screens is native layer implementation of screens on iOS and Android for your app so that you're not creating JavaScript views and not handling the view transitions on the JavaScript layer, rather you handle them on the native layer. And so a few updates here that will likely be picked up by the React Navigation libraries. [34:43]

React Navigation and ExpoRouter libraries. One is that they're adding more support for the forum sheet presentation. So this is kind of the bottom sheet interaction that you'll be used to on phones. And previously it wasn't supported on Android. And now there's an Android support. It was supported on iOS but you had a limitation. [35:02]

So if you ever played around with those bottom sheets, you can kind of pin them to certain points, and they'll kind of stick. They call these detents, I think. [35:10]

Carl Vitullo: This is like the sort of mobile version of a modal, where it's like an overlay that you slide around. [35:16]

Mo Khazali: Yeah, exactly, those ones. So the ones that come from the bottom, and, you know, you've got a little modal, and the screen behind it is still kind of visible, and you can adjust how big the modal is. they call them sheets, I guess, in mobile development. Modals, when you're talking about in a mobile navigation world, it's the ones that kind of fully cover the screen. [35:35]

Not the ones that can partially cover the screen. So you've got some of these pop ups that fully cover the screen. Sometimes you'll see them on, like, login pages or something like that. And so, a lot of these sheets, you can kind of control where they are, so you can pin them to different locations. [35:47]

So, with this new API, you are able to, on iOS, set as many points to kind of have these snap points. And on Android, I believe, there's three different snap points. That you can define. So this is kind of sticking true to the iOS and Android APIs on the native layer. They've also made some minor improvements on animations when it comes to iOS to make it a bit more smooth. [36:11]

And one of the other things that they've done is that if you've got a screen that's now detached, from the main tree of your navigation, so it's no longer rendered. You can preload these screens, and so this will kind of happen through React Navigation so that if you know a user is going to go onto a specific screen, you preload it, render everything, create the native views, and so you won't have this delay in getting the screen loaded onto the app, which is quite a nice feature, and I think this is great. [36:39]

Quite important for optimizing your app and making sure that everything is smooth, quick, and snappy. So those are kind of some of the things. You won't really be implementing any of these yourself. You'll probably use React Navigation, so keep an eye out on the React Navigation docs and the ExpoRouter docs, because some of this stuff will be landing. [36:56]

Some of it's already been landed as well. [36:58]

Carl Vitullo: Nice. Makes sense. Yeah. [37:00]

React 19 and React Native, and PR

Carl Vitullo: Tell us about React 19 and React Native. [37:04]

Mo Khazali: so taking a step back, React Native just released the new architecture. So that was the, big release that they've been kind of working on for many, many years. And so, I think they're going through a stabilization period right now. They are I think waiting to make sure that everything is smooth, stable with the last two versions of React Native that have been released. [37:26]

I suspect this will be some point in early to mid 2025, sometime in the next two releases of React Native, where they'll actually support React 19. I know that there's been some issues with supporting React 19 anyway with React Native. I think there's been some internal testing, but they haven't conclusively made sure that everything is working as expected. [37:46]

So, I think there's just going to be some delay on this. But I think it's not something that we haven't seen in the React Native ecosystem. There's sometimes a lag with these major version upgrades anyway. [37:55]

Carl Vitullo: Yeah, that makes sense. And especially, I'm just, I'm kind of connecting dots of what you were just talking about with like React Native screens, adding support for like preloading. And that sounds adjacent to, like, some of the use optimistic or use transition hooks that have popped up now as, like, first class APIs. [38:15]

So I wonder if that's maybe some of the tension there, is that now that it's a first class API, a feature of React 19, React Native needs to figure out how to implement it [38:28]

Mo Khazali: Because it's not just JavaScript there's also an element of, you know, how do you map those to native functionalities, right? So if you're transitioning to allow a native component to be rendered, well, how do you handle that on the native layer? [38:41]

So there's a lot more support that needs to happen, it's not just the browser. But you need to also make sure that at least iOS and Android support those features, not to even get into the whole out of tree platform shenanigans where you've got a bunch of other platforms that are maintained by the community and they also need to support it. [38:56]

So yeah, it has a long tail. [38:58]

Expo experimental support

Carl Vitullo: But it looks like Expo has experimental support. [39:03]

Mo Khazali: this is probably one of the musings of Evan Bacon over a weekend just hacking away, but yeah, there's a lot of these sort of, like, Expo kind of goes ahead of the curve with some of these things and tries to push the React Native ecosystem forward, which is great so, I'm not surprised that this is supported with some sort of flag in Expo. [39:21]

So yeah, it's the experiments. reactCanary, setting that to true. In Expo SDK 52, it works. These are very much experimental. Don't try these for any production apps, but it's just kind of trying to see what the effects would be ahead of time. I mean, we've seen this pattern, like Expo supporting RSCs with the bundler, with some custom changes to the bundler ahead of time before it's even, you know, supported, in any capacity officially by Meta. [39:46]

So, it's cool to see it, but it's still a long way to go for production apps. [39:51]

Carl Vitullo: Sure, yeah. Makes sense. [39:52]

Next.js experimental CSS inlining

Carl Vitullo: Well, I have a very, very small bit of React, er, a very small bit of Next. js news. They've added a experimental CSS inlining feature. And now, if you are generating, you know, if you're, you're, if you're pulling in CSS styles, instead of it being compiled into a CSS asset and Loaded with a link tag. You can configure next so that it will just inline those styles in a style tag Yeah, this takes advantage of the React 19 precedence in deduping You know, CSS features. [40:28]

So I guess this is enabled by React 19 But yeah, definitely pretty small, relatively minor performance optimization. [40:37]

Next 15.1

Carl Vitullo: guess a larger bit of news. Thank you, Mark. There's also Next 15. 1 that's out Yeah, last episode we talked about how Next 15 was stable and now they're up to 15. 1 [40:50]

Mark Erikson: The biggest one here is that because React 19 is now actually out, they've switched to using React 19 everywhere. So actually, it's kind of funny because for now they're on React 19 stable, but there's a good chance that they will continue using those canary releases in future versions of Next down the road. [41:10]

So this may actually be only a temporary problem. you know, period of time where they're, where the version of React they use actually exactly matches the stable version. [41:20]

Carl Vitullo: Right. I didn't know they have, you know, One of the headers on the 15. 1 release notes is React 19, parentheses stable. So yeah, right. They've been on Canary for forever. [41:33]

React Native Fast IO

Mo Khazali: Cool. So, next up we've got the pre release version of React Native Fast. io out. So this was sort of first showcased at React Native London Con in November. So this is made by Mike Grabowski, who is the co founder and CTO of Callstack. And so it's basically built on top of the Nitro modules package that we've seen and talked about in the past few months that's been made by Mark Roussevy. [41:59]

And so it's a way to create native libraries that are super, super fast to execute. And so, Mike from Callstack has been working on trying to get some of the I. O. functionality in React Native implemented with Nitro modules so that they're as fast as possible. And hence, React Native Fast I. O. [42:18]

So he started off with WebSockets but he eventually wants to target WebSockets, Fetch, FileSystem APIs, Blobs, and Streams. And so the whole idea is you can use the WebSockets or the Fetch that comes from React Native Fast. io and in theory it should beat all of the benchmarks for any other implementations of I. [42:36]

O. related functionality in React Native. So this isn't anywhere near production. But it's something that you can give it a shot and play around with and just run some benchmarks on and eventually at some point it should land and it could be quite interesting to see what that means for the whole ecosystem because these are quite core functionalities, right? [42:54]

Carl Vitullo: Yeah. I uh, definitely pretty low level. If that gets much faster, that enables a lot of other interesting experiments. [43:00]

Mo Khazali: Exactly. And I think The, one of the things with this is that it's one of the, like, first implementations of an actual library with Nitro modules. So, so far Nitro modules have been very hypothetical in terms of what you can achieve. Mark's been using it on a few of his libraries, but nobody else, sort of, in the community has adopted it to this degree to build an actual package. [43:20]

So, it can really start to push a lot of people towards Nitro modules when they're building native dependencies. [43:25]

Carl Vitullo: Neat. Cool. [43:27]

NPX Create Target

Mo Khazali: In other news, and we talked about Expo's random demos that they release with some cool features and going ahead of the curve. Evan Bacon in a very truly Evan Bacon fashion has been working on a new CLI tool specifically for iOS called NPX Create Target. And so the whole idea with this is, is that there are certain parts of an iOS app that you can't build with React Native and you need to build in the native layer. [43:51]

So what are those? Those are things like widgets, live activities. Lockscreen widgets, and there's a whole host of things that are not part of, like, the main app that you use, but are almost extensions on top of on top of your main app. And so, the whole idea with this is, is that it's been quite difficult to get these up and running with React Native so far, because you need to go into Xcode, add those, widgets and then kind of do the binding between your React Native app and the widgets that you create or those targets that you create. [44:19]

And so the whole idea with this is is that it's a simple NPX command that you can run and you choose the type of target or widget that you want to use and then it kind of bootstraps all the code, links it to your React Native app, has a way for them to communicate between each other, and all you need to do is just write the Swift code to basically implement that on the native layer. [44:37]

And so it's a much easier way to add these targets to your existing application to your existing Expo application. So it's a pretty cool thing. It's, it's it's nothing that you couldn't do before, but it obviously was a lot more work. And this just makes it significantly easier to get up and running with those features to make your app feel even more interconnected within the OS, within the person's phone. [44:55]

I [44:55]

Lightning round

Carl Vitullo: Alright, that's all of our main content. Let's jump into the lightning round. Moe, you're up again. [45:02]

React Native demo for Android XR

Mo Khazali: So, quick thing. Android released some new features. Cool mixed reality stuff Android XR. So there's a whole release on that. And of course someone had to create a demo of React Native running on it. So there's a quick tweet showing React Native running on Android XR. [45:17]

We'll see how this expands, but it's always within days that someone creates a demo of React Native running on any new platform or any new APIs. [45:25]

Carl Vitullo: Nice, cool. Okay, so this looks kind of like Android version of Apple Vision. [45:30]

Mo Khazali: Yeah, it seems like it's a competitor to Vision OS, basically but Android's really trying to standardize the way that XR goggles are built with Android. [45:41]

Carl Vitullo: right, cool. Good luck. [45:43]

If Not React, Then What?

Mark Erikson: Another post from Alex Russell was going around in the last few weeks. Alex generally is on a one man crusade against client side JavaScript and the React ecosystem in particular. This one was titled, If Not React, Then What? And most of it boils down to most sites shouldn't be single page applications. [46:04]

Most sites shouldn't be using react. I guess there's other client side libraries that you can use, but generally they shouldn't be client side in the first place, which is frankly, like, like my own summary is actually a, like a reasonable stance to take. And if he phrased it that way, he would probably have more people listening to him. [46:23]

But the vitriol and the vehement and the anger that he puts into these posts, even when he has valid points, makes it really hard for people to actually listen to what he's saying. [46:33]

Carl Vitullo: Sure. I haven't read this in depth yet. I would like to but yeah, he like very strongly states that, let me pull a direct quote. " React is a legacy technology, but it continues to appear in Greenfield projects. In short, nobody should start a new project in the 2020s based on React. Full stop." That is uh, not something I'd agree with. Strongly stated. [46:57]

Mo Khazali: reading the About Me page, and Alex Russell, I didn't know this, works at Microsoft. And he's a partner project manager on the Edge team. [47:05]

Mark Erikson: he was previously at Google and he also basically invented like two thirds of what we now know as the web component spec as well. I. [47:11]

Mo Khazali: Yeah, I wonder how Microsoft feels about these stances. all of these posts are, these are not my, you know, employer's opinions. These are endorsed by no one except me. [47:22]

Carl Vitullo: I randomly, I was just trying to refresh my memory on who Alex Russell is. Cause I, I recognize his name, I know his Twitter handle is slightly late, and I have seen him for years, as like, somebody in the ecosystem. So I was just trying to refresh my memory more specifically, and I quickly found A random Hacker News comment that describes him as early member of the Chrome team, three time elected member to the W3C from 2013 to 2019, and representative of TC39 from 2006 to 2017. [47:52]

this is from two years ago, and it says, Lately, he's been very critical of single page apps in React, going as far as to call the past ten years a lost decade. guess he's been on this for a minute, but has some, like, Drawing deep credentials to, on, you know, web technologies. So, interesting. [48:08]

Curious. But if he's on, if he's coming at this from a web components perspective, that adds a lot of color to my understanding of the situation and his arguments. [48:19]

Mark Erikson: my take on it is like, he, he absolutely has the technical credentials to back up most of his opinions as well as statistics on like how bad, I mean, like many website bundles actually are like, he's not wrong about that, but he then goes from that to say that anyone using react is doing it wrong. Basically any single page app is wrong and the people who push react have been doing so with malicious intent from day one. Which is way over the line. [48:49]

Carl Vitullo: Yeah, I'm gonna, I would disagree strongly with that. I feel like in, I feel like I can understand his macro perspective there, cause like, I have used a lot of like news websites that are like clearly using React very badly. It has been, it has been put in a lot of contexts that I don't know that it was the best tool for the job, because it was a popular tool that was easy to hire for. So I guess I can empathize with the perspective a little bit, but, I don't know, the nuance there, I feel like there's more nuance [49:18]

Mark Erikson: no nuance, and that's the issue. [49:20]

Mo Khazali: Well, just to go a little bit more into this. I just read his Rebuttal to if someone says, well, what about React Native? And I'm just going to read this verbatim. "React Native is a good way to make slow apps that require constant hand tuning and an excellent way to make a terrible website. It has also been abandoned by its poster child, [referring to Airbnb]". And then he goes on to suggest that you should use Capacitor and Cordova instead. Cordova is The poster child of making awful applications. [49:47]

Carl Vitullo: everything he just said applies way more to Cordova than to React Native. [49:51]

Mo Khazali: yeah, his, he seems to be pushing you to make web apps and use those on mobile with responsiveness. So I've at least on the native side, I think his opinions are incredibly unvalidated. He's probably has more credentials on the web, but that is a bizarre take to then go and say Capacitor and Cordova are better options. [50:10]

Carl Vitullo: Oh yeah, yeah, definitely agree with that one. [50:13]

Mark Erikson: Moving right along. [50:14]

Vitest vs. Jest

Carl Vitullo: Great post titled Vitest vs Jest. I think this is Very needed. I think this is a great post. Just it starts with like just like a raw feature comparison comparing what does Vitest support and what does Jest support. And just goes into a bit of like a oral history of like, why did Jest appear? Why did it succeed? always appreciate some oral histories. I think it's really useful to understand how things came about. [50:41]

Like I remember when ultimately Jest succeeded because it got open sourced. Also by Meta right, like within six months after React came on the scene. So like people had started using React, people had started using all of the everything Facebook was putting out, Facebook at the time was putting out React and Flux and then like, Oh sure, Jest. [51:06]

So it definitely got a huge, huge, huge boost by the timing of its open source release. I never really got a ton of professional experience using other tools like Mocha or Chai and all of those. I don't really know what the comparison is from my perspective like functionality wise they all seemed about the same and But I don't know I used Jest because I was early in my career and I didn't have opinions and it seemed popular So why not? [51:31]

Yeah, over the years definitely it became It, it became not a preferred tool of mine because I found myself needing to maintain parallel bundle configurations for, a production build, and then for Jest, and then for like end to end testing, and then, and so it's just like, it just became like one more target that made upgrading instance, like, new webpack or new, I don't know, any new core technology, I found updating Jest was just a huge pain in the butt. [52:03]

So it became not my preferred tool for that reason. And Vitest seems to be a little bit better about that, but But I have not had that same professional experience of, I'm on a team with 15 other engineers trying to update a core technology without breaking everything or stopping work. So that's really the litmus test for me on a tool like Vitest or Jest. [52:23]

And I've had negative experiences with Jest and no experiences with Vitest. Ergo, Vitest is obviously better. But [52:29]

Aiden Bai “render-shaming” sites while working on React Scan

Mark Erikson: there's a young engineer named Aiden Bai, who I, I think is, I could be wrong on this, might not even be 20 years old yet. But he's the creator of a tool called Million. js, which is kind of like a, almost like a proto version of React compiler where you could isolate parts of your component tree and it would optimize like the text updates in there. [52:50]

And he's since gone on and been working on a bunch of other React related performance tools. Some of them have been branded with Million as well. I think there's a like a million lint and like a a million VS code extension that try to highlight some React performance issues. But he's working on a tool called React Scan, and it loosely put pretends to be the React DevTools in the browser in order to get access to React saying, I just got done rendering, here's the new component tree. [53:24]

And he's been advertising this with a tweets that are kind of render shaming. Sites like he did one where he pointed out that like typing in a search input in Twitter Makes basically every component on the page Rerender and those naturally got a lot of circulation and stuff going around So he called out a number of sites that way And it's, it's both really, really clever marketing, as well as, you know, a bit of an example of ways that React does not necessarily lead to a pit of success kind of a thing you know, just because of, you know, React's default render behavior. [54:07]

I've very briefly dug, you know, dug into the source code just enough to see that that's how it's hooking into React's updates. I've not tried to go through the code and see how the rest of the analysis is implemented. But this feels very similar in spirit to some of the work I've done at Replay over the last couple years. [54:24]

So I, I always approve of people digging inside React's internals in ways they're not supposed to. [54:28]

Carl Vitullo: Yeah, I small reaction. I saw one of the site, one of the render shaming tweets he put out was about GitHub. [54:35]

Mark Erikson: The list view that is used to render source code was re rendering all the list items every time you scrolled. And so, scrolling performance was relatively bad. And he tweeted it, tagged someone at GitHub, and they did actually fix it like a day or so later. [54:53]

Carl Vitullo: yeah, that's worse than I was thinking. I thought it was uh, something about typing, but scrolling, ooh, rendering every line of code on a diff while scrolling. Yeah. That's, that's, that's not going to do good things. [55:03]

Mark Erikson: it's virtualized, so like it wasn't rendering like 50, 000 lines of code at once. But even just what was on screen could be, you know, relatively slow. [55:14]

Lenz’s Weber’s testing-library/react-render-stream-testing-library

Mark Erikson: And then the last one plug for a friend uh, Lenz Weber is co maintainer of Redux Toolkit and works on Apollo Client. And he'd been putting in a ton of work to try to write tests for Apollo in conjunction with React Suspense and ran into all kinds of problems. And this is one of those things that is, it's a library maintainer problem. [55:36]

This is not an app developer. But, you know, like we've, we've had lots of tests in the React Redux code base over the years that say, okay, I'm going to render a component, do an update. And I expect React will have re rendered this many times in the process. And as React's internal behavior changed over time, we kept having to go in and tweak those assertions, you know, like when, when React 18 switched to batching by default, like the number of render counts changed in a lot of our tests. [56:07]

And in fact, at one point we had to say, like, if it's 17, then we expect that this test will render four times. If it's 18, we expect it'll render three times, et cetera. So like, this is not the kind of thing that an application test would need to care about, but a lot of library tests needed to care about this thing. [56:26]

And, you know, we always implemented it with basically. You know, having a, having a variable outside a component, the components defined inside the test and you count how many times it rendered. So in the process of working on the test for Apollo, Lens came up with a new approach, which he's called the React Render Stream Testing Library, and it actually got included in the testing library. [56:52]

organization, part of the, like the RTL group that we all know and love. And this takes a different approach where it actually kind of buffers up all the renders that occurred. And then you can say, okay, give me almost like a wrapper for the contents of the next render in the sequence. [57:12]

And then let me write assertions against the contents of the DOM as it happened in that render. So you're still doing the usual testing library approach of, like, let me look for a button, let me, you know, assert that certain text is on screen. But rather than kind of conceptually testing it against a, quote, live version of the DOM, You're asking for a series of snapshots of it, and this library does the work of kind of buffering those, and then you can just sort of take the next one, do some assertions, take the next one, do some assertions. [57:47]

I actually tried making use of this in a test with Redux Toolkit the other day. And it required a bit of a mental model shift to try to use it that way, but it actually ended up being much more consistent, and like, I didn't have to write any waitfors, because it wasn't timing based anymore. So, again, if you're not writing libraries, you probably don't need this, but if you are writing libraries, this might be useful. [58:13]

Outro

Carl Vitullo: All right. That's all the news we have for you this month, this year. Woo! Thanks for joining us. We will be back next month on the last Wednesday of January here in the live stage, or back in your podcast feed just as soon as we can. [58:28]

Mark Erikson: And Mo was worried we wouldn't have enough to talk about. [58:31]

Carl Vitullo: Haha, it's gonna be a short episode. [58:32]

Well, [58:33]

Mark Erikson: all. Yeah look forward to talking with you folks next month, and enjoy the break, everybody. [58:39]

Carl Vitullo: yeah. Happy holidays. [58:40]

Mo Khazali: Always a pleasure. Hope everyone has a lovely time off, and enjoys the festivities, and uh, looking forward to what next year's got in store for us. [58:48]

Carl Vitullo: 2024 was good to you. Good to you all. It was good to me. It's been a, it's been a weird year for me, but a good one. Yeah, end of episode. Personal updates. this has been the first year of my life when I accepted for myself that I'm queer. I'm not straight. It's been a good year for me, I hope it's been a good year for you. [59:06]

Thanks so much. We gather sources from This Week in React, Bytes. dev, React Status, Next. js Weekly, our React. js, the subreddit, here in Reactaflux, and direct from those publishing articles. If you see anything newsworthy, definitely let us know at hello at reactaflux. [59:21]

com. Bye! I read every email that comes in, even the spam, so send me an email. I'll check it out. If this is a show you get value from and want to support, the best way you can do so is by submitting a review wherever you listen, and by telling your friends and co workers about it. Cheers. Thanks for listening.

TMiR 2024-11: React 19 is unblocked, Next 15 is 'stable', Expo launch week. The cool kids are on BlueSky

Reactiflux — Tue, 26 Nov 2024 16:00:00 GMT

[01:35] Job market: FRED data, Layoffs.fyi
New releases
- [01:51] VSCode 1.95
- [02:20] Node v23
- [04:12] Docusaurus 3.6
- [04:40] React Navigation 7.0
- [04:46] better-auth v1.0
- [05:06] Mantine v7.14.0
- [05:14] Storybook 8.4
- [05:22] Gatsby v5.14
- [05:34] Rspack 1.1
- [05:39] Angular beat React to v19
[05:57] Conferences
- [06:06] React Day Berlin Berlin, DE Dec 13 & 16
[07:39] Main Content
- [07:39] React 19 RC1
  - [08:17] Tech writeup of a solution to the sibling rendering issue that delayed React 19’s release
- [11:27] Next.js 15
- [15:25] TS 5.7
- [19:48] React Router v7 | Remix
- [24:28] Vite v6
  - [24:50] Environment API
- [27:52] Expo Launch Party
- [40:10] New CSS
  - [40:14] A Friendly Introduction to Container Queries
    
    [41:05] A Framework for Evaluating Browser Support
  - [43:48] State of CSS 2024
- [47:02] Framework betas:
  - [47:08] RSC in Expo Router is now in Beta!
  - [47:29] TanStack Start beta
- [49:14] React Native 0.77 RC0
- [50:02] New List dropped in React Native
- [51:45] Twitter -> Bluesky migration
  - [54:54] ericclemmons/awesome-starter-packs, stevendborrelli/bluesky-tech-starter-packs, A complete guide to Bluesky 🦋
  - [55:13] Technical debate over how “decentralized” Bluesky actually is.
  - [55:57] Web Without Walls | React Universe Conf 2024
[59:03] ⚡ Lightning round ⚡
- [59:06] Deno v. Oracle: Canceling the JavaScript Trademark
- [59:27] Two ways to the two Reacts
- [59:52] That's not an abstraction, that's just a layer of indirection
  - [01:00:04] React Anti-Pattern: Stop Passing Setters Down the Components Tree
- [01:00:31] What is HTTP/3?
- [01:01:03] Leaked Vercel v0 system prompts
- [01:01:59] React Scan to highlight component renders (by the author of Million.js), which he used to point out Github’s code view re-rendering on every scroll
- [01:02:56] What’s Next for the React Compiler?
- [01:03:14] Framer Motion spinning out as an OSS tool (Motion), and conversely GSAP is joining WebFlow

Carl: Hello everyone. Thank you for joining us for October's This Month in React, where we recap and digest the recent developments in the ever evolving React and web ecosystem come and do live out of Reactiflux, the place for professional React developers and supported by Infinite Red a React Native consultancy, but more about them later. [00:18]

I'm Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs like events like this. And build some tools to help keep the community operating smoothly. [00:31]

Mark: I'm Mark. My day job is working at Replay, which is a time traveling debugger for JavaScript, and outside of that I do way too much Redux stuff. [00:38]

Mo: And I am Mo. I head the mobile team at Theodo. I am an active, semi active part of the React Native community. And I organize the React Native London conference and the meetups and sometimes dabble in open source with libraries like Expo and Tamagui. [00:54]

Mark: If you're only semi active, what qualifies as active? [00:57]

Mo: I don't know. I, I feel like I'm less active than I was a few months ago. Maybe I just need to take a little bit of a break and become reactive. [01:05]

Mark: You just ran a conference! [01:07]

Mo: Yeah, maybe that's taking most of my energy out of my sails. [01:10]

Carl: Yeah, right. I think organizing a conference gives you a little bit of a pass on other contributions. That's a lot. That was a [01:16]

Mo: Yeah, it was it was a fun time. Intense, but fun time. [01:19]

Carl: All right. Jumping into some quick hits. I'm gonna change up the format a little bit. The last couple months we've had so many new releases that new releases are just mostly part of the content now. But I'm gonna run through some quick new releases with like, no discussion. Just like, this is out, go check it out if you want. If it's relevant to your life. [01:35]

Job market: FRED data, Layoffs.fyi

Carl: But job market stuff looks pretty steady state compared to last month. Like, layoffs. 23andMe has laid off a couple of folks. But, generally seems to be pretty stable again. not much to say there. Okay. [01:50]

New releases, lightning mode. [01:51]

VSCode 1.95

Carl: VS Code they released like every, I don't know, six weeks, something like that. They've got VS Code 1. 95, which mostly looks like it brings out co pilot things. thing that caught my eye the most was you can add multiple files to like a working set, they call it, in the co pilot AI assistant stuff. [02:10]

So that seems kind of neat. I haven't used the copilot very much, but being able to say, here are the files that are relevant. Please do this for me. That seems neat. That seems cool. [02:20]

Node v23

Carl: There is a new version of Node, Node 23 Which means Node 22 is now LTS Two things caught my eye that seemed neat Biggest one is they now have native support for loading ES modules using Require. [02:37]

this seems like a huge compatibility bridge between common JS and ESM, which has been a pain point for like five years, literally since the ES modules were released. So that's cool. It's been experimental for a long time and is now no longer experimental. It's just stable. So that's cool. [02:54]

They also added a native, flag to node, the node executable to run your package. JSON scripts. So no longer do you have to do NPM run. Now you can do node dash dash run. Which is just kind of cool. that was like a weird coupling between NPM and node. So like moving that into the runtime just kind of makes sense to me. So cool. Just especially while we have more variation in like runtimes and, Package management [03:19]

Carl: tools and whatever. [03:20]

Mark: I agree that Node having support for being able to use require to pull ESM modules into CommonJS a huge thing. I think you could do it the other way around where you could import CJS files, apparently. I'm still hazy on that one. But in general, the interop panes between ESM and CommonJS in Node have been the big barrier and reason why package maintainers like myself have had to go through shenanigans trying to get our packages defined and published properly with multiple different artifacts inside. [03:58]

As always, the fact that a new version of Node. js has support for this doesn't mean we'll be able to drop that immediately because, you know, the long tail but at least it's a step in the right direction. [04:12]

Docusaurus 3.6

Carl: DocuSource put out 3. 6. It's faster apparently. Seems good. [04:16]

Mark: Apparently that's because they did switch from using Webpack to using RSPack, which is, it's effectively Webpack. But rebuilt in Rust, so it's like public API compatible. So, an example of a migration path to get faster build tools without having to sort of switch which build tool ecosystem you're in. [04:40]

Carl: React Navigation put out version 7 if you're in React Native World. [04:46]

better-auth v1.0

Carl: A project I've mentioned at least once on this show for authentication, BetterAuth, is at 1. 0. They've been doing a really fast, rapid release cycle, I've noticed. like, last month they were on version, 0. 6 and then they did, like, 0. 0. 9, and now 1. 0. So, cool. Seems good. Love authentication. And it seems like a good project for it. [05:06]

Mantine v7.14.0

Carl: Mantine put out version 7. 14. Seems like a decent UI toolkit. [05:14]

Storybook 8.4

Carl: Storybook has 8. 4. I have opinions about Storybook. I don't use it. But hey, if you do, they are talking more about like testing and stuff. [05:22]

Gatsby v5.14

Carl: Throwback Gatsby released version 5. 14. It's out. [05:28]

Mark: genuinely surprised anyone's still working on it. [05:30]

Carl: Gatsby is still here. It still exists. Me too, a little bit, [05:34]

Rspack 1.1

Carl: RSPack put out 1. 1. We talked about version 1 release Recently. [05:39]

Angular beat React to v19

Carl: And amusingly, Angular has released version 19, beating React to the punch. Nothing that means anything, but yeah, well, Angular's got a new major version out. [05:50]

I saw they're looking to revise their style guide, which is apparently 52 pages long currently. So that's ridiculous. [05:57]

Conferences

Carl: Yeah, conferences. Mo, you wanna talk? [06:00]

Mo: Yeah, sure. So, we're reaching the end of the year, which means conferences are going into hibernation mode as expected. [06:06]

React Day Berlin

Mo: But we've got one more left for you all this year, React Day Berlin. And React Day Berlin happens in December every year. It's a really cool gathering of people. I was there last year and I'll be doing a talk this year with a friend of mine from Amazon, Anisha Malde, about universal React, so it's a, it's a great of React people. [06:25]

They have a really cool venue called Cosmos It's a really historical city. If you're in Europe, I'd recommend you come around. It's, it's a good time. [06:32]

Carl: And it's on my birthday, so I'm not going. [06:34]

Mo: Happy birthday, Carl. Early birthday. Very early birthday. [06:38]

Sponsored by Infinite Red

Carl: All right, sponsor time. We are sponsored currently exclusively by Infinite Red. They're an expert React Native consultancy that's been around since 2015. Coming up on 10 years, wild. They're our only sponsor in part because very few companies do as much as they do for the React Native ecosystem. [06:55]

And so just really happy to be a part of it. Have a earnest collaborator in that kind of way. Yeah, I've seen their name around for as long as I've heard about React Native being used professionally. They only do React Native and have built over 75 apps for companies from startups to like the biggest fortune, whatever companies in the world. [07:13]

than being great people who I'm happy to collaborate with, be sponsored by they're a team of about 30, mostly developers, mostly with more than 10 years of experience. And they work alongside your team to help you develop expertise in React Native. So if you are working for a company, spinning up a new product with React Native, and want to hit the ground running, definitely give them a ring. [07:36]

Infinite. red is the website. Cool, all right, [07:39]

Main content React 19 RC1

Mark: so we actually have a very, very big Big development if you've been paying attention the last few months, we've been tracking that the React 19 release has got delayed because of concerns over changes to suspense behavior when multiple sibling components all want to suspend you know, the change had been made last fall, the community pointed out problems with it, Back in the spring, and the React team said okay, fine, we'll hold on React 19 until we can come up with a solution for this issue. Well, the good news is, that fix is actually done and out as a new React 19 RC. [08:17]

Tech writeup of a solution to the sibling rendering issue that delayed React 19’s release

Mark: And the React team put together a very good visual and technical explanation of what they changed and how the behavior works. They're in the GitHub issue link, so I highly recommend taking a look at that. Big picture is that the original behavior as of 18, if you had multiple sibling components that all wanted to suspend, was it kind of acted like a promise. [08:40]

all, Where, in one render pass, it would kick off all of them, wait for them all to complete, and then actually show the content. The change that effectively broke things was it would render the first child that's suspended, see it, and say, oh, wait, let's wait for that one to complete, then pick up with the siblings, making it more like a serial for loop. [09:05]

And the new behavior is when that first child suspends, It will go ahead and show the fallback, but it will kick off kind of a pre warming step in the background. So like, not like a complete render, but I guess kind of like a partial render, enough to kick off the requests. So that at least the other requests are in flight right away. [09:29]

And so the overall behavior should be at least as good as it originally was, if not maybe actually kind of better. In, in some certain ways. So the two key takeaways here are that the, you know, the suspense behavior that people were concerned about has been addressed. It did take them a few months, but they, they did it in a comprehensive way, not just slapping in a bug fix. [09:52]

And also that hopefully React 19 final is very, very close. There's still no specific timeline, but they did make the comment that we hope to publish 19 stable. Boy, [10:03]

Carl: Yeah, and just maybe to restate what you were saying in different words, so my understanding of like the problem that they introduced and why they introduced it is Like you said previously, it was just sort of rendering all of the siblings before it handled the suspense. [10:18]

And that was undesirable because it introduced latency before the fallback would be rendered. It did a bunch of work before showing the fallback. So they wanted to change it so that the fallback would be shown quicker, but caused requests to behave as a waterfall rather than kicking off in parallel. [10:36]

It would kind of waterfall shape of your component tree. If you had requests being kicked off by like child components and sibling components and stuff and so now they managed to find like a happy balance where they don't do all of the work of rendering, you know doing the I'm fuzzy on the terminology around like commits and rendering and all that so I can't speak to precisely there [11:00]

Mark: someone had a blog post that explained these things. [11:03]

Carl: I read that but many moons ago, yeah, so it's a nice Midpoint between what it used to do and what they wanted it to do and now it works correctly. [11:13]

So yeah, They delayed it back in June and they now have a fix So, you know, only a couple of months delayed. It's only all year that we've been talking about React 19. So maybe it'll be released soon. moving on. [11:27]

Next.js 15

Carl: Next. js has version 15, out and stable. You know, they call it out and stable, but I don't know, it's stable version is like using of the big changes is using like React 19. RC in the apps router, the app router. And so that still feels to me like the proving ground for React 19. [11:50]

So calling Next. js 15 stable when it's recommending that you use an unstable version of React feels funky to me. Feels like a, like a workaround to the problem of people don't test, you know, release candidates, so they're just going to call it stable. [12:06]

But yeah, I'm not sure that I personally would base a production system off of the app router in Next 15 because it just, because of that, it feels like a beta, beta is maybe too strong, but it feels like they're still exploring. claim it's stable, I don't know what sort of underlying technical issues might cause things to have to be changed. [12:27]

Mark: This touches on multiple different aspects that we've talked, at least I think we've talked about previously. One is that, you know, especially with all the server component stuff, the React team used to be able to, pre alpha test all their ideas internally at Facebook, but they can't do that with server components because it relies on having a separate server, and Facebook has all their own server, which is one of the reasons they ended up collaborating with Vercel. [12:55]

To be like, they convinced Vercell to go with their vision, but also it conveniently aligned with, we need someone who doesn't have Facebook server infra to let us build out server components and prove that it works. Along with that the app router has always used a pre release version of react. [13:14]

Like this. Like, even before they came up with the Canary system, it was using, assorted, experimental, unstable builds. And so, haven't been keeping track of which version specifically, but, I would assume that over the last year, versions of Next 14 have been using, you know, React 19 Canaries, betas, RCs. [13:36]

So, if anything, it's, More stable now than it was a year ago. But part of the point was that, the App Writer needs all this new functionality in 19 in order to work. And the whole point of the Canary system was that, well, even if it's not fully 100 percent stable stable as a standalone release, frameworks like Next are able to paper over the rough edges so that from their point of view and from the consumer's point of view, It's stable. [14:05]

So, I agree that the versioning system is funky, but it's also not a new thing. [14:10]

Carl: Right. Definitely not new for sure. But yeah, if you're doing a little side project, probably fun to play with. If you're a founding engineer at a new company, I'm not sure I would start a new thing on it. It's not sure I would start a new revenue generating entity on it. [14:25]

So, yeah, one new thing that they introduced is an instrumentation. js file, hook, I don't know. It's a place where you can plug in to the core, like, network level of the system. Next. js for things like observability and monitoring. [14:43]

So that seems pretty cool. I think that is one of those like quiet underrated things that every app needs and that is not always super easy to figure out how to fit it in. In the past, I have done a fetch wrapper that introduced things like performance metrics and observability and stuff. So just having that as like a a framework feature in Next. Makes a lot of sense to me. Glad to see it. [15:07]

They also put out a, a form component, which seems like it overlaps with like the native behavior that the native form enhancements that React 19 is introducing, so I'm a little bit fuzzy on like what that abstraction is super duper for, but yeah, it's there. [15:22]

Cool. On to TypeScript. [15:25]

TS 5.7

Mark: So, the TypeScript release chain also keeps chugging along. I think they do releases every two or three months. And so we're now up to TypeScript 5. 7. There are a couple nice to haves, like checking for variables that never got initialized, like borderline winter. Related stuff, but at the types level. The, the interesting thing from an ecosystem perspective the story around, you know, how TypeScript interacts with module output and file paths has always been very complicated, because it's always been very complicated at the JavaScript level. [16:00]

And one of the things that had been kind of a pain point, weird point, frustration thing was that even when you were writing, like, Writing TypeScript files in order for some ES module, you know, import behavior to work properly, your imports still had to say you were importing from a js file in the import path. [16:25]

And that always felt really weird. It's like, yes, I realized that's what is actually executing at runtime and that the build output is a bunch of js files, but the file name I'm, but with the file that I'm writing this in is a ts file. Like this, this doesn't make sense. This is weird. I don't want to have to do this. [16:45]

And the TS team had resisted trying to make changes here because after the first couple of years of doing TypeScript features that required actual separate output, like enums, they're now very much on board with like, we are a superset of the JavaScript language and the compiler doesn't do anything to have to rewrite the actual behavior of your code. [17:11]

But they appear to have actually added a mode that will change import path names. So when you have an import that says import from something. ts If this flag is enabled, it will rewrite that to say import something from a js. It only does this in certain conditions where it's a relative path and not, and not a, like a globally scoped path. [17:41]

I, I don't pretend to understand the rationales behind it. I'm mostly just going off the release notes here. So, it seems like a rather grudging Decision to tweak things in favor of better ecosystem interop. [17:54]

Carl: this feels very much like stuck between a rock and a hard place in that, like, Now there are more and more ways to run your TypeScript code without doing a full compilation pass, sending it fully through the TypeScript compiler, TSC, It's an intersection of like, there are more ways to run your code without fully compiling it and executing the built output. And there are more ways to, or rather, imports are getting stricter about file extensions and just like, Ooh, oh no, what do you do with that? Those are like incompatible assumptions. [18:29]

this seems, I agree, this seems like a grudging, I don't know if I want to call it a hack fix or a band aid or something, but like, just even as they're talking about it in the release notes, it's, I feel like I can sense their trepidation and like angst over, like, you know, like a quote from it is like, you might need to use conditional exports with scoped custom conditions to make this work for like absolute paths, like if you're using, you know, your TS config to, you know, import, you know, structure and not use relative paths and it's just like, Oh no, that's [18:59]

Mark: so thrilling, [19:01]

Carl: Right! [19:01]

It's like, oh god, that's, this sounds like a whole new problem. they're trying to fix a problem. They may introduce more problems. I think this is going to be painful for a long time. [19:11]

Mark: but it's there. If you feel you need this. [19:14]

Carl: maybe you do. Yeah, I don't know. Anyway, seems, seems rough. V8 introduced compile caching, which allows runtimes to reuse some of the like JIT compilation steps. So TypeScript is taking advantage of that new V8 feature to improve its startup time. They talked about, you know, if you do like TSC dash dash version, it now prints faster. [19:38]

So like, that's cool. That's nice. Startup time is definitely a pain point for Node generally, JavaScript generally. And that's nice. Less latency. [19:48]

React Router v7 | Remix

Carl: Cool, okay, moving on. React Router v7 slash, you know, the one with Remix. headline, big pull quote, " We encourage all Remix v2 users to upgrade to React Router v7." This seems really neat. I want to play more with this, but I think really playing with it is going to take a lot. I have an app in mind that I want to try and move over. [20:12]

It's currently using Remix 1, so I can upgrade to 2 and then upgrade to React Router 7. Woo! Multistage upgrades. Yeah, the big highlight here, I guess, is that Essentially, I think my mental model for understanding this change, you know, Remix to React Router is what was Remix is now Framework Mode in React Router. [20:34]

So you can still use React Router as you always have, as just like a library. Or you can use it in Framework Mode, which has a Vite plugin to get more control over, you know, the build step, the compilation, which is what used to be Remix. So it feels like they explored a lot of like API surface area. [20:55]

Like, how do we fix this? How do we make this work correctly as we want it to with Remix? And then it feels like they got it, they got it where they want, they refined it to where it was just kind of an abstraction over existing build tools. Like that was the big push to not have like, you don't interact with Remix, you interact with Vite and there's a plugin that is Remix. [21:15]

And so now this feels like the next logical step there where like it is truly just an agglomeration of existing tools that you can choose how to use in the way you want. I think that's pretty neat. That seems pretty cool. I definitely want to play with this a lot more. [21:27]

Mark: as I roughly understand the sequencing, so Remix itself was originally based on ESBuild, and there was no way to really mess with that configuration. Then they managed to come up with a Vite plugin, which did the same thing. And then the Vite plugin, I guess, became the default way to use Remix. [21:44]

And now that it's like, well, at this point, there actually isn't much left that's specific to Remix the framework. It's all in the plugin. And so that enabled them to help take some of this, and take basically all this functionality, back into React Router, the library. And so as you said, there's the client side piece, which has always been there, and then it's like, well, all this stuff that used to be server related, and used to be specific to the Remix framework, is now encapsulated in the Vite plugin, so it's just there if you want to use it. [22:14]

Mo: I mean, it's quite interesting because I feel like this idea of, frameworks being almost add ons or plugins to the bundler, whether it's Vite, I guess I've seen this with Vite only, is quite an interesting premise and I think it's picking up a little bit, maybe almost as a response to how Next. js is such like a, tightly It's not proprietary, but proprietary like piece of software where you're like really buying into Next rather than buying into the tools that are, you know, underlying Next. [22:43]

And I see that with the new React Native Framework One as well, where it's really kind of, it's a Vite plugin. Everything's on Vite and we're building on top of Vite and we have some extra functionalities that comes out if you want to use it as kind of a framework. So it's interesting to see how this shift from the Remix team has had, I think, probably reverberations across to other, parts of the ecosystem. [23:04]

I guess the question that I still have is, why have they done this from a branding perspective? Like, it seems like a lot of brand capital that they probably had in Remix Is, kind of disappearing by going into React Router. Now you could argue whether or not that's good brand capital or not, because Remix has had its fair share of controversies. [23:22]

it's an interesting move for me. [23:24]

Carl: I would raise, as a counterpoint, That they already captured the brand value because they sold Remix to Shopify, [23:31]

Mo: It's a monetary brand value rather than anything else. Like a monetary for acquisition brand value. [23:36]

Carl: I think there's a decent argument to be made there. but also like react router has been Around for like 12 years 11 years Literally, like, the original way of doing routing in React. So it kind of makes sense to me to say like, Look, we solved this problem. [23:54]

I have been watching them try to figure out where the boundaries are between routing and, like, server and, they've been trying to figure out how to do data loading and, bundle splitting at the router level. For that entire time. So it feels to me like they spun up a new brand to do more experimentation and now got there and then folded it back into the original tool that they've been trying to solve this in forever. [24:20]

Mo: the process got acquired, which is a nice payout as well. [24:24]

Carl: great bonus. Yeah. [24:25]

Mo: Yeah, makes sense. [24:27]

Carl: Speaking of Vite. [24:28]

Vite v6

Mark: So associated with that Vite version six just came out. And it's interesting because they've tagged it as the most significant release since Vite 2. And yet I was looking through the announcement and the migration guide, and it looks like there isn't a lot that really feels user facing in terms of features and changes. [24:50]

Environment API

Mark: Best as I can tell, a lot of this one is on the inside, and it looks like they did a lot of major refactoring internally to enable what they're calling the Environment API. And as I understand it, the idea is that because JavaScript these days is used in so many different ways, it's used in the browser, it's used in Node, in Deno, in Bun, in worker runtimes, that may have differing constraints. [25:18]

It seems that the environment API is going to allow you to generate build output targeted for different environments based on certain definitions. I'm still kind of hazy on that part myself. I have seen a number of mentions that things like some of the other, Framework level Vite wrappers are going to benefit from having the environment API available. [25:45]

So, seen some mentions here, I don't quite know how all the pieces connect. general takeaway is like, it seems like, a fairly easy upgrade. saw a couple people on Reddit say like, yeah, I just like bumped the version and it just worked. So it might not have an immediate benefit for an application in terms of speed or build output per se, but it does seem like it's fairly foundational for a lot of the framework level stuff that's going on in the ecosystem. [26:12]

Carl: Yeah, we definitely agree with that. I've encountered a little bit of that environment pain. Not using Vite, but just like trying to use Cloudflare workers. Trying to do, a worker serverless type of architecture. Definitely can tell that it is, Like bleeding edge of the ecosystem and a lot of the existing tooling is just like not well suited to support it precisely. [26:37]

Yeah, just like having an existing, like daemon, existing process that is long lived. It's just a very different set of constraints from a short lived process that Handles a request and shuts down. So, Remember the era of the, of the acronym for rendering? SSG and SSR and ISR and S So, I feel like this environment API to me, it feels like a reaction to that, of like, look, we have all of these contexts in which web pages are being rendered and used. [27:08]

And we don't even have a language to talk about it. I guess Vite has, spent most of the version five release iterating on what has then turned into this environment API. It sounds like they introduced it as. Something else the runtime API in 5. 1 and iterated on it, iterated on it, realized that what they landed on was different enough from that, that they just came up with a new name for it and put out a major release. So yeah, definitely looks interesting and valuable. [27:38]

And yeah, given how Vite seems to be like the common building block that everyone else is starting to rely on, here for it. This seems like the kind of exploration that is super, super valuable, especially given that place in the ecosystem. [27:51]

Mark: Definitely. [27:52]

Expo Launch Party

Mo: yeah, let's move on to some React Native land. And interestingly so, towards the end of November, we've had Expo's launch week. This is where Expo kind of bundle a bunch of the stuff that they've been working on and launch it in one go over a few days. it's been quite interesting to see some of the stuff that's been coming off. [28:10]

Nothing is particularly a big surprise but it's interesting to see the culmination of some of the stuff being released out to the public. So, I'll go through some of this bit by bit, and we'll talk through it. [28:19]

The magic of Expo DOM Components

Mo: So, the biggest thing that the Expo team has been talking about over the last few months, I'd say, is DOM components. [28:26]

This idea of how uh, Can we make it super easy to run web based DOM elements inside of a native app without turning the entire app into a Cordova Ionic sort of web view based app? this is controversial at the best of times, I think, right now. A lot of people seem to really like it. [28:44]

There's some people who feel like it's kind of a step I think the expo team is trying to take this pragmatic approach of, a lot of people have React web apps, how do we kind of get them to migrate incrementally and introduce them into the React native ecosystem. So, The article that we've linked has some interesting use cases. It kind of looks at the integration of, you know, you still, if you have a WebView based app, maybe there's some cases where you still want to introduce some native functionality. [29:11]

So, you know, you press a button, maybe you still want to have a haptic on the native device. So how do you integrate those things together? And make it kind of feel native in some capacity. So it talks about some of that, some of the patterns that you want, and some use cases. So some of the things that have been really difficult to do in React Native is things like displaying markdown. [29:28]

Markdown, you know, you have to create your own renderer with native components for it. And it's a lot of work to do that natively. Anyone who's done that will kind of attest to that. And Stuff like that gets really easy because it's a solved problem in the web world. So, they're kind of not saying you should use this for your entire app. [29:44]

They're kind of being very, very, very clear about that. thinking of using that in places as an escape hatch more than anything. [29:51]

Mark: More interop is always a good thing. [29:53]

Mo: yeah, you know, it's good to have that. Now, this isn't something that necessarily is new. Like, you can always use WebViews in React Native. It's been around for probably since the very, very, very early days. [30:03]

It's nothing new. There was always React Native WebView as a library. this is just an easier way and a nicer way to do it. And it uses the favorite directives that everyone has now in the React ecosystem, which is the use directive at the top of the file. And you just pop in a use DOM and it kind of works. [30:18]

I think we're starting to overuse directives. We should probably stop as an ecosystem. It's just getting a bit out of hand, but that's a different conversation for another time. I see Carl passionately nodding at this. Mm [30:30]

Carl: flashbacks to like, I guess it was like ES6 when the use strict directive was introduced. And I just remember the emphatic, you know, like people would say like, Ooh, what if we did this other directive? And I just remember the reaction being like an emphatic, like, No, this is the only directive we're ever going to do. Never again. This is terrible. We should not have had to do this, but we needed to. Never again. [30:53]

And so now seeing like, we got like, what, four or five now in React? And they don't even have the same semantics. Like it used to be only at the top of the file and now it's like top of the source file, which is technically different. Not the, and like some of them are at the tops of functions. It's, it's complicated. It's too much complication. [31:13]

Mo: I tend to agree with you. I quickly want to touch on some of the limitations to dissuade people from trying to use this for their entire app, so I'll just quickly quickfire those. The first thing is that performance is really going to suffer. Because, you know, when you're running a React Native app, it does have a JavaScript engine that uses Hermes under the hood. [31:30]

But for this, you're basically instantiating a new JavaScript engine that will run web code, so that can be JSC on iOS and V8 on Android. And that basically slows down your load time quite significantly. And then if you do want to tackle that, you're probably going to have to have some hacky stuff to preload these components, hide them, and then display them. [31:48]

It becomes a mess. So you really want to use this when you have no other options, or, you know, You have an escape path long term to basically get rid of these, these webviews. And then the other thing here is you have to be very, very clear as to how you handle your navigation. Because the worst thing for a user experience is having multiple layers of navigation. [32:06]

So, you know, you have your stacks and your tabs inside of your native app, and then suddenly someone clicks a button inside of the webview, and it just adds a new screen onto your webview. And so you've got like two or three layers of navigation. It gets messy. Be careful, think about it deeply basically use at your own risk and think about the consequences of your actions. [32:24]

Introducing Workflows: CICD built for your app

Mo: In other things that the Expo team's been launching so Expo launched workflows. This was one of the more surprising things. They hadn't, they kind of kept this under wraps a little bit. But the whole concept with this is so far you know, Expo's got their cloud build tools, EAS build and EAS update. [32:38]

So you can use builds to create your mobile native builds. They've got a submit tool. solution as well, which kind of pushes that thing to the App Store for you on Google Play and Apple App Stores. And they also had an update mechanism, which allowed you to issue over the air updates to your users. [32:52]

Now, this, they never had a workflow or like a proper CICD tool. So you would have to basically almost run your CICD on another cloud or another sort of CICD tool and then call Expose. servers just to trigger the build or trigger the update. So they've kind of created some very basic workflow functionality. [33:11]

It's YAML based. You know, you can run bash commands, you can run NPM commands in it. It has some very basic control flows as well. So if you kind of want to get away from, you know, using GitHub actions for your, for your mobile builds and mobile updates, it's a cool option if you don't want to add that as an extra piece that interacts with Expo. [33:30]

It's something to see how they develop and extend over time. [33:33]

Environment variables in EAS: new changes to simplify setup

Mo: other unexpected, but this is incredibly welcome news they have revamped the way that you handle environment variable handling within Expo. Now this is something that has been a real pain. I think it's the place that the Expo team probably struggled the most to come up with a good and comprehensive solution. [33:52]

Because you've got sort of different layers of environment variables when you're dealing with a mobile app. You have sort of secrets that are stored inside of the app's binary. Then you've got JavaScript based environment variables that anyone can inspect if they go into the JavaScript, so you don't really want to use any secrets or put any secrets within them. [34:10]

Then you've got some stuff for your build processes. So there's sort of these like multiple layers of environment variables and they each had different sort of sensitivities or levels of secrecy that you needed to maintain. And so they've centralized all of this in one place. So EAS can kind of manage all of this for you. [34:26]

And they've tried to centralize this because environment handle, variable handling in Expo was a nightmare. You had to kind of deal with three different environment variables, like working in a consultancy was one of those things that clients would come to us and be like, why is this so hard? And I would be like, I don't know, there's probably should be a solution. [34:43]

One of our clients actually, prior to start a startup, like, like, thought very seriously about starting a startup to solve this problem, and I told them don't, please don't, Expo will probably solve it, and they have. So, it's good. I think it's still to be seen how it bodes in practice, but from first glance, it looks like you kind of define these centralized environments, and they have all of your environment variables in one place managed by Expo, which can make things significantly easier, and you can kind of define the visibility, visibilities as well. [35:08]

So this is very welcome, because I think it's. It's kind of long overdue and it's one of those things that was a big pain point. [35:13]

Carl: I love that. It sounds great. Sounds like a real problem that needs, you know, sounds like an improvement, but I have never worked anywhere that did not have some kind of pain with environment variables, including on my like solo projects, like currently the, you know, the main app that I write code for. As a stupid, terrible environment variable setup, because like, you know, it's CICD with GitHub Actions deploying to a Kubernetes cluster. [35:41]

And so like, I have to take, I can't remember the, I think I put all of the secrets in GitHub. But then they get loaded into GitHub Actions alongside lots of context, build context, that the action provides on its own. And then I have to manually take all of the information that's relevant to the executing code and put that in a secret in Kubernetes and then load that. [36:03]

So, like, I'm glad they're trying to improve it. I also just kind of think dealing with secret data is just a hard problem. So, I suspect this may not be the end of it. [36:13]

Mo: I don't think it's the end of it. If they make it marginally better, especially, I think, I think it kind of ties hand in hand with their workflows functionality because they needed a, you know, solution to environment variables if they're creating almost a CICD. So, I think it's kind of hand in hand with that, but yeah, the exact same problem, right? [36:29]

Like, even if you, before these workflows, what you had was you had the same environment variables, probably in GitHub, and then you had them replicated somewhere in EAS for your builds, and then somewhere else in your, for your updates. Maybe this removes some of that duplication, so at least your client side secrets. are sort of shared by Expo and managed by Expo. I hear your pain with the Kubernetes and backends, like infrastructure environment variables. I've done the exact same thing with GCP and Terraform and trying to manage those and it's not a, it's not a fun ride. [36:58]

Carl: Nope. [36:59]

Expo SDK 52

Mo: Cool, and last but not least, obviously they also released Expo SDK 52. they say that this is their biggest release ever and I kind of believe it because the new architecture is out Cool. So that is a big, big revamp of everything in the internals of React Native, and they obviously manage a massive SDK with a bunch of different libraries. [37:16]

So they've had to make sure all of it is compatible. So far we're hearing about some pains with Expo Go. Some people are having some troubles with Expo Go because it suddenly switched to the new architecture by default. So people are having some upgrades. Issues, but that's to be expected, to be honest, with such a big revamp of the internals and people will need to update their apps. [37:35]

Some interesting highlights, just quickly running through these. Expo Video is a new library that's become stable now. So this is a revamp of the old Expo AV library that handled audio and video. They're splitting these out to Expo Video and Expo Audio. And it comes with a whole bunch of cool stuff. [37:50]

Like, being able to generate thumbnails, being able to have picture in picture and a whole bunch of other stuff which is, is needed to, to kind of play video in a, in a high quality way in native apps. They've also released a beta of Expo Audio, which is, again, a rewrite, and this is great, and hopefully it just becomes a little bit nicer implementation. [38:09]

And then they're releasing a whole bunch of stuff to their file system libraries, their cameras, and so on and so forth, Expo Images getting some updates. So there's a lot of good things. I'm not going to go through all of them because it is a massive changelog. But go and try it out. DOM Components as well, which we mentioned earlier on, is available with Expo SDK 52. [38:25]

So if you want to play around with those DOM Components and figure out how you can integrate WebViews inside of your existing app with DOM Components, go for it. Expo SDK 52 is the place to try it out. [38:36]

Mark: Sounds like a pretty big deal. [38:38]

Mo: Yep. [38:39]

Carl: Maybe one day I'll use Expo. [38:41]

Mo: I'd love to hear your feedback on it, Carl, because it's quite a nice DevEx. I've had people who've, like, have you, you've built for React Native back in the day, right? [38:49]

Carl: Yes. Short answer, yes. [38:51]

Mo: it's usually people who have built with React Native or built native apps before, ages ago, and then they come in and try Expo, and they're like, holy crap, this is something. it has that, like, mind blowing effect, so I'd love for you to try it and then come with your feedback. [39:04]

Carl: I briefly tried Expo like five years ago, [39:08]

Mo: Not the same. yeah, they're totally different, totally different, totally different ecosystem. Yeah. [39:13]

Carl: I remember it had a huge constraint of, it felt a little bit like a create react app in that it did a lot. But if you were building a production app, you were going to have to eject from it sooner or later. And the ejection story sounded pretty rough. [39:28]

Mo: yeah, ejection was not a fun time. they had a lot of, I think that was the biggest, like Expo had almost a dip in reputation and it was because of ejecting. And so they, they completely got rid of ejecting. You don't eject anymore. You can add native dependencies as you wish. And it's a totally different mechanism. [39:42]

So Expo in 2019, 2019. is a very different thing to Expo in 2024. And I'd say they've regained that reputation, which is great. [39:52]

Carl: Cool. Sounds good. Yeah. I guess my, perception way back when was like, this feels like create react app, create react app feels like it's dying. This feels like it might die, but here we are five years later and it is totally transformed. Looks really great. This is definitely what I would, you know, were I to try a native app. I got a long list of other things to do. [40:10]

New CSS

Carl: Cool. Okay moving on. This is slightly unstructured. [40:14]

A Friendly Introduction to Container Queries

Carl: I'm going to frame this conversation around a Josh Kumo article about a friendly introduction to container queries. I don't think I had heard of container queries, but like, I was reading this was like, holy shit, there is so much new CSS stuff that I, that has just not crossed my radar. [40:31]

So container queries are basically media queries, but for the containing element. So you can say all sorts of things. not super duper sure what the support story looks like for them. that's basically why I checked out of paying close attention to CSS news is because it was so much of it is like Chrome only, or, you know, not supported in Firefox or Safari. [40:54]

And so like, stopped paying attention because so many of the things that looked really interesting and neat were not stable. And if a CSS feature is not stable, you can't polyfill it in the same way as JavaScript. Bye. [41:05]

A Framework for Evaluating Browser Support

Mark: Conveniently on that note, Josh also just put out a post that discusses his approach for looking at browser support for various features, CSS or JavaScript, and sort of like his mental model of, how do I decide when a feature works? Might be good for me to actually use in practice. Of course, like it literally, it basically boils down to it depends, but he walks through kind of the process of how he gets to that and the article actually literally starts out according to can I use container queries are supported for almost 93 percent of users. [41:39]

Carl: Right, and I see in the, thumbnail, in the, you know, preview image, is 93 percent good enough? And that was exactly my response to that. So, I don't know. it's a hard thing. [41:47]

so, container queries just caught my eye as like a great Way to do a great enhancement over media queries because media, queries, you can adjust your styling based on, you know, the size of the screen, based on the capabilities of the device, but container queries, it looks like, I don't know the depth of the capabilities, but the most obvious one I'm seeing right here, you know, the first one it shows is, you know, mid width of the containing element and like, that's great. [42:18]

I have had so many responsive. design bugs where, I try to reuse an element in a new context and it's narrower because I wanted to put more elements next to each other or something than I did in the previous one and it looks like with container queries I could Avoid those bugs by saying, if the space this is in is this size, render in this way. Which is a very different, much more powerful method of querying than just the device support. So, yeah, that seems really [42:53]

Mo: I'm curious as to when, I think it's still probably in, experimental phase, but I'd love to see when this becomes available for something like Tailwind. [43:01]

Carl: Right, and it might, I wonder if it would even be like a breaking change. Because they currently have, you know, SM, MD, different size constraints. Thanks. Thanks. And it feels like they might be able to just modify those to be based on the container. [43:16]

Mo: they've done that exact pattern when they like introduced the group functionality. Like, they obviously had like hover, active, focus, or whatever for the different states, and then they just added a group colon active. So I wonder if this becomes like a container dash sm, container dash md, or something like that. [43:31]

Like, that would be consistent in my mind, at least. [43:34]

Mark: quick Google search says that they put out a first party plug in for container queries back in 2022. And there's something involving an at container wrapper on a parent. [43:48]

State of CSS 2024

Carl: I said this is going to be kind of a loosely structured thing, related to this conversation, there was a state of CSS survey, you know, same as state of React, state of JS, whatever, Devographics, Sasha Greif and I was just looking at the list of CSS features and thinking like, wow, I have not used more than half of these. CSS is totally different. And you know, in the introduction to this State of CSS survey shouts out, "let me make a prediction. We'll look back at 2024 as the turning point between CSS classic and new CSS." And that's interesting. I feel I definitely learned and became expert in classic CSS. CSS Classic. [44:31]

Describes as like, the build steps and all of that. I had to learn floats and positioning and box model and I feel like none of those things are super relevant anymore. Now it's grid and flex. And so it's just like a whole new set of Primitives that I have not had professional experience using like oh dang cool. Wow shifting landscape know what? I thought was stable land is now totally different just really [45:01]

Mo: I the one that always, like, that winds me up that I learned about a little while back, that was just like, What? Why does this exist? But it's also very impressive that it exists. Is, like, the mathematical functions that you can use now in, like, CSS for calculating values. Like, power of, square root, logarithms. Like, how do I, what case do I have where I need to, like, calculate a size based off of a logarithm in CSS? Like Cool, I'm glad it exists, but I can never imagine needing to use that. [45:30]

Carl: we do some funny layout logic and on the Reactiflux website. And yeah, you can do that. the font size is based on the viewport width, for instance. [45:41]

Mo: but would you ever use a logarithm based off of that? [45:43]

Carl: Hey, maybe if I wanted to, you know, nonlinear scaling, [45:46]

Mo: Yeah, maybe. Anyway, it's quite cool. [45:48]

Carl: I don't know. Wild. [45:49]

Mark: big picture metaphor. I think what's come into my mind is that it feels like it's a little bit like the ES 2015 spec where you could do a lot of stuff in JavaScript prior to that. And a lot of stuff in ES2015 was effectively syntax sugar for stuff you could do before. But there were also a number of things in ES2015 that required support at the language runtime level, like proxies, that simply could not be done before and enabled virtualization. [46:17]

A whole lot of new functionality from there. So, you know, I, I know that CSS is not like a strictly versioned spec the way that, you know, the JS language is at this point, but I think that's kind of the, the metaphor that we're going for here. [46:31]

Mo: yeah. [46:32]

interesting. Complete side note before we move on, but since we started with this, Josh Comeau his website is like one of the most beautifully designed tech websites I've seen. Like, I say this every time I look at it, I'm like, wow, this is beautiful. He's done a phenomenal job with this website. [46:47]

Mark: Josh is amazingly talented, he is an amazing educator, his blog is wonderful, I can vouch for his courses without having looked at them because I see the care and effort he's put into his blog post. So, highly recommend all of Josh's stuff. [47:00]

Carl: Very, very true. [47:02]

Framework betas:

Mark: Okay, moving on a little more quickly, a couple different frameworks and pieces are in beta. [47:08]

RSC in Expo Router is now in Beta!

Mark: One is that the Expo router now has support for server components. And Mo can probably talk a little bit more about the actual implementation nuances here, but big picture, it's a big deal because it's server components coming out in any framework other than Next, and more specifically within the React Native ecosystem. [47:29]

TanStack Start beta

Mark: And then as sort of an inverse of that, Tanner Linsley's 10 stack start framework is now in beta, and it's a deliberately non server component framework for now. Tanner has said he will look at adding some server component support down the road, but his argument, and he's made BlueSky within the last few days, is that he feels server components are actually of very limited use. [47:59]

and really much less flexible compared to a server function concept architecture for managing data. So he did just do a talk about and kind of advertising some of the features at React Summit New York last week. I looked, if you check out the Git Nation website, the video is available for people who have, you know, paid up for the early access to the videos and it'll go public sometime in the next month. [48:27]

Mo: Just to quickly touch on the exporouter RSC stuff, So it is very much an experimental at this point, it's beta. You can't even host it on a production server, you need to do it locally, so it just means you're basically testing it out in dev at this point. It was previously just on Evan Bacon's machine, and now it's on, you can have it on your machine, which is quite, quite cool. [48:47]

But yeah, like the cool thing about RSCs and React Native is that you're rendering native components under the hood. So you almost render native views, native texts, native images, and you almost do a building block of components through an RSC that is then rendered natively, so it's not web views or anything like that. [49:03]

So it's very different to the DOM component stuff that we talked earlier, which makes it very interesting. Still very early days, but we've seen really cool demos of this over the last year at React Conf and beyond. [49:14]

React Native 0.77 RC0

Mo: Picking on the React Native terrain, very quickly, React Native version 0. 77 has had its release candidate, which is very quick after 0. 76. This is a very small release. Expectedly so, after the massive release that was the new architecture becoming default. So, just some quick things. Swift templates for iOS. [49:35]

This is taken away from the Objective C base of code in the internals of React Native and making it more Swift based and more modern, which is great. They've done some improvements on tvOS integration, which is great because tvOS has kind of been one of those platforms that's been in the shadows and not well supported. [49:52]

And there's some general better performance improvements specifically when dealing with animations. So there's some minor improvements, but nothing super major and not a whole lot of breaking changes. [50:02]

New List dropped in React Native

Mo: Now, speaking of the new architecture Last month we had the release of the new architecture with 0. 76, and we're already seeing some interesting stuff coming out of it. [50:12]

So, Jay Meistrich, who I've known for a little while now, actually released a completely new list component for React Native called LegendList. So, Jay maintains a few libraries called, like, LegendState, another state management library, and I think LegendMotion, which is an animation library. And he recently Created a new list, and now he, he claims that I inspired him to do this at a talk that I did at React Advanced, which is very flattering, and I think he's giving me way too much credit and I definitely don't deserve that, but basically the, the whole concept is with the new event loop in React Native, you can kind of synchronously call on layout events. [50:50]

Which you previously couldn't with React Native and so this is a JS only implementation as a list and it seemingly, on first glance, outperforms FlashList and the FlatList that comes default with React Native so it may be the quickest list in the React Native ecosystem right now. A lot of people are very, very excited by it. [51:08]

Jay is quite good at performance stuff because he spent a lot of his time as a game developer back in the early 2000s basically. So, he was dealing with a lot of very, very, very low memory and low CPU devices. And I guess he kind of knows this stuff decently well. So it's going to be interesting. [51:25]

He's released it to public, so you can go and try it out right now. But it's still to be seen. He's adding more and more APIs as we, as we speak. So it's quite interesting. [51:33]

Carl: Super cool. Mo, I'm going to challenge you on that because if somebody tells you that you were an inspiration, I think you should [51:39]

Mark: Take all the credit. [51:41]

Mo: I just did a talk. It was nothing special. [51:44]

Carl: Ah, that's pretty special. [51:45]

Twitter -> Bluesky migration

Mark: All right, and our, our last big item for this episode is, is not directly tech related, but it is, because React is more than the tech, it's the people in the community, and, you know, we, we spend time talking about conferences, but, you know, we, we get a lot of our links and keep an eye on things from, you know, historically, from Twitter, and Twitter has been where, you know, most of the web dev community has chatted and interacted online for the last several years. [52:11]

And without going into, you know, some of the, the political or, you know, aspects behind it Twitter has declined a lot in the last couple of years. And there's been various waves of people saying I'm done with Twitter and I'm leaving. And the main alternative that a lot of people had gone with was Mastodon. [52:27]

But Mastodon's always had sort of that, like, I'm a Linux user and I know how to set up everything myself kind of a vibe to it. And there's been an alternative to Twitter called BlueSky, which had been invite only for a while. I believe they opened up to public signups maybe about a year ago. But it always felt very niche. [52:48]

And really the main thing I knew about it over the last year was that Dan Abramov, after leaving Facebook had gone over there to actually work on their web and native apps as, as his day job. Well, there has been a massive migration of the greater web development tech community from Twitter over to BlueSky really within just the last month. [53:13]

And I mean, there's, there's been lots of other. Twitter communities that have moved over there black Twitter, football, Twitter, basketball, Twitter, science, Twitter, etc. And feels like, to me, like one, in the earlier era of Twitter where it was people talking rather than just bots or big businesses. And two, the, you know, just the general atmosphere and sort of discussions that are, that are happening. [53:43]

So, a lot of people from the React community have signed up and started being very active over there. A number of people have specifically deleted their old Twitter accounts. As an example, Seb Markbaga from the React team. I believe actually nuked all his old tweets, and moved over to Blue Sky. I think Dan Abramov's Twitter accounts are, are, are gone at this point. [54:09]

So a number of people are doing the Scorched Earth thing, and like, wiping out all their old messages, which I'll be honest, as someone who has always depended a lot on, you know, archiving the web and, you know, linking to external discussions makes me sad because I hate to see historical discussions and tweets and artifacts go away. [54:33]

Having said that, as far as the community goes, I personally am feeling Like Blue Sky is probably where I'm going to put my posting energy going forward. There is, there's a lot of people there. It feels like the community is self sustaining at this point. And it's where a lot of the discussion is happening now. [54:54]

Starter packs: ericclemmons/awesome-starter-packs, stevendborrelli/bluesky-tech-starter-packs Bluesky Directory A complete guide to Bluesky 🦋

Mark: One nice thing is that Blue Sky has these things called starter packs, where anyone can just make a list of people they recommend on a certain topic. And it makes it very easy to follow some or all of them. At once. There are directories of starter packs out there. there's a question about whether BlueSky is kind of related to crypto related things. [55:13]

Technical debate over how “decentralized” Bluesky actually is

Mark: there were a couple good articles talking about some of the technical implementation differences at the server level between Mastodon and BlueSky and like how actually decentralized things are. Loosely put, BlueSky is semi centralized, but it's possible to run your own server and own your own data, somehow. [55:38]

So, big picture, a lot of folks who are from the React community are no longer active on Twitter, and they are now active on BlueSky. [55:47]

Carl: Yep, can confirm. Definitely saw a massive shift in the last, like, month. It's been notable. Yeah. Definitely a lot more people posting out there, yeah. [55:57]

Web Without Walls | React Universe Conf 2024

Mo: because of the crypto question, if you're interested in how the BlueSky backend and like the decentralized nature of BlueSky operates, Dan Abramov did a talk at React Universe Conf about this called Web Without Walls, so I've just shared that and that gives a pretty comprehensive, it is a 40 minute talk, but that gives a pretty long and comprehensive discussion about what the nature, the decentralized nature of BlueSky is. [56:22]

Quickly to add on this, actually, BlueSky is a universal React Native app. So it uses ExpoRouter and it's basically using the same code base for web and mobile, which is quite cool. And you're seeing something in production that's being used by, as we speak, 17, 18 million users now, which is pretty [56:40]

Mark: They reached over, like, 21 million a couple days ago. okay. So I'm clearly off of the uh, off of the numbers. [56:47]

There was about a week and a half where they were adding about a million people a day. [56:51]

Mo: React Native London Conf, we actually had the and Sam from the BlueSky team. Dan now works mostly on the AT protocol stuff, but Sam works on the mobile app and the web app. They are talking about it. This was while they were getting a million per day. So it was quite cool to see them there talking about some of the stuff that they're working on. [57:06]

It's a really cool team, and it's a very small team that's building this, which makes it all the more impressive. And it's super cool that they can take on the likes of a certain someone who's multi multi multi billionaire who's trying to create his own community. So, you know, pretty cool. [57:20]

Carl: Yep, it is super cool. I could probably talk a lot more about it. I have opinions on this. And I've been thinking about the need for data portability and the benefits, the potential benefits of decentralization in the context of social media for most of a decade. I'm actually considering if I want to try and do a business effort based on the underlying data that is BlueSky. [57:45]

I think that there's a lot of opportunity to iterate on the UI layer of social media. And if you have a common public data set, that's a lot easier to do. [57:53]

Mo: on that Carl, the current BlueSky app was not the original BlueSky app Which makes it all the more interesting. So Sam created his own BlueSky client It was better than the original BlueSky app because he could use it with the AT protocol And then they just hired him and made Sam So it kind of shows that like, with this decentralized nature, anyone can make a client and sometimes it'll be better. [58:14]

Kind of like the, what was that Reddit client that was better on, on iOS back in the day, but then Reddit shut it down? I forget [58:20]

the name. [58:21]

Carl: of them. Apollo? [58:22]

Mo: Well, [58:23]

Mark: all, all of them, yeah. [58:24]

Mo: all of them, but Apollo. So yeah, similar story, but the decentralized nature helps with that. [58:29]

Carl: It does. And also the BlueSky client is both a universal React native app, and it's also open source. So I've seen a bunch of React and web people, like not just posting on BlueSky, but what they're posting is their experiments building, you know, iterate changing the UI of the client they're posting from like, Oh, wouldn't it be great if we had Markdown support in BlueSky? [58:51]

Look at this proof of concept that just hacked [58:52]

Mark: We're splitting [58:53]

Carl: a PR. [58:53]

Mark: the notifications tab into subtabs. [58:56]

Carl: could talk a lot more about this. We're already 10 minutes over and. Still need to do the lightning round. But yeah, okay, Blue Sky's great. Follow me. [59:03]

⚡ Lightning round ⚡

Mark: Alright, lightning round, go! [59:06]

Deno v. Oracle: Canceling the JavaScript Trademark

Carl: Deno vs. Oracle. We mentioned this a while ago. I think two months ago. Deno opened a petition to ask Oracle to release the JavaScript trademark, and this is a follow up to that. Seems neat. Seems cool. Love it. They are like formally asking Oracle now. It has moved on from just a petition. [59:27]

Two ways to the two Reacts

Mark: Next up, an author named Bobae Kang has written some good articles talking about the mental mindset of React at a very conceptual, architectural level. And has a good post called, The Two Ways to the Two Reacts, which kind of contrasts Next, where everything is about the server first, versus something like a tan stack start, which is client first, and then optionally adding in the server. [59:52]

That's not an abstraction, that's just a layer of indirection

Carl: Another one. Great post that I love, called, That's not an abstraction, that's just a layer of indirection. [59:59]

Mark: True that [01:00:00]

Carl: Just generally true, like, end of, end of comment. [01:00:04]

React Anti-Pattern: Stop Passing Setters Down the Components Tree

Carl: Related, while I was looking for, you know, doing my final pass of resources to pull in I've seen this anti pattern kind of blog post called stop "passing setters down the components tree" and, agree. [01:00:17]

That is a wonderful example of not an abstraction. If you're just passing the set state setter down as a prop, you should probably do it differently. [01:00:26]

Mark: something something dispatching actions. [01:00:29]

Carl: Aha. What Redux? [01:00:31]

What is HTTP/3?

Carl: Yeah, I saw a neat post from Cloudflare called, What is HTTP 3? That made me go, whoa, I didn't know there was an HTTP 3. So yeah, that exists. It's something about QUIC. And I think it's related to, like, I don't know. It sounded like the promise benefits. They sounded very familiar from what I remember reading about HTTP 2, which as far as I know have not really been realized. So Seems like a new attempt to edit something something UDP, HTTP 3. [01:01:03]

Leaked Vercel v0 system prompts

Carl: Someone posted on Reddit that they managed to exfiltrate the system prompts for Vercel's V0 AI UI generation tool. And that's cool, that's interesting. It looks like this was not, you know, any weird black hat stuff, like they just saw something leak. and managed to continue prompting the AI until they got the full system prompt. [01:01:25]

So this is output from the AI, which means it might not be real, but it does seem approximately correct. You know, Must write valid JavaScript code that uses state of the art Node. js features and follows best practices. Does not use the components. You know, so it's like massive, massive prompt. [01:01:44]

I think it's an interesting, you know, peek behind the curtain. This is what the wizard looks like kind of [01:01:50]

Mark: And today's example of why I do not want to spend the rest of my career writing prompts. I want to write code. [01:01:57]

Carl: What's the difference? [01:01:59]

React Scan to highlight component renders (by the author of Million.js), which he used to point out Github’s code view re-rendering on every scroll

Mark: Alright, a couple perf related items. Aiden Bai, the author of the Million. js React plugin for performance, I guess. Recently put out a new tool called React Scan, which can be used to identify, you know, components that are over rendering in your app. I glanced at the source code for 30 seconds and saw that it's messing around with some of the internals of React's Fibretree, and as someone who has spent a lot of time messing around with the React code, And React's internals in the React DevTools. [01:02:28]

I have a sense of how this is probably working, and I approve. In fact, he actually used it to identify that GitHub's current source file display, which is based on React, was apparently re rendering all the lines every time you scrolled. And he even managed to identify, yeah, like, here's the component. [01:02:46]

And here's like the prop that needs to be memoized in order to fix that. And a couple hours later, some GitHub engineer actually fixed it. So that's a step in the right direction. [01:02:56]

What’s Next for the React Compiler?

Mark: On a similar note, Satya from the React team just did a, just did a, an update talk called what's next for the React compiler talking about some of the upcoming features they're thinking of working on that would hopefully further improve performance. [01:03:10]

Carl: Very smooth. Unrelated, non smooth transition [01:03:14]

Framer Motion spinning out as an OSS tool (Motion), and conversely GSAP is joining WebFlow

Carl: Framer Motion which is a React animation tool. Uh, Is spinning out. It is no longer under the Framer brand and it is no longer React specific. Uh, It's just an open source tool called Motion, which seems cool. Framer Motion is definitely something I've heard about a lot for doing like complex, advanced animations and whatever. [01:03:37]

So yeah, it seems cool. Love it. In the inverse direction GreenSock animation platform, GSAP, was acquired by Webflow. Love it. Love seeing open source tools get money. The maintainers do a lot of work and they deserve to be compensated for it. So yeah, super happy to see that. [01:03:54]

Mark: This feels like that, you know, that classic line about there's two ways to make money. Bundling and unbundling. [01:04:00]

Carl: Yes. 100%. [01:04:03]

Mark: One library leaves, another library joins. [01:04:05]

Carl: Right, every company is either a bundling or unbundling play and here we go. Here's two examples. Well, all right Thank you everyone for joining us and sticking with us all the way to the end. We will be back Well, actually we will not be back on the last Wednesday of the month because the last Wednesday of December is Christmas and we are Not recording on Christmas. I am so sorry. I'm not sorry [01:04:26]

But yeah, we so we will be back recording at the end of December probably that Monday TBD Or back in your podcast feed as soon as we can. Yeah, thanks so much, Mark. Yeah. Always [01:04:37]

Mark: nice too be here. I'm very much looking forward to a nice long Thanksgiving break where we'll probably mostly be hacking and Redux stuff. [01:04:43]

Mo: yeah, it's always a pleasure to be here. Um, Lovely chatting with you all and loved getting into blue sky shenanigans this month, so we'll see what next month has in store for us. [01:04:52]

Mark: Thank you for the behind the scenes bit on that. I did not know that they'd swapped clients. [01:04:56]

Mo: I'll hopefully share the recording once we have it live and everyone can hear the story from the comforts of their home. [01:05:02]

Carl: Cool. All right. We gather sources from this week in React, bytes. dev, react status, Next. js Weekly, the React. js subreddit, here in Reactaflux, and directly from people publishing articles, mostly on BlueSky. If you see anything newsworthy, definitely let us know by posting it in the Tech News and Reads channel here in Reactaflux, or send me an email. [01:05:24]

I will read it if you send me an email to hello at reactiflux. com yeah, I read everything. I will read it. If this is a show you get value from and want to support, best way to do so is by submitting a review and by telling your friends and coworkers about it. Help them get as smart as you are about React. [01:05:41]

See you next month.

This Month in React, October 2024: React DevTools update, React Native 0.76 (new architecture dropped), Web Components are(n't) the future

Reactiflux — Tue, 29 Oct 2024 16:00:00 GMT

[00:56] Job market: FRED data, Layoffs.fyi
[01:40] New releases
- [01:43] React Native 0.76 proper
  - [01:54] New Architecture is here
  - [05:18] BlueSky and Expensify
- [06:22] React Compiler Beta
- [07:23] React DevTools v6
- [07:50] Zustand v5
- [08:17] eslint-plugin-react-hooks v5
- [08:45] Announcing Deno 2
  - [08:45] /r/bun: Deno 2 vs Bun? What are your thoughts?
  - /r/deno: Deno 2 vs Bun? What are your thoughts?
- [10:14] Tauri 2.0
- [11:40] One - the new RN framework
  - [11:40] Creators of Tamagui
  - [11:40] Built on ZeroSync
- [16:15] Cloudflare Workers updates
- [22:05] Zeego 2.0
[22:33] Conferences
- [22:35] HalfStack London London, UK Nov 13
- [22:40] React Native London London, UK Nov 15
  - Special Discount for podcast listeners with discount code TMIR
- [23:10] React Summit US New York, USA Nov 18-21
- [23:14] React Africa Casablanca, Morocco Nov 29
- [23:19] React Day Berlin Berlin, DE Dec 13 & 16
[23:33] Sponsored by Infinite Red
[24:50] Some React 19 progress, but no ETA
- [24:50] Lazy Context Propagation
- [25:51] “Server Actions” renamed to “Server Functions”
[26:08] React Native Bottom Tabs library using native bottom tabs
[27:45] Meta Connect showcasing new AR/VR apps built with RN
[29:07] Static Hermes Updates
Reddit is revolting against Epic React
- [30:16] Anyone else feel burnt by Epic React? : r/reactjs
- [30:42] Epic React V1 => V2 Upgrade & Deception.
[37:12] Web Components Are Not the Future
- [37:12] Followup to this from March 2020: Maybe Web Components are not the Future?
- [37:34] Web Components Are Not the Future — They’re the Present
- [37:53] Liskov's Gun: The parallel evolution of React and Web Components
[44:10] Announcing VoidZero - Next Generation Toolchain for JavaScript
- [44:37] OXC compiler
- [44:37] OXC Transformer Alpha
[45:23] Updates from the 104th TC39 meeting
- Stage 4 proposals
  - [45:33] Promise.try
  - [46:21] Sync Iterator Helpers
  - [46:48] Import Attributes
  - [46:58] JSON modules
  - [47:05] RegExp Modifiers
[47:11] Language Evolution “JSSugar” proposal
- [47:11] NullVoxPopuli on X
- [47:11] NullVoxPopuli on X
- [47:11] BrendanEich on X
- [47:11] Daniel Ehrenberg thoughts
[50:44] Lightning Round
- [50:44] The Disappearance of an Internet Domain – .io
- [51:51] How to control a React component with the URL
- [53:16] If WordPress is to survive, Matt Mullenweg must be removed
- [55:09] Web Without Walls — Dan Abramov
- [57:23] Preact compat discussion
- [57:44] Content-visibility in CSS
  - [57:44] Using CSS containment
  - [58:00] contain - CanIUse
  - [59:50] content-visibility - CanIUse
- [01:00:39] How I Built My Blog • Josh W. Comeau
- [01:02:24] Types of React Components 2024

Carl: Hello everyone. Thank you for joining us for the October edition of This Month in React, where we recap and digest the recent developments in the ever evolving React and web ecosystem. We're coming to you live from Reactiflux, the place for professional React developers. [00:14]

And we're supported by Infinite Red, a consultancy that exclusively works with React Native, but we'll do a little ad read for them later. [00:21]

Hello, I'm Carl. I'm a staff product developer and freelance community manager here at Reactiflux where I run community programs like these events and the star helpers, and do other stuff to keep the community running smoothly. [00:33]

Mark: Hi, I'm Mark. My day job is at replay. io, which we're going to have a slight tangent on the io part of this later on. And other than that, on Redux stuff. [00:43]

Mo: The mobile team at Theodo which is a global consultancy and I'm active within the React Native ecosystem, organizing the React Native community and here and there dabbling in some open source. Happy to be here as always. [00:56]

Job market: FRED data, Layoffs.fyi

Carl: Yeah. First up, some quick hits while people start filtering in. We did not do a job market update last month. It was actually pretty quiet. Not a lot of news. It seems kind of back to baseline. data for posts made to Indeed is still, like, two thirds of what it was at the beginning of 2020 before pandemic hit. [01:14]

that might have been a high watermark for the industry, so it's, it's kind of hard to say. Layoffs at least have been, look very low for the last two months in a row. So that seems good, but yeah, the hiring has not really picked up. But not sure it's going to. [01:29]

I wonder about that. Definitely the vibe I've been getting is that most of the roles being hired for are more on the seniors end of the scale, which is Not ideal, not great, but yeah, seems to be where it's at. [01:40]

New releases

Carl: Yeah, into some new releases. [01:41]

Moe, you want to tell us about React Native? [01:43]

React Native 0.76 proper

Mo: Yes, indeed. I feel like this is years in the making, so I've got to really drum this up as much as possible. But, the new architecture is finally here, [01:54]

New Architecture is here

Mark: Woohoo! [01:55]

Mo: So this is React Native version 0. 76. And if you go back into likethe history of React Native over the last five years, the first mention of the new architecture publicly was in 2019. [02:08]

And really what the whole purpose of the new architecture was, was to make a more stable Baseline for React Native interacting with native platforms. How components are rendered. How does JavaScript code trigger native code and native modules? And how do we move different things around different threads and make sure that everything is optimized and consistent? [02:28]

A lot of people think that the new architecture is like a performance oriented update. It doesn't really have that many major performance improvements. There's minor ones, but really what it's trying there for mainly is, I think, for library maintainers and for framework authors to be able to create a more consistent pattern of communicating between native and React Native. [02:47]

So, for a little bit of context, React Native's old architecture used this thing called the bridge. So it was basically a messaging bridge where you could pass in serialized JSON from the JavaScript layer and from the native layer and it would kind of get communicated across this bridge. But the issue with a bridge is that it can have some traffic, right? [03:03]

So you can bombard it with a lot of JSON and suddenly because it's asynchronous it has limits in terms of how much it can communicate if you were trying to update things frequently or send a lot of data through that bridge you would block that, and what we would call that is that the JS thread is blocked, and so your app would basically drop in its frame rate, the CPU usage would spike, and everyone would be unhappy, and your users would be like, Hmm, this is not quite native feeling to me. [03:30]

But, as of now, there's been a lot of work that's been done. React Native has a bunch of different stuff that I'm not going to go into too much detail about. But the bridge has been replaced with what we call the JavaScript interface. And so what that means is JavaScript code can get a reference to a C object that communicates with a native layer, and it can directly invoke methods within that C layer that would live on the native layer. [03:51]

So it removes the bridge and it's just direct communication via JavaScript interface to the native layer. So that makes things significantly more efficient. It's not just that, the new architecture is a lot of different parts. There's the new event loop, there's the new renderer and then there's the new native module system, and of course the JSI, which is kind of underpinning all of that. [04:11]

the article that you shared in the chat has a lot of details and it's a good summary, so I would start from there if you've been kind of under the rocks. In the React Native ecosystem and not,really hearing much about the new architecture. I think it's a really good summary about why it matters, what you can achieve. [04:25]

And ultimately, I think one of the biggest things is that it's giving you parody with React behaviors, because a lot of things that were in React before just didn't work in React Native properly and people were figuring that out on usage. Basically, it wasn't really documented very well anywhere. very exciting times. [04:40]

it's finally happened. [04:42]

Carl: Yeah, I feel like this is an update that's a little easy to be, you know, under a rock on. If it's been in progress for literally five years now, I could see how that might slip into the back of your mind as something like, There's a lot of things I waited five years for, and by about the third or fourth year, I started wondering if it was ever going to actually happen. [05:01]

Mo: exactly, and you know, it's one of those things where yeah, it's been happening for five years, but you do get new architecture talks every conference that's a React Native conference or like React Native adjacent. So it's been the topic of conversation and everyone's like, Oh, that'll probably come at some point. [05:15]

And it feels quite surreal to have it actually here. [05:18]

BlueSky and Expensify

Carl: Cool. I saw a post from Software Mansion, which is a React Native focused, consultancy as far as I know, talking about bringing the new architecture into the Expensify app, and I understand that the Blue Sky native app is doing a release candidate for it that's like, opt in, and they say it's, you know, it's a release candidate, it's unsupported, try it at your own risk, please report bugs. [05:41]

But like, those are real apps, like Expensify is widely used enterprise app. So that's some real usage. That's pretty cool. [05:48]

Mo: props to the meta team, they actually spent a lot of time with real apps that are large scale apps that, you know, were popularly React Native. They approached the developers of those apps and said, Hey, can you turn on the new architecture before we release and make sure that it's working and behaving and functioning in a way that doesn't really have regressions and is actually better than it was before. [06:06]

So they've really tested this out and drawn it out. They've worked with library maintainers one on one to get them on to the new architecture boat. So, this is as good as it ever will get in terms of just biting the bullet and releasing. [06:19]

Carl: Nice. Yeah. [06:22]

React Compiler Beta

Mark: The first one is that the React compiler is now in beta. The first, you know, early adopter, I guess, releases came out at React Conf back in May. And it's now in beta you can actually meaningfully try it out, they've done a lot of work to try to improve the behavior against real world applications. [06:42]

Along with that, there's a couple different ESLint plugins the Rules of React Hooks plugin has been updated, and it's got some additional checks for whether things are actually components. Along with that, the compiler has its own associated plugin that tries to check for the rules of React behavior. [07:02]

You know, basically, are you doing anything that is considered illegal, even if it technically runs inside of your React component? And so they're highly recommending that people start trying to use the rules of React plugin in your applications to find places where you're doing things that you're really not supposed to in React. [07:23]

React DevTools v6

Mark: Along with that, there's a new React DevTools extension release. They did a lot of shuffling around of the internals, but what is probably most relevant here is that the DevTools now actually have support for showing server components in the tree. And this is a big deal, because up until now there really hadn't been any way to atsee what server components were actually, being used when you were looking at the code on the client side. [07:47]

So that's a pretty distinct improvement there. [07:50]

Zustand v5

Mark: Flipping away from that over into state management, Zustan just came out with version 5, and it doesn't have any new features, but it does drop some, legacy backwards compatibility changes, default exports, a couple other things, and it now requires React 18. [08:08]

So if you're using Zustan, you may want to look at picking that up. [08:11]

Carl: Yeah. Hang on. The Redux guy talking about another state management library. Hold up. [08:15]

Mark: I'm allowed to. ( laughter) [08:17]

Carl: For sure . [08:17]

eslint-plugin-react-hooks v5

Carl: There's also a new major version of the ESLint plugin for React Hooks. Looks like it supports ESLint v9, and it doesn't look like there's a lot of changes, I think it's mostly just compatibility for latest versions. But, they did change how the rule works for component names. [08:33]

So now, previously it used to require a non lowercase letter. So it'll let you do things like an underscore in front, and now it doesn't. Now it has to be an uppercase letter. they kind of flipped the bit on that. [08:44]

Mark: Picky, picky. [08:45]

Carl: Cool. [08:45]

Announcing Deno 2

/r/bun: Deno 2 vs Bun? What are your thoughts? /r/deno: Deno 2 vs Bun? What are your thoughts?

Carl: Deno released version 2 as well. We've covered Deno sporadically over the last couple of episodes, but the highlights here that they shout out are backwards compatibility with Node. [08:56]

js and NPM, native support for the package. json and Node modules. I guess that's part of backwards compatibility. More package management, I know, you know, the original idea behind Deno dependencies was just like a little bit more URL based and kind of free for all like no registry just like install code very like go Inspired and I guess they're walking that back pretty hard. [09:21]

Mark: they've walked [09:22]

back a lot of things around NPM compatibility. [09:25]

Carl: Yes, I feel like they started out heavily opinionated and are walking back a lot of those opinions, which okay I mean, I guess fair enough. They did also do a lot of work on the standard library and things So it could well be that some of those opinions were just like this is less work. [09:40]

We're gonna launch it they've got a standard library Support for private NPM registries. Yeah, a lot of these things are just kind of like details on backwards compatibility with node and NPM they're doing LTS releases. They've got their own JSR, JavaScript, something registry. [09:57]

And there were a couple of threads that I wanted to shout out of exact same title posted in the Bun and Dino subreddits, Dino2 vs Bun. What are your thoughts? I won't summarize them. It's just like a bunch of Reddit commenters, you can see, see the two, the two camps reacting to the news, [10:14]

Tauri 2.0

Mark: The Tari framework, which lets you build desktop apps using web technologies as an alternative to Electron just came out with version two. They have some improvements around HMAR and plugins and various other internal improvements. If you're building desktop apps, probably worth taking a look. [10:32]

Carl: Yeah, I thought it was neat that they added a permissions model. I guess they used to have like an allow list of things that your app was allowed to do. And they talked a little bit about enhancing that with, you know, a permissions model, which seems like a good improvement. Yeah, they also mentioned mobile support, which was like, what? I feel like they buried the lead on that. It's like, I want to know a lot more about that. I feel like Rust based native app framework where you can use React on Android and iOS. Like, huh, I want to know a lot more about that, but they didn't say too much in the announcements. [11:04]

Mo: Yeah, it's, as with all things with thisso it's not official yet with Taure. I think they're just kind of working on it, so I,suspect they're kind of saying, hey, we're working on it. The general gist with all of these Electron like frameworks it ultimately ends upbeing something like Cordova with Ionic. [11:22]

it's a web view that triggers some native functionality. It won't be a truly native app, which is, I guess, one of the distinguishing factors of React Native. But it'd be very interesting to see how they play this out. And how it works in practice. It might be something a bit different, but they're being very cryptic about it so far. [11:38]

So, remains to be seen. [11:40]

One the new RN framework

Creators of Tamagui

Built on ZeroSync

Mo: Moving on. So, earlier this year the React Native Core team came up with this big announcement saying, Hey, we think you should use frameworks. And not build your own frameworks every time you initialize a new React Native app. And so at that point they introduced Expo as the only option to, as a pre built framework. [11:57]

They said, you know, you're either using Expo, or you've built your own framework by building on top of the core of React Native. And so now we have finally gotten a second framework that's come in and said, Hey, I I'm a contender for that spot as well. the framework is called one. I'm not too sure why there's, that's the naming, but, there we are. [12:16]

You have a theory. All right. [12:17]

Carl: so it looks like they're built on a sync engine that's called Zero. ZeroSync. so I guess this is, you know, they're built on Zero so they are one. [12:26]

Mo: Cool. So, this is an interesting development because the person who's behind this is behind the library called Tamagui. So Tamagui is a styling library within the React Native Ecosystem. the whole spiel with Tamagui is that it's an optimized view layer library that you can use not just for your React Native apps, but also in things like Next. [12:46]

js. So you can kind of share your UI across the board between React Native and the web. it's used to build these universal apps. Tamagui is quite an interesting project. It's actually a very heavyweight library, because it comes with things like a styling solution, a compiler that, does view flattening. [13:05]

Next. js optimizations out of the hood. it's a very heavy styling solution when you're using it just for React Native, and it's notoriously complicated as well. they've taken Tamagui, paired it with a whole bunch of other stuff, like a file system routing based solution, and the most interesting part, I'd say arguably, is the fact that this is beat based.previous to this, you couldn't use Vite for React Native because you'd have to use either Metro or in some cases you could use Webpack, but it was quite a pain to actually get that working. the creator of this, Nate, has been working on seeing if Vite can become a compiler for React Native. [13:42]

React Native, and it seems like there's some good movement on this. So, it uses Veep by default to kind of standardize the bundler across web and mobile. So, it's a very interesting proposition and they have a lot of experience but it's still going to be interesting to see how this plays out. [13:58]

It's very early days. So, I would Tread with caution until it's reached some point of stability and it's being used. But it's very interesting to see how it's forming. [14:09]

Carl: Yeah, definitely early days, but like, I'm taking this reasonably seriously. It seems like a pretty clever and opinionated take on how to do a framework on React Native. I guess, you know, like, my rough mental model for this this feels to me like the React Native equivalent for Remix. [14:28]

in large part because it's beat based, you know, okay. [14:31]

Mo: but it has a lot of, like, very similar ideas, right? Like, they've kind of introduced this concept of loaders as well. it's very Remix esque. so I can see why you take that comparison. [14:42]

Carl: another thing that I find fascinating here is they put local first and sync engine very heavy in their homepage marketing for this. they talk a lot about this being built on zero sync, which is built by a company that I've heard of and that the CEO follows me on Twitter. [14:57]

I think that's cool. it's being built by a team that worked at a decentralized exchange that I had heard of. Six years ago. So they worked on decentralized tech that I took seriously as someone I also worked in decentralized tech six years ago. So I think it's really interesting that that's the Opinion they're bringing to this company that they named that they worked at Uniswap I viewed as one of the serious contenders in web 3 before it became overtaken by scams So it looks like they have now moved out of Web3, taken that decentralized technology experience, and are building a React Native framework that is based around local first, you know, data on your device, primarily synced to a backend. [15:40]

And I think that's really cool. I am pretty bullish on local first generally, I'm very curious to see how this works. Early days, like you said, it's interesting to me. I am intrigued. [15:51]

Mo: and Uniswap is built with Tamagui. So the web and the mobile app is built with Tamagui which kind of is a real implementation, real world production app that's using the universal app paradigm. they know how to do it. It's just a matter of how, easy to use it is for other developers who aren't that familiar with this sort of framework or this [16:10]

Carl: it's Yeah, right. It's easy to say how powerful and useful something is when you are the person who made it. [16:15]

Cloudflare Workers updates

Carl: Cloudflare Workers released a bunch of new updates, and a lot of them look really cool to me. So I'm using Cloudflare Workers a little bit in like, a side project or two. [16:24]

I would like to use it more for ReactiFlux projects, but actually Discord does not allow the gateway to connect to like, the Cloudflare Workers durable objects. For some reason, I don't know why, that seems weird. than the fact that you just can't connect to the API, they seem like a really powerful way to interact with Discord. [16:43]

So, I would love to use them for that. Sadly, I can't. ButI think Cloudflare released, yeah, 18 big updates to the workers platform is the headline here. Literally the title of release. Something that I found really interesting is they are advertising CICD with PR preview releases for workers. [17:01]

I think that's not going to be quite as like turnkey, instantly useful as it is in like Netlify or you know, Vercel where, you know, like, you get a PR preview on your website, you just get a new domain, boom, done, everything kind of works. Assuming you didn't like actively screw something up and how you are doing, you know, base URLs. [17:22]

I think for a backend service like this, it's just not going to be quite so simple and like zero effort to take advantage of PR previews. Like you, you need to have a staging environment where you can be notified of a new URL being available and then dynamically swap out the, like, base route for this. [17:39]

And then like other stuff, like what about. Seeding test data and things like that. So I don't think this is quite so like Mind blowingly immediately useful as it is on a web deployment CICD, but that's still super cool Like that's you know, like for it for a discord bot, which is mostly where I've tried to use these like that's still pretty Accessible. [18:00]

Yeah, so I think that's pretty pretty useful some other smaller stuff Logging on the dashboard for your workers. I have run into issues with like Observability was not easy before this, so I have actually already enabled logging on the dashboard in one of my projects because I needed it, and I was like, oh, cool, great, now I can just do it's not effort. [18:17]

Better Node. js compatibility, they have, because it's a serverless runtime, they don't have stuff, like FS or HTTP or things like that. It was a little bit more Sandbox, like, Request Lifetime, they give you the entire environment in the request handler. So, when they say greater Node. [18:35]

js compatibility, I'm not quite sure how to interpret that. The, they had like a compatibility chart, and it included like 100 percent on, you know, NodeFS. But like, I don't know what that means when you don't have a file system, you know. I don't think they are actually emulating a file system where you can read and write. [18:52]

Maybe they are, I don't think they are. [18:54]

Mo: [18:54]

they're slowly going through the list of Node APIs, And I think they support like only 50 percent of them. So they still don't support like file system in any capacity, just because it doesn't make sense for the runtimes they have, because our workers kind of just run in a V8 isolate. [19:11]

just running somewhere on their edge network [19:13]

Carl: That's what confused me though, because the compatibility thing said 100 percent coverage for FS. And so it's like, I know you don't support this because of the environment, what does that mean? I don't know how to interpret this chart. [19:24]

Mo: yeah, I think some of them are probably just weird polyfills or just like shimmed values. I'm [19:30]

Carl: Yeah, I mean, I guess even like, doesn't immediately explode is an improvement, you [19:36]

Mo: Is it an improvement yet? [19:38]

Carl: Which is where it's been for me, like, oh my god, there were some weird things that happened when I was trying to develop that. Like, CommonJS imports and things, yeah, so, yeah, I have to play around with that a little bit more. [19:48]

Yeah, they also have Next. js support. via open next, which they've open sourced. So like, cool, here's an open source runtime that they are using themselves in production to provide next support. And like, that's enormous. I think I saw when this was announced Vercel, some of the big Vercel DevRel folks who are active on Twitter seemed a little bit like they were nervous. [20:12]

Mo: I've used Cloudflare Workers quite a lot recently, and they had some, like, Next. js support, limited. They've been increasing it for the past few years. They started off with just, like, you can static export Next sites. Great. You can do that with anywhere and host it anywhere. Right? Then it was like, we'll support some limited sub features of Next. [20:28]

And I think they're now supporting it almost fully with the OpenNext runtime. And I can see why some of the Vercel folks would be a little bit on edge, because if you support Next to that degree, yes, Vercel has a lot of nice DevEx features, but when you look at the cost for a large scale site, and where Vercel would make a lot of their money you can get the majority of those functionalities, or like 80 percent of those functionalities on CloudFlare pages. [20:52]

it kind of works similarly. You get those preview branches and all of that. So I can see why they'd be a little bit anxious about that, but I suspect they'll do what Vercel usually does, which is introduce a new, like, runtime dependency, and then it'll take everyone six months to basically get on the same compatibility. [21:11]

So we'll see. [21:12]

Carl: They'll just dig that moat a little bit deeper, maybe. Yeah, they also have per worker SQLite, which is neat. Previously, I guess it had only been, like key value store based, so it was kind of like having local storage available per worker, which is great, but, you know, you can't query it.you can't really do structured data in a situation like that. As well as blue green deployments, incremental rollouts. And queues, and a vector database, performance improvements, like, you know, one of the performance improvements is faster time to first token on their AI, platform. [21:41]

like you were saying, Mo, about Vercel getting maybe a little nervous aboutCloudflare workers with real Next support for things like the dynamic images, some of their, longer tail of server based functionality with PR previews, incremental rollouts, and, a queuing system, like,that starts to sound a lot like the offerings that Vercel offers. [22:03]

But yeah, [22:05]

Zeego 2.0

Mo: Cool. I'll quickly just give a shout out to version Zgo. So for those of you who aren't familiar, Zgo is a wrapper, it's almost like an abstraction, on top of context menus on both native and web. So again, going in that universal app trend you can use a single API in your code base to create context menus for your web with Radix, and then it'll hook into the native layer context menus on iOS and Android. [22:26]

So it's a nice little library to use as a utility when you do want to have context on certain elements of your app. [22:32]

Carl: Cool, seems useful. [22:33]

Conferences

Carl: Alright I'm gonna fly through some conferences. [22:35]

HalfStack London London, UK Nov 13

Carl: Halfstack London is happening in two weeks. November 13th. [22:40]

React Native London London, UK Nov 15

Mo: Yes, and another shameless plug React Native London conference, this will be the last announcement before it actually happens in Just over two weeks now. So, this is happening in London, of course on the 14th and 15th of November. Tickets are gonna probably start closing soon, in the next week and a half, roughly, so grab your ticket if you're interested, and there's a discount code with TMIR for this month in React. [23:03]

Where you can get 10 percent off. So come along, say hi to me if you're there, shoot me a message if you do plan on attending. We'd love to host you. [23:10]

React Summit US New York, USA Nov 18-21

Carl: There's also React Summit in New York November 18th through 21st. [23:14]

React Africa Casablanca, Morocco Nov 29

Carl: React Africa in Casablanca, Morocco at the end of the month in November 29th. [23:19]

React Day Berlin Berlin, DE Dec 13 & 16

Carl: And React Day Berlin December 13th and 16th. [23:23]

Mark: I will be speaking at React Summit. [23:25]

Carl: Cool. Yeah, go to React Summit in New York and go meet Mark. I live in New York. [23:31]

I will try and make it if I can. [23:34]

Sponsored by Infinite Red

Carl: So we are exclusively brought to you by Infinite Red. That's very tongue in cheek, but yes, they are our only sponsor right now. Infinite Red is an expert React Native consultancy. They've been around since 2015 uh, and are owned by Jim and Holmgren. [23:47]

Todd Wirth and Gant Laborde. They've been super active in the community for literally my entire career. I got my start like professionally with React around 2014 or so. So like, I have been aware of them for a really long time. And yeah, I connected with them in a conference and just great vibes. So good. [24:04]

They only do React Native and have built over 75 apps for companies from startups to like huge enterprises. And just like, other than being good people who do a lot of good things for the React and React Native ecosystemsthey seem to be very good to their people because they, like their average tenure of employees at their company is more than seven years. [24:23]

Which is wild to me. That's double the tenure I've ever spent at one company. So that seems great. They are not a like feature factory. They work alongside your developers at your company and help you develop your own expertise there. So if you are spinning up a new product with React Native and want some help hitting the ground running, definitely give them a ring. [24:41]

And uh, you do let them know that you heard about them from us. Not that we get anything out of it. Just, you know, Maybe help us in the next contract negotiations. He he he. [24:48]

Main Content

Carl: Into our main content though. [24:50]

Some React 19 progress, but no ETA

Lazy Context Propagation

Mark: So we've been attempting to track the progress of React 19 and there were a couple of progress that I saw happening in the last month or so. The. Big thing is that we're still waiting for them to finish work on the changes related to the parallel suspense rendering behavior that caused an outcry earlier this year. [25:13]

And I saw a couple PRs from Andrew get merged. I later saw one of them get reverted. And then, just in the last week or so, I think I saw one of them get unreverted or a feature flag get landed around that. So, there is work going on, I have no evidence to say how much more work is needed to be done. I also think I saw someone from the React team, possibly Sophie, mention that they're hoping to get it out by the end of the year, but, you know, nothing concrete either way. [25:46]

So, stuff's happening, stand by, and wait. It's all we can do. [25:51]

“Server Actions” renamed to “Server Functions”

Carl: Hurry up and wait. Yeah. And I guess one concrete change that has happened is server actions have been renamed to server functions, which I don't know, I guess that seems good. There's a lot of things in the ecosystem that were called actions. So one less thing called action seems good. [26:07]

Mark: Probably. [26:08]

React Native Bottom Tabs library using native bottom tabs

Mo: Cool. So, the next update is that there's this library called react native bottom tabs that's made by one of the developers at Callstack, Oskar Kwaszynewski. Who I've known for a little while. And This is quite an interesting development. Because The current library that you use for navigation within React Native Is called React Navigation. [26:28]

And React Navigation has bottom tabs within it. But they're not fully native backed bottom tabs. And so it means when there's updates Or specific Styling applied to certain platforms Let's say onLet's say on iOS Where if you're on like tvOS, the tabs go on the top. And if you're on tablet, you can have them as like a sidebar. [26:47]

But on mobile, they kind of just look like a normal tab bar. Those changes wouldn't be reflected because they were just basically JavaScript views that were customized. And so the whole purpose of React Native bottom tabs is to create native based navigationOn React Native apps using a JavaScript API. [27:05]

So this will hook into the native layer and it'll look and be styled as a native layer bottom tab, which is quite cool. And a lot of work's being placed into it. One of the things that I've been thinking about with this is could this possibly be introduced and upstreamed into React Navigation because It's a really good alternative. [27:27]

So in React Navigation, we've got native stack navigators, which is the stack navigator that you can use. And it uses the native functionality for the stacks. This could also be introduced as some sort of native tab navigator. So still to be seen, but quite interesting as an update. [27:45]

Meta Connect showcasing new AR/VR apps built with RN

Mo: Cool. Next up, we have MetaConnect happening, and there was a whole bunch of AR VR showcases, which was cool. Obviously, Mark Zuckerberg went on stage and showed off the Orion headsets, which are not really going on sale, but they're kind of showing the future of where Meta wants to go, which I'm personally quite excited about, I really like AR, I hate massive VR goggles, but I really like the form factor of the uh, Google Glass. [28:09]

And I was quite gutted that Google Glass was, was basically chopped. I think it was just a bit too early for its time. But, on the side of that demo there some sort of, like, engineering blogs that were released. And they showcased at the event the Instagram and Facebook apps for the new MetaQuest. [28:25]

interestingly despite Instagram being a native application and despite you know, parts of the Facebook app also being backed by native the Instagram and Facebook apps for the MetaQuest have been rebuilt with React Native, which is quite a big step forward. win for the React Native ecosystem because it's being used on more and more platforms and powering more of Meta's apps that is part of the core business. [28:50]

So this was quite cool to hear and they've built some incredible apps. Like if you, if you look at the demos, there's really swift animations there. Everything looks really buttery smooth and looks really nice. So, it's a really cool showcase of, what they've been able to achieve by rebuilding some of this stuff in React Native. [29:06]

Cool. [29:07]

Static Hermes Updates

Mo: Just a quick update on Static Hermes. Not much is happening here. There's a lot of discussions around like how compatible it would be and you know, what challenges it would introduce with the existing ecosystem. Svetlan Mikhov, who's one of the people behind Static Hermes and who first introduced it last year at React Native EU actually talked about some of the limitations that they were facing trying to take Static Hermes to production with the wider ecosystem. [29:30]

A few people have been playing around giving him some feedback. He's been going on long threads on Twitter explaining some of the details of the implementation, especially with assembly code. So he's been like pasting assembly code in Twitter threads which is quite interesting and he's been styling them like, he's been going through a lot of effort to try to really like explain to the community, which is props to him. [29:48]

But Evan Bacon, as Evan Bacon does came up with a demo of using Static Hermes with Expo dev clients on iOS. So Software Mansion's been working on some stuff around trying to take Static Hermes to production, and Evan Bacon's been trying to see if he can find a way to make it work with a basic Expo app. [30:07]

There's still some limitations it's not anywhere near production ready, but it's just, things are being done in that space, which is quite cool to see. [30:14]

Carl: Yeah. Super cool. Nice. [30:16]

Anyone else feel burnt by Epic React? : r/reactjs

Carl: This is maybe a little bit of a small note, but I think we've plugged it before. So I wanted include some follow up from the ecosystem. Folks on Reddit have been sharing about feeling burnt by Epic React, which is Kent C. Dodd's React course. I empathize. I get it. Their criticisms are pretty legit. [30:34]

Some of them are legit. Some of them feel like, you know, reddit commenters having strong opinions about how the world works, which are not necessarily based in economic realities. [30:42]

Epic React V1 => V2 Upgrade & Deception.

Carl: Butsome of the complaints that seemed a little more legit to me were, like, people who had bought the, version one, the old version a couple of years ago, were upset about having to pay almost full price to get the upgrade. [30:54]

Marker

Carl: And on the one hand, like, if you bought a course and you learned the course, why do you need to buy it again? I can understand wanting it. And I guess I can understand, like, wanting to, I don't know, it feels a little bit like folks, Feels a little entitled. Feels a little bit like wanting stuff for free. [31:13]

Like I don't know, he put in a lot of effort to update it. I think the previous version came out like four years ago and that's a long time. A lot of things have changed and been updated and the ecosystem has moved on a lot. So I don't know that it is a reasonable expectation to get a brand new course for free or for extremely cheap just because you paid for it a couple of years ago. [31:37]

If you paid for a course that is intended to like help you kickstart a career using the technology, I don't know that you should necessarily need to buy another course targeting people who are trying to kickstart careers in the industry several years later. If you do, like, maybe you didn't take full advantage of the first course. [31:55]

I don't know. So I empathize with that. People were also criticizing the cost of it as being very expensive. It is like, you know, it's several hundred dollars. Like, I think full price for it is like 700. [32:05]

Mark: my train of thought on that one is that Kent is entitled, it's a free market, Kent is entitled to put whatever price on, you know, something he's selling, and you are free to ignore it if you don't feel like it's going to be useful or provide enough value. there were maybe some comments about, like, folks not liking his teaching style. [32:24]

That's more of a valid concern, but if you don't want to pay that much money for his course, if you feel like a 20 Udemy course is better, then go pay 20 for that course and move on. [32:36]

Mo: Yeah, I'm inclined to agree as well with Mark there. It's just, you do your research before you purchase something. I think he's abundantly popular where you can watch some videos online of Kent. See if you like his teaching style, if you don't like his teaching style, and then make an informed choice as to whether or not you want to spend several hundred dollars for it. [32:53]

I think trying to argue after the fact to say, hey, this wasn't great, it wasn't worth the price, well, cool, but, you know, leave a review for it, I guess, and move on. It's, a free market with this type of thing. Yeah. [33:04]

Carl: what? Like, I dropped out of college after a year. Each of those college credits was like 1, 500, 15 years ago. So I feel like I would have gotten much more value out of a course like this than I did out of any individual college course that I took. I don't know, I left that comment on Reddit and they did not find it compelling or I got a negative score. But that's my opinion on it. Like, education, in general, costs so much money. And the value to Cost for something like this to me seems pretty clearly at least worth trying I don't know if you're going for it Yeah, and in the comments to joshwcomo has a course out as well. [33:47]

Also seems really great Also a pretty similar price point, like curated education material from an industry leading expert. You don't get that for free. It's a lot of effort. It's hard to be an industry leading expert. It's hard to design a course syllabus. It's hard to produce that content. [34:03]

It's hard to distribute it. It's hard to, yeah. So I don't know. It's,they're doing it all on their own. These are independent educators in general. Like they are doing their own thing on their own time. Yeah. [34:15]

Mark: And, I mean, just, just as a related point, so I did all that work in the first half of this year to update the Redux Essentials tutorial in the Redux docs, which I did all that work for free, and I'm not charging any money for it. And, for the first time I actually tried tracking my hours. And I put in 80 hours of actual focused time, which on the one hand feels like it's not much, you know, like my first instinct is, well, that's only two weeks of work. [34:44]

On the other hand, let's face it, across a typical two week period, I don't actually put in 80 hours of focused effort in my day job. you're in your seat for eight hours, maybe, but you're getting maybe four or five hours of productivity tops. And like, that was, quote, just building off of an existing tutorial where I'd written the content and written the example app. [35:05]

I wasn't coming up with that stuff from scratch. I was converting it to TypeScript, figuring out how to add a couple new features to teach a couple new ideas and then, you know, doing the work to get the right commit sequence, and then turning that into code. Updated content. So, I mean, it was effort, but like, I wasn't doing all this stuff from scratch and that still took me like multiple weeks worth of focused time that I did for free. [35:33]

And so, I got a sense of the amount of work Kent was putting into version two of his course and like he was significantly revamping things. [35:42]

Mo: there's a comment in the Reddit thread, which I actually agree with quite a lot and I think it's the right approach with this, which is The person says, well, it is expensive and you can go through YouTube and find each of those topics and find like a tutorial video on them for free on YouTube. [36:00]

But if you have the money, what you're basically paying for is someone to curate that content for you. Summarize it, create a syllabus for you, and give it to you on a silver platter, right? instead of searching for that material, you're paying for that person's time to curate that material for you. [36:15]

The information is there for free, but you are paying for Kent's time and organization to come in and create something valuable for you so that you don't have to spend the time searching. So if you got the money for it, great, go for it. There's someone else in the chat as well that mentioned, which I think is a good point to put it into perspectivea lot of companies will let you expense stuff like this on like a training budget or, an upscaling budget that they have. [36:36]

So when someone like probably prices something at several hundred dollars, I don't think he's expecting indies to come in and all shell out several hundred dollars. I suspect the goal is to find like a midpoint price point where it's. Expensive for indies, but quite cheap for corporates to pay for a large number of licenses. [36:58]

And he does have a option to select multiple licenses and buy for your team. So I think that's probably where the pricing is coming into place. [37:05]

Mark: Yeah, sort of the training equivalent of targeting the enterprise market. [37:09]

Mo: Exactly. [37:09]

Mark: moving along touching on some drama. [37:12]

Web Components Are Not the Future

Followup to this from March 2020: Maybe Web Components are not the Future?

Mark: I think we might have mentioned some previous bits of the web components versus React thing that's been going on the last couple months. This started with a post from Ryan Carniato, the author of the Solid Framework. Where he said that Web Components aren't the future. [37:27]

And that spawned a whole lot of discussion after that. A lot of folks from the Web Components community were upset. [37:34]

Web Components Are Not the Future — They’re the Present

Mark: Someone wrote a post called, Web Components are not the future, they're the present. Which made a bunch of arguments, both technical and sociological, about how Web Components should be fitting in. [37:46]

Lots of debate in Twitter threads, Mastodon threads. I'm not on Blue Sky, but I bet there was probably some debate over there, too. [37:53]

Liskov's Gun: The parallel evolution of React and Web Components

Mark: there was one other article that really stuck out to me called the Parallel Evolution of React and Web Components. It's stupidly long, even by my standards. [38:01]

It's 11, 000 words. It's a very long read, and I had mixed thoughts on it. I thought the first third of this was a really good technical discussion about, Some of the web component's early specs came out even before React did. Both of them have evolved over time. The middle third devolves into the author kind of bashing on React for a while, and then it kind of finishes up with some more decent thoughts about technical aspects and how they fit into web application architectures. [38:31]

I'm not gonna suggest that everyone should read it, but there was some interesting background material, and at least the author put in actual time Writing this post as opposed to just, you know, random bashing of things purely on Twitter if you want to see some of the web components discussion that stuff's out there [38:48]

Carl: my understanding is that one of the biggest problems of web components, I've never used them, I understand them to be in, you know, Intended to be used as like leaf nodes, kind of like your, your design system. Like if you are going to build a design system in React, I think that web components advocates would say, no, no, no, don't build those components with React, build them with web components. [39:10]

And then you can use them in many, many places and many frameworks and yada, yada. My understanding is that web components have many of the same problems as trying to build your own design systems, where the hardest part is things like versioning. And if you don't get it exactly right the first time, it's kind of difficult to ship new changes to them. [39:29]

So it sounds like web components are still hit a lot of the same problems. They just kind of shift the context. And so you have to figure out like, when you're doing a design system in React, The problem is around versioning and like packaging. Like, do you do many sub libraries? Like, do you make your own like React modal component and your own tool tips and your own buttons and your own accordion tabs, whatever, or do you do one big bulk package? [39:54]

But then it's like, you end up with these like, well, okay. If you ship a change to this. Low level component used within this design system, like, how do you migrate all of the clients that are using that design system without doing like a big bang rewrite across dozens of clients? [40:11]

And like, that's hard. It's not trivial and it sounds like web components have that same problem But instead of versioning happening through semver in npm, it happens in this entirely bespoke Web component standard system and like that doesn't seem better to me. It's like you have to learn a whole new, Context, as well as dealing with the same problem. [40:32]

So, like, I haven't seen that discussed at all in any of these, you know, discussions. These, you know, when people are talking about the technical merits of Web Components, I'm not seeing, like, and here's why it works better for this reason. I also just really, like, the Web Components are not the future, they're the present article. man, I did not like it. I thought it was good. So, this is not a compelling argument. Like, you know, a quote from it that I pulled was like, they're not solid components, they're not React components, they're not Svelte components, they're not Vue components, they're standards based web components that work in all of the above. [41:04]

And that seems like a big assertion to make when the maintainers of solid, React, Svelte, and Vue are all saying, they don't work for us. So, I feel like you can't just say, they work in all of those, when the maintainers of those frameworks are saying, they don't work. And it doesn't really argue why they work, it just kind of asserts that they do. [41:21]

Mark: it's a little bit like a lot of the React arguments that were happening earlier this year, where there's like 30 different partially overlapping topics. And people are arguing about a different subset of them. [41:33]

So, in this case, the concerns are technological, some of them are ideological. Folks who prefer web components or advocate for web components tend to be the kind of people who like frameworks. They feel that frameworks are too heavy, they feel that frameworks have bad results on the industry, they prefer to, you know, kind of stay closer to the browser, you know, they use the platform mentality, and so they see large frameworks as sort of the enemy, and so anyone who is using a framework is kind of a bad person. a lot of the vocalness here is coming from these people who's like, it's a standard,therefore it's better.These frameworks aren't standards. I don't see a lot of people in the React ecosystem, like, actively advocating against web components. more of a, whatever, we don't care.So, worth noting that, you know, Ryan's article, came from his perspective more as a framework author, and similarly, Rich Harris, the author of Svelte had a number of complaint threads on Twitter recently, where he was talking about there's a bunch of really, really weird behaviors in browsers that only exist because the web component specs demand those, and that has caused problems for him as a framework author. [42:58]

Things like, Cloning domnodes requiring you to pass in an additional flag, but that makes the cloning process 30 percent slower, [43:08]

Carl: Right. And in contrast to that, the present article says, towards the back half of it, it says, I'm not a conspiracy theorist, but I find interesting the number of people who are and have been sponsored and or hired by for profit companies whose platform rely heavily on said frameworks. [43:25]

So it's like, I feel like the web components aren't working for us. Framework authors are making arguments like that. I'm taking a 30 percent performance hit because of the spec requirements to support these. Like that's a very precise technical argument. Not, I'm not a conspiracy theorist, but [43:42]

Mo: [43:42]

that sounds like, here's my friend's opinion about these guys. They're awful people. Not my opinion. I'm just quoting what my friends, I'm not a conspiracy theorist. That sounds pretty conspiracy theorist to me. [43:52]

Carl: Yeah. It's big, just asking questions energy. we should move on though. I think Mo, you said you have to duck out. [43:57]

Mo: I do have to leave, so I guess I can just say goodbye hereand hopefully see you all next month. So it's been a pleasure in all things react and react native and I'll see you all in the next one. [44:08]

Mark: we've got a bunch more stuff to get through, [44:10]

Announcing VoidZero Next Generation Toolchain for JavaScript

Mark: Evan Yu, the author of View and Veet and a number of other things, Has announced a venture backed company called VoidZero, which is quote working on the next generation of JavaScript tooling This might sound a little bit familiar. [44:24]

That was sort of the pitch behind the Roam tool set So in this case some of the things that VoidZero is working on correlate a lot with Things that were already in progress with the VEET framework. [44:37]

Oxc Transformer Alpha

OXC compiler

Mark: There's a Rust based JavaScript compiler called OXC, which also includes a linter and reusable parsers and things like that. [44:46]

So I believe that's now gonna be sponsored under Void0. There's a project called Rolldown, which is going to be a Rust based re implementation of the Rollup build toolset. So eventually the goal is to really make Vite a whole lot faster, ultimately. Vite currently uses a mixture of, I believe, ESBuild for local dev builds and Rollup for production builds. [45:12]

And so they're also trying to make the behavior more standard, or more similar across dev and production as well. [45:18]

Carl: Yeah, definitely seems interesting. Always down for stuff to core dev tools to be made faster. All right, cool. [45:23]

Updates from the 104th TC39 meeting

Carl: I'll move us on some new TC39 news. They just had a meeting and blog post I saw said four new proposals advanced to stage four and the list had five items in it. [45:33]

Promise.try

Carl: so there's promise. try, which is now stage four. It seems neat. It looks like it's basically a likeconvenience so that if you don't know whether a function is going to return a promise or not, you can give it to promise. try and then you can handle any errors that it emits as though it were a promise. [45:53]

And the advantage of that is that, you know, if you did something like promise. resolve. then and then execute that function, which would be a great way to achieve this behavior without a change to the language that would process it on the next tick. [46:06]

So it doesn't execute synchronously as, you know, line by line. It gets thrown to the event loop and then event loop comes back and executes it. So, you know, that's. Not always what you want. If you are trying not to do that, now you have a new tool to do so, which is promise. try. [46:21]

Sync Iterator Helpers

Carl: I also liked the sync iterator helpers. [46:23]

I think we mentioned this in a previous episode. Maybe not the last one, maybe the one before. But it's. Basically letting you do stuff like map, filter, reduce on iterable objects without Spreading it into an array first Which I think creates a copy. So like this seems great. You can now map over without the cost of Producing an array from it first. [46:47]

I love it. Here for it. [46:48]

Import Attributes

Carl: Some other ones that I didn't talk about Think about as hard there's import attributes which I think is like metadata for describing what you're importing, something like that. [46:58]

JSON modules

Carl: JSON modules. So you can import JSON files as modules without, you just kind of natively. It seems good. [47:05]

RegExp Modifiers

Carl: as well as regex modifiers. couple of new changes, five new things to the language. Seems good. [47:11]

Language Evolution “JSSugar” proposal

NullVoxPopuli on X

BrendanEich on X

Daniel Ehrenberg thoughts

Mark: And one other thing that came up at that meeting there was a presentation I think co authored by a number of JavaScript engine implementers at Google and Mozilla and a couple other companies. That is very long and complicated, and it's worth reading through, but as a high level summary, we've had the TC39 process for, like, 15 some years now, and, you know, we had the big bang change to the language with ES2015, and then a steady stream of new language features since then. [47:45]

And the expectation is that once TC39 finishes standardizing a given feature, Every JavaScript engine out there. Is going to end up fully implementing this. Now in practice, if it's basically V8 and spider monkey from, you know, from Mozilla, that's the majority of people as far as browsers are concerned, but there are other JS engines out there as well, and implementing all these new language level features takes time and effort, some of these engine implementers were actually saying, you know what, we actually. [48:19]

are thinking that maybe we shouldn't be required to implement every feature that is added to the JS language spec. Sometimes these things have performance implications, sometimes these things have actually caused security related concerns, It's not like a full blown proposal, but it's kind of like a what if we considered this kind of a thing. [48:42]

what if we sort of split the JavaScript language spec into things that are actually going to be implemented by runtime engines, versus things that are in the spec, and we agree it's part of the language, But would only ever be implemented by transpilers, like Babel or ESBuild or something like that. [49:05]

So that, the JS engines don't have to literally implement every finished feature ever. a number of folks felt this was probably a bad idea. I can understand some of the concerns that are being raised by the engine folks. But, splitting the language feels problematic. You know, certainly the folks who are, you know, kind of in on that, like, I don't want to have to use build tools to write my JavaScript are, are not happy about this. [49:34]

But, even knowing that, you know, some of these things won't make it into the engines and might not be able to take advantage of, you know, built in optimizations feels kind of sketchy. [49:43]

Carl: Yeah, I can definitely understand that though, like so many things, I feel like, I mean there are so many lingering polyfills and transforms and whatever that Babel and all of them are like still implementing, even though they are now part of the language, just because how do you know when it's okay to remove stuff like that? [50:03]

I can understand the motivation of saying like, look, this is the reality. We are still transforming this even though technically by the spec, we don't have to. I can definitely understand why they would see, just start saying like, this is a practical reality, pragmatically, this is what's happening. the standardization process should reflect that and acknowledge that some things will just live in the transformer. [50:25]

I can definitely understand that argument. But yeah, I guess that's also weird. Like it introduces a new like point of abstraction in the standardization process and like, what is JavaScript? that's weird. [50:38]

Mark: Alright, so, now we're in and we haven't started the lightning round. So, let's try to actually make this a [50:43]

lightning round, shall we? [50:44]

⚡ Lightning round ⚡

The Disappearance of an Internet Domain – .io

Mark: Moving along. So there was an article titled Disappearance of an Internet Domain. the TLDR here is that the io domain is associated with a set of islands in the Indian Ocean owned by Great Britain and Great Britain just signed a treaty to eventually hand those islands over to you. [51:05]

I think the island of Mauritania. And so based on international law, there's a chance that once this 3D handover is complete, there is no longer a separate territory. And if there's no longer a separate territory, then there's no legal reason to have a io domain associated with that. And so the article says that, you know, if we, if we've, Assume that these laws and practices get followed strictly, then hypothetically, five years from now, the io top level domain might go away completely. So that's up for grabs, but it's a legitimate concern. [51:46]

Carl: The intersection of geopolitics and tech debt seems bad. [51:51]

flying through a little bit. [51:51]

How to control a React component with the URL

Carl: So I saw a great blog post by Sam Zelikoff called How to Control a React Component with the URL. blog post makes the argument that it's a very common feature request. [52:00]

I think that it is not as common a feature request as it should be because it is the power of the web. URL addressability, deep linking, being able to open a URL and have it, represent the same page that somebody else is seeing. So I think that is a phenomenal goal to seek, and so more things should behave that way. [52:17]

just a pull quote from it that I think summarizes What makes that hard is the fundamental reason why we're heading down a bad road, he says that we now have two sources of truth for the search text. And that's exactly it, like, when you are writing React, you tend to have your source of truth be something in React state. [52:35]

But if it's in the URL state that it exists outside of React's Awareness, you know the universe that you've created for your app that is within react the URL state lives outside of that So it's very easy to accidentally duplicate state then you have a state synchronization problem and I also want to call out that problems like that are a Wonderful example of why dogmatic best practices can really easily lead you to broken apps [52:59]

Then if you use a form library, it's going to keep track of its own state. Then you have to do state synchronization between the URL and the form. That's a really easy way to get a lot of bugs. So if you follow the rule of always use a form library, you're going to run into state synchronization bugs if you try to implement this feature. [53:16]

If WordPress is to survive, Matt Mullenweg must be removed

Mark: one more drama related item, I'm really gonna TLDR this. The WordPress community is basically blowing up right now. WordPress founder and project company CEO Matt Mullenweg went on a seemingly unprovoked rampage. [53:35]

He is basically upset that one of the biggest WordPress hosting companies, quote, isn't giving back enough to the project. And there's all kinds of issues where Matt is both simultaneously the CEO of Automatic, one of the other bigger hosting companies. And the leader of the open source project and the nonprofit foundation. [53:58]

And it turns out that in some cases, he's the sole person who controls some of the key websites. There's been issues with him, basically hijacking a plugin that was developed by this other company blocking people from the Slack and all kinds of other Like, he's basically blowing up their community single handedly, and seemingly for no reason. [54:22]

And a lot of folks who had been very involved with WordPress are like, I can't be involved with this anymore. So, a lot of WordPress folks are actively looking to stop using WordPress and find something else. There's an extremely long, very well written post that lays out a lot of the details linked in the chat, called, If WordPress is to survive, Matt Mullenweg must be removed. [54:45]

It's long, it's complicated, but it's also a very thorough look at everything that's happened. [54:50]

Carl: Yeah. Oh man, there's so much to get into. There's so much that could be said about this, but yeah, it's,oh, this has been, this has built its own cottage industry of podcasts and interviews and blog posts. Yeah. It's also not really React. WordPress developer is like an entirely separate thing from web developer. [55:06]

So yeah, it's kind of not related to our main topic. [55:09]

Web Without Walls — Dan Abramov

Carl: we've had a couple of tangential references to Blue Sky. I love Blue Sky, I think it's really cool, I've been on it for like over a year because Twitter sucks and meh, I have opinions. [55:20]

But so Dan Abramov, who I'm sure some of you may have heard of once or twice, gave a really great talk. he's currently working at BlueSky as an app developer which is, I'm actually interested to speak with him a little bit more about that kind of transition because he went from core team, building React to now React consumer and I think that is just such a relatively rare Transition to make and I'd be really curious to hear not just like what he thinks about that transition as someone who's made it But also what Dan Abramov thinks of that as a very clear thinker and clear speaker butwe gave a really great talk about the app protocol, which is the underlying technology that BlueSky is built on top of and it hits a lot of really cool things that I personally have been thinking about for a decade about the future of social media and data portability and federated access. [56:14]

not just social graphs, but also to the actual data. I just think it's really cool. Like, I saw some people talking about, like, Oh, it doesn't matter if you have You know, you can always export the social graph because you have your contacts list. And like, that doesn't really matter. [56:28]

It doesn't matter if you have the social graph, if you have the connections between the people. If the people are not producing content, you know, if they're not interacting with each other on that platform. And I would boil down this hour long talk that Dan gave that is really good. And I think you should watch if you're interested in social media and building apps on social platforms. [56:47]

It really comes down to, like, it's not just an open source Twitter clone. It is an open network that people are publishing Twitter like data to, and no one can close your app off. You know, there is no way for something like the, Twitter X API Shut down, the Reddit API shut down. [57:10]

You can't do that because it's built on a federated decentralized protocol. it's not just a proprietary API. So yeah, I think that's really cool. This is a really interesting thing. I think this is going to be a generational shift in how social media operates. So yeah. [57:23]

Preact compat discussion

Mark: There was a Reddit discussion thread going and was looking into the compatibility of Preact with, you know, actual React and debating some of the pros, cons, and trade offs. And since Preact has been traditionally pitched as a React compatible library, worth looking at. [57:43]

Carl: Yeah. [57:44]

Content-visibility in CSS

Using CSS containment

Carl: There's some interesting stuff with CSS containment. It seems pretty, like, wonkish, deep in the weeds stuff to properly understand, but it looks really interesting as, like, a performance optimization for rendering. [58:00]

contain CanIUse

Carl: The bulk of it, as I saw in researching it for, you know, an hour and a half, I haven't really used it yet, is there's a contain and a contain visibility, you know, a CSS attribute now, that let you signal more precisely to the browser renderer, how much effort to dedicate to rendering a particular part of the page. [58:19]

So, you know, like, how I'm making sense of this is in React, if you're trying to choose whether or not to render something, for a long time the decision has been kind of like, conditional rendering, like, is the DOM in the page at all, or, like, display none. [58:34]

And you know, there's a lot of other, like, subtle variations around that, like, should it live in the accessibility tree as well, like, You know, there's a lot of subtle nuances to that. So this adds a lot more subtle nuances. Very exciting. But yeah, so it looks really interesting. It lets you constrain So that's kind of part of it, but it's also a little bit on like sandboxing. Like, I guess the contain element is maybe a little bit more on sandboxing. It's like, if you were to like render an ad into your page, you might be able to do it using this instead of an iframe. [59:07]

So, and still maintain the same kind of strong guarantees about how it behaves on the page, how it looks on the page. [59:16]

Mark: someone in the chat just said it's like, it's kind of like Shadowroot, and I think that's a little bit, like, along the right lines. Like, you're telling the browser that elements inside here aren't going to have layout interactions with the rest of the page. [59:28]

So, like, whereas, a normal element, depending on your CSS, might, interact or overlap or something with other parts of the page, might cause the browser to do, a bunch of additional checks against other DOM nodes to see if they in some way. And so contain tells it, nope, anything under here is scope, you don't have to waste time and effort checking locations versus the rest of the page. [59:50]

content-visibility CanIUse

Carl: Yeah, and something else they shout out in the docs about it is, like, really long pages using it to optimize, you know, rendering performance. If you've got a massive, massive amount of HTML, then just saying, like, nope, this is off screen, like, don't render it. If that makes sense they were saying that that would help you maintain performance on a huge page. [01:00:07]

But it also talks about like reducing layout shift. So I wonder if that is actually going to be like practical and useful, or if it just would just be like too weird to have to, I've, I've had to do that kind of performance optimization and. Cracking the size of the content being rendered so that you don't have it, like, you scroll down, something goes out of view and then like gets, stops being rendered and then everything on the page shifts. [01:00:31]

So you have to keep like scroll because what you were looking at just changed. I, I don't know. I don't know if that advertised benefit will actually be real. I don't trust it. [01:00:39]

How I Built My Blog • Josh W. Comeau

Carl: We mentioned Josh W Comeau earlier. He has put out a great blog post. How I built my blog. Looks pretty interesting. [01:00:45]

I, I just always appreciate little technical write ups of things like this. [01:00:49]

Mark: and like, it's more than just the blog. I mean, I think he goes into some details about the developer, the education platform and whatnot. But Josh always puts such care and effort into everything he builds. [01:01:03]

Carl: Yes, a consummate crafts person. So yeah, it's a good write up. He's very thoughtful about how he builds and how he writes. So this is really great. I have also built a large documentation site for a previous employer. And as I was reading this, I just saw so many problems that I remember dealing with in that. [01:01:19]

Like he talks about, you know, authoring content in MDX and the kind of weird errors you get when doing that. He talked about like doing syntax highlighting with Prism and how it can really explode complexity of, you know, just the amount of HTML on a site, which is a problem I had I built this whole thing, put all of this documentation on a single like API reference massively tall site and oops, it's 12 megabytes of just HTML. [01:01:45]

So I ended up having to like totally re architect how the syntax highlighting was happening because just it totally exploded the amount of HTML on the page. so he talked about using, like updating to the latest version of MDX and using Sheeky which is like a server side, Syntax highlighting tool that seemed pretty interesting and definitely sounded like it would have solved some problems. [01:02:04]

I had a couple years ago And he also referenced he's got a like interactive rainbow on the home page And You can edit how it behaves and that behavior gets synchronized across all viewers of the site simultaneously through PartyKit, which is near and dear to my heart. I helped set up their community a couple years ago. [01:02:23]

cool. It's a good read, [01:02:24]

Mark: All right. [01:02:24]

Types of React Components [2024]

Mark: And the final item for today Robin Wierich is another prolific React educator and author of useful tutorial learning blog posts. Thanks. And he put up a post called Types of React Components in 2024. it's actually a bit of a history lesson. It goes back and looks at the old style create class and mixins, the still newer but by now out of date class components, the higher order components pattern, and then the relatively modern function components, server components, and async components. [01:02:58]

So it's not something that's necessarily going to teach you to do things, but it's a useful look at and sort of like the evolution of React over the years. [01:03:06]

Carl: And apparently this is part of a whole series that he's doing updating his most popular blog posts for 2024. generally, I saw a couple of other ones and I wanted to add them, but I, oh god, we already had so many links. So, yeah. Definitely go check those out. he's a great writer. I have been reading his blog for 10 years and he just keeps putting out bangers. [01:03:29]

So yeah, definitely check it out. [01:03:31]

Mark: right. I think we're actually at the end. [01:03:33]

Carl: We are at the end. We've made it. Oh my God. You guys, you're still here with us. Thank you for sticking around for 80 minutes. Thank you so much for joining us. We'll be back on the last Wednesday of next month here at the live stage in Reactiflux or back in your podcast feed just as soon as we can. [01:03:48]

Lennart, [01:03:49]

Mark: Yeah. I got nothing this week other than I am diving into working on some RTK query features, specifically infinite queries, which is a complex thing that I didn't know about and I'm thankful that we're basing it off of how React query works. So My side project for a while. [01:04:08]

Carl: That was fun. Cool. We gather sources from ThisWeekInReact, Bytes. dev, React Status, Next. js Weekly, React. js, Subreddit and here in Reactiflux, mostly from the tech reads and news, If you see anything that you feel like we should talk about feel free to send it to us via email to hello at reactiflux dot com T M I R in the subject line. [01:04:28]

Job market: FRED data, Layoffs.fyi Help them know how smart you are. Alright, see you later.

This Month in React, September 2024: Async Components??, a React 19 cheatsheet, static Hermes, and trademarks drama

Reactiflux — Tue, 24 Sep 2024 16:00:00 GMT

New releases

Main Content

[15:08] Bulletproof React updated for NextJS
[15:52] New React Native Debugger
[18:05] Hermes new Runtime Bytecode Translation
React 19
- [22:14] React 19 Cheat Sheet
- [24:10] What’s new in React 19 (moreso a discussion of the evolution of the rendering model)
- Build-time Components
- You can use async functions for components in React 19??
  - Core team forgot to put it in release notes??
[26:22] A milestone for TypeScript Performance in TanStack Router
[27:46] "we’ve decided to make a few changes to ease the adoption of Next 15"
[30:07] Trademarks drama
- From Deno: JavaScript™
- [31:46] WordPress v WPEngine
  - [33:10] Trademark page diff seems targeted
[33:49] "You're writing a vite-based SPA. You need to add a few API routes (i.e., for authentication). What do you do?" -[36:43] Mo at Future Frontend: Dynamic UI at the Edge

⚡ Lightning round ⚡

Conferences (React, Javascript)

SquiggleConf Boston, MA USA Oct 3-4
RenderCon Nairobi, Kenya Oct 4-5
React India Goa, India Oct 17-19, 2024
React Brussels Brussels, Belgium Oct 18
Next.js Conf SF, USA Oct 24
React Advanced London London, UK Oct 25, 28
HalfStack London London, UK Nov 13
React Native London London, UK Nov 15

Carl: Hello, everyone. Thank you again for joining us for the September edition of This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. We're coming to you live in Reactiflux, the place for professional React developers, and we're supported by Infinite Red, a little bit more on them. I'm going to do something different this month. I'm going to do the ad read after our You know, quick hits at the start. [00:21]

Hello, I'm Carl. I'm a staff product developer and a freelance community manager here at Reactiflux, uh, where I run community programs like these events and help keep the community operating. [00:31]

This month we don't have Mark, sadly. He's in Turkey, um, I think. Not sure if he did a conference, but he just couldn't swing it this month. [00:37]

Mo: And I am Mo. I head the mobile team at Theodom. I'm quite active in the React Native ecosystem. Get very involved in a bunch of different conferences and some open source here and there. [00:47]

I organize the React Native London, community. And basically oversee a team of different developers who are specialized in React Native. So, happy to be here to chat, as always. [00:56]

Carl: All right, straight into some new releases. [00:57]

Node v22.8.0

Carl: We've got Node version 22. 8. I didn't see anything super big that caught my eye in this change. New Node, minor version released. [01:06]

Deno v2 RC

Carl: We've got Deno v2 release candidate coming out. It looks like this is coming out in Continuing the trend over the last couple months that we've discussed of Deno kind of walking back some of its opinions, they have gone pretty hard on Go style dependency management and a couple of other Go and other highly opinionated back end languages. [01:25]

They're kind of walking those back. Stuff like, they had been Encouraging people to use window instead of process. They are changing that in order to be more compatible with existing NPM modules. Just generally be more compatible across the ecosystem. Yeah, a couple of other things like that too, like making it easier to use with NPM. [01:41]

Generally making it more compatible, which I think is why they're walking back some of their highly opinionated opinions. [01:47]

Relay v18

Carl: We've also got Relay version 18. Are people still using Relay? I don't really have a good sense for its, I don't know, usage. I know, obviously, Facebook still uses, Meta still uses it, but, yeah, not sure how much community uptake it's had over the last three or so years. [02:01]

Mo: Not much on our side. [02:03]

Carl: But a change that should make it a little bit easier for people to start using, they have added IntelliSense for the Relay config file. Just getting started, I've tried to get started with Relay two or three times over my career, and just never got over that initial hump of figuring out how to get it working. [02:17]

So, uh, maybe some stuff like that will help. Make it a little easier to use. Not having used it, I can't really speak to the other changes they have, but you know, improve validation of argument types, an alias, catch, throw on field error. Cool. [02:28]

Redwood v8

Carl: There's also Redwood with a major release, version 8. Redwood is sort of trying to be the Laravel of the React ecosystem, sort of an all in one framework that does all the things that you need. Instead of making you find all the packages yourself to glue the bits together, which seems pretty cool. Yeah, this major release upgrades a lot of dependencies, adds Docker support, which I was a little surprised to see. I, I think of Docker support as not something a framework needs to, like, explicitly add, but cool. [02:53]

I guess maybe they're making it a little bit easier to just get running in that environment, which since Docker is such a widely used primitive, that makes a lot of sense. Seems cool. They talk about an experimental SSR and RSC setup, so if you're doing server side rendering, or if you're interested in server side rendering and server components, might be, should be easier. [03:12]

As well as adding support for background jobs, which is definitely something that an all in one framework, I think, I would expect to provide. So that's cool. [03:20]

Mo: The Docker support is really interesting because It's almost in direct, I want to say, almost opposing to how Next does it, which it seems to me like Docker is like, hey, you have a Docker image and you can basically use it to deploy your full stack web app into, into whatever cloud platform you want to use. [03:38]

Super easy, primitive, that's agnostic to whatever cloud provider you want, you self host it, you scale it up yourself, however you want, and our batteries included framework will just work. Whereas Next is notoriously difficult to be able to, uh, self host. So I just find that interesting. Maybe it's directly done as sort of a distinguishing factor compared to Next. [03:55]

I don't know, but I find it quite interesting. [03:57]

Carl: Yeah, makes sense. I have preferred to host anything I do in Docker for most of the last 10 years, so it's, that will make it easier. I'm interested in trying out Redwood, so having it better support my preferred environment will definitely help with that. [04:09]

Epic React v2

Carl: There's a new release of Kent C. Dodd's Epic React, version 2. The overview of the course, it's going to teach you React fundamentals, hooks, advanced APIs, suspense, advanced patterns, performance, and server components. I was a little surprised I couldn't easily find like a diff of what is being covered and what they're focusing more on, uh, between the old version and the new version, which I had been hoping to see. [04:33]

I have not bought it. I consider myself an epic React dev already, so I don't feel like the target audience. But yeah, they're doing a 40 percent off promo right now, so if you have an educational budget at work, definitely consider spending some of it on this. it's about 420 right now. Nice. [04:48]

Full price is 700, and I think it's jumping up there in about two weeks from time of recording, which is on the 25th. [04:55]

RsPack v1

RsBuild v1

Carl: Some kind of big news. RS Pack and RS Build both released 1. 0 in the last month, about two weeks apart. RS Build is like a Rust based build tool, if you have not paid attention to previous episodes where we've discussed it. [05:10]

A decent amount. And RSPack builds on top of that to provide a Webpack compatible bundler. I feel like this was all the way back to like 2014 15 when Webpack was new. I mean, Webpack really replaced tools like Gulp. I think I went straight from Gulp to Webpack, and it was a massive just step change improvement. [05:28]

It was clearly better in just doing everything. Uh, but It was really complicated to configure, uh, not the fastest tool. So like, almost immediately people were talking about ways to make it faster, ways to make it do the great things that it did in a better manner. I feel like, uh, especially in the web ecosystem, we love our tools to be fast and snappy. [05:50]

so a counterpoint to that, people have been interested in having a faster, better solution than Webpack, but the flip side is that Webpack does so much that it's just really hard to actually make a replacement. So I feel like this is a culmination of like a decade long process. [06:05]

project to produce something like that. So to get a Rust based natively compiled language build tool that provides drop in compatibility with an existing massively complex, massively used tool. Awesome. Seems really cool. [06:20]

Metro 0.80.11

Mo: So, speaking of bundlers and staying on the same thread, as you will know, React Native has its own bundler that, uh, is purpose built. [06:28]

or the use of React Native apps. Um, and it's called Metro. So, Metro just released a more of a patch than a minor although React Native's versioning is a little bit confusing because everything is a minor because they want to be able to do as many breaking changes as possible, but they released a patch and there was some insane performance benefits here, so They took the resolver step, which was a bit slow within Metro, and they made it around 15 percent, sorry, 15 times faster, and that made a massive difference. [06:56]

So when they ran it on the, uh, Expensify app, which is notoriously a large scale, open source React Native app, the total build time, was brought down from around 13 seconds down to about 3. and that's about 4 times faster for the whole build process, right? So resolving is just one step of it, they've made that significantly faster, but that makes a big impact on the overall build time. [07:16]

And so this is really cool, but one of the added benefits of this is because it's, it's, it's a, it's a patch here, it's actually not a breaking change at all. So you can use it 3 versions back, 3 major React Native versions back, and it kind of works. So all you need to do is just bump your dependencies and you'll get the faster resolving times, which is really cool. [07:34]

So big shout out to the Metro team, specifically, uh, Rob Hogan's been working on this. They did a really good job, and hopefully it just makes our dev tools a little bit faster, which we all love. [07:42]

Carl: Yep, yeah, right. Like I just said, we love our fast dev tools in the web ecosystem. Cool. 15 times faster in a patch release. That is rare. Very cool. [07:52]

Effect 3.8

Carl: Wish I could say more about this, but Effect has released version 3. 8. Cool. Effect seems really cool, but it's also got a really steep learning curve because it's basically an entire new, like, standard library and programming paradigm all at once. It seems really cool. What I've seen in it, it seems to take a lot of inspiration from functional programming tools like languages and environments like Elixir. [08:15]

Just encouraging you to build more like composable APIs? Yeah, we, again, we've talked about this a little bit in the past, so it, I, I won't fully rehash everything, but it's a huge, massive, steep learning curve that seems really cool and possibly worth it. So it's, you know, it's, I feel like I say this so many times every episode, but this is something that I'm really curious about, learning more about and using more and yeah. [08:39]

if you like functional programming in web, definitely. Consider looking at effect. [08:43]

Astro 4.15

Carl: We've got Astro 4. 15. Big change, they say that Astro actions are stabilized. Um, and it looks like they've swapped out how those actions are configured so that it's a little bit more concise. [08:54]

Uh, you describe the shape of the data that it receives and what to do with that data when you get it. Rather than treating it like a whole request where you then, like, do the validation and the error handling yourself. That's adding some opinions to it, but doing a validation schema and then providing a handler that receives valid data that conforms to the schema that you provided. [09:16]

Seems like a pretty solid abstraction point there. There's also some other things like, the astro islands pattern. you could previously configure it to load those islands asynchronously, idly, when the, when the tab is idle. Uh, and they've now added a timeout so you can set a maximum time that it will wait for your page to go idle. [09:36]

Uh, which seems like a nice, you know, 99th percentile performance improvement. If, if, if you're on a slow device that never goes idle, that's going to cause problems if you're only loading when idle. [09:45]

React Email v3

Carl: So we've also got a new major version of React Email, uh, version 3. 0. Looks like this is another, you know, release getting ahead of React 19. [09:54]

They have swapped out their rendering. So it's now async by default. as well as adding a new component library, improving performance. They added a superbase integration so that you don't have to manually, like, render and then copy the output into superbase, which seems nice. I'm a little surprised to see a new component library here, but I guess in an email environment there are just so many ridiculous constraints that, uh, I guess it makes sense that you need a specialized component library for that environment. [10:20]

But yeah, uh, React Email, if you're doing anything with emails, that seems like a pretty solid tool to use. [10:26]

React Native 0.76 RC2

Mo: So, I've kind of stuck the next one in. It's not really a release, but it's a release candidate, so it's kind of a blurred line, but we'll just go with it. The second release candidate of React Native 76 is out. [10:38]

So, when I say, for those who aren't in the React Native ecosystem, when I say 76, I mean 0. 76. It's just, it's so far up that we've just We just get rid of the zero because it's easier to say. But anyway, React Native, 0. 76, Release Candidate 2's out. Um, now, this will still take a few more weeks, at least, to, to land, but, this version of React Native is going to be, quite monumental because the new architecture will be the default. [11:02]

Going forward from this version. Now this new architecture is nothing new. It's been around, it's been talked about for years now. Um, contrary to the name, uh, it was new a while ago. Um, but it was a, it was a massive undertaking because you're basically gutting the internals of React Native, replacing it with React. [11:18]

Something that's totally different in terms of how the native layer is handled. And so you're needing a new rendering engine, you need a new way to interact with native code and the native APIs. And so what that's meant is that this, it's had this long tail of getting library maintainers, 3P libraries, and, and, All of these things ready so that app developers don't have that much of a pain with some of their libraries not working if they switch over to the new architecture. [11:43]

And so hopefully it's going to result in a lot more stability, some performance gains. We're waiting to see, but this is going to be a big release and you can still use the old architecture, but new one is the default. And it will be going forward. So, very exciting times, very monumental times. It's probably going to come with some teething pains as it does when you do such a major rewrite, but we're keeping our fingers crossed. [12:02]

They've put a lot of work into this. [12:04]

Carl: For sure, yeah. And as we've discussed many times on here, especially Mark, nobody tries really as candidates. So if you're using React Native, just At least give it a shot. See if there's any, like, obvious failure points, because, uh, open source maintainers love hearing about those growing pains as you're trying to switch over. [12:20]

This is a great opportunity to do it. We're RC2. We're running out of candidates. [12:24]

Sponsored by Infinite Red

Carl Vitullo: We are brought to you by Infinite Red, our main sponsor right now. They are an expert React Native consultancy that I am quite pleased to be a partner with because they are like authentically showing up to support the React Native and React ecosystems in like really meaningful ways. [12:40]

They organize conferences, they host the largest React Native podcast, they publish the largest React Native focused newsletter, and they're Just really excited to work with them. Other than being great people who do great things in the community, they also, well, more precisely, they're a team of about 30 people, mostly developers with mostly greater than 10 years of experience. [13:01]

So they actually work with your team to help you develop an expertise in building React Native. So if you are. Building something with React Native and need a little help hitting the ground running on that, definitely reach out to them because they are great people who will help you do good work. [13:17]

Upcoming conferences

Carl: Moving on to some upcoming conferences. There's a lot, so I'm gonna just do, like, half of these, because we're already 15 minutes in. Mark and I will both be at SquiggleConf in Boston, Massachusetts, October 3rd and 4th. it's organized by a conference buddy of mine, Josh Goldberg. [13:32]

I'm looking forward to it. It should be, should be a great time. It's going to be at the Aquarium in Boston, which seems great. there's also going to be RenderCon in Nairobi, Kenya, October 4th and 5th. React India is in Goa, India, October 17th through 19th. And React Brussels in October, uh, 18th, Brussels, Belgium. [13:51]

There's also Next. js Conf in San Francisco on the 24th of October. [13:55]

Mo: And then, if you're in London, ReactiveLabs London is happening on the 25th of October for the in person day and the 28th of October for the remote day. I will be there. I'll be doing a talk about React Native there, so if you're around, come and say hi. [14:07]

Carl: Uh, I think Mark will be there too. Sadly, I will not. I will be in Mexico City, having a great time. There's also Halfstack London in London on November 13th. [14:16]

Mo: And then this is the announcement that I've been waiting a long time to make on this conference, but we have the two month rule, so we're trying to remain impartial. [14:23]

We are doing the first ever React Native conference in London. So, RNLConf, React Native London conference, effectively, is happening on the 14th and 15th of November. in London, central London at the Brewery, which is this like old building from the 1800s, uh, where a bunch of the monarchs of the UK went and visited, and it was a big festive place. [14:42]

Anyway, it is now an events venue that we have gotten, and we're gonna have a lot of core people from the React Native ecosystem there. Charlie Cheever, the founder of Expo, is gonna be there. we have a lot of different cool folks from Meta, from Amazon, and from a bunch of different places coming to share. [14:54]

Ideas and talks with everyone. If you are interested in joining, we have also, I've just made a discount code for anyone who listens to the podcast, so it's TMIR. Feel free to just grab a ticket that way, and hopefully you'll save a little bit of cash as well. [15:05]

Carl: All right, into our main content. [15:08]

Bulletproof React updated to include Next.js

Carl: Bulletproof React got updated for Next. js. This is a simple, scalable, and powerful architecture for building production ready React applications, it describes itself as. Um, so this, I guess it's a set of example apps, to help you get started. I wanted to call this out because it seems like a pretty good resource. You know, it's a question we get in, you know, Reactiflux all the time. [15:30]

It's like, hey, where can I find a, production grade application to use as a reference? I want to learn. I want to learn more about how they do it. and yeah, this seems like a good resource. It's, it's a whole ass. They have an example app written in a couple of different frameworks, so they have updated it to use the app router, I believe, and yeah, seems like a great resource. [15:52]

New React Native Debugger

Mo: Cool. So, this month we had React Universe Conf happening in Wroclaw in Poland. I was there hosting the conference and there was a lot of React Native stuff that was announced. now they were kind of s I want to say soft announcements in some capacity because people kind of knew about them already. It wasn't anything like mind blowingly new, but it was really cool to see the output of a lot of hard work that people have been anticipating for a while. [16:14]

So the first one was the new React Native debugger. just a little bit of context on some of this. Debugging in React Native has been a pain. Anyone who's built with React Native knows that, like, debugging has been a mess. Like, you could use a bunch of different tools in conjunction with one another. [16:29]

Some of them worked for certain things, other ones worked for other things. there was a point where, you know, you used Flipper for a while, and Flipper wasn't great. everyone really did not like Flipper, and so it got deprecated because it was just not really usable. so it was a lot of different tools that you needed to have in your tool belt to be able to effectively debug. [16:45]

the new, the team at Meta tried to kind of, go from a fresh blank slate and say, hey, how do we build a really good debugger that resembles some of the experiences that people are used to with other frameworks and other other languages? And so they built a completely new debugger that's fully built on the Chrome DevTools protocol. [17:00]

And it looked like it was, from what we saw at the conference talk, it looked like it was a lot more reliable. It addressed a lot of the minor pain points that you felt when you were trying to debug. And I guess the big thing was that we finally have reliable breakpoints. Which was a real pain to get working within React Native. [17:16]

So, really, really, exciting stuff to, to, to get. And it should be public soon. So we're excited to get, get our hands dirty with it and, uh, and try it out. [17:25]

Carl: Getting into the Chrome debug protocol seems like such a massive improvement here. Instead of using some kind of like bespoke debugging system, I love that you can just actually tap into a widely used tool that a lot of people are familiar with. [17:38]

Mo: And it makes sense in terms of the direction that, you know, React Native is going, which is they want to make it more friendly for the web devs to be able to come in and build native mobile apps, right? So you don't want to force React web devs to learn a totally new dev tool framework or a model. You just use the tools that people are familiar with. [17:55]

And so I think it was a great choice, and it looks good. So we'll wait for it to come into the hands of all of us, and then we'll play around with it and make it better over time, and it'll be a great time. Oh, yeah. Cool. [18:05]

Hermes new Runtime Bytecode Translation

Mo: So more stuff from React Universe Conf. Another announcement, almost like a thing that we saw into, was, Hermes, which is the JavaScript engine that's used with React Native on most apps, now has a new runtime sort of bytecode translation. [18:19]

Now it's very complicated and complex, and the talk explains it far better than I do, because it's some really low level stuff, so you kind of need to wrap your head a little bit around assembly and some, some stuff like that. A little bit of context, just to contextualize this, I think helps. last year there was a talk by the Hermes team at React Native EU called, uh, talking about this, this new concept of Static Hermes, which was, could we take JavaScript code and, uh, Make it typed native code, and sort of compile that down so that you get near native, if not just native performance, using C Um, and so that was a really cool concept, and the benchmarks that they ran from their early tests was showing that it was massively faster to execute JavaScript code because you were basically executing native code there. [18:59]

it was a really cool approach of, you know, How you bypass the restrictions of JavaScript's runtime. But there were some limitations in the sense of how people use React Native in practice. And, you know, people use a lot of different features like over the air updates, which means you can kind of replace your JavaScript bundle. [19:17]

with a server and add new code to a mobile app without going through an app store. So that's like a big feature that a lot of people use in React Native. And so this wouldn't work with the current model of static Hermes. a lot of different build tools. when you, when you pass your code through something like Babel, it loses the type annotations. [19:32]

So how does that then get compiled down to, you know, typed native machine code. It was hard to really wrap it into the ecosystem and how people are using and developing React native apps. So, Intermediately, the Hermes team's been working on sort of runtime bytecode translation, which means, Okay, well, if we can't do this at compilation time, could we? [19:52]

Find ways to boost performance at runtime and compile things to native instructions without needing to necessarily rely on things that you might only have at compilation time, like your type annotations. whilst being able to still let people do things like over the air updates. And so that's this. [20:08]

concept of the runtime bytecode translation. This isn't landed anywhere and it will take a long time. It will probably first go through Meta's internal process of testing and seeing how it works within their apps. And then if it's stable, it'll phase, in a phased approach, get drip fed to the rest of the community. [20:24]

So it's going to take a little bit of time, but it's really interesting stuff and it can have massive performance gains when you're running really computationally heavy tasks that you would previously run in JavaScript, using this bytecode translation. [20:35]

Carl: Interesting. Okay. So I remember Hermes. That's like, that was like a V8 competitor. It was a runtime for JavaScript optimized for React Native. So it sounds like this is going to be doing. Like, you know, all these JavaScript runtimes, they always have various levels of, JIT, just in time compilation happening. I remember, you know, V8 has like TurboFan, and I don't remember any of the other brand names. [21:00]

But, okay, so this is sort of a new type of JIT sort of thing, where it, like, over time will create a I don't know, like codify the bytecode so that it doesn't need to do the JIT every single time? Is that, am I understanding that right? [21:14]

Mo: That's what it seems like to me. Again, there's a blurred line between static release that happens at compilation and this, which is kind of JIT. [21:22]

And this is a little bit, there is some level of caching that you can do, right, because those instructions don't change commonly. They're changing once every time you kind of do an over the air update. So, um, a lot is still unknown. it's just more, showing the possibility of if you have unannotated JavaScript code, how much could we, compile it down to bytecode and still get some of the performance gains that you can get out of something like Static Hermes. [21:46]

Which would be a lot more aggressively, compiling things down and, and it has a lot more context because of having access to the source code and being able to run this at compilation. So it's a more practical step that they're trying to address with how the community uses React Native and how probably Meta uses React Native internally as well. [22:03]

Carl: That makes sense. My mental model here is aggressive caching of JIT bytecode. Definitely will be curious to see how that shakes out as it starts to roll out. Exits idea stage and enters production stage. [22:14]

React 19 Cheat Sheet

Carl: All right. A bit of stuff on React 19. Man, I'm a little sad Mark isn't here today because there's a couple of new resources and some, some new info that I'd love to get his take on. [22:23]

But yeah, so Kent C Dodds put out a React 19 cheat sheet and it looks pretty great. You know, even just kind of casually skimming this, I learned several new things that I hadn't realized. Even, even as someone who considers himself to put a decent amount of effort to stay on top of things as they happen. [22:40]

I still learned about like four or five new things from this cheat sheet. Probably the single biggest one is that since when could we use async functions? Like we apparently in React 19 you can do if you know you're doing a function component like you do now you can just mark that as async and it will return a promise like async functions do and React just like knows how to handle that. [23:01]

That makes a lot of sense. I am curious how that, I guess where I really wish I had Mark to talk about. This instead of me is, I don't really understand the difference between the suspense primitive of like throwing a promise versus now this where you can just return a promise. Yeah, this is a really great single page cheat sheet, you know, eight and a half by 11 with a bunch of great resources. [23:25]

You know, it talks about like what the use hook is for, talks about the better error reporting, resource preloading APIs, so you can make sure that You know your fonts and your images are available. Loading style sheets with precedence. Uh, I, something I had known was that React 19 will let you render like scripts and style sheets just within your output and it will hoist them up to, you know, be Loaded as appropriately, something I didn't know is that you can signal their precedence, their relative precedence. So, you know, default precedents or high precedents. This is, this is a base level style sheet that needs to apply to everything versus this is a, you know, could override those base styles, things like that. Really great resource. Kent C. Dodds, of course, putting out lovely educational resources. [24:10]

What’s new in React 19

Carl: There's also a great, What's New in React 19 blog post put out by Vercel. Mostly the bulk of the content talks about how the rendering model for React has evolved over the years. Uh, I thought this was just a really great breakdown of why. [24:25]

We've gone from why React is pushing server components and like what the value proposition there is. It has a really great series of diagrams showing like, all right, this is how, this is how data fetch and resource loading happens in a single page application versus an SSR application versus now what React server components unlock. [24:47]

And just showing like the data flow of like server to client. And it really does a good job of illustrating those waterfalls and how those waterfalls end up hap end up being imposed by the rendering model and how server components change that rendering model to enable fewer waterfalls to happen. another good resource talking about new things unlocked. In React 19, there was a good post talking about build time components, which is distinct from like server side rendering or server components, pretty related to like, you know, SSG, static site generation. Yeah, static site generation. [25:22]

If you say that acronym SSG, the presumption is that that refers more to something like Gatsby, which is a one time, it doesn't have a server, it has static generation. so this, this discusses build time components, I think sort of as a complement to server rendering or server components, where as part of the build step, as part of, you know, your transpilation and compilation and whatever, you can statically generate. [25:47]

Some of your, some of your resources, some of your pages, some of your components. I thought that was a good call out as new technical capability. Returning back to my earlier thought on the cheat sheet, I saw in real time Kent C Dodds learning that you can return a Promise from a component. So just like earlier this month, he put out on Twitter like, oh, you can, you can just do this. [26:08]

You can just mark it as async. Amazing. So just to drop the link to a good thread in there, but really good. I'm not sure what the difference is between that. You know, classic suspense, throwing a based thing and just doing an async function. [26:22]

A milestone for TypeScript Performance in TanStack Router

Carl: Moving on. TanStack had a really great post discussing a performance optimization they did for TanStack Router. [26:29]

This is a very different type of performance optimization than most that we see discussed. This is not like runtime performance. This is not, you know, how the library works while you're using it. This is an optimization they did in your editor. So like, as your site grows larger, because their routing is type safe, it's actually doing a lot of, it's actually throwing a lot of work at the language server, at the TypeScript language server that your IDE is running. [26:56]

In this blog post, they break down a pretty complicated site that has, I think they say, This example has 400 route definitions with validated search parameters, and I, you know, it takes like three seconds for the language server to get back to you. So, like, if you're writing code and you, like, open IntelliSense to see, like, oh wait, what, what query strings can this receive? [27:17]

Like, sitting and waiting for three seconds as it parses that. Not great. but yeah, they talk about improvements they did for that. And just because, like, type safe routing is super cool and super difficult, and like, how often do you think about the performance of the TypeScript language server in your IDE? [27:34]

For me, never. so just seeing this, like, Deep technical write up of how they've improved the performance of something that I have never thought about is pretty great, pretty interesting. [27:46]

"we’ve decided to make a few changes to ease the adoption of Next 15"

Carl: Cool, an update on Next 15, which is not out yet. Yeah, they said, we've decided to make a few changes to ease the adoption of Next 15. [27:54]

We'll relax the React 19 requirement for the Pages router so you can upgrade in your own time. I appreciated this because my read on the Next. Ecosystem right now is that there's a lot of attention being paid to the app router, but technically that's Bleeding Edge. That's the newest, still experimental grade, kind of. [28:14]

So they encourage you to use it in the same way that open source maintainers encourage you to use release candidates. But strictly speaking, the Pages router is still where the business is. So seeing them talk about sending support for that into React 19 seems good. Bethany, for the app router, we decided not to block on the general release of React 19. [28:34]

So I guess that they are looking to release. Finished non-experimental app router, before or, or they're decoupling released app router from the React 19 release. [28:45]

Mo: Does that mean that they would ship the app router apps if you start a new app, router app with Next, that it would just be using like an RC of React 19, or would it just be using React 18 unless re 19 gets launched? [28:59]

Carl: There was some confusion a while ago because they were using release candidates by default. Uh, I don't remember where that landed off the top of my head right now, but I think that's right, but I can't answer you definitely. I'm just looking at this thread again and I see someone ask a very similar question. [29:15]

How do you relax the React 19 requirement when React is bundled into Next? Do you maintain a release for 18 and 19? Did not get a response, so not sure. This is kind of continuing the trend of version confusion with Next and React, like, it's not very clear. [29:33]

Mo: I wouldn't personally feel comfortable using an RC with Next, if, Next 15, if they say, we've tested it, it's stable, but then at the same time, I wouldn't trust it to work well with React 18 either, because I would suspect they haven't tested that enough. [29:46]

So, you're in this no man's land where you're like, do I just stay on Next14 until it's actually, you know, stable and React 19 is launched and out of our seat? Interesting questions. [29:57]

Carl: Yeah. Confusing, but a similar, you know, vein of confusion as we've had for like most of 2024. That confusion has not been cleared up. Confusion remains. [30:07]

Trademark disputes!

Oracle, it’s time to free JavaScript

Carl: There's been a couple of trademark dramas this month. Like, I don't know why all the trademark stuff is coming out of the woodwork right now, but um, the Deno team put out a, like an open letter requesting that Oracle release the trademark for JavaScript. and this is one of those like, Funny, weird like quirks of history that not that impactful, but it is still a thing. [30:27]

Like Oracle owns the trademark for JavaScript. Like the reason that the TC39 standards body that determines what JavaScript is technically They are not building JavaScript. They're building ECMAScript, which ECMA is an international standards body. And the reason it's called that is because Oracle owns the trademark on JavaScript. [30:47]

And they have done nothing with it. They have not enforced it, as far as I know, in a decade. They have not They haven't done anything with it. So, yeah, the Deno team is asking people to sign a letter. so, I would encourage you to do so. I have signed this letter. I think it's great. I would love for Oracle to be less in the web ecosystem. [31:04]

Please. [31:05]

Mo: I don't think I knew that Oracle had the trademark for JavaScript until I saw this. I don't know if you did, but it was, uh [31:11]

Carl: I did know that. I mean, it's one of those stupid things. Like, it's called JavaScript because they were trying to, like I don't know. Ape on the popularity of Java back in the 90s, even though there's no relation. [31:23]

So it's like, I think because I, I think it was something like in those early days, Oracle was like, no, no, no, no, hang on. You can't call it JavaScript. We own Java. And so I think that's how they ended up owning it, but then they didn't do anything in JavaScript or in the web because they're Oracle. And yeah, so it's just one of those like weird quirks of history. [31:40]

So this feels like writing a wrong to me in a way that like, yes, please, let's resolve this tech debt, like get out of there. [31:46]

WP Engine v Automattic

(https://x.com/justinferriman/status/1838356417482514842)

Carl: And this is a little far afield from React, but there's been some WordPress drama. my, I don't do WordPress. I've never worked as a WordPress developer. So this is a little bit of me catching up on stuff. [31:59]

But so my understanding of this is that there's. the WordPress maintainer is Automatic with two T's, and then there's a, another company called WP Engine that seems to, I think they're like a services business, I think, so I guess it's, it's a little bit like If there were two Vercels, like an official one that was actually maintaining Next, and then another one that, like, didn't actually do very much of the maintenance, but also provided all of the same, like, hosting, just with a different set of defaults. [32:26]

And if that other actor that did not do all the maintenance work and the development work was making way more money than the people actually building on it. So, that's my understanding of the difference between Automatic and WP Engine. Is that WP Engine makes a lot more money and contributes less. so the CEO of Automatic has gone on a bit of a tear and it seems not great to me. [32:48]

They are now accusing WP Engine of like infringing on the trademark of WordPress by way of introducing confusion. Like people think that WP Engine is, you know, WordPress engine and they think that they play a larger role in the ecosystem than they actually do. But they've done so, Automatic has done this by sending a cease and desist that doesn't, I don't know, it seems not great. [33:10]

Trademark diff seems targeted

Carl: There's, um, the trademark page, I saw a diff, like, just in the last week, like, as they sent the cease and desist, Automatic updated the trademark information page from saying, you can do whatever you want with the abbreviation WP, to you can do anything you want That doesn't add confusion to the ecosystem, and also WP Engine is not great and we don't like them. [33:30]

And so it's just like they specifically called out this organization that they are sending a cease and desist to in updating their trademark guidelines. It's just like, Oh, Oh, okay. I feel like if you wanted to make that argument and you needed to make it 10 years ago when they started. So it's drama, some big drama happening in WordPress right now. [33:49]

"You're writing a vite-based SPA. You need to add a few API routes (i.e., for authentication). What do you do?"

Carl: I saw a great. Twitter post from someone who is doing like a sync engines and lots of other like local first type development that I find very interesting. He posed the question, you're writing a Vite based SPA. You need to add a few API routes like for authentication. What do you do? And got a lot of engagement and I thought it was just a really good discussion. [34:11]

I wanted to draw a little bit of attention to it just because a lot of great opinions coming out in there. I have recently been playing with. Cloudflare workers. And to me, they hit this really great niche that is perfect for this. Cloudflare workers are basically like serverless architecture. You, you know, set up a handler, and like, you don't do any of the infrastructure administration yourself. [34:31]

It just, you know, starts up and stops. But they do it way better than anyone else that I've played with so far. Like, you know, I've used Lambdas and some other similar, you know, serverless architecture things, and all of them have, you know, Awful, terrible, brutally bad developer experience. Like, uh, this is a couple years out of date, so I think it's changed, but I don't think it's changed that much. [34:53]

I, I just remember having to upload a zip file into AWS in order to test, in order to deploy changes to a, to a lambda function that I had written. And like, There's no environments, there's no way to say like, this is in test, this is in production, there's no way to test locally. So then like, this entire serverless framework spun up around that to try and make it better, but like, oops, it didn't actually work that way. [35:14]

It didn't, it didn't match functionality, so it didn't serve the purpose. So yeah, I think for me this, the answer to what do you do if you need to add a few API routes is set up Wrangler, and then in locally and use Cloudflare Workers. [35:28]

Mo: You stole the words from me, basically, which was I would use Cloudflare Workers for a few reasons, like AWS's serverless model means that you're still managing your infra to some degree, like what region do you place your serverless function? [35:41]

How does it scale? How does it, you know, uh, how do you do API routing? Maybe you'll need to add another layer, with API gateway in front of it. It's not, like, Straightforward. And so Cloudflare Workers for me was like truly serverless because it's just a function that runs close to the users, somewhere on a CDN, and you get access to run some JavaScript somewhere on the edge, which is really quite cool. [36:03]

there's some stuff around, you know, like I think that there's some trade offs, like you can't use Node packages, it's a custom runtime, and you know, if you want to use a specific router, like there is Hono as an example that you can use within Cloudflare Workers to do API routes. Auth is not as straightforward, I'd say. [36:19]

So, like, for small tidbits And, you know, tasks that I just need something that runs without me worrying about it, definitely Cloudflare Workers. And so, shameless plug, I did a talk with, a very close friend of mine, Samuel McLeod, who now actually works at Cloudflare and is on the Wrangler team, so he works directly on Workers, and we were talking about how do you Move your front end code to live on the edge in Cloudflare Workers with minimal effort. [36:43]

Mo's talk at Future Frontend 2024

Mo: So it's a, it's a, it's a talk that we did in Finland this year. Um, so, I'll share the link. but basically the gist of this was what if you could just take your use states that you have inside of your app and change it to use server state with a different import from a third party library and it would automatically just pop it inside of a durable object on the Cloudflare Worker environment. [37:02]

And so there's a lot of cool magic and a lot of cool primitives that they've got that lets you build on top of, and I really like it. If I wanted to build a little bit more full fledged, you mentioned Auth as an example, maybe. I quite like Superbase these days. It's relatively simple. You know, you can run Deno functions within it. [37:18]

It also has a database model, which, you know, is managed for you. It's kind of, for mobile devs, I think it's The better Firebase, which, you know, Firebase promised to be the way that you don't have to write back end code for a mobile dev, and then it really wasn't great. and I think Superbase is a little bit nicer, and it's also relational DBs, which I prefer personally, so. [37:38]

It kind of just works. [37:39]

Carl: Pretty much the major constraint of a serverless runtime is they pretty much have to be stateless because, you know, they start up and they spin it down. So if you want to persist state, you need to maintain some kind of other infrastructure to, you know, some kind of database or something like that, which like, as soon as you start running your own server for a database or something like that, like, well, why not just put the code on there too? [38:01]

And Cloudflare workers give you both durable objects. Which are interesting and cool, and I haven't played with them very much, because they also have a key value store that is like this. Dead simple. It works basically like local storage with shared context between invocations of your workers, which just like, if I'm doing something small that I don't want to spend like a week setting up new infrastructure and then don't want to have to maintain that over time, like something that I can just forget about for two years and then come back to and go like, what, how, how the hell does this work? [38:33]

Workers. Love it. I guess I should while hyping Cloudflare and workers so much, I should probably mention that they are like basically the only stocks that I individually own that isn't in an ETF, because I like Cloudflare. But yeah, that's, I don't know if I have a conflict of interest, but. [38:50]

Mo: That is a vote of confidence, Carl. [38:51]

Carl: I'm trying to put my money where my mouth is. Or, you know, now I'm putting my mouth where my money already was. ( both laugh) [38:57]

Mo: is this some sort of, like, ramping up stock prices? I don't know. Yes, yes. [39:03]

Nitromodules released to the public

Mo: There's just a very quick update on NitroModules, which we talked about last month. And so, uh, NitroModules is this way to run faster native code from React Native. [39:12]

And, uh, it's now been released to the public. And so a few people have been playing around with it. William Candillon, who builds React Native Skia and now React Native WebGPU, or WGPU, so to speak, is now using it on his project, and a few other people I know are experimenting with it. So we'll see some cool results, and I think it'll hopefully improve the performance of the React Native ecosystem as a whole. [39:31]

NodeJS adds an experimental permission model

Carl: Um, Node. js is taking a cue from Deno and they are adding a permissions model. I think this is super cool. I thought the permissions model is something that Deno got right. I think it's just very interesting to, rather than just allow all the permissions that your process has, being able to signal to the process, what this code is going to need to access. [39:56]

Um, I think that's a, I think that's really good and interesting and useful, especially in alternate runtime environments like workers, like serverless environments and things like that. An example where this would be useful. I remember a couple of years ago, uh, someone in Reactiflux set up a little five project allowing anyone to execute code from within the chat. [40:15]

Yeah. Um, so you could just, you know, like, use some chat command with a code block. They had set up a bot that would pull that code block in, execute it, and spit out the output. They were able to do that, I believe, because of Deno's permissions model. Because they could guarantee that the code only had access to this very tight sandbox. [40:32]

You know, if you're running code from arbitrary people in a chat room, that's very dangerous. So you need an effective permissions model. So, um Now we have that. Now Node. js has that. Uh, maybe not relevant for most people, but especially if you are working on something that would allow, or that would benefit from allowing your users to run code, run arbitrary code, Node. js now supports that better, at least. [40:54]

TypeScript with React styleguide

Carl: This isn't new. I don't think I, I have, no, it's undated. I don't know when it came out. but I just crossed my radar and I like it. It's a TypeScript style guide. they have a, they have a react appendix that I, I thought was pretty neat. And just, I love a good style guide. [41:09]

Another common question in Reactiflux is like, what are the best practices? Well, there's a lot of practices. Some of them are worse than others. Some of them are good generally in all circumstances. Some of them only make sense in a very narrow range of circumstances. [41:23]

So just like, what are the best practices is a very difficult question to answer. And I think this TypeScript style guide does a pretty good job of Outlining a decent range of them. You know, some of them are opinionated, like it talks about project structure and like how to organize your source code and like, okay, there's a lot of ways to do that acceptably. [41:40]

but something in the, you know, the first thing it talks about in the React Appendix is like required versus optional props. And. It calls out props as a discriminated type, which is, it's so good. Instead of having a props object with a bunch of optional values, doing it as a group of different, you know, fully formed Types. Uh, so like, you know, the example they give is like a status indicator. Instead of saying like data, you know, error, status as like optional props, just saying like, no, no, the success status has a status value of success, data with this type, whatever. Then the loading status has, says this That's so much better. Like that is absolutely a best practice. So, um, Good resource, I enjoyed it. it had a couple of, maybe it's just because its opinions align with my own opinions, but I thought it was a really good resource. Definitely recommend it. And also, more generally, on the subject of style guides, I think a style guide is a wonderful resource to bring into your company. [42:44]

Uh, the most effective teams I've been on have had a style guide document that was routinely updated. Just, uh, if. I think it's a really great anchor point for technical discussions. Like, if you have a technical argument with your team about, like, we should not be doing this, this is bad. Argument should have an output in the form of a PR to a style guide. I think that's really great. [43:05]

Inside ECMAScript: JavaScript Standard Gets an Extra Stage

Carl: Not new news, but a good resource. We've talked briefly in previous months about the TC39 ECMAScript standardization process. You know, there's four stages, you can present an idea in stage one, then if you do X technical work, it gets to stage two. Stage three is like, basically standardized, but it's not shipped yet, and stage four is like, fully shipped. [43:27]

There has been a problem over many years of a lot of things getting stuck at stage two. The transition between Stage 2 to Stage 3, and then like, oh, we found a new problem in Stage 3, so we gotta ship it back to Stage 2. Just like, the delta between Stage 2 and Stage 3 has turned out to be very, very large, in a way that has made it difficult to ship some of these proposals. [43:50]

Just like, If it gets shipped back down to stage 2, that has some problems. So this article from The New Stack just did a really good job of explaining more of that history than the half assed summary that I just gave, and talks about the stage 2. 7, you know, sub stage that they added relatively recently. [44:09]

It sounds like the gist of it is that if you've written tests for your thing, then getting bumped back all the way back down to stage two, like, calls into question the validity of those tests. And stage 2. 7 resolves that problem to make it a little bit clearer about what that means. If you're curious about, you know, if there's like, if there's a, proposal that you've been following and are curious about the standardization process. [44:30]

Um, I just think this is a pretty solid resource explaining the history. [44:34]

Remix The Web from mjackson

Carl: cool. I came across a fun project from Michael Jackson, from the Remix team called Remix the Web. Michael Jackson, Ryan Florence have been so involved in the web React, in the React ecosystem for so long. I have always. I've respected them greatly as people who, like, they don't just try to solve a problem. [44:55]

They try to solve a problem in a way that makes sense, given the primitives available on the web. So it's not just trying to do everything in JavaScript. Like a lot, a lot of Java, a lot of React libraries I've seen, they end up, re solving a lot of problems in JavaScript that you might not need to if you just leaned on the web platform a little bit harder. [45:14]

And some of that is because of aspirational support for React Native. If you solve it in JavaScript, then it can work not on the web platform. So like, there's trade offs to doing that. The trade off is that If you write in JavaScript, like, it's probably going to be slower. It's probably going to be worse in some way than if you can use a native, you know, web platform feature. [45:34]

That is the backstory for why I'm particularly interested in this. So, Michael Jackson is putting together a monorepo of modules that are narrowly scoped to do one thing and do that thing well. An example of this that I remember him talking about Years and years ago, in the context of React Router, is they built React Router on top of a primitive, on top of a wrapper they made around the history API. [45:59]

So it's like, in trying to make a router, they found all of these weird, nasty edge cases around managing history, managing scrolls position, things like that, and found the platform feature to be highly deficient. as a, you know, mode of interacting with that. And so they made a wrapper abstraction around that to make it easier to deal with. [46:19]

And so my understanding is that this Remix the web monorepo project is a bunch of those. So like in, if they find, A rough and grody, web platform feature, they write a wrapper around it, and into this repo it goes. So, uh, I'm interested, it seems curious, it seems pretty cool to me, I have certainly found a lot of platform features that don't do quite what I want, so, uh, I'm, yeah, I'm paying attention to it. [46:41]

Seems cool. [46:42]

Replacing React code with CSS :has selector

Carl: And somewhat related to the idea of solving things with JavaScript, I saw a good blog post titled, Replacing React code with CSS colon has selector. The gist of it is, I'll pull a quote. Until recently, we couldn't select objects in the opposite direction of the CSS cascade. You know, CSS is top down. [47:06]

You can get, you can start from the top and it gets more specific. So you can say, in all of these elements that are under this type of parent, style it this way. But you can't, you couldn't say previously, in this parent, if it has this type of element within it, style it this way. It was a, it was sort of a, you know, unidirectional control flow in that way. You could style descendants based on their parents, but you couldn't style parents based on their descendants. And the CSS Has Selector enables you to do that, which I have run into so many situations where I wanted to do that, and you just can't. You just couldn't. So, uh, you end up having to solve it with JavaScript to like add a little bit of state to communicate whether some element is within it. [47:51]

And yeah, so the CSS has selected something I've been wanting for a really long time, and I really appreciated that. I'm seeing it framed as, here's all the things you can stop doing with React because of this CSS feature. And yeah, it's written by Nadia Makarevic. I hope I'm not mispronouncing that. She also wrote a great book on React as well. Yeah, just really, I really enjoy her writing. She seems like a great writer and seems to pick good topics. I like it. [48:19]

Performance Optimization Strategies for Large-Scale React Applications

Carl: And last lightning round link, just going to call out a Reddit thread. I've started, I set up a thing to pull in top posts from Reddit into the tech reads and news channel, and it's served us some good stuff. [48:31]

I like it. But yeah, somebody asked the question, somebody asked about. Performance optimization strategies for large scale React applications and it got a decent amount of response. So I just thought that was a good, I just wanted to call attention to a cool thread full of a lot of opinions. It seemed like a good thing. [48:47]

I didn't really see anything that like massively caught my eye as like, this is the right thing to do. But it did get quite a few Lengthy explanations of how some person or another has done performance optimizations at work. Uh, and that was always a big part of my work. My career has always, I've put a lot of emphasis on performance optimizations. [49:08]

Wanted to call that out. Go read it. It's good. [49:10]

Outro

Carl: Cool. Alright, that's everything we got. thank you for joining us. We will be back on the last Wednesday of October here in the live stage or back in your podcast feed just as soon as we can, if that's how you listened. We gather sources from This Week in React, Bytes. [49:23]

dev, React Status, Next. js Weekly. The React js subreddit here in Reactiflux and direct from those publishing articles. usually on Twitter, maybe on blue sky, maybe on RSS feed. Lots of things. If you see anything newsworthy, uh, definitely let us know in the tech News and reads channel of Reactiflux. [49:39]

Or send it directly to me hello@reactiflux.com, uh, with TMIR in the subject line. It's an acronym for the show. I read literally every email that comes in, even the spam. So yeah, if you've got a hot tip, send it to me and I'll 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 on Spotify, which helps us, Rank? [50:01]

I'd say stay in the rankings, but like, we don't rank, so, you know. Or, you know, post it on Twitter, send it to your co workers, stuff like that. Appreciate it. Thanks for listening. [50:08]

Mo: Always fun to do this every single month. Thanks, for having me, and hopefully I'll see you all at some point in person, somewhere, maybe at the, uh, RNLConf. [50:15]

Till next month.

This Month in React, August 2024: Matt Pocock taught us to make modules, RN is faster, iterator helpers are cool, JSR/Deno going sour

Reactiflux — Mon, 26 Aug 2024 16:00:00 GMT

Main Content

⚡ Lightning round ⚡

Quick hits

[50:51] Job market
- FRED data
- Layoffs.fyi
[52:06] New releases
[54:20] Conferences
- React Universe 2024 Wrocław, Poland Sept 5-6
- JSConf Chile Santiago, Chile Sept 5-7
- UtahJS Conf Salt Lake City, UT, U.S.A. Sept 13
- React Alicante September 19-21
- JSConf Ireland Dublin, Ireland & Online Sept 25-26
- SquiggleConf Boston, MA USA Oct 3-4
- RenderCon Nairobi, Kenya Oct 4-5
- React India Goa, India Oct 17-19, 2024
- React Brussels Brussels, Belgium Oct 18
- React Advanced London London, UK Oct 25, 28
[57:09] Outro

Carl Vitullo: Hello folks, welcome, thanks for joining us. This is the August edition of This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. We're coming to you live from Reactiflux, the place for professional React developers. We're supported by Infinite Red, a consultancy that exclusively works in React Native. but more on them later. [00:22]

Hello, I'm Carl. Uh, I'm a staff product developer and freelance community manager, here at Reactiflux mostly, where I run community programs like these events and the star helpers, and build tools to help keep the community operating. [00:34]

Mark Erikson: I'm Mark. most people know me as the Redux maintainer or that guy with the Simpsons avatar, and I am currently an engineer at Replay. [00:42]

Mo Khazali: And I am Mo. I head the mobile team at Theodo, which is another React Native and just generically tech consultancy. I'm also the organizer of the React Native London community and super excited to be here as always. [00:56]

Sponsored by Infinite Red

All right. Mark, you want to start us off? [01:53]

React 19 progress

Mark Erikson: So, last couple sessions, we talked about how React 19 had been delayed due to what has been known as Suspense Gate, where the React team had made a change last fall to pre rendering behavior for multiple nested suspense components. [02:07]

So that instead of doing them in parallel, it effectively does them in serial. And people complained and said, we rely on these existing behavior, you're going to make a number of people's apps slower. And there was an outcry, and the React team had been ready to release React 19, and instead they backed off and said, "okay, yes, we see this is a big deal, we are going to figure out how to change the behavior." [02:30]

But, the original PR that got merged was pretty complex, they've continued iterating on the internals. So it's not nearly as simple as revert the PR, it's we need to iterate further on the internals and figure out how to re implement some of the older behavior on top of the newer code changes. [02:48]

https://github.com/facebook/react/pull/30800

Mark Erikson: There's been a thread where people have been trying to ask for updates, and the last comment in that thread a few weeks ago was, well Stay tuned to this thread for updates, but no indication of actual work. And so finally, within the last week and a half, I've seen a couple PRs where there is actual evidence of work being done on this. [03:07]

Uh, Andrew Clark filed one PR that's added a feature flag that would later be added to gate this upcoming work. And then he just put up a PR a couple days ago with what looks like the initial implementation work for this Suspense sibling pre rendering behavior. I'm not sure if it's basically just this one PR, if he's working to split it into further PRs, or what the actual status is, but there is an actual PR with actual progress, and no idea how long it'll be before that gets merged, how long things will stay in beta or RC, but there is public evidence that they are actually pushing forward on this, and if you look at the code, you can see some of the complexity of the implementation work, like it's not just You know, one flag that gets turned on and off. It's a bunch of additional logic internally to make the older behavior possible. [03:57]

https://github.com/facebook/react/pull/30684

And meanwhile, I've been very interested in this part. Sebastien Mårkbage had been spending, you know, really most of his last couple of years working on the server side aspects of React. Server components and a lot of the HTML, you know, related pre rendering work, but he's actually turned his attention to the React DevTools in the last month and a half. [04:17]

And he's just been putting up a whole series of PRs, refactoring the guts of the React DevTools and making a whole bunch of improvements. And so two of them in particular, he's actually implemented what looks like React DevTools support for showing server components as part of the tree in the React DevTools. [04:37]

https://github.com/facebook/react/pull/30798

Mark Erikson: And along with that, what looks like a feature for being able to view the source of server components from React DevTools on the client side. This is something that I had always wondered, like, when are they going to get around to doing this? Like, we've supposedly shipped this production ready feature, and yet there's no way to really debug or view server components. [04:56]

So to me this is a pretty big deal. [04:58]

Carl Vitullo: Yeah, definitely. Dev tool support has always been so good in React that calling it, you know, production ready when there isn't that dev tool support seems a little surprising. So yeah, cool to see that coming. I'm a little surprised to see that they are actually able to get like the source of server components into the client seems cool. [05:16]

That PR is only a hundred lines added, 35 lines removed, so that seems very easy if they had a lot of support. [05:23]

React Native 0.75

Mo Khazali: So, next up, React Native version 0. 75 has been released. Now, this has been one of the most sort of subtle and quiet releases of React Native I've seen in a very long time. There's a lot of sort of minor improvements under the hood that's happened. [05:37]

The first thing is that we have a new version of Yoga. So, Yoga is the layouting engine in React Native that basically handles Your JavaScript code being translated to native layer drawing on the canvas. And so it's now got support for, so, so recently a couple of versions ago, we got support for gap when you're dealing with flex like layouting, and now there's also percentage value support for for GAP as well. So it's getting closer and closer to what you can do on the web. Another sort of update within this version is that you've got new architecture support that's getting more and more mature, and so you see that some of the libraries that previously didn't have new architecture support are getting more and more. [06:12]

Positive support within the new architecture paradigm. And also, um, what you see is that tools where you can see the list of dependencies that you have now also mark whether or not new architecture is supported within it. It seems like we're kind of gearing towards finally having the new architecture as a default with the next release of React Native, which would be a pretty big deal. [06:31]

But again, we've been saying that for a little while, so I'm not holding my breath, but I'm very, very cautiously optimistic about that. And then the last big thing within this version is that a couple of versions ago, again, they announced that you should use a framework and they suggested Expo as kind of the only option really that's, that's available currently. [06:46]

And so we see a few movements that are coming out of that announcement. One of which is that the CLI tool React Native init is now being sunsetted in some capacity and moved to a community CLI. So. By the end of the year, so December 31st onwards, when you run the commands react native init, they just will no longer work, um, and you'll be guided either to use expo or to use the community fork of the CLI that will be maintained by the community. [07:11]

But this is kind of a, let's just move it to the side. And wait for it to reach its demise type of thing. Which is, that's fine. That's kind of the direction that it's going towards. But it's just something to keep in mind though. [07:21]

Carl Vitullo: Yeah, sure. Shades of create react app sunsetting. Commonly used tool that's just gonna slowly fade away. [07:28]

Mo Khazali: Yes, exactly. Very much so. [07:30]

How to Create an NPM Package

Mark Erikson: Alright, Matt Pocock, who's probably best known for a lot of his articles and courses on how to use TypeScript properly, has actually put together something adjacent and published a very long, detailed article on how to properly create and publish a package on NPM. This is an extremely detailed and very step by step guide that goes all the way from, you know, literally create a new Git repo to creating a package. json file, some of the fields you would want to define in there, setting up tools like TypeScript and Prettier, and one of the more complicated pieces, how to actually define the JavaScript files that are used in terms of the package exports. [08:13]

https://blog.isquaredsoftware.com/2023/08/esm-modernization-lessons/

Mark Erikson: Now, I spent a very large portion of 2023 trying to figure out a lot of this stuff for myself, because in today's JavaScript ecosystem, figuring out how to publish packages that properly support things like both ES modules and common JS modules is an absolute nightmare. [08:32]

And there's all kinds of different permutations and different runtimes and environments and other things that you're going to run into. This guide isn't going to cover every different use case you'll run into, but it is a very, very good detailed look at a lot of the common things you would want to do to set up a reasonably standard package setup in today's environment. [08:52]

So definitely worth looking at. [08:53]

Carl Vitullo: Yeah, definitely. I have needed something like this many times. I've always kept track of generally each change in the ecosystem, but then when I, you know, actually sitting down and needing to write a new package and remembering which changes happened, what the current state of the best practice for setting up a new package are is always Very difficult. [09:12]

So I'm really excited to have this. It's, I think your post from 2023 was like the first time I had seen somebody try to articulate what best practices for publishing a, you know, like professional quality NPM module looked like, and it's so weird. It's gotten so strange. [09:29]

Mark Erikson: It is so painful and so bizarre. [09:31]

Now I will, I will say I will say like a lot of the pain comes from Node, not allowed to import CommonJS into ESM, I can never remember which way it is. Um, like, you could do A into B, but not B into A. I just don't remember which way the limitation was. But the last couple versions of Node 22, I believe they've finally started to implement valid support for going both ways without any errors. [09:59]

I can't remember if it's behind a flag, but at some point that version is going to become widely used enough that we can maybe, in five years, start to go past this. [10:10]

Carl Vitullo: Hopefully. Yeah, I had actually just seen a tweet somebody put out complaining about a similar thing where, I think they called it a cardinal sin of CommonJS, but it was conditional exports. [10:20]

You could put what you exported behind a flag. [10:23]

Mark Erikson: Yeah, I think that was probably Ketanaito, the author of MSW. [10:27]

Carl Vitullo: Correct. Arya in the chat saying, can't import ESM from CommonJS, but can import CommonJS from ESM. [10:35]

Mark Erikson: Yep, that sounds right. Yep. [10:36]

Implementing React from Scratch

Mark Erikson: So I've always been a very big fan of articles that try to build a miniature version of a real library from scratch and kind of walk you through, here's the kind of functionality, here's what it actually looks like internally. Here's some of the pieces that you might consider. These are really, really good for both understanding the mental model and you know, kind of peeling away the black box and like understanding what's actually going on inside of these libraries. So I've seen a few different good articles along that line for both, you know, React and Redux and, and, you know, bundlers and other tools over the years. [11:11]

So someone named Robbie Prusin just put out a really, really good new example of this implementing React from scratch that walks all the way through the process of creating elements um, modifying the DOM, putting, and putting all the pieces together. Really, really good post. Definitely recommended. And so, along that line, two other earlier posts that I'd recommend. The one I've pointed people to for me, for years, was from Rodrigo Pombo back in 2019, Build Your Own React. And then swyx has a classic post on how React hooks work by building your own version of hooks in 30 minutes. [11:45]

Carl Vitullo: Yeah, also a huge fan of this kind of, like, first principles, understand how it works by making your own miniature version of it. Reminds me of, like, in the physical world, building a model. You're not going to use it for something for real, necessarily, but this gives you a really clear mental model of what's going on under the hood. [12:04]

Vercel adds retention periods

Carl Vitullo: I'm going to throw this in. This is maybe a lightning round tier post, but I'll show you right now. Vercel announced that they are going to allow you to configure retention periods for your deployments. I saw Guillermo Rauch post on Twitter about this and saying it was something that people have been requesting since he released, now, the precursor to Vercel. [12:25]

So this is a feature that goes back nearly 10 years of people requesting it. And just like generally, retention periods, I feel like they're underrated. I feel like they're super powerful and just really good for a lot of things. Being able to configure how long data sticks around, I think, is a bit of a superpower. [12:42]

It's one of the things that, like, once you figure out how to make use of it, it just lets you do a lot of really good, powerful things. I have an affinity for them because my first full time job was doing tech support for a backup server, and so learning retention periods and how the retention policies were structured was a big part of my early tech career. I think it's cool. It seems good. [13:03]

Waku 0.21 adds Server Actions support

Mark Erikson: All right. So we're continuing to see folks try to work on building out React server component support in various frameworks. Uh, you know, Redwood's done some work. The remix folks are trying to work on things and one framework that's been plugging away kind of quietly is Waku, which is the brainchild of Daishi Kato, the author of Jotai and Valtio and maintainer of the Zustand library. [13:27]

They have just released version 0. 21, which now includes support for server actions. We're still at a point where Next is really the only, like, full, you know, quote unquote, production ready implementation of React server components and server actions. But it's good to see that other frameworks in the ecosystem are getting closer. [13:47]

While I don't know the overall status of WACU, like, it feels like it's starting to get a lot of the pieces fleshed out. And, you know, worth at least looking at. I mean, probably not ready to use in production yet. But it's an alternative approach to server components that'd be worth investigating. [14:02]

Mo Khazali: Quite interesting that on their website, when you scroll down at the very bottom, it has a big sponsored by Vercel. Which seems quite funny, given that it's somewhat a competitor to Next in some capacity. [14:13]

Mark Erikson: I was talking with Tanner Linsley and he said that like, Vercel has actually been doing a lot of work to both, like they, they sponsored, React Rally, the conference at the last minute, and they're even sponsoring some of the work on TenStack Start, I believe. [14:24]

Carl Vitullo: Yeah, they are definitely all over the place sponsoring all sorts of stuff. So I guess they're just generally investing in the React ecosystem. Here for it. Let's distribute VC money. [14:34]

Mark Erikson: Yeah, very much so. [14:35]

Redux Essentials tutorial updated

Mark Erikson: Okay. Next up is an item that is very near and dear to my heart because this has taken me like the entire calendar year in one form or another. [14:44]

In fact, I think I actually published this, might've even been like the day after our last recording in July, but you know, hey. So Redux Toolkit came out in the fall of 2019. In the first half of 2020, I wrote a brand new tutorial for the Redux docs that I dubbed the Redux Essentials Tutorial. [15:02]

And it was about 25, 000 words, and it covered how to use Redux Toolkit to build a plausibly realistic example app. And it taught Redux Toolkit for the first time as the default way to use and build Redux applications. And so that has been the primary Redux tutorial for the last four plus years. [15:23]

But it was starting to get a little bit outdated in a couple ways. While I still think that the original version of the tutorial was, frankly, a really good piece of work and something I'm very proud of. I saw in retrospect that I could have done a better job explaining various, you know, Redux concepts. So, at the start of this year, I set out to do a pretty thorough modernization and update pass on that tutorial. [15:46]

I did the work to convert the existing example application to TypeScript. Start to finish every single commit. And then I added some additional features and examples to demonstrate newer Redux Toolkit features that did not exist in 2020. From there, I went through and did a very thorough update on all the content. [16:06]

Improved a lot of the explanations, moved pieces around. Ended up adding about 9, 000, close to 10, 000 words of overall content, not counting the content that got changed and shifted and moved around. So, a month ago, I published the finished update to this Redux Essentials tutorial. So, it is now TypeScript start to finish. [16:27]

Which is something I spent a lot of time, I had spent time debating it out in the past. You know, I've always been concerned that adding TypeScript into the mix this early is going to add more learning overhead. [16:38]

And that's still the case. But ultimately TypeScript adds so much benefit, and it's how we want people to learn. to use Redux, that I decided it was worth it to just do the whole tutorial in TypeScript all the way through and try to explain the pieces as I went. So, it's live, uh, it's now up to like 50, 000 words, it is incredibly comprehensive, covers effectively all the APIs in Redux Toolkit and explains Enough about how things work that you can follow through and use it and understand most of the why. [17:11]

It doesn't go into how things work internally. For that, we still have kind of the lower level Redux fundamentals tutorial that explains, you know, like, how does a Redux store work, or how do some of the pieces connect together. But this is the way we want people to use Redux, and, you know, I'm pretty I'm biased, but I think it's the best way for people to learn Redux. [17:32]

So I am very excited to have that out. It took me multiple months of effort to try to put that together. [17:38]

Carl Vitullo: Nice. Cool. 50, 000 words. You could sell that as a book. [17:42]

Mark Erikson: Pretty much. [17:43]

Carl Vitullo: all right. I will pull us onto our next one. [17:46]

TS 5.6 RC

Carl Vitullo: TypeScript 5. 6 has a release candidate. Seems cool. Just going to call out a couple of cool things. [17:52]

Something that caught my eye was the disallowed nullish and truthy checks. It's practically a linting rule, really. It just helps catch stuff that are pretty obviously bugs. Like, a good example they called out was if you accidentally switch the equals and the greater than in the, you know, trying to do a greater than equal comparison. [18:10]

Oops, that's an arrow function, which is always going to be truthy. And so now TypeScript will give you an error for that. This expression is always truthy, you probably didn't mean to put that in an if. That just seems pretty useful. They talk a bit about other situations where they do allow, you know, constant expressions, but truthy expressions will now warn, which seems really great. [18:31]

https://github.com/tc39/proposal-iterator-helpers

Carl Vitullo: I also liked the iterator helpers. It looks like they're pulling in a stage three proposal for, you know, ECMAScript, JavaScript, which I'm a little surprised by. You know, I, I thought that they generally wait for things to ship. [18:43]

Mark Erikson: Stage three has usually been their target. [18:45]

Carl Vitullo: Yeah, okay, cool. Good to know. But yeah, iterator helpers, it looks like that feature generally looks to be a recognition that people want to use iterables as if they were arrays, and so it adds a lot of array type, you know, functions to iterables. [19:01]

So you can do things like map and filter and things like that on them. So that's super great. I'd love to see TypeScript adding support for that because that looks really great. I have tried to do that a number of times and been really annoyed that I had to spread it into an array first before using map. [19:16]

So that's, I'd love to see it. [19:17]

`expo-dom` released

Mo Khazali: So, let's switch gears a little bit into some React Native news. So, a couple of cool things. First off, Expo DOM has been announced. So, now you've got a whole bunch of different ways to do code interoperability between web and mobile, uh, and all things in between. So, you now have React Strict DOM, there's React DOM, there's Expo DOM. [19:36]

It's getting very confusing very quickly. But, really, the gist of all of this is, Expo's been really pushing this narrative of you want to be able to use a single code base to target web and mobile at the same time. Part of the challenge that will come up with a lot of people will be, well, I already have my web code base and I already have my React Native code base and combining these two together is going to be a bit of a tough egg to crack when you're dealing with a massive length in migration. [19:58]

This is one of the things that they want to target with this, which basically is that they want to allow you to use DOM Primitives directly within, your React Native applications. So you put a use DOM directive at the very top of your file, and then that basically means you can start using DOM in there, and what it does under the hood is it basically constructs a web view and renders those DOM elements instead of real native elements. [20:17]

Now this is quite powerful because it kind of means you can mishmash a little bit of DOM in places where you already have some code that's using React DOM inside of a React Native code base. And in theory, if your code is responsive and behaves well on mobile web, then it'll kind of work as you expected within your React Native app. [20:33]

There is a lot of disclaimers within this in terms of how your data flow works and all of the different things that come with that, you can't, you know, render children within it. It's very primitive rendering at the moment. But, it's a path towards migrations, if you so need it, desperately. It's not a long term thing, I think it's a very short term, temporary, here's how we just get a fully functioning app out in the meantime while we slowly add native views into our application. [20:56]

Carl Vitullo: Ah, interesting, okay. This is a stopgap they're not necessarily looking to have people build full React Native applications using web primitives. [21:06]

Mo Khazali: Thanks. It's more of a migration thing. So, you know, I've worked on a number of apps. In fact, I'm working on one right now where it's a hybrid app. [21:13]

A lot of companies will have hybrid apps where they have some of it in React native, that's native views. Some of it are web views and you have to use a web view inside of the native app to render some of the screens because, you know, they didn't have the time to build that out in a native fashion. So this is kind of just streamlining that process a little bit. [21:28]

I think it's just to try to entice people to come over to the dark side of the native world, and then hold them hostage afterwards. Jokes aside with all of this though, I think it's a, it is a migration path. It is very experimental, it's nowhere near production ready, it's just being brewed as we speak this month, um, and they've released a bunch of demos and it's now officially on their docs, but it's very much with all of the disclaimers of you shouldn't use this yet. [21:49]

And it comes with a whole bunch of limitations. [21:50]

Carl Vitullo: Reminds me of Cordova and things like that. I'm a little surprised to see Expo doing something along those lines. I thought we had generally agreed that just like flapping a web view in a native app was not great, but okay, cool. [22:01]

Mark Erikson: So just to make sure I follow the technical train here. [22:03]

So roughly speaking, you write a line or two of code that looks like it's just rendering. Another React component, but under the hood, it's actually creating a whole web view, attaching it to the native layout, injecting the JavaScript code into the web view, and then actually rendering a web component, a React DOM component inside of that, right? [22:24]

Mo Khazali: Exactly. That is exactly what it's doing, yeah. Layers of abstractions on top of layers of abstraction. So I think this will be around as a migration path. I think this is a small side project that they're just whipping up to make it easier for people to adopt the universal app paradigm, which is, you know, I want to have a single code base for all of my platforms. [22:40]

I think you really want to focus on React strict DOM if you're thinking about the long term of your app, if you want to go down the route of having a universal app. This is just a temporary stopgap if you happen to have code in the web world that you want to easily use and migrate over to the native world. [22:56]

Carl Vitullo: Sure. Yeah, right. I guess I still had the strict DOM in my head as you started talking about this and it threw me off. Definitely a, uh, a subtle but significant boundary between those things. Okay. Interesting. [23:08]

Mark Erikson: And to recap for people who might not have listened to the last couple, last few episodes, React strict DOM, on the other hand, is adding more web like API capabilities to the React Native platform. [23:19]

So you write more code that looks like React DOM for the web, and it makes your React Native code basically read as if it were web code. [23:27]

Mo Khazali: Because the, the current status, and I guess maybe going a little bit further back into the context of this, we've had React Native Web for a long time, which allows you to basically take React Native code and run it through almost like a translation layer, uh, with almost like an interoperability layer that lets you render those native views and native texts on the web. [23:44]

So this is, this has been around for years. It's like pretty much been there since the launch of React Native a few months after they kind of, somebody launched this project who now works at Meta. But that was a very big bloated piece of, of a dependency that you would add to your web app. So then React Strict on was like, can we, can we kind of find a way that's in the middle that uses the web based APIs, also makes it easier for web developers to come into the React Native world, translates them down to native views. [24:06]

But also has a minimal overhead to use that same code on the web. And so, this is pretty much the exact opposite of that, but it's sort of a temporary stopgap. [24:15]

Carl Vitullo: Yeah, interesting. Okay, so if, like, React Native Web from, you know, ye olde days was asking web developers to write code like React Native developers And React strict DOM is allowing web people to write what looks like web code, [24:31]

Mark Erikson: Native code that looks like web code. And then this is this, eh, let's just shove a web view in the middle of our, all of our native views. [24:38]

Carl Vitullo: They're covering all their bases. They're trying everything and seeing what works best. Cool. All right. [24:43]

Mo Khazali: Where there's a will, there's a way. [24:45]

Carl Vitullo: We've got a lot of wills going on. [24:48]

Mo Khazali: There's many wills going on here. [24:50]

Carl Vitullo: Neat. Very neat. [24:51]

Nitro Modules

Mo Khazali: Let's move on to Nitro modules because this has been a big thing in the React Native ecosystem in the last month. Again, a little bit of context because I think this will help everyone kind of understand and set the scene. So, a few years ago with the old architecture, when you wanted to access native layer code, you would need to use a native module. That used something called the bridge and the bridge would basically serialize some JSON or some, some sort of JavaScript objects, send it across a bridge as we like to call it. And that data could be used by the native layer to be interacted and run some native operations. And that's how sort of the JavaScript layer and the native layer used to communicate with each other. [25:23]

That bridge caused a lot of issues because you had sort of this one pathway to communicate between the native layer and the JavaScript layer and it caused slow apps and many issues and a lot of library maintainers were incredibly frustrated because it meant that if you use their library in a certain way, it would completely bog down people's apps and they were getting a bunch of issues around how their library is slow or React Native in general as being slow. [25:43]

So then the new architecture tried to create a better way to interact between the JavaScript layer and the native layer. And so that's where TurboModules came into place. So the idea with TurboModules was you would create a TypeScript interface to define the type of functions and values that you want to communicate between the JavaScript layer and the native layer. Then it would run through some C code gen to generate the connection layer between the native layer and the JavaScript layer. And then you could write native layer code and use that with what they call turbo modules, which was the name for it. [26:13]

That was a much more neat and streamlined way to communicate between the JavaScript layer and the native layer. That's a massive step up from the old architecture, and now Mark Roosevee, who is one of the sort of like people in the React Native ecosystem who's known to create some really cool native layer libraries that work really well, has now been playing around with this idea of creating an even faster way to communicate between JavaScript and the native layers and to write native layer code as, as a React native developer. [26:39]

And he's calling it Nitro Modules and he's created a lot of fun puns out of them. For example, if you wanted to generate a Nitro Module, you run Nitrogen, which is, uh, quite fun. Um, [26:49]

Carl Vitullo: Oh, my god. [26:50]

Mo Khazali: It's great. [26:51]

There's, this isn't really public at this, it's not very clear a lot of the stuff that works under the hood. I think it's getting released and drip fed as we kind of speak this month, but just some comparisons that he's run with Objective C based turbo modules compared to Nitro modules is that it's apparently like 10x faster, so 220 milliseconds in a benchmark that he ran versus 20 milliseconds. There's also another way that the Expo team have created Expo modules. [27:16]

We're going, we're seeing a trend here, right? Like the React Native Ecosystem likes to invent and reinvent different ways of doing the exact same thing, whether it's with the strict DOM stuff or with this, but anyway. So then you've got Expo modules, which is slower to Turbo modules. And then now there's Nitro modules, which is apparently the fastest of them all. [27:31]

So we'll see how this plays out. It's yet another approach of trying to handle this native to JavaScript communication. We'll see if it, if it actually pans out and how it, how it goes on, but promising signs at the beginning, and a lot of people seem very excited about it. [27:43]

Carl Vitullo: Yeah, super neat. Throwing a bunch of shit at the wall and seeing what sticks, trying a bunch of different approaches. [27:49]

I feel like that naturally flows out of where React Native sits in the world because it has iOS, Android, web, macOS, Windows, well, you know, it gets touched by so many different developers. And so I feel like where web and React can get a little bit like monoculture a little bit just because it's, you know, there's the one true way of doing it, but I feel like that sort of variety of approaches maybe flows a little bit more naturally out of React Native as a kind of a, I don't know, kind of a natural melting pot of developers. I appreciate that. [28:21]

Mark Erikson: Polyglot development. [28:22]

Carl Vitullo: Yeah, sure. [28:23]

Mo Khazali: It feels like React in the early days, rather than what React is today. [28:26]

Like, I've been in between the web and the mobile ecosystem. And, you know, I feel like the React ecosystem has reached a point of maturity, and there's less experimentation going on, it feels. Whereas with the React Native ecosystem, there's a bunch of people working on 3D rendering at the same time, and then there's a bunch of people working on web support at the same time, and then there's a bunch of other people working on native to, you know, JavaScript interfacing all together. I think it brews, a healthy amount of competition to try to get the best solution out of there. [28:52]

Carl Vitullo: Yeah, thriving ecosystem in the biological sense. It's uh, evolution, survival of the fittest, many, many competing strategies and competition with each other. It's cool to see work on the bridge happening, because, I haven't done a ton of serious development with React Native, but that has always been a huge bottleneck. [29:10]

I mean, you know, anytime you have a lot of data flowing through one thing, like, it's gonna be a challenge, it's gonna be a limiting factor if it's not fast. Interesting to see this come out of CodeGen from using TypeScript as a schema, it sounds like. It sounds familiar to my extremely vague understanding of things like protobuffers, where, like yeah, if you're just sending JSON, There's only so much you can optimize it because JSON as a data structure is just slower to parse. [29:37]

You know, you don't have a schema, you don't know what it looks like, so you have to figure out what it looks like as you go. So starting from a schema, starting from a specification of what the data contains, and then using that to generate like ultra fast native code makes a lot of sense to me. That's, that's pretty cool. [29:53]

JSR and Deno: Final Review 🚮

Carl Vitullo: All right. I will bring us on. Just a couple thoughts on JSR and Deno. I think Mark brought these up and had them cross my radar, but David Bushell, who is a WordPress developer mostly, wrote a couple of blog posts that I think are pretty It's a pretty rough indictment of the JSR, you know, module ecosystem and generally the path that Deno has taken through module, you know, managing modules, package dependency. [30:20]

One of the criticisms that he brings up about Deno in general is as a, you know, okay, it's a venture backed company. We've talked a little bit on this show before about venture backed open source projects. One of the criticisms that David Bushel puts out is that it doesn't really feel like, it feels corporate, like the communication feels corporate. [30:38]

It feels like corporate PR, not, you know, somebody talking about what they're working on. And that was actually, that resonated with me because that's something I've noticed. Like, for instance, I set up an ecosystem news channel here in Reactiflux, and Deno stuff is some of the only things that come through it, and it feels like somebody set up a corporate process and there's somebody whose job it is to make sure that all of the communications channels get populated, you know, in a way that it doesn't feel that way for other projects like Expo or React or things like that. [31:07]

So, I don't know, just like as a vibe. That was an interesting call out that I had noticed on my own as well. They talk about the meandering path that Deno has taken through trying to get package dependencies going, you know, cause, um, Ryan Dahl had a, you know, what node got wrong about Imports, I'm misquoting that, but he complained about errors he had made in creating Node and talked about how he was going to do it differently this time with Deno. [31:34]

And then they, you know, they did like a deno. land package registry for a while and then like, oop, nope, we're replacing that with JSR. But now it's all a little confused. Like it's, JSR applies certain restrictions on what you can publish. Like you have to annotate the return types. of any published module. [31:53]

So you can't just let it infer the return type, which seems like a kind of strange restriction to put on it. I guess it's maybe to enforce SemVer through types, you know, use those return types as a schema and assert like, oh, nope, you got to break it. You change the types. I don't know. It's interesting. [32:08]

It's curious. The single most, like, disruptive point that David Bushell made was pointing out that Dnode doesn't resolve sub dependencies like Node does. Like, the way that the JSR registry works does not permit sub dependencies in the same way, in the way that we've grown accustomed to with Node. Which, like, I have called that out before. [32:28]

That, subdependencies, dependencies of dependencies, is one of the best parts of the JavaScript ecosystem. The fact that I can install a package and I don't need to, you know, to an extent, I don't need to Manually make sure that I have given it everything that it needs. You know, there's some exceptions, like if you're using, you know, there's peer dependencies where that is still the case, but in general for if I install a library, that library brings in what it needs on its own. [32:56]

There's downsides to that of course, as well, but I generally consider that to be one of the major differentiators between JavaScript and, you know, PHP or Python. So seeing that go backwards is, seems like a bad thing to me. So that seems, yeah, I don't know. It's just a, a lot of pretty negative takes on Deno and JSR. It's given me a lot of pause on it. [33:15]

Mark Erikson: I mean, it's not just one hard problem, it's dozens o f hard problems simultaneously. I mean, you know, think, think back to, you know, trying to work with C where there is no such thing as a package manager. Java is sort of its own different world. C sharp is its own different world. [33:31]

Rust has the cargo tool and a centralized registry. Python is an utter mess. There was an XKCD years ago about how bad Python package management is, and I've continued to kind of just keep a general eye on developments in the Python world. And it's more confusing over time. So there's a lot of very, very justified complaints about how bad package management is on multiple levels in, we, we say the JS ecosystem, and by that we usually mean the Node plus NPM. [34:02]

But all things considered at the same time. Most of that ecosystem generally works, and so it's been interesting to see Deno take a slightly different path and actually have to sort of backtrack a bit and say, Well, yeah, actually it turns out maybe a couple of those ideas weren't so bad after all. [34:19]

Carl Vitullo: Right, they went pretty hard in copying Go style dependency management. [34:23]

And I always thought Go style dependency management sounded like an absolute nightmare. And so, yep, alright, they're walking some of that back. [34:30]

web-infra-dev/rslib: The library build tool powered by Rsbuild

Mark Erikson: There's yet another new build tool out called RSLib to work through the chain of pieces on this one. [34:37]

So, the folks at ByteDance have an incredibly prolific infrastructure team, and so the way I understand this is they built a full blown Rust re implementation of Webpack that they call RSPack. In fact, they've actually made a couple comments about it would be nice if this could just be turned into Webpack version 6, in theory. So RS Pack is web pack five, but entirely rebuilt and rust, effectively. [35:02]

RS build is a layer on top of RS Pack that makes it a lot easier to configure, or the, the configuration syntax is closer to like Es builds configuration level roughly than web pack's configuration level, where you're having to create a whole bunch of plugins. [35:19]

And so, rsbuild is meant more for applications, and I guess they've made a third layer on top of that where rslib is a wrapper or specialization of rsbuild that is more meant for building libraries with a proper configuration output. So, I'm not sure what's leading to all this proliferation of build tools from them, but they are very happily cranking away on a whole series of things. [35:45]

2024 Stack Overflow Developer Survey

Carl Vitullo: All right. I'll pull us onto our next one. We spent a lot of time last month talking about state of JS, state of React, state of HTML, we have another survey, the Stack Overflow Developer Survey, the results came out this month. I'm not going to do too deep a dive, I think, although Mo, yeah, we had talked about, you know, demographics and selection biases of the state of JS, definitely more to talk about here. Yeah, some, some points that I took away from this that were interesting to me. I mostly looked at the professional developer respondents, just that's who I am. That's who I am viewing as the target audience for this show. [36:20]

Something that surprised me a little bit, they said that more than 75 percent of professional developers have at least a bachelor's degree. I think it was like 45 percent have a bachelor's, like 26 have a master's, and like another 5 percent have some kind of specialized professional degree, like a JD or, you know, something like that, legal, medical, whatever. [36:40]

For years of experience, front end developers were absolute bottom of the list, except for student, which was interesting, but also not surprising. You know, Boot camps, they probably teach you front end, like, makes sense. It's probably the most accessible part of the software field. So not super surprising there, but yeah, uh, also less than 6 percent of respondents to this survey self identified as a front end developer. [37:03]

That's lower than I think it was in previous years. It feels like front end has kind of. I don't know, it feels like it's diminished over the last couple years. I was looking at the country demographics. I was curious about this because I know from our statistics who uses Reactiflux, I know that we have a huge Indian population within the server. Having my own read, my own perspective on what those metrics look like by actual like usage and participation. I was curious to see how they'd be reflected. And the answer is not great. Top five countries as responded to the Stack Overflow survey were the U. S. with like 19 percent, Germany with a bit over eight, India with a little over seven, UK with five and a half, Ukraine four and a half. [37:45]

I was curious to see how, what data I could find to back that up on, you know, what those stats look like. I couldn't find a direct comparison between the US and India, partly because the only English sources I could find for tech jobs in India just said all of IT, all of software in one. [38:02]

https://www.meity.gov.in/content/software-and-services-sector

https://www.bls.gov/oes/current/oes151252.htm#nat

Carl Vitullo: But yeah, they said five and a half million IT and software workers in India, when I summed those same jobs up for Bureau of Labor Statistics in the U. S., that was like four and a half million. So just to say, there's definitely a huge English speaking bias in these surveys, which is unfortunate because the programming world is much larger than the English speaking world. some other Things, JavaScript was the number one most used technology here, and 25 percent of people learning to code self reported using Google Cloud. [38:32]

I think that was like one of the top. That was the number one. That was the like most reported. Vercel was number three in people learning to code. Uh, for professional developers, top three, obviously, AWS, Google, and uh, Microsoft, but Google and Microsoft combined were about equal to AWS's numbers. On that list, Vercel was seventh. [38:51]

Just about a percent lower than DigitalOcean, which was behind Cloudflare, which was behind Firebase. React and Node, together, both topped the web frameworks list of, technologies used with jQuery in number three. But yeah, 18 points behind React and Node, so definitely a different tier. But yeah, jQuery, what staying power it's had. I actually saw that this was, I believe the 18th birthday? It's old enough to vote. [39:15]

Mo Khazali: The one thing that's interesting to me is just the 25 percent of folks learning to code use Google Cloud. I have a suspicion that might be to do with the fact that I know that there are GCP is quite involved in student fairs and a whole bunch of stuff giving free credits to people for hackathons and whatnot. [39:31]

I wonder if there's some sort of correlation there where a lot of people seem to use it for their student experimenting and hacking, but maybe not so much when they get into the professional world. Just an observation. [39:42]

Carl Vitullo: Yeah, that actually makes a lot of sense. I have seen them sponsor a lot of hackathons and things like that. [39:46]

Yeah, I hadn't considered that, but scans. Cool. That was our last main content piece, uh, I guess into the lightning round. [39:53]

Cocoapods going into maintenance mode

Mo Khazali: I'll just jump in with an update from the React Native ecosystem, or more, more broadly speaking, the mobile ecosystem. So, in terms of package managers, CocoaPods used to be the be all and end all when you wanted to build an iOS app, in terms of managing your packages, and we've come a long way where CocoaPods is now going into maintenance mode. [40:10]

Now, CocoaPods is actually used by most of the cross platform technologies as the package manager of choice. So React Native uses it, but I think Flutter also uses it, and apparently Unity also uses it for some of their stuff as well. So there's a whole lot of this ecosystem that's being built in CocoaPods. [40:25]

But what's happened here is that Apple's actually released their own package manager called the Swift Package Manager, or SPM for short. What the CocoaPods team called it was that they got Sherlocked, which is a reference to old school OS X, where they Basically got rid of an app called Watson, which was what Spotlight is now. [40:41]

They created Sherlock at that point, which basically did all of the functionality that Watson used to do that was already integrated into the OS itself. So they're basically citing that saying we've been Sherlocked and we're now going to go into maintenance mode as a result, because there's no competing with Apple. [40:55]

So a sad day for everyone who loved and used CocoaPods for years, but obviously we're going forward into the SPM era and React Native is already kind of on that route to adopt SPM support. [41:07]

Accident Forgiveness · The Fly Blog

Carl Vitullo: I saw a cool policy change for Fly. io, which is a, sort of a competitor to Vercel, it's a cloud compute platform. [41:14]

They are doing an explicit accident forgiveness policy, which is just kind of great. It's generally socially understood that platforms like AWS or Vercel or, you know, whatever if you have some weird billing situation that arises, like I think one that happened was like somebody got in an infinite loop during their CI build and that caused a huge number of function invocations and because you could build per function invocation, they had, you know, like a 200, 000 bill when they're used to paying like 2, 000. [41:45]

It's socially understood that most of the time, if it's not a repeat occurrence and it's not malicious, then they will forgive the bill. But it's socially understood. It's not in policy anywhere. It's just you put it on Twitter, you complain, it becomes a PR issue, and the company refunds you. [42:00]

So now fly. io has put up an actual policy saying we forgive accidents and has given more clarity around there. I appreciate that. It's always nice to see social norms turn into policies, especially when they deal with six figures in billing. [42:17]

spatial compute

Carl Vitullo: I saw a wonderful blog post from Sunil Pai, who I'm just a big fan of. We've collaborated a little bit in the past, but he has done PartyKit. He worked on Wrangler at CloudFlare. He's now working at CloudFlare again. He wrote about spatial compute, which is letting the network decide where in the world to run your code. So this is sort of an incremental step forward for serverless paradigm. [42:40]

Instead of starting up a server that runs your code, you just say, this is the code that I want to run. Please start it when this request is made. But you still generally tell it, what region of the world that code is going to be hosted in. So this is just a blog post talking about not doing that. Letting the server decide, letting the network decide where in the world to run your code. [42:59]

I just think that's a really interesting idea. It seems good. Seems kind of inevitable. Uh, and this is the first time I've ever seen anyone mention it. So calling it out. [43:06]

Mo Khazali: Interestingly, he's called it spatial compute. And I think he's put a disclaimer at the top saying, sorry, Apple, but that I wish he chose another term for that. [43:13]

That's already been used. [43:15]

Carl Vitullo: Oh, that's true. That is what Apple called their Vision. [43:17]

Mo Khazali: Yeah. Vision Pro Computing. Yeah. It's, it's, I wish there was another term he could use for this. [43:22]

Carl Vitullo: I like that he called it out and still did it anyway. [43:25]

Mo Khazali: Yeah, exactly. [43:25]

How Airbnb Smoothly Upgrades React

Carl Vitullo: Womp womp. Yep. Airbnb, we talked about Airbnb last episode as well. Uh, they put out a blog post about how Airbnb smoothly upgrades React. [43:34]

Last month, we talked about how they had just upgraded to React 18. So this is now two months later. them talking a little bit more about the process by which they did so. It was a pretty good read. It talks a lot about, like, feature flagging, you know, blue green deployments, and just sort of the trials and tribulations of what it means to update a core dependency of a widely used app that is in many, many phones with a huge variety of, you know, Performance and, you know, network and all those sorts of things. [44:01]

So I appreciated that, just right at the beginning of the They show like, you know, here's the ideal, like a stair step function of what version we're using. And then here's the reality of what version we've used over time. And it's got lots of like false starts where it's, they ship it and it's like, Oh, nope. [44:14]

Okay. There's a bug. We got to roll it back. Let's try again. Nope. Still bugs. Roll it back. This is, Relatable to my career. There's just, you can't do a big overhaul without missing some kind of edge case that you didn't anticipate. So, um, just always appreciate seeing people pull back the curtain and show what those pains look like, especially at big companies that have huge distributions. [44:34]

Use useId() Instead Of Hand-Making IDs

Carl Vitullo: all right, great blog post from React Training, which I'm actually not sure who's running this anymore, but it was started by Michael Jackson and Ryan Florence of React Router and Remix. They've been on my radar for a very long time. Looks like this was written by Brad Westfall. Use ID instead of hand making IDs. [44:50]

This was one of the clearer articulations of what use ID is meant to be used for that I've read. This just really kind of made it click for me. It talks about using. an ID attribute on the DOM, and why you shouldn't handwrite them. And it was just very clear and simple. The gist of it is, if you handwrite an ID, then you can only use that component once in order to not violate the guarantees that an ID has with the browser. [45:17]

You know, in a browser, an ID is supposed to be unique. If you select an ID, you get one element exactly. And so if you hand write an ID, your component can't be reused without violating that contract. What a simple idea. That makes sense. I now intuitively understand why use id is a valuable API to have. Um, yeah, just appreciated that. I love when something I didn't understand just clicks and becomes intuitive. I like it. [45:42]

Common Sense Refactoring of a Messy React Component

Carl Vitullo: Calling out this great blog post from Alex Kondov, he wrote, Common Sense Refactoring of a Messy React Component. Refactoring messy components, breaking them down into, from one mega component that does way too much into a smaller number of components that each have a smaller, you know, a single responsibility, has been a recurring theme in my career. [46:01]

This looked like a really great write up. I appreciate that it just does, like, A two paragraph preamble and then dumps 300 lines of kind of gross code on you. It's like, yeah, you know, that is, that's the experience of entering a new code base most of the time. I appreciated this breakdown of here's what the process of refactoring a messy component looks like. [46:20]

Introducing Structured Outputs in the API

Carl Vitullo: All right, small news from OpenAI. I had actually noticed this. We use OpenAI to do a resume review AI feature here, and I just did a revision to it, and it's much better. It's a little bit sassy. It's very terse. I like it. But yeah, OpenAI now has structured outputs in the API, so you can tell it what shape of JSON you want it to give you back, and it will give you that structure. [46:43]

I know in the past that has been a pain point. I remember people complaining about like just getting OpenAI to give you pure JSON without like, okay, here's the JSON you asked for, JSON. Uh, you know, just purely unhelpful. Just caught this bit of news. If you're curious about writing a little open AI side project, I think this is maybe going to make it a bit easier. [47:03]

Mo Khazali: It's also quite interesting for the mobile world, because you see a lot of a bigger shift towards server driven UI now, where, you know, you render things or you compile a JSON object that defines how the UI should look like in the mobile space, because, you know, that really works in mobile because, you You don't have to go through App Store updates, so you can basically have a dynamic page that uses JSON to decide how to layout itself. [47:24]

And so maybe pairing that with something like this could be very interesting because you can give it the right confines and restrictions and then say generate me dynamic UI and then it'll kind of be a smart AI native based app. [47:35]

Carl Vitullo: Wild. Kind of V0 vibes. V0 from Vercel. [47:40]

All right. Here's my last little news item. [47:42]

Sentry is now Fair Source

Carl Vitullo: This actually crossed my radar very late. I would like to be more prepared to talk about this because it's at the intersection of, you know, open source and licenses and legal stuff, which I am personally fascinated with. But Fentry has announced that they are FairSource. FairSource is a new concept to me. [48:00]

It's a new project. So they say, today we're launching FairSource, a new approach to software sharing that is safe for companies to adopt and developers to use. Seems pretty neat. They talk about, they give a list of projects that are working with it, and they define it as like publicly available to read, allows use, modification, redistribution with minimal restrictions, and I guess notably it says that it undergoes delayed open source publication, which they give as a four letter acronym, D O S P, very enterprise. [48:29]

It's not quite a license, it's sort of a social contract surrounding a license, I guess. They talk about a new functional source license, but it also recognizes a fair core license. And the business source license. It's interesting. I'm definitely gonna have to dig into this a lot more because this is just referencing a bunch of licenses that I haven't heard of in a like social contract for how source gets released that I haven't seen codified. [48:56]

I've seen companies do things similar to this before, but there hasn't been a name for it. It hasn't been saying like, yes, we are. This, we are FairSource, so definitely interesting. It's not quite free and open source, but it is adjacent free and, you know, FOSS, FOSS has been difficult for many companies to actually execute on and live up to. [49:17]

So this looks like a more friendly. type of license, mode of releasing source code into the world. So maybe it'll give engineers at more companies greater ability to make a compelling case for open sourcing internal code, which would be lovely. I would love to see more proprietary code get open sourced. [49:35]

Too many things happen in secret. [49:37]

Mo Khazali: The delayed open source publication is quite interesting because it's having a separate Closed source version of a code base that gets synced with an open source version is not, you know, unheard of. The React Native code base, as an example, is like this. So, it's not the most bizarre thing to have, and it's been happening. [49:52]

It's just maybe not been codified like you mentioned, and maybe this is the way to do it. [49:56]

Carl Vitullo: Right, exactly. That's the classic problem in a lot of businesses that would like to open source, is there's some part of it that is, like, truly proprietary, where if they release that, then, like, you know, they're giving away the secret recipe. [50:07]

Or Contractual agreements they have with their customers where like they wrote some custom integration code and like that can't get open sourced. So like there are very real business constraints that make it difficult in some cases to open source code. Like you said, some companies have done that through things like synchronizing source code, but that's been done kind of ad hoc. [50:29]

It's, you know, Each company has figured out its own way to work, to make that work. So seeing this as a template, a framework for people evaluating that decision, to push it over the finish line, to make it actually happen. Uh, that seems really valuable. This seems like one of those like quiet things that will have an outsized impact on the open source world. Pretty neat. [50:51]

Job Market

Carl Vitullo: All right, some information about the job market. It was not great this month, but most of that was because of layoffs at Intel, just not great. So 15, 000 layoffs from Intel alone, overall like 25, 000 layoffs in tech. Which is not great, but since most of that came from one company, that's still pretty on track from where it was last month. [51:11]

Intel screwing up doesn't really reflect too much on the broader, you know, tech and software ecosystem, I don't think. [51:18]

https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE

Carl Vitullo: I've been using this Fred data source of. Job postings on Indeed. And that is still trending down, which I'm a little surprised about. It's just been a consistent downward trend. It's down to 68 percent of the baseline of like the start of 2020. So, you know, pre pandemic, which I'm surprised. That's wild. I thought it was getting better. [51:38]

Mo Khazali: Just on that, I guess like Intel and Cisco both together are 21, 000 out of the 25, 000 layoffs. So if you take those two out, it's, it's actually like three, four thousand. [51:49]

Carl Vitullo: Okay. That's actually quite a bit smaller. [51:50]

That's nice. So yeah, last month I commented that it was the first time in a while we haven't had a pretty big pop of layoffs at the start of a new quarter. So yeah, cool. I guess that's generally holding true except for two megacorps running into problems. [52:04]

A couple of new releases. [52:06]

Material UI v6

Carl Vitullo: material UI put out version 6. They commented that they took two and a half megabytes out of the bundle size they'd installed on your disk, not the published size of your bundle, which made me look at that and go, wow, this is a 12 megabyte Install size, which is wild. That's larger than I realized. But yeah, Material UI, if you're using it, there's a new version out, new major. [52:28]

Mark Erikson: Although on that note, the TypeScript team has done some fantastic work shrinking the size of the installation on disk. Like it, it was up to like 50 megs, I think, as of like 9. And they did a lot of work in 5. 0 to convert some of the internals over to ES modules. And then, and then. Working on deduplicating some of the bundled files that they had and other internal optimizations. [52:55]

I think at this point it's down to like 20 or 25 megs, which is still sizable, but I mean on the other hand, you know, 50 percent net win is a net win. [53:04]

Carl Vitullo: Adhering that size, you know, 25 megs for all of TypeScript versus, you know, I don't know if it's exactly 12, I don't have the number in front of me right now, but half of TypeScript for material UI seems like a pretty big lift. [53:16]

Tauri v2 RC

Carl Vitullo: There's also Tauri v2 has a release candidate out. I don't know a ton about that, but we talked about it briefly in the past. [53:24]

Mark Erikson: It's an Electron competitor allows you to build apps that run on the desktop But the UI is built with web technologies The difference is that Electron you're shipping an entire copy of Chrome as the rendering engine Whereas Tauri uses whatever OS's native web views instead So the overall shipped size is a lot smaller. [53:43]

Carl Vitullo: Heck yes, seems cool. So they've got a new version 2 coming out, which should be big. [53:47]

NX v19.5

Carl Vitullo: There's also NX version 19. 5. I don't know a ton about NX. [53:53]

Mark Erikson: It's primarily a monorepo management tool. So managing lots of individual packages for both, you know, multiple libraries, multiple applications in one repo, which each of which could be, you know, being built with different tools. Like you might have, you know, a common TypeScript library and maybe, you know, a Vite app and an Angular app all in the same repo. And so NX does work to deduplicate the builds as well as manage creating and updating a lot of those packages. [54:20]

Upcoming conferences

Carl Vitullo: On to some conferences that are coming up. [54:22]

https://www.reactuniverseconf.com/

Mo Khazali: Next week, if I'm not mistaken, and time is not escaping me, is React Universe Conf. React Universe Conf happens every year in Wroclaw in Poland. So it's happening on the 5th and 6th of September. Uh, it used to be called React Native EU, but it's now evolved since React and React Native are getting closer and closer together by the day. So I will be emceeing the conference. Hence why I'm giving this shout out. [54:44]

So come along. Hopefully it'll be a good time. There's a lot of great speakers headlining there. [54:48]

Mark Erikson: Was it September, almost September already? [54:50]

Mo Khazali: That's why I have to take a double glance at the calendar. [54:53]

https://www.jsconf.cl/

Carl Vitullo: Cool. There's also JSConf in Santiago in Chile. Overlapping with React Universe. So that's going to be September 5th through 7th. [55:01]

https://utahjs.com/conference

Carl Vitullo: I feel like we've been talking about Utah conferences a lot, I guess. But yeah, Utah JS is doing a conference. Seems like there's been a lot of stuff going on in Salt Lake City. Yeah. [55:10]

https://reactalicante.es/

Carl Vitullo: There's also React Alicante in Spain, September 19th through 21st. [55:15]

Mark Erikson: I'm speaking, looking forward to it. [55:17]

Carl Vitullo: Woo! [55:18]

https://www.jsconf.ie/

Carl Vitullo: And JSConf Ireland in Dublin, September 25th and 26th. [55:23]

https://2024.squiggleconf.com

Carl Vitullo: Yeah, SquiggleConf in Boston is October 3rd and 4th. This is organized by a conference buddy of mine, Josh Goldberg. He is author of a book on TypeScript and just a wonderful, friendly, lovely person. I'm actually going to be volunteering there, so I'll be helping out with making sure the conference goes off. [55:41]

Mo Khazali: Yeah. So Josh, I was going to similarly give a big shout out to Josh for being an amazing person. But beyond that, me and him have been bonding. So we spent a bit of time in Amsterdam and we bonded over being first time conference organizers this year. So him and I have been trying to be each other's support group here and they're sending each other some tips and advice. [55:57]

But Josh is, is incredibly well known in the community and he's going to hopefully put together a really, really cool event. So definitely go there if you're in the U. S. [56:05]

Mark Erikson: The other organizer, Dimitri, is less well known, but also a wonderful person. [56:10]

Carl Vitullo: Yep, I just got to meet Dimitri the other day, uh, talking about volunteering. Seems really cool, seems really lovely. I'm going to brag, I was at the table at React Miami where Josh Ideated the name SquiggleConf, so I was there for the origin. So, very happy to volunteer. [56:26]

https://www.rendercon.org

Carl Vitullo: Overlapping with that, there's RenderCon in Nairobi, Kenya, October 4th and 5th. [56:32]

https://www.reactindia.io/

Carl Vitullo: Then, React India in Goa, India, October 17th through 19th. [56:37]

https://www.react.brussels/

Carl Vitullo: There's React Brussels in Brussels, Belgium, October 18th. I went to that not last year, but the year before. It seemed really great. I got to hang out with the organizer at React Conf in Las Vegas, and just really great dude. Would recommend React Brussels for sure. [56:53]

https://reactadvanced.com/

Mo Khazali: Cool, next up we've got React Advanced London, so this happens around October time every single year in London, so I've been going for a few years now, and the Great React Conference is probably the biggest React Conference that there is in the UK, so definitely head there, I will be there again this year, so if you're around, pop me a message and we'll say hi. [57:09]

Outro

Carl Vitullo: All right, cool. That is everything we've got for today. Thank you everyone for joining us. We will be back on the last Wednesday, even though today is Thursday, uh, last Wednesday of the month to hear on the live stage of Reactiflux or back in your podcast feed just as soon as we can. [57:23]

Mo Khazali: Thank you all for joining and listening to us ramble on and chat all things React and React Native. [57:28]

It is always a pleasure and see you all next month. [57:31]

Carl Vitullo: We gather sources from This Week in React, Bytes. dev, React Status, Next. js Weekly, the React. js subreddit, and here in Reactiflux. If you see anything that seems newsworthy, uh, that you think we should discuss, just put it in the tech reads and news channel here in Reactiflux. [57:49]

Or, if you like, You can send it to me in an email at hello at reactiflux with T M I R in the subject line, which is a, it's an acronym for the show. I read every email that comes in, including spam because I'm a crazy person. So I will read it even if we don't end up covering it. If this is the show you get value from and want to support, the best way you can do so is by giving a review on Spotify or whatever platform that you actually listen to. [58:15]

Tell your friends, tell your coworkers, we're cool and smart and we can help you sound cool and smart too. You're pretty cool and smart too. See you guys next month. Bye.

This Month in React, July 2024: State of React, State of JS, React, HTML

Reactiflux — Tue, 30 Jul 2024 16:00:00 GMT

Quick hits
- [02:14] Job market
  - FRED data
  - Layoffs.fyi
- New releases
  - [03:48] Vitest 2.0
    
    Future plans
  - [04:06] Remix 2.10
  - [04:24] Jotai 2.9
  - [04:34] Storybook 8.2
  - [04:52] RN Reanimated at 3.14
  - [04:59] HTMX 2.0
  - [05:03] Mako is Now Open Source
- [06:01] Conferences (React, Javascript)
  - [06:01] React Rally Salt Lake City, UT, USA August 12-13
  - [06:25] React Universe 2024 Wrocław, Poland September 5-6
  - [07:23] JSConf Chile Santiago, Chile September 5-7
  - [07:32] UtahJS Conf Salt Lake City, UT, U.S.A. September 13
  - [07:44] React Alicante September 19-21
  - [08:00] JSConf Ireland Dublin, Ireland September 25-26
Main Content
- Survey results:
⚡Lightning round ⚡

[00:00] Carl Vitullo: Hello. Thanks for joining us for the July edition of This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. We are coming to you live from Reactiflux, the place for React developers.

[00:13] And we actually have a sponsor this month. Woo! First time we're supported by Infinite Red, a consultancy that works exclusively in React Native. They've been around since 2015, have employees on the core team of React Native, and are super great.

[00:26] I'm going to do a little more on them after we do introductions, but I am Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs and otherwise build tools to keep the community running.

[00:39] Mark Erikson: I'm Mark, most of you know me as the guy who does Redux stuff, and as far as day job things go, I am actually looking for a new position, which is a bit of an interesting personal development, so if folks have suggestions for places I should be getting in touch with or that might be interested in me, please ping me and let me know.

[00:59] Mo Khazali: And I am Mo. I head the mobile team at Theodo, and I'm an active community member within the React Native ecosystem. I organize the React Native London meetup and soon to be conference, and just contribute here and there, dabble a little bit into open source. Nowhere near as much as Mark does, but I do try.

Sponsored by Infinite Red

[01:18] Carl Vitullo: Yeah, and a little more on our sponsor. Infinite Red is a expert React Native consultancy. I'm actually uniquely excited to get them specifically, Infinite Red, as a sponsor. They have been around, I've been seeing their name for the entirety of my career since I started in about 2014 with React. And they organize conferences, they host the largest React Native podcast, and generally have just shown up in very real ways to support the ecosystem and the community.

[01:46] So I got a chance to connect with one of their founders, Jamon Holmgren at React Conf down in Las Vegas, and we just really vibed. They seem like really great people, they talk about how they are a team of 30 with mostly developers, mostly with more than 10 years of experience, and they work with your team to coach you on how to best use React Native.

[02:07] So if your company is looking to build up some React Native expertise, definitely check them out. And thank you, Infinite Red, for sponsoring us.

Job market: FRED data + layoffs.fyi

[02:14] Carl Vitullo: Cool. All right. On to some quick hits. Job market updates.

[02:18] So there's a new source of data that I'm following, which is amusingly called FRED, an economic data set based out of the St. Louis Fed. So apparently the job site indeed does some like data analytics stuff that now the Federal reserve is relying on for like labor information. And this is a chart of software development job postings that have been posted to Indeed. And it is, indexed off the beginning of 2020. So it's more than doubles at about the start of 2022 and is down to about like 68 percent of that 2020 baseline and it's been pretty flat.

[02:57] I really like this because I've been looking at layoffs. fyi for, you know, a year now and it just doesn't quite do it. It is, there's, there's enough, there's a lot of variability. It's only the source of Layoff. So this is kind of the other side. What does hiring look like? And unfortunately, hiring is flat to down, which is not great. But at least people aren't getting laid off as quickly anymore.

[03:20] Yeah, speaking of layoffs, layoffs. fyi. This is the first time in, like, the A year and a half that we haven't had a, like, a pop of layoffs at the start of a new quarter. So that's a small positive sign. It's down versus last month in June and only the second time this year that we've had less than 10, 000 developers laid off. So, seems good. Hiring is not ticking up though.

New Releases

[03:44] Carl Vitullo: Mark, you want to take us through some new releases?

[03:46] Mark Erikson: Sure, a couple of the most interesting ones.

Vitest 2.0

[03:48] Mark Erikson: Vitest 2. 0 is out. A bunch of small changes, but it's interesting to note that they're working towards a browser mode. Because we've had browser based testing for a while, but trying to focus on running unit tests in the browser. So, this has some very interesting potential there.

Remix 2.10, fog of war

[04:06] Mark Erikson: Remix put out a new release that has a fog of war feature, which looks like it's about trying to optimize downloads of route information. Looks like rather than bundling all the route information ahead of time, they will actually download chunks of it as you go, which should improve loading speed.

Jotai 2.9

[04:24] Mark Erikson: Uh, Jotai 2. 9 is out. And it looks like the public behavior is basically the same, but they've reworked the internals.

Storybook 8.2

[04:34] Mark Erikson: Storybook 8. 2 has, trying to look at the release notes, a few small changes, probably not a whole lot of big stuff.

[04:42] Carl Vitullo: I've never quite understood the niche, the purpose that Storybook really serves. But, you know, hey, minor release, so it seemed worth calling out. I know it's pretty widely used.

[04:52]

React Native Reanimated 3.14

[04:52] Mark Erikson: React Native Reanimated has 3. 14. So I guess there's your, there's your Pi release.

htmx 2.0

[04:59] Mark Erikson: Totally outside of React. HTMX just hit 2. 0.

Mako released

[05:03] Mark Erikson: And there is yet another Rust based JavaScript build tool that came out. This one's called Mako. I saw it. I'll be honest. I have no idea how this is any different than the other seemingly like 15 other Rust based build tools at this point.

[05:20] Carl Vitullo: Mako has come out of the Ant design. That's what caught my eye as being notable.

[05:24] So this is a Rust based developer being built by the team that put together one of the reasonably popular component toolkits. It seems notable for that reason to me. But yeah, yet another Rust based build tool. One more thing on Mako. They put up a bunch of benchmarks that show it being like 10 times faster than Webpack and noticeably faster than RSBuild 0. 6, which is pretty impressive. They also talked about like not being able to get it to work, getting their benchmark to work with the latest release of RSBuild, which is 0. 7. So who's to say if those benchmarks will really hold up, but yeah, cool.

Conferences

React Rally

[06:01] Carl Vitullo: Some conferences coming up. We've got React Rally in Salt Lake City, August 12th and 13th. I've been to React Rally a couple of times Over the years and definitely a great one. I also noticed it's pretty much the only conference in August. I think because everyone's on vacation.

[06:16] Mark Erikson: React Rally is wonderful. They've done a great job of really having a good community vibe over the years. I should be there. So folks want to come by and say hi, please do.

[06:24]

React Universe

[06:25] Mo Khazali: Next up. We've got React Universe Conf in Wroclaw in Poland on September 5th and 6th. I actually am seeing this conference. So if you like listening to me talk about weird stuff and ramble, it's the place to be, I guess, but no, it's a great conference.

[06:41] It used to be the former React Native EU, and now it's expanding to cover all things React based. And we've got some really good speakers there. So obviously you've got the, the popular React Native speakers that are the lineup of every single React Native community conference that you know, but we've also got folks like Dan Abramov, who's been I can't see Dodds and some others, and I would highly recommend coming to it.

[07:03] The organizers really know how to organize conferences. They've done it for many, many years and you're guaranteed pretty much to have a great time.

[07:10] Carl Vitullo: Yeah. And on them knowing how to organize a conference, they organized React Conf. They were one of the organizer partners for that. So yeah, they certainly do. They have organized yet another conference. Definitely would love to get up to Poland if I can. Cool.

JSConf Chile

[07:23] Carl Vitullo: A, an overlapping conference. There's also a JSConf Chile in Santiago. That's September 5th through 7th.

UtahJS Conf

[07:32] Carl Vitullo: There's a Utah JSConf again in Salt Lake City on September 13th. I guess this is. JavaScript versus React for React Rally. But yeah, so we have two conferences in Salt Lake City a month apart.

React Alicante

[07:44] Carl Vitullo: There's React Alicante, which is going to, it looks like it's going to be an online conference.

[07:49] Mark Erikson: It's in person in Spain and I'm speaking there.

[07:53] Carl Vitullo: Cool. Oh, awesome. Wonderful. Go see Mark speak in Spain. That is September 19th through 21st.

JSConf Ireland

[08:00] Carl Vitullo: There's also JSConf Ireland in Dublin with also streaming September 25th and 26th.

[08:07] And that is all of the conferences we have this month. Uh, I will shout out, last month I mentioned a conference that I will not name again because it came to light that they were using fake speakers on their website and had various people listed as speaking at the conference who were not. So, uh, I updated the transcript, but I wanted to shut that out. I did try to check. I do look at the conference websites and try and vet them, but I got it wrong last month. Sorry.

State of the web surveys

[08:32] Carl Vitullo: All right. Onto our main content. We are slightly behind the times by a month or two on State of surveys. There have been a bunch of state of React, state of JavaScript, state of HTML, all kinds of states that have come out over the last two months or so, which is later than I expected.

[08:50] Usually these have, in years past, the state of JS surveys have done a pretty good job of coming out. Pretty promptly, they've been running for, it seems like, most of my career. So, just surprised. Seemed like there were some, hitches this year.

[09:04] Mark Erikson: Yeah, like, I'm not sure if it was that they, they just took a really long time to analyze the data, or they were working on, I know they did a lot of work on, like, new data visualizations as part of the survey results.

[09:14] So, it might just have been that it took them a long time to get the new sites put together.

[09:19] Carl Vitullo: I did notice that they had some really cool data interactivity bits on it, like you can, for a lot of, at least on the State of JS site, the State of React one got, looked like a little bit less attention, which is fair, it's a much smaller survey, it's like a third of the size. But, they had some interesting stuff where you could filter or correlate responses. So it's like, Oh, you can see years of experience as it pertains to salary. So there was a lot of really cool data exploration stuff there.

[09:48] I did also see a little bit of chatter online or on Twitter about how the survey was promoted and what that means for its sample size and audience. demographics mainly, like the survey responses were like 92 percent male and that's not great. I've seen other spaces get up to like 80 percent male, so, you know, 15 to 20 percent female, which seems to be about the high watermark, unfortunately, for online based tech communities. But yeah, so just, just wanted to shout out that I have heard a little bit of that.

State of HTML

[10:21] Carl Vitullo: I'll start with the two smaller surveys.

[10:23] So state of HTML was actually really interesting to me. I don't super duper know how to stay on top of, like, HTML and CSS changes, so I feel like every couple of years I, like, see a talk from someone who's a genuine cutting edge expert in CSS and, you know, use the platform kind of stuff and go like, "oh, holy shit, I don't know how to use HTML anymore," because just reading the state of HTML, I found a bunch of little things, a bunch of new features that I was not aware of. I unfortunately didn't take a bunch of notes on them, but just scroll through, see what catches your eye, see what you haven't stayed up to date with.

"Use the platform"

[10:58] Mark Erikson: I know we've had, you know, there's, there's kind of the running meme of, you know, the, the folks who insist on use the platform and the, and the React community is a little bit like, "but the platform doesn't support all the things we want to do," but browsers are continuing to implement, new features, the HTML and JavaScript specs keep advancing.

[11:17] And it's a fair critique that folks who tend to focus on, the React type front ends probably don't know as much about the nuances of what's available in HTML and CSS as folks who are more focused on that. So, like, there's sort of fair critiques on both sides, and it's worth keeping an eye on, the new advances there.

[11:39] Carl Vitullo: Yeah, something that I have thought of many times over my professional career is like, there's use the platform, you know, there's a lot of things you can do without writing JavaScript code. If you can do it with a native feature, it's going to be less development time. It's going to be, it's probably going to be faster, more performant for the user.

[11:56] But that use the platform nature is in tension with the flip side of React trying to allow people to write code that runs in more environments. So it's sort of, there's sort of that dichotomy. There's the pressure of writing a tool tip library, writing a modal library that works in React Native as well as natively on the web.

[12:16] And if you rely on the platform features, then you can't do the React Native side of things. So There's been a big tension there for many, many years, but I have been very interested in what it would look like if there was a component toolkit that just said like, nope, fuck the other platforms, we're just going to go all in on web, we're going to do it in as few lines of code to get the best user experience and the best developer experience possible.

[12:38] I don't know of one that's really working in that way, but I think it would be really cool.

[12:42] Mo Khazali: So two points on that, which I think was a really interesting point that you raised, Carl. One is part of the reason why a lot of these libraries don't really work well for React Native is the lack of web API support in the React Native ecosystem.

[12:54] And it is actually something that's being worked on. So Microsoft opened an RFC last year and they said, well, you know, we, we, whether we like it or not, as native developers, the web APIs have won. They're becoming standardized. Things are. Relatively stable. So why not try to at least use those as the interfaces, even if the native implementations are different under the hood, so that when you do use your trusty old React library, it does just kind of work out of the box in the React native ecosystem.

[13:18] So there is a move towards that and you've got React strict DOM and whatnot. But the example, the counterside to that is the example of tooltips that you mentioned. Like tooltips are not a mobile. Friendly UI element. So there's no easy answer to this unless you create really high level primitives that are UI agnostic.

[13:35] But functionality wise, they kind of behave similarly. So, you know, from a way that it looks, it's totally different on iOS, Android, and web, but at least the APIs for the developers are the same. So opens a tool tip on the, the, the web with a hover, but you know, maybe opens up a modal. A bottom sheet modal on native.

[13:52] So it's a big point of contention for us React Native developers that we're trying to figure out. I don't think we have the answer, and I don't think anyone's figured out the sweet spot. But we'll get there. We will get there.

[14:02] Carl Vitullo: Yeah, I feel like it crosses my mind every couple of months, but just hearing you talk about like, the web platform just makes me think yet again of a 2013 talk called the birth and death of JavaScript.

Birth and Death of Javascript

[14:13] Carl Vitullo: And yes, JavaScript is intentional. But yeah, if you are not familiar with JavaScript. That birth and death of JavaScript talk, watch it because like, oh my God, it's the most, it has remained the most like prescient talk I've ever watched. It is exactly discussing how JavaScript takes over the world and we're just living it, we're just living that 10 years later, 11 years later. Anyway, that's a, that's all kind of long diversion for state of HTML, but.

State of React

[14:39] Carl Vitullo: There was also a state of React survey. It was pretty good. I kind of got more interesting signal I felt out of the state of JavaScript survey. There was a lot of survey time dedicated to like, what React features do you use? And that's just not really a question that I have, you know, I don't really care if you use, you know, use context. You probably do. If you don't, you probably should. That section, what features do you use, is interesting in terms of like, what are people aware of, but I don't know that it really changes that much.

Component Libraries

[15:07] Carl Vitullo: It did have a lot of good data about component libraries and ecosystem that I thought was, just, we, we spend so much time in here bantering about like, what the vibes are and how does it feel What tools does it feel like people are using more and talking about more?

[15:23] So this is a good data based check in on how accurate the, the vibes, our read of the vibes are and pretty accurate. I'm pretty happy. We'll get more into it with the state of JS, just that did have a lot more of the vibes, but some things I thought were notable component libraries, generally not popular.

[15:40] Some of them are reasonably widely used, but like not loved. Radix were the most loved with Headless UI, also pretty high up there. Radix and Headless UI are not ones that live large in my mind, so it was cool to see those surfaced. Definitely, like, you know, obviously we talk about ShadCN pretty frequently, but Redux and Headless UI, good ones to check out.

[16:03] Headless UI looks cool because it's unstyled, so it's just behavior, and then you make it look the way you want. Which, here for it, love it.

[16:11] Mo Khazali: I think that's kind of the direction that they're all going with as well. Like, you know, R a bit more opinionated, but still flexible in a lot of ways compared to, let's say, your run of the mill material UI.

[16:21] I think that's the general direction where these things are going. And Headless is great for that. I guess that's the appeal with Shad for me as well, right? Like I know a lot of people love ShadCN. The appeal is, well, if you don't like the rounded corners specifically, it's just a tailwind prop to change and you're kind of done.

[16:36] So you have a lot of flexibility there.

[16:38] Carl Vitullo: Yeah, definitely makes sense. It's been curious to see how slowly that has evolved over the years. I, I bailed out pretty quick on component toolkits cause I just, I don't want it to look like a bootstrap site.

StyledComponents still big

[16:48] Carl Vitullo: So there was also something that I found interesting just because it seemed like a, you know, narrative violation is styled components are still pretty dominant in terms of actual usage, like enormously widely used, you know, everyone talks aboutTailwind and whatever, but. Style of components, they're here to stay, they're sticking around.

[17:05] Some other interesting data, 23 percent of respondents are still on either React 16 or 17. So this is like, how many years after 18 was released? And 6 percent of survey respondents don't know what version they use, which is interesting to me.

[17:21] So, yeah. If you're using React 18, congrats, you are on the cutting edge. The only 68%, less than 70 percent of survey respondents are on React 18. Talking about nobody uses beta versions. Nobody uses advanced versions. I think it was like less than 1 percent have tried a canary. So rounding error. All right.

State of JS

[17:43] Carl Vitullo: State of JS, the big one. Mo, you want to, you want to kick us off with your thoughts? Break up my monologue.

A Note on Survey Sample

[17:48] Mo Khazali: Sure. Good to start off with what you kind of start off generically about the survey results, which is you got to look at the sample size.

[17:53] It's like the most important thing to do when you start with this, because it makes the data seem a lot more contextualized as a result. So a colleague of mine, she was talking about this and I kind of took notes and then looked through it and I was like, yeah, wow, that's very accurate. She was giving me her thoughts.

[18:09] But the first thing is, location is heavily US based. So if you look at the respondents, 16 17 percent are from the US. If you combine Germany, France, and the UK, Those become close to the US respondents. They're about the same as the US respondents, a little bit more. So all of this data is heavily skewed by the US market.

[18:25] Things like, let's say like the Indian developer community is very, very underrepresented. There was only about 500 respondents where that's about two, 3%. Whereas, you know, they should be a lot more because proportionately they'll have a larger developer community than that, which is represented.

[18:41] Carl Vitullo: I think the total number of respondents was like 20 or 30, 000.

[18:44] So hearing only 500 from India is like a little bit shocking. Yeah,

[18:47] Mo Khazali: it's, it's quite poorly represented. Or the Netherlands, as an example, has got about 500 as well. The Netherlands is a big tech hub in Europe. A lot of big tech conferences happen, JavaScript conferences happen in the Netherlands because there's already a big community there.

[19:00] So it's very interesting, I think it's probably more to do with marketing and how they got the word out, and which communities it goes to. And so when you have location being heavily based in the US, then it skews salaries quite significantly. US salaries for developers are much higher. than European salaries And so all of the salary data is being taken on sort of an average, and so that moves the whole scale, basically.

[19:20] The other thing which kind of you hinted on, Carl, was it's almost exclusively male. So 94 percent men, which isn't great. It's really heavily, disproportionately male. Men who have responded to this. And then the worst view that you can see, and this should, if anyone has any doubts about this, just look at this view and hopefully your doubts will be completely gone but when you combine the gender and the yearly income views, you can see that men have a higher average salary.

[19:47] Shocker. So the gender pay gap is very much there, and it's something to the degree of 20, 000 on average between men and women. Shocking, right? And unfortunately as well, again, racial demographic, it's mostly white respondents, 70 plus percent as well.

[20:02] So there's, there's, the sample size isn't very representative, I'd say. Still interesting findings, but just those caveats are very interesting to contextualize everything.

[20:10] Carl Vitullo: Definitely. Yeah. It's funny. The salary to gender is one of the only things I did to play with the data. So it's funny that we both went straight for that. Yeah. Also on salary on, you know, US based salary, skewing it, you know, higher, I actually was, looking at that chart, looking at the, you know, the, the quartiles and seeing that my last job, like two years ago, my last full time software tech job was like, On the very high end of that.

[20:36] So it's like, Oh, apparently I kind of maxed out the scale, which is interesting because I definitely have not, I was not at the top of the scale. I, my last salary is 171, 000. Like it was good. I was very happy with it, but. I know plenty of people who are making like double that. So I was surprised as much as US salaries will skew it higher, I was a little surprised to see the absolute high end of the scale, not really represented. Do you know, just knowing people who are making that.

[21:04] Mo Khazali: So. Fascinating. You know, you say that because again, it's relative because if you, let's say like, look at the UK, 170, 000 per year, and your yearly salary is basically the top, top, top end, like maybe top two, 3 percent of developers. in the UK. So it's, it's all relative.

[21:18] Like, like you say, yes, even in the U. S. you can go much higher and then it starts to become really skewed. So yeah, very interesting, but the data is never going to be accurate.

[21:26] Carl Vitullo: Right, right, right. Yeah, I think top of market, I don't know, Netflix intentionally tries to pay top of market. I think they're in like 350 range.

[21:33] I've heard rumors, consider this a rumor, but I've heard of like super top developers at OpenAI making upwards of like seven, eight, nine hundred k, a million dollars a year salary. So yeah, high end of the scale is crazy in the US, but we can, we can bail out of demographics for a minute.

[21:52] I'm going to just rapid fire some of these, some of the breakdowns, some of the analysis that I was looking at.

Vue Tops Angular for usage

[21:57] Carl Vitullo: Vue has surpassed Angular by usage according to this survey, which caveats about sample aside is interesting. Angular definitely not loved. It had a like net unfavorable view of it. I think majority of respondents had a negative view of it. it's still in competition with Vue and React by usage, but it is substantially more negative than either of those, than either React or Vue.

[22:22] Everyone still loves Svelte. It was number one by like a long shot on interest and favorability rating, but not very top by actual usage. It has been consistently, growing in usage over the years. So React is still generally positive. It's still the most positive by rank. You know, in this list, it was number one most positive, but that's been declining over the last two or three years and is very tight with Svelte right now.

[22:49] The dots were like practically overlapping, like definitely within margin of error for which one was more positive. Astro topped out the list of other options, It did not make the cut to be in the main list, but one of the shout out, Astro is in contention. it was funny.

Developer Happiness

[23:05] Carl Vitullo: The, they had a chart of happiness and generally all of the libraries people were happiest in 2018, which I just thought was funny because I tend to think of 2018 as like peak tech for, in a lot of different ways.

[23:18] Like when I think of Reactiflux and its activity and its growth and its vibes. 2018 was definitely a banner year. So that seems to just generally be true across the industry. Everyone was happy in 2018 and people are less happy now.

[23:31] Next usage has been growing pretty consistently for like the last four or five years by this survey. Remix has been pretty flat, which I put them in the same usage bucket. I put them in the same popularity bucket in my mind. So that was a little surprising to me. There's also, Remix had a much more negative perception than I expected. It's about even for, you know, positive and negative responses.

[23:52] I love it. I thought it was great. So I'm just surprised to see that. Over the last, like, three years, testing, usage of test tools. has grown pretty significantly, whether it's Jest, or VTest, or Playwright, or Cypress. All of them saw usage go way up in the last two to three years, which is very funny because that, that tracks very well with my experience of three to four years ago, nobody was writing tests.

[24:17] Just, people actually started writing tests in the last couple of years, which is funny. Yeah, Playwright versus Cypress. The vibes are supported by the data. People love Playwright. It's got really great retention. It's got really great net favorability rating. Cypress, a little bit less so. It's still very widely used, but the retention chart was much more negative.

[24:39] And it's just not as well loved, which generally tracks with the sentiment that I've seen.

[24:44] Mark Erikson: Yeah, I think I saw that Playwright Downloads had recently surpassed Cyprus's. I know I've seen a lot of mentions of companies migrating from Cyprus to Playwright. So, yeah, matches my experience.

[24:55] Mo Khazali: We literally, this week, migrated one of our clients from Cyprus to Playwright.

[25:01] So, another anecdote of how the general vibes are going in the community.

[25:05] Carl Vitullo: Yeah, Roboto just asked in the chat, what are people's problems with Cypress? I've run into a bunch of weirdness on flaky tests and just general quirks, like the edges have been rough. I haven't really done enough with Playwright to say what's better about it, but it seems like it's based on a more stable foundation.

[25:24] Mark Erikson: I can briefly speak to this. Cypress runs your entire test in the browser. It basically kind of like hijacks everything about the browser behavior and sort of re implements a lot of that itself. Whereas Playwright, the test is running externally. And it's sending, like, DevTools protocol commands to the browser.

[25:42] CypressR also has a really weird not actually async model. The way I understand it is it actually runs through the entire test code ahead of time and collects a queued list of commands, and then it executes those later. So you can't even use, like, real async await in your test syntax, whereas with PlayWrite you can.

[26:03] Carl Vitullo: Interesting. Yeah, because I think Cypress came out before, like, headless Chrome was a thing, because I remember they, all of the browser automation stuff from, you know, years gone by are very hacky. Like, they're scripting the browser in a just really janky way, and the browsers produced a headless variant that is more intentionally able to be scripted.

[26:26] And so I'm pretty sure that Cypress predates that change, and so they had to do the hacky weird stuff, and Playwright came about after that change, and they do less hacky weird stuff.

[26:36] Mo Khazali: There's one more thing with the Cypress, I guess, model that pushed people away in the last couple of years, which was that they basically, they, I believe they're VC backed.

[26:46] They needed to find a path towards monetization. So they released a paid model where you had a dashboard on their sort of like hosted platform. And then there was free alternatives. And they were scanning your node modules. There was this thing that came up where they were scanning node modules and sort of sabotaging if you were trying to use an open source alternative to their paid platform, which people really did not like.

[27:09] And there was a lot of backlash. So I think a lot of people lost a lot of trust with Cypress as well after that.

[27:13] Carl Vitullo: That tracks. Okay. That's not great. Yep. Also in testing, the generically branded testing library is also losing ground, which I'm surprised by. I loved it. I thought it hit a really great niche between like unit tests and full end to end tests.

[27:28] But I guess my thought is maybe. Playwright is now stable enough to cover that use case with less setup process. Cause it did take quite a bit of work and influenced how I developed features when I had testing library tests in place. So maybe it's a similar benefit for less work using Playwright instead of testing library.

[27:49] Mark Erikson: It is worth noting that Playwright actually added testing library inspired APIs like get by test.

[27:56] Mo Khazali: And I have another hypothesis to this, which is again anecdotal, but it's from working with many different sort of clients. I think it might also be market led, and the reason I say that is because end to end tests are much easier to sell to your business stakeholders.

[28:10] Oh, we're running and executing the full end to end lifecycle as if it was a user, and it helps prevent bugs because you can see when a flow, a major flow is broken. Whereas Component tests, whether they're with React testing library or any other solution or unit tests, are much smaller pieces of the segment.

[28:26] And I think when you're crunched for budget, but you still want to have some level of testing and confidence as a business stakeholder, you'll push your developers to do more end to end tests because they understand it more. That's my hypothesis. I've seen it more in conversations with some of the leaders and the companies that we've been working with.

[28:40] Carl Vitullo: Yeah, that makes sense. I personally find that a benefit because it'll, testing library lets me sidestep the whole, a whole set of questions. Like how do I log in? So weird stuff like that gets easier if you strip away the, you know, the stuff surrounding the feature you want to test. And once you've just run through the interactions there, but it definitely would be easier to sell.

[29:01] We're going to test the whole thing. All right. Many diversions later. So testing, State of JS. Vitest usage has really skyrocketed. It's been very impressive. Jest is still surprisingly well loved to me. Generally testing across the board, way up. Everyone is writing more tests. Moving out of tests into native.

[29:20] There's generally, it looks like a lot more people are building native code. This is probably a reflection of how much work the React Native and Expo teams have done to make that feasible for people who are use, who are coming at it from web development. Like in the, you know, different runtime section of this, they had, are you using, Electron, Expo, Cordova, React Native, all sorts of things, including native mobile.

[29:48] You know, just, are you building a native app? All of those are, well, all the modern popular options are way up. You know, Cordova is, you know, Declining, luckily, but React Native, Native Mobile, all of that is trending pretty way up.

[30:02] One option that was brand new to me in this survey is Tauri. Looked like an option that people love for doing native stuff and wanted to shout it out.

[30:11] Mark Erikson: Yeah, and for those who aren't familiar with it, Tauri is basically a competitor to Electron. You know, the idea is you're writing a web app that runs it runs within the desktop as a native like application.

[30:22] The distinction being that with Electron, you're having to ship an entire separate standalone copy of Chrome to run your web app, whereas Tauri wraps whatever the native web view is for that platform. So, you're only shipping, say, like, A five meg set of assets instead of, you know, 150 megs of Chrome to run your couple of megs of JavaScript.

[30:45] Mo Khazali: And just from a native app developer's purist perspective, I would, from a React natives perspective would say that's not really your native, but it's a good hybrid option, but that is just a personal thing because you're not rendering native views at the end of the day. You're rendering a web app with some connections onto the native layer APIs.

[31:02] But that's generally the challenge with anything like Electron, Ionic, Capacitor, or Tauri.

[31:08] Carl Vitullo: Yep. Into like bundling and those tools, Webpack declining sharply. Really bad compared to others, like favorability and retention and all of that. Unfortunately, the way the questions are asked is, What have you used?

[31:23] So there, it doesn't have a way of capturing What people currently use versus what they have used and have switched off. So it's hard to say whether people are actually not using Webpack anymore or, and whether they've added new tools to their toolkit or whether they've replaced it, that is not a question that we can answer with this dataset.

[31:42] My, my intuition, my guess here would be that a lot of people are still using Webpack professionally, still working on a project that was spun up, you know, over the last two to five years. And, you know, switching bundlers is a really challenging project with not a lot of business value. So, yeah, I, I, it would not surprise me if a lot of people are still using Webpack at work, but have stopped relying on it for projects they make on their own or for, you know, open source work.

[32:10] Mark Erikson: Also worth noting on that, on that front, that, Create React app. There's still plenty of CRA apps out there, even though it's no longer officially maintained or recommended, and that has always used Webpack internally. And Next is still a Webpack wrapper. They've been working on TurboPack, which I think now fully supports dev mode, but I don't think it supports production builds yet.

[32:33] So, Next is still wrapping around Webpack for the foreseeable future.

[32:38] Carl Vitullo: Yeah, generally, like, ESBuild and Vite have been the big winners here as Webpack is losing usage. Rollup is going up as well a little bit, but as far as I know, that's largely used by library maintainers, not app developers. Yeah, monorepo awareness is also growing a lot.

[32:55] You know, the classics from, like, Several years ago where Yarn Workspaces and Lerna, those are declining. They are not the popular options anymore, but NX and PMPM are currently the leaders there, although I'm not sure if people would answer, I'm, I'm, I'm wondering if people might've said, Oh yeah, I use PMPM when they didn't mean they use it for monorepos, that's not the primary use of PMPM as far as I know.

[33:18] And TurboRepo from. Vercel is also growing, but for other runtimes, Bun is slightly more popular than Deno. Interesting to check in on.

[33:27] Mark Erikson: Now, is that, is that in sentiment or like actual usage amounts that we know of?

[33:33] Carl Vitullo: That was claimed usage. So people saying, yes, I have used this. More people said that for Bun.

[33:39] But, who's to say if it was personal, who's to say if it was professional, playing with something is very different from introducing it in a work setting, and my intuition says that Deno is currently better positioned than Bunn to be used at work, which is a much stickier usage. Yeah, another fun stat that I caught and wanted to shout out.

[33:57] 18 percent of respondents have not used any AI tools. You know, whether that's Copilot or ChatGPT or Claude. Yeah, 1 in 5 of tech people who are aware enough of the online Zeitgeist to respond to a survey have not used it at all.

[34:14] Mo Khazali: Just another interesting fun one. Apparently, 50 percent of respondents are still using Lodash actively, which I found was interesting, but more interesting than that is the 33 percent that still use Moment, despite some of those APIs basically being available in the, in the browser APIs.

[34:29] So, takes a long time to get rid of some third party libraries, it seems.

[34:32] Carl Vitullo: Yeah, yeah, it really does. Yeah, and I wanted to shout out the 20 percent of people who responded that are still hoping for, a pipe operator and pattern matching. My heart goes out to you as one of you.

[34:44] I, that's something, those are two features that I got really excited about and like. 2015 16 that we are still waiting for. So I think I'm, I think I've given up at this point. Yeah. And Mo, about, uh, on library usage, I was really surprised to see that RxJS had a lot of usage. I think of it as a niche library, but, but by survey responses, a surprisingly large number of people are making use of it.

[35:09] Mo Khazali: That's quite interesting. I mean, the, the, the one that everyone makes jokes about is jQuery as well, which is 22 percent still, but you know, yeah, it's, it's, RxJS has always been more niche and I'm, I think it was mainly used predominantly by the Angular community, if I'm not mistaken, right? Someone from the, uh, from the comments is saying that it's still a first class tool in Angular, so that, that might check out as to why it's got such a high usage.

[35:31] Carl Vitullo: Okay, that, that would scan. Sure, sure.

[35:33] Okay. Maybe this is my React bias showing then.

[35:37] Mark Erikson: Yeah, I mean, they've, Angular has been introducing signals within the last couple major versions as they're, they are trying to put some emphasis on that, but RxJS is still very integrated into the Angular ecosystem.

[35:49] Carl Vitullo: Gotcha. Okay. Looking at survey respondents generally, you know, the number of people who answered like the demographic questions at the beginning versus number of people who answered, who gave any answer for what content do you consume, like 80 to 90 percent do not consume content.

[36:05] Like they did not give any answer for what content do you consume, which I just think is really. I think it's an important thing to keep in mind when you're, you know, as people are saying like, Oh, you know, Oh, everyone is, everyone's talking about this. Everyone's thinking about this. So and so made a video on this.

[36:19] Like, you know what? Most people didn't see it. Most people are not thinking about that. Most people aren't even aware of that. I just think that, I just think that is a great, Demonstration of like the participation inequality that happens in so many software communities, or that happens in communities generally, where like 90 percent of the people are not participating in the same way as the most active 10%.

Dark Matter Developers

[36:43] Mark Erikson: And I have a very specific link for that, which is Scott Hanselman's classic post on dark matter developers, people who are just going to work and doing their thing and going home, and they don't know about the Twitter discussions or what's popular or the trends. They're just doing their thing quietly.

[37:01] And we don't hear about them because they're not involved in the discussions. But the

[37:06] Carl Vitullo: That is actually specifically the target that I'm kind of going for, for this podcast. I want to be the once a month, one hour long summary of that fire hose. Like, you don't care enough to drink the entire fire hose, stick your face in front of the blast of water, but want to get the signal.

[37:23] that's what I view our role here as. We pull that signal out so that you can spend one hour consuming it instead of More than that, If you, instead of it being a part time job, staying on top of the latest news, I want this podcast to be an effective way to do so.

[37:37] So yeah. Hello, Dark Matter developers. All right. That is half an hour of content on State of JS, which is good because there was not a ton of, React news otherwise. So yeah, Mark, you want to take us into our lightning round links?

[37:49] Mark Erikson: Yep. So having said that we do have a bunch of lightning round stuff to go through.

NYT and Slack update to React 18 (Enzyme to blame)

[37:54] Mark Erikson: First off, a couple of interesting company migration blog posts. We were talking earlier about, you know, like only two thirds of respondents being on React 18 and the New York Times put up a pretty big post about how they just updated React. to React 18. Some good details on the work they had to do and some of the challenges they ran into, especially with some of their embedded interactive setups, and some information on some of the performance improvements that they saw.

[38:21] One interesting note is that A lot of their work had to do with migrating from enzyme tests to React testing library. And so, on a very similar note, Slack put up a post where they said, you know, we have tons and tons of enzyme tests and we, we tried to migrate those to React testing library. And, it was so hard, we actually ended up trying to automate a lot of the conversion using a combination of AI language models and some various additional tools.

[38:52] So, this goes back to the test, and to the whole test discussion. Like, tests provide value, but they're code. And code becomes legacy. And you have to update it and modernize it. And that in itself can be a real drag on trying to change things.

Rise Tools launched

[39:05] Mo Khazali: So I'll jump in with a few things. First is that Rise Tools has been launched.

[39:11] So Rise Tools is created by Mike Grabowski. So Mike is the former founder of Callstack and he's been very involved in the React Native ecosystem. It's basically, it's not tied to React Native, but it's basically targeting React Native for now. It's a way to build server driven apps. It's a server driven UI app where the server controls how the UI is layouted.

[39:32] And it kind of comes with all things battery included, from the server, all the way up to the React primitives, and even some more opinionated UI design systems like Tamagui if you want to use it. It's kind of evolving in a way where it ends up being a bit of a meta framework on top of a meta framework.

Mo's talk about server-driven mobile UI

[39:48] Mo Khazali: So a meta meta framework, we're getting into that age of front end development. Um, but it's really cool. It's server driven UI is very difficult. And I talk about how difficult it is in mobile development, many places. And I did a talk recently at a meetup in Poland. So shameless plug. If you're interested to see why this is an actual challenge in the React native world, just take a look at that YouTube video and hopefully you'll get a bit of a primer.

[40:11] Mark Erikson: Gasp! A shameless plug on this podcast. What?

NativeWind UI launching

[40:15] Mo Khazali: Next up, Native Wind UI is launching. So this goes very much along the same train of thought as we were having a conversation about with the state of React, where a lot of these component libraries are not popular anymore, but people want these sort of copy pastable code components that have 90 percent of the stuff there and they can modify and change it as much as they want.

[40:35] It doesn't come with any behavioral APIs. It's just. UI wise, how do things look like and what do the components look like? So this is basically like Tailwind UI. It's going to be a paid UI kit, UI copy and pasteable components and templates. But I think it's interesting that the React Native community is going in this space.

GlueStack too

[40:51] Mo Khazali: Similarly, the GlueStack team. So GlueStack is, made by the former creators of NativeBase, which was another popular UI library and. GlueStack is basically the successor to that and they initially had a more batteries included opinionated API component library that is now going seemingly in a very similar direction to native WinDUI and Tailwind UI, which is, we have these copy pastable components.

[41:16] So think of it as ShadCN as well, but in the React Native ecosystem. And the lovely thing about both of these libraries is, they work universally with React Native. So if you're targeting React Native on the web, these libraries will automatically work on both web and mobile, which is really cool, and a step in the right direction.

Swift Package manager support, moving away from CocoaPods

[41:30] Mo Khazali: More in the React Native ecosystem, so, If you've been in this ecosystem, you'll know that typically what we use on the iOS and MacOS front is we will use CocoaPods as a dependency and package manager. Now, CocoaPods is good, it works, it's one that's been around for a while. The iOS native community is moving towards Swift Package Manager that Apple created themselves.

[41:53] And so now this PR got merged, but we will have Swift package manager support for React Native. So if you want to use Swift package manager, you now have the option to do so, which is going to be great for brownfield apps. So apps that are, some parts of it are in React Native, other parts are just purely native.

[42:07] This will make it much easier to adopt if you've already been using Swift package manager for your native apps.

[42:11] Now, one of the things that has been a challenge with the React Native ecosystem is around out of tree platform support and how easy it is to integrate them with tools like Expo. So out of tree platforms, for everyone who's not aware, are platforms that are not iOS and Android.

[42:26] So, web, macOS, Windows, AR, VR, headsets like Vision Pro, and so on and so forth. So those are all platforms that are not officially managed and maintained by Meta, but they have sort of community partners that are maintaining them. And so macOS is maintained by, uh, Microsoft. And one of the challenges there was how do you get Expo to work with it?

[42:45] Because previously you would need to do it in a bare React Native app, which means you have to do a lot of the typing and the wiring and all of the infrastructure underneath it. There's this concept of config plugins in Expo, and now there's support for React native Mac OS, and people are seemingly getting ready to be able to develop desktop apps with Expo, which is really exciting.

[43:03] Carl Vitullo: Sorry, wait, did you say that this is maintained by Microsoft?

[43:06] Mark Erikson: Yes. Microsoft maintains the React native implementations for Windows and for Mac.

[43:13] Carl Vitullo: Okay. Just needed to check that. Cool.

[43:15] Mo Khazali: Yes. Yeah. this is one of the things with React Native where there's so many people involved now. It's not just Meta, it's Meta, Microsoft, Amazon, Shopify, and name a bunch of other companies.

React Native Filament

[43:24] Mo Khazali: Next up, we have React Native Filament. So, it's a hot time in the 3D rendering space of React Native. there's a lot of stuff that's happening in the last few months. React 3 Fibers suddenly got a big boost in the React Native ecosystem. More and more people are talking about it. I've seen a lot of talks in 2024 about it.

[43:41] The Skia team, the React Native Skia team have also been talking about GPU and 3d rendering. So they did that at their talk in AppJS. We covered it in the podcast back in May. And so now the team at Margello have released React Native Filament. So it's a base 3d rendering engine built for React Native. The nice thing about it being C is that it works kind of out of the box for most of these native platforms.

[44:02] It is seemingly, again, this is how it's marketed, is that it's basically with less than 50 lines of code for you to load a 3d model and basically have things like pan gestures, zooming, and all of that, which is really hard to get.

[44:15] And you need to actually manually code a lot of that yourself. So this is really cool. We'll see how it, how it materializes and how it evolves. There's a lot of 3d libraries that are coming to fruition and you've got to choose and see which ecosystem grows. So you're basically placing bets on horses and seeing which one kicks off.

React Native for web devs

[44:31] Mo Khazali: On the trend of what we talked with the state of JS and, you know, how, uh, native usage is growing, Kati Kraman from the Expo team, she's written an article, a guide to React Native for web React devs. So people that haven't been in the native space kind of understand what are the things that you need to learn sort of like a TLDR before you can start creating React Native apps.

[44:51] This is amazing because frankly, this is one of the things that I always rave about and rant about, if you don't tell people about the gotchas, they'll come and burn themselves in the React Native ecosystem, and then they will hate React Native for the rest of their lives. So, I love education and good education like this, which is specifically targeted for web React devs.

Build Windows apps from a Mac

[45:09] Mo Khazali: And last in this React Native train, at least in this one, is that one of the things, again, with out of tree platforms, again, with the Microsoft team, is that they maintain React Native Windows. But you need to have a Windows machine to develop for React Native with Windows, which many of us don't, myself included.

[45:25] I have renounced the Windows days since many, many years ago. And so it makes it really hard to build Windows apps. And I've always wanted to do it. I've got an Xbox. You can build Xbox apps with React Native using the Windows implementation, but you need a Windows machine to be able to test your apps, which kind of sucks.

[45:40] So they've written an article on how you can build Windows apps, with React Native. On a Mac. The spoiler alert is that it's not straightforward, unfortunately, you have to boot up a parallel Windows machine and then sort of port forward stuff and then use it on a VM to test it out, which is not the best DevEx, but at least there is an escape hatch if you really are inclined to do so.

[46:00] So hopefully that opens the doors to React Native Windows for more and more people who are using Macs as their development drivers.

Ecosystem Performance group, e18e

[46:06] Mark Erikson: Changing gears entirely, we all know the jokes about how, you know, Node modules is the heaviest object in the known universe. you know, you install one package and you get 1, 500 dependencies installed as a result.

[46:20] And there's a lot of factors that go into it. It's how the Node ecosystem has evolved. There's also cases where, you know, certain maintainers are obsessed with Maintaining infinite backwards compatibility instead of allowing the ecosystem to move forward with modern tooling. I've been complaining for years that surely there has to be a way that we collectively as a community could go in and start You know, removing unnecessary dependencies from popular packages and end up improving, you know, download speeds and number of dependencies for everybody.

[46:52] And there's now an actual community effort to do this. It's in a group called the Ecosystem Performance Effort. And it's just a community group. They've got a Discord for discussing things and a repo for pointing things out. But it's things like, could we look at, say, the isnumber package? And find the most common parent packages that depend on it, and replace those.

[47:16] And end up saving, you know, like, cutting down on dependency trees, and saving download bandwidth for everybody. I'm very, very excited to see a lot of people actually spending time and effort on this. This is the kind of grassroots, you know, like, effort that actually benefits everybody.

[47:32] Carl Vitullo: I saw a PR specifically about inlining isNumber, and it did, I don't know if I quite 100 percent buy this math, but the math they did was, by inlining this package instead of installing it as a dependency, we save this many kilobytes. This module is downloaded this many times per week. You multiply those together and ergo, we are saving 440 gigabytes of bandwidth every week. I am, I wonder if that is how that shakes out in practice with like caching and stuff. But if by inlining is number, we can have 440 gigabytes less data flowing through the air. Uh, that's, that's fascinating.

ES2024 released

[48:10] Carl Vitullo: We have also, ES2024 has been ratified by the, by TC39. We've got the spec, which is very dense and hard to read. Fun. Rob Palmer, who's part of the team involved in that also announced it on Twitter. A lot of these are like pretty esoteric to me, like well formed Unicode strings.

[48:30] I didn't know they were not well formed. Promise. withResolvers, I guess. I don't, I don't know what that is either. ResizableArrayBuffers, ArrayBufferTransfer. Two that are a little bit more salient for me is Array. GroupBy and Object. GroupBy. What a great thing to have added to the standard library. So that's nice.

[48:50] There's a regex v flag for creating regular expressions with more advanced features for working with sets of strings. Yeah. Lots of stuff. We've got a new spec, nothing too exciting though.

Memory leaks: Compiler won't save you

[49:00] Mark Erikson: We've mentioned one or two different articles that looked at ways you can end up with memory leaks in React applications due to closures and how JavaScript engines actually behave, and there's, there's some discussion of what happens when React Compiler comes into play, and so the author of those posts did some more research and concluded that no, you can, you can still end up with memory leaks, even with React Compiler.

[49:25] It sort of ends up in the same situation where. Capturing variables in scope, and due to the way JavaScript engines work, you can still end up with some memory leaks if you're not careful. Similarly, Jake Archibald, who's done a lot of articles and research over the years around JS behavior, also just put up a very, very similar post talking about memory leaks and garbage collection with closures.

[49:46] So, this is stuff that I only sort of half understand myself. And so seeing people go into these deep technical dives to research the actual behavior is very helpful. We've also, I believe we've mentioned the new JSR package registry a couple times, created by the Deno team. And there was a video talk from, I believe, Luca, who's part of the Deno team, going into some details on You know, a lot of the stuff that I've run into publishing the Redux packages over the last couple of years.

[50:15] You know, issues trying to do the publishing, various problems with npm, goes into some details on how JSR is different, how it's supposed to work, and give some examples of actually doing the publishing. I don't know how much actual usage JSR is getting, but it's nice to see people actually rethinking this.

React Native + Flutter

[50:33] Mo Khazali: The next thing is just a little bit of memes. More than anything, someone has decided to post a demo of React Native and Flutter running in a single app, which is quite funny. Believe it or not, I actually have tried this about a year ago. And the reason was we had someone who wanted to migrate away from Flutter.

[50:50] So out of these memes, good conversations have actually started around how you can migrate and integrate Flutter and React Native together. In the case where someone wants to move away from Flutter. And you use React Native instead, so pretty fun times.

Bun Q3 roadmap

[51:01] Carl Vitullo: Earlier this month, Jared Sumner posted about the Q3 roadmap for BUN.

[51:06] He says it's not exhaustive. And in the replies, adds more like, Oh, maybe we'll get to this too. But new stuff they're looking, they, they want to add a full stack bundler. I'm not exactly sure what that means, but I guess it's going to have overlap with like RSPack and probably server components too. I don't know.

[51:22] A text lock file. So I guess another lock file format. I don't know why we need another package dependency tool. A CSS parser? on this roadmap seem confusing to me as a JavaScript runtime. He also talks about adding V8 C API compatibility, which sure, that makes sense, I can, I can see that, and getting better snapshots and timers for the bun test and mentions that he would like to ship a Postgres client sometime this quarter, but it's not in the main roadmap post that he made.

Learn Suspense by building a Suspense-enabled library

[51:57] Mark Erikson: So, we've been talking about suspense for, what, like six plus years now, but, there's been all the confusion over, how can you use suspense? Suspense only works with, React server components, or can you use it on the client? Are you supposed to use it on the client? There was a really good post that came out recently, Learn suspense by building a suspense enabled library that goes through some of the actual mechanics of trying to build a client side lib that uses suspense.

[52:24] I'll be honest, I bookmarked this one because people have been begging for suspense support for RTKQuery. I looked at the issue actually, the issue is at least three years old. So I will probably be referring to this post when we hopefully get around to doing it, maybe later this year?

Mark's talk, "Why Use Redux Today" at React Summit

[52:39] Mark Erikson: And the obligatory self plug, so I gave a talk at React Summit last month on why use Redux today, because this is a question that gets asked all the time.

[52:50] TLDR, there's a lot of reasons why people adopted Redux in the first place. Some of those reasons no longer make sense, like avoiding the legacy context API, but the architectural reasons to consider using Redux are still valid. Being able to have a centralized store, being able to see that the state changes in the dev tools, having a well documented pattern for keeping state outside the component tree, So, it's not a lot of a sales pitch, it's like half of a history lesson, and then, discussions of trade offs, because I still find myself unable to give an unambiguous sales pitch.

Chrome collects extra data for Google websites

[53:24] Carl Vitullo: Cool. This is sort of general tech news a little bit, but Chrome apparently gives Google properties privileged information about your system resources, which is sketchy as heck. Why does Google need to know how much CPU my computer is currently using? Anti competitive behavior. Chrome taking advantage of vertical integration to suck up more data to use for reasons. Not great. Not exciting.

Component, composition, colocation

[53:48] Mark Erikson: There was a really good post talking about trade offs and various architectural patterns between different ways to fetch data. Do you fetch data in hooks as components render? Do you do suspense based data fetching that starts nested down in your component tree versus do you try to kick it off, higher in the component tree, say like with a route or a page loader? Some very good actual thoughts of trade offs between these different patterns.

Secret knowledge to self-host Next.js

[54:15] Mark Erikson: And then, there was a good article from the folks at Flight Control, where they talked about challenges in trying to self host Next. js anywhere other than Vercel. It's feasible, but you definitely have to do some extra work.

[54:29] Hosting Next on Vercel is obviously the happy path, and there's some challenges to try to fill in some of the pieces that Vercel would provide for you.

Node can strip TS types soon?

[54:37] Mark Erikson: Last but not, not entirely least, a few bits of news from the Node ecosystem. Node has merged a prototype PR to strip types and allow being able to just run TypeScript files directly.

[54:50] Obviously, they're not actually checking the types, but similar to like TS Node, at least stripping off the types so it can just execute the code. Very perfect concept, but they're interested in iterating on it.

Native SQLite drive in Node

[55:01] Carl Vitullo: Yeah, there's also, there's now a native SQLite driver in Node. Like if you're, if you have Node, you can now use SQLite. Wild! Apparently this came out of As Node was adding support for more browser stuff, like, apparently, I actually didn't really know this, you can also use local storage, quote unquote, from within Node, and that is backed by SQLite, and so then they did the work, after they got local storage in there, they added on a native SQLite driver.

[55:30] I have been interested in Sqlite and the opportunities that it brings for like development patterns for a while, I'm actually making use of it in a bot that we use here in Reactiflux. I have a Kubernetes cluster set up with a Sqlite database just to keep everything co located and local. So I just have to back up a file instead of having to keep a running database server somewhere.

[55:52] So yeah, just seeing more motion on Sqlite and seeing it get closer to the, uh, the actual runtime is, Very cool. I think that's awesome.

Node moving away from CorePack?

[56:00] Mark Erikson: Then, last item. So, Node ships with the npm package manager. And you've always had to use npm to then install other package managers like yarn and pnpm globally. There's been a long running effort to give Node a way to more directly install and use other package managers automatically.

[56:21] If a project actually specifies it, and that's involved Node shipping a tool called CorePack. And it's been considered experimental this whole time, and it now seems as if there's discussions about removing CorePack. from Node. Folks like the Yarn maintainer are not happy about this, and I've seen a bunch of arguing about it, even within the last 24 hours.

[56:43] So, who knows where this is going to land. You know, it's not like it prevents you from using Yarn or PMP in either way, it's about ease of usability. But clearly there's a lot of both technical debate and opinionated feelings involved.

[56:56] Carl Vitullo: Yeah, I'm surprised to see a move towards getting removed.

[56:59] It seems like a very valuable thing to have. It seemed very in line with the general direction of trying to decouple NPM from Node. js. But like you said, it's, this seems to be still very early.

[57:12] Mo Khazali: I'm also quite surprised we've started using Corepack, and I think it's actually in the interest of other package manager maintainers, but I'm surprised they have backlash, interested to definitely read more about it.

[57:21] Carl Vitullo: All right. That is the last link that we have. Thank you everyone for joining us. We'll be back on the last Wednesday of the month here in the live stage or back in your podcast feed just as soon as we can, which will hopefully be before Monday.

[57:33] Mo Khazali: Thank you everyone for having me. Thank you for listening on to my rambling as always.

[57:37] Always a pleasure and see you all next month.

[57:39] Mark Erikson: Likewise, my two things, I will hopefully be publishing a very, very updated version of the Redux Docs Essentials tutorial within, like, the next few days, I've been working on it all year, and I will be glad to have that done. And as I mentioned at the start, I'm looking for a new position.

[57:54] So, if you have suggestions, let me know. Please contact me.

[57:57] Carl Vitullo: We gather sources from This Week in React, Bytes. dev, React status, Next. js Weekly, the React. js subreddit, and here in Reactiflux from the Tech Reads and News channel, as well as just following a million people on Twitter and looking for articles that way.

[58:11] If you see anything that it seems like we missed, definitely send us a message. An email at hello at reactiflux. com with T M I R in the subject line. That's an acronym for the show. I read every email that comes in, including spam. So I will read it, even if I don't respond to it. We actually got a tip about the RISE tools for React Native.

[58:30] Thank you for sending in a tip. That's our first one. Shout out. Thank you. If this is a show that you get value from and want to support, the best way to do so is, like, subscribe. Give it a review, help us show up in discovery charts for other people, or send it to your co workers, even if that gives away the secret of how you know so much about React.

[58:46] Thank you so much, see you next month.

This Month in React, June 2024: React 19 delayed (drama-ish), why no JS Laravel, TS 5.5 and more

Reactiflux — Tue, 25 Jun 2024 16:00:00 GMT

Quick hits
- [00:51] Layoffs.fyi
  - [01:35] Software jobs down 20% vs 2018? From ADP
- [02:12] New releases
- [06:51] Conferences (React, Javascript)
  - React Nexus July 4-5, 2024. Bangalore, India
  - Chain React 2024 July 17-19, 2024. In person in Portland, OR, USA
  - The Geek Conf July 25, 2024. Berlin, Germany
  - WeAreDevelopers World Congress Berlin, Germany & Online July 17-19
  - CityJS Singapore Singapore, Singapore July 24-26
  - ~~We Love JS~~ Unfortunately this appears to be a fake event
  - React Rally August 12-13, 2024. Salt Lake City, UT, USA
Main Content
- [09:43] React 19 delayed
  - [09:55] Previously, per Andrew: React 19 was ready to release
  - TKDodo: React 19 and Suspense - A Drama in 3 Acts , and also How React 19 (Almost) Made the Internet Slower
  - [19:03] Joe Savona “We'll hold the 19 release”
- What does the React team want for data fetching?
  - Seb: “We never released official Suspense on the client, we did RSCs instead” and “Some people got the render-as-you-fetch memo. Some people chose to ignore it.”
  - Andrew: “the community shouldn’t think ‘we bullied React into changing fetching strategies”.
  - Related: how do we communicate with the React team?
    
    [21:33] Tanner Linsley: “I feel there needs to be a permanent React + community working group”
    
    Joe Savona: “we’re working on ideas to get feedback earlier and more users trying canaries”
- [23:42] TC39 proposals advanced
- [26:05] Codemod partners with React
- [27:52] React Compiler
  - [28:03] I tried React Compiler today, and guess what... 😉
  - [29:32] Understanding React Compiler
- [29:50] Why We Don't Have a Laravel For JavaScript... Yet
  - Why Don't We Have A Laravel For JavaScript?
- [35:45] Vercel Ship 2024
- [37:35] TS 5.5 released
  - Matt Pocock breaks it down
- [40:41] Mind the Gap by Ryan Florence at Big Sky Dev Con
- React Native Stuff:
  - [41:36] Lorenzo leaving RN world 😭
  - [43:47] Expo Atlas available
  - [46:40] Expo adding React Compiler support
  - [46:52] Starlink’s RN story
  - [47:14] Expo Router 3.5
  - [48:16] SF Symbols Beta Support in Expo
⚡Lightning round ⚡

[00:00] Carl Vitullo: Hello, thanks for joining us. This is June's edition of This Month in React, where we recap and digest the recent developments in the ever evolving React and web ecosystem. We're coming to you live from Reactiflux, the place for professional React developers.

[00:13] I'm Carl, I'm a staff product developer and freelance community manager here at Reactiflux, where I run community programs like these events and build tools that help keep the community going.

[00:24] Mark Erikson: Hi, I'm Mark Erikson. My day job is working at Replay. io where we're building a time traveling debugger for JavaScript. And outside of that, I do Redux stuff.

[00:33] Mo Khazali: Hi everyone. I'm Mo. I head the mobile team at Theodo. I'm quite active in the React Native community and I organized the React Native London meetup and here and there dabble in open source with a couple of libraries in the React Native ecosystem. Very happy to be here.

[00:47] Carl Vitullo: Uh, I'm just going to start off with some quick hits of new releases and conferences.,

Layoffs updates

[00:51] Carl Vitullo: Starting off immediately, because the market, the job market is so bad, I've been reading off stuff from layoffs.fyi.

[00:59] We're not quite at the end of June, it's a couple of days left at time of recording, but most of the way through June, we're at about 9. 2, 000 laid off from 40 companies, which is down, I mean compared to six months ago we're down substantially, but compared to two years ago we are up substantially, so it's still not great. I've seen some other broader metrics trickling out from other places, like I saw a link from ADP that I unfortunately don't have handy suggesting that the overall like, tech market is at about 80 percent of it was, I believe, compared to 2018.

The rise—and fall—of the software developer

[01:35] Carl Vitullo: Yeah, I, I found that really interesting because between hearing headlines about like record hiring during the pandemic and record layoffs in the two years, after that, it was like, Where do we end up? So that's the first data point I've seen, uh, addressing that question of, like, what's the net gain loss, and it suggests net loss of, like, 20%, which seems massive, but yeah, it's also, it's ADP, I don't know how much to trust that, I would assume that they got a very large sample size, but I'm not sure how they defined, like, tech, so, I don't really know how to interpret that in, through a lens of like software development.

New Releases

[02:12] Carl Vitullo: But yeah, moving on to some new releases.

Turborepo 2.0

[02:14] Carl Vitullo: There is TurboRepo 2. 0. That's probably especially relevant if you're doing stuff with Next. It looks like it's mostly like a fancier UI. They're doing like a pretty high effort in terminal UI. Like it's, you know, reactive and interactive. And you can now break down your logs on a per task basis rather than it just being, you know, a constant scroll back the way terminals usually are.

[02:38] So that seems neat. Oh, they had some new docs, and it looks like they included some, like, fundamental information about Monorepos, which seems cool.

React Admin v5

[02:47] Carl Vitullo: React Admin released version five. We actually had Francois Zaniotto, hope I'm not mispronouncing that, on as a guest a couple of weeks ago, and I think he's super cool.

[02:57] I love his ethos for the company that he's building, which maintains React Admin and does agency work. So I just wanted to shout that out.

Rsbuild 0.7

[03:04] Carl Vitullo: RS build released version 0. 7, which they say is going to be the last release before 1. 0. Mark, you had some thoughts?

[03:14] Mark Erikson: ByteDance, the folks behind TikTok, have a massive web tooling infrastructure team. They've actually rebuilt Webpack in Rust, and I know that, you know, rewrite it in Rust is its own meme at this point, but it seems like they've, they've truly built a Webpack compatible version in Rust called RSPack. On top of that, they have a higher level abstraction layer called RSBuild, which has an easier configuration format, a little bit like ESBuild does. if you actually look in their docs, they have a migration guide for switching from Create React app to RSBuild. I did that on a little side project a few months ago.

[03:55] It was really easy to switch and the compile time dropped from like 30 seconds to less than a second. it feels like a, an actually viable competitor tool.

[04:06] Carl Vitullo: Nice. Super cool.

Biome 1.8

[04:08] Carl Vitullo: We've also got biome 1. 8. Yeah. I have a soft spot for biome. I was an early supporter of Rome. I have been eager to see what comes out of that.

[04:17] So yeah, it looks like they've got like new support for CSS. They have better support for language servers in workspaces, so if you've got like a big monorepo, it should work a little bit better. New reporters, migration, some more linting options, but yeah, Biome is like kind of an all in one. They try to do like formatting and linting and, yeah, it's a bundle play.

[04:38] They're taking in a bunch of tools that, were separate and doing it all as one package.

[04:42] Mark Erikson: And written in Rust.

[04:44] Carl Vitullo: Written in Rust. Sure. So super fast, blazing fast. Is blazing fast still cool?

Astro 4.10

[04:51] Carl Vitullo: There's also Astro 4. 10. I am hoping to play around with Astro this month. So maybe I'll be able to actually, you know, say some more intelligent things about what the experience is.

[05:01] But I, I know lots of people who love the tool. It looks like some small improvements, nothing too major.

Valibot 0.31

[05:06] Carl Vitullo: This is a new library to me, Valibot released 0.31.

[05:10] It's a competitor to Zod, which does like schema validation or, you know, data validation through a schema with like type generation and all that kind of stuff.

[05:19] This looks like a pretty solid competitor. They talk about, tree shaking and stuff, which I'm broadly skeptical of tree shaking as a general promise. It's very difficult to verify.

[05:30] Mark Erikson: My understanding is that Zod, when you import it, you're basically importing a giant object that has all the possible validation types built in, and I think Valobot's sales pitch is that it's a bunch of individual functions, and so you would only import the actual bits that you need.

[05:47] And therefore, you're not getting a giant blob of runtime code.

[05:51] Carl Vitullo: Yeah, I think they said it was like, could be up to like 95 percent smaller than Zod, while also like significantly simplifying the mental model of the schema and the type validation.

[06:02] If I can think about it less and have it affect the size of my code less, like both of those sound like things that I would want.

[06:10] Mo Khazali: I guess the thing is, it's a question of how much you want to really optimize your bundle size and at what stage you're at. If I'm recalling correctly, Zod minified and gzipped was about 60kb, something around that size.

[06:22] So it is quite a chunky library to add into your dependencies. So, I guess if this actually delivers on that promise and it's closer to 90 percent less than that, which is I guess 6kb, it wouldn't be too bad of a shave to do, I'd say. But, remains to be seen if it's in practice going to be that good.

[06:40] Carl Vitullo: Yeah, I just pulled up Bundlephobia for Zod, and it's, yep, 61kb minified, 14kb minified and zipped. Which is Hefty. Yeah, that's enormous. That would give me a lot of pause.

Upcoming Conferences

[06:51] Carl Vitullo: Onto some conferences. Mo, I think you had a few.

[06:53] Mo Khazali: Yeah, I'll jump right in.

React Nexus

[06:54] Mo Khazali: So, firstly, at the very beginning of July, 4th to 5th of July, React Nexus is happening in India.

[07:00] One of the great conferences that I attended last year, I really enjoyed. The crowd there was quite a, quite a large crowd as well. I think there's about 500, 600 people. So a massive conference, but people are so friendly and I got to meet a lot of lovely people. So would highly recommend if you're sort of in the South Asia region to, to definitely give it a shot, if you can make it to Bangalore.

Chain React

[07:19] Mo Khazali: Mid July, we have Chain React and this is hosted by the folks at Infinite Red. Another one of those great conferences. I've not been to Chain React myself, but I'm, So involved in the React Native community that I get told every year, why are you not at Chain React? And you're missing out on one of the best conferences ever.

[07:34] So the FOMO hits real hard every time around Chain React. The folks at Infinite Red are absolutely amazing, and they organized an incredible conference from all accounts that I've heard of. Everyone really loves Chain React, so if you are in the U. S. and you're in the React Native scene, you really do not want to be missing Chain React. If I was in the U. S., I would definitely be at Chain React this month, so I cannot give it more praise than that.

GeekConf

[07:58] Mo Khazali: And then, lastly, towards the end of July, we have GeekConf, so GeekConf is another sort of React Native conference with a little bit of a blend of web as well added into it. So that's happening on the 25th of July in Berlin. There's also a day that's dedicated to remote track, but 25th of July is the key date that's going to be happening in person, and I'll be speaking at that conference as well, and hopefully if any of you folks are there, please do come around and say hi, would be lovely to meet some of you in person.

[08:24] Carl Vitullo: Heck yeah.

WeAreDevelopers World Congress

[08:25] Carl Vitullo: Leaving the list of conferences that us as hosts have personal experience with, there's a We Are Developers World Congress in Berlin, July 17th through 19th.

CityJS Singapore

[08:35] Carl Vitullo: There's a CityJS in Singapore. That's going to be July 24th through 26th.

We Love JS Amsterdam

[08:42] Carl Vitullo: We love JS in Amsterdam in the Netherlands, August 9th and 10th.

React Rally

[08:46] Carl Vitullo: And then the last conference that we're highlighting in the next two months is React Rally, which is going to be August 12th through 13th in Salt Lake City. Actually, I have been to that one in the past and it was pretty quality.

[08:58] Mark Erikson: Yeah, I, I would also. Emphasize like React Rally has been fantastic. the organizers are great.

[09:04] they do a really good job of giving it a good community feel. I was there last year and attendance was unfortunately just a little down because of trying to revive it after COVID. So if, if you can all make it to React Rally in August, please go. It's, it's totally worth, worth it.

[09:19] Carl Vitullo: Yeah, and it's the home neighborhood for a lot of really big people in the React and web ecosystem.

[09:25] there are quite a number of people who live generally in Utah and in Salt Lake City. I think Kent C. Dodds is out there.

[09:32] Mark Erikson: Kent, Tanner, Ryan.

[09:33] Carl Vitullo: Yeah, it's their home neighborhood. I assume they'll be at the conference. Yeah, anyway, cool. All right, moving on to some of our main content here. Mark, you want to start us off?

"SuspenseGate"

[09:43] Mark Erikson: Boy, oh boy, oh boy. Okay, welcome to SuspenseGate. So, for the for those of you who may not have been following all the drama on Twitter, we're here for you.

"This is the exact build we'll release as 19.0"

[09:55] Mark Erikson: About a month ish ago, a month and a half ish ago, Andrew Clark actually tweeted that, We've, we've updated to a new React 19 release candidate, and we think that this release candidate is going to be the final one, like, these are the actual bytes we plan to release as React 19, unless there's any other major changes.

[10:17] Well, there is now cause for major changes. And in fact, React 19 has been delayed semi indefinitely. The React team is going to be doing some updates, and we don't know how long that's going to take. Why are they doing these updates?

[10:32] In November of last year, Andrew Clark put up a PR that changed the behavior of the suspense component and how it manages loading children that are suspending to fetch data.

[10:44] Previously, if you had multiple children inside of suspense, And they all wanted to fetch some data. The suspense component would give each of these components a chance to start rendering and start the data fetching. And then actually pause and wait for all of the components to finish fetching their data.

[11:04] Doing it all in parallel, kind of like a promise. all combination. And with this PR, the React team changed it. So that React really only gives the first child that suspends a chance to fetch, and then it waits for that child to finish loading its data, tries to re render, and then keeps going until the next child component tries to fetch data.

[11:28] Basically doing all of that in serial instead. Now, they, if you look at the PR, Andrew listed some potential reasons for this. One is that this actually made Facebook. com load a little faster. But also, it has to do with how the React team thinks. that people should be doing data fetching on the client side.

[11:51] And basically their argument is, you, you shouldn't be doing data fetching nested deep in the component tree. Instead, you should hoist it up to the top at like the route level or the page level instead. And so their argument is like, well, we don't think people should be doing this pattern much anyway.

[12:11] So it's okay for us to change it. Now, this was done as part of React 19's development, and React 19 is a major version. So you can totally, you know, make changes. It's, it's legal under the terms of semantic versioning. And this was available in the React 19 Canaries, but as we all know, nobody actually tries out pre release versions, everyone waits until it's actually released, and then tries it, and then reports bugs.

[12:38] So, this basically went unnoticed by the community for months. And about a month ago, someone mentioned it on Twitter, very briefly, and TK Dodo, the maintainer of React Query, Saw that comment and said, oh, that doesn't look great, and then didn't think about it. And then just a couple weeks later, there was another discussion thread, and suddenly TK Dodo and a bunch of other people began to realize, wait a minute, this is actually a very significant change in how suspense works.

[13:08] And in particular, the React 3 Fiber developers, which is the React for 3D game engines, Realized we depend on suspense heavily because we need to be able to load a lot of different things async like game assets. So it's not just about data fetching, it's about lots of other async behavior. And they, and they started showing demos where, everything went from loading in parallel to loading as a waterfall in serial.

[13:38] And now example apps were way, way slower as a result. There was a massive firestorm on Twitter. A day or so later, Sophie Alpert from the React team said, We talked about this in a React team meeting today. We didn't realize how many people would be affected by this. But also, this was a very major change to React's internals. We did this, like, seven months ago. We've continued making lots more changes to the internal since then. We can't just roll back this change. We know what we would need to do in order to re enable the old behavior, but it's going to take another fairly significant set of internal changes to do that.

[14:19] So, we don't know when we're going to get around to it. Stepping back for a second, at that point in time, the community conclusions were, they already said React 19 is release candidate and ready to ship, and we don't, like, we know this would take major changes. Therefore, the conclusion was React 19 is about to ship with this behavior and we're all going to be stuck with it for the duration of React 19 as a major release.

[14:45] Carl Vitullo: Yeah, I don't know, some of the like firestorm framing for this, it makes me a little bit like, I don't know, it's, okay, this was a, this was a confusing behavior, and something that they overlooked, but I am glad that this conversation did happen.

[14:59] And ultimately, the React team had this pointed out to them and did respond ultimately, I think, appropriately. So, like, it's, I don't know, how do you, How do you do open source development with millions of people, very few of whom actually try out pre releases?

[15:15] Mark Erikson: Yeah, that actually even ties into the events this week of Jordan Harband and some of the package updates going on. Mo, you had a thought?

[15:24] Mo Khazali: Well, I was just thinking, well, firstly, ironically, I remember when we did the last, last month's episode, we were talking about how this might be like the quickest release cycle for React, or, well, you know, it'll be a quick transition into Release Candidate and then released, and then this came up. So I find that quite funny that sometimes these things will come up and we can't predict it.

[15:41] But I think it's, you know, around the whole expecting people to test canaries and, and release candidates, I almost wonder if there's a different way that that needs to be done and if there's some level of automation that can be done to ensure that not just, you know, apps that are using RSCs and are, you know, the most up to date and exactly architected in a way where Meta wants them to be architected, are tested, but rather, there's a whole wide range of apps, ones that are built over a long period of time, there might be SPAs or other things like that, all of those get tested. I don't know if there's a nicer way to handle that, but I feel like just expecting people to test Canaries and test RCs will not catch stuff like this .

[16:20] Mark Erikson: That's the thing, I believe the Vue ecosystem has like a full fledged, I don't know the right term for it, they have a massive automation setup that tests all kinds of libraries across the ecosystem against the latest versions of like Vue and Vuex and Pinia and Vue Router and all these other tools. And similarly TypeScript, every time you push a PR to TypeScript, it does checks against almost all of DefinitelyTyped, or at least like a, the most widely used libraries on, on DefinitelyTyped and across the ecosystem, to try to catch a lot of these issues ahead of time.

[16:56] But even then, there's a distinction between, do the library's tests fail, and how are people using that library. I think in this case, React Query had one test that did parallel fetching in a suspense, but it was like two components running locally. And so the effects of it would not have been meaningfully visible in terms of timing.

[17:18] Carl Vitullo: Right. Right. And ultimately this is a like timing and parallelism issue. And I don't know, I'm not sure that that's something that would work. have been proactively tested? Like, I'm not sure that it's something that An automated test suite could like reasonably easily evaluate. And I'm not sure that someone would have said, Oh, this is a large enough risk that we need to invest, you know, several days of engineering time in order to make sure that we have test coverage that will flag this if it breaks.

[17:48] So I don't know, I, to me, this is just like such a. Niche interaction between, you know, it's, it's such a corner case between the assumptions of the React core team and the, you know, evaluation work that they do against the Facebook project and the, you know, broader needs. So like, I don't know, I saw various negative takes, like, oh, I don't know, I saw lots of various negative takes, I'm not even gonna try and imagine, try and make up one.

[18:16] Mark Erikson: the React Summit organizers for the last couple years Have done an event that they call the React ecosystem contributors summit, where they get like 25 to 30 maintainers and contributors to various tools and libraries together in a room. And they just give us a chance to vote on whatever topics we think would be worth discussing and then give us three hours to, talk about it in whatever way we think would be useful.

[18:44] So, I was there. There were two topics that were discussed. Two thirds of the room was discussing the technical aspects of the suspense change, two thirds of the group was discussing the technical behaviors. One third of us were discussing, how can we have better communication and interactions with the React team.

Joe Savona: Some thoughts on the suspense changes from 19 RC

[19:03] Mark Erikson: A couple of days later, Joe Savona from the React team put up a long Twitter thread, which is very, very good and very worth reading. And he said, number one, we're going to hold off on the React 19 release. We agree that this is a major behavior change. And frankly, we underestimated how many people would be affected by this pattern change.

[19:24] So they're going to step back and they're going to do something to do it. My, my, my assumption is trying to do the actual work to re implement some of the older behavior in the, in the reconciler internals. So that's good. Like the community complained, we communicated, they listened, they changed plans.

[19:43] These are all actually very, very good things, but that ties into the communications question. Like a semi official way to communicate to the React team is by filing an issue, and the React issues are basically useless in that sense. One thing, they've been full of spam, both in terms of like really, really old issues and literal, literal spam issues, but also like the React team doesn't pay tons of attention to their issues list.

[20:10] And so just filing an issue is not necessarily going to get like a quick response. There's Twitter, and a lot of the, you know, React team members are very active on Twitter, and that's great, but it's also not like a formal communications channel. So, what we concluded in our little set of people talking during this Contributors Summit, is that we really need to bring back this idea of a working group.

[20:36] For React 18, the React team put together a React 18 working group where they specifically invited 50 to 75 people from across the ecosystem and continued adding to it over time. And there was a public GitHub repo where the React team and the invited contributors could write comments. Anybody could read it, so the discussions were public, but the idea was have a high signal ratio of meaningful discussions and questions about React 18, how things worked, how people could actually use some of the features and what the practical results would be.

[21:12] And I think that was a great success. Like, there was a lot of really good information in that repo. So our conclusion, as the little group of people talking amongst ourselves, was we should somehow have a permanent version of the working group. And actually, Tanner Linsley independently tweeted the same thing a few days later, as well.

Tanner Linsley: React needs a permanent working group

[21:33] Mark Erikson: So along with that, Joe Savona also said in his tweet thread that we are actively looking at how can we get more feedback on pre release versions and how we can actually Have better communication with the community. So, I don't know exactly what will happen, but I'm hopeful that something like this working group model would be an option going forward.

[21:55] Mo Khazali: That's not, you know, too far away from how the React Native team does it, you know, for, for the past couple of years, I'd say, since, you know, Nicola Corti and Riccardo have come into the React Native team, they've been pushing this sort of release cycle where they'll have two, three different people from the community owning the release process for each version of React Native that comes out, and that Inherently add some level of community involvement to the releases.

[22:17] Obviously a working group with more and more and more people, you know, about 60, 70 people sounds like there's going to be even more exposure, which is great. But I think it's, it's something that could take a page out of the React native core teams book as well, because they've done it successfully there.

[22:29] Mark Erikson: Overall, takeaways are, nobody tries pre release versions, we really need a formal communications channel between the React team and the community that they will pay attention to, and that we can collectively offer feedback that they will see.

[22:44] Carl Vitullo: Yeah, I, I, I chimed in on that because I don't know, Reactiflux, we're a thriving subset of the community.

[22:50] Maybe we could be a neutral space for that type of communication to happen where they don't need to own the moderation side of things that has not turned into a conversation. So, hey, maybe it will eventually, but yeah. Twitter is definitely, I'm not sure how effective it was ever as like a DevRel, you know, source of truth, but now, like, if you don't have an account, they don't even let you view tweets, so, I think it is past time, well past time for DevRel from the React team to go somewhere else. Like it is, it's been over a month since the last blog post. And other than that, I don't know where any communications from the React team out to the broader community come from. It's basically the blog and the Twitter and the blog is not active. So. Yeah, I hope that that working group concept turns into something a little more effective.

TC39 proposal advances

[23:42] Carl Vitullo: But yeah, okay, cool. Next subject, TC39 proposals. A bunch just came out. I'm just going to kind of run through this on the high level. Yeah, promise. try, it looks like it's pretty much just like a quick wrapper on, , you know, new promise, and then you immediately resolve with a value.

[23:58] I've done that a number of times, so I guess there's a use case for this, but in the abstract I'm not really coming up with a great example of why you would want to just Take a synchronous value and make it a promise.

[24:09] Deferred import evaluation seems useful. it's a way, it's a way of delaying execution of some parts of the import process when you're getting a module in.

[24:20] You can, you know, mark it as deferred so that it will not actually evaluate the module. It'll still like parse it and do some other interpretation steps that I'm blanking out at the moment. But it will not actually evaluate the code until later on.

[24:33] Mark Erikson: Basically this, this allows. Speeding up, like the initialization process by not running all the code in the application right away on startup, even though you know, you'll need some of that code later.

[24:48] Carl Vitullo: Yeah. Okay. There we go. Another one was joint iteration. I thought this was pretty cool because I've needed this a number of times. It's a way of iterating over more than one. iterable at the same time. That's on stage 2. 7, which means it's still pretty far from getting shipped.

[25:03] Error. isError seems very useful for, for types. I guess lots of new stuff is moving down the pipe, I don't know how many of these are super important to call out in great detail, but yeah, Mark, Mo, anything that caught your eye is particularly important?

[25:18] Mo Khazali: I, I really think Error.isError is the one that I'm most interested in. Obviously quite a while away before it gets to adoption. It's still on the process step two, it's stage two, but hopefully very soon. Well, I don't know how long this process is going to take for them.

[25:31] It was interesting. The TC39 meeting that they had was happening in Helsinki, uh, near Future Frontend, which was a conference that we gave a shout out to last month.

[25:39] And I happened to be there. That was quite cool to see some of these folks gather together and how they chatted about some of these standards. Just being privy to those conversations was fascinating. So they have a, they have an incredible process that I've, I've not seen anything like before in any other sort of working group.

Panel discussion at Future Frontend

[25:53] Mo Khazali: So quite interesting, would recommend. There's a, if you go onto the Future Frontend streams, they actually have a big panel discussion for, from the second day of Future Frontend, and they actually discuss some of these proposals in detail, which is quite cool.

React partners with Codemod

[26:05] Carl Vitullo: All right, let's move on to the next one.

[26:08] This is, I'm, CodeMod they announced they are partnering with the React team to help migrate to React 19.

[26:16] I know, I feel like the React team initially popularized the idea of CodeMods. So this is like not a surprise at all to me. I guess I wasn't really familiar, wasn't really aware of Codemod as like its own separate team. I see, you know, this is posted by the founder of CEO of Codemod, I guess.

[26:34] So that's kind of news to me. But yeah, so there's gonna be more Codemods, I guess, to help your codebase stay up to date with React 19.

[26:42] Mark Erikson: I am very familiar with code not code mods as a technical concept I had no idea there was an entire company devoted to building tools for code mods as like a corporate thing.

[26:53] Carl Vitullo: Right, right as a technical thing Very familiar. I don't really understand what the business case for that would be. I don't know, I guess maybe consulting. Maybe it's a services business.

[27:03] Mo Khazali: Apparently the way that they also make it more effective is that they apparently pair it with some AI. It might be a pivot, I don't know, but apparently they pair it with some AI and some nice CLI tools to make your code mods more effective. That's not an endorsement, I don't know if it works well, but that's seemingly their model.

[27:20] Carl Vitullo: Makes me a little skeptical, but yeah, I don't know. Codemods generally are great.

[27:24] Any migrations and like major refactorings like that are definitely substantially helped by having automated tools that do, you know, even if it's like 60 to 80%, that's still pretty great, but yeah, cool. So there's an official partnership there. So I guess there's a business that is writing these codemods and the React team is in collaboration with them to make sure that they work well.

[27:45] That's cool. That's great. Love that it's not just the core team trying to do everything on their own. Yeah, Mark, you want to take us on to React Compiler?

React Compiler

[27:52] Mark Erikson: Sure. So, React Compiler came out in beta at ReactConf, and so we're starting to get, you know, various examples of people trying it out hands on in the real world.

I tried React Compiler today, and guess what… 😉

[28:03] Mark Erikson: There was a very good post from Nadia Makarevich, I believe is the name, who has written a number of excellent articles about React rendering in the past. And she tried it out on both some toy applications and some larger, real world codebases that she had. And she found that the results were mixed. She expected the compiler to optimize fairly large percentages of the components in those codebases.

[28:29] And it only seemed to optimize like 20 or 30 percent. Now, , apparently the compiler tool does have a health check command that will tell you which components it would bail out of because those are breaking the rules of React. And I believe that the updated React lint rules can also give you an indication of which components might not get optimized.

[28:51] But her takeaway, I believe her takeaway was You know what? Well, okay, like this, this seems promising, but if real world code bases aren't going to get, or are we going to have like 20 to 30 percent of the components improved, that's not quite what we were pitched. Now, I will note that, uh, Satya from the React, React compiler team, I believe commented here in Reactiflux that, hey, this article is great.

[29:14] Like, we got to See these example apps that she posted about, and we've been doing a bunch of additional changes to make sure we're handling those cases. So, I mean, just because it didn't work perfectly in her case, doesn't mean that the compiler's bust. It just means that it's still a work in progress. So having that real world feedback is actually very good.

Understanding React Compiler

[29:32] Mark Erikson: And then Tony Alicea, wrote an Excellent article that actually breaks down what the compiler does and what the output looks like and how it works in practice. So, very worth reading if you want to understand what the compiler actually does for you.

[29:47] Carl Vitullo: Heck yeah. Cool. Yeah, I guess I'll move us on.

Why don't we have a Laravel for JavaScript... Yet

[29:50] Carl Vitullo: I wanted to call out this There's been a lot of, conversation that I've seen around, like, Laravel, specifically, specifically Laravel, Theo put out a video that then somebody wrote a blog post replying to of, " why don't we have a Laravel for JavaScript?"

[30:06] And this actually crossed my radar from somebody who's not in the React world at all, they were talking about scoping a project, adding authentication to some app. And they said, "this developer estimated two weeks to add authentication to the product and I thought that was ridiculous. We have that out of the box in Laravel."

[30:24] I, I, I chimed in because it's like, you know, I've done auth a couple of times in my life, in my career and like, yeah, you know, okay, sure. A login form, that's not hard to do in a day, but when you get like a settings page and you know, you got to be able to change your email address and reset your password and do two factor authentication and, you know, social login, It's like, you know, I mean, two weeks doesn't sound that wrong to me.

[30:48] And he replied like, All of this is, all of that, everything you just described comes out of the box in Laravel. And it's like, alright, you know what, okay, maybe we do complicate things a little bit. Maybe not overcomplicate, but I guess, it, it, we do have so much flexibility and modularity and ability to Write things from scratch in React and, you know, in the React ecosystem more broadly, maybe that we have, you know, as far as the pendulum swings, maybe we have stayed in maximum modularity mode for a little bit longer than might be optimal.

[31:21] I don't know. I, I'm curious what you guys think of that. where's the trade off? Where's the optimal line between modularity and out of the box functionality? I

[31:29] Mark Erikson: mean, I think a lot of it also is the, you know, the whole back end, front end split. I mean, Laravel, you know, PHP, Rails, Ruby, they are back end languages, and the use case is You know, like, you know, the back end is doing basically all the work for you, and then, you know, there, there might be some additional stuff on the front end.

[31:53] And so I think the frameworks there, they've, they've been around longer, and also they evolved to have, we, we need to have everything the back end needs to do all the work. Whereas, JS has always had the front end, back end split, and it's not that we couldn't build something that was, you know, absolutely out of the box like that.

[32:13] I mean, there are, you know, some examples of that in the JS ecosystem, but I think it's typically been much more of a, like, I just need a basic HTTP server like Express. to serve up my client side code and then go from there. So, I think the modularity is a big aspect, but then also the differences in, like, the ecosystem historically as well.

[32:34] Mo Khazali: I do think, you know, I've spent a bit of time working in the Django world a little bit, and I can definitely see the appeal to having something like Laravel, where so much comes out of the box. Done for you. And that interconnectedness means that it is a lot smoother to do things like you mentioned, like settings on a profile to modify those things.

[32:51] They're all like one centralized model in Django. And it's significantly easier to create those sort of CRUD operations for users on like a settings page. It doesn't take you weeks. It takes you a day. And I know a lot of people who've been developing a while, like they spent time in the PHP world or in the Python world with Laravel or Django, and then they, you know, started doing React in our company and they were all like, this sucks, really don't like doing this.

[33:12] It was so easy with Django, but I guess it's the pendulum swings and we probably land on some sort of midpoint, you know, I wouldn't be surprised if people start building things on top of Next, which allows it to be a more full fledged opinionated server that also can render and template React code.

[33:26] Mark Erikson: That's what Blitz was. Blitz started off as the whole suite of things to go with Next, and then they tried to fork Next, and then they gave up on that idea.

[33:35] Carl Vitullo: Yeah, and I mean, I guess this is, over the last ten years, React has slowly, I feel like it's grown in scope of, like, where people want to use it.

[33:43] Like, when I first started it, There was a lot of, put it in, like, this spot, this little rectangle on the website, like, that's where React goes, and several years ago, that moved into, most people are using React to build their entire app, like it owns the entire client side, and now we're moving Up the chain into React owns more of the server side as well.

[34:05] So maybe that's just kind of like the, this projects like Laravel already owned the data model in the server. And they had to come from there into owning more of the client side to provide a better experience there. And they certainly don't compete with React there in any meaningful way. Like nobody would, I don't think anyone would seriously suggest that projects like Laravel are able to provide. An exact, or a highly comparable, interactive client side experience.

[34:35] You know, as I'm saying that, nobody would argue that. I think DHH has seriously argued that.

[34:39] Mo Khazali: I was gonna say DHH hasn't argued that yet.

[34:42] Carl Vitullo: So, okay, people do People do argue that, but let me add the caveat of offline capable. I don't think anyone would seriously argue they provide an offline capable client side experience comparable to React.

[34:54] And so, yeah, I guess, you know, now with, as server components expand in utility and capabilities, like, yeah, maybe we will start seeing more of a Laravel. Or Ruby on Rails type of full ownership of the experience, which would make it more easy. Because that's really the problem here is React isn't even aware of the data model in most applications.

[35:18] So that makes it very hard to do CRUD interactions, if you don't have the data, if you don't have direct access to the data. I just thought that was a really interesting framing for this. Like I have all, I've, I've lived in React for many, many years. And so then seeing people talk about how quickly you can do common tasks in a Laravel, it's like, Oh, Shit. Interesting. That's, that is a big difference.

[35:39] Cool. Let's move on to Vercel Ship, their conference roundup. Moe, do you want to take us on that?

Vercel Ship 2024

[35:45] Mo Khazali: Sure. just the general and quickly running through this, Vercel is obviously moving across and, and taking up more of the, more than just becoming a hosting platform, so.

[35:54] There's pieces on how you can collaborate and people in different teams can collaborate and, you know, preview different sort of webpages. And we've seen some stuff like that and more focus on observability. So they've added things like metrics and feature flags. And so there was someone who actually commented on Twitter about how beautiful their toolbar was as well, which I thought was quite cool. But no, there's, there's like a lot of direction around like product collaboration and a push in that, in, in that direction. So that's quite interesting.

[36:18] Just on the observability piece, I actually found it quite interesting that hosting providers are going in that space. So Cloudflare a few months ago acquired Baseline, which is also an observability tool, and I think they're trying to integrate it into their workers slash Cloudflare pages space, which is a competitor to Vercel's, you know, hosting platform plus their, their serverless functions that they've got.

[36:37] So, or the edge functions that they've got. So I think it's interesting that a lot of them are moving. Past just hosting into that observability space as well. And I think there's going to be a pretty big competition in that space in the next couple of years.

[36:48] Carl Vitullo: Okay. That makes sense. Yeah. I haven't yet played with this at all, but I think I've heard people discussing the Vercel, metrics and feature flagging and that, yeah, I think that the, tacking those onto the, to a hosting provider does make a lot of sense to me because I feel like you get, you start getting a lot more things for free if those are all bundled together into one thing, like, I don't know, just having used LaunchDarkly and other feature flagging tools like that.

[37:14] It feels like if they knew when a release was happening, if those feature flagging tools knew when a release was happening, I can imagine various optimizations or improvements to the, like, developer experience, the experience of putting out a new release that could be enabled by that. So yeah, that's something I'm paying attention to.

[37:34] We'll see how that goes.

TS 5.5

[37:35] Mark Erikson: All right, next up, TypeScript 5. 5 is out. And the, the single biggest thing that is interesting about this release is what they're calling inferred Type predicates. So as a little bit of background, one of the nifty things about TypeScript is you can write code that does runtime checks, and TypeScript uses that to narrow down TypeScript type of a particular variable is.

[38:00] And part of that is not just having like an if statement, but actually having separate functions that, for example, accept any value, and then they do some runtime checks and you tell TypeScript, if this function returns true, then the actual TS type of the value must be some more specific type. And so you can use that to tie together runtime checks and type and compile time behavior.

[38:27] But the issue was that things like filter callbacks for arrays, which return a boolean, didn't do any of that narrowing. And so you might have, like, an array that could be, like, item or null, and you could do a check. In the filter callback and say, if thing is not null, you know, return true, which ought to tell you that by the time we're done, we only have actual items and no nulls.

[38:53] But TypeScript wouldn't automatically narrow down the TS types based on callback functions like that. So with TypeScript 5. 5, they've improved the type inference. So that if you have a function that accepts some value and does some checks and returns a boolean, TypeScript will automatically try to narrow down the TS types of the output to be stricter.

[39:18] And so, this is going to be a nice little quality of life improvement for a lot of different TypeScript use cases. One other interesting thing that I saw in there, is that apparently they're doing some syntax checking on regular expressions. Mostly just catching things like, you know, like you have too many parentheses in there.

[39:36] But that one's actually pretty cool too.

[39:38] Carl Vitullo: Yeah, definitely super cool. I, on my list of things that I, that would make me excited, like typescript checking regexes was not on there, so I, Very unexpected for them to even start moving in that direction. But like, heck yeah, please help me make my regexes a little more robust.

[39:54] Mark Erikson: One other thing towards the bottom that's under the hood. So they've done some changes on their internal variable definitions. So that they get more optimized by the JavaScript runtime, basically making sure that the same fields always exist. And you don't like occasionally add an extra field to the object dynamically.

[40:15] And so because of that, the runtimes are able to optimize the behavior. And they found that it actually improved compile times by like 5 to 10 percent just by making the fields more consistent.

TypeScript 5.5 is a BANGER

[40:26] Carl Vitullo: Yeah, I also want to share, Matt Pocock did a really great, just like quick 10 minute video breaking down what's new in TypeScript 5.

[40:35] 5. So definitely worth, he's just such a great TypeScript expert. Just wanted to call that out. Great resource.

Mind The Gap talk

[40:41] Carl Vitullo: Cool. I wanted to shout out a conference talk by Ryan Florence that came out of Big Sky DevCon. I saw quite a number of people referring to it as like the best talk I've seen in years. I don't know if I would go that far personally. It's a great, it is a great talk.

[40:57] It's, it's kind of just, I think I would describe it as like an oral history of the Problem space that React Server Components is trying to address. It just sort of talks about like the difference between, you know, the server and the client and the network being in the middle and plots out a couple of different tools and where they live in that, You know, taxonomy.

[41:19] Definitely worth checking out. I mean, Ryan Florence has been around for so, so long. So hearing him just do kind of a dump of history of a problem, I thought was really interesting. It was definitely worth listening to.

[41:32] Mo Khazali: I'll jump in with some React Native stuff quickly.

Lorenzo Sciandra exiting React Native

[41:36] Mo Khazali: So first, and I'd say most significant news in this space is unfortunately that Lorenzo Sciandra from the Microsoft team is leaving the React Native world and also leaving Microsoft, which is, I would say personally, a pretty big blow to this, to this community.

[41:51] He's been such an instrumental part of. Getting more and more community involvement inside of React Native. He's been doing React Native for more than six years and, you know, being based in the UK. I've known him personally for a couple of years now and such a lovely guy. And I think he's moving on to focus something around making sure that the tech space is A little bit healthier and a little bit more humane, as he likes to put it.

debug:mind by Lorenzo 'kelset' Sciandra

[42:13] Mo Khazali: And he's been focusing on mental health struggles within the tech ecosystem and within, within a career of tech. So you should definitely check out his podcast called Debug Mind. But really just want to, from the bottom of my heart, say a big thank you to Lorenzo for everything that he's done over the last six plus years.

[42:27] An absolute shame that he's leaving us, but I am very excited for everything that he's going to be doing afterwards.

[42:33] Carl Vitullo: Yeah, I have repeatedly come across his name when I've looked for React Native resources. He's done so many great lists of like, I can't even remember the various types of lists he's done, but just like major projects in the React Native space and educational resources on React Native.

[42:51] Yeah, definitely a big blow to have him exit the ecosystem.

[42:55] Mo Khazali: And, you know, more than that, you know, I think Lorenzo has been sort of the person who's been trying to bring the meta team closer and closer to the community. So, you know, Lorenzo, for the first time that I went to Meta's offices, Lorenzo invited me and, Organize that with a lot of the Meta folks to, to bring me over and, you know, for me to be able to chat and bring some of my concerns over to some of the folks at Meta and, you know, that became more of a recurring thing, all thanks to Lorenzo.

[43:17] So he's been very instrumental and he's one of those sort of open source maintainer that maintainers that really cares about the community. So yeah, definitely a big blow.

[43:24] Carl Vitullo: Yeah, and earlier, Mark was talking about how the React Native team has been a little bit better than the React core team at interfacing, doing like working groups and things like that, and including the community and the development.

[43:36] I wonder, I wonder what role he played in making that happen.

[43:40] Mo Khazali: A major one, definitely. So, yeah, but. Best of luck to him. I'm sure he's got some amazing stuff lined up that he's going to be exploring next. And yeah.

Expo Atlas

[43:47] Mo Khazali: Next up, one thing that I'm personally super excited about is Expo Atlas. So Expo Atlas is almost like a sort of bundle size visualizer, but taken to a little bit of a higher level.

[43:57] And this is something that's been missing from the React Native ecosystem for a long time. So just a little bit of context. Bundle size has never been a concern for the React Native ecosystem, unfortunately. For, for, for better or for worse, because it's all sort of sent once in the bundle of an application, when you download it from the app store, people don't seem to really care that much about how much JavaScript you ship, so long as it's downloaded once it's done.

[44:19] And, you know, things like app startup time and actually, you know, having a lot of JavaScript and runtime don't affect React Native apps as much because of. Things like Hermes existing, where you have an engine that will have some sort of like bytecode representation and not have to load the entire JavaScript bundle into, into its runtime.

[44:35] So that's been a challenge when you're trying to take React Native and put it on the web and deal with this whole universal story. And so, you know, one of the things that I spent a lot of time around React Summit, speaking to Evan and Cedric from the Expo team about was, you know, how do we make sure that some of the third party libraries that have.

[44:52] I've been creating over a long period of time in the React Native ecosystem, actually have small bundle sizes when you try to take them to the web. And Expo Atlas is kind of the take that the Expo team has at doing that, which is, well, a lot of these libraries are all CJS based, so if we just introduce tree shaking into the bundler for React Native, It's not going to necessarily solve that problem by itself because most of the libraries won't be tree shakable.

[45:13] So then what's the way to do it? Well, let's just visualize the problem, see what libraries are bundling in a lot of crap, and then see if we can slowly start to, as a community, shave some of that off and improve the performance for React Native web apps. This is a slow burn. It's not going to. Change over the next year, two years, maybe even three years, because there's a lot of legacy there.

[45:31] But I think it's the right step. It's showing and visualizing the problem. So great tool that's out there. We'd definitely check it out. It shows you in a different way to how like the bundle visualizers that you might be used to, it actually shows you which import of a library you have in your code that is actually causing this library that might be bloating your bundle to be loaded.

[45:50] So, you know, it might, it goes down the tree for transitive dependencies as well, which is quite cool.

[45:54] Mark Erikson: Oh, that's wonderful.

[45:56] Mo Khazali: Really great tool.

[45:57] Carl Vitullo: Yeah. I'm looking at this, the visualization of the blog post with the, you know, recursive squares showing the, the bundle size and, oh man, I remember almost a visually, almost identical tool, much less polished.

[46:10] Clearly this has someone who did a design pass, but there was a very similar tool that came out for Webpack in like, I don't know, 2014.

[46:19] Mark Erikson: There's been a number of them, Webpack Bundle Analyzer, Source Map Explorer, and a couple others.

[46:25] Carl Vitullo: I, I like practically made a career out of like fixing performance issues just because I learned that tool and it actually enabled me to do things.

[46:33] So yeah, cool. Love to see it. Love to see it in the React Native context. Definitely looks valuable.

[46:38] Mo Khazali: Cool. So then a few sort of quick things.

Expo adds Compiler support

[46:40] Mo Khazali: Firstly, Expo's now added React compiler support. We saw this in the React Conf app. It was already using the React compiler. So just, you know, if you want to try it out experimentally, you can use the React compiler and see how it works for your app.

Starlink's React Native app

[46:52] Mo Khazali: Next up is Starlink's React Native story. So this was interesting because it came out during AppJS, which happened last month. So the Starlink app is, is obviously built with React Native and it uses a lot of the expo libraries and things like React 3 Fiber. And it's really cool to see how some of these tools that we all have available to us are used in practice in some pretty serious production apps.

Expo Router 3.5

[47:14] Mo Khazali: And then another quick fire one, minor changes to Expo Router in Expo Router version 3. 5. So, just some stuff like, you know, supporting the, the sort of the hash parameters. There's some stuff around native, native intents with deep linking that you'll need for having a more seamless handoff between different Devices, and also for allowing for certain links to, to come with more details to, to really augment the native functionality.

[47:38] Another small thing that I think is quite important, that's not actually one of the top headlines with this, is that previously Expo router was using an, a non standard version of the request and response. And with this version, they've, they've standardized it a bit more, which is great because that should definitely be standardized.

[47:55] And then a few. Other minor things that I'm just going to run through. One is React Native Vision OS won the Git Nation Open Source Award, which was quite cool. It's a really cool project. Definitely give it a shot. And the folks from Callstack were there at a bunch of these different conferences with Apple Vision pros, trying to get people to try out React Native with Vision OS, which was quite a fun thing to try out.

SF Symbols beta support in Expo

[48:16] Mo Khazali: Next up there is sf symbols. So sf symbols is sort of an icon pack that comes default with iOS. It oftentimes feels very Apple esque and having that inside of your app means that the icons are uniform with the OS and they look and feel like it's an iOS application and Expo's added beta support for it.

[48:36] This is an interesting one because React Native is obviously cross platform. The main targets that you'll have is an iOS and an Android app, so specifically supporting icon sets and an icon set that's available for iOS means that you may need to have some divergence in your code base if you want to really use those SF symbols, and you'll need to create or choose equivalent Android icons, so a little bit of an odd take, but I'll see you A lot of people seem to really want to use SF Symbols, even with React Native apps.

[49:03] So I'm sure that there was a level of feature requests and community involvement in trying to get that working. So that's definitely there. And then lastly, React Native Screens. This is actually a library that you will rarely ever have to use directly inside of your application code, but it's actually being used under the hood by React Navigation, which is by far the most common navigation library within React Native.

[49:25] And they've just added some extra minor improvements. One that's quite cool is transparent header support. Obviously on the native layer, there's functionalities on iOS and Android to be able to add a transparent heading that's got a little bit of a blur, and it comes up with some cool effects. You can do that in React Native with the, with the default navigation libraries.

[49:43] So React Native Screens has been updated to support that on both iOS and Android now, which is just cool minor changes. And that's just about everything that's been happening in the React Native ecosystem in the last month.

[49:53] Carl Vitullo: Nice. Excellent. Thank you for catching us up.

[49:56] Okay, shall we move on to our lightning round, see how many links we can get through there?

[50:00] Mark Erikson: Yes, because we're already an hour in, so moving right along.

React Internals Explorer

[50:03] Mark Erikson: I saw a really, really cool tool called React Internals Explorer. It looks like you write some React code in a sandbox editor. And then it actually digs into the React fiber tree and shows you the structures of that.

[50:17] I haven't even had time to play with this, but just like glancing at it and seeing a screenshot. I'm actually really, really excited about this because I love digging inside React's internals. I know most other people don't need to, but this looks really helpful. And the author has already written a whole series of blog posts where they actually go straight into the React source code and explain how specific features of React are implemented under the hood.

[50:41] So if you want to know how React works inside, very worth reading.

What's new in JavaScript Frameworks for May 2024

[50:44] Carl Vitullo: Yeah. I wanted to call out a blog post from the Chrome team where they just, they do a recap. What's new in JavaScript frameworks for May, 2024. So this is, I guess this is old. It's undated. So I guess it must have come out last month, but they are just, they just quickly round up a bunch of.

[51:02] they go through like Angular, Astro, React, Remix, Next, Vue, NUC, Solidsfelt, and a couple of others. Yeah. This is Adi Osmani is. One of the, you know, it looked like they did a video and wrote a blog post with it. I thought it was curious, or I thought it was interesting to see what the Chrome team thinks about JavaScript frameworks.

Memory leaks

[51:24] Mark Erikson: There were a few different blog posts that touched on the theme of memory leaks. There was one that talked about memory leaks inside of Node, potentially if you're using the relatively new local async storage feature. the example there was with setTimeout.

[51:42] Apparently, Node can be keeping track of async call stacks attached to the context storage, and so you could actually end up leaking a whole bunch of memory if you're using it in certain ways.

Sneaky Memory Leaks

[51:53] Mark Erikson: Uh, similarly, there are also a couple of very good blog posts talking about potential ways you might end up with memory leaks in a React application.

[52:00] In cases where you're using like use callback or use memo or with React query where you're writing functions that are doing data fetching or something like that, and they're closing over variables that are in scope and they might not even be getting used. But the closure keeps those variables alive longer than you would have expected.

Data Fetching Patterns in Single Page Applications

[52:21] Mo Khazali: Cool. So next up is an article that's actually on Martin Fowler's blog. So Martin Fowler being the big thought leader and evangelist of, of all things, application development, period.

[52:33] Mark Erikson: Enterprise architecture patterns.

[52:35] Mo Khazali: You see, divisive at the best of times, Martin Fowler is, but there's, there's been more and more React articles popping on, and they're not actually written by Martin Fowler, but they're written by someone who works at, whose name is Juntao, or actually, I don't think he works at ThoughtWorks, but he's very close with Martin Fowler, so he writes on Martin Fowler's blogs.

[52:53] And he's been doing some really cool work on writing articles that start from the basic principles and expand out and create more and more complex applications that explain a bunch of concepts. So his latest article is about data fetching patterns in single page applications, and it starts with basic React concepts, builds up around, you know, asynchronous states being handled on the client side, parallel data fetching, how do you handle fallbacks, and then things like pre fetching, and then kind of It takes you through this journey and tells you when you should use which one.

[53:21] Would recommend it. It's a very, very long read, probably one of the largest blog articles I've seen in a very long while, but it's definitely worthwhile if you want to get a more holistic viewpoint. And he's written a lot of articles like this. Another great one that he's written just to give a shout out is called modularizing React applications with established UI patterns.

[53:38] And this is one that Mark is not going to be very happy about, but this one is one of those, which is like, how do you enterprise ify React code, but it's actually a very interesting article that has some thoughts about how you should architect React apps. And some of those patterns, not all of them, are actually very good to make it easier for you to do things like testing and so on and so forth.

[53:55] Carl Vitullo: Cheers. Yeah. Oh man, I remember reading Martin Fowler's blog like 15 years ago when I was like starting my career. So just for it to still be relevant is like a little bit mind boggling to me.

[54:07] Mo Khazali: The website still looks like it's from 15 years ago as well.

[54:10] Carl Vitullo: Yeah. It's unchanged from when I started reading it.

[54:13] Yeah. Not a single change that I can identify.

[54:16] Cool. Yeah. I wanted to bring up a blog from Snyk, a security. Firm, I don't know, security product service, 10 modern Node. js runtime features to start using in 2024. It's, I have always found it really tricky to stay on top of every level of development over time.

[54:35] So I appreciate a little roundup post like this that just sort of calls out a number of new features that I may not have caught the release of. It's sometimes it's hard to see, see the each individual release. So the 10 that they call out are a test runner. Native mocking, native test coverage, watch mode, core pack, the env loader, some import meta fields for the **dirname and **file fields, native timers and promises, permissions module and a policy module.

[55:08] Those last two are not super clear to me, but like the test runner and native mocking and test coverage. Super great to not have to pull in a third party tool for that. As well as, yeah, I mean, watch mode. The number of times I've installed NodeMon. If I can stop relying on a third party package for that, I'll be pretty happy.

[55:26] I haven't checked that out yet, though. CorePack is actually, I feel like the name of it makes you compare it to Webpack, or it makes me compare it to Webpack, at least. But actually, it's, the main use for it is being able to specify a package manager at a specific version, which is so useful. Um, I appreciate that they have made it, I guess it's a, I guess it's a combination of being able to pin a specific version of your package manager, but it's also, I think, some underlying tools to make cross compatibility possible between package managers.

[55:59] Mark Erikson: The primary issue is that NPM has always come pre installed with Node. But if you want to use Yarn or PNPM, or, Bun, I guess, you have to first use NPM to install those tools globally. And that's kind of a one off per system thing. And then you have to remind everybody that they're supposed to be using this package manager, the project.

[56:22] And so I think the idea of CorePack is that if you specify in your package JSON, that, Hey, we're actually using Yarn 4. 1 or PMPM 9. 2. It will automatically do the work to make sure that the right package manager is available and being used in that project.

[56:40] Carl Vitullo: Right. It fills the gap where, like, PackageLock or Yarn.

[56:44] Lock will let you pin your dependencies, left the, you know, the gap of what about the version, you know, for the package manager because the different versions interpret that lock file slightly differently sometimes. Or, you know, I've had a more recent version of Yarn blow away my Yarn or, you know, start adding things like a, a digest half to the, to the lock file.

[57:06] So being able to pin a version, super great. Yeah. As well as like having a env loader, so we don't need to use env anymore. But yeah, so I appreciated this as a quick summary of a number of new built ins for Node.

[57:18]

Migrating to the Next App Router With Zero Downtime

[57:19] Mark Erikson: There was a very good post on migrating to the next app router with zero downtime. One of the pain points with server components is that you have to have the entire application set up with server components as the outer layer of the application in order to use them at all.

[57:36] There's no straightforward, simple, like migrate, just a little piece of my component tree. And while you can use the app router with everything still on the client, as a client component, it's still a key step in order to even be able to think about using server components with Next. And so, this article was a good example of how a team with an existing Next app that used the Pages router was able to mimic the routing setup in the app router and carefully, step by step, make sure that things worked the same both ways.

[58:05] Switch over and then be able to start using some server components piece within the existing structure.

Deno Standard Library nearing 1.0

[58:12] Carl Vitullo: All right, Deno announces that the standard library is nearing 1. 0. That sounds great to me. The standard library is now a collection of 38 packages, they say. I appreciated this. Rather than doing it all in one big bang 1.

[58:26] 0 release for the standard library, they're actually going to repeat a process for bringing each of those 38 packages up to stable relief. So they're gonna do it through like a release candidate and then gather feedback with like a a one month timeline for each of those packages to gather feedback.

[58:45] So yeah, that's A lot of effort, a lot of energy being invested into creating a standard library and oh man, here's a standard library for a JS runtime.

[58:55] Mark Erikson: I'm confused. Are we allowed to have that?

[58:57] Carl Vitullo: Right? It's, it, the classic criticism of JavaScript is the lack of a standard runtime.

[59:02] So, oh my goodness, we have a standard runtime hitting stable. I feel like that's going to affect the ecosystem in some way, but we'll have to see what happens there. Cool.

Why don't we do Acid tests anymore?

[59:11] Carl Vitullo: I'm going to call this one out. This was, I put, I put up one of my tweets. I don't know. I think it's a good question. I'm going to do it.

[59:16] I proposed the question out, why did we stop making checks like the ACID3 test? Why isn't there an ACID3 test for, for example, progressive web apps? I remember the ACID test series of, projects was

[59:30] Mark Erikson: Browser rendering behaviors.

[59:32] Carl Vitullo: Browser rendering behaviors. It was, is the browser you're viewing the web page in standards compliant? Here is something. It should look like this. And I remember checking that in, you know, 2008 or whatever, when I was a wee baby nerd. And, my browser didn't render it correctly, and then a couple years later it did.

[59:50] I was considering, like, what factors may have moved us away from things like that, and I feel like it used to be so hard to ship new things, new standards. That it took big coordinated pushes like that, or maybe the ecosystem was also just smaller and the number of players involved were, you know, it could fit in a room, but I feel like we've lost something a little bit in there.

[01:00:12] Like the acid three test was CSS three was ratified as a standard. They put out an associated test for this rendering behavior so that. Users could check if their browser was working in compliance with the standards. And I guess I, I put up the comparison to progressive web apps because like, They are not fully rolled out, like Chrome put out, the Chrome team put out a lot of support for progressive web apps, very much as a attempt, I think, to make web pages viable as competitors to native apps, and it just kind of never really happened, I think in large part because we never got cross compatibility With all the browsers for those capabilities.

[01:00:54] And I don't even know that we, as an ecosystem, as web developers, have a shared understanding of what makes a progressive web app, you know, what defines a progressive web app? How do you distinguish that what you've made meets all the criteria? So, I don't know. I just, it was lamenting our lack of those sort of litmus tests for, I guess, bringing a Technical definition to some of the terms that we throw around frequently.

[01:01:21] Mark Erikson: It's, it's not quite what you're asking for here, but I can point to a couple ways that there's been more efforts to do interoperability efforts. One is I think the latest version of the speedometer benchmark for JS engines was specifically built to include a bunch of different things.

[01:01:38] Reasonable, plausible example applications using various JavaScript frameworks. Like I know that there's like a React, Redux, Todo application as part of the benchmark sequence. So that's been an attempt to semi standardize things and make things a little more plausible. Also, I believe the last three or four years, all the major browser Vendors have done, I don't remember the exact term but like an interoperability effort where they identify like the top five or six pain points of places we know where browser behavior is differing and we're all going to make a push this year to make sure we all work the same way for these things.

[01:02:15] So it's, it's not quite the same as having like the ACID3 test or, you know, a named version of CSS that we're all trying to implement, but it is, it is kind of along those lines.

[01:02:27] Carl Vitullo: Right. Yeah. I don't know. I guess I, I, I think the branding that used to be baked in to those sort of releases served, I think to me, it served a valuable function in developer education. And I think that we've lost something through not having it.

Web Platform Tests dashboard

[01:02:41] Carl Vitullo: Like there was a web platform tests dashboard that like, yes, here is a single place that compares all of the features, accessibility, all of the compatibility across browsers, but it's not actually, you know, as a developer, it doesn't tell me what features are grouped together? What features go well together? What capabilities are unlocked by supporting this thing? We're going well beyond the scope of a lightning round link right now.

HTMX: Simplicity in an Age of Complicated Solutions

[01:03:09] Mark Erikson: all right, and last one we got on the list. HTMX is a library for basically adding attributes to HTML tags that do things like data fetching and automatically inserting the results into the page without having to explicitly write JavaScript yourself, and they put up a blog post entitled Simplicity in an Age of Complicated Solutions, where they have some examples of handling inputs and data fetching with VanillaJS or with React code.

[01:03:37] And they point out and say, look at how complicated this is. Whereas if we just slap HTML into the page and we add a couple attributes, look at how simple this is. And there's, there's some valid trains of thought to this. Certainly you're writing less code as an application developer. I questioned a little bit some of their arguments on general principle, but it is worth reading for an alternate viewpoint on how application behavior should be implemented.

[01:04:00] Carl Vitullo: Yeah, definitely interesting from a perspective of just considering expansion of complexity too. I thought that was, I thought it was cool to read from that lens too.

[01:04:08] Cool. All right. That is all of the, all the links we have. Thanks everyone for joining us. We'll be back on the last Wednesday of the month in here in the live stage of Reactiflux or in your podcast feed as soon as we can after that.

[01:04:20] Mark Erikson: Thank you for listening. Plug, please check out Replay. io for debugging your tests and trying to fix flakes. And also, I'm almost done with a very large revamp of the primary Redux tutorial to make it TypeScript first and explain more things. Carl just pasted a link to the draft PR in there. I would appreciate feedback.

Revamp "Redux Essentials" tutorial

[01:04:43] Mark Erikson: I'm hoping to have this done within the next couple weeks. Like, I'm almost done with the first draft, and then hopefully there's not too much more work to do. So, feedback, please?

[01:04:52] Carl Vitullo: For sure. Awesome. Yeah. Mo, anything you want to add?

[01:04:55] Mo Khazali: Nothing. Just thank you again for having me and always a lovely time chatting with you all and going over everything that's been happening.

[01:05:02] And yeah, looking forward to the next one.

[01:05:03] Carl Vitullo: Most definitely. Yeah. Always good talking to you guys. Cool.

[01:05:07] we, we gather links from, um, a bunch of different sources, including thisweekinreact, bytes. dev, reactstatus, nextjsweekly, the reactjs subreddit. Right here in Reactiflux from the Tech Reads and News channel, um, and directly from people publishing articles, usually on like Twitter or Blue Sky.

[01:05:26] If you see anything that you think that we should be paying attention to, definitely feel free to email us at hello at reactiflux. com with T M I R in the subject line. That's acronym for the show. I read every email that comes in, even the ones marked as spam. If this is the show you get value from and want to support, the best way to do so is to send it to someone.

[01:05:45] Send it to your co workers, help them learn how you know so much about React. Otherwise, you know, submit a review, do stuff like that. But yeah, thank you so much for joining us. Appreciate it. See you next month.

Reactiflux - Transcripts

TMiR 2026-06: React Compiler is getting rusty, what does AI mean for engineering culture

This Month in React: June News Roundup

Intros

New releases

ESM only, no programmatic API right now

Nub JS, from Zod creator

React Core news

Other core improvements

Fragment Refs have been documented in canary

React DevTools MCP tools, including component tree and perf analysis APIs

React Foundation progress

There’s a(n early) react.foundation website, advertising funding for maintainers and community groups

They’re gonna have a booth at Chain React at the end of July

Christoph Nakazawa posted his “Modern Engineering Values” and how he uses AI

NPM / security updates

Code optimization still matters!

TanStack Table cut memory in v9 by 90% on large lists by optimizing JS objects and optimized TS perf

Pierre Diffs was significantly optimized - has to handle virtualization, syntax highlighting, source loading

CompileCat is a new optimizing compiler to improve JS execution after bundling, similar to Closure Compiler. (the RSPack team says they’re working on something similar )

Mark’s React-Redux \+ signals draft perf PR and updated React-Redux benchmarks repo

TMiR 2026-05: Who even is on the Core team anymore, TanStack got pwn'd bad

Interview

Some podcast meta

New Releases

Main Content

React Core

React team status after Meta layoffs?

React Compiler port to Rust still in progress, latest PR

Tanner Linsley is "projecting" React (it's definitely not a fork)

Both Remix and TanStack are exploring "what if no React"?

TSRX, a variant on JSX

Security! Everything is compromised

TanStack Router compromised, and Socket analysis

Nx monorepo tool compromised as a result

React2Shell recaps from Lachlan Davidson and Sylvie

NPM adds “staged packages” and E18E adds guidance

PNPM 11 defaults to min release age, NPM 12 will block by default

Mark posted his big AI blog posts. Part 1: Fears and Journey

Outro

Mark & Carl talk with Swizec Teller about using AI at work

This Month in React April

Introductions

What convinced you AI code tools were worth using?

Using early ChatGPT for DB migrations

Watching AI use a command-line

Background chat agents

Staying very hands-on while using AI tools

Driving AI closely without reading its code

Mark's workflow; OpenCode with CodeNomad UI, plus IDE+git UI. Opus 4.6 on API

Swizec's workflow, latest Cursor on Opus

Carl's workflow, mostly Claude Code but looking at custom orchestrators

Exploring fully autonomous agents

Mark's AI debugging work in React core

Value of providing more context

AI-owned documentation

Using good engineering practices still matters?

How do you know the right code to make?

Good communication still matters

What will "review" look like in the future?

Automating functionality tests with deployment practices

What behaviors belong to the agent, and what fundamentally can't be part of the agent?

Impacts of LLMs on software engineering?

A superpower right now is a domain expert who can kind of code

TMiR 2026-02: CloudFlare remakes Next with AI; Vercel big mad. We talk too much about AI Agents

New releases

TS 6.0 beta! (last TS impl release; stricter defaults)

Yarn 6 preview (rewritten in Rust)

Electrobun (Tauri alternative)

Gatsby React 19 support, styled-components RSC support

npmx.dev (alternate NPM site UI)

eslint-plugin-react-render-types (typed children)

Main Content

React Core updates:

Docs updates: useActionState (merged), use and RSC sandboxes (wip)

Hermes WASM support, Hermes Node compat CLI

“State of…” survey results

CloudFlare v Vercel beef

Carl Vitullo monologs about AI Agents

AI productivity and impacts on our attention

Docs updates: `useActionState` (merged), `use` and RSC sandboxes (wip)