This Month in React, August 2024: Matt Pocock taught us to make modules, RN is faster, iterator helpers are cool, JSR/Deno going sour

Transcript from Wednesday August 28th, 2024

Main Content

⚡ Lightning round ⚡

Quick hits

Carl Vitullo: Hello folks, welcome, thanks for joining us. This is the August edition of 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're supported by Infinite Red, a consultancy that exclusively works in React Native. but more on them later. [00:22]

Hello, I'm Carl. Uh, I'm a staff product developer and freelance community manager, here at Reactiflux mostly, where I run community programs like these events and the star helpers, and build tools to help keep the community operating. [00:34]

Mark Erikson: I'm Mark. most people know me as the Redux maintainer or that guy with the Simpsons avatar, and I am currently an engineer at Replay. [00:42]

Mo Khazali: And I am Mo. I head the mobile team at Theodo, which is another React Native and just generically tech consultancy. I'm also the organizer of the React Native London community and super excited to be here as always. [00:56]

Carl Vitullo: We are brought to you by Infinite Red, our main sponsor right now. They are an expert React Native consultancy that I am quite pleased to be a partner with because they are like authentically showing up to support the React Native and React ecosystems in like really meaningful ways. [01:12]

They organize conferences, they host the largest React Native podcast, they publish the largest React Native focused newsletter, and they're Just really excited to work with them. Other than being great people who do great things in the community, they also, well, more precisely, they're a team of about 30 people, mostly developers with mostly greater than 10 years of experience. [01:33]

So they actually work with your team to help you develop an expertise in building React Native. So if you are. Building something with React Native and need a little help hitting the ground running on that, definitely reach out to them because they are great people who will help you do good work. Cool. [01:51]

All right. Mark, you want to start us off? [01:53]

React 19 progress

Mark Erikson: So, last couple sessions, we talked about how React 19 had been delayed due to what has been known as Suspense Gate, where the React team had made a change last fall to pre rendering behavior for multiple nested suspense components. [02:07]

So that instead of doing them in parallel, it effectively does them in serial. And people complained and said, we rely on these existing behavior, you're going to make a number of people's apps slower. And there was an outcry, and the React team had been ready to release React 19, and instead they backed off and said, "okay, yes, we see this is a big deal, we are going to figure out how to change the behavior." [02:30]

But, the original PR that got merged was pretty complex, they've continued iterating on the internals. So it's not nearly as simple as revert the PR, it's we need to iterate further on the internals and figure out how to re implement some of the older behavior on top of the newer code changes. [02:48]

https://github.com/facebook/react/pull/30800

Mark Erikson: There's been a thread where people have been trying to ask for updates, and the last comment in that thread a few weeks ago was, well Stay tuned to this thread for updates, but no indication of actual work. And so finally, within the last week and a half, I've seen a couple PRs where there is actual evidence of work being done on this. [03:07]

Uh, Andrew Clark filed one PR that's added a feature flag that would later be added to gate this upcoming work. And then he just put up a PR a couple days ago with what looks like the initial implementation work for this Suspense sibling pre rendering behavior. I'm not sure if it's basically just this one PR, if he's working to split it into further PRs, or what the actual status is, but there is an actual PR with actual progress, and no idea how long it'll be before that gets merged, how long things will stay in beta or RC, but there is public evidence that they are actually pushing forward on this, and if you look at the code, you can see some of the complexity of the implementation work, like it's not just You know, one flag that gets turned on and off. It's a bunch of additional logic internally to make the older behavior possible. [03:57]

https://github.com/facebook/react/pull/30684

And meanwhile, I've been very interested in this part. Sebastien Mårkbage had been spending, you know, really most of his last couple of years working on the server side aspects of React. Server components and a lot of the HTML, you know, related pre rendering work, but he's actually turned his attention to the React DevTools in the last month and a half. [04:17]

And he's just been putting up a whole series of PRs, refactoring the guts of the React DevTools and making a whole bunch of improvements. And so two of them in particular, he's actually implemented what looks like React DevTools support for showing server components as part of the tree in the React DevTools. [04:37]

https://github.com/facebook/react/pull/30798

Mark Erikson: And along with that, what looks like a feature for being able to view the source of server components from React DevTools on the client side. This is something that I had always wondered, like, when are they going to get around to doing this? Like, we've supposedly shipped this production ready feature, and yet there's no way to really debug or view server components. [04:56]

So to me this is a pretty big deal. [04:58]

Carl Vitullo: Yeah, definitely. Dev tool support has always been so good in React that calling it, you know, production ready when there isn't that dev tool support seems a little surprising. So yeah, cool to see that coming. I'm a little surprised to see that they are actually able to get like the source of server components into the client seems cool. [05:16]

That PR is only a hundred lines added, 35 lines removed, so that seems very easy if they had a lot of support. [05:23]

React Native 0.75

Mo Khazali: So, next up, React Native version 0. 75 has been released. Now, this has been one of the most sort of subtle and quiet releases of React Native I've seen in a very long time. There's a lot of sort of minor improvements under the hood that's happened. [05:37]

The first thing is that we have a new version of Yoga. So, Yoga is the layouting engine in React Native that basically handles Your JavaScript code being translated to native layer drawing on the canvas. And so it's now got support for, so, so recently a couple of versions ago, we got support for gap when you're dealing with flex like layouting, and now there's also percentage value support for for GAP as well. So it's getting closer and closer to what you can do on the web. Another sort of update within this version is that you've got new architecture support that's getting more and more mature, and so you see that some of the libraries that previously didn't have new architecture support are getting more and more. [06:12]

Positive support within the new architecture paradigm. And also, um, what you see is that tools where you can see the list of dependencies that you have now also mark whether or not new architecture is supported within it. It seems like we're kind of gearing towards finally having the new architecture as a default with the next release of React Native, which would be a pretty big deal. [06:31]

But again, we've been saying that for a little while, so I'm not holding my breath, but I'm very, very cautiously optimistic about that. And then the last big thing within this version is that a couple of versions ago, again, they announced that you should use a framework and they suggested Expo as kind of the only option really that's, that's available currently. [06:46]

And so we see a few movements that are coming out of that announcement. One of which is that the CLI tool React Native init is now being sunsetted in some capacity and moved to a community CLI. So. By the end of the year, so December 31st onwards, when you run the commands react native init, they just will no longer work, um, and you'll be guided either to use expo or to use the community fork of the CLI that will be maintained by the community. [07:11]

But this is kind of a, let's just move it to the side. And wait for it to reach its demise type of thing. Which is, that's fine. That's kind of the direction that it's going towards. But it's just something to keep in mind though. [07:21]

Carl Vitullo: Yeah, sure. Shades of create react app sunsetting. Commonly used tool that's just gonna slowly fade away. [07:28]

Mo Khazali: Yes, exactly. Very much so. [07:30]

How to Create an NPM Package

