This Month in React, May 2024: Updates from React Conf

Transcript from Friday May 31st, 2024

Carl Vitullo: Hello everyone. Thank you for joining us for May's This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. We're coming to you live from Reactiflux, the place for professional React developers. We have so much news this month because there was ReactConf and so many of the things that we had been discussing over the last three or four months actually like dropped and landed. [00:00:23]

And are available and there are eight hours of talks discussing all of the things that we have been like punditing and talking heads about direct from the source. So I am excited about that. We're going to dig into it. [00:00:34]

But first, I'm Carl. I'm a staff product developer and freelance community manager here at Reactiflux, where I run community programs like these and build tools to help keep the community running. [00:00:44]

Before I hand it off to Mark I'm gonna hand it off first to our new guest host for the month where it's a bit of a trial. [00:00:50]

Mark Erikson: I think he's gonna do fine! [00:00:51]

Carl Vitullo: Mark, thank you for introducing me to our new guest host! Do you want to introduce yourself? [00:00:56]

Mo Khazali: Nice to be here with you all. So my name is Mo. I head the mobile team at Theodo and I've been sort of an active part of the React and React Native ecosystem for a few years now. And I help organize some meetup groups like the React Native London meetup and have here and there dabbled in some open source contributions within the ecosystem with libraries like Expo and Tamagui. [00:01:16]

Very happy to be here with you all and looking forward to chatting all things React Native. [00:01:20]

Carl Vitullo: Awesome. Thanks for joining us. [00:01:21]

Mark Erikson: And I'm Mark Erikson, my day job is working at Replay. io, where we're building a time traveling debugger for JavaScript. And outside of Replay, I do Redux stuff. [00:01:30]

Carl Vitullo: Some quick hits before we get into the main news. [00:01:33]

Layoffs news

Carl Vitullo: Quick layoffs overview from layoffs. fyi. This month, over May, there were 9, 600 laid off. from 36 companies, which is down quite a bit actually from April. last month in April, there were 22, 000 laid off from 57 companies. So that's improving a little bit. So far, this year has been substantially better than last year, but that's not saying very much because last year was like, the worst year in the last 20 years. So improving steadily is still not great. [00:02:02]

New Releases

Carl Vitullo: Some new releases. It looks like there's been a couple of new releases in sort of the fallout of React 18. [00:02:07]

Docusaurus 3.3

Carl Vitullo: 3 coming out, there's a Docusaurus just doing a minor release on 3. 3. Nothing too new there, it's basically just like fixing some new warnings that popped up. [00:02:17]

Mantine 7.9.0

Carl Vitullo: Mantine has also put out a 7. 9. 0 release. Mantine seems pretty cool, I haven't played with it too much myself, I don't play with very many UI toolkits, but this is high on my list of ones to look at. [00:02:30]

Astro 4.8

Carl Vitullo: There's also Astro 4. 8, which just came out. They're coming out with a couple of new things that look pretty interesting. You know, also like classic performance improvements and bug fixes. They have an experimental Astro Actions, which, you know, okay. We have one more thing in the ecosystem called Actions, which is unfortunate, they pitch it as, "actions make it easy to define and call backend functions with full type safety from your client code." And full type safety on a backend request is wonderful. Happy to see that. That's pretty great. [00:03:00]

They also have an experimental request rewriting feature. Request rewriting is pretty important on a large production application. It's where you receive a request on one URL and handle it internally as if it was a different URL. So you can do stuff like aliases or rewrites or silent redirects and things like that. [00:03:18]

Redwood 7.5

Carl Vitullo: There's also Redwood 7. 5. I recently spoke with the Redwood folks at ReactConf and it got, it actually got me a lot more excited about the project. [00:03:26]

Upcoming conferences

Carl Vitullo: All right, switching into some upcoming conferences. Me and Mo are going to bounce off each other here a little bit. [00:03:32]

Render Atlanta

Carl Vitullo: In two weeks, I am sad that I will not be able to make it to this one, but Render Atlanta is happening June 12th through 14th in Atlanta, Georgia. [00:03:41]

Looks like a really great conference. I have heard nothing but phenomenal things from past years, and it looks like a great crew is heading out there this year. So yeah, definitely check it out if you are looking for a conference this month. [00:03:52]

Yeah, Mo? [00:03:53]

Future Frontend

Mo Khazali: And just around the same time, so June 13th to 14th, Future Frontend is happening in Helsinki. [00:03:58]

So that's up north in Finland. And I can personally attest to how good this conference is. It's one of those conferences that has a real community feel to it. You know, 100, 150, 200 people coming. And everyone is super passionate about building front end apps, not just in the React world, but across boundaries. And that means you get some really cool wacky ideas coming up. [00:04:15]

Last year, someone demoed a talking hamster that was built in JavaScript, which was one of the most wacky and coolest conference talks I've ever seen in my life, and I really enjoyed it. So would definitely give it a shot if you're kind of in Europe and around at that time. [00:04:27]

Carl Vitullo: And I, I believe one of the organizers is, uh, Juho Vepsäläinen. He has been active in Reactiflux from very early on, he used to have a channel himself for his project, SurviveJS. [00:04:37]

So I, he's been on my radar for my entire career. He seems like a wonderful person. I've never met him in person though. So I'm sad that I also won't be able to fly out to, you know, I can't make the Georgia, so Finland is a bit of a tough sell. [00:04:49]

React Norway

Carl Vitullo: But that week is a heavy conference month because React Norway is also happening June 14th in Larvik, Norway. I don't know anything about the organizers there. So, can't comment. [00:05:01]

React Summit

Carl Vitullo: There's also React Summit, June 14th and 18th in Amsterdam in the Netherlands with a remote option as well. React Summit definitely, uh, I've spoken with the organizers in the past and they seem quite great. I have not attended it myself though. [00:05:15]

React Nexus

Mo Khazali: At the very beginning of July, 4th to 5th of July, in Bangalore, in India, there's React Nexus. Now, last year I had the pleasure of attending React Nexus, and it was such a great community. [00:05:24]

I gave a talk then and really just an amazing level of energy there. I think it was about four or five, 600 developers all there. And I really felt like there was something unique about it. There was a lot of passion and a lot of drive there and people were just genuinely interested in learning. So really would recommend it if you're kind of near the South, South Asia area to definitely give React Nexus a try. [00:05:43]

Chain React

Mo Khazali: Around a couple of weeks after that, there's Chain React. So that's July 17th to 19th. That's in Portland, Oregon. Now, I haven't had the opportunity to visit Chain React, but I'm very close with some of the organizers of it, the folks from Infinite Red. I've met them here and there at different conferences, most recently last week, actually, and they are a lovely crew, are a lot of fun, genuinely so much energy and fun, and I've heard nothing but great things about Chain React. So if you're US based and can make it out to Portland, definitely would recommend going to Chain React. [00:06:12]

The Geek Conf

Mo Khazali: And then a week after that on July 25th, there is the Geek Conf. I happen to know these organizers because they're a key part of the React Native community, the folks from GeekyAnts, and they are hosting a conference in Berlin. So it's the first year that they're doing this and I'll be doing a talk there. So a shameless plug that you should definitely come around and we should hang out. [00:06:31]

But the Geek Conf is really kind of intersecting web and React Native, which I think is the direction that the ecosystem is going towards. They have some really great lineup of speakers coming around. Folks like Tejas Kumar and Bruno Polino and many others, not including myself there, which I don't consider myself to be a great speaker. So you should come for those folks, and maybe we can hang out in the process as well. [00:06:50]

Carl Vitullo: Let's jump into the main content then. [00:06:53]

React Conf Recap

Carl Vitullo: Obviously the main subject this month is going to be React Conf. They put up a post on the blog with a React Conf 2024 recap, which is phenomenal. [00:07:03]

Something I appreciate, they link to the section in the live stream where each of the talks happened. So appreciate that. I feel like so many conferences take weeks to get their conference recordings up. So just leaving the live stream up and linking to the talks. What a solution, it's so good. Something else I found impressive. The livestream recording already has 165, 000 watches. Nope, sorry, since I watched it last night, it's now up to 167,000, which is wild. [00:07:29]

They open with a recorded bit from the CTO of Meta and then go to Seth Webster, manager of the React team. And he just shouted out on Twitter after the fact, because he was getting some questions about his voice, he apparently had COVID and has had some enduring health effects as a result of complications from that. So I just thought it was really like powerful of him to take center stage, introducing the concept, knowing that that's his experience right now. So, I just wanted to shout that out. He put up a really good, a little explanation of it after the fact. And, I just thought it was really powerful. Wanted to give that a little bit of a signal boost. [00:08:04]

Mark Erikson: Nice to touch on the fact that there are real people with real human concerns involved in building the tools that we actually use. [00:08:12]

Carl Vitullo: Yes, the human aspect of React. But yeah. Let's also dig into some of the technical aspect of React as well. Mark, you want to lead us in here? [00:08:21]

React 19 RC

Mark Erikson: Happily. Pointing to a couple of the big announcements from the conference. The first one was that React 19 itself has actually gone straight all the way from beta to release candidate. [00:08:31]

I wasn't sure that they would even get to this step by the conference, but clearly they feel pretty good about the overall stability of, you know, what they've been trying to work on. I'm not going to try to go through all the various features and everything. If you've been listening to the podcast for the last few months, you've heard us discuss most of them at some point. [00:08:49]

And the blog post itself does actually touch on all the major things that are in there. Things like, you know, hooks for dealing with for the new HTML streaming capabilities for things like assets. A lot of different stuff in there and whether these are going to have direct relevance for your own application will always vary, but there's been a lot of time and effort put into all these different pieces and how they tie together, even strictly on the client side, beyond things like server components as well. [00:09:21]

Definitely worth taking a look at the RC blog posts, a great summary of what all is there in React 19. Related to that specifically, of course, there were talks at the conference that then went deeper into some of these aspects. Lydia Howley and Sam Selkoff both had talks that kind of gave overviews of the pieces there, especially some of the server component stuff. Worth watching those if you get a chance. [00:09:44]

Server Components on Expo

Mark Erikson: Along with that, there was also a talk from the Expo team and Evan Bacon talking about how server components might actually fit into the React Native side of things. Mo, you have any thoughts on that one? [00:09:55]

Mo Khazali: Yeah, so, this is something that the Expo team's been kind of silently working in the background for a little while, there was an interesting tweet that Evan had at one point. I think it was in a tweet exchange where he was like, if you look through my Git commits and my sort of hobby repos, you'll see the direction that Expo's going, because it's a very direct sign into my psyche. And you can see that he started working on this several months ago, and it's finally come to fruition. [00:10:15]

But they've kind of been trying to work out what server components mean in a React Native ecosystem, which was, it was a big question mark, I think, for everyone in the community, because traditionally mobile apps are client side, and what does it mean to have the server rendering native layer components and elements? [00:10:31]

I think they delivered on a phenomenal demo. There's still a long way to go before it reaches production and something that we can use, but really the core is that as long as there's sort of native layer supports for the right components, you can stream any JS that you want across the wire that's sort of serialized in the RSC way. [00:10:48]

And then that can render native layer components on the device, which is quite cool. And what that means is you can basically stream JS that can orchestrate certain native behaviors, like maybe showing a native share card or showing a contact card on someone's phone. Those are sort of native elements, but they can still be orchestrated and sent across the wire with JS. [00:11:05]

I'd really recommend going through and watching the demo that they had, because the majority of the talk is actually the demo, and you'll get a real good sense of what that means and what it would look like in practice. And interestingly, in the aftermath of it, it fueled a massive debate across the entire React Native ecosystem on the place where debates always get fueled, which is Twitter or X these days. It was a question of, because you can just basically send any JavaScript across the wire that will change how the app behaves, what does that really mean for Apple's terms of service? [00:11:32]

And there was a bunch of people who were like, this absolutely violates Apple's terms of service. Your app will get rejected. Why is Expo doing this to the community? Why are they putting them down a rabbit hole? [00:11:40]

And then other people saying, no, absolutely not. You can basically replace the entire JavaScript bundle today in React Native. So why should this change it? So interesting debates came out of it, but nonetheless, there's some exciting stuff going on. And I think we're just at the very tip of the iceberg so far. [00:11:55]

Carl Vitullo: Yeah, a couple months ago, I had presumed that server components were just not going to be a thing on React Native, and was very surprised that they had full plans to integrate and make them work, pretty much the same as how it does on web. [00:12:09]

So yeah, definitely worth checking out the demo to see how they get that going. [00:12:12]

React for Two Computers

Mo Khazali: On top of that, afterwards, there was a talk by Dan Abramov, where he went over the paradigm of React for two computers, kind of sticking with the server component mode and model. And it was a really primitive explanation. I really love explanations like this, where someone kind of breaks things down into the very, very basic primitives. [00:12:30]

Like you've got a web server. Here's how you can render HTML on the web and send it across to the client. Okay, what happens if we start to extract certain parts of this, separate them out and see how you can kind of construct React server components from scratch. I think Dan did a post on, it was something on GitHub that he posted, which kind of walked through the thinking for this talk, but really articulating it in a talk, put it into a nice story. [00:12:51]

It was quite fascinating. And I think it was a really good explanation for anyone who wants to really understand server components. I don't know if you had any thoughts on it, Mark, yourself, but I quite enjoyed that. [00:13:00]

Mark Erikson: A couple bits. He actually did put up a post earlier this year on his blog called The Two Reacts, which I think directly is, the exact same line of thought that led into this talk. [00:13:10]

If you've watched Dan over the last year and a half, he's been throwing a lot of ideas against the wall to see what sticks in terms of teaching people server components and the mental model that, and like, we're trying to figure out what mental model makes sense to both explain it and make use of it properly. [00:13:29]

The thought process here of, you know, it's expanding React to the server, but also it's still one React tree just split across two computers is something worth trying to wrap your mind around. [00:13:42]

Carl Vitullo: Yeah, I was just thinking of whether I wanted to share this under the React compiler notes, and I think I'll get deeper into it. [00:13:47]

But, I do think that this is a continuation of a pretty stable vision that the core team has had for React. From the outset, server rendering was something that was, you know, ostensibly possible to do with React. And there were many years and people were just kind of like wild westing it and doing it themselves and, you know, render to string and, Oh, cool. Now we can render a, you know, like a streamable HTML. [00:14:12]

This is not new, it's just a new attempt at solving the same problem in a way that does it better than previously. So it's just a, you know, it's one more incremental step forward. [00:14:23]

