TMiR 2026-07: React-alikes, GOVERNANCE, and state management

Transcript from Wednesday July 29th, 2026

Carl: Hello. Thank you for joining us for the July edition of This Month in React, as we recap what's been going on with React Native and other things across the web. We are coming to you live from Reactiflux, the place for professional developers using React. And I'm Carl. [00:00:00]

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

Mark: Hi, I'm Mark. My day job is replay.io, where we've built time travel debugging, are working on autonomous QA, and I get to do all kinds of awesome time travel-powered React analysis tools. And outside of that, I am still doing Redux stuff, and I'm actually finding the energy to do a fair amount of that right now, which is cool. [00:00:22]

Carl: Nice. Heck yeah. Hell yeah for finding the energy to invest in a project you love. [00:00:41]

Mark: Yep. I'm also actually back at home after, like, two and a half months of almost nonstop conference travel. [00:00:47]

Carl: We were saying in prep, we have kind of a grab bag this month. There's not, like, one big thing to discuss, but yeah, we're gonna get into a couple things. [00:00:53]

Uh, obviously there's been more security stuff and new releases of major projects, like TypeScript 7, which we've discussed, like, four times already, but y- it's here. Yay. [00:01:00]

We also are gonna get into some open source governance questions. There's been some developments on the React Foundation. And l- kind of out of left field at the same time, Poimandres a cooperative doing open source around Three.js. It also published some governance work. So yeah, we're gonna get into it. [00:01:09]

New releases

Carl: But first, the first new release. [00:01:27]

Vite+ Beta

Carl: Vite+ from Voidzero is in beta now. [00:01:29]

Mark: It's not paid anymore. Oh, okay. They dropped that. I think they dropped the paid part even before they got bought out. [00:01:33]

They initially said it was paid. Then they said, "No, no, we'll, we'll make Vite+ free. We're gonna build our own server runtime layer on top of Cloudflare," and then Cloudflare just bought the entire company. [00:01:40]

So- Great ... Plus itself, as far as I know, is going to be entirely free at this point multiply. But it's just the Void Zero company had been paying a bunch of people to build out OXC, you know, that whole layer of parser tooling, partly to use in the Rolldown Rust-based bundler. [00:01:51]

The latest version of Vite uses Rolldown, but then there's all these other Rust-based tools related to that. And so Vite Plus is a combination of we have pre-configured all these different tools into one super package, as well as added some additional layers of functionality on top of that. So it's essentially supposed to be an entire JS development suite in a box, sort of akin to what Rome was promising a few years ago. [00:02:13]

Carl: Cool. Love that. [00:02:40]

TypeScript 7.0 released

Mark: Meanwhile, as mentioned, we have talked about this repeatedly, so I don't have to go into a lot of details, but TypeScript 7 is finally live. Hooray. This is the Go implemented native implementation of the TypeScript compiler that is supposed to be up to 10X faster, so the actual... [00:02:41]

If you install the actual TypeScript package at latest now, it is actually built with Go under the hood. The biggest caveats here at the moment, as we've again talked about, the programmatic TypeScript API essentially does not exist in version seven, because the API had been partly official, partly unofficial before that And lots of different tools had various dependencies and needs. [00:03:00]

A lot of them had hacked together solutions in the past, and so the TypeScript team said, "Okay, we know the compiler itself's working. We're gonna get that out the door. We want to take our time and carefully consider what a better and proper public API would look like to support all the different use cases people have come up with, and we'll get that out the door in, like, a version 7.1 or 7.2." so there is some, there is an update on that front. [00:03:28]

open PR for “content mappers” to integrate other language syntax

Mark: They've put up a PR for something they're calling content mappers, and the way I'm understanding this is that for other languages like, say, View or Angular that have templates, you want to be able to type check the templates. The TypeScript compiler handles JSX, which means React kind of got special treatment there. [00:03:56]

But how can other languages actually get similar behavior for non-TypeScript syntax? And so this content mappers proposal from the TS team is a way that they're hoping they can address essentially a plug-and-play conversion of other syntax into something TypeScript itself can type check. So there, there may be other API integration things that they're looking at as well, but this feels like it's a, a good step in that direction. [00:04:17]

And in the meantime, a bunch of teams are doing things with integrating with TS Go in hacky ways you're not supposed to anyway. [00:04:49]

Johnson Chu made a compatibility layer to drop-in for unsupported tools

Mark: Johnson Chu, who I think built the Alien Signals library, and I think also works on the Vue Volar language extension, if I've got my connections right, put together a package called the TypeScript Native Bridge, which is supposed to help polyfill some of the, I think, the language server-type integrations so that they're faster. [00:04:57]

OXC type-aware linting stable

Mark: And then the OXC folks have been doing their own hacky native TypeScript integration to try to enable typed lint rules within the OXC linter. And so the typed linting support has just gone stable as well. So, lot of improvements around TypeScript compiling and checking in the entire tooling ecosystem. [00:05:18]

Carl: Interesting. Yeah, type-aware linting would be a really big win. I've wanted that a number of times, and we've never really gotten there. [00:05:42]

Mark: TS ESLint has them, but it requires a lot of slower integration and running full-blown standard TS type checking. [00:05:49]

Carl: Cool. Can you talk about this install time security, Mark? [00:05:56]

NPM v12 and new security defaults

Mark: Due to the entire series of supply chain attacks that we've seen happen over the last year, one of the biggest issues has been that packages are allowed to run scripts after install by default. And so you're just arbitrarily executing remote code on your machine with your privileges. And so several other package managers like pnpm had switched to disallowing that by default. [00:06:00]

And so npm 11 still allowed that, but they started adding the options to disable running scripts by default and preparing things. So npm 12 actually does flip the switch on a lot of those options. So npm 12 no longer runs post-install scripts by default. By default, it does not allow a Git repo URL as a valid dependency, and it has a couple other options that it turns off by default to enable security. [00:06:27]

Dependabot supports a configurable delay

Mark: I also saw that GitHub is changing Dependabot, so it now has a cool down by default, so it won't install new deps until, like, two or three days after they came out. [00:07:00]

So we are very, very belatedly, as an ecosystem, finally learning some lessons we probably should have learned many years ago, and changing some of the default behaviors of our tools to try to cut down on the blast radius of some of these malware releases. [00:07:10]

Carl: Yeah. And we've covered some of that in recent episodes, so I, let's not rehash it entirely again. Mm. Yeah, definitely some, uh, long overdue changes here. [00:07:27]

Mark: Yep. [00:07:37]

More React RSC security tweaks for 19.x

Carl: As well as, I guess, in w- security tweaks for server components that were just released this week. [00:07:37]

Mark: Yep. Looks like another denial of service attack possibility. [00:07:44]

Carl: Okay. [00:07:48]

Mark: So just bad, bad... So not remote code execution, but bad input freezes the server. [00:07:48]

Carl: Okay. Can't have that. That's a denial of service vector. Okay, well that's the, like, brand-new releases we have. There's some other new stuff, but a little bit, like, less, you know... N- we're not gonna start with it, but we're gonna do that towards the end. [00:07:54]

Main Content

Carl: Main content. [00:08:06]

React org updates

Carl: We are gonna start with the React org updates, and we're gonna frame this against the backdrop of, like, open source governance generally. There have been some changes announced by the, uh, you know, React Foundation within the Discord. [00:08:07]

“Leadership Council” and Working Group structure on the new team page

Carl: There's been, you know, there's been a, a couple of visible changes to the website and PRs to the actual governance repository. [00:08:22]