Mark Erikson: Alright, Matt Pocock, who's probably best known for a lot of his articles and courses on how to use TypeScript properly, has actually put together something adjacent and published a very long, detailed article on how to properly create and publish a package on NPM. This is an extremely detailed and very step by step guide that goes all the way from, you know, literally create a new Git repo to creating a package. json file, some of the fields you would want to define in there, setting up tools like TypeScript and Prettier, and one of the more complicated pieces, how to actually define the JavaScript files that are used in terms of the package exports. [08:13]

https://blog.isquaredsoftware.com/2023/08/esm-modernization-lessons/

Mark Erikson: Now, I spent a very large portion of 2023 trying to figure out a lot of this stuff for myself, because in today's JavaScript ecosystem, figuring out how to publish packages that properly support things like both ES modules and common JS modules is an absolute nightmare. [08:32]

And there's all kinds of different permutations and different runtimes and environments and other things that you're going to run into. This guide isn't going to cover every different use case you'll run into, but it is a very, very good detailed look at a lot of the common things you would want to do to set up a reasonably standard package setup in today's environment. [08:52]

So definitely worth looking at. [08:53]

Carl Vitullo: Yeah, definitely. I have needed something like this many times. I've always kept track of generally each change in the ecosystem, but then when I, you know, actually sitting down and needing to write a new package and remembering which changes happened, what the current state of the best practice for setting up a new package are is always Very difficult. [09:12]

So I'm really excited to have this. It's, I think your post from 2023 was like the first time I had seen somebody try to articulate what best practices for publishing a, you know, like professional quality NPM module looked like, and it's so weird. It's gotten so strange. [09:29]

Mark Erikson: It is so painful and so bizarre. [09:31]

Now I will, I will say I will say like a lot of the pain comes from Node, not allowed to import CommonJS into ESM, I can never remember which way it is. Um, like, you could do A into B, but not B into A. I just don't remember which way the limitation was. But the last couple versions of Node 22, I believe they've finally started to implement valid support for going both ways without any errors. [09:59]

I can't remember if it's behind a flag, but at some point that version is going to become widely used enough that we can maybe, in five years, start to go past this. [10:10]

Carl Vitullo: Hopefully. Yeah, I had actually just seen a tweet somebody put out complaining about a similar thing where, I think they called it a cardinal sin of CommonJS, but it was conditional exports. [10:20]

You could put what you exported behind a flag. [10:23]

Mark Erikson: Yeah, I think that was probably Ketanaito, the author of MSW. [10:27]

Carl Vitullo: Correct. Arya in the chat saying, can't import ESM from CommonJS, but can import CommonJS from ESM. [10:35]

Mark Erikson: Yep, that sounds right. Yep. [10:36]

Implementing React from Scratch

Mark Erikson: So I've always been a very big fan of articles that try to build a miniature version of a real library from scratch and kind of walk you through, here's the kind of functionality, here's what it actually looks like internally. Here's some of the pieces that you might consider. These are really, really good for both understanding the mental model and you know, kind of peeling away the black box and like understanding what's actually going on inside of these libraries. So I've seen a few different good articles along that line for both, you know, React and Redux and, and, you know, bundlers and other tools over the years. [11:11]

So someone named Robbie Prusin just put out a really, really good new example of this implementing React from scratch that walks all the way through the process of creating elements um, modifying the DOM, putting, and putting all the pieces together. Really, really good post. Definitely recommended. And so, along that line, two other earlier posts that I'd recommend. The one I've pointed people to for me, for years, was from Rodrigo Pombo back in 2019, Build Your Own React. And then swyx has a classic post on how React hooks work by building your own version of hooks in 30 minutes. [11:45]

Carl Vitullo: Yeah, also a huge fan of this kind of, like, first principles, understand how it works by making your own miniature version of it. Reminds me of, like, in the physical world, building a model. You're not going to use it for something for real, necessarily, but this gives you a really clear mental model of what's going on under the hood. [12:04]

Vercel adds retention periods

Carl Vitullo: I'm going to throw this in. This is maybe a lightning round tier post, but I'll show you right now. Vercel announced that they are going to allow you to configure retention periods for your deployments. I saw Guillermo Rauch post on Twitter about this and saying it was something that people have been requesting since he released, now, the precursor to Vercel. [12:25]

So this is a feature that goes back nearly 10 years of people requesting it. And just like generally, retention periods, I feel like they're underrated. I feel like they're super powerful and just really good for a lot of things. Being able to configure how long data sticks around, I think, is a bit of a superpower. [12:42]

It's one of the things that, like, once you figure out how to make use of it, it just lets you do a lot of really good, powerful things. I have an affinity for them because my first full time job was doing tech support for a backup server, and so learning retention periods and how the retention policies were structured was a big part of my early tech career. I think it's cool. It seems good. [13:03]

Waku 0.21 adds Server Actions support

Mark Erikson: All right. So we're continuing to see folks try to work on building out React server component support in various frameworks. Uh, you know, Redwood's done some work. The remix folks are trying to work on things and one framework that's been plugging away kind of quietly is Waku, which is the brainchild of Daishi Kato, the author of Jotai and Valtio and maintainer of the Zustand library. [13:27]

They have just released version 0. 21, which now includes support for server actions. We're still at a point where Next is really the only, like, full, you know, quote unquote, production ready implementation of React server components and server actions. But it's good to see that other frameworks in the ecosystem are getting closer. [13:47]

While I don't know the overall status of WACU, like, it feels like it's starting to get a lot of the pieces fleshed out. And, you know, worth at least looking at. I mean, probably not ready to use in production yet. But it's an alternative approach to server components that'd be worth investigating. [14:02]

Mo Khazali: Quite interesting that on their website, when you scroll down at the very bottom, it has a big sponsored by Vercel. Which seems quite funny, given that it's somewhat a competitor to Next in some capacity. [14:13]

Mark Erikson: I was talking with Tanner Linsley and he said that like, Vercel has actually been doing a lot of work to both, like they, they sponsored, React Rally, the conference at the last minute, and they're even sponsoring some of the work on TenStack Start, I believe. [14:24]

Carl Vitullo: Yeah, they are definitely all over the place sponsoring all sorts of stuff. So I guess they're just generally investing in the React ecosystem. Here for it. Let's distribute VC money. [14:34]

Mark Erikson: Yeah, very much so. [14:35]

Redux Essentials tutorial updated

Mark Erikson: Okay. Next up is an item that is very near and dear to my heart because this has taken me like the entire calendar year in one form or another. [14:44]

In fact, I think I actually published this, might've even been like the day after our last recording in July, but you know, hey. So Redux Toolkit came out in the fall of 2019. In the first half of 2020, I wrote a brand new tutorial for the Redux docs that I dubbed the Redux Essentials Tutorial. [15:02]

And it was about 25, 000 words, and it covered how to use Redux Toolkit to build a plausibly realistic example app. And it taught Redux Toolkit for the first time as the default way to use and build Redux applications. And so that has been the primary Redux tutorial for the last four plus years. [15:23]