Mark Erikson: Yeah, I actually had a chance to talk with Ricky Hanlon while I was there in Vegas, actually, ironically, like five feet from where Carl's sitting right now, and he was talking a bit about, we didn't exactly know what the end state looked like, but we had a lot of intuitions about what it would feel like when we got there, and There, there was like partially a master plan, but also partially not. [00:14:48]

It was just, we think these are the big problems we need to solve along the way. And that's how we ended up in things like hooks and whatnot. Eventually those have led to the point where now the grand vision is kind of coming together. [00:15:02]

Mo Khazali: And I guess just to go in from the React Native perspective as well, me and Evan were having a chat about this at App.Js and a few other people as well were kind of echoing the same sentiment, which is it's been the same in the React Native ecosystem. [00:15:14]

Larger scale organizations have been using server driven UI, where you kind of describe your layout in the form of a JSON object and ship that through an API endpoint or from your CMS directly to define how your page is layouted. [00:15:27]

And server components on React Native as well are just kind of a continuation of that same paradigm of starting to move some of the layouting and some of the business logic of your front end app over to the server to kind of optimize it and also allow for more flexibility and better performance in many cases. [00:15:43]

Like you say, it's just a natural continuation, whether you're on web or on mobile. [00:15:46]

Q&As with React and React Native Core team

Mark Erikson: So, wrapping up a couple of the talk links here, there were also Q& As with both the React core team and React native core teams. I admittedly did not have a chance to watch these, but there's, I'm going to assume that there is material worth watching in both those sets of discussions. [00:16:04]

Carl Vitullo: Sadly, I missed it as well. There was just too many interesting people to have great conversations with. I did hear that, I saw like a kind of snarky, sarcastic tweet from someone on the, I can't remember who now, someone on the React Native team, saying something to the effect of, like, we dropped so many bombs in this React Native Q& A and you're talking about this? Just as sort of a meta commentary on the Twitter discourse. It sounds like the core team thought that they got very deep in the weeds talking about some of the, talking about the technical details. [00:16:33]

React Compiler

Mark Erikson: All right, moving along to another fairly sizable announcement from the conference and something I've been very eagerly waiting for it at the point that I almost stood up and did actually cheer when it happened. [00:16:43]

The long awaited React compiler is now actually both open source and usable. Finally! The React team had been promising that it's real, trust us, it works. And they'd said at a couple talks last year that, you know, we're trialing it in production in a couple real Facebook sites. [00:17:03]

It is now open source. You can now actually use it. And they've dropped a lot of information about how it actually works as well. So it's now actually officially listed in the docs. And there's instructions for setting up and using it. It's worth noting that in its current form, the way to use it is as a Babel plugin, which means that ironically we've been doing all this work to switch our build tooling over to Rust, and suddenly we might actually need to re add Babel, just to get the compiler to work. [00:17:31]

Having said that, the compiler itself is like 90 percent it s own code, and it's really just using the Babel plugin layer as a way to manage the parsing of the code. But they've even played around with an eventual rewrite of some of the compiler logic in Rust. Um, there will likely be other alternative ways to load it into your build system down the road. [00:17:55]

So, it's not like it's Strictly built out of Babel. One really neat piece is that they actually have a live playground. If you ever went to the Babel website, Babel has a playground that shows you, if you write some JavaScript code and have certain compilation settings activated, here's what the output looks like. [00:18:14]

They've got a playground for the compiler as well. And I think this is really valuable on multiple levels. One, is that it literally shows you what the output will look like, so you can get a sense of the transpiled code without having to do an actual build step. It also actually has a set of vertical sidebars which show you what the actual compiler internals are outputting at each step of the transformation process. [00:18:43]

The compiler itself is awesome. A real, no kidding, deep compiler, like, with all the, you know, real world compiler optimizations. And so getting a sense of both what kinds of passes they're doing and what the results look like, I think is really cool. There were a couple of really good talks at the conference about it. [00:19:01]

Lauren Tan did a kind of a usage walkthrough, you know, let's add it to a project. Let's use it. The React DevTools will now show you if certain components have been optimized. She even had written her own little proof of concept VS Code plugin that would show in your editor if certain components were being optimized. That's not actually available yet that I know of. They may end up releasing like an official version of that VS Code plugin at some point. [00:19:29]

Meanwhile, Sathya and Mofei, also on the compiler team, did more of a deep dive into how it works. And Mofei in particular did a live coding demo where she showed like, let's actually write a little Babel plugin that makes use of some of the compiler internal, and see how the output of it changes as they add each piece of the compiler logic to it. [00:19:50]

One more good explainer, Jack Harrington had a chance to do, I think, both a video and a blog post where he walked through using the compiler and talked about some of the usage changes and the mental model aspects. I think one of the big pieces for people to understand is that this does several different things. [00:20:10]

One is it adds like the dependency array aspects to useEffect, useMemo that we've always kind of wanted so we don't have to do it ourselves. [00:20:18]

Another is that it overall optimizes the rendering performance of components. But on top of that, it kind of flips the mental model of React rendering on its head. [00:20:29]

One of the big things you've always needed to know is that React renders recursively by default, and now the compiler flips it, so that finally, only components whose data actually changed will re render. So this is a big deal. [00:20:42]

Carl Vitullo: Yeah, I also saw on Twitter, just sort of an open question that I thought was a good one to ask. [00:20:48]

Jamie Kyle asked if library authors were going to be expected to ship components and hooks pre compiled. And Sathya responded that like, yep, they're just like all of the other transpiling, compiling in the ecosystem. You know, if you're authoring in TypeScript or Flow or, I can't think of any other compiled things off the top of my head, then yeah, so you published the compiled artifacts to npm, so I thought that was worth calling out for anyone here who might maintain a library. [00:21:17]

Mark Erikson: It's worth noting that the compiler output does expect to use a new hook that is, strictly speaking, only available in React 19. Having said that, there is a very simple polyfill. [00:21:31]

It's really just a useMemo that allocates an array. That polyfill ought to make the compiler's output work if your app is still on React 17 or 18. So, in theory, you could drop this into an existing React 17 or 18 application and still get the same performance benefits. Which is nice because, you know, basically nobody's on React 19 yet. [00:21:54]

Mo Khazali: I guess in terms of another small detail as well, to keep in mind if you're trying to add this in, is the React compiler, as far as I'm aware, expects for you to list it as the first Babel plugin in your config, and the idea with there is they want to have the state of your code base before any other plugins mess around with it and transform it. [00:22:12]

So, it's, that's just a little gotcha in case you are trying to integrate it. Just now into your app, hearing about this. [00:22:18]

Mark Erikson: And again, with Carl, with what you said earlier, it's, this is a vision that the React team has had for a while. You know, they, they'd said early on that they designed the hooks APIs, you know, specifically the dependency arrays under the assumption that someday a future magical compiler could do that for you. [00:22:36]

They honestly weren't sure if, and when they would ever get around to it. And it was pointed out that they didn't have compiler expertise on the team. At the time that they were making that assumption, but that was a thing that they assumed would eventually happen. You know, they played around with a proof of concept compiler called prepack years ago. [00:22:54]

That attempt didn't work out. And even this current compiler took a couple of different attempts to really figure out what they, what it was supposed to do and how they were going to do it. But the thought process of we could use a compiler has been around for a while. A couple other quick notes to wrap this up. [00:23:12]