Mark: I specifically had been griping, I think in the last two months, that I have no idea who's even on the React team anymore. And I don't know whether they literally heard me or whether this was just, you know, kind of coincidental timing. [00:08:32]

But they did a significant update to the existing React team page on the website. They updated it both with, you know, current people involved in moving some folks to more of, like, an emeritus status. But the team page now actually reflects a new team structure that is coming out of this React foundation itself, where there's, like, a set of different working groups for topics like, you know, server components and compiler and, and other things. [00:08:46]

But then there's, like, a leadership council that appears to be essentially, like, a, a representative from each of those groups, as well as possibly a couple others. So I still don't, still don't have a lot of details on the actual responsibilities, but we're seeing some visible evidence that they're working on the organization process here. [00:09:17]

Carl: Interesting. Cool Curious, the reason I'm in the Discord is 'cause, 'cause somebody reached out asking if I wanted to help with community, and so now seeing a bunch of people listed as on the Docs and Community Working Group and nobody reached out to me makes me feel like I got left out. [00:09:39]

But that's okay. I'm an independent actor, unaffiliated. [00:09:51]

Mark: The list of working groups is, uh, server, DOM, fiber, docs and community, compiler, DevX, and React Native. [00:09:55]

Carl: Yep. I am s- slightly surprised to see React Native generally put into its own single group, because they're a- at least as large as React. [00:10:04]

I would say technically, you know, problem space they operate within is larger than React itself. So I'm slightly surprised to see it positioned as a single working group under the umbrella of React. But I guess, you know, there's other organizations that are more meaningfully invested in React Native, so, uh, maybe this is more of, you know, division of labor. This is the pipeline more than the umbrella, per se. [00:10:12]

Mark: It's also worth noting that there, there's like seven or eight people on the leadership council, which I guess, you know, matches roughly the number of working groups. And then the working group members section is at least a good 20-plus people long for current people, and then there's a set of advisors and a set of emeritus people. [00:10:33]

So there, there's a good 30 to 35 names listed on this page. Like, it's not just, you know, two to three people. [00:10:54]

Carl: It's quite a long list, and it is much more specific. I don't know. We just complained about this, and it's really nice to see a, like, full refresh that looks reliable. That's nice. [00:11:01]

Stub governance docs for the Leadership Council

Carl: I was reading a little bit of the charter. It is pretty interesting. It looks like they're quite earnestly trying to make this, like, you know, open participation, and I've thought a lot about governance questions and stuff like cooperatives and, like, how do you do... If you have multiple people with opinions about what to do with a project, a shared good, I don't know, it's really hard, it's really hard to do that right in a way that allows people to feel represented and like they have agency in the overall system. [00:11:11]

So I appreciate the challenge of what they are trying to do. It is difficult to set up a general organization that lets many people in many walks of life feel heard. I like the, the way they scoped it as, you know, "the mission and scope of the project is to develop and maintain React and associated open source software. The leadership council will be responsible for technical oversight of the open source project." [00:11:39]

You know, like, this is... I can tell that from reading this, that the way that they are discussing responsibilities and constraints and decision-making and work delegation, like they are very meaningfully trying to make this open participation And with a high bar of quality. [00:12:00]

Yeah. This is, you know, primary source kind of stuff. This is-- The commit on this charter.md document is two days old, so this is, like, brand new. No one has really been... This is a- as yet untested. The processes described here are not currently fully implemented. But yeah, what I see here looks quite good to me. I like it. [00:12:19]

Mark: And to be clear, like, the, the repo's public. I mean, I can look at this information right now. I don't-- The- there hasn't been, like, a formal team announcement of the leadership council and the charter per se, but clearly they're trying to put all the pieces together to be able to say, "This is the way we're gonna do things." [00:12:38]

Carl: Yes. Okay, I don't see-- I heard rumor of a, uh, pending blog post, but I, I don't see it yet, so... But yeah, I expect that there should be some broader announcement of what this is and what it means and what their intentions are coming soon. But what I see here looks quite good. I like it. It seems like a good effort. [00:12:56]

Mark: Like I said, I, I griped a little bit about the lack of visible progress in the last few months, but clearly what we're seeing here, and even what I'd heard about the amount of effort that was needed to just create the foundation in the first place. Like, there is a lot of effort going on behind the scenes, clearly, and there's a lot of good faith intention behind what they're trying to accomplish. Like, this is not just for show. [00:13:13]

Carl: Yes. Agreed. [00:13:36]

Mark: One of the longstanding complaints about- You know, the community with React and React with the community has been, they do most of their coding work in public, but there's also some that happens behind the scenes in private. And historically, they've had the problem that any time they push a draft PR, people jump on it. [00:13:37]

It's like, "Oh, React is working on this new feature," and they start writing blog posts and tutorials and everything. And so that has actually made the React team less likely to show their work in public, because a lot of times it is an experiment or a prototype, and there's no guarantee that this will even ship at all. [00:13:55]

So there's been discussion on both sides that it would be really helpful if they tried to follow a TC39 stages model, where it's very clear that we are working on concept X. It is a stage one prototype, a stage two, like, we think this is likely. Stage three, this is probably gonna ship. Stage four, it's ready. That kind of thing. [00:14:14]

Rick Hanlon update on the React team using a “stage” process internally

Mark: And so Rick posted a comment on Reddit saying that they've been trained to follow that model themselves internally and had some success with it. But essentially, they're trying to prove to themselves that they can actually work using that approach before they fully publicly commit to doing that and making the scale, the stages and progress public. [00:14:37]

Carl: Yeah, and we've talked a couple times in past episodes about the general challenges, like the tensions there of them earnestly wanting to work in public and having repeatedly tripped over the same problem every time they've tried to of, you work in public and then you get just a bunch of yahoos talking over you as you're... [00:15:01]

You know, the, the people who don't, people who haven't seen the work that went into the current state that is actually now public and end up just re-litigating all the same issues or, you know. So there, there are a lot of very real challenges there, and I earnestly appreciate the continued exploration of how to make that actually functional and work well for as many people as possible. [00:15:18]

Pete Hunt and Nick Schrock join Vercel to run Frameworks/Next and Agent DX

Mark: One other small but related item. You know, there are a bunch of React folks at Vercel at this point, and Guillermo just announced that Pete Hunt and Nick Schrock have both joined Vercel. [00:15:39]

Pete Hunt was one of the first advocates for React at Facebook at the time. He did one of the more famous talks that helped get React off the ground in public. He had spent the last few years, I think, working at a company called Dagster that just got acquired, and so this is presumably his chance to move on from that. But the announcement is that he'll be leading the frameworks group in Next.js itself. [00:15:52]

And then Nick Schrock was instrumental in the development of GraphQL as a spec at Meta, and he is gonna be working on Agent DX or something along those lines. [00:16:18]

So Ver- Vercel continues to scoop up more and more of the folks who were involved with React at Meta at some point in the past. [00:16:31]

Carl: Yeah, I'm curious to see about the interplay between Agent DX and the GraphQL, because increasingly so, what an agent needs to do with an arbitrary server is get the data it wants And that's what GraphQL's good at. [00:16:39]

Hey. Yeah, I'm skeptical of MCP. MCP is gonna die. Actually, no, it's not gonna die. It's gonna, it's gonna live forever the way that, like, SOAP does. Yeah. It's gonna be an early exploration of a, an A- API, and I think it's going to be widely hated in five years. Calling it now. There's my mark on the yardstick. [00:16:56]

Poimandres published a charter (original announcement)

Carl: Related to the org updates and open source governance more than that last update, though, Polymanders has published their charter as well. It's been around for, I would say, at least eight years, maybe 10 years at this point. Oriented around Three.js and 3D rendering on the web, I think is a fair characterization. [00:17:16]

Mark: A, a number of, number of folks there have prior experience in game development one way or the other. Sort of a set of artists collaborating to build related things together kind of a vibe. [00:17:36]

Carl: Yes. Yes. Right. We all have a shared interest, a shared passion in this. You know, I open their website and it's full of WebGL demos with, you know, parallax and physics and refraction and, you know, translucent interact... [00:17:50]

You know, so it's, that's generally what they're anchored around. It's a bunch of artists doing art on the web in different ways, playing with visual technology on the web. And I- when I say playing, I don't mean to diminish. I mean earnest play in the sense of exploration. [00:18:05]

Mark: It's also worth noting that was originally developed by one of the, one of the earlier folks in that org, and I b- and I think Z- possibly Zeustin and Jotai and Vultio are still owned by that org on GitHub. [00:18:21]

Carl: Yeah. Zeusstand, React Three Fiber, React Spring, Jotai, Volto, Drei. [00:18:37]

Mark: Some very solid well-known libraries in the React ecosystem. [00:18:42]

Carl: Yes. Yeah. Tons and tons of well-known projects. Yeah, so like, I hope that didn't sound diminishing because I do not mean to diminish. [00:18:45]

These are talented, respected. But yeah, so they, they... As a point of comparison, these other technical, highly technical, highly skilled folks have also published a charter, and I think the React one is a little bit more clearly articulated. I appreciate this charter. It is, you know, it discusses the core principles and what it means to be a member and how decision-making works and how they adopt projects. [00:18:52]

But, you know, it's like the membership is one paragraph and says, "What are the working roles? There's no strict definition of a working role." So it's more vague. There's less buttoned down there. Which makes sense. You know, this is an open source collective of artists who are very talented, and they're very talented in more along technical things. [00:19:16]

Like whereas people coming from Meta are much more experienced in the corporate aspect of precision of language and clarity of, you know, communication and definitions in documentation like operating agreements and charters. So i-it's, I'm positioning these in reference to each other, mostly because of the coincidence of timing of them having both come out at the same time, and because I think that's a really interesting and valuable comparison to draw. [00:19:32]

What does it look like when a corporation helps found a foundation versus what does it look like when artists as part of a collective do the same thing? These are contrasting ideologies creating something, and these are two examples. I think it is fascinating to look at both. [00:19:57]

Mark: So let's say they wanna work on a, uh, React Three Fiber version 10 to be able to make use of WebGPU and make it more AI agent friendly. [00:20:12]

An example initiative

Mark: They'd like to work on their own design system for common look and feel and behavior. And then they also want to work on better quality text rendering in WebGL, apparently. [00:20:20]

Carl: Okay. Cool. I appreciate that. Yeah, text rendering is really hard because it's actually insane when you start drilling into the details of how glyphs are rendered on your screen. [00:20:33]

F- 'cause like for instance, if you're on a low DPI monitor, they will do all sorts of crazy sub-pixel rendering in order to make it look, you know, 20% crisper. Which ironically actually Apple gets flack for now because all of their displays are high DPI, and so they don't do those anymore, and then it's really hard to get crisp icons on OSX. [00:20:43]

Mark: Yeah, anytime a text rendering article pops up on Hacker News, I end up reading it, 'cause there, there's some deep stuff there. [00:21:01]

Carl: Yes. If you see text rendering or Unicode in a blog post title, like I highly recommend checking it out, because you probably take it for granted, and it's probably like insanely complicated. [00:21:08]

Text rendering in WebGL is likely going to be a fascinating project that deserves its own full initiative from a, uh, collective of expert engineers with visual experience. [00:21:18]

React-alikes

Carl: Cool. Okay, let's move on a little bit. Recently, we've been covering more and more React-alike projects. I'm gonna coin it, I'm calling it, these are React-alikes. [00:21:30]

Octane from Dominic Gannaway

Carl: Yeah, we've got a new one, Octane, from Dominic Ganaway. [00:21:40]

Mark: Yeah. Okay, so there's, there's a whole causational chain here. So Dominic started off by creating a library called Inferno back in 2014 or 2015, and the idea was React similar, but much, much faster. Whereas Preact was, say, like React, but only for the web and as small as possible. [00:21:43]

So, like, there was like a Inferno-React compat library that tried to fill in some of the differences in behavior, but the whole point of Inferno was let's make something very small and very fast. Dominic joined the actual React team and was there for a few years. He left Meta. He, I believe, worked with Rich Harris in some of the Svelte 5 stuff for a while. [00:22:06]

And we actually covered Dominic just in the last couple months because he recently released a- another different framework called Ripple, which tried to pull together a few different ideas, and he also released a JSX improvement language called TSRX, and then iterated on its design a couple times. So he's back, and he has another new framework called Octane, and the sales pitch for this one is very intriguing. [00:22:30]

It's essentially what if we took React's syntax and pretty much almost all the semantics, but we have a compiler, and thanks to the compiler, we can eliminate the virtual DOM, we can get rid of the rules of hooks, and actually have, like, conditional hooks, and we don't need a dependency array. And so there's actually a, a very strong connecting line through all these things. [00:23:04]

It's like what if React, but better in certain ways. Svelte was all compiled. TSRX is a compiler syntax layer. So there's a lot of different previous threads of work that are getting pulled together in this project. Now, I took a look at the commit history for this project. It looks like he only started working on this, like, a month or a month or and a half ago, thereabouts. [00:23:29]

You can pretty s- quickly see the commit messages going from, you know, first test, try this, oops, broke, fix, whatever, to, like, very quickly building up the pieces And he's officially launched it in some sort of like, well, I don't know what the actual version number is, but like he feels it's ready enough for people to try. [00:23:58]

The implementation has obviously been AI built. Here's where it gets interesting. So he just joined OpenAI to work on their own web front end. I believe he'd been using Claude To do the implementation. But in some discussion on Twitter, he said, like, "I am actually seriously pushing Octane forward because OpenAI heavily relies on React in their web stack, and we need to essentially, like, find ways to make that faster and more optimized." [00:24:22]

So there's both the personal history of, "I am very familiar with React and its ecosystem, and I'm trying to push it to the next level, and now I have a day job that will fund me to do that, and also g- they get to benefit from them." One other interesting technical point out of this. So it's React syntax and almost React semantics, but it's totally different packages, which would normally mean that there's no ecosystem out of the box because there are no packages that import from Octane. [00:24:55]

There are packages that import from React. So if you look at the Octane repo, there is an entire subfolder where he has programmatically built adapter layers for commonly used React libraries to make them work with Octane, ranging from component libraries to, in our case, React Redux and Redux Toolkit. [00:25:28]

Essentially, look at the actual source code, create a port or thin adapter layer that imports from Octane instead, and I assume they work? So it's brand new and no one's using it yet, but this looks very genuinely fascinating on multiple levels. [00:25:51]

Carl: The thing I'm observing on the homepage in the announcement, you know, code snippet, it looks extremely familiar, except for there's no return in this function, which is strange. [00:26:10]

Mark: That'd be the TSRX. [00:26:22]

Carl: Right. [00:26:23]

Mark: In fact, n- notice if you look carefully, there is a, there's an @ symbol right before the opening curly brace. That's apparently the TSRX symbol that this just auto-returns. [00:26:24]

Carl: See, I don't like that. Th- th- those feel like personal preference decisions that don't actually really matter. It reminds me of, like, CoffeeScript. That was so mixed. It was so perfect. They had the single versus the double arrow function, which would change the behavior of binding this. You know, a hyphen greater than did normal function binding, and equals greater than bound this automatically to the function. And people loved that so much that we pulled it into this language, and that's where we got arrow functions from. And I don't think that this at symbol justifies it to the same degree. Like, I don't think implicit return... Like, JSX had an implicit return, too. You know, it was like you add braces or you don't. [00:26:34]

And so adding a new symbol to the language in order to change the behavior of something that we already have a, a variable on, I think is gonna be a distraction. I think that's a, I think that's an API failure, I would say. Like, the rest, plenty of these, you know, the rest of these all seem... It bothers me that it's so close to being familiar, while m- making a, a dramatic departure like that. Implicit return is a big difference. [00:27:18]

Mark: It's worth noting that it does support both existing JSX syntax and the new modified TSRX syntax, so it is pick and choose. [00:27:45]

Carl: Skeptical. It's interesting. Overall, I think this is a really good idea and a good direction to explore. I'm reacting strongly to that small note because I think this is good to explore, and that feels like a, that feels like a unintentional self-injury that will make it more difficult for this to succeed, I think is why I'm calling it out. [00:27:54]

But yeah, I think that's really cool. Like, you know, boom, they got a use effect in an if. Can't do that in React. So conveniences like that seem really cool, and I'm excited to see if this works, and I hope that it doesn't introduce foot guns that make it less successful. [00:28:11]

Ryan Carniato: "React’s staying power is because of complacency"

Mark: Yep. That ties into the next bit conveniently because we organized it that way. [00:28:27]

I think partly in, in response to the release of Octane and some other related discussions, Ryan Carniato had a couple tweets that relate to this. So, like, you know, one of Solid's selling points has been that it mostly looks like it re- like React. It uses JSX syntax. It is JavaScript inside. Okay, the state and the effects are different, and the getters are different. [00:28:31]

But, like, it looks like React much more than Angular would be. So Ryan had a couple tweets where he was commenting that, you know, at this point, he feels like the... React is commonly used largely because of complacency. It's the modern no one got fired for choosing IBM kind of a thing. [00:28:52]

Follow-up: “Do people think FE innovation is dead? Would explain why there’s resistance to move past old React.”

Mark: And then he also had a, a tweet commenting on, like, do people just not feel that there's going to be any more innovation in front end? So I mean, like, he's been talking about a number of these points for a while, so, like, there's not necessarily, like, new changing details there. That, we've talked about this before, you know, AI is sort of encoding React as the default, and we're also still stuck in writing, like, 2019 era React and not even using a lot of the newer APIs. [00:29:12]

Carl: Yeah. I do appreciate this chat shout-out. "Directly contradicts the meme of a new framework every week." Like- [00:29:47]

Mark: Yep ... [00:29:52]

Carl: all right. Yeah, can't have it both ways. We're literally, the JS ecosystem is criticized for all things at every moment. [00:29:53]

Mark: I mean, why not both? We can have a new framework and nobody uses it. [00:30:01]

Carl: Yeah. True. Entirely real. [00:30:05]

Mark: I mean, the number of times I've seen new "React state management library" posted on r/reactjs, man. [00:30:08]

Carl: Yeah, you know, actually, I'm gonna tie that back to what you just said of not moving past 2019 era React. People are still doing 2019 era open source announcements of, "Hey, I made a new library." [00:30:14]

And like, yeah, that worked 10 years ago. I don't think it works anymore. But yeah. [00:30:26]

Parallel articles on Solid 2.0 with async, and Remix 3

Mark: One last little point on that note. We've talked before about both Solid 2.0 being in beta and having some new, uh, async features with the asynchroness baked directly into the signals graph. And someone put up a good, you know, w- very well-written tutorial-like post illustrating both just the overall usage and talking about some of the nuances there. [00:30:31]

And then someone else explicitly ported the example app into Remix Version 3 as a intro to how you would do things with Remix 3 as well. [00:30:55]

Carl: Cool. Nice. Love that. Anytime somebody does a direct port of one app to a different framework, especially in demos like this, I love it. I listen to a lot of economics, and there's a big thing, uh, in that field about natural experiments. Like, you know, y- some decision is made, and boom, now you have a randomized population that you can determine the outcome of that decision on. [00:31:07]

This feels like this, uh, open source equivalent. Somebody made a demo app, somebody else ported it to an different framework, and now we have a very pure comparison of those two frameworks. [00:31:29]

I have always thought it would be incredibly valuable if we had a, like, representative, like, "No, this is the best possible to-do app in nine different frameworks." [00:31:40]

Mark: That was the whole to-do MVC website back in the day. [00:31:50]

Carl: But then, like, they all suck. I feel like none of them achieved... Individually, none of them were actually good enough to wear that mantle, and so it was like, wait, actually, these are not, this is not... [00:31:54]

Or, I don't know, maybe that's just a reality of the fact that you cannot actually have a single the best anything because there are nine different approaches to doing tables in React, and so you cannot make a single definitive React to-do list. But, oh, man, I... So anyway, that's why I love that somebody has ported one demo app from one framework to another. This is really good. [00:32:03]

Cross-framework benchmark measuring reactivity

Mark: All right. So there, there's a long-running JS frameworks benchmark that's been out there that measures things like loading performance or swapping items in a long list, et cetera. That has been, like, the holy grail that every new framework tries to add and measure itself against. [00:32:22]

NullVoxPopuli, who is part of the Ember community, has put together a sort of similar benchmark, but trying to solely measure the reactivity and re-rendering portion of it. [00:32:40]

I only glanced at it. I don't fully understand the nuances and the differences of how, like, what is being measured differently than the, the JS framework benchmark. But I've, I've watched this person long enough to know they have a pretty good idea what they're talking about, and so they're trying to measure more about, like, the, the state update sequence, I think, than necessarily just, like, DOM loading time or something to that effect. [00:32:53]

Carl: Yeah. So I mean, this table has- Incrementing render effect. So I guess that means the length of time it took to render and then produce an effect that would increment and then thereby trigger a re-render, an infinite loop, it sounds like. And it's saying React took 8.7 times longer than the baseline to just do that. [00:33:19]

Which is, [00:33:38]

Mark: which is Angular apparently. [00:33:39]

Carl: Yes. Or the baseline there was solid, but yes, most of these Angular is the, is the benchmark. [00:33:40]

Okay, this is interesting. So this, these are a lot of... This does look like a pretty solid stress test. You know, like 1,000 item list, one update on 25% of items at random. Like, that's pretty good. You know, that reminds me of like a stock ticker, you know, a table of stock results with real-time prices updating. [00:33:47]

Mark: Interesting. I actually just dealt with that scenario in the React Redux prototype branch that I'm working on. I'm going to have to go steal some ideas from this, for this one too. [00:34:06]

Carl: Ah, there you go. [00:34:14]

Yeah. I had to render sparklines once, and do you know how many DOM nodes are in a sparkline? Do you know what happens if you render one sparkline for 30 table results? So I, yeah, the optimization that has to go into that is kinda crazy sometimes. But yeah, cool. This looks like a very good benchmark. And yeah, it is in fact saying that Angular has the best performance as rendered by time spent- [00:34:15]

Mark: Doing the data update work, I think [00:34:38]

Carl: the values here are not super-duper helpful, I would say. The options here are values raw, so I don't k- I, like, I don't know if that's raw on milliseconds. I don't know what unit's it in, or a score, which is also not helpful, or multiplicative relative time. So anyway, this is really interesting. I think this has potential to be very helpful. [00:34:42]

Benchmarks are great, and we have a new one. [00:35:02]

Aiden Bai released ReactBench to measure AI code quality

Mark: And then one other benchmark, Aiden Bai, who has been on a tear releasing various kinds of React-related analysis tools, right up my alley, put out a React bench to try to measure how well different AI models write React code. He put together some kind of a scoring metric for common mistakes and patterns, and is measuring how well they actually write good code versus bad code. I'm assuming that a fetch in a use effect is scored as bad. [00:35:04]

And for the record, apparently GPT 5.6 is leading at a 53% score on the benchmark. [00:35:38]

Carl: Cool. Interesting. I love this because this is such a, like "code crafts person" versus "fuck it, ship it" attitude. This is something I felt like I had to get over in my professional career, 'cause I jumped around employers so many times, and I was so close to the React ecosystem, it's like, "Oh, cool. [00:35:45]

I know all the best practices. I know how to do it right." And then you join a company, it's like, "Oh, you're just putting a component in state? Got it." Yeah, I bet the, I bet all of these models are trained on some pretty garbage code, because most of the code in the world is complete garbage. And I think that's very clearly demonstrated by the highest score on this being 53%. [00:36:00]

Mark: I'm gonna have to go dig into that benchmark to see what they're actually scoring things on. [00:36:20]

Carl: The time I saw a component being put into state was during a take-home test... No, during a whiteboard interview for a new company, and I terminated the interview because I was like, "If you're doing this, then I do not wanna work here. I am so sorry." [00:36:24]

Alex Russell blasts “state management” (and most of the React ecosystem) in favor of sync engines

Mark: All right, so that, that ties into our next item. Alex Russell wrote a, as usual, incendiary blog post blasting the React ecosystem and its practices. And as always, it's a very well-written post, and I actually agree with and understand a lot of the points he's trying to make. I disagree with the conclusions and the way he's messaging a lot of them. [00:36:37]

Carl: Yeah. [00:37:05]

Mark: So his first argument is React has built-in state management, but the existence of dozens and dozens of state management libraries must mean that either React isn't a state management system or React is an insufficient state management system. And I think we would all agree it's, it is a state management system, but it's very insufficient, the fact that it's all tree-shaped. [00:37:05]

So that's why we have all these external state management libs. He then goes on to, to blast the fact that there's the plethora of external state management libraries and that they're all big and complicated and basically just pub/sub event emitters. But where-- He then takes it in a very surprising direction, which is essentially that all these different state management libraries, quote, and I will paraphrase, "Don't actually manage state." [00:37:32]

They store a value at a point in time. They are pub/sub and trigger updates, but they don't have any sense of what was the state over time or how do you intelligently merge in changes over time. And so he then points to sync engines and CRDTs as essentially this is what I think is the right way to manage state. [00:38:02]

Of course, half his argument is all these libraries are large and then people do bad things for SSR and hydration and send down massive JSON blobs, and that leads to bad perf. But he's also primarily arguing that the entire way the React ecosystem uses the word state management is wrong, and that almost everybody would be better off using some kind of a sync engine or, or CRDT to both auto-merge changes as well as manage the time aspect of changes. [00:38:36]

I hear what he's saying. I disagree on a number of levels. When I wrote my Redux versus Context post a few years ago, I actually explicitly said that to me, a state management tool is, well, essentially pub/sub. You store a value, you have a way to update it, you have a way to read it, and a way to trigger updates. All these libraries fit that category. He's the one trying to put the extra dimension of time on top of that. [00:39:12]

I agree sync engines and CRDTs are useful, and that probably a lot more people ought to look at them. But I feel like saying these are a blanket solution that almost everybody should go with if, you know, assuming you're doing more than just server-side rendering, feels like it's a pretty big step. [00:39:39]

And so I had a bit of a debate with him on Blue Sky about this, kind of trying to probe and get him to expand on a few of the thoughts, and he eventually did say that like, "Yeah, I'm basically saying that everyone needs to have a major mental shift in how they approach thinking about state whatsoever In applications." [00:39:59]

Which I get what you're saying, and number one, that's not going to happen, and number two, I don't agree that it needs to happen. [00:40:18]

Carl: Yeah. The, specifically that thought, that expressed thought of, "the problem here is that everyone else is thinking about this wrong and everyone needs to learn this new thing in order to do it correctly." [00:40:25]

Categorically, I'm gonna say that i- if that's your defense, it's ineffective. Like, no one has, no idea has ever been adopted to that extent. Like, the best you get is something like React. React is one of the most widely successful used technologies like that, and we're discussing how badly abused it is. So like, no, you are never going to get everyone to do any particular thing in a particular manner. [00:40:39]

I also empathize. Like, most state, quote-unquote, in React apps is actually cache. You know, and we've discussed how, like, most state should just be like React Query, because actually you're just caching network state. This is not your local state. [00:41:06]

Mark: Use Nuxt, put more of it in the URL so it, it survives a page refresh. You know, use, use uncontrolled form inputs, that sort of thing. [00:41:20]

Carl: Right. Right. And so sure, it is probably technically, from a technical perspective, it is correct that we are misusing state. State is a precisely def- defined technical term, and we are probably misusing it. We are certainly misusing it. But like, I don't know, what are you gonna do about it? [00:41:29]

Mark: I tried to hint at this in the Blue Sky thread, and you didn't really bite on my train of thought and went in a different direction. But like, I'm a big fan of going back to how did we get here, what problems were people trying to solve? Problem A leads to problem B leads to problem C. Each stage builds a new tool to try to address the previous problems we had. [00:41:48]

We went from, you know, you can't do JavaScript in the browser to you can do a bunch of JavaScript in the browser to, okay, y- we've got jQuery to make it easier to work across browsers, but you're just toggling a class in the DOM. You're hoping that the DOM is what you think it is at that point in time, otherwise it breaks. It's hard to scale all these jQuery click handlers. What if we tried using actual variables to keep track of this data? How do we start to write larger scale structures and architectures? Keeping track of all this logic's hard. What if we just declared what we want it to look like and let the framework take care of it? Okay, we're having trouble keeping that data in sync across large parts of our apps. [00:42:08]

So I'm not saying that the current React or front-end ecosystems are Great. I'm not saying that they are, like, you know, absolutely the best possible theoretical way we could have landed on doing things, but I do think it's important to say, "This is how we got here, and this is the real world current state of things. What can we practically do to improve things?" [00:42:50]

And so I would be very happy to have conversations with Alex about, like, "Okay, here's how the React ecosystem got here. I'm sure you know this already, but, like, this is where we are. Here are some influ- here's are some ways we could try to nudge things and push people towards mentally modeling." [00:43:20]

But just starting off by saying, "React claims to have state management and it doesn't fit my definition, and therefore it's wrong, and everyone else has weighed these things on top that aren't my definition, therefore they're bad, and also bad at perf." I get that he- a little bit of this is him venting, and I think part of it was the, "I've had these discussions, let me write down my thoughts so I can refer to them." okay, cool, agreed. But it feels a little bit like shouting into the void, and it's not going to improve the situation at all. [00:43:36]

Carl: Right. Yeah. Like, there are two little trigger phrases here that make me go, "Er." And one is the first sentence. "It is by no means the gravest linguistic crime of the React epoch, blah, blah, blah." [00:44:05]

