1
00:00:00,000 -->
00:00:13,000
Carl Vitullo: Thank you so much for joining us for the August edition of This Month in React as we recap what's going on with React, React Native, and generally on the web platform. We are coming to you live from Reactiflux, the place for professional developers using React.
2
00:00:13,000 -->
00:00:28,000
Carl Vitullo: I am Carl generally known as vcarl on the internet. I'm a staff product developer, freelance community leader, occasional entrepreneur, sometimes consultant here helping run Reactiflux. And generally just trying to keep this place valuable and pro-social for everyone around it.
3
00:00:28,000 -->
00:00:44,000
Mark Erikson: And I'm Mark. My day job is at Replay, where we've built a time traveling debugger and now an automated QA platform that uses t , the time travel awesomeness to help find bugs in your app. Replay QA, please check it out. And outside of that, I am still doing an awful lot of Redux stuff
4
00:00:44,000 -->
00:00:55,000
Carl Vitullo: Mm-hmm. Cool. Yeah August is often a slower month. A lot of Europe is on vacation. you know, kind of the end of summer. It's the start of school. So just often there's not as much going on.
5
00:00:55,000 -->
00:01:02,000
Carl Vitullo: We do have a lot of new releases or pre-releases, release candidates to talk about. Yeah. Let's get going.
6
00:01:02,000 -->
00:01:25,000
Carl Vitullo: First off on our new releases, we've got Waku 1.0 as a release candidate. Yeah. Waku, I don't know, I feel like I've been thinking of it and describing it as a new framework for server components, and I actually went back and checked how we've discussed it, and we've been discussing it for three years now. Like, three years is no longer a new tool, you know? But yeah, here we are at 1.0 with a release candidate.
7
00:01:25,000 -->
00:01:50,000
Mark Erikson: The, and, and, and to recap Waku is a React server components framework that's been built by Daishi Kato, who i- who is also the brains behind Zeustand and Voltio and Jotai, and a slew of other state management related libraries. And the goal is to be a minimal server components framework rather than something like the, the all-encompassing Next.js
8
00:01:50,000 -->
00:02:06,000
Carl Vitullo: Yeah. So cool. Love to see things get to release candidates. The fact that they've been driving towards 1.0 for so long makes me think, I don't know, makes me think this is being thoughtfully approached. Generally they, they, are very thoughtful, so that's very cool to see.
9
00:02:06,000 -->
00:02:16,000
Mark Erikson: It looks like they've, they've been doing some, some navigation fine-tuning and improvements, but other than that, it's mostly like we, we think we've got it close to being final soon
10
00:02:16,000 -->
00:02:37,000
Carl Vitullo: yeah, a- actually I'm gonna, I'm gonna put out a little call to audience, anyone listening. If you have, like, built something with Waku, I would actually love to hear about it. I don't think I know anyone personally who has, like, any kind of extensive experience. So, yeah, if you have any feedback, I'd love to hear about it in the #general-tech channel or, you know, shoot me an email to hello@reactiveflux.com. Just general curiosity.
11
00:02:37,000 -->
00:02:48,000
Mark Erikson: I was actually just wanting to try to look up download stats. Like, I've, I've seen it for a while. my general assumption is that it's not widely used, and certainly not in comparison to something like Next.js or React Router.
12
00:02:48,000 -->
00:03:01,000
Carl Vitullo: Yeah. on that, I just checked. It has 22,000 downloads per week which compares to, you know, TanStack React Query at 60 million n. So yeah, definitely on the smaller side yeah. Okay, moving on.
13
00:03:01,000 -->
00:03:23,000
Carl Vitullo: Another release candidate. We have Pre Act 11 coming out , the main thing they highlight is it's now tree shakable which is a claim that I always take with a pretty substantial helping of salt. Just never know. I don't know. There's so many ways to break tree shaking, and we've been... libraries have been working to be more tree shakable for, like, six, seven, eight years.
14
00:03:23,000 -->
00:03:39,000
Carl Vitullo: So, you know, I don't know. It's cool. Love that. That's great. I hope it works. But yeah, Preact is generally interesting. It's cool. Last month we were talking about React alikes, and Preact is definitely the original React alike, although it is increasingly less alike as time goes on.
15
00:03:39,000 -->
00:03:56,000
Mark Erikson: Yeah, although it do- it does say that the, the compat package now includes the several other React methods that have been added recently. So while the semantics have diverged somewhat over time, they are at least still making an effort to try to keep it relatively drop-in if possible.
16
00:03:56,000 -->
00:04:24,000
Mark Erikson: MobX 7 came out. it's funny because Mo- like MobX, I think technically was, like the first releases of it were actually a few weeks before Redux came out back in 2015. So MobX has been around for a while. MobX 7 is primarily a cleanup and modernization release. They've dropped the legacy implementation and now it now requires proxies to actually track things, which has always been the default behavior.
17
00:04:24,000 -->
00:04:32,000
Mark Erikson: Improved some bundle sizes, some tweaks to the, to the React bindings. So still out there and still being worked on
18
00:04:32,000 -->
00:04:46,000
Mark Erikson: And on a much bigger note Next 16.3 is out, and the, the Next team talked a lot about this release. they seem to feel this is one of the bigger releases they've done in quite a while.
19
00:04:46,000 -->
00:04:59,000
Mark Erikson: there's a bunch of dev improvements. It's supposed to build faster, less memory usage but it also has what, what they're calling instant navigations for s- better spa-like behavior as well
20
00:04:59,000 -->
00:05:20,000
Carl Vitullo: Well, yeah, I saw they, they had also done a AMA on Reddit. Although I, I, I read through a fair bit of it, and it was a lot of like, "Yeah, we're working on caching. Yeah, big sites are still hard." So I don't know. It it, it was good to check in. It was cool to see... You know, it was a lot of big names giving, you know, direct answers to questions, but um,
21
00:05:20,000 -->
00:05:22,000
Mark Erikson: There weren't a lot of great secrets revealed in that.
22
00:05:22,000 -->
00:05:41,000
Carl Vitullo: Right. Yeah. And it's just like it's been such a consistent through line for two or three years now of like, yes, caching is hard. Local development is hard, especially if you're dealing with, like, 100,000 pages being generated. So, you know, it's just like , the challenges and the stated improvements have a certain sameness to me over time for Next.
23
00:05:41,000 -->
00:05:47,000
Carl Vitullo: I'm su- You know, it does improve. It gets better. It, it... But, like, the challenges are still pretty similar.
24
00:05:47,000 -->
00:06:01,000
Mark Erikson: And, you know, may- maybe this is just a snide comment from the gallery from someone who doesn't even use Next at all, but it always... It, it's felt like a little bit of that complexity was sort of self-inflicted in a way
25
00:06:01,000 -->
00:06:24,000
Carl Vitullo: Right. Yeah. I think we have another thing to talk about later on. I can't remember what this got in the doc, but Lovable put out a blog post about moving away from Next to TanStack. And yeah, you know, it's, a, a lot of it is like, oh yeah, we had performance problems, and those performance problems got resolved by moving to Vercel, but we would, would like to have more optionality f- than in our hosting.
26
00:06:24,000 -->
00:06:50,000
Carl Vitullo: So, you know, it's, the same kind of complaints, and agreed that a lot of the complexity seems kinda self-inflicted. they keep trying to fix it by adding more complexity, it feels like. You know, it's, it's a continuous additive system, and the fact that they keep adding new things to try to address the problems, and the root problems being solved don't seem to be changing, makes me suspect that the, they have gone deep into the diminishing returns of additions.
27
00:06:50,000 -->
00:06:55,000
Carl Vitullo: I think it's perhaps time to subtract. But subtracting is usually a major version bump anyway.
28
00:06:55,000 -->
00:07:04,000
Carl Vitullo: Okay. We have a new React Native version 0.87. Man, I- every time we have got a release, I miss having Mo out here because
29
00:07:04,000 -->
00:07:05,000
Carl Vitullo: he
30
00:07:04,000 -->
00:07:06,000
Mark Erikson: was just about to say that
31
00:07:06,000 -->
00:07:47,000
Carl Vitullo: He's got such a good breadth. Maybe I should bring him on as an analyst or something like that. But yeah, the, the big highlight here looks, to me at least, looks to be that they now have a strict TypeScript API and type definitions are being actually generated rather than hand-authored. That's a huge... Going from hand-authored types to generated types is always a massive project. It looks like this has been in the works since about point or 0.80. So, you know, that's seven, seven releases now that they've been going towards it. So, their strict TypeScript API is now the default. Not everything will be compatible, so there's an opt-out, but they've stated the intention of this - you know, the, the opt-out going away over time.
32
00:07:47,000 -->
00:08:19,000
Mark Erikson: TanStack Table version nine is out, and I believe I, I, I know I'd at least pasted a couple of the prior blog posts in the tech reads and news channel. I don't remember if we actually linked them in the, in the podcast last month. Some of the updates they now have a increasingly wide range of adapters for different frameworks React, Preact, Vue, Solid, Svelte, Angular, Lit, Alpine, Ember and Octane. So pretty much anywhere you're using a framework you could use TanStack Table if you wanted to.
33
00:08:19,000 -->
00:08:34,000
Mark Erikson: They've made a whole lot of improvements to performance. They've pulled off some very nifty JavaScript tricks to try to cut down on memory usage rewritten the internal state management, improved type safety, and as we d- were just saying, things are more tree shakable.
34
00:08:34,000 -->
00:08:35,000
Mark Erikson: Wonderful
35
00:08:35,000 -->
00:08:57,000
Carl Vitullo: Wonderful. Yeah. Tables. Man, ugh. I love that, I love that TanStack has been so persistent at trying to make a good table abstraction, but I'm gonna be honest, I settled in, like, 2017 of saying, like, "Nope. There is no table abstraction worth its weight in the bundle. I'm gonna re- write every table from scratch," which has its own trade-offs.
36
00:08:57,000 -->
00:09:15,000
Carl Vitullo: You know, it's, it, then you have to copy functionality and stuff is missing. But, like, man, just, like, seeing this release talking about how they have, like, a new architecture that, y- you know, with a record number of framework adapters, it's just like, man, tables are so much more complex than we give them credit for.
37
00:09:15,000 -->
00:09:17,000
Carl Vitullo: It's so hard to make a good table
38
00:09:17,000 -->
00:09:19,000
Mark Erikson: But I thought coding was solved
39
00:09:19,000 -->
00:09:25,000
Carl Vitullo: Coding is? It's completely solved. , it gets more and more solved the less closely you look at the outputs.
40
00:09:25,000 -->
00:09:42,000
Mark Erikson: On a completely different note we've talked in the p- past about w- what was known as the records and tuples proposal for the JavaScript spec, which was supposed to add new data types to the language that were gonna be deeply immutable, and then you could just say, "Is this value equal to the other?"
41
00:09:42,000 -->
00:10:10,000
Mark Erikson: And the triple equals operator would do a deep comparison. That proposal eventually got withdrawn. It's dead, it's gone, it ain't happening. So there's now a new proposal called composites, which is sort of trying to solve the same problem, but in a very different way. Reading it, it looks like you create these wrapper objects, and then the wrapper objects will do the value comparisons for you, I think.
42
00:10:10,000 -->
00:10:21,000
Mark Erikson: So nothing immediately actionable here, but it, it is interesting to see that the design committee champions are still trying to figure out a valid solution for this problem
43
00:10:21,000 -->
00:10:39,000
Carl Vitullo: Yeah, that's interesting. Looks like it's kind of I'm looking at this example in the actual spec, the stage one draft spec basically wrapping an object in a composite constructor, and then, you know, you do the same object keys and values in two, and then do a triple equals comparison, and cool, they're equal.
44
00:10:39,000 -->
00:10:44,000
Carl Vitullo: Th- so that's awesome. That's interesting. That's useful. But yeah, stage one, that's pretty far away from released
45
00:10:44,000 -->
00:11:12,000
Mark Erikson: And then we've talked some previously about Solid 2.0 being on the way and having a major change in how it handles async, to how that's baked into the signals graph. They've officially hit release candidate this month. So there's the 2.0 RC announcement blog post but then there's also some deep dives that we'll touch on later that talk in more detail about how the async graph works and what that means for your code.
46
00:11:12,000 -->
00:11:37,000
Mark Erikson: I continue to say that, like, Ryan Carniato is probably doing some of the absolute deepest research into framework development and data modeling and how to build better tools than pretty much anyone else out there. Obviously the React team put a lot of thought into server components. The Next team's putting a lot of thought into, you know, building their framework.
47
00:11:37,000 -->
00:11:41,000
Mark Erikson: Ryan's doing, like, the bleeding edge research here
48
00:11:41,000 -->
00:12:14,000
Carl Vitullo: I love that, so the async lives in the graph is for one, just a great header. I love that as a thing to unpack and understand. But it's a, I, I wanna call out this little parenthetical that says, "A computation can return a promise, parentheses, or an async iterator." And man, a, promises versus async the iterator is just so much more powerful. So being able to support those, like, you know, it's a little aside because everyone knows and uses promises and those, you know, everyone assumes those. But man, I've been using async iterators more and more lately, and they're so powerful.
49
00:12:14,000 -->
00:12:34,000
Mark Erikson: I, I was, I was skimming through the third of the three explainer blog posts, and they fleshed that one out in more detail. And I think the example there shows a component that, like, looking at it, you almost wouldn't even know that it would get updates because it just works reading the data
50
00:12:34,000 -->
00:12:48,000
Carl Vitullo: Yeah. I've been using them mostly because I have been doing all of my code in effect the last couple of months, and, like, or everything is a generator. And generators can be iterated upon. But yeah, like, you know, it, an async iterator is basically a promise that can resolve multiple times.
51
00:12:48,000 -->
00:13:15,000
Carl Vitullo: Like, ugh, that's incredible. I don't know. So just, like, So many times when you're modeling something as an asynchronous request, it may actually be better to model it as a stream of incoming data, and you can't do that with a promise. You cannot have an, a stream a stream of events. So i- iterators are just, like, this really magical in-between point between events, like, you know, event-driven architecture and promises. anyway,
52
00:13:15,000 -->
00:13:19,000
Mark Erikson: Ben Lesh would like to have a word with you about RxJS and Observables at this point
53
00:13:19,000 -->
00:13:39,000
Carl Vitullo: Ha ha. Fair enough. Yeah, super cool though. Last thing I'll say on that is definitely lend... early and prominent shout-out of async iterators, I think, lends credence to what you were saying about him being on the cutting edge of the research here. Like, yeah. Everyone else needs to catch up. go become familiar with async iterators, because it will level up your professional, capabilities. Okay, moving on.
54
00:13:39,000 -->
00:13:42,000
Carl Vitullo: Bun has had a big release
55
00:13:42,000 -->
00:14:00,000
Mark Erikson: it's the single biggest change log I've ever seen. It's for what is technically a minor release, except that they also literally rewrote the entire thing from Zig to Rust with AI. Technically, there's no breaking changes, so yeah.
56
00:14:00,000 -->
00:14:04,000
Carl Vitullo: Yep, they've moved out every zig. They're now on Rust.
57
00:14:04,000 -->
00:14:05,000
Mark Erikson: Deep cuts
58
00:14:05,000 -->
00:14:08,000
Carl Vitullo: Deep cuts. You know, you can't just put an opportunity like that in front of me.
59
00:14:08,000 -->
00:14:47,000
Carl Vitullo: Yeah, I think this is super cool. there's been a bunch of drama, a bunch of words typed and spoken about the Rust rewrite, and, like, I just, I don't find that very interesting. The most interesting thing I think is that they used Basically a fully automated workflow and the existing test suite to say, "This works. Go fix it so that it works in this language instead." and then $160,000 in tokens later, they had a Rust-authored version that is apparently good enough to release, and not only good enough to release, but good enough to build a, like, remarkable set of additional features on as part of that release.
60
00:14:47,000 -->
00:15:05,000
Carl Vitullo: So, that's fascinating. That's cool. It's a little crazy to see that much coming out. J- Jared Sumner has always been, like, kind of confusingly prolific at, in terms of, like, level of output here. So I don't know, just seeing him become AI-enabled is remarkable.
61
00:15:05,000 -->
00:15:53,000
Carl Vitullo: But I was gonna say, oh, this is the most important one, and then I'm looking at the whole list and they're all pretty wild. Like, bun.image lets you do a lot of really powerful image manipulation for the web natively, you know, just within Bun, which is great, 'cause I have previously done stuff like that with FFmpeg and Sharp, and those feel like they were written in the early 2000s, because they were. those have been around for a long time because nobody wants to rewrite them, because doing that work in a way that is performant and, like, usable is really hard. So, you know, kudos for shipping something like that. I haven't played with it myself yet. I want to. But yeah, decode, resize, rotate, encode JPEG PNG, WebP, GIF. Yeah, just, like, all of the image formats, doing resizing and basic editing kind of stuff is really, really interesting.
62
00:15:53,000 -->
00:16:04,000
Carl Vitullo: But then they've also got bun.webview, which is basically like Playwright or, you know, Cheerio or something, just natively within the standard library, which is wild and really helpful.
63
00:16:04,000 -->
00:16:24,000
Carl Vitullo: I haven't made use of this yet, but I did go through... I have a skill that I made for myself that is like, "Here's how to set up a new project here. You know, here's how to set up the linting, here's what tools to use." And I told it, "You should use bun 1.4 because the web view stuff makes it really easy to do end-to-end testing," allegedly. I still need to validate this.
64
00:16:24,000 -->
00:17:07,000
Carl Vitullo: But they've also got, like, a markdown parser and, like, a cron scheduler a pseudo terminal so you can dri... You know, they, they say, "So you can drive Bash, Vim or whatever from JavaScript without Node PTY." I've been rigging up a bunch of, like, experimental AI agent harness stuff, as part of doing that, I've been writing a lot of wrappers for Bash to be like, "I need this service to be running in the background while this server runs. it's really janky. I've had AI write a shit ton of, like, bash-compatible things that are, like, forwarding control codes, and making sure output redirection works as expected, and all those little subtle details. So again, one more thing that is, like, a pretty big load off of my mind building something if I can just ship it out to a standard library.
65
00:17:07,000 -->
00:17:18,000
Carl Vitullo: So anyway, yeah, it's a massive change log. Lots of controversial practices involved in producing it and releasing it, but mm, it's pretty cool. End result is pretty neat
66
00:17:18,000 -->
00:17:37,000
Carl Vitullo: Cool. And uh, man, another thing I've been dreaming of for years and years and years, GitHub is now doing a public preview of stacked pull requests stacked PRs. we've talked about this a couple times. I'm not sure how widely familiar, you know, the ecosystem is with stacked PRs.
67
00:17:37,000 -->
00:18:07,000
Carl Vitullo: This has been a, the way that I work intuitively for a number of years at this point, like probably dating back to 2019. Where, like, work on something, produce a finished branch, push that up, create a pull request, and then I'll ... Most of the time, the thing I just built was to enable future work. You know, it was to unblock other work that I mean to be doing. So then I'll just take that branch and continue working off of it, off a new branch, and boom, that's a stacked, you know, that's a series of stacked branches.
68
00:18:07,000 -->
00:18:29,000
Carl Vitullo: I'm, while branch A is being merged, I'm working on branch B, and then, you know, when branch A gets merged, I push up branch B for review. The, the revision here is that now you can just push them all up and mark the PRs as stacked on top of each other and it will automatically do lots of rebase and branch juggling for you.
69
00:18:29,000 -->
00:18:46,000
Carl Vitullo: Yeah, the challenge there is, okay, you stack branches up like that, like I was just describing, but then when you merge them, you know, the, the, the commit SHA changes. You know, maybe you do a squash merge. You know, maybe it's a, Anything other than a fast-forward, and you now have to do a rebase in order to have the, have the branch
70
00:18:46,000 -->
00:18:58,000
Mark Erikson: Which means you have to pull down locally, you have to do the rebase, you have to, you have to do some juggling locally, push it back up, actually create things, and you have to repeat that for every time you do, you, you merge one of those PRs
71
00:18:58,000 -->
00:19:17,000
Carl Vitullo: Right. And so when you've got, you know, branch A and branch B, it's not so much work. But when you've got branch A that drives branch B, that drives branch C, that drives branch D, and you've got eight people all contributing to a shared code base, like that pull, rebase, push cycle ends up being a pretty substantial amount of work.
72
00:19:17,000 -->
00:20:06,000
Carl Vitullo: So it's really cool that GitHub is now enabling this. There's a, there's a pretty closely related concept here as well called a merge queue, which is basically like an engineering practice where as part of review, you know, you don't just mer- you don't just merge when approved. You don't say like, "Okay, this, this PR is now approved for ship," whatever. "Let's merge it now." it's part of a queue, you know, it's in line. So, just as a way to manage conflicts, avoid doing rework because, you know, it... When you ha- when the work that's being merged into release is more predictably sequenced, a lot of benefits fall out of that. And stacked pull requests are a really interesting way to enable a simplified version of that for a, a larger number of people.
73
00:20:06,000 -->
00:20:09,000
Carl Vitullo: So I... This is really cool. I'm excited about it. I I'm gonna have to play with it.
74
00:20:09,000 -->
00:20:30,000
Mark Erikson: mean, it's, it's, it's worth noting that on GitHub, the unit of review is the PR. Like, you can have as many commits as you want, but what you see by default is the final result on the branch, and that is what we're all very used to reviewing, and it's, it's what many other GitHub-like tools have copied.
75
00:20:30,000 -->
00:20:57,000
Mark Erikson: But there were, there have been plenty of other code hosting and review tools Gerrit, Phabricator, and others, where the unit of review was the commit. And so another part of this usage-wise is how big of a unit am I trained to review at once? So, like, maybe you have your, you know, your 5,000-line PR, but it makes sense to review the changes in smaller chunks.
76
00:20:57,000 -->
00:21:17,000
Mark Erikson: Well, on GitHub, it becomes difficult to go through and review, like, one commit at a time or something. So either you say, "Here's the whole thing. Looks good to me," or you have to split it into multiple PRs so that smaller chunks are more easily reviewable, but then you have to do the branch juggling dance.
77
00:21:17,000 -->
00:21:23,000
Carl Vitullo: Yeah, and I guess I, I also wanna say this was, like, Jared Palmer's pet project while he was at GitHub.
78
00:21:23,000 -->
00:21:24,000
Mark Erikson: For about three months
79
00:21:24,000 -->
00:21:31,000
Carl Vitullo: For the... Right. So it appears that Jared Palmer legitimately joined GitHub specifically to ship this, got it into a state where it
80
00:21:31,000 -->
00:21:33,000
Mark Erikson: It's the meme. It's the
81
00:21:33,000 -->
00:21:34,000
Carl Vitullo: Yeah.
82
00:21:33,000 -->
00:21:38,000
Carl Vitullo: Right. And then left, and then went... Yeah, so anyway, that's, that's pretty funny. Uh.
83
00:21:38,000 -->
00:21:41,000
Carl Vitullo: Okay. Into our main content yeah.
84
00:21:41,000 -->
00:21:42,000
Carl Vitullo: Yeah.
85
00:21:42,000 -->
00:21:43,000
Carl Vitullo: Right
86
00:21:42,000 -->
00:21:49,000
Mark Erikson: Right so a few smaller items from React core news-ish stuff this month.
87
00:21:49,000 -->
00:22:15,000
Mark Erikson: There's a new API that's coming out for React DOM. It's a function called Browser, which is intended to be passed to the increasingly expanding use method. So it's use. The idea is it re- the return value of use will differ depending on whether you're calling this on the server or on the client.
88
00:22:15,000 -->
00:22:41,000
Mark Erikson: So if you call it on... If you have a component and it's getting rendered on the server, in a server component or whatever React will see that and essentially leave a hole in your component output. And then it knows that when this run, runs again on the client, then it will fill in. pretty much every code base at this point has some form of a do this logic only on the client util or, or something along those lines.
89
00:22:41,000 -->
00:22:47,000
Mark Erikson: This is essentially building that functionality directly into React DOM itself
90
00:22:47,000 -->
00:22:48,000
Mark Erikson: Let's see.
91
00:22:47,000 -->
00:23:15,000
Mark Erikson: We, we... I believe I mentioned last month that, that there were updates on the way for the React Foundation website, and then they were also talking about governance-related things. They have shipped an update to the website, so it at least looks less AI vibe coded at this point. still Looking and waiting for more public details on what the foundation is going to do long term, but again, you know, bits of activity.
92
00:23:15,000 -->
00:23:18,000
Mark Erikson: Things presumably are churning away behind the scenes.
93
00:23:18,000 -->
00:23:47,000
Mark Erikson: As, as we mentioned earlier, the Next team did an AMA over on Reddit. There's some discussion. Some of it's the obligatory complaining about Next.js not having proper middleware and things like that. I skimmed it. Honestly, the biggest thing I got out of it is that React 19.3 is probably coming in the near future, and that it should solidify the fragment ref and view transition features which have been in Canary for a few months.
94
00:23:47,000 -->
00:23:49,000
Mark Erikson: So good to know that's on the way
95
00:23:49,000 -->
00:24:14,000
Mark Erikson: And then the other interesting bit was that the OXC team has shipped their official support for React Compiler built into Oxlint, et cetera. And, and this is interesting for multiple reasons. So React Compiler itself was originally written in TypeScript and also required a Babel plugin. And so it existed, but we've spent all these years converting our build tool chains to Rust.
96
00:24:14,000 -->
00:24:51,000
Mark Erikson: Babel is slower. People saw that build times got slow again, and like, "We don't like this. Can you just do it in Rust?" The React team did an AI-assisted port of the compiler logic from TypeScript to Rust. That is in the React repo. But then the question is: how will that integrate with other build tools? So other teams, Biome, OXC, Bun, et cetera, have been taking the Rust code and trying to figure out the best way to integrate it, and the OXC team in particular has actually pushed ahead in a lot of ways.
97
00:24:51,000 -->
00:25:09,000
Mark Erikson: They tried to integrate it once, and then they decided that it made their binaries too big, and they didn't wanna ship that to everybody, including people who don't use React at all. So apparently they went back to the drawing board. They found some ways to optimize the code, shrink the bundle size, make it semi-optional maybe.
98
00:25:09,000 -->
00:25:21,000
Mark Erikson: And apparently now the both the build performance and the binary size are good enough that they felt ready to actually ship it. So that, that support is now baked in at this point.
99
00:25:21,000 -->
00:25:45,000
Mark Erikson: And Biome is trying to do some integration as well. Bun 1.4 is supposed to have React Compiler support. So slowly but surely, these pieces are all coming out in the ecosystem in a much faster way, and so hopefully that means that more projects will be actually be adopting the compiler over time and thus seeing whatever runtime performance benefits you get from using it
100
00:25:45,000 -->
00:25:46,000
Carl Vitullo: Should we go to Asteroid?
101
00:25:46,000 -->
00:25:50,000
Mark Erikson: Yes, the asteroid not astro, asteroid
102
00:25:50,000 -->
00:26:28,000
Carl Vitullo: Yeah. Yeah. Nolan Lawson, who is is somebody who's been, like, individually fairly influential on me as a developer I just first encountered him 10, like, more, 15 years ago when I was still in college. So it's cool to see his name still around. he put out a great blog post called The Asteroid Currently Hitting Front-End Web Development. , basically the same thing I actually said on, at the end of our last episode about impacts of AI on educators, on content creators, especially in the front-end engineering space. And basically, you know, he's highlighting that He says, "A lot of the educators I admire in the front-end web space seem to be either bowing out or dialing back their efforts."
103
00:26:28,000 -->
00:27:11,000
Carl Vitullo: And like, yeah, Axel Rauschmeyer, hugely influential blogger about the standards process and, you know, JavaScript itself as a language. Salma Alam N- Naylor, well, Selma and Josh we talked about specifically at the end of the last episode. And, and then he calls out, too, that, like, Kenzie Dodds, Addy Osmani, Rachel Neighbors, Lydia Hallie have all moved more from front-end development into, like, AI agents software development. Which I, which I think is fair. You know, I don't, I, I, I think comparing people stepping back versus staying on the cutting edge. for a long time front-end was the cutting edge, and then it was, like, React Native and where are we gonna put React next? And so now it's not as much that. Now it's AI and how do you build stuff? How do you build a software factory?
104
00:27:11,000 -->
00:27:27,000
Mark Erikson: , even that is a theme we've touched on for a while. I mean, swyx used to be part of the React ecosystem space. He was a mod on the, you know, in the subreddit, did a lot of talks, and then, then he got involved with Svelte, and then he pivoted to running AI conferences and, and podcasts.
105
00:27:27,000 -->
00:27:38,000
Mark Erikson: , we've even talked about, like, the energy at React conferences seems to be down, whereas the AI conferences have all the energy. So, like, there,
106
00:27:38,000 -->
00:27:39,000
Carl Vitullo: Right
107
00:27:38,000 -->
00:27:41,000
Mark Erikson: like, a lot of trend here
108
00:27:41,000 -->
00:27:55,000
Carl Vitullo: . This post from Nolan Lawson, he talks about the future of front end. And I'm just gonna read a couple of, like, high-level points he makes. The front end is less risky to just hand to an agent. Developer experience is becoming less critical overall. Standards will catch up. I think this is interesting.
109
00:27:55,000 -->
00:28:02,000
Carl Vitullo: I, these rhyme with points of contention that I've seen in the industry for essentially my entire career. Like, you know,
110
00:28:02,000 -->
00:28:32,000
Carl Vitullo: is front end... Right. Front end is easy, and developer experience isn't worth the time investment. , I wanna call this out. He says, under developer experience becoming less critical, "The agents know React. For better or worse, React is heavily over-represented in the training weights." And again, like, something we talked about last episode, I believe, was Aiden Bai put together a benchmark of not just React, can it make something functional, but how well does it actually execute React best practices across different models?
111
00:28:32,000 -->
00:28:38,000
Mark Erikson: they know what React code looks like. They don't really know how to write good React code
112
00:28:38,000 -->
00:28:40,000
Carl Vitullo: Right. So
113
00:28:40,000 -->
00:28:42,000
Mark Erikson: They know what bad React code looks like
114
00:28:42,000 -->
00:29:07,000
Carl Vitullo: Yes, bad React code is heavily overrepresented in the training set, but, I used to, I used to work, when, when I was more earnestly working full time, I went to a lot of different companies for, you know, a year, six months, a year and a half, and the reason I was able to be very successful at that is because every company used the same set of very bad practices that represented a fundamental misunderstanding of the advantages that React offered.
115
00:29:07,000 -->
00:29:23,000
Carl Vitullo: And so it's like, cool, I understand those, let me come in and fix this incrementally one thing at a time, and the improvements are so mind-blowing to you as somebody who doesn't understand the tools you're using, that, you know, great, cool, great, awesome. Who... Lovely performance reviews, yada, yada.
116
00:29:23,000 -->
00:30:39,000
Carl Vitullo: I both understand where he's coming from on this. there is less risk in f- the client versus the server. If you fuck up data on the client, like, you just, you know, pull f- from scratch from the back end. But if you screw it up on the back end, like, oops, data loss. Oops, you know, security vulnerability. So it, you know, these are both true, and I think, like, fundamentally missing some kind of point. So I don't know, it talks about the future of front end and front-end education. I think there's still a lot of room for human cognition as steering input to guide agents that, you know, they may be individually capable of achieving, you know, X, Y, Z, maybe even better than I can, but they need to be told what the constraints are in a w- in a manner that is, you know, y- helpful to guiding them to waste less. You know, like, rework is so costly that if you, if I, as the intelligent human with experience using these tools and knowing, you know, what has downstream effects six months, a year, five years from now, then yeah, I think there's still a lot of room for expertise meaningfully
117
00:30:39,000 -->
00:31:01,000
Mark Erikson: when I wrote my own AI journey emotional blog post back in April, one of the points I made was that I did... Once I got past, "I will never use this," and actually started using these tools, I've been able to use them effectively because I already know how to write code. I already understand what good code looks like.
118
00:31:01,000 -->
00:31:23,000
Mark Erikson: I know how I want to do things, and now I'm just trying to speed up the process of doing the work that I already intended to do. or using the tools to give me a range of options, and then I make the decision based on which one actually feels like it fit, fits the best. but then that brings up all the, and all the usual questions of, well, how do you get all this experience?
119
00:31:23,000 -->
00:31:35,000
Mark Erikson: Well, I did it for 20-plus years by hand, and now I'm reaping the benefits of that. And how do others gain that experience in today's world? I don't know. I'm not in that position at this
120
00:31:35,000 -->
00:31:51,000
Carl Vitullo: Yeah. You know what? I think they learn it, I think they learn it essentially the same way that I did. Fucking trial and error. Like, I have a, I have an associate's degree. I have nev- you know, I've taken one year of computer science. Like, I was not taught these things. I learned them largely through trial and error.
121
00:31:51,000 -->
00:32:14,000
Carl Vitullo: You know, you join a company, you ship some code, you have to deal with the consequences of the code that you shipped. I, there's no substitute for experience, and it is easier than ever to go from non-functional to functional. And once you have to maintain a functional thing and keep it operating and expand on it and improve upon it, I feel like the lessons aren't that different.
122
00:32:14,000 -->
00:32:23,000
Carl Vitullo: I don't know. At the end of the day, I think it's, it comes down to how well can you ask questions of this... You know, we're all gonna be managers in the, in this AI world,
123
00:32:23,000 -->
00:32:37,000
Mark Erikson: So a lot of the discussion around this whole direction has then been, yeah, like, what... where is the place for us? What does that mean for our careers? How do we feel about this?
124
00:32:37,000 -->
00:32:45,000
Mark Erikson: So Scott Tolinski uh, one of the hosts of the Syntax.fm podcast with Wes Bos did some work within the last few weeks that really touches on, on this.
125
00:32:45,000 -->
00:33:07,000
Mark Erikson: Scott had his own AI psychosis phase some months ago. And coming out of it, he's like, "Okay, This has affected how I feel, like, literally on a daily basis. I wonder how other devs have been going through this as well." And so he put up a survey online. Has been trying to gather as many respondents as possible.
126
00:33:07,000 -->
00:33:13,000
Mark Erikson: I think he's up to 7 or 8,000 respondents at this point. So you know, a f- fairly decent sample size.
127
00:33:13,000 -->
00:33:30,000
Mark Erikson: And it, it's, it's relatively short, but it asks questions like do you feel like your skills are eroding based on your AI usage? How many times have you found yourself staying up later than you intended because just one m- just one more prompt, one more prompt,
128
00:33:30,000 -->
00:33:50,000
Mark Erikson: Or, you know, sort of the slot machine effect of just asking it to do, you know, some more work. So he gathered up the results, and I believe his wife is actually, like a, a psychologist with, with a, with a doctorate. And so he was having her work through him on some of the statistics and the analysis on this.
129
00:33:50,000 -->
00:34:17,000
Mark Erikson: And he also was reaching out and doing some video interviews with a number of people to follow up and get some ac- you know, some more direct, you know, r- real-life anecdotes and data. So I actually did a video with interview with him, and we, we had a good discussion. He pulled all this together into a half-an-hour YouTube video where he talks about his experience, his research, and brings in video clips of a bunch of people including myself.
130
00:34:17,000 -->
00:34:37,000
Mark Erikson: It's a really good video. I, I strongly encourage people to take the time to read through this. The end, like, the end bit of it is basically take care of your mental health, folks. Like, don't let this, rapid pace change in the world get to you. Take care of your mental health, establish your boundaries, and then go from there.
131
00:34:37,000 -->
00:34:47,000
Carl Vitullo: Yeah. Yeah. Very important. I think at the intersection of that, take care of yourself, understand your boundaries, hold yourself to your boundaries, which is hard.
132
00:34:47,000 -->
00:34:52,000
Carl Vitullo: staying within them for a long period of time is really hard.
133
00:34:52,000 -->
00:34:59,000
Mark Erikson: I know what the right things are and I am not the world's best poster child for sticking with them. Do as I say, not, not as I do
134
00:34:59,000 -->
00:35:49,000
Carl Vitullo: Right, right. and I wanna connect that back to this, you know, asteroid hitting front-end web development and educators falling off and no longer producing output at the same level that they were in the past A lot of my, I think a lot of my energy in producing this podcast, in running Reactiflux, in contributing to the ecosystem has been, especially the last five years, has been very much rooted around what can I do to not burn out? So, you know, it's like the reason this is a once a month podcast instead of weekly or daily or whatever is 'cause I would burn out if I did anything else. Like this is enough effort for me and this is already once a month for an hour plus prep is already disruptive enough to the other things I want to do in my life that I can't do anything more than this.
135
00:35:49,000 -->
00:35:50,000
Mark Erikson: Ditto
136
00:35:50,000 -->
00:36:03,000
Carl Vitullo: Okay, we've achieved some small level of success. We have several hundred people listening every month, which is lovely and great, but like, you know, on the grand scheme of things like this is never gonna pay my bills. This is never gonna be a full-time career. And like, you know, whatever, that's fine.
137
00:36:03,000 -->
00:36:33,000
Carl Vitullo: That's okay. That's okay because that's what I, I built it not to be that. I built it not to take over my life. I built it to let me do it at my leisure, at my convenience. And I don't know, you know, in some ways, like, a personal life philosophy of mine is to like be inexorable, just like, th- just be unstoppable. Like you don't need to be the fastest, you don't need to be the smartest, the most resilient, but like just keep going.
138
00:36:33,000 -->
00:37:28,000
Carl Vitullo: If you, if you're going in a direction, just steady advances incrementally. And so like, you know, I'm not, I, I'm never gonna have hundreds of thousands of social media followers and you know, tens of thousands of hours listened across multiple platforms. But like, you know what? When the other people burn out, here we are. know, other people do these content projects for a year, two years, three years, but like Reactiflux, we've been around more than 10 years now and I've been helping run it for a lot of that, most of that. I've been a moderator or an admin for 10 years now, 10 and a half years now. So I don't know. That's, I think that's, that is an attitude that is not widely rewarded in tech, in tech generally. You could say some other things about different subdivisions there, but I think it's, I don't know. I think it's important for mental health and pers- physical health as well 'cause burnout is not just a mental health issue.
139
00:37:28,000 -->
00:37:34,000
Carl Vitullo: You can have serious physical health consequences from that. Anyway, yeah, I don't know. I'm gonna trail off there.
140
00:37:34,000 -->
00:37:51,000
Mark Erikson: Yeah. So here's sort of the flip side of that keep persisting thing. I mean, we, we listed a number of people who have made the decision to step back because they're feeling burned out or feel like the, you know, the audience and the career that they'd built just no longer exists at this point.
141
00:37:51,000 -->
00:38:05,000
Mark Erikson: So Josh Goldberg, who has been a very prolific open source contributor working across multiple different linting and build tools recently just announced that he's stepping back completely from open source maintenance.
142
00:38:05,000 -->
00:38:23,000
Mark Erikson: I actually talked- had talked to him live just before he posted this, and he, he told me this was where he was headed. Some of it is life changes. He's, he's had a number of stuff going on in his personal life that have taken up time and energy. Some of it is getting very frustrated with AI PR spam
143
00:38:23,000 -->
00:38:32,000
Mark Erikson: and, you know, just not wanting to deal with yet another seemingly plausible bug report that turns out to be complete nonsense.
144
00:38:32,000 -->
00:38:40,000
Mark Erikson: And some of it is just a desire to literally go out and touch grass and do other things with his life
145
00:38:40,000 -->
00:38:41,000
Mark Erikson: at this point.
146
00:38:41,000 -->
00:38:51,000
Mark Erikson: that's also an entirely valid set of decisions, and he said he's ha- essentially handed over all of his projects or they're in maintenance mode at this point.
147
00:38:51,000 -->
00:39:15,000
Mark Erikson: He's still working. I believe he's at Sentry at this point, but he's stopping open source work. And so, like, I'm happy for him in the sense that I want... He's a good- he's a great person, and I want him to do what's best for his life. It's a little sad in seeing someone who has been involved, you know, saying, "That's, that's it for this phase of my life," and stepping away
148
00:39:15,000 -->
00:39:24,000
Carl Vitullo: Right. It, it's sad to me because he's a friend. I consider him a friend. He stayed at my house once because he was passing through and needed a place to crash.
149
00:39:24,000 -->
00:39:25,000
Carl Vitullo: I... He's a lovely person
150
00:39:25,000 -->
00:39:40,000
Carl Vitullo: He's so kind and so generous, and so purely wants to do good that it sucks. it makes me genuinely sad to see him take a s- need to take a step back because he can't do it all, you know?
151
00:39:40,000 -->
00:39:52,000
Carl Vitullo: Because he, nobody can do that all. It's too much. You can't work full-time and have a engaging, rewarding personal life and do these side projects, and also organize a conference, 'cause he was doing that, too. So yeah
152
00:39:52,000 -->
00:40:10,000
Mark Erikson: I mean, I've, I've had my own thoughts. Like, I, I have no plans to stop open source work anytime soon. In fact, I've actually got uh, like I said, we said last month, I'm trying to push through a big new React Redux feature, and I've got a bunch of plans for what will hopefully turn into our next set of major version releases.
153
00:40:10,000 -->
00:40:34,000
Mark Erikson: But you know, purely mathematically, the day will come when I no longer do Redux-y things. It might be 'cause I'm 83 years old and no longer have the mental capability to do it. And, but, like, mathematically I'm gonna stop eventually. It's just a question of when and why, and what am I doing with my life?
154
00:40:34,000 -->
00:40:42,000
Carl Vitullo: Yeah Tough. I don't know. I've wrestled with that a lot. What am I doing with my life? What is my life? Who am I? What do I care about? What are my values?
155
00:40:42,000 -->
00:40:46,000
Mark Erikson: Why are any of us here? Why are any of us Why
156
00:40:46,000 -->
00:40:53,000
Mark Erikson: on that note I'll, I'll toss out three other links. I'm not sure there's necessarily a lot of discussion, but they, they fit very neatly under this category.
157
00:40:53,000 -->
00:41:09,000
Mark Erikson: a group calling themselves the Software Stewardship Lab is trained to help improve open source sustainability. And ironically, when I was on vacation in Scotland earlier this year, I actually happened to talk with some of the people who apparently were...
158
00:41:09,000 -->
00:41:33,000
Mark Erikson: They must have been doing some of the planning for this at the time. Daniel Roe, who's the leader of Nuxt, you know, the, the next equivalent for, the Vue ecosystem is involved. Vlad Harbuz, Andrew Nesbitt, who's been doing massive research on packaging ecosystems uh, Matias Capelletto, who's involved with the, the npmx project, Miranda Heath, who's been doing research on burnout.
159
00:41:33,000 -->
00:42:11,000
Mark Erikson: A lot of, again, very, very good people who care deeply about open source and community as a concept are involved in this. I'm a little unclear on how they're hoping to improve things, but I highly, highly approve of the concept, and these seem like the right kind of people to be doing thinking and research I read a really, really long blog post, my favorite kind that covers a number of things related to AI migrations and software craftsmanship. It's long enough that I don't remember what all was in here, but it was a really, really g- good post and worth taking a look at.
160
00:42:11,000 -->
00:42:28,000
Mark Erikson: And then James Garbutt, who's involved with the E18E Ecosystem Cleanup Initiative, wrote his own post on humanity in open source, and some of his points are that, yeah, we're, we're getting swarmed with AI PRs and issues.
161
00:42:28,000 -->
00:42:53,000
Mark Erikson: Open source is about more than just... Like, the construct of open source is about more than just licenses and releases, et cetera. It's about the communities that are getting involved, and it would... And then there's also the questions of, you know, how do we keep building those communities, especially if people keep getting burned out?
162
00:42:53,000 -->
00:42:56,000
Mark Erikson: So he has s- several different thoughts on trying to manage that
163
00:42:56,000 -->
00:43:15,000
Carl Vitullo: Yeah. Okay, at the mention of communities, I wanna jump in. - we're talking about, communities maintaining shared infrastructure is how I'm gonna frame this, you know, humanity and open source. Do you know how many different communities are maintaining the shared infrastructure that support every aspect of your basic life?
164
00:43:15,000 -->
00:43:16,000
Mark Erikson: Where's
165
00:43:16,000 -->
00:43:17,000
Carl Vitullo: I think...
166
00:43:17,000 -->
00:43:21,000
Carl Vitullo: Yeah, right, but y- right, okay, so there's XKCD of all the stacked, you know, boxes
167
00:43:21,000 -->
00:44:08,000
Carl Vitullo: with, like, that fragile thing. But, you know, like, you know what? Like, how do your lights stay on? How do you get hot water? You know? How do you stay cool? How do you get groceries? Like, each of these is the output of a shared infrastructure being maintained by a community. You know? Okay, the s- the, the, the power that might be, the community there might be a regional monopoly as dictated by, you know, legislative priorities. but, like, th- th- I guess that's how I wanna frame this. Like, I think we are exceeding the type of human scale. You know, this is like the Industrial Revolution of software. Like, it used to be all handmade parts that were not interchangeable. Th- and we've been moving more and more towards interchangeable, fully automated whatever.
168
00:44:08,000 -->
00:44:49,000
Carl Vitullo: And, like, yeah, for better and for worse. Like, if you take that lens of handmade versus scaled, you can apply that to almost anything. Like, I occasionally like to bake bread. I also buy store-bought bread because it keeps longer, and it keeps longer because it's a fully automated system that has been refined for 150 years because people need bread, and not everyone has the available time and resources to bake it. So, you know, like I, I love to think about water, water is a crazy, when you actually look into the, like, societal level engineering projects.
169
00:44:49,000 -->
00:45:13,000
Carl Vitullo: So like control of the flow of water is a shocking percentage of human effort over the millennia. Like not, keeping it within the tolerable bands. You have to have enough to keep everyone who lives there alive, but not so much that it washes their houses away. And like managing that is a preposterously large project, and when's the last time you thought about it?
170
00:45:13,000 -->
00:46:14,000
Carl Vitullo: So like that's... I think open source is now moving more in that direction, where it had been very human scale of like, I know the 15 people who are making all of, you know, making this whole thing work. And now we're starting to go into a place where there is enough automation in generating and consuming code that that scale of investment no longer really works. Another useful lens here is like Etsy versus Walmart. Like I can go to Etsy and I can buy picture frames or, you know, a pin or a sticker or a shirt, and that was probably handmade by somebody, hand designed by somebody, and I'm gonna pay a little premium for that. But like most people don't actually care that much about where their shirts come from. They don't care about the manufacturing process of, you know, how this, was this picture frame made with sustainably grown wood, or is it a composite made out of sawdust and epoxy? Like most people don't care. It looks good on the wall.
171
00:46:14,000 -->
00:46:33,000
Carl Vitullo: So that, to me, is a really fundamental lens here. It's people who are used to being very close to the production grating against the automation of what they have taken great pains to do well. And neither side is wrong. Both of them are fully correct.
172
00:46:33,000 -->
00:46:47,000
Mark Erikson: So partly angling off that, and this was actually in what passes as a script over here. Two more stories of migration that circle back through the AI aspect, the frameworks aspect.
173
00:46:47,000 -->
00:47:01,000
Mark Erikson: Cursor just got done migrating their entire system from Solid to React, and they talked some about it, and one of the things they said is, "Well, the agents are more used to writing React.
174
00:47:01,000 -->
00:47:29,000
Mark Erikson: They actually make a lot of mistakes, but at least we're familiar with those mistakes, and they're obvious to us now, and we can control and correct for those. Whereas with Solid, they just sort of got confused most of the time." so that... There was, there was a lot of debate back and forth on Twitter. A, a lot of quote tweets and, and some discussion from the Solid team saying you also didn't ever really give us much of a chance, but yeah. So there's, there's its own drama there.
175
00:47:29,000 -->
00:47:37,000
Carl Vitullo: Yeah. Certainly no, certainly no part of this was because Lauren used to be on the React team. There's probably no bias there. Yeah.
176
00:47:37,000 -->
00:47:46,000
Carl Vitullo: This is such a shady tweet. Like, "Much love to the Solid team and congrats on launching Solid 2. We just finished moving away from you." Like, that's some hella shade to throw.
177
00:47:46,000 -->
00:48:11,000
Mark Erikson: And then we mentioned earlier, Lovable talked about having migrated I think their own actual system away from Next.js and over to TanStack Start. And I, I, I know they switched their project setup from whatever the previous was to TanStack Start. I believe this is separately saying they switched their own infrastructure to be built on TanStack Start instead.
178
00:48:11,000 -->
00:48:21,000
Mark Erikson: I love a good migration post. This goes into a lot of details, and it does say that they did some of that work with AI tooling further down once they had identified some of the constraints
179
00:48:21,000 -->
00:48:38,000
Mark Erikson: we could have spent a bunch of time on this. I think we've probably gotten far enough. We probably shouldn't spend time on this, but sort, sort of a meta point and, and one of the things we keep circling on is you can switch very easily from tool A to tool B or language A to language B at this point.
180
00:48:38,000 -->
00:48:50,000
Mark Erikson: You say, "Here we've got this thing. This thing works. Make it work in some other tool set entirely," and if you've got enough tests, enough tokens, enough time, then it pops out on the other end.
181
00:48:50,000 -->
00:49:00,000
Mark Erikson: Having said that, I do actually want to bring up one more set of framework-y things because I think this is fascinating reading as a person who spends too much time caring about frameworks.
182
00:49:00,000 -->
00:49:21,000
Mark Erikson: I mentioned earlier that Ryan Carniato and the Solid team have been doing a bunch of bleeding edge research especially into how the entire signals data graph can encode the asynchronous of the data in there instead of needing to, like, separately keep track of promises or, you know, loading flags, et cetera.
183
00:49:21,000 -->
00:49:33,000
Mark Erikson: And so they've put up a, a series of three posts that go into the details on what that means in practice when you use Solid 2. I thought they were fascinating reading myself.
184
00:49:33,000 -->
00:49:47,000
Carl Vitullo: Our last main topic before we go into what are allegedly short asides, lightning round. The general unreliability of GitHub lately lately. they Put out a blog post talking about the outage on August 17th. And like, yeah, you know what? Like, they're not...
185
00:49:47,000 -->
00:49:57,000
Carl Vitullo: They're barely holding one nine of availability lately That ties very closely to the rise of agentic coding and the sheer volume of commits that are being pushed,
186
00:49:57,000 -->
00:50:08,000
Mark Erikson: they've published a number of stats in the last several months about how the number of PRs and commits and API calls has just absolutely gone through the roof in the last few years.
187
00:50:08,000 -->
00:50:10,000
Carl Vitullo: Like 10X, 20X
188
00:50:10,000 -->
00:50:12,000
Mark Erikson: a large multiplier
189
00:50:12,000 -->
00:50:22,000
Carl Vitullo: Yeah, fair. Yeah. there are now more and more people throwing out GitHub competitors, which I think is interesting. There's Cloudflare, Netlify, Cursor.
190
00:50:22,000 -->
00:50:25,000
Carl Vitullo: oh, wow from chat, "GitHub reported one commit per millisecond."
191
00:50:25,000 -->
00:50:28,000
Mark Erikson: initially read that as one commit per, from Microsoft. I'm
192
00:50:28,000 -->
00:50:36,000
Carl Vitullo: Yeah, me too. All it takes, one commit for Microsoft to take down the system. The commits are coming from inside the house. Okay, sorry.
193
00:50:36,000 -->
00:51:05,000
Carl Vitullo: But yeah, so there's now... there's a combination of factors that are making people start to put out GitHub competitors. Okay, obviously we're in the middle of discussing the significant outages that GitHub has been having for a number of months now. But there's also, we don't know how to work anymore. We don't know what the best way to... Uh, Well, okay, we never knew what the best way to work is, but we had at least settled on pretty widely adopted patterns, which GitHub, you know, codified and then led in a
194
00:51:05,000 -->
00:51:15,000
Mark Erikson: You have, you, you have a trunk, you make a feature branch, you work for a few hours or a day, you push a PR, a teammate reviews it, CI goes green, and you ship it
195
00:51:15,000 -->
00:51:24,000
Carl Vitullo: Right. there's a lot of assumptions about how you use Git in that workflow. And so, like, you can use Git in different ways if you were to so choose.
196
00:51:24,000 -->
00:51:25,000
Carl Vitullo: Uh, I actually re-
197
00:51:24,000 -->
00:51:26,000
Mark Erikson: was a thing back in the day
198
00:51:26,000 -->
00:51:40,000
Carl Vitullo: Yeah, and I actually have moved uh, one of my projects more towards a Git flow type thing, where you have a periodic release, and you cut an RC, and you do user acceptance testing on the uh, on the release candidate, and you ship that artifact.
199
00:51:40,000 -->
00:51:58,000
Carl Vitullo: There's an explosion in exploration of new ways to work with code and new ways to collaborate with others around code that I think is driving some of this curiosity to try alternatives. I'm personally very curious about trying to self-host some infrastructure here.
200
00:51:58,000 -->
00:52:08,000
Carl Vitullo: I don't know. Maybe this is me b- spending five years independent and not working with companies, but like, man, there's just much unexplored territory now
201
00:52:08,000 -->
00:52:30,000
Mark Erikson: there was a really good discussion over in swyx's Discord just a couple days ago with a different but similar theme. Some of it was the debate over, "Wait, you guys are still reading code?" but then that also ties into, "Wait, you guys are st- like, like who's using an actual IDE to do their work?"
202
00:52:30,000 -->
00:52:55,000
Mark Erikson: Versus this new breed of agentic swarm management tools, where what really matters is you have a chat screen and a dashboard of all the agents and the work trees in flight, and maybe it's got like an integrated diff viewer, but what really matters is, like, the task management rather than, like, I need to have the code open so I can type.
203
00:52:55,000 -->
00:53:25,000
Carl Vitullo: Right. the way I have been working is very acceptance-driven of just, like, does this achieve the goal I set out when I started this project? And I don't really review the PRs as much. I do quick , sanity checks of, like, you know, is this 15,000 lines when it could be 2,000 lines? But, you know, like, very high level. I'm not really understanding the... You know, I, if I wanna understand something about how the code works or how the code is structured, like, I ask the agent, 'cause the agent wrote it. yeah, I don't know.
204
00:53:25,000 -->
00:53:54,000
Carl Vitullo: Dashboards and such, I think is... that feels not quite right to me. That feels like project manager kind of capacity more than, like... I don't know. These, like, task tracking is different from did you build the right thing? What's underway is different from are we working on the right things? So, just thinking about it through the lenses of different professional titles, like software engineer versus, like, manager versus, like, director of product or project manager, program manager.
205
00:53:54,000 -->
00:54:11,000
Carl Vitullo: Like, all of those needs of establishing what the space we're working in is, what other solutions have other people tried? What, what are we ruling out? What is the actual need we're solving? Are we achieving that need?
206
00:54:11,000 -->
00:54:23,000
Carl Vitullo: Yeah, that's all the same. Now that code is no longer the primary thing that I want to read in order to understand the, the answers to those questions. Yeah. I don't, I think we're, I think we gotta figure it out, kind of from scratch.
207
00:54:23,000 -->
00:54:59,000
Mark Erikson: So point is, there's an awful lot of experimentation going on in how we as developers are, what tools we're using to do the work and what the workflows look like. And so then between the massive increase in commit scales and, you know, the, the changes in those workflows, we're seeing a variety of different hosting tools come out that, you know, either just, hey, you can have your Git hosting not on GitHub or, but also po- possibly make it more agentic friendly,
208
00:54:59,000 -->
00:55:00,000
Carl Vitullo: Yeah.
209
00:54:59,000 -->
00:55:01,000
Mark Erikson: whatever that means
210
00:55:01,000 -->
00:55:16,000
Carl Vitullo: Interesting. I'm, I'm exploring some stuff around this area as well. I'm going to be coming at it from a very different direction from all of these places, which are still fundamentally anchored around software as a service published on the cloud which I think is limiting. But yeah.
211
00:55:16,000 -->
00:55:24,000
Carl Vitullo: Two that I wanna shout out. Tangled.org is pretty interesting. They're doing... They're trying to do essentially GitHub on at protocol.
212
00:55:24,000 -->
00:55:25,000
Mark Erikson: no
213
00:55:24,000 -->
00:55:38,000
Carl Vitullo: So it's, you know, it... That's cool. It's a decentralized social media platform, and they're putting basically the social components of GitHub onto that decentralized protocol. So awesome. That's awesome. That's very cool.
214
00:55:38,000 -->
00:55:55,000
Carl Vitullo: Cloudflare is also doing a, yeah, versioned storage that speaks Git, is their headline. We had some others in the notes from Cursor and Netlify, but I wanna be honest, I don't, I don't feel like either of those are in the right place to successfully execute on that vision.
215
00:55:55,000 -->
00:56:16,000
Mark Erikson: Mm-hmm. I will say that this article on scaling Git was fascinating. there's been a lot of efforts over the years to make Git scale. Microsoft has done a lot of work on, like, virtual file systems and improving algorithms inside of literally the Git implementation itself. This one's more focused on the hosting side of things
216
00:56:16,000 -->
00:56:48,000
Carl Vitullo: Yeah. And okay, this is why I'm skeptical of software as a service cloud-based, 'cause, like, that's the problem. Like, Git is a decentralized system, you know? You can just add a remote, and it... Like, you push. It's exactly the same. yeah, if you're dealing with pushes from literally the entire world, that's really hard to optimize. But, like, I dream, I hope, I wish that at some point we will get to a state where more people can have, you know, world accessible, safe compute that they control.
217
00:56:48,000 -->
00:57:14,000
Carl Vitullo: Like, I have a network accessible storage here. It technically can run a Git server. Like, there's no reason I couldn't use that as my primary store, and then, like, make that available to some other tooling that is aware of that storage and does collaborative features on top. When you distribute stuff like that, you don't have to worry about load at any individual site anywhere near as much, which is what this Git any, any scale kind of post is talking about. Anyway.
218
00:57:14,000 -->
00:57:16,000
Carl Vitullo: some lightning round whatever.
219
00:57:16,000 -->
00:57:51,000
Carl Vitullo: I saw a fun thing, npm.report. It looks like an interesting way to just get, like, a very brief... I don't know, this is, this is maybe a very early project. Just looking at some of the numbers on the landing page Well, it's certainly not ingesting all of npm to do this. But yeah, it's interesting. It's doing supply chain trust signals for npm organizations, so the audit, visualize, share, track over time. Uh, It's an interesting idea. I'm not quite sure if the execution is fully able to execute upon the idea it has, but it's looks interesting. Supply chain management auditing is so in vogue right now because it doesn't work very well.
220
00:57:51,000 -->
00:58:10,000
Mark Erikson: So I, I mentioned Andrew Nesbitt earlier. He's been blogging for, for a while on package management ecosystems. He's, he's probably the world's foremost expert on all the world's package managers out there, and has put up a lot of blog posts on, like, how they work internally, where they're flawed, all these other things.
221
00:58:10,000 -->
00:58:34,000
Mark Erikson: He's also written several satire posts on his blog. , he's written some fake articles about fake AI-driven CVEs slipping through the chains. he did this one a supplier security questionnaire. You know, the kind of thing that, like, a, a company security office would send out to their dependents, except this one's clearly being sent to an open source person.
222
00:58:34,000 -->
00:58:55,000
Mark Erikson: And the questionnaire just gets more and more absurd on the requirements that they're placing on this unnamed open source maintainer. And, and that, that's sort of what happens when the legal compliance side of things wants assurance that your supply chain is secure, and two-thirds of your app is just we installed this NPM package
223
00:58:55,000 -->
00:58:58,000
Carl Vitullo: Yeah. Cool. Nice. Love that
224
00:58:58,000 -->
00:59:17,000
Carl Vitullo: Okay. Well, continuing on our security thread there . I read a really great blog post called Everything I Own, Owned. so this person, Chaz Schlarp, put out a blog post about pointing Claude at various physical devices that he literally owns, that are physically in his possession, and just saying like, you know, "Hey, can you hack this?
225
00:59:17,000 -->
00:59:25,000
Carl Vitullo: Can you get control over this? Can you put a custom firmware on this?" and the answer resoundingly is yes.
226
00:59:25,000 -->
00:59:26,000
Mark Erikson: Nice
227
00:59:26,000 -->
00:59:44,000
Carl Vitullo: you know, hacked his own webcam a- alarmingly hacked it in such a way that he was able to turn off the recording light which ideally should not be possible. Ideally, that should not be a software controlled feature. It should be electrically impossible for the camera to record while the light is off. Oops, this one could.
228
00:59:44,000 -->
01:00:17,000
Carl Vitullo: Also hacked his monitor. And I... Something I appreciate is for each of these devices, he puts up a GitHub repo of the new firmware, how long it took Claude to figure it out, and how many prompts from him it took Claude to figure it out. So this, you know, the webcam was three and three quarter hours of Claude time with 33 prompts. His monitor is hour and a, hour and 15 minutes with 13 prompts. A microphone was four hours, you know, four hours and 15 minutes with 32 prompts.
229
01:00:17,000 -->
01:00:53,000
Carl Vitullo: I think this is really fascinating from a couple of different ways because to tie it into a like macro, huge question of ownership conversation that I've been hearing about for the right to repair. Like most things don't let you repair it. They don't let you, you know, access any kinds of internal state. And so like now that these AI tools are good enough at reverse engineering and cybersecurity stuff to just hack it, like, hmm, that's actually pretty interesting for right to repair. Like you know, to the extent that rules and policies are only as good as your ability to enforce them.
230
01:00:53,000 -->
01:01:05,000
Carl Vitullo: Like oops, they can't enforce their own security practices because it used to just assume that it was too hard to flash a custom firmware and now it's actually not that hard as, if you know generally what you're doing.
231
01:01:05,000 -->
01:01:09,000
Mark Erikson: Or a lot of cases, if you don't know what you're doing or just willing to tell Claude, "Try harder."
232
01:01:09,000 -->
01:01:50,000
Carl Vitullo: Right. Right. here's a fun one. This is a mini key light. So I think it's, you know, it's like for video production, it's just like a little controllable two by three inch light. And he says, " This one turned out way more interesting than I expected. It's the only one with meaningful firmware integrity protection. It signs the firmware updates with ED25519 and a hash of the firmware payload and rejects firmware that doesn't validate. Unfortunately, while that's an improvement, it protects the firmware ex- at exactly one point in time, during updates. I asked Claude to look for an exploit that might enable, you know, other attack surface, and it found an HTTP post request that drops a payload straight into the internal UART which includes a memory poke command."
233
01:01:50,000 -->
01:01:53,000
Carl Vitullo: So it, you know, it's got signed
234
01:01:53,000 -->
01:01:54,000
Carl Vitullo: verification
235
01:01:54,000 -->
01:01:55,000
Mark Erikson: Change this value."
236
01:01:55,000 -->
01:02:17,000
Carl Vitullo: Yeah. So it's, it, it has ostensibly update security, but it also has an HTTP endpoint that will let you, like, arbitrarily revise memory. He says, "This means a single HTTP post of ATSC equals," and then two hexadecimals comma-separated values, "turns the signature check into a no-op, and we can freely update the firmware." So it's just like, man, that's crazy.
237
01:02:17,000 -->
01:02:18,000
Carl Vitullo: That's great.
238
01:02:18,000 -->
01:02:19,000
Mark Erikson: you tried
239
01:02:19,000 -->
01:02:33,000
Carl Vitullo: At least you tried. Yeah, defense in depth, it's really hard. I don't know, that's really interesting. Like, if we own, if we more meaningfully own the ability to control what the tech in our rooms is doing, that's powerful. I appreciate that. We should have more of that.
240
01:02:33,000 -->
01:03:32,000
Carl Vitullo: Final AI security adjacent thing from the Trail of Bits blog. The Sorry State of Skill Distribution, talking about how the skill marketplaces for AI agents are full of malicious skills that will exfiltrate your, you know, credentials and blah, blah, blah, blah, blah. Yeah, so don't download arbitrary skills without reading what they're gonna be doing. You know, this is just an extension of I don't know, running untrusted code is never good, and running untrusted skills that will have the ability to run untrusted code on your hardware is even worse, ' cause these are smart. Yeah, reminds me too, I, I just learned, this happened last month, but a certain AI platform controlled by a person whose name I don't like to uh, give airtime was, it turns out the whole agent itself was uploading all of the directory that you ran it in with no control. So it would pull every, every file in there and just dump it into a remote GCP container.
241
01:03:32,000 -->
01:03:46,000
Carl Vitullo: So, like, state of security right now in the AI w- world is pretty rough. Most people are being very sloppy about it, and if you are riding the cutting edge, the odds that you run into something that will aggressively attack you is pretty high .
242
01:03:46,000 -->
01:03:48,000
Carl Vitullo: Oh yeah, Mark, tell us about this conference
243
01:03:48,000 -->
01:04:33,000
Mark Erikson: Yep same two I mentioned last month, and conveniently they're the... I, I know about them because I will be speaking at both of them in the next few weeks. ZurichJS is happening, I believe, on September 11th in Zurich, Switzerland. I said it last time, I'll say it again, because he r- especially because he ran across the transcript and thought it was very heartwarming. Faris Aziz is a good, close personal friend of mine. He's running this conference. He's been running the ZurichJS meetup for the last year or two. This is the first time conference for them and I know how much effort he has been putting into putting this together, from selling tickets to doing outreach and getting sponsors to building an entire conference management platform from scratch.
244
01:04:33,000 -->
01:04:46,000
Mark Erikson: Faris is awesome. This will be a fun conference. The speaker list looks great. I'm looking forward to seeing a lot of good, good friends there. If you are anywhere in Europe or even not in Europe, consider buying a ticket and joining us there. It'll be great.
245
01:04:46,000 -->
01:04:47,000
Mark Erikson: similarly,
246
01:04:47,000 -->
01:04:50,000
Mark Erikson: React Alicante is in Alicante, Spain.
247
01:04:50,000 -->
01:05:05,000
Mark Erikson: I believe that's around September 23rd, 24th-ish. That's also been a lot of fun. it's a very well-run conference. Another great organizer, Victoria. it's a good conf- there's a lot of good people there. Come join us. Hang out. Talk in real life. It's a thing
248
01:05:05,000 -->
01:05:09,000
Carl Vitullo: Yes, I can confirm that Mark is a lovely person to go to a conference with.
249
01:05:09,000 -->
01:05:27,000
Carl Vitullo: Cool. All right, that's all we got for you this month. Thanks for sticking around an extra 25 minutes past our... Well, I'd say past our typical end time, but it's not like we've ever hit that, I think, this year. we'll be back next month. Maybe not on the last Wednesday, 'cause it's the last day of the month. Or we'll be back in your podcast feed just as soon as we can after we record.
250
01:05:27,000 -->
01:05:41,000
Carl Vitullo: Yeah, thanks so much. If this is a podcast that you find valuable I'd actually just personally love to hear it. If you shot me an email to hello@reactiflux.com and said something about how this has influenced the way you think or do things, that would be personally meaningful to me.
251
01:05:41,000 -->
01:05:58,000
Carl Vitullo: Or give us a review. Tell somebody else that you know about this podcast. That would all be very helpful. We have a sponsor for next month, which is great. yeah, so that should cover most of the costs of producing it for the year, I like not paying for it myself. cool. Thanks so much. See you next month.
252
01:05:58,000 -->
01:05:59,000
Mark Erikson: Take care
253
01:05:58,000 -->
01:06:03,000
Mark Erikson:
