1 00:00:00,000 --> 00:00:14,000 Carl: Hello. Thank you everyone for joining us for the September edition of This Month in React, as we recap what's going on in the React, React Native, and across the whole web ecosystems. We're coming to you live here in Reactiflux, the place for professional developers using React. 2 00:00:14,000 --> 00:00:35,000 Carl: I'm Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I do community programs like this event and the event I did yesterday, and build tools to help keep the community operating, and unfortunately, somewhat neglect those tools after several years of maintaining them, resulting in some, uh, we've had a couple of people get kicked by accident because of some changes that happened there, but we'll fix that. 3 00:00:35,000 --> 00:00:51,000 Mark: Hi, I'm Mark. My day job is still at Replay, where we're still building really awesome time travel-powered dev tools and an automated QA layer on top of that that can find bugs automatically. and boy, am I still doing a lot of Redux stuff in my spare time. Woo! 4 00:00:51,000 --> 00:01:08,000 Carl: Yeah, you've got a few new things to announce there. The, the big headline here is we've got a new, you know, React minor version, 19.3. people are continuing to eulogize software engineering as a field, so we're gonna keep talking about that. I feel like we've been touching on that more and more the last couple of episodes. 5 00:01:08,000 --> 00:01:09,000 Carl: Let's start off with some new releases 6 00:01:09,000 --> 00:01:37,000 Mark: so speaking of me being busy, um, the first item on the list is that the Redux family of libraries now has a single unified combined docs site. we'd al- always had multiple separate doc sites because we had multiple separate libraries, each with their own repository. The Redux core, which also had all the tutorials and the usage guides, Redux Toolkit, React Redux, and then Reselect. 7 00:01:37,000 --> 00:02:02,000 Mark: and so each of them had their own markdown files. They each had their own Netlify site and, and build previews and everything. And people had filed complaints over the years saying that it's confusing that I have to jump from site to site to follow links or, or information. Uh, the sites all had the same look and feel, which was good, except you get confused which site you're looking at, some pages were duplicated across sites just in case. 8 00:02:02,000 --> 00:02:25,000 Mark: I had said for years, "I can't do that," because the only way I can think of to do it at the technical level is to combine all of our repositories into a giant monorepo, and this will require massive amounts of Git history surgery and changing all the pipelines and the issue management. 9 00:02:25,000 --> 00:02:51,000 Mark: And, like, I'm doing this in my spare time. I... There's no way I can put hundreds of hours into this effort. Well, last year, actually pre-AI, I had very briefly prototyped an alternate idea, which is what if I just cloned the other repos whenever you do a Redux core docs build, and then you got the files on disk, and then Docusaurus lets you combine multiple sets of content into one site. 10 00:02:51,000 --> 00:03:10,000 Mark: And so I'd at least proved that it was possible in theory. And so, as I'll talk about later, I'm doing a whole bunch of Redux-related cleanup work at the moment. And over the last, like, just two to three weeks, I said, "What if I just point my agent at this and say, 'Do it for me?'" And we worked through all the complexities. 11 00:03:10,000 --> 00:03:30,000 Mark: We got all the content up and running in one site, worked through a bunch of issues around PR previews and other things, and I, uh, officially shipped it while I was 34,000 feet over the Atlantic on Monday. and so there's now a single site, redux.js.org. It's got a dropdown to s- you select which set of library docs you're looking at, de-duplicated pages. 12 00:03:30,000 --> 00:03:39,000 Mark: I also did a massive cleanup sweep to find every place we had out-of-date explanations and content, and so that's all up there. 13 00:03:39,000 --> 00:03:41,000 Carl: you got another news to announce too 14 00:03:41,000 --> 00:03:59,000 Mark: Yep. so for the last couple months I've been saying that I was working on a new React Redux hook. It is now in alpha. It's called useSignalSelector. It is a drop-in replacement for useSelector that uses proxies and signals inside to try to optimize updates. It should not be the default one that you choose. 15 00:03:59,000 --> 00:04:12,000 Mark: It's meant for large apps with thousands of connected components. It does have a larger bundle size, but it speeds those up as well. So, it's pretty solid at this point, and I'd love people to do some real-world testing on it. 16 00:04:12,000 --> 00:04:13,000 Carl: Oh, yeah. 17 00:04:13,000 --> 00:04:31,000 Carl: We mentioned this last month, as an RC, but it's now out for real. Vite+ has a 1.0 release. They... This l- this is pretty neat. It looks like it's trying to offer, like, a general kind of one-stop. I guess it's a little funny. It's kind of an abstraction over, you know, what we would typically do for NPM scripts. 18 00:04:31,000 --> 00:04:51,000 Carl: , instead of, like, npm run, npm create, npm install, it's got vite+, you know, vp create, vp install, vp dev. That's interesting. It's, it's trying to provide d- sane defaults for a lot of these really common behaviors using, you know, the current cutting edge of tools, Oxlint and Vitest and Vite 8 rolldown. 19 00:04:51,000 --> 00:05:07,000 Carl: I see TS Down mentioned, for packing libraries. It has a monorepo awar- aware task runner with caching. So you know, it's, it's trying to do a lot. I would love it if one tool did all of this. That's really great. I hope it works as well as advertised. 20 00:05:07,000 --> 00:05:30,000 Carl: Stuff like monorepos gets really complicated. I'm actually, m- currently in a project where I'm looking at options for monorep- repos across different languages. You know, I wanna, I want to not lock myself into only using TypeScript, so that's, you know, that's a whole different prospect. so yeah, I'm curious. I'll have to play with this. I'll have to see what it actually looks like in practice. But yeah, so, Vite+ has a 1.0 now. 21 00:05:30,000 --> 00:05:53,000 Mark: It, it is interesting to compare it to earlier similar things. Create React app at least tried to provide pre-built configs for Webpack and Jest and Babel and everything else so you didn't have to do it. And then the Rome project was originally supposed to be linter, formatter, everything else, one AST parse, and everything is fully combined. 22 00:05:53,000 --> 00:06:10,000 Mark: And then it flopped as a company, and we were left with just the standalone formatter that became Biome. So kudos to the Voidzero folk for managing to build the separate tools and then figure out how to get a layer on top of that, sort of flipping the process. 23 00:06:10,000 --> 00:06:27,000 Carl: We've also got Vitest 5. you know, I, I don't know. It's a test harness. It's advertising a lot of performance improvements, which is great. It's always good when our tests run faster. Not seeing a ton of, you know, major changes that would get me excited about a new test runner, but, hey, new version. 24 00:06:27,000 --> 00:06:30,000 Carl: L- V- Vitest is great, and now it's great-er. 25 00:06:30,000 --> 00:06:41,000 Carl: , we talked about this a couple of months ago. Uh, Cloudflare produced a open source Next runtime, so you can self-host it more effectively. they 26 00:06:41,000 --> 00:06:42,000 Mark: a slop, it's a slop fork 27 00:06:42,000 --> 00:06:48,000 Carl: It's a slop fork for sure, but you know, hey, the, the, if we have functional tests, what's the problem? so yeah, it's a slop fork. 28 00:06:48,000 --> 00:07:01,000 Carl: We talked about this in February. Uh, they are now announcing a 1.0 seven months later, so it was a slop fork, and hey, maybe it's now revised down into something a little bit less sloppy. And it's a 1.0, so that's great. 29 00:07:01,000 --> 00:07:27,000 Mark: , so Lovable spins up tens of thousands of dev servers for all the different apps that they build, and even with Vite using Rolldown and Rust powered inside, they decided it wasn't fast enough for them. So they, they similarly have reimplemented some of the guts of Vite to make it even more Rustified in some way, and this has apparently been fast enough to handle the, the speed of all the dev servers they need to spin up 30 00:07:27,000 --> 00:07:37,000 Carl: Nice. Cool. Yeah, I mean, certainly they're dealing with a lot, l- large volume of code right now. Improvements they make and the, friction they experience is gonna be pretty representative of the industry. Cool. 31 00:07:37,000 --> 00:07:42,000 Carl: Again, something we talked about last month as an RC, Preact version 11 was released. 32 00:07:42,000 --> 00:08:03,000 Carl: We talked about most of the benefits last time, so I'm not gonna, going to exhaustively, you know, re-discuss them. In reduced package size on disk, you know, install size of the whole module. they're talking about tree shaking, which, man, you know, everyone always talks about how it's all tree shakable now, and then I feel like the next version talks about how it's really tree shakable for real now. 33 00:08:03,000 --> 00:08:23,000 Carl: So I just always take that with a hefty dose of salt. But hey, they're advertising it. It seems great. Tree shakable per feature, which is lovely. Yeah, lots of deeper in the weed stuff. They're saying hydration 2.0, hydrating while lazy chunks are loading makes zero DOM mutations. Cool. Love that. yeah, Preact version 11 seems great 34 00:08:23,000 --> 00:08:53,000 Mark: Meanwhile, MSW, Mock Service Worker, just released version three. This looks like it has some pretty meaningful changes. They're going ESM only, like a lot of other libraries. More granular entry points, which sort of ties into the tree-shaking sides of things. Um, they now support, uh, GraphQL subscriptions built in, and there's a whole new API for defining network sources that's kind of like a, an, an improved version of the handler definition approach that it had. 35 00:08:53,000 --> 00:09:11,000 Mark: and it also has lower level support for being able to directly intercepts all the way down to the socket layer, even with, even within Node. So I know Artem's put a lot of time and research into figuring out how to make network interception more effective, so this one feels like a pretty big release. 36 00:09:11,000 --> 00:09:28,000 Carl: Yeah. Love that. MSW is, I haven't used it lately. The times that I've had to reach for it, it's been like an absolute essential part of achieving whatever task I was working on. Like, if you're doing integration tests, then like, ugh, MSW is so good. so yeah, exciting. 37 00:09:28,000 --> 00:09:47,000 Mark: React Router put out version 8.4. They've done some internal re-architecture and changing their context structure to reduce re-renders. they've also got some optional more efficient route matching. So I guess if you've got apps with lots of routes and that's a possible performance bottleneck, then they've got an option that will try to make that faster 38 00:09:47,000 --> 00:10:05,000 Carl: Cool. And, uh, Remix is advertising its, V3 release candidate. I don't know, where... At what point do we stop including Remix in here? 'Cause they're, like, very publicly not a React framework anymore, you know? We're leaning on it for its historic relevance at, this point, starting to. 39 00:10:05,000 --> 00:10:23,000 Carl: yeah, they're saying since the beta, it's grown a lot. A complete database workflow with migration seeding, status checks, full stack hot module replacement, reload server modules, improved public asset serving. So, you know, it's, it's a, full web framework. They are moving away from React. 40 00:10:23,000 --> 00:10:42,000 Carl: They are... I believe it's pretty heavily relied on at Shopify, which I think we're gonna talk about later too, is, uh, moving off React Native. So I, yeah, wow. I g- you know, hey, come to think of it, actually, Shopify generally seems to be exiting the React ecosystem if they're doing Remix and native apps. 41 00:10:42,000 --> 00:10:43,000 Carl: Interesting 42 00:10:43,000 --> 00:10:48,000 Mark: And I, I don't think we actually have the link in here, but I believe Shopify just bought Tailwind 43 00:10:48,000 --> 00:11:01,000 Carl: Oh, did they? Curious. Oh yeah, on September 9th. I missed that. Okay. Remix is great. Technically, our website, one or more of our websites runs on it for Reactiplex, or has run on it. I've lost track at this point. But yeah. Definitely paying attention 44 00:11:01,000 --> 00:11:03,000 Carl: Jotai has a v3 release. 45 00:11:03,000 --> 00:11:28,000 Mark: So Jotai is an Atom-based state management library. I believe Recoil was the original library from Facebook that introduced that paradigm. Recoil died. Jotai was a smaller version from Daishi Kato. Version three is mostly clean up. I believe it, it also went ESM only, and changed a few exports and shuffled around some API locations. 46 00:11:28,000 --> 00:11:34,000 Mark: So mostly clean up, but there, there's a definite trend of libraries going ESM only at this point. 47 00:11:34,000 --> 00:11:41,000 Carl: Mm-hmm. Oh, yes. Yes, we've talked about that trend several times in the last couple of months. Love to see it. Finally. Ugh 48 00:11:41,000 --> 00:11:47,000 Mark: I heard an earful about it at a React Alicante last week. That may be a separate discussion topic 49 00:11:47,000 --> 00:11:49,000 Carl: Ooh, interesting. Okay, cool. An earful about ASMR 50 00:11:49,000 --> 00:11:54,000 Mark: the, uh, let's just say that a couple people have very, very strong opinions about this. 51 00:11:54,000 --> 00:11:55,000 Carl: Against or for? 52 00:11:55,000 --> 00:11:57,000 Mark: Uh, mostly against 53 00:11:57,000 --> 00:11:59,000 Carl: Fascinating. Okay. All right. 54 00:11:59,000 --> 00:12:13,000 Carl: again, something we talked about is, uh... we referenced this earlier 'cause, uh, this is a Pointmanders project, and they released a, a charter a couple of months ago, listing this as a project they were gonna be pursuing. But they've, uh, announced something. 55 00:12:13,000 --> 00:12:39,000 Carl: - Pointmanders Glyph is a typography engine for web graphics. So, like, we're doing text rendering in WebGL, and generally in, you know, graphics pipelines is actually pretty complicated because of the way, like, sub-pixel grouping and, like, kerning and... I don't know. Actually, typography is an- typography and typesetting is an absolutely insane depth of, you know, complication. The closer you look at it, the weirder it gets. 56 00:12:39,000 --> 00:12:56,000 Carl: so writing a new one f- from scratch i- targeting a new environment is a huge undertaking, and they have announced one. Um, so that's pretty cool. I don't do very much WebGL stuff. But especially if you work on fancy landing pages, check this out 'cause it can make your text look better, probably. 57 00:12:56,000 --> 00:13:05,000 Carl: , yeah, Pointmanders does tons of WebGL stuff if you're not familiar with the name. So yeah, definitely h- I personally have a lot of trust for them in, in this domain. Looks pretty cool. 58 00:13:05,000 --> 00:13:28,000 Mark: I feel like I've been, we've been seeing an explosion of more React-alike or React knockoff or React variation libraries. We talked about one recently called Octane from Dominic Ganaway. That was essentially React, but it has to have a compiler, and it tries to clean up some of the rough edges, like hook dependencies. 59 00:13:28,000 --> 00:13:53,000 Mark: Dominic had also put out the TSRX, like, improved JSX syntax layer as well. There's a, there's a new React-alike called Vdact, which is also React with a compiler, but rather than having, like, the fiber runtime underneath, it acts more like Svelte and just compiles straight down to DOM manipulation code. 60 00:13:53,000 --> 00:14:14,000 Mark: Have not tried it, have not looked at it, but it has some examples on the front page of you write a React component with a useState hook, and it just gets directly compiled into, like, createElement div and DOM append calls immediately. So keep the friendly syntax, skip the runtime, and presumably things end up smaller. 61 00:14:14,000 --> 00:14:37,000 Mark: also, several months ago we had mentioned that Tanner Linsley wrote a post called Projecting React where he said, "I really don't need all the concurrency features that the React team has spent years building, and they're kind of making server-side rendering slow. What if I slop fork React to just rip out all the stuff I don't care about?" 62 00:14:37,000 --> 00:15:05,000 Mark: And so he said he had done it, and technically the source was available somewhere if you looked very carefully. The repo is now more actually available, and he's calling it Redact, so React with a letter D in the middle. It's still essentially like a you probably shouldn't use this, but it is there and the source is available, and it is on npm if people really want to use it. 63 00:15:05,000 --> 00:15:20,000 Mark: we're seeing a lot of people looking at React and saying, "Well, if this is kind of the default way to write apps today, but we don't like some of the behaviors or the syntax, what are some alternate ways we could rework this to fit our needs?" 64 00:15:20,000 --> 00:15:23,000 Carl: you know what? I, this was a late addition, but it's a new release. 65 00:15:23,000 --> 00:15:24,000 Carl: Uh, we have a new website. 66 00:15:24,000 --> 00:15:47,000 Carl: I threw it together. This is, you know, it's sloppy. I threw this to a new model just as, kind of to explore capabilities. I've been, I've literally been meaning to rebuild our website for years at this point, um, because I just, you know, jerry-rigged it into the existing infrastructure we had for Reactiflux, and that was not built for this. So it was not a good experience, and I knew that the entire time I've been doing this. 67 00:15:47,000 --> 00:16:01,000 Carl: so now we have a better one. It's, it's significantly better. Typography is way better. behavior of, you know, you can... Now we have a sidebar with all the links instead of them just being at the top, and if you click on one of them, it will jump the play ahead to the right time so you can start listening as you read. 68 00:16:01,000 --> 00:16:16,000 Carl: we've also got some link search, some topic search. It should just be... I, I have already used this website a few times for myself as I'm doing the documentation or, you know, prep notes, and like, "When did we talk about that?" hey, it's already useful for me. Uh, it's live. There's a couple things still broken. 69 00:16:16,000 --> 00:16:22,000 Carl: Please don't sign up for the newsletter, 'cause it doesn't work. I haven't set up a publishing flow, and you will get test emails if you do. Sorry. 70 00:16:22,000 --> 00:16:29,000 Carl: You know, I'm, I'm calling it slop because I used AI to make it, but it's better than that. You know, I put more effort than slop into it. 71 00:16:29,000 --> 00:16:31,000 Carl: yeah. Anyway, reasonably proud of that. 72 00:16:31,000 --> 00:16:46,000 Carl: we actually have a sponsor this month, I'm proud to announce. Yeah. If you have ever launched a full-stack React, Next.js, or Remix app on serverless hosting, you know the pain points. Cold start latency on that first request, and then out of nowhere, unpredictable bandwidth bill at the end of the month. 73 00:16:46,000 --> 00:17:03,000 Carl: Cloudways Velocity gives you fully managed, persistent Node.js and full-stack hosting built specifically for developer speed. Because it's running on always warm infrastructure, cold starts are off the table. You get seamless Git push deployments, zero downtime rollouts, built-in Cloudflare enterprise CDN, and enterprise security, all managed right from an intuitive UI. 74 00:17:03,000 --> 00:17:20,000 Carl: No configuring nginx, no SSH head-scratching, and most importantly, flat, predictable monthly pricing with no surprise bills. Stop overpaying for serverless spin-ups and stop wasting time on server administration. Go to cloudways.com/velocity, deploy your project in minutes, and experience how fast your apps should be running. 75 00:17:20,000 --> 00:17:32,000 Carl: , start your free trial, and you can use promo code CWREACT for 25% off your first month, exclusive to React to Flux. Yeah. Give it a shot if you're deploying a Next.js or full-stack React app. 76 00:17:32,000 --> 00:17:34,000 Carl: Okay, cool. Main content. 77 00:17:34,000 --> 00:17:37,000 Carl: There's a new React minor version, 19.3 78 00:17:37,000 --> 00:17:45,000 Mark: Nice. And this has a couple features that we have, as usual, talked about multiple times already, partly because they've been in Canary for a while. 79 00:17:45,000 --> 00:17:56,000 Mark: the first is official view transition support. There's now a new view transition component that is built in. once again, like I don't work with front-end code myself. 80 00:17:56,000 --> 00:18:26,000 Mark: I don't write view transition-y things. But this is a major new capability of the web platform as a whole, being able to do crossfades and a- other animations between parts of a page, separate pages, et cetera. It's built into the browser, but there's a bunch of nuance in how you set it up and how it works properly, and my understanding is, is that React's component is doing a lot of heavy lifting for you internally to be able to set all those up properly. 81 00:18:26,000 --> 00:18:43,000 Mark: if you look at the 19.3 release notes, there are a lot of examples in here on how you use the new component, how you specify different kind of animations, and apparently it also even integrates with Suspense as well. So that's a pretty major new feature. 82 00:18:43,000 --> 00:19:13,000 Mark: The other one is fragment refs, and this is another... This deals with a longstanding pain point in React where you could get refs to an individual DOM element. But let's say you have, like, a list component where there might not even be a parent, a single parent DOM node. It's just a flat list of children. There might not be anything to get a handle to. 83 00:19:13,000 --> 00:19:43,000 Mark: So fragment refs allow you to attach a ref to a fragment element in your component, and React essentially pretends that there is a fake synthetic parent wrapper around all the children and gives you the methods that you can call to interact with them just as if there were a real DOM element there. They've had to put a lot of work into this, and this definitely solves a gap in React's interop abilities. 84 00:19:43,000 --> 00:20:01,000 Mark: There's also a new feature called Browser. Anytime you're doing server-side rendling, rendering, you run into the problem of I have some code in a component, and the component gets rendered on both the client and the server, but this bit of code should only run on the browser. 85 00:20:01,000 --> 00:20:36,000 Mark: And so frameworks like Next.js have had their various, like, dynamic import or SSR Only or whatever other flags are in there to try to limit what logic runs in what environment. So there's now a new function called Browser in React DOM, and you call it and you pass the result to the Use hook. So it's Use, parentheses, Browser, parentheses, and that throws, that triggers suspense, and at that point, React on the server says, "Oh, I shouldn't actually render this. 86 00:20:36,000 --> 00:20:51,000 Mark: Leave the hole." And then when it gets to the client side, it runs again and says, "Ah, yes, this is client-side code. We will only actually run it there." So it's an official built-in solution, again, for something that people have needed to do for years 87 00:20:51,000 --> 00:20:55,000 Carl: Yeah, I like that. I like that a lot better than the, was it use server that was the, 88 00:20:55,000 --> 00:21:03,000 Mark: Use server and use client are bo-are both directives. This is a, a function that you import and call inside of a component 89 00:21:03,000 --> 00:21:15,000 Carl: I've been, like, casually whining about the use of directives for that and how I don't like directives because the, the whole thing with the use strict when we invented directives was just the one, no more. 90 00:21:15,000 --> 00:21:17,000 Mark: and then they proliferated 91 00:21:17,000 --> 00:21:26,000 Carl: and, like, this seems great. If you can just say this needs the browser APIs, then okay, if it doesn't say that, then you have free reign to assume that it might not have access to them, so cool. 92 00:21:26,000 --> 00:21:30,000 Carl: , that seems like a, you know, I love that. This seems like a big improvement to me 93 00:21:30,000 --> 00:21:50,000 Mark: One thing that's not listed in the release notes, but I, I saw some discussion somewhere on the R- React to Flux side, and it, it ties into the Preact thing. Bundle size. I don't have the hard numbers in front of me, but I saw some comments saying that 19.3 had a very significant jump in bundle size. 94 00:21:50,000 --> 00:22:15,000 Mark: And React DOM is already a very, very large library, and clearly the view transition support and fragment refs and, you know, whatever other bits they added add a s- it's just a significant amount of extra code. And that code is in React, and React itself is 100% untree shakable. It's all intertwined together. 95 00:22:15,000 --> 00:22:37,000 Mark: So your bundle is going to be getting the view transitions code whether or not you ever use a view transition in your app, and it keeps growing. And, you know, view transitions look like a very useful feature, but is anybody over there actually considering bundle size as an objective? I suspect not 96 00:22:37,000 --> 00:22:42,000 Carl: Sure. Do you know what the best site to check bundle size is anymore? It used to be Bundlephobia 97 00:22:42,000 --> 00:23:03,000 Mark: bundlejs.org. the problem with Bundlephobia and a couple of the others the npm and npmx websites just tell you how big is this on disk in node modules. Uh, Bundlephobia tries to figure out how big it is, but it's kind of simplistic in how it looks at the entry points. 98 00:23:03,000 --> 00:23:32,000 Mark: and right, and so, you know, like number one, if you, if you just look at React, React itself is the platform agnostic piece. It's React DOM that matters. And in React 19, they changed the entry point structure, so it's React DOM/client. So you have to specifically know that's what you're importing from, and then it's actually in like a third file inside of that. 99 00:23:32,000 --> 00:23:52,000 Mark: Bundlejs.org lets you explicitly write some snippets of code. So if you wanted to do like export create route from React DOM/client, it literally downloads the files and bundles them and tells you how big it is bundle size is 222K, 70K gzip 100 00:23:52,000 --> 00:24:00,000 Carl: There's also React Dev Tools, a new major version, version eight. I gotta say, this is, you know, surely this is just updating to match the latest 101 00:24:00,000 --> 00:24:20,000 Mark: they have actually been doing a fair amount of work on it. I believe the existing profiler tab is now deprecated or removed, and instead they're, they now better integrate with the performance tab that's built in. on the other hand, there's now a suspense debugging tab that is part of the dev tools. 102 00:24:20,000 --> 00:24:30,000 Mark: that's supposed to do actually some slightly time travel-ish things and show you like sort of a, a skeleton layout of the page and the suspense loading sections as they come in 103 00:24:30,000 --> 00:24:38,000 Carl: Love that. Yeah, I mean, the profiler and the performance features were great, but, it was a duplication. We had our own performance tab in the Chrome dev tools already 104 00:24:38,000 --> 00:24:50,000 Mark: I will point out that replay's time travel abilities in our MCP have some awesome React Performance Insights tools because I built them 105 00:24:50,000 --> 00:25:04,000 Carl: . Yeah. I'm looking at - the past releases for the Dev- React Dev Tools too. It looks like they're doing a major r- release about every year. Thereabouts the past couple years. Although, yeah, the, cadence of follow-up releases has definitely dropped in the last three or so. 106 00:25:04,000 --> 00:25:18,000 Carl: You know, I see version 5 and then 5.1, and then 5.2, 5.3, 6, 6.1, 6.2. But yeah, 7 just got a single patch release, and now we have 8. But hey, maybe that means it's settling down. It's stabilizing. 107 00:25:18,000 --> 00:25:25,000 Mark: And then a couple adjacent tidbits that are related to React Core, but not from the React team themselves. , 108 00:25:25,000 --> 00:25:52,000 Mark: there was an article on how the... You can now build a React app with a whole lot of Rust-based tools start to finish. A lot of that actually involves the React compiler having been slop forked to Rust by the React team, and then the other bundlers said, "Actually, even in its Rust form, it's kind of hard to integrate, so what if we then further fork and customize the integrations with our own tools?" 109 00:25:52,000 --> 00:26:10,000 Mark: And so, like the OXC people essentially h- now have their own variation of the React compiler that better integrates and runs faster. And so the article points out that you can use that and some Vite plugins and some other pieces to more efficiently build a React app start to finish. 110 00:26:10,000 --> 00:26:18,000 Mark: and then we've actually had some very interesting discussion going on in our very own #react-internals channel, a channel that I watch like a hawk. 111 00:26:18,000 --> 00:26:37,000 Mark: Last year I was really interested in the, this concurrent store API discussion that Jordan Eldridge from the Relay team was working on that was essentially supposed to be useSyncExternalStore, but Transition compatible. And then that whole effort stalled, for a whole variety of reasons. 112 00:26:37,000 --> 00:27:14,000 Mark: And just within the last couple weeks, a couple of community members, Xander and Justin, have been actively working on their own improved polyfill implementations of what this might look like, uh, and making some pretty significant progress on both. It's a long way from community members saying, "We've built a seemingly working version of this," to it ever actually landing in React itself, but I'm very truly hopeful that something like this will actually land in React at some point, because this is the missing piece that libraries like React Redux need to actually be properly Transition compatible. 113 00:27:14,000 --> 00:27:19,000 Mark: So I'm, I'm excited to see anybody putting effort into this right now 114 00:27:19,000 --> 00:27:20,000 Carl: Yeah, I love it. 115 00:27:20,000 --> 00:27:22,000 Carl: All right. Into the sad topics. 116 00:27:22,000 --> 00:27:23,000 Mark: Into the sad topics 117 00:27:23,000 --> 00:27:46,000 Carl: Dave Kiss put out a blog post titled A Eulogy for the Software Engineer. In loving memory of the software engineer, 1968 to 2026. a- I view this as slightly tongue-in-cheek. I think this is overstating it a fair bit. But yeah, you know, like, our profession is totally different here at the end of September as it was one year ago, you know? 118 00:27:46,000 --> 00:28:05,000 Carl: When I think back to what I was doing September of last year, I was pretty aggressively using AI agents for the first time. But I was doing it very much from a perspective of you know, watching it like a hawk, reviewing its code. We're using it as a more of a collaborator. a thing we've said in the past is, automation versus mech suit. 119 00:28:05,000 --> 00:28:23,000 Carl: You know, do you climb in and drive it, or is it let do its thing and check on the results of? And for me personally, it's definitely moved much more towards something I check the results of rather than reading all of its output. You know, d- having it, directly enable the code that I'm writing, per se. 120 00:28:23,000 --> 00:28:34,000 Carl: We also have the state of devs, from, uh, Devographics to talk about, so we c- if we do, we can put that into some greater context a little bit later. Eulogizing software engineers, though 121 00:28:34,000 --> 00:28:57,000 Mark: I mean, I, I wrote my own blog post, you know, on a, on a similar theme back in April, you know, detailing how I'd gone from the idea of hating AI to trying it, just over a year ago. It's actually been just over a year that I've been using AI to write code. And I, I am still very intentionally on, uh, if I understand the analogy right, the mech suit side. 122 00:28:57,000 --> 00:29:25,000 Mark: I'm the one doing the driving and it's improving my abilities. That is a very, very intentional choice that I'm making to limit myself to my context-switching ability and what I can keep in my own head. I will say that even within the last few weeks, I've noticed that I'm willing to let, my chat sessions be a little more autonomous. 123 00:29:25,000 --> 00:29:43,000 Mark: some of it's been the, "Hey, I need to go run errands for a couple hours. You have permission to actually, like, run a few more experiments and try some stuff out while I'm gone." And oh look, I'm, I'm getting work done while I'm running, running errands. It's great. but also I have more trust in the output. 124 00:29:43,000 --> 00:30:13,000 Mark: one of the biggest reasons why I was scared to use AI at all was because I considered it completely untrustworthy. I saw too many hallucinations. It's nondeterministic. I did not believe that you could safely build software with AI. And yeah, I, I completely watched it like a hawk. And The models keep getting better, and now that Opus 5.5 and Fable actually talk to you like a human again. 125 00:30:13,000 --> 00:30:42,000 Mark: Honestly, I have very few complaints about the code that is getting generated at this point. Like, could it be better architected? Probably a little. But it's perfectly readable. It's perfectly valid code. I've seen people write way worse c- I've written way worse code. It's more than good enough at this point. And it is still continuing to change how I actually do my job, and it's weird. 126 00:30:42,000 --> 00:31:07,000 Carl: I'm gonna pull in the next link too. Uh, Laurie Voss, who has been very influential at NPM a- for a long, long, long time, put out a post, "We are all product engineers now." And, you know, it's like, hey, you know what? Like, that's the title I've been claiming for four years now. there's a funny part of this new world that feels weirdly like it was built for the set of incentives that I encountered my entire career. 127 00:31:07,000 --> 00:31:41,000 Carl: . I'm thinking about, like, the code crafts people movement, and, you know, it's like, "No, we care about the craft of it. It has to be well-architected. It's gotta be, you know, this and this, the... It's about the process and not just the output." It's like, yeah. I'm gonna expand the scope of this for a moment. I tend to think of that kind of idea of, like, the craft of the work and the output of it as they're kind of inherently in tension. If you, If you want everything handcrafted and, you know, made with care and with a human's judgment and attention built into it, that's a lot of energy per unit. 128 00:31:41,000 --> 00:31:56,000 Carl: And if something takes a lot of energy per unit, it's more expensive. And if it's more expensive, it's less accessible to people who have less money. If you think about anything that you buy, there's that tension between handcrafted and mass-produced. Like- 129 00:31:56,000 --> 00:31:59,000 Mark: An Ikea table versus something from an Amish furniture store 130 00:31:59,000 --> 00:32:28,000 Carl: And, like, you're gonna pay more for the other one. So it's, you know, it's a tax on morals. It's a tax on values. Yes, I am personally someone who finds a lot of value in the way things are done. You know, the ends do not justify the means. The means have to justify themselves. but it's also true that I am someone who values making things accessible for more people, and the way you do that is by operationalizing, productionizing, reducing the per unit costs. 131 00:32:28,000 --> 00:33:00,000 Carl: And so, like, those are in tension. Those are naturally in tension. You can't have one without, you know, sacrificing the other. As we're eulogizing software engineering and, you know, the way things have been done, that's kind of the framework that I'm thinking about the next phase of this world we're in, is like, you know, yes, okay, it's an, it's... The craft is different. you know... Th- this is, analogous to, like, you know, full hand tools versus powered tools, electric tools. You know, are you using a battery-powered thing or are you spending your muscles to do it? 132 00:33:00,000 --> 00:33:05,000 Mark: which which from what I've read is still a massive argument topic in like the wood crafting communities 133 00:33:05,000 --> 00:33:29,000 Carl: Totally. Yeah, and you know, like I have this, right behind me here, I have a, you know, a whole toolbox full of all these hand, hand tools, whatever. Including, you know, I've got like a little drill, you know, a hand drill thing that you can put a little drill bit in and you just turn it yourself and s- but I also have a battery-powered drill, you know, for putting holes into things that that would just take too much energy for. 134 00:33:29,000 --> 00:33:42,000 Carl: That's how I'm thinking about this. you know, this We Are All Product Engineers Now i- from Laurie Voss is about y- you know, like the job of making software will become what the agents can't do. 135 00:33:42,000 --> 00:34:08,000 Carl: I think that is a really good articulation of, like, generally work. you know, it's about any work that you do, any work that I do is about finding a niche that I can do relatively better than anyone else. And so now if agents are able to do a lot of things pretty well, then that just affects the boundaries of what I should be looking at, you know? So, like, and I've said, I, you know, I- I... 136 00:34:08,000 --> 00:34:34,000 Carl: My point as we've talked about agents and this shift in the industry, my point has very consistently been around, like, asking questions of it. You know, it's, it's about communicating with your code, with your project, and setting the priorities and communicating intentions now more than actually the nuts and bolts, the, the, the bits and bobs of making it do the thing you intended it to do. 137 00:34:34,000 --> 00:34:43,000 Carl: Like, you know, now it's about how clearly can you articulate your intentions and how aligned are your intentions with the real world? Like, are... I- is it achievable? 138 00:34:43,000 --> 00:35:02,000 Mark: there's a lot of sense in which You can, like, you can go off and build any piece of software you want now essentially at the press of a button. It's more complicated than that, but if we assume that as a starting point, then it's a question of what are you trying to build? What are your intentions? 139 00:35:02,000 --> 00:35:32,000 Mark: How well do you understand what the end goal is and what things have to happen to get there? How well can you hand your agent the right context so it knows what you want to accomplish? How much time and effort have you put into defining the guardrails to make sure it doesn't do something stupid? And some kind of measurements that it can use to decide, you know, I've actually finished the job successfully. 140 00:35:32,000 --> 00:35:46,000 Mark: it's more about, I mean, constructing the systems that do the building, whether you're doing a w- a single chat conversation at a time, like me, or you're setting up, you know, entire automated software factories. 141 00:35:46,000 --> 00:35:55,000 Mark: I took great pride in the craft concept. I never lived up to it as much as I thought I should, but I tried to live up to it. 142 00:35:55,000 --> 00:36:07,000 Mark: I got huge amounts of satisfaction from spending hours beating my head against a problem and coming up with a really clever solution and jumping up and down and screaming, "It works, it works, it works." 143 00:36:07,000 --> 00:36:37,000 Mark: it saddens me that that's not the exact thing that I'm doing at this point in my career. But it's also really, really satisfying to say, "Okay, I had, you know, a set of work tasks and I cranked them out exceptionally quickly because I was just able to point my agent at it and say, 'Here's the problem I'm trying to solve. Here's how I want you to investigate it.' And it did the really hard stuff, and we came up with a solution, and then I said, 'Here's the next step.'" 144 00:36:37,000 --> 00:37:07,000 Mark: Or similarly, I have been massively productive in Redux work in the last two months. the useSignalSelector hook is an idea that I've had in my head for the last three years, and I'd only ever managed to do, like, two individual one-day explorations of it. And finally this spring, in between traveling to conferences, I said, "Okay, let's run a bunch of research tasks on 20 different signals libraries. 145 00:37:07,000 --> 00:37:33,000 Mark: We have architect, you know, docs describing how they work. Okay, read these, synthesize them, propose to me a possible implementation that does the thing that I want it to do." And then built a prototype and iterated and wrote tests and found edge cases and improved it and iterated. I literally did not have the time or mental capacity to do all that work by myself. 146 00:37:33,000 --> 00:37:56,000 Mark: the combined doc site is something that it's been asked for for years, and it just wasn't a priority for me because there was life going on. And over the course of a couple weeks I was able to say, "Okay," like I did actually technically do a prototype for this last year. Is this a viable solution? What would we have to do to productionize this? Do it for me. 147 00:37:56,000 --> 00:38:13,000 Mark: And it actually got like the bulk of it working in one session in the course of like three or four hours, partly 'cause it wasn't as hard as I thought it would be. But I mean, the agent then proposed most of the cleanup work that needed to be done, and at that point it's me telling it, "Okay, yes, do phase three, do phase four, do phase five." 148 00:38:13,000 --> 00:38:33,000 Mark: So like I truly do feel excited and empowered by this. Like I have cranked out things that I've wanted to do for years, and even if it wasn't me carefully crafting the lines of code, there is a lot of personal satisfaction in seeing that stuff come to life. So that's where I've landed 149 00:38:33,000 --> 00:38:48,000 Carl: Yeah. I agree. What Laurie says here about, They talk about what, what's next on the chopping block, what's possibly safe. And you know, what they say is possibly safe, deciding what to build in the first place, deciding the definition of good and making it delightful. And like, yeah, you know what? 150 00:38:48,000 --> 00:39:05,000 Carl: Like, those are matters of taste. And, like, a thing that I think that we keep saying in this podcast, I keep saying it generally, is that, like, AI fundamentally has no taste. It is designed to enable people to offload cognitive tasks into something that, can do base cognitive work. 151 00:39:05,000 --> 00:39:22,000 Carl: It has no way of judging whether its own work is good. It can determine whether it passes objective metrics and whether it meets these clearly defined requirements. But if you give it, if you ask it to define what good is, it can't do it. It can't do it in the way that you or I would. 152 00:39:22,000 --> 00:39:25,000 Mark: it's how we get purple backgrounds and gradients 153 00:39:25,000 --> 00:39:48,000 Carl: Right. Right. And but, like, you know what else cannot, fundamentally is unable to determine a y- workable definition of good is, like, a corporation, a large team, you know, a committee. To me, all of the same criticisms being leveled about AI outputs rhyme very closely with things like, designed by committee. " what's a zebra? It's a horse designed by a committee." 154 00:39:48,000 --> 00:40:20,000 Carl: if, that aspect of productive work, the, you know, validation on outside objective metrics, like, that's what a corporation is really good at. Like, you just throw bodies at it, throw minds at it, to handle all of these incremental cognitive tasks of deciding what needs to be made, making it, figuring out what metrics you judge it by, recruiting people to evaluate it, and then synthesizing their feedback into, you know, a response of, "does this meet their requirements?" 155 00:40:20,000 --> 00:40:35,000 Carl: They don't require taste to successfully execute, which is, you know, like, that's the stereotype of a, like, you know, the indie versus corporate. You know, the, like, artist versus sellout. This is a force multiplier in those - comparisons. 156 00:40:35,000 --> 00:40:59,000 Carl: This is easily 100X. You know, now you don't have to hire 100 people. You just, you know, give five people a large token budget. To me, it's fundamentally approximately the same thing. So I, I don't know. That's Not to diminish the disruption and the change, but I don't think it's quite as, like, fundamental as a lot of people believe it to be. 157 00:40:59,000 --> 00:41:00,000 Mark: Yep 158 00:40:59,000 --> 00:41:25,000 Mark: So tossing in the, the additional relevant links we've got here. Thorsten Ball, who's part of the AMP Code Agent team, put up his thoughts on where software engineering is going. Some of these I definitely agree with, like code review is in the form we've known it, is probably going away. He also thinks unit tests and, and terminals and shells will go away. Those I'm, I'm less convinced on. But, it's a good set of thinking on the direction. 159 00:41:25,000 --> 00:41:38,000 Mark: Brooks Lybrand from the Remix and React Router teams put up a sort of similar themed post on do frameworks even matter anymore? And some of it's the usual, like, okay, React won. 160 00:41:38,000 --> 00:41:56,000 Mark: Some of it is, well, if agents can crank out code, does it really matter what the code is if no one's really even looking at it in the first place? And then a couple of discussions from social media. 161 00:41:56,000 --> 00:42:10,000 Mark: Francois Best, who is the maintainer of the Nuxt URL State Library, put up a tweet where he said he's been feeling kind of burned out, and how do you actually keep doing this when nobody cares and all you're getting as issues is agent slop? 162 00:42:10,000 --> 00:42:23,000 Mark: I definitely feel this one. We've been getting a lot more slop issues and PRs filed on the Redux repos, just within the last couple months. And so I've, I've definitely been feeling some of that myself as well. 163 00:42:23,000 --> 00:43:03,000 Mark: And then Sebastian Lorber, our former co-host here on the podcast, also put up a tweet asking, like, why would you even spend time building software for others when anyone can have their agent just crank out code for themselves? And I actually replied to Francois with kind of my own thoughts. At this point, like for me personally, especially on the Redux side of things, it's really about responsibility. I took on the mantle of Redux maintainer 10 plus years ago. I'm the one who's put the responsibility on myself for doing all the work and keeping things up to date. 164 00:43:03,000 --> 00:43:35,000 Mark: AI does not take that off my shoulders, and in fact, I've managed to make a whole lot more work for myself within the last couple months. But I plan on doing this for quite a long time. Redux usage is going down by market share. Absolute numbers up, percentage down. So honestly, I have no idea how many people will care if I improve the docs, if I ship a new API, but someone will get benefit out of the work that I'm doing. 165 00:43:35,000 --> 00:43:59,000 Mark: I actually talked to some folks from large companies at conferences just the last week who are using Redux toolkit in giant monorepos, and it's like, "Yay, my stuff's being used in production. This makes me feel good." so I may not be getting a lot of direct feedback, but someone will benefit from the work that I'm doing, and so I'm going to keep doing my thing even if not as many people care. 166 00:43:59,000 --> 00:44:00,000 Carl: Yeah. 167 00:43:59,000 --> 00:44:20,000 Carl: I'm having some kind of reaction to this quote from Sebastian, uh, "What motivates you to build software for others anymore?" I think about it, like, a huge number of very successful open source projects were not made for others. It's somebody scratching their own itch, and then they posted about it, and other people went, "Oh, I have that itch too." 168 00:44:20,000 --> 00:44:41,000 Carl: You know? So it's like a lot of the best, most impactful open source was not made in that way. It was not for someone else. Nobody was, like, doing user interviews to uncover pain points. It's just like, "No, I'm doing this work. I believe in myself. I believe this is valuable because it's valuable to me. I'm just gonna publish it and see what comes out of that." 169 00:44:41,000 --> 00:44:51,000 Carl: And then, you know, over time it's become more and more reliable, or, uh, relied upon rather. The flip side of scratch your own itch and maybe other people have it is, like, maybe they don't. 170 00:44:51,000 --> 00:45:08,000 Carl: Maybe the way that you're scratching that itch is, like, way more complicated than it needed to be and, you know, some, or somebody else already made a, a back scratcher and you just never looked for it, you know? Like, I run into that a lot. I reach for making my own thing before I do research into what others have made a little bit too readily. 171 00:45:08,000 --> 00:45:32,000 Carl: So I don't know. That's Something about that framing made me really... And, like, how do you care when nobody else does? Like, I don't know. Sorry, but, like, that's fucking life. I don't know. some part of me bristles a little bit, just like . It gets my hackles up a little bit when people are talking about, like, pushing through motivation and pushing through, like, being ignored, and it's like, I don't know, that's just been my life. I've never had an, never felt like I had an audience. 172 00:45:32,000 --> 00:45:47,000 Carl: I never felt like people were interested in what I was doing and I never had validation. I just kinda kept doing it for my own reasons. So, like, okay are you having to explore and find self-motivation for the first time versus validation from others? 173 00:45:47,000 --> 00:46:00,000 Carl: like, yeah, sure, validation from others is very nice. We are very social creatures. But also, like, I don't know, believe in yourself. Some confidence that what you're doing is valuable. Like, uh, intrinsic motivation is way more durable than extrinsic motivation. so yeah, I don't know. 174 00:46:00,000 --> 00:46:04,000 Carl: This feels very related. thank you Dogpaw Hat for reminding me. 175 00:46:04,000 --> 00:46:12,000 Carl: there was an AI policy.dev website put together. I saw this when it was launched. I saw who had contributed to it and I am not... 176 00:46:12,000 --> 00:46:16,000 Mark: I believe it's from, uh, James and some of the E18E folks 177 00:46:16,000 --> 00:46:32,000 Carl: Yeah. E18e, uh, Daniel Roe and James Garbutt, both of whom are lovely people, really phenomenally thoughtful contributors, I think. Um, so th- yeah, so this is a, an attempt at, a generally useful AI policy for open source maintainers. 178 00:46:32,000 --> 00:46:53,000 Mark: The comparison I would make is it, it's kinda like pre-made software licenses, just like the GPL and the MIT are pre-written ways to say, "Here's how you are legally allowed to use my code.", this is an attempt to predefine possible ways that you might accept or disallow AI-powered contributions to an open source project 179 00:46:53,000 --> 00:47:19,000 Carl: Yes. and there are four policies right now. AI allowed, which permits generated code, written text, agent submission, agent PRs. Human voice, it requires the communicative text should be human authored. AI can help you, but it must never speak or think for you. Then human responsible, which drops that a little bit more. How you made it is y- your business, but everything you submit, you own, you are responsible for. And then just AI disallowed, nothing at all. 180 00:47:19,000 --> 00:47:27,000 Carl: I'm thinking about where I fall on this, and I'm full-ass AI allowed. I don't write my own PRs, I don't write my own commit descriptions anymore. 181 00:47:27,000 --> 00:47:32,000 Carl: I don't review the code in depth, and it, so far that's been working out, out pretty well for me. 182 00:47:32,000 --> 00:47:53,000 Mark: I've been right on the edge, this actually ties to what I was saying in the, in the last, you know, the last couple months of both day job and Redux work. I've got a standing rule that my agent should not do any Git commits without explicit permission, and I have been allowing it to do some commits for, like, some long-running tooling migration tasks or some other things. 183 00:47:53,000 --> 00:48:07,000 Mark: I have also not generally allowed my agent to open up any PRs directly. I have allowed it to do a few, especially, like, some one-off little quick, configuration fix PRs to the Redux repos. 184 00:48:07,000 --> 00:48:20,000 Mark: Uh, other times I've said, "Okay, give me a PR description," and then sometimes I've still written my own bullet points and then put a separator and then pasted, "And here's the agent," blob. 185 00:48:20,000 --> 00:48:42,000 Mark: But also there's been some times when I've just pasted the agent blob in directly. And so, like, I'm, I'm right on the edge of, well, I didn't write this, but, like, the text is readable and it covers things, and is it worth my effort to actually write it up by hand right now? 186 00:48:42,000 --> 00:48:46,000 Mark: So like I'm, I'm, I'm, I'm right on the edge of, how I want to use that there. 187 00:48:46,000 --> 00:49:06,000 Carl: Yeah. There's a part of me that thinks that I think some people will receive this as, you know, insulting or mean, so which is why I pause. But, um, there's a part of me that feels like if you're getting low-quality slop contributions in PRs and issues, then your contribution guidelines are insufficient. 188 00:49:06,000 --> 00:49:39,000 Carl: Okay, in eulogizing the software engineer, I think that we miss that software engineering has never been a very mature field. Like, I've said this over the years in this podcast once or twice at least of, in other fields, if you have a professional engineering certification, you know, if you go that extra mile, you do all the school, you do the work as a, an engineer, an electrical engineer, a mechanical engineer, an aerospace engineer, um, a structural engineer, and you become a, you know, capital P-E professional engineer, then you are asked to sign off on designs. 189 00:49:39,000 --> 00:50:00,000 Carl: And if those designs are deficient, if, you know, there's a failure, a design failure, then you are personally liable. Like, if people die, you are held culpable for their death. And, like, we don't do anything like that in software engineering. Like, there is absolutely no level of accountability in our field comparable to that in physical engineering fields. 190 00:50:00,000 --> 00:50:08,000 Carl: And so, like, okay, sure, software engineering as we understand it is dying, you know, quote-unquote dying. it was never really that 191 00:50:08,000 --> 00:50:33,000 Carl: mature. It was never-- We, we never held ourselves to the same pan- standards as other engineering fields. And in some ways, I think what we're looking at right now is going to enable us to do that, because it's, you know, like if, if you're reviewing a million lines of code, like, there is absolutely no way you can individually, as a, a single human person, say, "This will not have any defects." 192 00:50:33,000 --> 00:50:57,000 Carl: Like, that's just not possible structurally. No way. And now it's much more possible. Talking about reviews, you know, I-- So I just submitted a PR it's one of the only projects I'm actually collaborating with others on at this point, to say that a lot of my opinions are based on, like, you know, the true, like, AI psychosis perspective of I'm not working with anyone else, and so nobody else's perspective matters but my own, except for this one, where I am collaborating with others. 193 00:50:57,000 --> 00:51:24,000 Carl: I opened a PR. Somebody else reviewed it, uh, left a bunch of notes, you know, with their agent. Their agent left a bunch of notes, and that made me go, "Ah, you know what? I didn't actually really do my diligence on reviewing this." So then I set a goal. You know, I opened a Claude, and I said, goal, like, "Fix all of these review notes, and then do a clean room review in a, you know, very p-powerful frontier model sub-agent." then- Do it again. 194 00:51:24,000 --> 00:51:38,000 Carl: Do that in a loop until our powerful clean room review sub-agent gives us a passing grade. And it did that five different times. It fixed all the things, did a review, fixed all the things, did a review, fixed all the things, did a review, and then it gave us a passing grade. And I, I actually did review that code to just be like, 195 00:51:38,000 --> 00:52:02,000 Carl: "Okay, is this like... Did it go down a f- like psychosis rabbit hole and invented a bunch of bullshit? Or did it actually do meaningful work?" And it did meaningful work. And it was a bunch, you know, it's, it's stuff like w- there were caching issues, and, you know, like we had tried to configure this with a fetch wrapper so that you could intercept, you know, network requests being made for auditability of what behaviors it's doing and things. 196 00:52:02,000 --> 00:52:26,000 Carl: And like, oops, that didn't get put to 100% of use cases, it was only on these 20% of call sites. And so I just by doing that cycle, that one single line goal of just do a loop, do a review and fix it, do a review and fix it, got it to a state that was much better. That's, that to me is enabling a greater degree of like confidence in the engineering 197 00:52:26,000 --> 00:52:55,000 Mark: I have two similar but different but similar anecdotes. One was I, I tried writing my own code review bot at work, because I didn't wanna sign up for, like, a CodeRabbit or a Codo, you know, existing commercial solution. built something and it works, and I was down to the point of trying out different models at different price points to see whether they actually found all the bugs in a set of examples, and also how long they took and how much they cost, and then I, I got busy with other things and I never merged it. 198 00:52:55,000 --> 00:53:18,000 Mark: But yeah, like I... getting stuck in a loop and, like, every time it comes up with five new issues was a thing that I saw, and like, do, do you put in a cutoff at some point and say, like, "After three rounds we just don't try again" or something?, so that was one part. But then the other one was I use a, an open source third party web UI for OpenCode. 199 00:53:18,000 --> 00:53:40,000 Mark: So OpenCode is the agent, but I don't use the terminal UI, I use a, a web UI. And, it's called Code Nomad, and OpenCode version two just came out, and so the third party UIs were having to update themselves to work with the new back end. I tried it, it worked. There were some glitches in the, in the UI in the new version, and so I had my agent take a look. 200 00:53:40,000 --> 00:54:06,000 Mark: I filed four PRs to fix some glitches in the UI. Whoever is building this UI is doing all their work agentically, and so not only in the feature development, but then the PRs are all being agent-reviewed. And so I filed four little PRs and I thought that was the end of it, and they all came back with, "Well, have you considered X, Y, and Z? And this is a blocker." 201 00:54:06,000 --> 00:54:29,000 Mark: And I don't wanna read none of that. And so I just went back to the, went back to the a- my agent session and said, "Read the comments and fix the problems." And we went back and forth on that, like, three times, and I was essentially not involved in this loop other than telling my agent, "Reread the latest comments and fix whatever it's complaining about." 202 00:54:29,000 --> 00:54:37,000 Mark: And eventually we got to the point where his agent was satisfied and they got merged. And it's like, was I actually a necessary part of this process? 203 00:54:37,000 --> 00:54:53,000 Carl: but like, has that not happened to you earlier in your career, like with somebody else on your team on a, you know, on a PR? It's like you, you know, you post a PR, they review it, you fix the issues, they review it, and then go like, "No, I'm not happy still." You fix the issues and 204 00:54:53,000 --> 00:54:57,000 Mark: Yeah, but at least there I was actually thinking about what I was doing, and here I wasn't. 205 00:54:57,000 --> 00:55:19,000 Carl: Sure, but you know, also, like, okay, but reframe that when they're wrong. Reframe that when they're arguing over st- points of style and technique and not actual, you know, resulting impact on the outcome. Like, I don't know. I go both ways on it. Like, to me that reminds me a little bit of the, when Prettier was introduced, and it was like, "Oh, we have to do our style by hand." 206 00:55:19,000 --> 00:55:25,000 Carl: And I'm like, "No, I don't care. This eliminates a class of arguments." You know? And 207 00:55:25,000 --> 00:55:27,000 Mark: I hate that this analogy works 208 00:55:27,000 --> 00:55:37,000 Carl: Right? If you open a PR and the title says it does this, and you review it, and actually the title is inaccurate, then you have to make a judgment call of do we update the title or do we affect the PR scope? 209 00:55:37,000 --> 00:56:05,000 Carl: You know? And like that judgment call is still yours to make. Like you were saying. You know, what, uh, do we kill it after three reviews, or do we add a, a, a different type of gate that's based on scope evaluation? You know? So like, to me it's, it's just, I love it. But also, you know, like, like I was saying, I have identified as a product engineer for multiple, multiple years at this point. So like, yeah, sure, of course I do. That's what we're all being forced to do right now. 210 00:56:05,000 --> 00:56:07,000 Carl: Okay, loosely structured shenanigans. 211 00:56:07,000 --> 00:56:15,000 Carl: One more from Laurie Voss. Let's move on. "Nobody pays for open source. We could force them to." Uh, eh. 212 00:56:15,000 --> 00:56:37,000 Mark: So the argument here is that sponsorships and volunteer payments have never worked out sufficiently at scale. The only way that we would ever get, like, a, quote, "meaningful amount of money" flowing to open source maintainers would be if the registries themselves start charging companies and just redistributing the money automatically. 213 00:56:37,000 --> 00:56:57,000 Mark: there's already third-party tools like TideLift and Thanks.dev which have the same logic, but it's still from voluntary donations. So what would happen if NPM itself just said, "Yep, if you wanna use NPM, you gotta pay up if you're a big company," and then they just automatically send that out. 214 00:56:57,000 --> 00:57:16,000 Carl: Yeah, I don't know. That is truly one of the only levers that could, that could work. I'm not sure it would. I'm not sure that companies acknowledge the, you know, long tail of value available there. I thought a lot about this a, a long time ago. I haven't thought about it in depth in a number of years. 215 00:57:16,000 --> 00:57:37,000 Carl: If forcing people to pay for something i- en masse is what taxes are for. Like, oh, no, do we have a tragedy of the common situation where the money being invested is not being adequately directed to support that common good? That's what taxes are for. But, like, nobody has authority, 216 00:57:37,000 --> 00:57:40,000 Mark: this is third-party taxes for the good of the community 217 00:57:40,000 --> 00:57:56,000 Carl: Right. And like, taxes only work when it's a regionally, you know, geographically based thing, because that's how governments work, is they control a geographic area and they say, "No, you are physically in the space that we control, and so you must do what we say in these ways, and we will respect your rights in these ways." 218 00:57:56,000 --> 00:58:03,000 Carl: there is No, government for the internet. There is no one who can institute taxes. there are registries it's true, but yeah, I 219 00:58:03,000 --> 00:58:14,000 Mark: I'm not saying that, like, this... Like, I acknowledge this is probably never going to happen, but I agree that if it i- if it would ever theoretically happen, I think doing it at the registry level is probably the, the only way it would 220 00:58:14,000 --> 00:58:17,000 Carl: I would agree. I, uh, the reason that I challenge that it would 221 00:58:17,000 --> 00:58:34,000 Carl: be effective is, okay, some registry locks itself down and says, "You must pay for access. We've put up a firm paywall." One person, one jackass, is gonna pay for it, break the whole archive, and then republish it for free. Like, that's how it works. 222 00:58:34,000 --> 00:58:49,000 Carl: It'll be on BitTorrent in 24 hours. So then it's no longer gated, and it's, you know, free again. ultimately, the way you stop that is law enforcement. Now, we don't have that for the internet. - That doesn't exist. So yeah, I don't know. 223 00:58:49,000 --> 00:59:15,000 Carl: I, want that to work. I don't think it does in practice, you know? There's a Calvin and Hobbes strip that I love to reference, which is, you know, his mom yells at him from the other room, "Stop running around the house." And he pauses and looks at camera and says, "The law is on the books, but it would take All of their resources to enforce it." and continues running. Calvin. And like, yeah, you can put a law on the books, but who's gonna make it happen? Who's gonna make it real? Who's gonna enforce it? 224 00:59:15,000 --> 00:59:19,000 Carl: Okay. I said we were gonna blast through this and then immediately failed 225 00:59:19,000 --> 00:59:36,000 Mark: at that. 226 00:59:36,000 --> 00:59:43,000 Mark: Rolling through things. Uh, if you haven't been hearing what's going on with OpenAI and Anthropic and swarms of agents going off and proceeding to use random internet message boards a- and artifactory hacks as, message boards, you should read these articles because frankly, this is pretty scary stuff actually. 227 00:59:43,000 --> 00:59:47,000 Mark: , and it's probably only going to get worse from here 228 00:59:47,000 --> 00:59:48,000 Carl: True. 229 00:59:48,000 --> 00:59:56,000 Carl: I'm including this in part because it was written by a Reactiflux member, and I just love it when people who are active and involved in Reactiflux are doing other things in the real world. 230 00:59:56,000 --> 00:59:58,000 Mark: Redux maintainer 231 00:59:58,000 --> 01:00:14,000 Carl: yeah. EskimoJo put out s- uh, an update for schemabenchmarks.dev, uh, which is seven months after the initial, you know, project kickoff, uh, trying to do performance benchmarking of different schema validation, you know, tools. 232 01:00:14,000 --> 01:00:37,000 Carl: And love that. That's great. Schemas are, especially, as I've been doing more and more AI shit, I've been really, really appreciating the deep abiding value of a quality schema. More and more I'm seeing why you need to have schemas literally everywhere, which means that having high-performing schemas available is really important, and so this is a really valuable project. schemabenchmarks.dev. Love it. 233 01:00:37,000 --> 01:00:54,000 Carl: little bit on State of Devs 2026. I don't know, this is kind of what we're talking about, this whole episode is, is the state of the devs, uh, where at least, you know, me and Mark are devs. It's kinda interesting looking at this. This is, you know, this is a look at the human side of things. 234 01:00:54,000 --> 01:01:09,000 Carl: , the demographic surveys are very often like, "What technologies are you using? You know, what are you interested in? What are you familiar with, and what would you choose not to use again?" But this one, you know, the headings are just workplace, AI, health, worldview, hobbies. 235 01:01:09,000 --> 01:01:11,000 Carl: So that's, that's interesting. 236 01:01:11,000 --> 01:01:28,000 Carl: This is, this is actually... This, they've kind of evolved into a sort of general, general purpose poll here. Like, worldview is, you know, global issues. 73% of US respondents cited rising authoritarianism as a concern, Which is not really... You know, that's not technical. It's true. But yeah, so this talks... 237 01:01:28,000 --> 01:01:51,000 Carl: this is a sort of a data-driven... This is a quantitative look at some of the things that we've been applying a qualitative perspective on. Definitely broadly interesting. Let me pull in some AI. You know, the median respondent is using AI to generate 63% of their code. The median opinion on AI sentiment is exactly neutral. 238 01:01:51,000 --> 01:01:52,000 Carl: It's 50%. 239 01:01:52,000 --> 01:01:54,000 Mark: means everybody hates it or loves it 240 01:01:54,000 --> 01:02:05,000 Carl: Yeah, right. A lot of this is very, like, smack dab in the middle. Like AI mental state, uh, AI tools have had a positive impact on my mental state. The median response 241 01:02:05,000 --> 01:02:19,000 Carl: is a two That's actually interesting. It says median is two, but, looking at this, 45% said strongly disagree, or just regular disagree, compared to only 23% who agreed or strongly agreed. 242 01:02:19,000 --> 01:02:41,000 Carl: So the median is smack in the middle, but actually, you know, the average, I think, would be a bit below. so yeah, I don't know. That's interesting to me because AI tools have had a pretty strongly positive impact on my mental health, I think. Maybe that's just, like, a measure of how serious my ADHD is. Like, I have so many ideas and now I can just put some of it, some of those thoughts into a robot. But yeah. 243 01:02:41,000 --> 01:02:50,000 Carl: State of Devs has some interesting stuff on worldview and health and hobbies. Yeah. You can see where your, your choices in life relate to the average developer. 244 01:02:50,000 --> 01:02:54,000 Carl: Okay, this is a tweet from Reece Sullivan, who i- I find very impressive. 245 01:02:54,000 --> 01:03:18,000 Carl: I talked to him, uh, four or five years ago when he was doing some Discord projects, and I've just, like, watched him meteorically ascend into being somebody with real projects and real, you know, audience and whatever, and I love it. Love that for him. He posted some quick miscellaneous thoughts about why MCP is so much better than CLIs, which I found interesting because I have voiced the exact opposite opinion in this podcast several times. 246 01:03:18,000 --> 01:03:34,000 Carl: So seeing somebody that I pretty highly respect on a technical level, well, both technical and product, because I've seen him choose interesting things to work on and then successfully execute them. Seeing him take such a strong stance in opposition to the one I have makes me think. But yeah. 247 01:03:34,000 --> 01:04:05,000 Carl: His argument here is, uh, that MCP is better because it has indexable tool catalogs, letting agents scale, no requirements for a sandbox, consistent auth, multi-account support, things like that. Those are fairly strong arguments. but also, I don't know, there's a... The way that I've been using AI lately most aggressively has been trying to give it a s- bunch of tools that it can compose together, which relates to something I saw from Cloudflare a, a while back about code mode for 248 01:04:05,000 --> 01:04:34,000 Mark: O- open, op- OpenCode V2 ha- has code mode built in. That's one of the reasons I upgraded. And, in fact, it, that might be the only way that agents can make MCP calls in, in V2. So, like, it might still only just do, you know, return one call, but I have seen it doing multiple calls in parallel and returning the results or doing some filtering, you know, writing little mini scripts to further alter the results when it gets back. 249 01:04:34,000 --> 01:04:37,000 Mark: it feels like a useful step forward in the abstraction 250 01:04:37,000 --> 01:04:49,000 Carl: Yeah. And so my opinions as I've been playing with these are that where I think it's gonna really end up is, I think relating into like JEV and stuff... The code mode is really interesting. 251 01:04:49,000 --> 01:05:05,000 Carl: I still am so skeptical about MCP specifically, just like some of its other constraints, i, I'm, I'm not a fan yet. code mode is really interesting. That's very much aligned with how I've been using agents to play this little space game that I have been talking about now and again. 252 01:05:05,000 --> 01:05:20,000 Carl: I just totally rearchitected their whole harness in order to do this. They have one tool, and it's run, and they give it code to run, and then it type checks that code, and if it, you know, passes All the validation, then it will actually run it. Otherwise, it'll kick it back to the agent to rewrite. 253 01:05:20,000 --> 01:05:37,000 Carl: And so I think there's something really powerful there about stuff like JEV, which is doing decision-making, but not code generation or text generation. Highly constrained code inputs for actually interacting with things rather than just doing individual tool calls the way that a lot of people have been the last year. 254 01:05:37,000 --> 01:05:43,000 Carl: And then just, yeah, I don't know. That's really interesting. I'm still skeptical about MCP, but this does make me reconsider some of it. 255 01:05:43,000 --> 01:06:04,000 Mark: All right, I've said a number of times that I think Ryan Carniato is the deepest thinker we have in the front-end ecosystem in terms of architecture and async behavior and how all these pieces fit together. And he's also a huge.. He's really big on the history of how did the ecosystem evolve to where we got here. 256 01:06:04,000 --> 01:06:26,000 Mark: And so he put up a post that he calls The Grand Unifying Architecture of Front End, where he says that front-end framework responsibilities ultimately come down to some combination of navigation on the client, content from the server, and how things f- fit together on the client for things like local UI or optimistic updates. 257 01:06:26,000 --> 01:06:52,000 Mark: And every framework is, can essentially be fitted on a grid to figure out where it fits in amongst these pieces. Uh, I mean, nothing in the article is going to, like, change how you write code today, but it does help visualize different frameworks from Svelte to React to, you know, whatever else, and say these are all just taking different trade-offs in the same space. 258 01:06:52,000 --> 01:07:25,000 Mark: And then completely separately, we've talked about a lot of different LLM-related things. Simon Willison is a one-stop go-to person for what are the latest developments going on, and he did a whole presentation on 2026 in LLMs so far that is pretty comprehensive. His blog is worth subscribing to just for the daily updates on the latest news in the ecosystem, and this one presentation is a pretty comprehensive look at how much stuff has changed just this year 259 01:07:25,000 --> 01:07:35,000 Carl: Yeah. that is an interesting retrospective. I appreciate that. It's wild to think that Claude Opus 4.5 launched less than a year ago, that that alone had such a big impact on how I authored code. 260 01:07:35,000 --> 01:08:00,000 Mark: All right, and then the last couple, a couple bits of React Native news. Shout out to both Sebastian and Mo, who are not here. Shopify is s- announced that they are pulling an Airbnb and are switching away from React Native for their primary apps, largely on the grounds that they can now just have AI generate Swift and Kotlin code and be building native apps directly. 261 01:08:00,000 --> 01:08:07,000 Mark: So they tried it, they prototyped it, they feel that the apps ended up faster, and so they're dropping React Native. 262 01:08:07,000 --> 01:08:23,000 Mark: On the other hand, Discord put up an article saying that they had just finished migrating to the React Native new architecture, and it took some work, but they're generally seeing improved performance and other good things that the new architecture was supposed to provide. 263 01:08:23,000 --> 01:08:31,000 Mark: So two different takes on what are we doing with React Native from pretty big companies. 264 01:08:31,000 --> 01:08:34,000 Carl: All right. Wrapping up with a couple of conferences. 265 01:08:34,000 --> 01:08:39,000 Carl: we got React India at the end of October, so in about a month. Uh, October 266 01:08:39,000 --> 01:08:43,000 Mark: Yep, and I, I know about all three of these because I will be speaking at all three of these 267 01:08:43,000 --> 01:08:49,000 Carl: then there's React Summit in, uh, mid-November. That's gonna be in New York on, uh, November 17th. 268 01:08:49,000 --> 01:09:07,000 Carl: And then another couple weeks later, React Day Berlin, December 4th. I might have to see if I can get a ticket to React Summit. It's in my hometown. I don't know. E- each of these would be great. I would love to go to each of these, but I just don't think I can. I just bought a house. I can't spend $1,000 on conference tickets. Maybe if I was speaking. 269 01:09:07,000 --> 01:09:11,000 Mark: one of the major reasons why I enjoy speaking is I get to run around to these places. 270 01:09:11,000 --> 01:09:22,000 Carl: Right? Every so often I get, like, a press, you know, I'm a member of the ecosystem, but I, you know, that takes work to, uh, do that outreach, and I haven't put that work in in the last 18 months or so. 271 01:09:22,000 --> 01:09:52,000 Carl: Thank you everyone for joining us. Uh, we'll be back on the last Wednesday of the month here in the live stage at Reactiflux or back in your podcast feed just as soon as we can after that. if this is a show you get value from and wanna support, best way to do so is submitting a review wherever you listen. Tell your friends and coworkers about it. Maybe one day I'll get my shit together and post more little short clips so that people can, you know, retweet them and repost them, and that- that's really probably the single largest thing I could do to make this podcast more successful, but that takes continuous ongoing investment of energy, and energy is something I'm low on most of the time. 272 01:09:52,000 --> 01:09:53,000 Carl: Set 273 01:09:52,000 --> 01:09:54,000 Mark: up a Claw to do it for you! 274 01:09:54,000 --> 01:09:58,000 Carl: I thought about it, but, ugh, it's a matter of taste! You can't do that. It's not good at it. 275 01:09:58,000 --> 01:10:08,000 Carl: All right, cool. Thank you so much everyone who, uh, stuck around all through, all through the end of this. It's funny, I See a past manager of mine in the audience, which is cute. Cool. All right. Talk to you guys later. 276 01:10:08,000 --> 01:10:13,000 Mark: See you folks.