But, like, okay, so, like, literally this starts off announcing that a gripe on semantics. Th- this is framed as a linguistic crime, so it's just definition and what are we talking about. And then at some point it's like his stated resolution here is, "Devs should..." And like, boom, done. You lost me. Devs is not precisely defined. Who are you talking about? Who needs to make a change? [00:44:15]

And you just say should. Like, devs should do something. Like, I don't know. Any- anytime somebody uses a general statement about a large population to say, "Everyone in this group should do X," like, you're wrong. It does not matter who you're talking about or what your idea is. [00:44:38]

That is never correct. So right. I, like, I broadly agree with the perspective here as I- correctly identifying a problem. [00:44:53]

Mark: As my mom used to say to us many times growing up, "You stated the problem, now state the solution." [00:45:02]

Carl: Right. It's a problem. The solution is hard. [00:45:07]

Like, there are lots of very smart people working very earnestly on this problem. You know, we as an industry are exploring the cutting edge of UI and what does it mean to interact, you know, human computer interaction used to be considered a field of academic research. And, like, all of us are HCI experts with no credentials and no... [00:45:09]

Like, you know, there's no scientific rigor behind the experiments we do. Our company, our companies just say, like, "Oh, I think this should be-" A dropdown instead of a type ahead select. And like, you know, okay, why? Oh, well, you know, that's what the design, that's what the design spec calls for. Okay, well, why? Well, that's what the designer wrote down. Well, okay, does that, how would people interact with that? This is a human computer interaction question, and there is a body of research. [00:45:30]

We are earnestly exploring all of this without the support of traditional, like, in years past, in decades past, people doing this type of exploration of a, a problem space might have the support of things like academic journals with peer review, and then ultimately, if it's published in this journal, then you can trust that it went through this review process and, you know, that by being present in its current form, it represents a consensus from this perspective. [00:45:56]

And like, we don't have that. We have blog posts. Like, you know, we have vibes of popularity. So like, we're exploring a really challenging problem space without very much ability to capture the results of those explorations, and that's a very hard space to be in. But that to say, I think there's a lot of really interesting stuff happening with sync engines, Electric SQL. I've, I remember hearing about a long time ago, the... Oh, God, I can't remember some of them. There were a lot of really good sync engineed and local first- [00:46:26]

Mark: Electric, Zero, Replicache, maybe that, maybe those are the same company. Howard Sync is out there, I think. [00:46:55]

Carl: Yeah. Thank you for filling in the gap. I have lots of the ideology and less of the, uh, proper nouns. [00:47:02]

But so yeah, yes, correct. This is a problem. People do misuse date, quote, unquote. But yeah, the way you change that is by effectively broadcasting a message that allows people to observe that their previous practices were incorrect and guides them into more correct practices. [00:47:07]

Mark: Update the docs, add a linter, build it in by default. [00:47:27]

Carl: Right. None of those include an angry blog post. I relate to that as someone who wishes to write angry blog posts, but I don't think it's an effective solution to the problem [00:47:30]

Aurora Scharff rewrote the Suspense docs page to cover how it works

Mark: Aurora Scharf, who has been doing a lot of fantastic conference talks and blogs on using Next.js and using Suspense in the last couple years, joined Vercel and i- in a dev role, role, and has been, I guess, part of or working with the React team. [00:47:41]

I think she's actually listed on the team page. And so she actually just did a significant update to the Suspense docs page to add a lot of details on what are all the cases that actually trigger a Suspense boundary, as well as some of the, the other use cases. So again, great to see a lot of the, the usage and technical details being fleshed out in the official docs. Always something I'm asking for. Yay. [00:47:56]

And a post on RSC performance patterns

Mark: Uh, and then she also wrote on her own blog a, a post on some various Suspense-related usage patterns that she's been playing around with. [00:48:22]

Cool. [00:48:31]

On the flip side, the TanStack folks have added initial server component support in its own form to TanStack Start. We've talked about that in previous months. [00:48:31]

TanStack removed RSCs from the website

Mark: And I believe they had been using that in the actual TanStack.com website, primarily to move heavy markdown rendering to the server so you weren't shipping the, the markdown rendering logic to the client and having to wait for that to happen. And apparently they've removed that. They put up a post saying they actually pulled out the server component usage. [00:48:41]

It worked, but it, they weren't getting a lot of benefit out of it, and it was actually hurting perf in some ways. And instead, they have restructured things. They've actually shipped a couple of very tiny libraries to do markdown parsing, and then separately, syntax highlighting. And so essentially going back to a somewhat more SPA-ish approach, but minimizing the amount of work done so they still get fairly fast loading times. [00:49:01]

Carl: Nice. Let me tell you, doing syntax highlighting on a documentation site is fucking crazy. I underweighted that as a problem circa 2018, and it almost killed the entire project, because we had wanted a single API reference page constructed from dozens of markdown documents, so we could maintain it as individual docs, but have it presented in a single, large, searchable page. [00:49:26]

And holy shit, we were shipping 12 megabytes of HTML across the wire because of syntax highlighting. We took syntax highlighting out, and it dropped to, like, you know, 600 kilobytes. Which is still insane, and, like, part of the reason it almost killed the project, because we just were trying to put too much docs on one webpage. [00:49:48]

But- Yeah, man, like when you start highlighting individual, every individual character and wrapping it in glyphs, in a span which has a class name, and, uh, so it's, it is insane how much markup bloat gets added just by syntax highlighting. So moving that from rendered on the server, shipped to the client, into data is passed from server to client and then rendered on, on the client makes total sense to me. [00:50:05]

But that's why this is the cutting edge of UI, 'cause like that sounds so obvious. Of course you just want a rendered page to come directly from the browser and oops, that rendered page is 20 times larger than it could be if you just sent the raw data needed to render it. So that's why it's so impossible to answer the question abstractly of whether or not server components are right for you, 'cause I don't know. Do you know? [00:50:32]

Anyway, that's a fun project. This is a really good case study. I love it. [00:50:56]

Mark, tell us, I'm giving you an opening to talk about your performance prototyping. [00:51:00]

Mark’s making progress on some React-Redux perf prototyping and thinking about RTK 3.0

Mark: So I'm pretty sure I alluded to this two months ago, and then I linked the draft PR last month. But for the last few years, I've been kicking around the idea that surely there is some way that I can magically use some combination of signals and proxies inside of React Redux to speed up performance updates in large scale applications. [00:51:04]

So cases where you have thousands of connected components, and right now we have to run all end subscribers and selectors on every dispatched action just for each selector to grab its state and diff the result and see if it needs to update. That's fine when you've got 500 or 1,000 components. When you've got 5,000, 10,000, whatever, that's just the overhead of calling those subscribers is expensive. [00:51:26]

So I played around with a couple proof of concepts in previous years. They were like, you know, like one-off, I'm gonna hack on something, and didn't get any further. So I finally came back to that , and I did a whole bunch of research on other signals libraries, proxy-using libraries. What do they do? How do they work? What are they good at? Where do they break? All very AI powered. [00:51:54]

And I have a working branch that adds a useSignalSelector hook to React Redux that is using the Alien Signals library inside. And essentially what it does is it wraps your selector so that the data is in a proxy, tracks what fields got accessed, and then essentially precomputes, "Hey, this was the state that got updated. Do we think that selector actually needs to run? Nah, skip it." With the idea being that in most cases, only a relative handful of selectors actually need to rerun most of the time. So if we can just pre-skip most of them, that ends up being a performance win. [00:52:16]

