use(browser()); Bun 1.4; is that an asteroid hitting web educators?

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.

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.

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

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.

We do have a lot of new releases or pre-releases, release candidates to talk about. Yeah. Let's get going.

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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.

Improved some bundle sizes, some tweaks to the, to the React bindings. So still out there and still being worked on

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.

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

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,

There weren't a lot of great secrets revealed in that.

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.

I'm su- You know, it does improve. It gets better. It, it... But, like, the challenges are still pretty similar.

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

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.

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.

I think it's perhaps time to subtract. But subtracting is usually a major version bump anyway.

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

he

was just about to say that

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.

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.

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.

Wonderful

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.

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.

It's so hard to make a good table

But I thought coding was solved

Coding is? It's completely solved. , it gets more and more solved the less closely you look at the outputs.

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?"

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.

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

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.

Th- so that's awesome. That's interesting. That's useful. But yeah, stage one, that's pretty far away from released

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.

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.

Ryan's doing, like, the bleeding edge research here

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.

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

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.

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,

Ben Lesh would like to have a word with you about RxJS and Observables at this point

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.

Bun has had a big release

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.

Yep, they've moved out every zig. They're now on Rust.

Deep cuts

Deep cuts. You know, you can't just put an opportunity like that in front of me.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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

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.

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.

So I... This is really cool. I'm excited about it. I I'm gonna have to play with it.

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.

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.

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.

Yeah, and I guess I, I also wanna say this was, like, Jared Palmer's pet project while he was at GitHub.

For about three months

For the... Right. So it appears that Jared Palmer legitimately joined GitHub specifically to ship this, got it into a state where it

It's the meme. It's the

Yeah.

Right. And then left, and then went... Yeah, so anyway, that's, that's pretty funny. Uh.

Okay. Into our main content yeah.

Yeah.

Right

Right so a few smaller items from React core news-ish stuff this month.

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.

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.

This is essentially building that functionality directly into React DOM itself

Let's see.

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.

Things presumably are churning away behind the scenes.

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.

So good to know that's on the way

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.

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.

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.

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.

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

Should we go to Asteroid?

Yes, the asteroid not astro, asteroid

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."

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?

, 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.

, 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,

Right

like, a lot of trend here

. 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.

I, these rhyme with points of contention that I've seen in the industry for essentially my entire career. Like, you know,

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?

they know what React code looks like. They don't really know how to write good React code

Right. So

They know what bad React code looks like

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.

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.

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

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.

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?

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

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.

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.

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,

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?

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.

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.

I think he's up to 7 or 8,000 respondents at this point. So you know, a f- fairly decent sample size.

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,

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.

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.

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.

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.

staying within them for a long period of time is really hard.

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

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.

Ditto

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.

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.

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.

You can have serious physical health consequences from that. Anyway, yeah, I don't know. I'm gonna trail off there.

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.

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.

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

and, you know, just not wanting to deal with yet another seemingly plausible bug report that turns out to be complete nonsense.

And some of it is just a desire to literally go out and touch grass and do other things with his life

at this point.

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.

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

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.

I... He's a lovely person

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?

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

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.

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?

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?

Why are any of us here? Why are any of us Why

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.

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...

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.

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.

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.

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?

So he has s- several different thoughts on trying to manage that

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?

Where's

I think...

Yeah, right, but y- right, okay, so there's XKCD of all the stacked, you know, boxes

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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...

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,

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.

Like 10X, 20X

a large multiplier

Yeah, fair. Yeah. there are now more and more people throwing out GitHub competitors, which I think is interesting. There's Cloudflare, Netlify, Cursor.

oh, wow from chat, "GitHub reported one commit per millisecond."

initially read that as one commit per, from Microsoft. I'm

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.

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

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

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.

Uh, I actually re-

was a thing back in the day

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.

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.

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

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?"

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.

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.

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.

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?

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.

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,

Yeah.

whatever that means

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.

Two that I wanna shout out. Tangled.org is pretty interesting. They're doing... They're trying to do essentially GitHub on at protocol.

no

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.

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.

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

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.

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.

some lightning round whatever.

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.

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.

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.

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

Yeah. Cool. Nice. Love that

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?

Can you get control over this? Can you put a custom firmware on this?" and the answer resoundingly is yes.

Nice

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.

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.

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.

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.

Or a lot of cases, if you don't know what you're doing or just willing to tell Claude, "Try harder."

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."

So it, you know, it's got signed

verification

Change this value."

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.

That's great.

you tried

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.

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.

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 .

Oh yeah, Mark, tell us about this conference

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.

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.

similarly,

React Alicante is in Alicante, Spain.

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

Yes, I can confirm that Mark is a lovely person to go to a conference with.

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.

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.

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.

Take care

​