Lauren Tan did a talk all the way back in 2016 that has kind of a couple indirect precursors to the thought process of the compiler and using it. They apparently used it in the official React Conf app. And the BlueSky Twitter alternative is already using it in production, partly because Dan works on BlueSky now. [00:23:32]

And also the React core team added it to BlueSky to help prove that it would work in a separate real world application. [00:23:39]

Remix is merging (back?) into React Router

Mark Erikson: I'll toss out one other announcement that came out of the conference. So Ryan Florence did a talk where he announced that Remix and React Router are merging, sort of, conceptually. [00:23:51]

The way he put it is that Remix itself, at this point, is basically just the latest version of React Router plus a Vite plugin that adds the actual build steps. And so, rather than continuing to put more things into the Remix packages specifically, they're just gonna move a couple more things over into the React Router packages, label that React Router v7, and it has an optional Vite plugin if you want to do server usage. [00:24:21]

Um, this of course was met with much confusion and complaining on Twitter. Personally, it makes sense to me. And it's worth watching Ryan's talk to get a sense of why they're going this way. [00:24:32]

Carl Vitullo: Yeah, and this was surprising. I won't say that it wasn't surprising. I just thought that, like, Remix, I mean, they're a venture backed business. They got acquired by Shopify. I am surprised to see them say that Remix is just not going to be a thing anymore. For that, for those branding reasons, branding and funding and,[00:24:49]

Mark Erikson: The caveat there is Ryan said in both the talk and the later blog post that they put up, like, we have more plans for Remix as both a brand and a set of tools that we want to circle back to in a few months. [00:25:05]

Like, we have some idea of something new we want to do with it, but for now the focus is like, let's just roll all this stuff into the next version of React Router and then you can pick and choose whether it's just doing client side stuff or server side stuff too. [00:25:19]

Mo Khazali: And I guess on the Shopify piece, Carl, I'd love to get your thoughts, but I feel like Shopify kind of achieved what they were trying to achieve with Remix, which was ultimately they took it and made it the backbone of Hydrogen, which was their own sort of, I guess, framework, so to speak. [00:25:33]

And it's great if you've ever used it to make a Shopify app. I don't know if that, maybe they're looking to get more out of it or not, but I feel like it probably achieved at least some of the purpose of why they, they, backed it as a framework and invested in it. [00:25:44]

Carl Vitullo: That's true. Yeah. And I guess, actually, I don't know this, but I think it was an acqui-hire, they started working at Shopify? Yeah. So that, that certainly makes sense, Shopify got their value out of business transaction for sure. But, so I guess, as surprising as it was to me for them to announce that they're now moving back to React Router as their primary brand for the work they're doing right now, they also have a long history of doing things like this. [00:26:09]

The React Router folks put out React Router and then they've done at least one, I think, departure that sort of builds on because they had done Reach router for a while because they had some new concepts that they wanted to explore. And I think that is a phenomenally responsible way to approach public experimentation in an open source setting. [00:26:30]

They have a large enough audience that if they announce a new project, people will give it a shot. And I think it is so smart, in terms of, like, branding and messaging and, managing expectations, I think they are tremendously smart and thoughtful about how they use brands, because, you know, you can do, like, a major version, you can do a beta or an RC, or, you know, do, like, an experimental phase in a project, but I think it is really great and honestly kind of them to the community to say like no This is different enough that we are giving it a new brand and we're gonna experiment and then now twice now They've said "cool, we learned a bunch of stuff and we're just gonna bring it back, now it's just React Router again." [00:27:12]

So because React Router specifically React Router is such a like foundational part of the Ecosystem. Like, you know, the React team has never blessed a routing tool to use with React. So it's, they've always just been the de facto one to use. And I think it is really marvelous that they have taken that position with such seriousness and done this kind of thoughtful experimentation with it. [00:27:38]

Mark Erikson: I can vouch that naming and branding and getting people to migrate is a really hard problem. [00:27:45]

Carl Vitullo: I want to call that out, I think it's really clever and smart and, just having been in the ecosystem since 2015 and watching a lot of thrashing and watching a lot of arguing on Twitter about like this and that and the other, I think they've been really consistently great about, once all the dust settles, at the time it was kind of confusing, but so I guess I want to be the voice that's like," it's going to be okay." [00:28:08]

Effect JS

Carl Vitullo: Okay, moving on to the next subject, I guess. This was a subject that I almost brought in on the last episode and held off because it seemed a little bit too out there. But I dug into it a little bit over the last month. [00:28:19]

Effect, they have released 3. 0 and they are now calling it production ready. It, it had crossed my radar in April with some people asking folks like Kent C. Dodds and other prominent educators, what they thought about it. So, and the consensus I saw then was like, looks neat, but it's real big. That's a lot to learn. I'm not, I'm not dipping my toes in yet. [00:28:41]

And basically what I understand it to be is a, it's almost a standard library for TypeScript, but it's also. Like a functional programming kind of paradigm, like it introduces new concepts for all the way down to console. log. So there's a fetch replacement. There's a console. log replacement. There's a promise replacement. It's an enormous surface area for the API. So in a very real way, it's like learning a new language, which is why I held off on this, because it's a Big swing. [00:29:15]

It is an enormous swing. One of the reasons I decided to bring it in is that I learned while digging into it that Johannes Schickling is one of the people backing this, one of the creators of the project. And he's been, I can't remember what his first project was. I've been following him for, it feels like forever. He was the founder of Prisma, which was a very influential ORM, schema declaration model. [00:29:40]

Mark Erikson: He's done some GraphQL stuff, and I actually had a chance to meet him in person back in December, and one of the ideas he's been playing around with is like a local first application where every single bit of the code from fetch data to literal client side state is held in an in memory SQLite database. [00:29:59]

So, like, rather than a bunch of used state hooks, he's got, like, reactive hooks that tie into SQLite running as WASM in the browser, and literally every bit of data in that example. is coming straight out of that SQLite database. Which sounds odd, but when you see it in practice, it's like, oh, I can see the intent behind why he's playing with this idea. [00:30:22]

Mo Khazali: I don't know if you folks recall Project Lightspeed, that Meta did a few years ago, I think it was like 2019, 2020. With the messenger app that they did, it was a very similar approach, which was everything on the client side is backed by SQLite database, the data fetching, the layouting, the local state. So I don't think it's an, it's that odd of a paradigm. [00:30:40]

It sounds like a, it could be a good scalable way to handle things. So interesting to hear that somebody else is like digging into that vision, Mark. [00:30:47]

Mark Erikson: So with the effect thing, like I echo what you're saying, Carl, is like, just trying to describe what the project is. And a couple bullet points is hard. If I could attempt to restate what you were saying a minute ago, it's multiple different pieces. [00:31:01]

One is that there's some similarity to the Redux Saga package, where instead of using Async await syntax, and actually kicking off things like async requests right now, I think your code uses generators and generally returns descriptions of like what kind of side effectful behavior you want the code to execute. [00:31:26]

But nothing actually happens until you return those descriptions to some kind of runner that actually goes off and does the work. Another aspect is that instead of relying on throwing errors just from any piece of the code, you actually end up specifying at the type level that this function could return a number and could throw a, like, could not parse integer error, or something like that. [00:31:54]