So I have a draft PR. It works, and it appears to be a significant performance win almost across the board. In terms of the number of updates, in terms of the total amount of scripting time that executes. It's a little bit slower in the mounting phase because it takes more work to set up the signal and the tracking time. [00:53:03]

There's definitely going to be some bigger bundle size. I don't know how big, like 5 to 10K maybe. And there's also a few weird cases, like doing certain identity comparisons won't work because you're comparing the proxy reference and not something inside the proxy. [00:53:25]

But it feels good enough, and I've got solid enough test coverage that I actually feel very good that, like, this is a, this is the direction that I would probably end up shipping. There's a lot of work to figure out around real-world testing and, you know, like all, all the, all the non-fun stuff around actually shipping real software. Uh, but the idea is it would be a separate set of exports. You would intentionally choose to use this. So like most apps would still have useSelector by default, but if you have a large-scale app and performance is a problem, then-- And you, you could choose to import this and make slightly different trade-offs in performance and bundle size. So I feel pretty good about that, and I'm, I'm still finding time to try to push that direction forward. [00:53:41]

I'm also thinking about what a notional Redux Toolkit 3.0 would look like. Uh, a couple years ago when I shipped 2.0, and I said at the time that I was deferring touching RTK Query at all because there's some unknown number of breaking changes we would probably wanna make. I don't even know what those are. We'll just kick that can down the road. [00:54:32]

Well, we've successfully kicked the can down the road almost three years at this point. Uh, the ecosystem is actually going ESM-only at this point. So presumably, if and when we do a 3.0, it would be ESM-only. Um, but I've had a bunch of things on my mind in terms of rough spots in our API and the way the internals have just evolved over time, but in a kind of haphazard way because people keep asking us to add options or capabilities, and we just added them without ever really, like, doing a coherent design upfront. And so there's, there's a bunch of pain points I've known about. There's a bunch of things I would like to improve. But they were all, you know, if, maybe, someday. [00:54:53]

And so actually just in the last 48 hours, I did a whole bunch of AI-powered research tasks saying, "Here's all the things I would like to have, the properties and qualities I'd like to have in a 3.0, um, some new options I'd like to add that we can't do right now because they break with TypeScript. [00:55:38]

Could we possibly come up with some kind of an API design that looks basically the same But is just different enough to clean things up and unlock the constraints. And, uh, as of last night, I've got a local prototype that Claude claims actually, like, does most of what I wanna do. So, like, noth- nothing's happening anytime soon over here, but, like, I actually have had the time and effort to do this because the AI can do the dirty work, and frankly, I didn't have the time or effort or mental capacity to do that work myself. [00:55:56]

And so being able to tell it, "Here's what I want. Can you just, like, run for a while and, and come back to me and tell me if this works?" has actually made this possible, which is actually pretty cool. So nothing's, like, nothing's gonna ship anytime soon, but I actually like the direction this is going. [00:56:29]

Carl: That's super fun. I love having problems within a box that is clearly defined enough to where AI can do it in that kind of way. A lot of the problems I've been exploring are primarily in my head, and so getting them out of my head and into a state that AI can check against is its own task, and so it's a problem. [00:56:47]

Mark: Part of me feels a little bad that some of my contribution here was just saying the equivalent of, "I don't like that answer. Try again. Think harder." But also, like, I had to come up with, "Here's the list of constraints that I want to satisfy and the problems I want to solve, and here's the list of the prior research we did. [00:57:04]

Now go think hard on these things." Like, I am actually driving the work here. [00:57:23]

Carl: Right. Having that body of knowledge and research is critical, and is real work, and should not be discounted. [00:57:28]

Making referential stability a type

Carl: Cool. Into a couple of final details before we wrap up. This is a fun aside. Making referential stability a type. So React relies pretty heavily on referential stability, which is triple equals equality. If you have two objects or arrays that are equal to each other, it is literally the same reference. It is the same pointer. It's in this, the same part of memory. [00:57:36]

And someone made a type that represents that, which is crazy. I don't understand how they did that. I saw our resident TypeScript wizard here, who is the person-- I think they're the only person who's answered any types question I've had in the last, like, decade, possibly literally. My favorite types wizard said, "Oh, cool. I tried to do this and gave up." Which I just love. Like, yeah, this is a hard problem. It's really cool. It would be really nice to have. Somebody seems to have put together a real effort at it, and I love that. It's cool. [00:57:59]

Mark: Yeah, what they bork on both Preact and GraphQL. They're one of the Preact maintainers. [00:58:31]

Carl: Oh, cool. I love that. Wow. Real-- I don't know. They got real chops. Yeah, core team of Preact, Urql, and- Gql.tada. So yeah, okay, they've got some real experience with wrangling complex data. That's awesome. [00:58:35]

Mark: There's been an interesting set of different projects around trying to compile TypeScript code to true native code. [00:58:48]

One that's been out there for a while is called AssemblyScript, and it's essentially a, a restricted subset of TypeScript, not full-blown true JavaScript semantics. But there's three different projects I've seen recently that are attempts to compile just straight-up TypeScript code to native code in some form. [00:58:57]

Porffor native compiler upcoming alpha

Mark: One's called Porffor, which is a... It's a single-person project. He's been posting about this for a while and doing a lot of performance optimizations on the output lately, and even making the compiler self-hosting. So he announced that Pro4 is about ready to hit alpha stage in the next few weeks. So that, that's a pretty massive technical achievement there. [00:59:17]

Perry cross-compiles Claude Code bundle

Mark: A second one called Perry that I, I don't know who's working on this, but I saw it pop up pretty recently. So they're also trying to compile TypeScript to native code, and they recently put up an article about taking the entire, like, 13-megabyte Claude code bundle that ships on disk and compiling that to native. [00:59:39]

And part of it's the compilation process, and part of it is all the semantics and non-JS bits that it expects, like relying on the, the message channel, message port interface to, to send messages back and forth over a microtask. [01:00:02]

Vercel releases scriptc native compiler

Mark: And then Vercel just announced something called ScriptC, and this is apparently in their Vercel Labs area, which is where they put all their vibe-coded projects. And, uh, boy was this one vibe-coded, I think someone on Hacker News points out that the first commit is 800,000 lines a week ago. Yeah, so who knows what the actual quality is there, but they're playing around with that. So Bunch of different people trying to solve the same problem of, it's both the publishing aspect and the runtime execution speed aspect. [01:00:17]

Carl: Cool. Interesting. Well, I would love it if we had some more native compiled… what attention we experience, because native compiling is also the thing getting suppressed by NPM for security reasons. So yeah, what, what attention the ecosystem is under right now of moving away from compiled dependencies, but also being very hungry for the kind of performance improvements that native code is capable of. [01:00:52]

Mark: I mean, I think in general, packages that have a native dependency used to rely on a postinstall script to check your local environment and then go manually download the binary. And at this point, most of them, like ES Build, have switched over to we're just gonna publish a se- a separate package for each possible native architecture. [01:01:21]

And then the package managers have gotten smart enough to say, "Oh, well, each of those packages lists a certain native environment that it needs. Let's only actually install the one that matches your current environment." [01:01:42]

Carl: Fair. Interesting. Complex, nuanced, subtle. [01:01:57]

Mark: Programming. [01:02:01]

Carl: Programming. Facts. [01:02:02]

Goodbye, forever, probably.

Carl: Cool, okay. Our last link for you today is, I don't know, it's kind of sad. [01:02:04]

Goodbye Forever, Probably. [01:02:09]

Mark: It's very personal. [01:02:11]