But it was starting to get a little bit outdated in a couple ways. While I still think that the original version of the tutorial was, frankly, a really good piece of work and something I'm very proud of. I saw in retrospect that I could have done a better job explaining various, you know, Redux concepts. So, at the start of this year, I set out to do a pretty thorough modernization and update pass on that tutorial. [15:46]

I did the work to convert the existing example application to TypeScript. Start to finish every single commit. And then I added some additional features and examples to demonstrate newer Redux Toolkit features that did not exist in 2020. From there, I went through and did a very thorough update on all the content. [16:06]

Improved a lot of the explanations, moved pieces around. Ended up adding about 9, 000, close to 10, 000 words of overall content, not counting the content that got changed and shifted and moved around. So, a month ago, I published the finished update to this Redux Essentials tutorial. So, it is now TypeScript start to finish. [16:27]

Which is something I spent a lot of time, I had spent time debating it out in the past. You know, I've always been concerned that adding TypeScript into the mix this early is going to add more learning overhead. [16:38]

And that's still the case. But ultimately TypeScript adds so much benefit, and it's how we want people to learn. to use Redux, that I decided it was worth it to just do the whole tutorial in TypeScript all the way through and try to explain the pieces as I went. So, it's live, uh, it's now up to like 50, 000 words, it is incredibly comprehensive, covers effectively all the APIs in Redux Toolkit and explains Enough about how things work that you can follow through and use it and understand most of the why. [17:11]

It doesn't go into how things work internally. For that, we still have kind of the lower level Redux fundamentals tutorial that explains, you know, like, how does a Redux store work, or how do some of the pieces connect together. But this is the way we want people to use Redux, and, you know, I'm pretty I'm biased, but I think it's the best way for people to learn Redux. [17:32]

So I am very excited to have that out. It took me multiple months of effort to try to put that together. [17:38]

Carl Vitullo: Nice. Cool. 50, 000 words. You could sell that as a book. [17:42]

Mark Erikson: Pretty much. [17:43]

Carl Vitullo: all right. I will pull us onto our next one. [17:46]

TS 5.6 RC

Carl Vitullo: TypeScript 5. 6 has a release candidate. Seems cool. Just going to call out a couple of cool things. [17:52]

Something that caught my eye was the disallowed nullish and truthy checks. It's practically a linting rule, really. It just helps catch stuff that are pretty obviously bugs. Like, a good example they called out was if you accidentally switch the equals and the greater than in the, you know, trying to do a greater than equal comparison. [18:10]

Oops, that's an arrow function, which is always going to be truthy. And so now TypeScript will give you an error for that. This expression is always truthy, you probably didn't mean to put that in an if. That just seems pretty useful. They talk a bit about other situations where they do allow, you know, constant expressions, but truthy expressions will now warn, which seems really great. [18:31]

https://github.com/tc39/proposal-iterator-helpers

Carl Vitullo: I also liked the iterator helpers. It looks like they're pulling in a stage three proposal for, you know, ECMAScript, JavaScript, which I'm a little surprised by. You know, I, I thought that they generally wait for things to ship. [18:43]

Mark Erikson: Stage three has usually been their target. [18:45]

Carl Vitullo: Yeah, okay, cool. Good to know. But yeah, iterator helpers, it looks like that feature generally looks to be a recognition that people want to use iterables as if they were arrays, and so it adds a lot of array type, you know, functions to iterables. [19:01]

So you can do things like map and filter and things like that on them. So that's super great. I'd love to see TypeScript adding support for that because that looks really great. I have tried to do that a number of times and been really annoyed that I had to spread it into an array first before using map. [19:16]

So that's, I'd love to see it. [19:17]

expo-dom released

Mo Khazali: So, let's switch gears a little bit into some React Native news. So, a couple of cool things. First off, Expo DOM has been announced. So, now you've got a whole bunch of different ways to do code interoperability between web and mobile, uh, and all things in between. So, you now have React Strict DOM, there's React DOM, there's Expo DOM. [19:36]

It's getting very confusing very quickly. But, really, the gist of all of this is, Expo's been really pushing this narrative of you want to be able to use a single code base to target web and mobile at the same time. Part of the challenge that will come up with a lot of people will be, well, I already have my web code base and I already have my React Native code base and combining these two together is going to be a bit of a tough egg to crack when you're dealing with a massive length in migration. [19:58]

This is one of the things that they want to target with this, which basically is that they want to allow you to use DOM Primitives directly within, your React Native applications. So you put a use DOM directive at the very top of your file, and then that basically means you can start using DOM in there, and what it does under the hood is it basically constructs a web view and renders those DOM elements instead of real native elements. [20:17]

Now this is quite powerful because it kind of means you can mishmash a little bit of DOM in places where you already have some code that's using React DOM inside of a React Native code base. And in theory, if your code is responsive and behaves well on mobile web, then it'll kind of work as you expected within your React Native app. [20:33]

There is a lot of disclaimers within this in terms of how your data flow works and all of the different things that come with that, you can't, you know, render children within it. It's very primitive rendering at the moment. But, it's a path towards migrations, if you so need it, desperately. It's not a long term thing, I think it's a very short term, temporary, here's how we just get a fully functioning app out in the meantime while we slowly add native views into our application. [20:56]

Carl Vitullo: Ah, interesting, okay. This is a stopgap they're not necessarily looking to have people build full React Native applications using web primitives. [21:06]

Mo Khazali: Thanks. It's more of a migration thing. So, you know, I've worked on a number of apps. In fact, I'm working on one right now where it's a hybrid app. [21:13]

A lot of companies will have hybrid apps where they have some of it in React native, that's native views. Some of it are web views and you have to use a web view inside of the native app to render some of the screens because, you know, they didn't have the time to build that out in a native fashion. So this is kind of just streamlining that process a little bit. [21:28]

I think it's just to try to entice people to come over to the dark side of the native world, and then hold them hostage afterwards. Jokes aside with all of this though, I think it's a, it is a migration path. It is very experimental, it's nowhere near production ready, it's just being brewed as we speak this month, um, and they've released a bunch of demos and it's now officially on their docs, but it's very much with all of the disclaimers of you shouldn't use this yet. [21:49]

And it comes with a whole bunch of limitations. [21:50]

Carl Vitullo: Reminds me of Cordova and things like that. I'm a little surprised to see Expo doing something along those lines. I thought we had generally agreed that just like flapping a web view in a native app was not great, but okay, cool. [22:01]

Mark Erikson: So just to make sure I follow the technical train here. [22:03]

So roughly speaking, you write a line or two of code that looks like it's just rendering. Another React component, but under the hood, it's actually creating a whole web view, attaching it to the native layout, injecting the JavaScript code into the web view, and then actually rendering a web component, a React DOM component inside of that, right? [22:24]

Mo Khazali: Exactly. That is exactly what it's doing, yeah. Layers of abstractions on top of layers of abstraction. So I think this will be around as a migration path. I think this is a small side project that they're just whipping up to make it easier for people to adopt the universal app paradigm, which is, you know, I want to have a single code base for all of my platforms. [22:40]

I think you really want to focus on React strict DOM if you're thinking about the long term of your app, if you want to go down the route of having a universal app. This is just a temporary stopgap if you happen to have code in the web world that you want to easily use and migrate over to the native world. [22:56]

Carl Vitullo: Sure. Yeah, right. I guess I still had the strict DOM in my head as you started talking about this and it threw me off. Definitely a, uh, a subtle but significant boundary between those things. Okay. Interesting. [23:08]

Mark Erikson: And to recap for people who might not have listened to the last couple, last few episodes, React strict DOM, on the other hand, is adding more web like API capabilities to the React Native platform. [23:19]

So you write more code that looks like React DOM for the web, and it makes your React Native code basically read as if it were web code. [23:27]

Mo Khazali: Because the, the current status, and I guess maybe going a little bit further back into the context of this, we've had React Native Web for a long time, which allows you to basically take React Native code and run it through almost like a translation layer, uh, with almost like an interoperability layer that lets you render those native views and native texts on the web. [23:44]

So this is, this has been around for years. It's like pretty much been there since the launch of React Native a few months after they kind of, somebody launched this project who now works at Meta. But that was a very big bloated piece of, of a dependency that you would add to your web app. So then React Strict on was like, can we, can we kind of find a way that's in the middle that uses the web based APIs, also makes it easier for web developers to come into the React Native world, translates them down to native views. [24:06]

But also has a minimal overhead to use that same code on the web. And so, this is pretty much the exact opposite of that, but it's sort of a temporary stopgap. [24:15]

Carl Vitullo: Yeah, interesting. Okay, so if, like, React Native Web from, you know, ye olde days was asking web developers to write code like React Native developers And React strict DOM is allowing web people to write what looks like web code, [24:31]

Mark Erikson: Native code that looks like web code. And then this is this, eh, let's just shove a web view in the middle of our, all of our native views. [24:38]

Carl Vitullo: They're covering all their bases. They're trying everything and seeing what works best. Cool. All right. [24:43]

Mo Khazali: Where there's a will, there's a way. [24:45]

Carl Vitullo: We've got a lot of wills going on. [24:48]

Mo Khazali: There's many wills going on here. [24:50]

Carl Vitullo: Neat. Very neat. [24:51]

Nitro Modules

Mo Khazali: Let's move on to Nitro modules because this has been a big thing in the React Native ecosystem in the last month. Again, a little bit of context because I think this will help everyone kind of understand and set the scene. So, a few years ago with the old architecture, when you wanted to access native layer code, you would need to use a native module. That used something called the bridge and the bridge would basically serialize some JSON or some, some sort of JavaScript objects, send it across a bridge as we like to call it. And that data could be used by the native layer to be interacted and run some native operations. And that's how sort of the JavaScript layer and the native layer used to communicate with each other. [25:23]

That bridge caused a lot of issues because you had sort of this one pathway to communicate between the native layer and the JavaScript layer and it caused slow apps and many issues and a lot of library maintainers were incredibly frustrated because it meant that if you use their library in a certain way, it would completely bog down people's apps and they were getting a bunch of issues around how their library is slow or React Native in general as being slow. [25:43]

So then the new architecture tried to create a better way to interact between the JavaScript layer and the native layer. And so that's where TurboModules came into place. So the idea with TurboModules was you would create a TypeScript interface to define the type of functions and values that you want to communicate between the JavaScript layer and the native layer. Then it would run through some C code gen to generate the connection layer between the native layer and the JavaScript layer. And then you could write native layer code and use that with what they call turbo modules, which was the name for it. [26:13]

That was a much more neat and streamlined way to communicate between the JavaScript layer and the native layer. That's a massive step up from the old architecture, and now Mark Roosevee, who is one of the sort of like people in the React Native ecosystem who's known to create some really cool native layer libraries that work really well, has now been playing around with this idea of creating an even faster way to communicate between JavaScript and the native layers and to write native layer code as, as a React native developer. [26:39]

And he's calling it Nitro Modules and he's created a lot of fun puns out of them. For example, if you wanted to generate a Nitro Module, you run Nitrogen, which is, uh, quite fun. Um, [26:49]

Carl Vitullo: Oh, my god. [26:50]

Mo Khazali: It's great. [26:51]

There's, this isn't really public at this, it's not very clear a lot of the stuff that works under the hood. I think it's getting released and drip fed as we kind of speak this month, but just some comparisons that he's run with Objective C based turbo modules compared to Nitro modules is that it's apparently like 10x faster, so 220 milliseconds in a benchmark that he ran versus 20 milliseconds. There's also another way that the Expo team have created Expo modules. [27:16]

We're going, we're seeing a trend here, right? Like the React Native Ecosystem likes to invent and reinvent different ways of doing the exact same thing, whether it's with the strict DOM stuff or with this, but anyway. So then you've got Expo modules, which is slower to Turbo modules. And then now there's Nitro modules, which is apparently the fastest of them all. [27:31]

So we'll see how this plays out. It's yet another approach of trying to handle this native to JavaScript communication. We'll see if it, if it actually pans out and how it, how it goes on, but promising signs at the beginning, and a lot of people seem very excited about it. [27:43]

Carl Vitullo: Yeah, super neat. Throwing a bunch of shit at the wall and seeing what sticks, trying a bunch of different approaches. [27:49]

I feel like that naturally flows out of where React Native sits in the world because it has iOS, Android, web, macOS, Windows, well, you know, it gets touched by so many different developers. And so I feel like where web and React can get a little bit like monoculture a little bit just because it's, you know, there's the one true way of doing it, but I feel like that sort of variety of approaches maybe flows a little bit more naturally out of React Native as a kind of a, I don't know, kind of a natural melting pot of developers. I appreciate that. [28:21]

Mark Erikson: Polyglot development. [28:22]

Carl Vitullo: Yeah, sure. [28:23]

Mo Khazali: It feels like React in the early days, rather than what React is today. [28:26]

Like, I've been in between the web and the mobile ecosystem. And, you know, I feel like the React ecosystem has reached a point of maturity, and there's less experimentation going on, it feels. Whereas with the React Native ecosystem, there's a bunch of people working on 3D rendering at the same time, and then there's a bunch of people working on web support at the same time, and then there's a bunch of other people working on native to, you know, JavaScript interfacing all together. I think it brews, a healthy amount of competition to try to get the best solution out of there. [28:52]

Carl Vitullo: Yeah, thriving ecosystem in the biological sense. It's uh, evolution, survival of the fittest, many, many competing strategies and competition with each other. It's cool to see work on the bridge happening, because, I haven't done a ton of serious development with React Native, but that has always been a huge bottleneck. [29:10]

I mean, you know, anytime you have a lot of data flowing through one thing, like, it's gonna be a challenge, it's gonna be a limiting factor if it's not fast. Interesting to see this come out of CodeGen from using TypeScript as a schema, it sounds like. It sounds familiar to my extremely vague understanding of things like protobuffers, where, like yeah, if you're just sending JSON, There's only so much you can optimize it because JSON as a data structure is just slower to parse. [29:37]

You know, you don't have a schema, you don't know what it looks like, so you have to figure out what it looks like as you go. So starting from a schema, starting from a specification of what the data contains, and then using that to generate like ultra fast native code makes a lot of sense to me. That's, that's pretty cool. [29:53]

JSR and Deno: Final Review 🚮

Carl Vitullo: All right. I will bring us on. Just a couple thoughts on JSR and Deno. I think Mark brought these up and had them cross my radar, but David Bushell, who is a WordPress developer mostly, wrote a couple of blog posts that I think are pretty It's a pretty rough indictment of the JSR, you know, module ecosystem and generally the path that Deno has taken through module, you know, managing modules, package dependency. [30:20]

One of the criticisms that he brings up about Deno in general is as a, you know, okay, it's a venture backed company. We've talked a little bit on this show before about venture backed open source projects. One of the criticisms that David Bushel puts out is that it doesn't really feel like, it feels corporate, like the communication feels corporate. [30:38]

It feels like corporate PR, not, you know, somebody talking about what they're working on. And that was actually, that resonated with me because that's something I've noticed. Like, for instance, I set up an ecosystem news channel here in Reactiflux, and Deno stuff is some of the only things that come through it, and it feels like somebody set up a corporate process and there's somebody whose job it is to make sure that all of the communications channels get populated, you know, in a way that it doesn't feel that way for other projects like Expo or React or things like that. [31:07]

So, I don't know, just like as a vibe. That was an interesting call out that I had noticed on my own as well. They talk about the meandering path that Deno has taken through trying to get package dependencies going, you know, cause, um, Ryan Dahl had a, you know, what node got wrong about Imports, I'm misquoting that, but he complained about errors he had made in creating Node and talked about how he was going to do it differently this time with Deno. [31:34]

And then they, you know, they did like a deno. land package registry for a while and then like, oop, nope, we're replacing that with JSR. But now it's all a little confused. Like it's, JSR applies certain restrictions on what you can publish. Like you have to annotate the return types. of any published module. [31:53]

So you can't just let it infer the return type, which seems like a kind of strange restriction to put on it. I guess it's maybe to enforce SemVer through types, you know, use those return types as a schema and assert like, oh, nope, you got to break it. You change the types. I don't know. It's interesting. [32:08]

It's curious. The single most, like, disruptive point that David Bushell made was pointing out that Dnode doesn't resolve sub dependencies like Node does. Like, the way that the JSR registry works does not permit sub dependencies in the same way, in the way that we've grown accustomed to with Node. Which, like, I have called that out before. [32:28]

That, subdependencies, dependencies of dependencies, is one of the best parts of the JavaScript ecosystem. The fact that I can install a package and I don't need to, you know, to an extent, I don't need to Manually make sure that I have given it everything that it needs. You know, there's some exceptions, like if you're using, you know, there's peer dependencies where that is still the case, but in general for if I install a library, that library brings in what it needs on its own. [32:56]

There's downsides to that of course, as well, but I generally consider that to be one of the major differentiators between JavaScript and, you know, PHP or Python. So seeing that go backwards is, seems like a bad thing to me. So that seems, yeah, I don't know. It's just a, a lot of pretty negative takes on Deno and JSR. It's given me a lot of pause on it. [33:15]

Mark Erikson: I mean, it's not just one hard problem, it's dozens o f hard problems simultaneously. I mean, you know, think, think back to, you know, trying to work with C where there is no such thing as a package manager. Java is sort of its own different world. C sharp is its own different world. [33:31]

Rust has the cargo tool and a centralized registry. Python is an utter mess. There was an XKCD years ago about how bad Python package management is, and I've continued to kind of just keep a general eye on developments in the Python world. And it's more confusing over time. So there's a lot of very, very justified complaints about how bad package management is on multiple levels in, we, we say the JS ecosystem, and by that we usually mean the Node plus NPM. [34:02]

But all things considered at the same time. Most of that ecosystem generally works, and so it's been interesting to see Deno take a slightly different path and actually have to sort of backtrack a bit and say, Well, yeah, actually it turns out maybe a couple of those ideas weren't so bad after all. [34:19]

Carl Vitullo: Right, they went pretty hard in copying Go style dependency management. [34:23]

And I always thought Go style dependency management sounded like an absolute nightmare. And so, yep, alright, they're walking some of that back. [34:30]

web-infra-dev/rslib: The library build tool powered by Rsbuild

Mark Erikson: There's yet another new build tool out called RSLib to work through the chain of pieces on this one. [34:37]

So, the folks at ByteDance have an incredibly prolific infrastructure team, and so the way I understand this is they built a full blown Rust re implementation of Webpack that they call RSPack. In fact, they've actually made a couple comments about it would be nice if this could just be turned into Webpack version 6, in theory. So RS Pack is web pack five, but entirely rebuilt and rust, effectively. [35:02]

RS build is a layer on top of RS Pack that makes it a lot easier to configure, or the, the configuration syntax is closer to like Es builds configuration level roughly than web pack's configuration level, where you're having to create a whole bunch of plugins. [35:19]

And so, rsbuild is meant more for applications, and I guess they've made a third layer on top of that where rslib is a wrapper or specialization of rsbuild that is more meant for building libraries with a proper configuration output. So, I'm not sure what's leading to all this proliferation of build tools from them, but they are very happily cranking away on a whole series of things. [35:45]

2024 Stack Overflow Developer Survey

Carl Vitullo: All right. I'll pull us onto our next one. We spent a lot of time last month talking about state of JS, state of React, state of HTML, we have another survey, the Stack Overflow Developer Survey, the results came out this month. I'm not going to do too deep a dive, I think, although Mo, yeah, we had talked about, you know, demographics and selection biases of the state of JS, definitely more to talk about here. Yeah, some, some points that I took away from this that were interesting to me. I mostly looked at the professional developer respondents, just that's who I am. That's who I am viewing as the target audience for this show. [36:20]

Something that surprised me a little bit, they said that more than 75 percent of professional developers have at least a bachelor's degree. I think it was like 45 percent have a bachelor's, like 26 have a master's, and like another 5 percent have some kind of specialized professional degree, like a JD or, you know, something like that, legal, medical, whatever. [36:40]

For years of experience, front end developers were absolute bottom of the list, except for student, which was interesting, but also not surprising. You know, Boot camps, they probably teach you front end, like, makes sense. It's probably the most accessible part of the software field. So not super surprising there, but yeah, uh, also less than 6 percent of respondents to this survey self identified as a front end developer. [37:03]

That's lower than I think it was in previous years. It feels like front end has kind of. I don't know, it feels like it's diminished over the last couple years. I was looking at the country demographics. I was curious about this because I know from our statistics who uses Reactiflux, I know that we have a huge Indian population within the server. Having my own read, my own perspective on what those metrics look like by actual like usage and participation. I was curious to see how they'd be reflected. And the answer is not great. Top five countries as responded to the Stack Overflow survey were the U. S. with like 19 percent, Germany with a bit over eight, India with a little over seven, UK with five and a half, Ukraine four and a half. [37:45]

