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

Transcript from Thursday June 25th, 2026

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]