And so you, like, it's a very, like I said, functional programming way of modeling code. Returned values versus possible thrown errors, and they have an entire JavaScript standard library built up because as we all know, one of the weaknesses of the JS ecosystem is we don't have much of a standard library built into the language itself. [00:32:17]

And there's a whole bunch of primitives around async concurrency. So things like retries and, you know, iteration, backoffs, and that sort of thing. So, like, that, as usual, I've not played with it, I've only tried to skim over the docs, and, yeah, like, my own reaction is like, Wow, that's a lot, I can't even wrap my head around this, but I think that's the best description I can come up with, and I think I see where they're trying to go with this. [00:32:45]

Carl Vitullo: I did dig around a little bit more than trying to read the documentation. I was directed to, a wonderful 10 minute introduction about it. That was what really sold me, and I'm like, yep, okay, we're gonna talk about this. So I definitely recommend checking that out. Um, from Ethan Niser, yeah, just, it's a great 10 minute introduction. [00:33:02]

And going back to Johannes Schickling, he gave a, an hour long talk titled Production Grade TypeScript at, they put on a conference, they put on a conference already, Effect Days 2024. It was also great. It was much deeper in the weeds. At one point he said, like, "I'm sure that a lot of people watching this talk on YouTube are going to be angry I'm not explaining what effect is." And I was like, dang it, that's me. I wanted to know what effect is (laughter). But it was a great talk besides that, uh, it just didn't quite answer the question I was hoping for. [00:33:32]

If he's got bona fides in, like, querying, schema, GraphQL, as well as local first, like, to me, those both extensively deal with the hardest parts of asynchronous behavior, with, like, retries and backoffs, like you were mentioning. So that is A lot of very deep experience with some very hard problems. [00:33:53]

And I do love local first. I think it is an absolutely wonderful paradigm and it is very challenging right now. So if we end up getting a relatively widely used and supported standard library that makes things like exponential backoff and retries and responding to different kinds of errors in different ways. Then. All of the myriad things that make asynchronous behavior difficult, then that sounds pretty cool. [00:34:19]

I'm pretty excited about it. So, I don't know, that's, that's all I will say on effect. [00:34:23]

Forensics of React Server Components

Mark Erikson: All right, moving along. We've discussed and linked to a lot of articles over the last few months that attempt to dig in and explain various aspects of React server components. [00:34:34]

What are they? Why would you care about them? How do you use them? How would you even go about building your own server components based framework? [00:34:42]

And we want to point to one article along those lines this month, the forensics of React server components. This one does a really good job of laying out a lot of the different pieces and how they fit together. [00:34:54]

It talks about, you know, client side rendering and kind of illustrates some of the data fetching and rendering workflow, server side rendering, and how data gets fetched on the server and rendered and loaded into the client. Hydration and servers and some of the issues with that, and then goes and digs into server components and kind of walks through a lot of what the data flow and mental model of where data and where server components fit into the life cycle, how the data fetching behaves, the interactions between server components and client components, and even shows some examples of the serialized output that server components return. So, it's a pretty good one stop shop for kind of wrapping your head around some of the actual usage and mental model of server components. [00:35:39]

Next.js v15 RC

Carl Vitullo: Okay, uh, Next15 has an RC coming out, or that is now out. [00:35:44]

Not entirely related, but I did see that Vercel has now raised 250 million dollars. So they are capitalized for a good minute longer. They're not going to go out of business anytime soon. [00:35:54]

But yeah, Next 15 supports React 19 and the compiler, they have changed their caching behavior pretty extensively, which I had understood to be one of the bigger pain points of using the app router. They have an experimental API called Next After, which solves a problem where you can schedule work to be processed after the response from the server has finished streaming. It solves the problem of needing to figure out, needing to guess when the response has come in. I think that's pretty neat. [00:36:22]

They also have a neat feature, they call it partial pre rendering, it is neat looking to me. They say, you can wrap any dynamic UI in a suspense boundary, when a new request comes in, Next will immediately serve a static HTML shell, then render and stream in the dynamic parts with the same HTTP request. That sounds a lot like out of order streaming that I had heard some stuff about in the past. [00:36:43]

I mean, that's always been the dream of server side rendering is you make a request, you immediately respond with something, so it's not just a blank screen and then fill in the rest of the bits. So it seems like a clear improvement to me to be able to do that in a single HTTP request without having to open a new connection and do all the TCP handshaking. So that, that should be a pretty good performance improvement. [00:37:05]

It's not just you, Next.js is getting harder to use

Carl Vitullo: I just wanted to call out an article that I saw entitled, It's Not Just You, Next. js is Getting Harder to Use. It just kind of calls out the increasing complexity of the framework. It's a little pessimistic, it's a little down note, but I think it's reasonably fair. [00:37:20]

Just to call out a couple of sections that seemed worth it to me. You need to understand a lot about the internals to do seemingly basic tasks. There are many ways to shoot yourself in the foot that are opt out instead of opt in. This is just a funny bit talking about like, you know, you go to a GitHub issue and you see an explanation of why that thing that you want to do isn't possible and go like, "oh, that does make sense." But they say, you probably read this and left with five more things to Google before realizing that you probably have to restructure your code, which is Brutally familiar. [00:37:49]

So, and on the app router, if you started a Next project, Next will default you into it, which implies that it's production ready. It implies that if you're starting something new that you're going to ship to production, you should use the app router. [00:38:02]

But this article calls out, "the official React docs don't share that same sentiment. They currently recommend the Pages router and describes the app router as a bleeding edge React framework." So, it seemed like a really good, really fair. Non complementary discussion of Next. [00:38:17]

Mark Erikson: I've seen a number of folks complain that the app router works great for the layouty stuff, but some of the integrations have been both buggy and somewhat hard to use. [00:38:28]

One comment I saw was the effect that, ironically enough, the app router Works better for static pages and the pages router works better for applications in terms of data fetching. So the names almost seem a little bit backwards, ironically. [00:38:43]

Mo Khazali: I don't know about you folks, but when the App router came out and you know, I've gotten more and more used to it as time passes, but I just found that the pages router, even just things like being explicit with, you know, whether you're doing get server side props or you're doing get static props, just found that I love the fact that it's explicit, so at least you as the developer have to explicitly define how you want sort of that page to be rendered, rather than sort of the automated, magical nature of the app router. [00:39:08]

I do miss that sometimes, but there's also a lot of benefits to having the app router, so I guess it's, as with all things, there's trade offs with it. [00:39:15]

Mark Erikson: All right, Mo, you have a lot more expertise on React Native than either the two of us. Want to hit some of those highlights? [00:39:21]

React Native New Architecture beta

Mo Khazali: Let's jump into it. So let's start off with Meta news. Firstly, we've been hearing about the new architecture for years now, if you've been in the ecosystem, uh, but they have officially put it into beta, which is a big deal if you've been here for a hot minute and the word on the street unofficially is that we might finally see it going into production or going into default and out of beta sometime this year. We'll see if that happens, but it'd be very exciting. [00:39:46]

The good news with all of this is there's more and more, uh, Third party libraries or open source libraries that are coming with new architecture support. And I think that's the real bottleneck right now is one having a good interop layer, which the folks shipped last year from the meta team. [00:40:00]

So that helps kind of ensure some level of backwards compatibility, whether it's with the layouting engine or with the rendering engine, but I think it's a really good step that they're going into beta and soon more and more libraries are going to support new architecture. [00:40:12]