I was curious to see how, what data I could find to back that up on, you know, what those stats look like. I couldn't find a direct comparison between the US and India, partly because the only English sources I could find for tech jobs in India just said all of IT, all of software in one. [38:02]

https://www.meity.gov.in/content/software-and-services-sector

https://www.bls.gov/oes/current/oes151252.htm#nat

Carl Vitullo: But yeah, they said five and a half million IT and software workers in India, when I summed those same jobs up for Bureau of Labor Statistics in the U. S., that was like four and a half million. So just to say, there's definitely a huge English speaking bias in these surveys, which is unfortunate because the programming world is much larger than the English speaking world. some other Things, JavaScript was the number one most used technology here, and 25 percent of people learning to code self reported using Google Cloud. [38:32]

I think that was like one of the top. That was the number one. That was the like most reported. Vercel was number three in people learning to code. Uh, for professional developers, top three, obviously, AWS, Google, and uh, Microsoft, but Google and Microsoft combined were about equal to AWS's numbers. On that list, Vercel was seventh. [38:51]

Just about a percent lower than DigitalOcean, which was behind Cloudflare, which was behind Firebase. React and Node, together, both topped the web frameworks list of, technologies used with jQuery in number three. But yeah, 18 points behind React and Node, so definitely a different tier. But yeah, jQuery, what staying power it's had. I actually saw that this was, I believe the 18th birthday? It's old enough to vote. [39:15]

Mo Khazali: The one thing that's interesting to me is just the 25 percent of folks learning to code use Google Cloud. I have a suspicion that might be to do with the fact that I know that there are GCP is quite involved in student fairs and a whole bunch of stuff giving free credits to people for hackathons and whatnot. [39:31]

I wonder if there's some sort of correlation there where a lot of people seem to use it for their student experimenting and hacking, but maybe not so much when they get into the professional world. Just an observation. [39:42]

Carl Vitullo: Yeah, that actually makes a lot of sense. I have seen them sponsor a lot of hackathons and things like that. [39:46]

Yeah, I hadn't considered that, but scans. Cool. That was our last main content piece, uh, I guess into the lightning round. [39:53]

Cocoapods going into maintenance mode

Mo Khazali: I'll just jump in with an update from the React Native ecosystem, or more, more broadly speaking, the mobile ecosystem. So, in terms of package managers, CocoaPods used to be the be all and end all when you wanted to build an iOS app, in terms of managing your packages, and we've come a long way where CocoaPods is now going into maintenance mode. [40:10]

Now, CocoaPods is actually used by most of the cross platform technologies as the package manager of choice. So React Native uses it, but I think Flutter also uses it, and apparently Unity also uses it for some of their stuff as well. So there's a whole lot of this ecosystem that's being built in CocoaPods. [40:25]

But what's happened here is that Apple's actually released their own package manager called the Swift Package Manager, or SPM for short. What the CocoaPods team called it was that they got Sherlocked, which is a reference to old school OS X, where they Basically got rid of an app called Watson, which was what Spotlight is now. [40:41]

They created Sherlock at that point, which basically did all of the functionality that Watson used to do that was already integrated into the OS itself. So they're basically citing that saying we've been Sherlocked and we're now going to go into maintenance mode as a result, because there's no competing with Apple. [40:55]

So a sad day for everyone who loved and used CocoaPods for years, but obviously we're going forward into the SPM era and React Native is already kind of on that route to adopt SPM support. [41:07]

Accident Forgiveness · The Fly Blog

Carl Vitullo: I saw a cool policy change for Fly. io, which is a, sort of a competitor to Vercel, it's a cloud compute platform. [41:14]

They are doing an explicit accident forgiveness policy, which is just kind of great. It's generally socially understood that platforms like AWS or Vercel or, you know, whatever if you have some weird billing situation that arises, like I think one that happened was like somebody got in an infinite loop during their CI build and that caused a huge number of function invocations and because you could build per function invocation, they had, you know, like a 200, 000 bill when they're used to paying like 2, 000. [41:45]

It's socially understood that most of the time, if it's not a repeat occurrence and it's not malicious, then they will forgive the bill. But it's socially understood. It's not in policy anywhere. It's just you put it on Twitter, you complain, it becomes a PR issue, and the company refunds you. [42:00]

So now fly. io has put up an actual policy saying we forgive accidents and has given more clarity around there. I appreciate that. It's always nice to see social norms turn into policies, especially when they deal with six figures in billing. [42:17]

spatial compute

Carl Vitullo: I saw a wonderful blog post from Sunil Pai, who I'm just a big fan of. We've collaborated a little bit in the past, but he has done PartyKit. He worked on Wrangler at CloudFlare. He's now working at CloudFlare again. He wrote about spatial compute, which is letting the network decide where in the world to run your code. So this is sort of an incremental step forward for serverless paradigm. [42:40]

Instead of starting up a server that runs your code, you just say, this is the code that I want to run. Please start it when this request is made. But you still generally tell it, what region of the world that code is going to be hosted in. So this is just a blog post talking about not doing that. Letting the server decide, letting the network decide where in the world to run your code. [42:59]

I just think that's a really interesting idea. It seems good. Seems kind of inevitable. Uh, and this is the first time I've ever seen anyone mention it. So calling it out. [43:06]

Mo Khazali: Interestingly, he's called it spatial compute. And I think he's put a disclaimer at the top saying, sorry, Apple, but that I wish he chose another term for that. [43:13]

That's already been used. [43:15]

Carl Vitullo: Oh, that's true. That is what Apple called their Vision. [43:17]

Mo Khazali: Yeah. Vision Pro Computing. Yeah. It's, it's, I wish there was another term he could use for this. [43:22]

Carl Vitullo: I like that he called it out and still did it anyway. [43:25]

Mo Khazali: Yeah, exactly. [43:25]

How Airbnb Smoothly Upgrades React

Carl Vitullo: Womp womp. Yep. Airbnb, we talked about Airbnb last episode as well. Uh, they put out a blog post about how Airbnb smoothly upgrades React. [43:34]

Last month, we talked about how they had just upgraded to React 18. So this is now two months later. them talking a little bit more about the process by which they did so. It was a pretty good read. It talks a lot about, like, feature flagging, you know, blue green deployments, and just sort of the trials and tribulations of what it means to update a core dependency of a widely used app that is in many, many phones with a huge variety of, you know, Performance and, you know, network and all those sorts of things. [44:01]

So I appreciated that, just right at the beginning of the They show like, you know, here's the ideal, like a stair step function of what version we're using. And then here's the reality of what version we've used over time. And it's got lots of like false starts where it's, they ship it and it's like, Oh, nope. [44:14]

Okay. There's a bug. We got to roll it back. Let's try again. Nope. Still bugs. Roll it back. This is, Relatable to my career. There's just, you can't do a big overhaul without missing some kind of edge case that you didn't anticipate. So, um, just always appreciate seeing people pull back the curtain and show what those pains look like, especially at big companies that have huge distributions. [44:34]