Carl: Very personal. This is by Salma Alam-Naylor, who goes by White Panther online. They were a very talented developer relations person for quite a while. I feel like they sprung up out of nowhere, or at least I didn't see them before they were huge. And I always thought they were very, very, just very skilled at it. [01:02:12]

I thought they did a really good job of being technically at the cutting edge, while being, like, personable and entertaining. And, like, that's really hard. All three of those is really hard to do. But, so anyway, she put out this blog post called Goodbye Forever, Probably: Why I'm Leaving Developer Relations and Why I'm Not Telling You What's Next. [01:02:30]

And oh man, I gotta say, a lot of this resonated with me. I've actually never had a job described as developer relations. I'm just a developer who blogged and has engaged with the community, which then later turned into the job of developer relations. This whole thing I relate to so much. Like, the number of times I've sat and seriously contemplated if I wanted to keep doing what I was doing is, like- At least five, possibly more than 10. I think about it often. [01:02:50]

And I've always stuck it out. I don't know, here I am. Probably because nobody's paying me and because I have full agency over everything I do, which has its own different trade-offs. And yeah, I don't know. This is just a really good articulation of how hard it is to be publicly visible in tech and to get paid for it. [01:03:18]

And I think that if you are someone who consumes tech content, this is a really good read to see what it's like on the other side of the page. [01:03:34]

Mark: Yeah. So, um, makes a, an, a bunch of different points. A lot of it is around dev rel as a job role, that it's, it is by its nature really hard to measure. You know, how are you... Like, what metrics are you being measured on? How are you trying to contribute to the company? How do you even know if you're having success? What is your role? Are you going to conferences, writing blog posts, writing documentation, that sort of thing. [01:03:43]

But specifically she also talks about being heavily overworked at multiple companies, and that contributing things. She'd spent a lot, a lot of time streaming. That was a really big part of her online persona, both in and out of the day job role. So that, that sucks up a lot of time and effort. But then also talking about AI killing teaching content. When she linked this post publicly on Blue Sky, there was a massive number of responses, and I know somewhere down in the replies, Josh Comeau said that he's looking at taking a break from building courses as well. [01:04:06]

So when you put in massive amounts of time and effort to carefully craft a teaching course, and then either y- you don't get much payoff because people aren't buying it or the content essentially just ends up getting swiped Yeah. Like, why put in the time? [01:04:42]

Carl: Yep. I was thinking about Josh and this as well, 'cause Salma says here, "I've too often overworked myself in desperate attempt to justify my existence. This has more than once caused me to suffer from health problems, including joint and nerve pain. At its worst, I couldn't even use my hands due to the pain." [01:05:00]

That happened to Josh. Like, both Josh and Salma had to learn to code with their voice because of hand injuries as a result of overwork. So, like, these are two extremely successful people who have, as in pursuing their success, ground their bodies into a state of non-function. [01:05:15]

So, like, that's the industry we're in. I don't know. This is what working in tech does. This is what succeeding in tech does. It's hard. One of the decisions I made in producing this podcast was I am not targeting entry level. This is not educational. This is not catch up, this is stay on the cutting edge. [01:05:34]

And part of that was because of looking at the economics and realizing that, like, you know what? If you're targeting entry level people, the market you're chasing doesn't have the income. They don't have money. They're trying to get into tech. Part of the reason I have never targeted entry level humans in tech, trying to get into tech, is because I felt the economics of it was pretty fucked up. It was, you're taking money from people who aspire to get into tech to get the high salaries, and that's playing off people's desperation to succeed and do well. [01:05:51]

And, like, ultimately, like sure, while the money was flowing, while it was easy to get into tech, while you could self-teach and then get a full-time job that pays you six figures, like fuck yeah, that was a great deal. That was great. That was phenomenal. It was a good part of the world to be in. [01:06:22]

And now you can't. And so I think we're gonna watch a lot of educators' careers dry up because for all the good they did for the people, the market they're serving to doesn't have the money. They're trying to get the money. [01:06:35]

I think we're gonna see more of this, unfortunately. It's gonna get blamed on AI, and, but there is a portion of that. People don't seek-- People are self-educating less often and relying on AI to learn more of those nuts and bolts details for them. That's true. But I do think there's another real problem of incentives. [01:06:51]

You know, this reminds me too of GitHub just announced, their sponsors program, the GitHub sponsors program, you know, they waved the banner. They, you know, did the proud marketing announcement that $100 million has flowed through the program since its inception in 2018. So since 2018, 2019 I think it was actually, 'cause the number in my head is seven years. But so over the past seven years of GitHub having a sponsorship program, $100 million has flowed through it in total. [01:07:09]

Mark: 14 million a year. [01:07:38]

Carl: Yeah. I did 30 seconds of back of the napkin research and math, and the number I came up with for venture capital dollars that flowed just in SF over the same time period is 200 billion. [01:07:40]

So while content creators are chasing their piece of $100 million, the businesses are chasing 200 times that. Thousands of times the sums of money involved. So like, I- it's, for all the commentary about, you know, who's doing what in education and content and making money, like at the end of the day, like there's a stereotype of a certain political subgroup that all just passes around the same $20. You get it, and you give it to someone else, and they give it to someone else, and they give it to someone else. [01:07:54]

And like that's how I see programs like GitHub sponsors. It's not a sustainable ecosystem 'cause you're all just passing the same $20 around at the end of the day. The money's coming from somewhere else. [01:08:25]

So that's my... Sorry, that's my political rant at the end of this. It's rough. It's rough out there. [01:08:36]

Conferences (React, Javascript)

Carl: Mark, did you add these conferences? Should we read them? [01:08:41]

Mark: Yeah, I put them in here, uh, because I will actually be speaking at both of them, and they're, they're also coming up. [01:08:43]

So listing the two conferences off the top of my head that I know I'll be at. [01:08:49]

Sep 11: ZurichJS, Switzerland

Mark: ZurichJS in Zurich, Switzerland on September 11th. The primary organizer, Faris Aziz, great person, first year putting on the conference. I have a sense of how much time and effort he has put into trying to organize this conference. Fantastic person, ton of effort, and I'm really looking forward to that one. Great list of speakers as well. [01:08:53]

Sep 25-26: React Alicante, Spain

Mark: And then, uh, React Alicante is in Spain September 25th and 26th, o- out on the Mediterranean coastline. This will be my third straight year speaking there. Again, wonderful conference, great community vibe, highly recommended. So if any of you happen to be in Europe or can make your way over to Europe, definitely check those out. [01:09:14]

Carl: Heck yeah. Well, that's everything we got for you. Thank you for listening. We'll be back here on the live stage on the last Wednesday of August, or back in your podcast feed just as soon as we can. Man, maybe, hopefully I'll get it in by the end of the month in July. I've been bad at that lately. Sorry everybody. [01:09:32]

Yeah, thank you so much for listening, especially to those of you who made it all the way through the end to hear this gratitude. [01:09:47]

Mark: We started the day by saying we've got a grab bag of stuff. Yeah, we never run out of stuff to talk about. We cut out 15 items. [01:09:53]

Carl: Yeah, we did cut out legitimately 15 items and still went 30 minutes over time. [01:10:01]

Yep. That's us. Thanks so much. If there's feedback you wanna send, if there's tips you wanna give, please email them to hello@reactiflux.com. I read every email that comes through. It's a low number. It's very easy. [01:10:06]

If this is a show that you get value from and wanna support, the best way to do so is by submitting a review wherever you listen and by sending this episode to your friends. Thanks so much. See you next month. [01:10:18]