There was this massive Google Sheet that just had all of the libraries that currently support new architecture that are commonly used in, in, in the community and some of the ones that don't yet. So it's, it's going in that direction. I think everyone's trying to push and get, get it finally over the line. [00:40:25]

Mo Khazali: Uh, in other news, Meta, both in React Conf and also at AppJS did kind of similar talks about how you should use a framework. So if you've been in the React space with Next, you will be familiar with this. Very much, but the idea here is that they've officially came out and endorsed that you should use Expo by default. [00:40:43]

And this isn't anything new. If you had been frequenting the React Native docs for the last couple years, they give a nod to Expo here and there, they use Expo Snacks for the coding examples, and they kind of make points to say you should go and check out Expo if you're starting out a new app. [00:40:59]

Um, but now they've explicitly said, you know, you should use a framework for the same reasons that you see in the React ecosystem. Routing, um, tooling, and having the right ecosystem in place, which I think is a great step because it really, using something like Expo really saves developers a lot of, uh, hassle and a lot of difficulty that you oftentimes face if you're just on a bare React Native project. [00:41:17]

React Native Skia on WebGPU

Mo Khazali: Now, going into community news, these things are fresh off of the press, predominantly out of App. js that happened last week. So, the first thing that I think was incredibly exciting was that we got some updates on React Native Skia. React Native Skia has been a 2D rendering sort of canvas that you can use in React Native to draw graphics, nice animated graphics, sometimes interactible graphics if you want to integrate it with things like Reanimated or GestureHandler. [00:41:43]

The announcement for this was in some ways the most amazing and also the most sort of cheeky announcement possible because it was sort of Apple esque intros with sort of rainbow colors going to form a hello and really just showing that they're very much great graphists at heart that are working behind this. And Skia is backed by Shopify as well. So it's got massive backing. It's a great project. So you should definitely check it out. [00:42:05]

Previously Skia was mainly used for 2D graphics. So it gave you a canvas. You could draw things on it. And people had I've been using it to kind of extend the boundaries to create what they call 2. 5D, which is 2D graphics that kind of resemble 3D, and through the illusions of looking at it, they kind of look like they're 3D, but they're still just rendered on a 2D graphic, uh, and this has a few limitations, it runs on the CPU, it's not really truly 3D. If you want to do anything like interactivity with it, you're quite limited by sieve there in terms of your performance. [00:42:35]

And hence, the talk that they had at Appjs was called Hello GPU. So first they started off saying, ah, there's video support now, so you can do a whole bunch of shaders on videos, which was quite cool, but really the key thing that was exciting was that they actually brought WebGPU into the React Native world. [00:42:50]

So you can use WebGPU to obviously target web, uh, with React Native Skia, if you're using React Native on the web, but you can also use it for iOS and for Android and having those sort of cross platform 3D visualizations and rendering, I think is going to be really cool for the community and not something that we've actually been able to do very effectively on the GPU layer. [00:43:09]

And they've integrated all the way down into the native layer APIs, so, Metal on iOS as an example. Especially with something like React Native running on Vision OS, where you really want to have these 3D objects that you kind of put in your vicinity in the spatial navigation paradigm. [00:43:24]

It will be so cool to be able to actually use that as well for VR and not just on Vision OS, but also maybe on some of the Quest runtimes and so on and so forth. So I think it's, it's a really cool step and it stops us from having to drop into the native layer as we've often had to do with this type of thing. [00:43:39]

React Native IDE

Mo Khazali: Next up on the announcements from AppJS, we saw the React Native IDE. So this has been kind of teased by the folks at Software Mansion for a long time. We've had a lot of sort of disparate tools in the React Native ecosystem. You know, when you're usually developing with React Native, you have to have your terminal running your Metro bundler and then maybe have Some Chrome DevTools running connected to the React Native DevTools to kind of, uh, your network requests coming in and analyze your source code. [00:44:04]

And then if you want to dig in and look at what elements are being rendered, where it's all really just sort of a bunch of different parts to the dev experience. And it's not been amazing. There's obviously been a lot of improvement. And if you come from the native world, sometimes those things can be a lot more integrated with Android Studio and Xcode. [00:44:20]

And so the lovely folks at Software Mansion have developed an IDE and it does some really cool stuff. I won't go into too much details. It does everything you would expect from an IDE. And I think it brings first class DevEx into the React Native world. It's going into beta or went into beta last week. [00:44:34]

And the coolest thing out of all of the demo was debuggers across the native boundaries, so when you put in a debugger, it not only could handle debugging on the JS code that you write, but you could also place debuggers inside of your node modules on the iOS Swift code, or maybe your Android code that you have written in Kotlin, which I think is really cool, because one of the challenges is you're kind of fiddling between Xcode and Android Studio and also Visual Studio Code, And this brings it all into one place, which is really quite exciting. [00:45:03]

React Native on TVs

Mo Khazali: And then the last thing that happened around React Conf, and they nodded at it again at AppJS, was around Amazon doing a keynote talk about using React Native beyond web and mobile. And so Amazon has started becoming a big proponent of React Native in general, but also React Native on TV specifically. [00:45:20]

And they have actually been using React Native for years now. They kind of hit it very cleverly where you couldn't really see it on first glance in the app binaries, but they came out with a big bang announcement last year saying we have actually been using React Native for a very long time, and it's been most of our apps. Huh. Gotcha. [00:45:35]

And so it was quite a nice announcement in that, well, there's more people using React Native and that's always a good show of faith in the technology for the community. But it was quite funny that they hid it for so long. [00:45:45]

Amazon obviously does a lot with Firesticks and TV devices, and their OS is based off of Android. So you can build TV apps for it with React Native. And I think they're very keen on people using React Native just because of its cross platform nature. They talked about many different things, challenges of performance and spatial navigation on TV. One thing, if anyone is interested in React Native for TV, a bit of a shameless plug here, so I apologize to you both, Carl and Mark. [00:46:12]

Mark Erikson: Shameless plugs! Gasp! [00:46:15]

Carl Vitullo: Who does those?? [00:46:16]

Mo Khazali: Questionable on my, on my character there, I'm so sorry, folks. But, as part of like some of the community stuff that, I've been doing with some of the folks from Amazon. We actually started an RNTV.dev blog, and it's kind of meant to be a centralized resource for everything about React Native on TV, because that doesn't exist. We thought, why not make it so that we can help people onboard into it more and more. [00:46:36]

The other last thing that they kind of dangled was they said, we want to support open source projects, especially ones on React Native for TV. So if you're interested and you've got a project that's extensively used on React Native for TV, Sign up for this form and we're gonna be, start starting to sponsor more and more projects on the React and React native ecosystem. [00:46:53]

So if you're a community maintainer, wink wink, you might wanna check that out and see if there's something that you can, uh, get some support from them for. [00:47:01]

And that is all of the React native stuff. Sorry folks for going into that rabbit hole. [00:47:05]

Carl Vitullo: No, thank you. That's, we have a dearth of React native expertise on our end, so I'm very glad you can speak to it. [00:47:11]

It's cool to hear more about the React Native TV stuff. Cause a couple of months ago, Oh God, probably a year ago now. I spoke to Kaleb McKelvey, I want to say it is, about React Native on TV. [00:47:24]