Use useId() Instead Of Hand-Making IDs

Carl Vitullo: all right, great blog post from React Training, which I'm actually not sure who's running this anymore, but it was started by Michael Jackson and Ryan Florence of React Router and Remix. They've been on my radar for a very long time. Looks like this was written by Brad Westfall. Use ID instead of hand making IDs. [44:50]

This was one of the clearer articulations of what use ID is meant to be used for that I've read. This just really kind of made it click for me. It talks about using. an ID attribute on the DOM, and why you shouldn't handwrite them. And it was just very clear and simple. The gist of it is, if you handwrite an ID, then you can only use that component once in order to not violate the guarantees that an ID has with the browser. [45:17]

You know, in a browser, an ID is supposed to be unique. If you select an ID, you get one element exactly. And so if you hand write an ID, your component can't be reused without violating that contract. What a simple idea. That makes sense. I now intuitively understand why use id is a valuable API to have. Um, yeah, just appreciated that. I love when something I didn't understand just clicks and becomes intuitive. I like it. [45:42]

Common Sense Refactoring of a Messy React Component

Carl Vitullo: Calling out this great blog post from Alex Kondov, he wrote, Common Sense Refactoring of a Messy React Component. Refactoring messy components, breaking them down into, from one mega component that does way too much into a smaller number of components that each have a smaller, you know, a single responsibility, has been a recurring theme in my career. [46:01]

This looked like a really great write up. I appreciate that it just does, like, A two paragraph preamble and then dumps 300 lines of kind of gross code on you. It's like, yeah, you know, that is, that's the experience of entering a new code base most of the time. I appreciated this breakdown of here's what the process of refactoring a messy component looks like. [46:20]

Introducing Structured Outputs in the API

Carl Vitullo: All right, small news from OpenAI. I had actually noticed this. We use OpenAI to do a resume review AI feature here, and I just did a revision to it, and it's much better. It's a little bit sassy. It's very terse. I like it. But yeah, OpenAI now has structured outputs in the API, so you can tell it what shape of JSON you want it to give you back, and it will give you that structure. [46:43]

I know in the past that has been a pain point. I remember people complaining about like just getting OpenAI to give you pure JSON without like, okay, here's the JSON you asked for, JSON. Uh, you know, just purely unhelpful. Just caught this bit of news. If you're curious about writing a little open AI side project, I think this is maybe going to make it a bit easier. [47:03]

Mo Khazali: It's also quite interesting for the mobile world, because you see a lot of a bigger shift towards server driven UI now, where, you know, you render things or you compile a JSON object that defines how the UI should look like in the mobile space, because, you know, that really works in mobile because, you You don't have to go through App Store updates, so you can basically have a dynamic page that uses JSON to decide how to layout itself. [47:24]

And so maybe pairing that with something like this could be very interesting because you can give it the right confines and restrictions and then say generate me dynamic UI and then it'll kind of be a smart AI native based app. [47:35]

Carl Vitullo: Wild. Kind of V0 vibes. V0 from Vercel. [47:40]

All right. Here's my last little news item. [47:42]

Sentry is now Fair Source

Carl Vitullo: This actually crossed my radar very late. I would like to be more prepared to talk about this because it's at the intersection of, you know, open source and licenses and legal stuff, which I am personally fascinated with. But Fentry has announced that they are FairSource. FairSource is a new concept to me. [48:00]

It's a new project. So they say, today we're launching FairSource, a new approach to software sharing that is safe for companies to adopt and developers to use. Seems pretty neat. They talk about, they give a list of projects that are working with it, and they define it as like publicly available to read, allows use, modification, redistribution with minimal restrictions, and I guess notably it says that it undergoes delayed open source publication, which they give as a four letter acronym, D O S P, very enterprise. [48:29]

It's not quite a license, it's sort of a social contract surrounding a license, I guess. They talk about a new functional source license, but it also recognizes a fair core license. And the business source license. It's interesting. I'm definitely gonna have to dig into this a lot more because this is just referencing a bunch of licenses that I haven't heard of in a like social contract for how source gets released that I haven't seen codified. [48:56]

I've seen companies do things similar to this before, but there hasn't been a name for it. It hasn't been saying like, yes, we are. This, we are FairSource, so definitely interesting. It's not quite free and open source, but it is adjacent free and, you know, FOSS, FOSS has been difficult for many companies to actually execute on and live up to. [49:17]

So this looks like a more friendly. type of license, mode of releasing source code into the world. So maybe it'll give engineers at more companies greater ability to make a compelling case for open sourcing internal code, which would be lovely. I would love to see more proprietary code get open sourced. [49:35]

Too many things happen in secret. [49:37]

Mo Khazali: The delayed open source publication is quite interesting because it's having a separate Closed source version of a code base that gets synced with an open source version is not, you know, unheard of. The React Native code base, as an example, is like this. So, it's not the most bizarre thing to have, and it's been happening. [49:52]

It's just maybe not been codified like you mentioned, and maybe this is the way to do it. [49:56]

Carl Vitullo: Right, exactly. That's the classic problem in a lot of businesses that would like to open source, is there's some part of it that is, like, truly proprietary, where if they release that, then, like, you know, they're giving away the secret recipe. [50:07]

Or Contractual agreements they have with their customers where like they wrote some custom integration code and like that can't get open sourced. So like there are very real business constraints that make it difficult in some cases to open source code. Like you said, some companies have done that through things like synchronizing source code, but that's been done kind of ad hoc. [50:29]

It's, you know, Each company has figured out its own way to work, to make that work. So seeing this as a template, a framework for people evaluating that decision, to push it over the finish line, to make it actually happen. Uh, that seems really valuable. This seems like one of those like quiet things that will have an outsized impact on the open source world. Pretty neat. [50:51]

Job Market

Carl Vitullo: All right, some information about the job market. It was not great this month, but most of that was because of layoffs at Intel, just not great. So 15, 000 layoffs from Intel alone, overall like 25, 000 layoffs in tech. Which is not great, but since most of that came from one company, that's still pretty on track from where it was last month. [51:11]

Intel screwing up doesn't really reflect too much on the broader, you know, tech and software ecosystem, I don't think. [51:18]

https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE

Carl Vitullo: I've been using this Fred data source of. Job postings on Indeed. And that is still trending down, which I'm a little surprised about. It's just been a consistent downward trend. It's down to 68 percent of the baseline of like the start of 2020. So, you know, pre pandemic, which I'm surprised. That's wild. I thought it was getting better. [51:38]

Mo Khazali: Just on that, I guess like Intel and Cisco both together are 21, 000 out of the 25, 000 layoffs. So if you take those two out, it's, it's actually like three, four thousand. [51:49]

Carl Vitullo: Okay. That's actually quite a bit smaller. [51:50]

That's nice. So yeah, last month I commented that it was the first time in a while we haven't had a pretty big pop of layoffs at the start of a new quarter. So yeah, cool. I guess that's generally holding true except for two megacorps running into problems. [52:04]

A couple of new releases. [52:06]

Material UI v6

Carl Vitullo: material UI put out version 6. They commented that they took two and a half megabytes out of the bundle size they'd installed on your disk, not the published size of your bundle, which made me look at that and go, wow, this is a 12 megabyte Install size, which is wild. That's larger than I realized. But yeah, Material UI, if you're using it, there's a new version out, new major. [52:28]

Mark Erikson: Although on that note, the TypeScript team has done some fantastic work shrinking the size of the installation on disk. Like it, it was up to like 50 megs, I think, as of like 9. And they did a lot of work in 5. 0 to convert some of the internals over to ES modules. And then, and then. Working on deduplicating some of the bundled files that they had and other internal optimizations. [52:55]

I think at this point it's down to like 20 or 25 megs, which is still sizable, but I mean on the other hand, you know, 50 percent net win is a net win. [53:04]

Carl Vitullo: Adhering that size, you know, 25 megs for all of TypeScript versus, you know, I don't know if it's exactly 12, I don't have the number in front of me right now, but half of TypeScript for material UI seems like a pretty big lift. [53:16]

Tauri v2 RC

Carl Vitullo: There's also Tauri v2 has a release candidate out. I don't know a ton about that, but we talked about it briefly in the past. [53:24]

Mark Erikson: It's an Electron competitor allows you to build apps that run on the desktop But the UI is built with web technologies The difference is that Electron you're shipping an entire copy of Chrome as the rendering engine Whereas Tauri uses whatever OS's native web views instead So the overall shipped size is a lot smaller. [53:43]

Carl Vitullo: Heck yes, seems cool. So they've got a new version 2 coming out, which should be big. [53:47]

NX v19.5

Carl Vitullo: There's also NX version 19. 5. I don't know a ton about NX. [53:53]

Mark Erikson: It's primarily a monorepo management tool. So managing lots of individual packages for both, you know, multiple libraries, multiple applications in one repo, which each of which could be, you know, being built with different tools. Like you might have, you know, a common TypeScript library and maybe, you know, a Vite app and an Angular app all in the same repo. And so NX does work to deduplicate the builds as well as manage creating and updating a lot of those packages. [54:20]

Upcoming conferences

Carl Vitullo: On to some conferences that are coming up. [54:22]

https://www.reactuniverseconf.com/

Mo Khazali: Next week, if I'm not mistaken, and time is not escaping me, is React Universe Conf. React Universe Conf happens every year in Wroclaw in Poland. So it's happening on the 5th and 6th of September. Uh, it used to be called React Native EU, but it's now evolved since React and React Native are getting closer and closer together by the day. So I will be emceeing the conference. Hence why I'm giving this shout out. [54:44]

So come along. Hopefully it'll be a good time. There's a lot of great speakers headlining there. [54:48]

Mark Erikson: Was it September, almost September already? [54:50]

Mo Khazali: That's why I have to take a double glance at the calendar. [54:53]

https://www.jsconf.cl/

Carl Vitullo: Cool. There's also JSConf in Santiago in Chile. Overlapping with React Universe. So that's going to be September 5th through 7th. [55:01]

https://utahjs.com/conference

Carl Vitullo: I feel like we've been talking about Utah conferences a lot, I guess. But yeah, Utah JS is doing a conference. Seems like there's been a lot of stuff going on in Salt Lake City. Yeah. [55:10]

https://reactalicante.es/

Carl Vitullo: There's also React Alicante in Spain, September 19th through 21st. [55:15]

Mark Erikson: I'm speaking, looking forward to it. [55:17]

Carl Vitullo: Woo! [55:18]

https://www.jsconf.ie/

Carl Vitullo: And JSConf Ireland in Dublin, September 25th and 26th. [55:23]

https://2024.squiggleconf.com

Carl Vitullo: Yeah, SquiggleConf in Boston is October 3rd and 4th. This is organized by a conference buddy of mine, Josh Goldberg. He is author of a book on TypeScript and just a wonderful, friendly, lovely person. I'm actually going to be volunteering there, so I'll be helping out with making sure the conference goes off. [55:41]

Mo Khazali: Yeah. So Josh, I was going to similarly give a big shout out to Josh for being an amazing person. But beyond that, me and him have been bonding. So we spent a bit of time in Amsterdam and we bonded over being first time conference organizers this year. So him and I have been trying to be each other's support group here and they're sending each other some tips and advice. [55:57]

But Josh is, is incredibly well known in the community and he's going to hopefully put together a really, really cool event. So definitely go there if you're in the U. S. [56:05]

Mark Erikson: The other organizer, Dimitri, is less well known, but also a wonderful person. [56:10]

Carl Vitullo: Yep, I just got to meet Dimitri the other day, uh, talking about volunteering. Seems really cool, seems really lovely. I'm going to brag, I was at the table at React Miami where Josh Ideated the name SquiggleConf, so I was there for the origin. So, very happy to volunteer. [56:26]

https://www.rendercon.org

Carl Vitullo: Overlapping with that, there's RenderCon in Nairobi, Kenya, October 4th and 5th. [56:32]

https://www.reactindia.io/

Carl Vitullo: Then, React India in Goa, India, October 17th through 19th. [56:37]

https://www.react.brussels/

Carl Vitullo: There's React Brussels in Brussels, Belgium, October 18th. I went to that not last year, but the year before. It seemed really great. I got to hang out with the organizer at React Conf in Las Vegas, and just really great dude. Would recommend React Brussels for sure. [56:53]

https://reactadvanced.com/

Mo Khazali: Cool, next up we've got React Advanced London, so this happens around October time every single year in London, so I've been going for a few years now, and the Great React Conference is probably the biggest React Conference that there is in the UK, so definitely head there, I will be there again this year, so if you're around, pop me a message and we'll say hi. [57:09]

Outro

Carl Vitullo: All right, cool. That is everything we've got for today. Thank you everyone for joining us. We will be back on the last Wednesday, even though today is Thursday, uh, last Wednesday of the month to hear on the live stage of Reactiflux or back in your podcast feed just as soon as we can. [57:23]

Mo Khazali: Thank you all for joining and listening to us ramble on and chat all things React and React Native. [57:28]

It is always a pleasure and see you all next month. [57:31]

Carl Vitullo: We gather sources from This Week in React, Bytes. dev, React Status, Next. js Weekly, the React. js subreddit, and here in Reactiflux. If you see anything that seems newsworthy, uh, that you think we should discuss, just put it in the tech reads and news channel here in Reactiflux. [57:49]

Or, if you like, You can send it to me in an email at hello at reactiflux with T M I R in the subject line, which is a, it's an acronym for the show. I read every email that comes in, including spam because I'm a crazy person. So I will read it even if we don't end up covering it. If this is the show you get value from and want to support, the best way you can do so is by giving a review on Spotify or whatever platform that you actually listen to. [58:15]

Tell your friends, tell your coworkers, we're cool and smart and we can help you sound cool and smart too. You're pretty cool and smart too. See you guys next month. Bye.