In that setting. And it was a fun, interesting talk. It's an interesting input paradigm. You know, a remote control is very different from a keyboard or a touchscreen. [00:47:33]

Mo Khazali: Yeah, it's really quite tough, Carl. Like, you know, we're used to touch displays or, you know, cursors on the web or the pointers or whatever it is. And then you're really suddenly limited to up, right, left, down, and a select key. And you're like, Oh, wow, how do I, how do I, what happens when I press down and I'm at the end of a carousel? Like, it's just so much, like, undefined behavior that isn't standardized. So, it's definitely a cool engineering challenge to delve into if you want something new. [00:48:01]

Carl Vitullo: For sure. It's a funny, stateful mode of input. [00:48:04]

Mo Khazali: Yeah 100%. [00:48:04]

⚡️ Lightning round ⚡️

Carl Vitullo: Okay, cool. On to the lightning round. [00:48:07]

Speculation Rules API in Chrome

Carl Vitullo: I'll take the lead with some new Speculation Rules API in Chrome. This was a new term to me, Speculation Rules, but so this is apparently finer grained control over how Chrome will prefetch pages. [00:48:22]

So this lets you more clearly signal to the Chrome browser whether and how it should try to prefetch something as a user, like hovers or begins to click, things like that. [00:48:33]

Josh Comeau's post on useDeferredValue

Mark Erikson: Josh Comeau put out a, yet another one of his incredible blog posts. I mean, basically every blog post or article that Josh Comeau ever writes is amazing. [00:48:42]

And this one was on snappy UI optimization with the relatively new React use deferred value hook. Now this came out in React 18, so it's actually been out for a couple of years, but frankly, almost nobody knows how to use this, including myself. And he pointed out that it's almost like a built in debounce for re rendering with a lower priority state update. [00:49:06]

And so he gave some examples of a feature on his own blog or site that really benefited from moving some expensive calculations and rendering. In debouncing them via used, used deferred value and it really improved the smooth smoothness and snappiness of the ui. [00:49:24]

BlueSky engineering culture

Carl Vitullo: Cool. I saw a pretty solid looking article from the pragmatic engineer about BlueSky engineering culture. I am all about BlueSky. I would love it if they are successful. And I always love a deep dive into engineering culture and, uh, you know, a white paper, as it were, of how an engineering team operates. So I thought it was pretty neat. For instance, they have two to three person teams with a directly responsible individual and lots of long form writing. [00:49:53]

So it's like little things like that, I think are really cool to, you know, it's the, in our careers, we get so little, opportunity to experience different types of workplace cultures. So I think articles like these are super valuable for understanding whether there is something better for you out there. [00:50:11]

So yeah, go check it out. Also, Dan Abramov works there, so you can learn about how Dan Abramov works. [00:50:16]

Why Patching Globals is Harmful

Mark Erikson: Let's see, Artem Zakharchenko, uh, his handle is kettanito, he's the creator of the mux service worker tool. Put up a post called, Why patching globals is harmful. And, you know, sort of in response to, you know, some of the, the React and Next teams a couple other teams as well, suggesting that, like, we should patch globals automatically in various situations. [00:50:38]

And his whole sales pitch is that, especially today, like MockServiceWorker just uses standardized JavaScript interfaces for doing this behavior, and we've collectively learned that patching globals is a really bad thing. So, you know, some useful food for thought there. [00:50:54]

New Webkit features in Safari 17.5

Carl Vitullo: There was a great post from New WebKit Features in Safari 17. 5. [00:50:59]

This caught my eye just because in so many cases, Safari is the last browser to implement something. So seeing oh, Safari implemented something, just caught my attention as like, Maybe we can use this now. It looks like Firefox is still a bit of a laggard on some of these features, but, there's a light dark function, light dark as a CSS function, which is a bit of a simplified developer experience for doing dark mode. [00:51:25]

So it previously there had been a media query for, I believe it was prefers dark mode. That doesn't sound right, but there was a media query where you could apply different styles if the user had a setting for preferring dark mode. This is now a function that does effectively the same thing. So, This is a solid improvement because with the media query, you pretty much have to like copy an entire style block. [00:51:50]

Whereas this you can just do inline, like if somebody wants a dark mode, you get this color. If somebody wants a light mode, you get this color. Just boom, nice little either or that you can do right in line. So I thought that was great. [00:52:01]

This is, I cannot believe that we are only just now getting this in 2024, but we now have text wrap balanced, where you can tell CSS that you want, for instance, a title of a document to stay balanced instead of like, this goes deep into design and typography. It's a classic problem of designers saying like, well, hey, on certain screen sizes, we have a dangling word here. Can we just fix that? And the answer for so long has been, "no, that's really hard." So now we have a CSS rule that lets us give better control over how text wraps. So that's wonderful. [00:52:38]

Mo Khazali: And I think there was a React library that was dedicated to this exact thing for the longest time. So it's cool. [00:52:44]

Carl Vitullo: That's why — cuz it's so hard. You needed JavaScript. You needed to like measure the characters and like know what font you're using. [00:52:52]

Mark Erikson: This is, this is a place I will legitimately happily use the platform. [00:52:56]

Carl Vitullo: Right? It's such a core part of designing a web page, like how does the text wrap? It's just so outrageous to me that it's 2024 and we are just now getting some mode of control of it that doesn't require JavaScript. And it didn't even work well in the past because you like, measuring fonts was not easy on its own, so that was weird. [00:53:15]

Mo Khazali: I'm going to rabbit hole again. You should have seen the, uh, Next. js implementation of that, because how do you consolidate the server rendering of the balanced text from the, it was, it had a whole, I went into the cores of that library, uh, massive rabbit hole. It was so funny to see how much work had to go into just getting that working on Next and on React client side. [00:53:33]

Mark Erikson: Part of me wants to go look and the rest of me doesn't want to. [00:53:36]

Mo Khazali: I will send you the link. Yeah,[00:53:37]

Carl Vitullo: we'll put it in the show notes too. Haha. Cool. [00:53:40]

And they also, there's also an app starting style rule for things like entry transitions, which is great because we now have a lot more options for entry transitions because stuff like popovers and modals are now entering the platform as well. [00:53:53]

Cool. Love it. Here for it. That's all I got. [00:53:56]

Why React Query

Mark Erikson: The folks from the UI. dev educational material site have put up a post that talks about why React query. I always love historical posts or posts that explain like, here's an abstraction, why does this extraction even exist? Like what work is it doing for us in the first place? [00:54:15]

And so they kind of walk through like, okay, if you were to actually just fetch data inside a component, here's all the work you have to do it correctly. And, oh look, React Query actually does all that work for you. Same thing for RTK Query and Apollo and SWR, in principle. They put up this in support of their new upcoming React Query course, which I believe has been written by the current maintainer of React Query, Dominic Dorfmeister. Knowing that and knowing the folks behind UI. dev, highly endorsed, even though I haven't actually looked at it. [00:54:45]

We can have a different web

Carl Vitullo: I saw a wonderful post from Molly White, who I am most familiar with her writing on looking at Web3 through a skeptical lens. [00:54:54]

Mark Erikson: Web3 is going great. [00:54:56]

Carl Vitullo: Yes, right. Her blog, Web3 is going great. She is a wonderful writer. She just gives great incisive commentary on Web3. She has put out this post titled, we can have a different web, it caught my eye. Because Web 3 took that moniker as trying to, kind of trying to ape the, like, Web 2. [00:55:13]

  1. They're like, well, Web 2. 0 is dead. We are now Web 3. And what a shame that only refers to kind of scammy cryptocurrency projects. I guess now I'd love to see like a Web 4. I know Block, briefly, Tried to do web five as a branding thing. [00:55:27]

Mark Erikson: Let's do the Winamp thing. It's like version two, version three, version five. [00:55:32]

Carl Vitullo: Yeah, right. If we could have Chrome just shout at you, it really whips the llama's ass, that would be great. [00:55:38]

But yeah, so, okay. This is, Molly White put out this great post. We can have a different web. Just talking about the local Maxima that we've found ourselves in. as users of the internet, you know, sort of bemoaning how if you search something on Google, you used to be able to find it. [00:55:54]

I think one of the points she makes that is important and nice is that all of those things that people loved about like the good old days of the internet, they're still there. It's just a little bit harder to find them. So sort of her claim is like, we can still have that. We just, you know, there's, needs to be a little bit more. [00:56:09]

I just definitely recommend checking it out. It tickled my brain a little bit because obviously I've been thinking a lot about community and communities of developers. And so we can have a different web, what is just a very exciting subject to contemplate for me. So definitely recommend checking that out. [00:56:23]

Mo Khazali: It just briefly also reminded me of the work that the folks at ARC are doing with the browser company with the new browser that they've released, ARC, that's based on Chromium. But, you know, I think they're also trying to kind of re envision what it means to search for something on the web where. And integrating some level of generative AI to pull everything and kind of give you a summary and signpost you to the right links so it's less overwhelming than searching on Google these days. [00:56:46]

It's definitely an interesting take. I think other people are also struggling with that same problem and trying to tackle it. Or we could go for a fully decentralized internet on everyone's phones. A certain TV show might have tried to spin that idea. [00:56:58]

Mark Erikson: A Black Mirror reference? [00:56:59]

Mo Khazali: No, I was, I was referring to Silicon Valley with Pied Piper. [00:57:02]

Carl Vitullo: Ah. No, Pied Piper. Okay. Yep. I also thought Black Mirror. So that says something. [00:57:08]

Mark Erikson: So Christoph Nakazawa, who some folks might know as one of the long, I guess, previous maintainers of Jest while he was working at Facebook, has gone off and created a 2D strategy game sold on Steam called Athena Crisis. [00:57:23]

I think it has some influences from, like, Advance Wars and that sort of genre. He built the entire game using React and CSS. And even though the game itself is, like, genuinely being sold on Steam, he's gone and open sourced the vast majority of the codebase. I had a chance to hear him talk about it a little bit while I was at React Conf, and he's even done things like putting up bounties for people to, like, improve the AI, or add new features to the map editor. [00:57:52]

Someone added, like, a tile mirroring feature so you can, you know, create maps that have, like, equal challenges for all the players. And so, his explicit goal was that, like, look, you know, maybe there's people out there who want to get into some kind of game related programming. And while this isn't like a 60 frames per second shooter style of game, there's still aspects of building a game that people might be interested in learning about, and they might be coming from the React community. [00:58:19]

And so by open sourcing this code base, folks can actually, you know, dig inside and learn and play around with it. So, you know, like kudos to him for taking that approach. [00:58:29]

Carl Vitullo: I also want to shout out that if you played Advance Wars back in the day, this will scratch an itch for you, I think. I've played it a fair amount. [00:58:37]

It's pretty good. I enjoy it. It's a good game. Having it also be fully open source and come with that ethos is just lovely. I love it. [00:58:44]

Cool. I'm going to share this. Lee Holmes put out a blog post. Actually, this is not new, but it just crossed my radar. I don't remember where. I think it was in one of the newsletters that I read. [00:58:54]

But it was titled, Security Risks of Postman. This is not new. This is, I think, even, maybe even reasonably well known. But like, Postman thinks data. They have a cloud service. It is meant to make it easier for you to, you know, keep your different development computers synchronized with each other. But, also You're probably using Postman to, you know, make requests to a development environment. [00:59:15]

And it might include things like authorization tokens, API keys, like all kinds of really sensitive information that You probably don't want other people to get access to. So that's just generally the topic of this blog post of like, Postman is a security threat. And yeah, can't argue with that. That's you, you should not be putting your API keys into something that feeds them into a third party. [00:59:38]

So yeah, definitely something to consider. I have always been confused about Postman. Their development path. I loved it for a long time and then they got really complicated with request collections and cloud features and whatever. So this didn't seem like something that needed to be a venture backed business, which is what it is, I believe. [00:59:58]

Mark Erikson: And last item out of our lightning round, while it's not React related, Angular 18 is out. And of course, not being an Angular dev, I only have the vaguest clue of what's going on over there, but looking at the changelist, they're in the process of dropping something that they used called zone. [01:00:15]

js, which monkey patched, like, every possible source of asynchronicity in the browser. In order to detect when data mutations happened so that the UI could then do the diffing and know if it needed to re render. They've also, I believe, been integrating things like signals and trying to move away from RxJS a little bit. [01:00:36]

So, you know, there's various aspects that are there for interop between RxJS and signals. But they're kind of shifting some of that mindset and data flow approach. [01:00:46]

Carl Vitullo: Yeah, man. Speaking of, funny to also talk about how patching globals is harmful and wow, I did not realize that Angular was patching globals quite that extensively. That is not great. [01:00:56]

Mark Erikson: Angular 1 had some kind of a loop that would just keep checking the controller values to see if they'd been mutated and Angular 2 plus, so going on like the last seven or eight years. Has all relied on this tool called Zone. js to, like, monkey patch every source of asynchronicity in the browser. [01:01:15]

Carl Vitullo: Yeah, that's a little bit wild. [01:01:17]

Mark Erikson: Alright, I think we're out of things to talk about for now. [01:01:20]

Carl Vitullo: 22 minutes over our planned time. Lot to get to this month. [01:01:23]

Alright. Thank you so much everyone for joining us. We'll be back on the last Wednesday of the month here in the live stage in Reactiflux or back in your podcast feed just as soon as we can after that. [01:01:33]

We gather sources from This Week in React, Bytes.Dev, React Status, Next JS, Weekly React Digest, the React JS subreddit, here in Reactiflux from the #tech-reads-and-news channel, and direct from those publishing articles, usually on Twitter or BlueSky. I'm not on threads, but maybe people post there. [01:01:51]

If you see anything newsworthy, definitely let us know. You can do so in the #tech-reads-and-news channel here in Reactiflux, or you could send us an email to hello@reactiflux.com with T M I R in the subject line. It's an acronym for the show. I read literally every email that comes in, even ones marked as spam. So if you send me something to that address, I will read it. I may not reply, but I will read it for sure. [01:02:13]

If this is a show that you get value from and want to support, the best way you can do so is by submitting a review, wherever you listen, and definitely tell your friends and coworkers about it. My thesis for the show is that there are a large number of people who are overwhelmed by trying to consume the fire hose. And so I'm trying to consume the fire hose for you and your coworkers. Yeah. [01:02:33]

Thank you so much. Catch us next month. [01:02:35]

Mark Erikson: Bye. [01:02:35]

Mo Khazali: Bye everyone.