This Month in React, June 2024: React 19 delayed (drama-ish), why no JS Laravel, TS 5.5 and more

Transcript from Thursday June 27th, 2024

[00:00:00] Carl Vitullo: Hello, thanks for joining us. This is June's edition of This Month in React, where we recap and digest the recent developments in the ever evolving React and web ecosystem. We're coming to you live from Reactiflux, the place for professional React developers.

[00:00:13] I'm Carl, I'm a staff product developer and freelance community manager here at Reactiflux, where I run community programs like these events and build tools that help keep the community going.

[00:00:24] Mark Erikson: Hi, 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 that, I do Redux stuff.

[00:00:33] Mo Khazali: Hi everyone. I'm Mo. I head the mobile team at Theodo. I'm quite active in the React Native community and I organized the React Native London meetup and here and there dabble in open source with a couple of libraries in the React Native ecosystem. Very happy to be here.

[00:00:47] Carl Vitullo: Uh, I'm just going to start off with some quick hits of new releases and conferences.,

Layoffs updates

[00:00:51] Carl Vitullo: Starting off immediately, because the market, the job market is so bad, I've been reading off stuff from layoffs.fyi.

[00:00:59] We're not quite at the end of June, it's a couple of days left at time of recording, but most of the way through June, we're at about 9. 2, 000 laid off from 40 companies, which is down, I mean compared to six months ago we're down substantially, but compared to two years ago we are up substantially, so it's still not great. I've seen some other broader metrics trickling out from other places, like I saw a link from ADP that I unfortunately don't have handy suggesting that the overall like, tech market is at about 80 percent of it was, I believe, compared to 2018.

The rise—and fall—of the software developer

[00:01:35] Carl Vitullo: Yeah, I, I found that really interesting because between hearing headlines about like record hiring during the pandemic and record layoffs in the two years, after that, it was like, Where do we end up? So that's the first data point I've seen, uh, addressing that question of, like, what's the net gain loss, and it suggests net loss of, like, 20%, which seems massive, but yeah, it's also, it's ADP, I don't know how much to trust that, I would assume that they got a very large sample size, but I'm not sure how they defined, like, tech, so, I don't really know how to interpret that in, through a lens of like software development.

New Releases

[00:02:12] Carl Vitullo: But yeah, moving on to some new releases.

Turborepo 2.0

[00:02:14] Carl Vitullo: There is TurboRepo 2. 0. That's probably especially relevant if you're doing stuff with Next. It looks like it's mostly like a fancier UI. They're doing like a pretty high effort in terminal UI. Like it's, you know, reactive and interactive. And you can now break down your logs on a per task basis rather than it just being, you know, a constant scroll back the way terminals usually are.

[00:02:38] So that seems neat. Oh, they had some new docs, and it looks like they included some, like, fundamental information about Monorepos, which seems cool.

React Admin v5

[00:02:47] Carl Vitullo: React Admin released version five. We actually had Francois Zaniotto, hope I'm not mispronouncing that, on as a guest a couple of weeks ago, and I think he's super cool.

[00:02:57] I love his ethos for the company that he's building, which maintains React Admin and does agency work. So I just wanted to shout that out.

Rsbuild 0.7

[00:03:04] Carl Vitullo: RS build released version 0. 7, which they say is going to be the last release before 1. 0. Mark, you had some thoughts?

[00:03:14] Mark Erikson: ByteDance, the folks behind TikTok, have a massive web tooling infrastructure team. They've actually rebuilt Webpack in Rust, and I know that, you know, rewrite it in Rust is its own meme at this point, but it seems like they've, they've truly built a Webpack compatible version in Rust called RSPack. On top of that, they have a higher level abstraction layer called RSBuild, which has an easier configuration format, a little bit like ESBuild does. if you actually look in their docs, they have a migration guide for switching from Create React app to RSBuild. I did that on a little side project a few months ago.

[00:03:55] It was really easy to switch and the compile time dropped from like 30 seconds to less than a second. it feels like a, an actually viable competitor tool.

[00:04:06] Carl Vitullo: Nice. Super cool.

Biome 1.8

[00:04:08] Carl Vitullo: We've also got biome 1. 8. Yeah. I have a soft spot for biome. I was an early supporter of Rome. I have been eager to see what comes out of that.

[00:04:17] So yeah, it looks like they've got like new support for CSS. They have better support for language servers in workspaces, so if you've got like a big monorepo, it should work a little bit better. New reporters, migration, some more linting options, but yeah, Biome is like kind of an all in one. They try to do like formatting and linting and, yeah, it's a bundle play.

[00:04:38] They're taking in a bunch of tools that, were separate and doing it all as one package.

[00:04:42] Mark Erikson: And written in Rust.

[00:04:44] Carl Vitullo: Written in Rust. Sure. So super fast, blazing fast. Is blazing fast still cool?

Astro 4.10

[00:04:51] Carl Vitullo: There's also Astro 4. 10. I am hoping to play around with Astro this month. So maybe I'll be able to actually, you know, say some more intelligent things about what the experience is.

[00:05:01] But I, I know lots of people who love the tool. It looks like some small improvements, nothing too major.

Valibot 0.31

[00:05:06] Carl Vitullo: This is a new library to me, Valibot released 0.31.

[00:05:10] It's a competitor to Zod, which does like schema validation or, you know, data validation through a schema with like type generation and all that kind of stuff.

[00:05:19] This looks like a pretty solid competitor. They talk about, tree shaking and stuff, which I'm broadly skeptical of tree shaking as a general promise. It's very difficult to verify.

[00:05:30] Mark Erikson: My understanding is that Zod, when you import it, you're basically importing a giant object that has all the possible validation types built in, and I think Valobot's sales pitch is that it's a bunch of individual functions, and so you would only import the actual bits that you need.

[00:05:47] And therefore, you're not getting a giant blob of runtime code.

[00:05:51] Carl Vitullo: Yeah, I think they said it was like, could be up to like 95 percent smaller than Zod, while also like significantly simplifying the mental model of the schema and the type validation.

[00:06:02] If I can think about it less and have it affect the size of my code less, like both of those sound like things that I would want.

[00:06:10] Mo Khazali: I guess the thing is, it's a question of how much you want to really optimize your bundle size and at what stage you're at. If I'm recalling correctly, Zod minified and gzipped was about 60kb, something around that size.

[00:06:22] So it is quite a chunky library to add into your dependencies. So, I guess if this actually delivers on that promise and it's closer to 90 percent less than that, which is I guess 6kb, it wouldn't be too bad of a shave to do, I'd say. But, remains to be seen if it's in practice going to be that good.

[00:06:40] Carl Vitullo: Yeah, I just pulled up Bundlephobia for Zod, and it's, yep, 61kb minified, 14kb minified and zipped. Which is Hefty. Yeah, that's enormous. That would give me a lot of pause.

Upcoming Conferences

[00:06:51] Carl Vitullo: Onto some conferences. Mo, I think you had a few.

[00:06:53] Mo Khazali: Yeah, I'll jump right in.

React Nexus

[00:06:54] Mo Khazali: So, firstly, at the very beginning of July, 4th to 5th of July, React Nexus is happening in India.

[00:07:00] One of the great conferences that I attended last year, I really enjoyed. The crowd there was quite a, quite a large crowd as well. I think there's about 500, 600 people. So a massive conference, but people are so friendly and I got to meet a lot of lovely people. So would highly recommend if you're sort of in the South Asia region to, to definitely give it a shot, if you can make it to Bangalore.

Chain React

[00:07:19] Mo Khazali: Mid July, we have Chain React and this is hosted by the folks at Infinite Red. Another one of those great conferences. I've not been to Chain React myself, but I'm, So involved in the React Native community that I get told every year, why are you not at Chain React? And you're missing out on one of the best conferences ever.

[00:07:34] So the FOMO hits real hard every time around Chain React. The folks at Infinite Red are absolutely amazing, and they organized an incredible conference from all accounts that I've heard of. Everyone really loves Chain React, so if you are in the U. S. and you're in the React Native scene, you really do not want to be missing Chain React. If I was in the U. S., I would definitely be at Chain React this month, so I cannot give it more praise than that.

GeekConf

[00:07:58] Mo Khazali: And then, lastly, towards the end of July, we have GeekConf, so GeekConf is another sort of React Native conference with a little bit of a blend of web as well added into it. So that's happening on the 25th of July in Berlin. There's also a day that's dedicated to remote track, but 25th of July is the key date that's going to be happening in person, and I'll be speaking at that conference as well, and hopefully if any of you folks are there, please do come around and say hi, would be lovely to meet some of you in person.

[00:08:24] Carl Vitullo: Heck yeah.

WeAreDevelopers World Congress

[00:08:25] Carl Vitullo: Leaving the list of conferences that us as hosts have personal experience with, there's a We Are Developers World Congress in Berlin, July 17th through 19th.

CityJS Singapore

[00:08:35] Carl Vitullo: There's a CityJS in Singapore. That's going to be July 24th through 26th.

We Love JS Amsterdam

[00:08:42] Carl Vitullo: We love JS in Amsterdam in the Netherlands, August 9th and 10th.

React Rally

[00:08:46] Carl Vitullo: And then the last conference that we're highlighting in the next two months is React Rally, which is going to be August 12th through 13th in Salt Lake City. Actually, I have been to that one in the past and it was pretty quality.

[00:08:58] Mark Erikson: Yeah, I, I would also. Emphasize like React Rally has been fantastic. the organizers are great.

[00:09:04] they do a really good job of giving it a good community feel. I was there last year and attendance was unfortunately just a little down because of trying to revive it after COVID. So if, if you can all make it to React Rally in August, please go. It's, it's totally worth, worth it.

[00:09:19] Carl Vitullo: Yeah, and it's the home neighborhood for a lot of really big people in the React and web ecosystem.

[00:09:25] there are quite a number of people who live generally in Utah and in Salt Lake City. I think Kent C. Dodds is out there.

[00:09:32] Mark Erikson: Kent, Tanner, Ryan.

[00:09:33] Carl Vitullo: Yeah, it's their home neighborhood. I assume they'll be at the conference. Yeah, anyway, cool. All right, moving on to some of our main content here. Mark, you want to start us off?

"SuspenseGate"

[00:09:43] Mark Erikson: Boy, oh boy, oh boy. Okay, welcome to SuspenseGate. So, for the for those of you who may not have been following all the drama on Twitter, we're here for you.

"This is the exact build we'll release as 19.0"

[00:09:55] Mark Erikson: About a month ish ago, a month and a half ish ago, Andrew Clark actually tweeted that, We've, we've updated to a new React 19 release candidate, and we think that this release candidate is going to be the final one, like, these are the actual bytes we plan to release as React 19, unless there's any other major changes.

[00:10:17] Well, there is now cause for major changes. And in fact, React 19 has been delayed semi indefinitely. The React team is going to be doing some updates, and we don't know how long that's going to take. Why are they doing these updates?

[00:10:32] In November of last year, Andrew Clark put up a PR that changed the behavior of the suspense component and how it manages loading children that are suspending to fetch data.

[00:10:44] Previously, if you had multiple children inside of suspense, And they all wanted to fetch some data. The suspense component would give each of these components a chance to start rendering and start the data fetching. And then actually pause and wait for all of the components to finish fetching their data.

[00:11:04] Doing it all in parallel, kind of like a promise. all combination. And with this PR, the React team changed it. So that React really only gives the first child that suspends a chance to fetch, and then it waits for that child to finish loading its data, tries to re render, and then keeps going until the next child component tries to fetch data.

[00:11:28] Basically doing all of that in serial instead. Now, they, if you look at the PR, Andrew listed some potential reasons for this. One is that this actually made Facebook. com load a little faster. But also, it has to do with how the React team thinks. that people should be doing data fetching on the client side.

[00:11:51] And basically their argument is, you, you shouldn't be doing data fetching nested deep in the component tree. Instead, you should hoist it up to the top at like the route level or the page level instead. And so their argument is like, well, we don't think people should be doing this pattern much anyway.

[00:12:11] So it's okay for us to change it. Now, this was done as part of React 19's development, and React 19 is a major version. So you can totally, you know, make changes. It's, it's legal under the terms of semantic versioning. And this was available in the React 19 Canaries, but as we all know, nobody actually tries out pre release versions, everyone waits until it's actually released, and then tries it, and then reports bugs.

[00:12:38] So, this basically went unnoticed by the community for months. And about a month ago, someone mentioned it on Twitter, very briefly, and TK Dodo, the maintainer of React Query, Saw that comment and said, oh, that doesn't look great, and then didn't think about it. And then just a couple weeks later, there was another discussion thread, and suddenly TK Dodo and a bunch of other people began to realize, wait a minute, this is actually a very significant change in how suspense works.

[00:13:08] And in particular, the React 3 Fiber developers, which is the React for 3D game engines, Realized we depend on suspense heavily because we need to be able to load a lot of different things async like game assets. So it's not just about data fetching, it's about lots of other async behavior. And they, and they started showing demos where, everything went from loading in parallel to loading as a waterfall in serial.

[00:13:38] And now example apps were way, way slower as a result. There was a massive firestorm on Twitter. A day or so later, Sophie Alpert from the React team said, We talked about this in a React team meeting today. We didn't realize how many people would be affected by this. But also, this was a very major change to React's internals. We did this, like, seven months ago. We've continued making lots more changes to the internal since then. We can't just roll back this change. We know what we would need to do in order to re enable the old behavior, but it's going to take another fairly significant set of internal changes to do that.

[00:14:19] So, we don't know when we're going to get around to it. Stepping back for a second, at that point in time, the community conclusions were, they already said React 19 is release candidate and ready to ship, and we don't, like, we know this would take major changes. Therefore, the conclusion was React 19 is about to ship with this behavior and we're all going to be stuck with it for the duration of React 19 as a major release.

[00:14:45] Carl Vitullo: Yeah, I don't know, some of the like firestorm framing for this, it makes me a little bit like, I don't know, it's, okay, this was a, this was a confusing behavior, and something that they overlooked, but I am glad that this conversation did happen.

[00:14:59] And ultimately, the React team had this pointed out to them and did respond ultimately, I think, appropriately. So, like, it's, I don't know, how do you, How do you do open source development with millions of people, very few of whom actually try out pre releases?

[00:15:15] Mark Erikson: Yeah, that actually even ties into the events this week of Jordan Harband and some of the package updates going on. Mo, you had a thought?

[00:15:24] Mo Khazali: Well, I was just thinking, well, firstly, ironically, I remember when we did the last, last month's episode, we were talking about how this might be like the quickest release cycle for React, or, well, you know, it'll be a quick transition into Release Candidate and then released, and then this came up. So I find that quite funny that sometimes these things will come up and we can't predict it.

[00:15:41] But I think it's, you know, around the whole expecting people to test canaries and, and release candidates, I almost wonder if there's a different way that that needs to be done and if there's some level of automation that can be done to ensure that not just, you know, apps that are using RSCs and are, you know, the most up to date and exactly architected in a way where Meta wants them to be architected, are tested, but rather, there's a whole wide range of apps, ones that are built over a long period of time, there might be SPAs or other things like that, all of those get tested. I don't know if there's a nicer way to handle that, but I feel like just expecting people to test Canaries and test RCs will not catch stuff like this .

[00:16:20] Mark Erikson: That's the thing, I believe the Vue ecosystem has like a full fledged, I don't know the right term for it, they have a massive automation setup that tests all kinds of libraries across the ecosystem against the latest versions of like Vue and Vuex and Pinia and Vue Router and all these other tools. And similarly TypeScript, every time you push a PR to TypeScript, it does checks against almost all of DefinitelyTyped, or at least like a, the most widely used libraries on, on DefinitelyTyped and across the ecosystem, to try to catch a lot of these issues ahead of time.

[00:16:56] But even then, there's a distinction between, do the library's tests fail, and how are people using that library. I think in this case, React Query had one test that did parallel fetching in a suspense, but it was like two components running locally. And so the effects of it would not have been meaningfully visible in terms of timing.

[00:17:18] Carl Vitullo: Right. Right. And ultimately this is a like timing and parallelism issue. And I don't know, I'm not sure that that's something that would work. have been proactively tested? Like, I'm not sure that it's something that An automated test suite could like reasonably easily evaluate. And I'm not sure that someone would have said, Oh, this is a large enough risk that we need to invest, you know, several days of engineering time in order to make sure that we have test coverage that will flag this if it breaks.

[00:17:48] So I don't know, I, to me, this is just like such a. Niche interaction between, you know, it's, it's such a corner case between the assumptions of the React core team and the, you know, evaluation work that they do against the Facebook project and the, you know, broader needs. So like, I don't know, I saw various negative takes, like, oh, I don't know, I saw lots of various negative takes, I'm not even gonna try and imagine, try and make up one.

[00:18:16] Mark Erikson: the React Summit organizers for the last couple years Have done an event that they call the React ecosystem contributors summit, where they get like 25 to 30 maintainers and contributors to various tools and libraries together in a room. And they just give us a chance to vote on whatever topics we think would be worth discussing and then give us three hours to, talk about it in whatever way we think would be useful.

[00:18:44] So, I was there. There were two topics that were discussed. Two thirds of the room was discussing the technical aspects of the suspense change, two thirds of the group was discussing the technical behaviors. One third of us were discussing, how can we have better communication and interactions with the React team.

Joe Savona: Some thoughts on the suspense changes from 19 RC

[00:19:03] Mark Erikson: A couple of days later, Joe Savona from the React team put up a long Twitter thread, which is very, very good and very worth reading. And he said, number one, we're going to hold off on the React 19 release. We agree that this is a major behavior change. And frankly, we underestimated how many people would be affected by this pattern change.

[00:19:24] So they're going to step back and they're going to do something to do it. My, my, my assumption is trying to do the actual work to re implement some of the older behavior in the, in the reconciler internals. So that's good. Like the community complained, we communicated, they listened, they changed plans.

[00:19:43] These are all actually very, very good things, but that ties into the communications question. Like a semi official way to communicate to the React team is by filing an issue, and the React issues are basically useless in that sense. One thing, they've been full of spam, both in terms of like really, really old issues and literal, literal spam issues, but also like the React team doesn't pay tons of attention to their issues list.

[00:20:10] And so just filing an issue is not necessarily going to get like a quick response. There's Twitter, and a lot of the, you know, React team members are very active on Twitter, and that's great, but it's also not like a formal communications channel. So, what we concluded in our little set of people talking during this Contributors Summit, is that we really need to bring back this idea of a working group.

[00:20:36] For React 18, the React team put together a React 18 working group where they specifically invited 50 to 75 people from across the ecosystem and continued adding to it over time. And there was a public GitHub repo where the React team and the invited contributors could write comments. Anybody could read it, so the discussions were public, but the idea was have a high signal ratio of meaningful discussions and questions about React 18, how things worked, how people could actually use some of the features and what the practical results would be.

[00:21:12] And I think that was a great success. Like, there was a lot of really good information in that repo. So our conclusion, as the little group of people talking amongst ourselves, was we should somehow have a permanent version of the working group. And actually, Tanner Linsley independently tweeted the same thing a few days later, as well.

Tanner Linsley: React needs a permanent working group

[00:21:33] Mark Erikson: So along with that, Joe Savona also said in his tweet thread that we are actively looking at how can we get more feedback on pre release versions and how we can actually Have better communication with the community. So, I don't know exactly what will happen, but I'm hopeful that something like this working group model would be an option going forward.

[00:21:55] Mo Khazali: That's not, you know, too far away from how the React Native team does it, you know, for, for the past couple of years, I'd say, since, you know, Nicola Corti and Riccardo have come into the React Native team, they've been pushing this sort of release cycle where they'll have two, three different people from the community owning the release process for each version of React Native that comes out, and that Inherently add some level of community involvement to the releases.

[00:22:17] Obviously a working group with more and more and more people, you know, about 60, 70 people sounds like there's going to be even more exposure, which is great. But I think it's, it's something that could take a page out of the React native core teams book as well, because they've done it successfully there.

[00:22:29] Mark Erikson: Overall, takeaways are, nobody tries pre release versions, we really need a formal communications channel between the React team and the community that they will pay attention to, and that we can collectively offer feedback that they will see.

[00:22:44] Carl Vitullo: Yeah, I, I, I chimed in on that because I don't know, Reactiflux, we're a thriving subset of the community.

[00:22:50] Maybe we could be a neutral space for that type of communication to happen where they don't need to own the moderation side of things that has not turned into a conversation. So, hey, maybe it will eventually, but yeah. Twitter is definitely, I'm not sure how effective it was ever as like a DevRel, you know, source of truth, but now, like, if you don't have an account, they don't even let you view tweets, so, I think it is past time, well past time for DevRel from the React team to go somewhere else. Like it is, it's been over a month since the last blog post. And other than that, I don't know where any communications from the React team out to the broader community come from. It's basically the blog and the Twitter and the blog is not active. So. Yeah, I hope that that working group concept turns into something a little more effective.

TC39 proposal advances

[00:23:42] Carl Vitullo: But yeah, okay, cool. Next subject, TC39 proposals. A bunch just came out. I'm just going to kind of run through this on the high level. Yeah, promise. try, it looks like it's pretty much just like a quick wrapper on, , you know, new promise, and then you immediately resolve with a value.

[00:23:58] I've done that a number of times, so I guess there's a use case for this, but in the abstract I'm not really coming up with a great example of why you would want to just Take a synchronous value and make it a promise.

[00:24:09] Deferred import evaluation seems useful. it's a way, it's a way of delaying execution of some parts of the import process when you're getting a module in.

[00:24:20] You can, you know, mark it as deferred so that it will not actually evaluate the module. It'll still like parse it and do some other interpretation steps that I'm blanking out at the moment. But it will not actually evaluate the code until later on.

[00:24:33] Mark Erikson: Basically this, this allows. Speeding up, like the initialization process by not running all the code in the application right away on startup, even though you know, you'll need some of that code later.

[00:24:48] Carl Vitullo: Yeah. Okay. There we go. Another one was joint iteration. I thought this was pretty cool because I've needed this a number of times. It's a way of iterating over more than one. iterable at the same time. That's on stage 2. 7, which means it's still pretty far from getting shipped.

[00:25:03] Error. isError seems very useful for, for types. I guess lots of new stuff is moving down the pipe, I don't know how many of these are super important to call out in great detail, but yeah, Mark, Mo, anything that caught your eye is particularly important?

[00:25:18] Mo Khazali: I, I really think Error.isError is the one that I'm most interested in. Obviously quite a while away before it gets to adoption. It's still on the process step two, it's stage two, but hopefully very soon. Well, I don't know how long this process is going to take for them.

[00:25:31] It was interesting. The TC39 meeting that they had was happening in Helsinki, uh, near Future Frontend, which was a conference that we gave a shout out to last month.

[00:25:39] And I happened to be there. That was quite cool to see some of these folks gather together and how they chatted about some of these standards. Just being privy to those conversations was fascinating. So they have a, they have an incredible process that I've, I've not seen anything like before in any other sort of working group.

Panel discussion at Future Frontend

[00:25:53] Mo Khazali: So quite interesting, would recommend. There's a, if you go onto the Future Frontend streams, they actually have a big panel discussion for, from the second day of Future Frontend, and they actually discuss some of these proposals in detail, which is quite cool.

React partners with Codemod

[00:26:05] Carl Vitullo: All right, let's move on to the next one.

[00:26:08] This is, I'm, CodeMod they announced they are partnering with the React team to help migrate to React 19.

[00:26:16] I know, I feel like the React team initially popularized the idea of CodeMods. So this is like not a surprise at all to me. I guess I wasn't really familiar, wasn't really aware of Codemod as like its own separate team. I see, you know, this is posted by the founder of CEO of Codemod, I guess.

[00:26:34] So that's kind of news to me. But yeah, so there's gonna be more Codemods, I guess, to help your codebase stay up to date with React 19.

[00:26:42] Mark Erikson: I am very familiar with code not code mods as a technical concept I had no idea there was an entire company devoted to building tools for code mods as like a corporate thing.

[00:26:53] Carl Vitullo: Right, right as a technical thing Very familiar. I don't really understand what the business case for that would be. I don't know, I guess maybe consulting. Maybe it's a services business.

[00:27:03] Mo Khazali: Apparently the way that they also make it more effective is that they apparently pair it with some AI. It might be a pivot, I don't know, but apparently they pair it with some AI and some nice CLI tools to make your code mods more effective. That's not an endorsement, I don't know if it works well, but that's seemingly their model.

[00:27:20] Carl Vitullo: Makes me a little skeptical, but yeah, I don't know. Codemods generally are great.

[00:27:24] Any migrations and like major refactorings like that are definitely substantially helped by having automated tools that do, you know, even if it's like 60 to 80%, that's still pretty great, but yeah, cool. So there's an official partnership there. So I guess there's a business that is writing these codemods and the React team is in collaboration with them to make sure that they work well.

[00:27:45] That's cool. That's great. Love that it's not just the core team trying to do everything on their own. Yeah, Mark, you want to take us on to React Compiler?

React Compiler

[00:27:52] Mark Erikson: Sure. So, React Compiler came out in beta at ReactConf, and so we're starting to get, you know, various examples of people trying it out hands on in the real world.

I tried React Compiler today, and guess what… 😉

[00:28:03] Mark Erikson: There was a very good post from Nadia Makarevich, I believe is the name, who has written a number of excellent articles about React rendering in the past. And she tried it out on both some toy applications and some larger, real world codebases that she had. And she found that the results were mixed. She expected the compiler to optimize fairly large percentages of the components in those codebases.

[00:28:29] And it only seemed to optimize like 20 or 30 percent. Now, , apparently the compiler tool does have a health check command that will tell you which components it would bail out of because those are breaking the rules of React. And I believe that the updated React lint rules can also give you an indication of which components might not get optimized.

[00:28:51] But her takeaway, I believe her takeaway was You know what? Well, okay, like this, this seems promising, but if real world code bases aren't going to get, or are we going to have like 20 to 30 percent of the components improved, that's not quite what we were pitched. Now, I will note that, uh, Satya from the React, React compiler team, I believe commented here in Reactiflux that, hey, this article is great.

[00:29:14] Like, we got to See these example apps that she posted about, and we've been doing a bunch of additional changes to make sure we're handling those cases. So, I mean, just because it didn't work perfectly in her case, doesn't mean that the compiler's bust. It just means that it's still a work in progress. So having that real world feedback is actually very good.

Understanding React Compiler

[00:29:32] Mark Erikson: And then Tony Alicea, wrote an Excellent article that actually breaks down what the compiler does and what the output looks like and how it works in practice. So, very worth reading if you want to understand what the compiler actually does for you.

[00:29:47] Carl Vitullo: Heck yeah. Cool. Yeah, I guess I'll move us on.

Why don't we have a Laravel for JavaScript... Yet

[00:29:50] Carl Vitullo: I wanted to call out this There's been a lot of, conversation that I've seen around, like, Laravel, specifically, specifically Laravel, Theo put out a video that then somebody wrote a blog post replying to of, " why don't we have a Laravel for JavaScript?"

[00:30:06] And this actually crossed my radar from somebody who's not in the React world at all, they were talking about scoping a project, adding authentication to some app. And they said, "this developer estimated two weeks to add authentication to the product and I thought that was ridiculous. We have that out of the box in Laravel."

[00:30:24] I, I, I chimed in because it's like, you know, I've done auth a couple of times in my life, in my career and like, yeah, you know, okay, sure. A login form, that's not hard to do in a day, but when you get like a settings page and you know, you got to be able to change your email address and reset your password and do two factor authentication and, you know, social login, It's like, you know, I mean, two weeks doesn't sound that wrong to me.

[00:30:48] And he replied like, All of this is, all of that, everything you just described comes out of the box in Laravel. And it's like, alright, you know what, okay, maybe we do complicate things a little bit. Maybe not overcomplicate, but I guess, it, it, we do have so much flexibility and modularity and ability to Write things from scratch in React and, you know, in the React ecosystem more broadly, maybe that we have, you know, as far as the pendulum swings, maybe we have stayed in maximum modularity mode for a little bit longer than might be optimal.

[00:31:21] I don't know. I, I'm curious what you guys think of that. where's the trade off? Where's the optimal line between modularity and out of the box functionality? I

[00:31:29] Mark Erikson: mean, I think a lot of it also is the, you know, the whole back end, front end split. I mean, Laravel, you know, PHP, Rails, Ruby, they are back end languages, and the use case is You know, like, you know, the back end is doing basically all the work for you, and then, you know, there, there might be some additional stuff on the front end.

[00:31:53] And so I think the frameworks there, they've, they've been around longer, and also they evolved to have, we, we need to have everything the back end needs to do all the work. Whereas, JS has always had the front end, back end split, and it's not that we couldn't build something that was, you know, absolutely out of the box like that.

[00:32:13] I mean, there are, you know, some examples of that in the JS ecosystem, but I think it's typically been much more of a, like, I just need a basic HTTP server like Express. to serve up my client side code and then go from there. So, I think the modularity is a big aspect, but then also the differences in, like, the ecosystem historically as well.

[00:32:34] Mo Khazali: I do think, you know, I've spent a bit of time working in the Django world a little bit, and I can definitely see the appeal to having something like Laravel, where so much comes out of the box. Done for you. And that interconnectedness means that it is a lot smoother to do things like you mentioned, like settings on a profile to modify those things.

[00:32:51] They're all like one centralized model in Django. And it's significantly easier to create those sort of CRUD operations for users on like a settings page. It doesn't take you weeks. It takes you a day. And I know a lot of people who've been developing a while, like they spent time in the PHP world or in the Python world with Laravel or Django, and then they, you know, started doing React in our company and they were all like, this sucks, really don't like doing this.

[00:33:12] It was so easy with Django, but I guess it's the pendulum swings and we probably land on some sort of midpoint, you know, I wouldn't be surprised if people start building things on top of Next, which allows it to be a more full fledged opinionated server that also can render and template React code.

[00:33:26] Mark Erikson: That's what Blitz was. Blitz started off as the whole suite of things to go with Next, and then they tried to fork Next, and then they gave up on that idea.

[00:33:35] Carl Vitullo: Yeah, and I mean, I guess this is, over the last ten years, React has slowly, I feel like it's grown in scope of, like, where people want to use it.

[00:33:43] Like, when I first started it, There was a lot of, put it in, like, this spot, this little rectangle on the website, like, that's where React goes, and several years ago, that moved into, most people are using React to build their entire app, like it owns the entire client side, and now we're moving Up the chain into React owns more of the server side as well.

[00:34:05] So maybe that's just kind of like the, this projects like Laravel already owned the data model in the server. And they had to come from there into owning more of the client side to provide a better experience there. And they certainly don't compete with React there in any meaningful way. Like nobody would, I don't think anyone would seriously suggest that projects like Laravel are able to provide. An exact, or a highly comparable, interactive client side experience.

[00:34:35] You know, as I'm saying that, nobody would argue that. I think DHH has seriously argued that.

[00:34:39] Mo Khazali: I was gonna say DHH hasn't argued that yet.

[00:34:42] Carl Vitullo: So, okay, people do People do argue that, but let me add the caveat of offline capable. I don't think anyone would seriously argue they provide an offline capable client side experience comparable to React.

[00:34:54] And so, yeah, I guess, you know, now with, as server components expand in utility and capabilities, like, yeah, maybe we will start seeing more of a Laravel. Or Ruby on Rails type of full ownership of the experience, which would make it more easy. Because that's really the problem here is React isn't even aware of the data model in most applications.

[00:35:18] So that makes it very hard to do CRUD interactions, if you don't have the data, if you don't have direct access to the data. I just thought that was a really interesting framing for this. Like I have all, I've, I've lived in React for many, many years. And so then seeing people talk about how quickly you can do common tasks in a Laravel, it's like, Oh, Shit. Interesting. That's, that is a big difference.

[00:35:39] Cool. Let's move on to Vercel Ship, their conference roundup. Moe, do you want to take us on that?

Vercel Ship 2024

[00:35:45] Mo Khazali: Sure. just the general and quickly running through this, Vercel is obviously moving across and, and taking up more of the, more than just becoming a hosting platform, so.

[00:35:54] There's pieces on how you can collaborate and people in different teams can collaborate and, you know, preview different sort of webpages. And we've seen some stuff like that and more focus on observability. So they've added things like metrics and feature flags. And so there was someone who actually commented on Twitter about how beautiful their toolbar was as well, which I thought was quite cool. But no, there's, there's like a lot of direction around like product collaboration and a push in that, in, in that direction. So that's quite interesting.

[00:36:18] Just on the observability piece, I actually found it quite interesting that hosting providers are going in that space. So Cloudflare a few months ago acquired Baseline, which is also an observability tool, and I think they're trying to integrate it into their workers slash Cloudflare pages space, which is a competitor to Vercel's, you know, hosting platform plus their, their serverless functions that they've got.

[00:36:37] So, or the edge functions that they've got. So I think it's interesting that a lot of them are moving. Past just hosting into that observability space as well. And I think there's going to be a pretty big competition in that space in the next couple of years.

[00:36:48] Carl Vitullo: Okay. That makes sense. Yeah. I haven't yet played with this at all, but I think I've heard people discussing the Vercel, metrics and feature flagging and that, yeah, I think that the, tacking those onto the, to a hosting provider does make a lot of sense to me because I feel like you get, you start getting a lot more things for free if those are all bundled together into one thing, like, I don't know, just having used LaunchDarkly and other feature flagging tools like that.

[00:37:14] It feels like if they knew when a release was happening, if those feature flagging tools knew when a release was happening, I can imagine various optimizations or improvements to the, like, developer experience, the experience of putting out a new release that could be enabled by that. So yeah, that's something I'm paying attention to.

[00:37:34] We'll see how that goes.

TS 5.5

[00:37:35] Mark Erikson: All right, next up, TypeScript 5. 5 is out. And the, the single biggest thing that is interesting about this release is what they're calling inferred Type predicates. So as a little bit of background, one of the nifty things about TypeScript is you can write code that does runtime checks, and TypeScript uses that to narrow down TypeScript type of a particular variable is.

[00:38:00] And part of that is not just having like an if statement, but actually having separate functions that, for example, accept any value, and then they do some runtime checks and you tell TypeScript, if this function returns true, then the actual TS type of the value must be some more specific type. And so you can use that to tie together runtime checks and type and compile time behavior.

[00:38:27] But the issue was that things like filter callbacks for arrays, which return a boolean, didn't do any of that narrowing. And so you might have, like, an array that could be, like, item or null, and you could do a check. In the filter callback and say, if thing is not null, you know, return true, which ought to tell you that by the time we're done, we only have actual items and no nulls.

[00:38:53] But TypeScript wouldn't automatically narrow down the TS types based on callback functions like that. So with TypeScript 5. 5, they've improved the type inference. So that if you have a function that accepts some value and does some checks and returns a boolean, TypeScript will automatically try to narrow down the TS types of the output to be stricter.

[00:39:18] And so, this is going to be a nice little quality of life improvement for a lot of different TypeScript use cases. One other interesting thing that I saw in there, is that apparently they're doing some syntax checking on regular expressions. Mostly just catching things like, you know, like you have too many parentheses in there.

[00:39:36] But that one's actually pretty cool too.

[00:39:38] Carl Vitullo: Yeah, definitely super cool. I, on my list of things that I, that would make me excited, like typescript checking regexes was not on there, so I, Very unexpected for them to even start moving in that direction. But like, heck yeah, please help me make my regexes a little more robust.

[00:39:54] Mark Erikson: One other thing towards the bottom that's under the hood. So they've done some changes on their internal variable definitions. So that they get more optimized by the JavaScript runtime, basically making sure that the same fields always exist. And you don't like occasionally add an extra field to the object dynamically.

[00:40:15] And so because of that, the runtimes are able to optimize the behavior. And they found that it actually improved compile times by like 5 to 10 percent just by making the fields more consistent.

TypeScript 5.5 is a BANGER

[00:40:26] Carl Vitullo: Yeah, I also want to share, Matt Pocock did a really great, just like quick 10 minute video breaking down what's new in TypeScript 5.

[00:40:35] 5. So definitely worth, he's just such a great TypeScript expert. Just wanted to call that out. Great resource.

Mind The Gap talk

[00:40:41] Carl Vitullo: Cool. I wanted to shout out a conference talk by Ryan Florence that came out of Big Sky DevCon. I saw quite a number of people referring to it as like the best talk I've seen in years. I don't know if I would go that far personally. It's a great, it is a great talk.

[00:40:57] It's, it's kind of just, I think I would describe it as like an oral history of the Problem space that React Server Components is trying to address. It just sort of talks about like the difference between, you know, the server and the client and the network being in the middle and plots out a couple of different tools and where they live in that, You know, taxonomy.

[00:41:19] Definitely worth checking out. I mean, Ryan Florence has been around for so, so long. So hearing him just do kind of a dump of history of a problem, I thought was really interesting. It was definitely worth listening to.

[00:41:32] Mo Khazali: I'll jump in with some React Native stuff quickly.

Lorenzo Sciandra exiting React Native

[00:41:36] Mo Khazali: So first, and I'd say most significant news in this space is unfortunately that Lorenzo Sciandra from the Microsoft team is leaving the React Native world and also leaving Microsoft, which is, I would say personally, a pretty big blow to this, to this community.

[00:41:51] He's been such an instrumental part of. Getting more and more community involvement inside of React Native. He's been doing React Native for more than six years and, you know, being based in the UK. I've known him personally for a couple of years now and such a lovely guy. And I think he's moving on to focus something around making sure that the tech space is A little bit healthier and a little bit more humane, as he likes to put it.

debug:mind by Lorenzo 'kelset' Sciandra

[00:42:13] Mo Khazali: And he's been focusing on mental health struggles within the tech ecosystem and within, within a career of tech. So you should definitely check out his podcast called Debug Mind. But really just want to, from the bottom of my heart, say a big thank you to Lorenzo for everything that he's done over the last six plus years.

[00:42:27] An absolute shame that he's leaving us, but I am very excited for everything that he's going to be doing afterwards.

[00:42:33] Carl Vitullo: Yeah, I have repeatedly come across his name when I've looked for React Native resources. He's done so many great lists of like, I can't even remember the various types of lists he's done, but just like major projects in the React Native space and educational resources on React Native.

[00:42:51] Yeah, definitely a big blow to have him exit the ecosystem.

[00:42:55] Mo Khazali: And, you know, more than that, you know, I think Lorenzo has been sort of the person who's been trying to bring the meta team closer and closer to the community. So, you know, Lorenzo, for the first time that I went to Meta's offices, Lorenzo invited me and, Organize that with a lot of the Meta folks to, to bring me over and, you know, for me to be able to chat and bring some of my concerns over to some of the folks at Meta and, you know, that became more of a recurring thing, all thanks to Lorenzo.

[00:43:17] So he's been very instrumental and he's one of those sort of open source maintainer that maintainers that really cares about the community. So yeah, definitely a big blow.

[00:43:24] Carl Vitullo: Yeah, and earlier, Mark was talking about how the React Native team has been a little bit better than the React core team at interfacing, doing like working groups and things like that, and including the community and the development.

[00:43:36] I wonder, I wonder what role he played in making that happen.

[00:43:40] Mo Khazali: A major one, definitely. So, yeah, but. Best of luck to him. I'm sure he's got some amazing stuff lined up that he's going to be exploring next. And yeah.

Expo Atlas

[00:43:47] Mo Khazali: Next up, one thing that I'm personally super excited about is Expo Atlas. So Expo Atlas is almost like a sort of bundle size visualizer, but taken to a little bit of a higher level.

[00:43:57] And this is something that's been missing from the React Native ecosystem for a long time. So just a little bit of context. Bundle size has never been a concern for the React Native ecosystem, unfortunately. For, for, for better or for worse, because it's all sort of sent once in the bundle of an application, when you download it from the app store, people don't seem to really care that much about how much JavaScript you ship, so long as it's downloaded once it's done.

[00:44:19] And, you know, things like app startup time and actually, you know, having a lot of JavaScript and runtime don't affect React Native apps as much because of. Things like Hermes existing, where you have an engine that will have some sort of like bytecode representation and not have to load the entire JavaScript bundle into, into its runtime.

[00:44:35] So that's been a challenge when you're trying to take React Native and put it on the web and deal with this whole universal story. And so, you know, one of the things that I spent a lot of time around React Summit, speaking to Evan and Cedric from the Expo team about was, you know, how do we make sure that some of the third party libraries that have.

[00:44:52] I've been creating over a long period of time in the React Native ecosystem, actually have small bundle sizes when you try to take them to the web. And Expo Atlas is kind of the take that the Expo team has at doing that, which is, well, a lot of these libraries are all CJS based, so if we just introduce tree shaking into the bundler for React Native, It's not going to necessarily solve that problem by itself because most of the libraries won't be tree shakable.

[00:45:13] So then what's the way to do it? Well, let's just visualize the problem, see what libraries are bundling in a lot of crap, and then see if we can slowly start to, as a community, shave some of that off and improve the performance for React Native web apps. This is a slow burn. It's not going to. Change over the next year, two years, maybe even three years, because there's a lot of legacy there.

[00:45:31] But I think it's the right step. It's showing and visualizing the problem. So great tool that's out there. We'd definitely check it out. It shows you in a different way to how like the bundle visualizers that you might be used to, it actually shows you which import of a library you have in your code that is actually causing this library that might be bloating your bundle to be loaded.

[00:45:50] So, you know, it might, it goes down the tree for transitive dependencies as well, which is quite cool.

[00:45:54] Mark Erikson: Oh, that's wonderful.

[00:45:56] Mo Khazali: Really great tool.

[00:45:57] Carl Vitullo: Yeah. I'm looking at this, the visualization of the blog post with the, you know, recursive squares showing the, the bundle size and, oh man, I remember almost a visually, almost identical tool, much less polished.

[00:46:10] Clearly this has someone who did a design pass, but there was a very similar tool that came out for Webpack in like, I don't know, 2014.

[00:46:19] Mark Erikson: There's been a number of them, Webpack Bundle Analyzer, Source Map Explorer, and a couple others.

[00:46:25] Carl Vitullo: I, I like practically made a career out of like fixing performance issues just because I learned that tool and it actually enabled me to do things.

[00:46:33] So yeah, cool. Love to see it. Love to see it in the React Native context. Definitely looks valuable.

[00:46:38] Mo Khazali: Cool. So then a few sort of quick things.

Expo adds Compiler support

[00:46:40] Mo Khazali: Firstly, Expo's now added React compiler support. We saw this in the React Conf app. It was already using the React compiler. So just, you know, if you want to try it out experimentally, you can use the React compiler and see how it works for your app.

[00:46:52] Mo Khazali: Next up is Starlink's React Native story. So this was interesting because it came out during AppJS, which happened last month. So the Starlink app is, is obviously built with React Native and it uses a lot of the expo libraries and things like React 3 Fiber. And it's really cool to see how some of these tools that we all have available to us are used in practice in some pretty serious production apps.

Expo Router 3.5

[00:47:14] Mo Khazali: And then another quick fire one, minor changes to Expo Router in Expo Router version 3. 5. So, just some stuff like, you know, supporting the, the sort of the hash parameters. There's some stuff around native, native intents with deep linking that you'll need for having a more seamless handoff between different Devices, and also for allowing for certain links to, to come with more details to, to really augment the native functionality.

[00:47:38] Another small thing that I think is quite important, that's not actually one of the top headlines with this, is that previously Expo router was using an, a non standard version of the request and response. And with this version, they've, they've standardized it a bit more, which is great because that should definitely be standardized.

[00:47:55] And then a few. Other minor things that I'm just going to run through. One is React Native Vision OS won the Git Nation Open Source Award, which was quite cool. It's a really cool project. Definitely give it a shot. And the folks from Callstack were there at a bunch of these different conferences with Apple Vision pros, trying to get people to try out React Native with Vision OS, which was quite a fun thing to try out.

SF Symbols beta support in Expo

[00:48:16] Mo Khazali: Next up there is sf symbols. So sf symbols is sort of an icon pack that comes default with iOS. It oftentimes feels very Apple esque and having that inside of your app means that the icons are uniform with the OS and they look and feel like it's an iOS application and Expo's added beta support for it.

[00:48:36] This is an interesting one because React Native is obviously cross platform. The main targets that you'll have is an iOS and an Android app, so specifically supporting icon sets and an icon set that's available for iOS means that you may need to have some divergence in your code base if you want to really use those SF symbols, and you'll need to create or choose equivalent Android icons, so a little bit of an odd take, but I'll see you A lot of people seem to really want to use SF Symbols, even with React Native apps.

[00:49:03] So I'm sure that there was a level of feature requests and community involvement in trying to get that working. So that's definitely there. And then lastly, React Native Screens. This is actually a library that you will rarely ever have to use directly inside of your application code, but it's actually being used under the hood by React Navigation, which is by far the most common navigation library within React Native.

[00:49:25] And they've just added some extra minor improvements. One that's quite cool is transparent header support. Obviously on the native layer, there's functionalities on iOS and Android to be able to add a transparent heading that's got a little bit of a blur, and it comes up with some cool effects. You can do that in React Native with the, with the default navigation libraries.

[00:49:43] So React Native Screens has been updated to support that on both iOS and Android now, which is just cool minor changes. And that's just about everything that's been happening in the React Native ecosystem in the last month.

[00:49:53] Carl Vitullo: Nice. Excellent. Thank you for catching us up.

[00:49:56] Okay, shall we move on to our lightning round, see how many links we can get through there?

[00:50:00] Mark Erikson: Yes, because we're already an hour in, so moving right along.

React Internals Explorer

[00:50:03] Mark Erikson: I saw a really, really cool tool called React Internals Explorer. It looks like you write some React code in a sandbox editor. And then it actually digs into the React fiber tree and shows you the structures of that.

[00:50:17] I haven't even had time to play with this, but just like glancing at it and seeing a screenshot. I'm actually really, really excited about this because I love digging inside React's internals. I know most other people don't need to, but this looks really helpful. And the author has already written a whole series of blog posts where they actually go straight into the React source code and explain how specific features of React are implemented under the hood.

[00:50:41] So if you want to know how React works inside, very worth reading.

What's new in JavaScript Frameworks for May 2024

[00:50:44] Carl Vitullo: Yeah. I wanted to call out a blog post from the Chrome team where they just, they do a recap. What's new in JavaScript frameworks for May, 2024. So this is, I guess this is old. It's undated. So I guess it must have come out last month, but they are just, they just quickly round up a bunch of.

[00:51:02] they go through like Angular, Astro, React, Remix, Next, Vue, NUC, Solidsfelt, and a couple of others. Yeah. This is Adi Osmani is. One of the, you know, it looked like they did a video and wrote a blog post with it. I thought it was curious, or I thought it was interesting to see what the Chrome team thinks about JavaScript frameworks.

Memory leaks

[00:51:24] Mark Erikson: There were a few different blog posts that touched on the theme of memory leaks. There was one that talked about memory leaks inside of Node, potentially if you're using the relatively new local async storage feature. the example there was with setTimeout.

[00:51:42] Apparently, Node can be keeping track of async call stacks attached to the context storage, and so you could actually end up leaking a whole bunch of memory if you're using it in certain ways.

Sneaky Memory Leaks

[00:51:53] Mark Erikson: Uh, similarly, there are also a couple of very good blog posts talking about potential ways you might end up with memory leaks in a React application.

[00:52:00] In cases where you're using like use callback or use memo or with React query where you're writing functions that are doing data fetching or something like that, and they're closing over variables that are in scope and they might not even be getting used. But the closure keeps those variables alive longer than you would have expected.

Data Fetching Patterns in Single Page Applications

[00:52:21] Mo Khazali: Cool. So next up is an article that's actually on Martin Fowler's blog. So Martin Fowler being the big thought leader and evangelist of, of all things, application development, period.

[00:52:33] Mark Erikson: Enterprise architecture patterns.

[00:52:35] Mo Khazali: You see, divisive at the best of times, Martin Fowler is, but there's, there's been more and more React articles popping on, and they're not actually written by Martin Fowler, but they're written by someone who works at, whose name is Juntao, or actually, I don't think he works at ThoughtWorks, but he's very close with Martin Fowler, so he writes on Martin Fowler's blogs.

[00:52:53] And he's been doing some really cool work on writing articles that start from the basic principles and expand out and create more and more complex applications that explain a bunch of concepts. So his latest article is about data fetching patterns in single page applications, and it starts with basic React concepts, builds up around, you know, asynchronous states being handled on the client side, parallel data fetching, how do you handle fallbacks, and then things like pre fetching, and then kind of It takes you through this journey and tells you when you should use which one.

[00:53:21] Would recommend it. It's a very, very long read, probably one of the largest blog articles I've seen in a very long while, but it's definitely worthwhile if you want to get a more holistic viewpoint. And he's written a lot of articles like this. Another great one that he's written just to give a shout out is called modularizing React applications with established UI patterns.

[00:53:38] And this is one that Mark is not going to be very happy about, but this one is one of those, which is like, how do you enterprise ify React code, but it's actually a very interesting article that has some thoughts about how you should architect React apps. And some of those patterns, not all of them, are actually very good to make it easier for you to do things like testing and so on and so forth.

[00:53:55] Carl Vitullo: Cheers. Yeah. Oh man, I remember reading Martin Fowler's blog like 15 years ago when I was like starting my career. So just for it to still be relevant is like a little bit mind boggling to me.

[00:54:07] Mo Khazali: The website still looks like it's from 15 years ago as well.

[00:54:10] Carl Vitullo: Yeah. It's unchanged from when I started reading it.

[00:54:13] Yeah. Not a single change that I can identify.

[00:54:16] Cool. Yeah. I wanted to bring up a blog from Snyk, a security. Firm, I don't know, security product service, 10 modern Node. js runtime features to start using in 2024. It's, I have always found it really tricky to stay on top of every level of development over time.

[00:54:35] So I appreciate a little roundup post like this that just sort of calls out a number of new features that I may not have caught the release of. It's sometimes it's hard to see, see the each individual release. So the 10 that they call out are a test runner. Native mocking, native test coverage, watch mode, core pack, the env loader, some import meta fields for the **dirname and **file fields, native timers and promises, permissions module and a policy module.

[00:55:08] Those last two are not super clear to me, but like the test runner and native mocking and test coverage. Super great to not have to pull in a third party tool for that. As well as, yeah, I mean, watch mode. The number of times I've installed NodeMon. If I can stop relying on a third party package for that, I'll be pretty happy.

[00:55:26] I haven't checked that out yet, though. CorePack is actually, I feel like the name of it makes you compare it to Webpack, or it makes me compare it to Webpack, at least. But actually, it's, the main use for it is being able to specify a package manager at a specific version, which is so useful. Um, I appreciate that they have made it, I guess it's a, I guess it's a combination of being able to pin a specific version of your package manager, but it's also, I think, some underlying tools to make cross compatibility possible between package managers.

[00:55:59] Mark Erikson: The primary issue is that NPM has always come pre installed with Node. But if you want to use Yarn or PNPM, or, Bun, I guess, you have to first use NPM to install those tools globally. And that's kind of a one off per system thing. And then you have to remind everybody that they're supposed to be using this package manager, the project.

[00:56:22] And so I think the idea of CorePack is that if you specify in your package JSON, that, Hey, we're actually using Yarn 4. 1 or PMPM 9. 2. It will automatically do the work to make sure that the right package manager is available and being used in that project.

[00:56:40] Carl Vitullo: Right. It fills the gap where, like, PackageLock or Yarn.

[00:56:44] Lock will let you pin your dependencies, left the, you know, the gap of what about the version, you know, for the package manager because the different versions interpret that lock file slightly differently sometimes. Or, you know, I've had a more recent version of Yarn blow away my Yarn or, you know, start adding things like a, a digest half to the, to the lock file.

[00:57:06] So being able to pin a version, super great. Yeah. As well as like having a env loader, so we don't need to use env anymore. But yeah, so I appreciated this as a quick summary of a number of new built ins for Node.

[00:57:18]

Migrating to the Next App Router With Zero Downtime

[00:57:19] Mark Erikson: There was a very good post on migrating to the next app router with zero downtime. One of the pain points with server components is that you have to have the entire application set up with server components as the outer layer of the application in order to use them at all.

[00:57:36] There's no straightforward, simple, like migrate, just a little piece of my component tree. And while you can use the app router with everything still on the client, as a client component, it's still a key step in order to even be able to think about using server components with Next. And so, this article was a good example of how a team with an existing Next app that used the Pages router was able to mimic the routing setup in the app router and carefully, step by step, make sure that things worked the same both ways.

[00:58:05] Switch over and then be able to start using some server components piece within the existing structure.

Deno Standard Library nearing 1.0

[00:58:12] Carl Vitullo: All right, Deno announces that the standard library is nearing 1. 0. That sounds great to me. The standard library is now a collection of 38 packages, they say. I appreciated this. Rather than doing it all in one big bang 1.

[00:58:26] 0 release for the standard library, they're actually going to repeat a process for bringing each of those 38 packages up to stable relief. So they're gonna do it through like a release candidate and then gather feedback with like a a one month timeline for each of those packages to gather feedback.

[00:58:45] So yeah, that's A lot of effort, a lot of energy being invested into creating a standard library and oh man, here's a standard library for a JS runtime.

[00:58:55] Mark Erikson: I'm confused. Are we allowed to have that?

[00:58:57] Carl Vitullo: Right? It's, it, the classic criticism of JavaScript is the lack of a standard runtime.

[00:59:02] So, oh my goodness, we have a standard runtime hitting stable. I feel like that's going to affect the ecosystem in some way, but we'll have to see what happens there. Cool.

Why don't we do Acid tests anymore?

[00:59:11] Carl Vitullo: I'm going to call this one out. This was, I put, I put up one of my tweets. I don't know. I think it's a good question. I'm going to do it.

[00:59:16] I proposed the question out, why did we stop making checks like the ACID3 test? Why isn't there an ACID3 test for, for example, progressive web apps? I remember the ACID test series of, projects was

[00:59:30] Mark Erikson: Browser rendering behaviors.

[00:59:32] Carl Vitullo: Browser rendering behaviors. It was, is the browser you're viewing the web page in standards compliant? Here is something. It should look like this. And I remember checking that in, you know, 2008 or whatever, when I was a wee baby nerd. And, my browser didn't render it correctly, and then a couple years later it did.

[00:59:50] I was considering, like, what factors may have moved us away from things like that, and I feel like it used to be so hard to ship new things, new standards. That it took big coordinated pushes like that, or maybe the ecosystem was also just smaller and the number of players involved were, you know, it could fit in a room, but I feel like we've lost something a little bit in there.

[01:00:12] Like the acid three test was CSS three was ratified as a standard. They put out an associated test for this rendering behavior so that. Users could check if their browser was working in compliance with the standards. And I guess I, I put up the comparison to progressive web apps because like, They are not fully rolled out, like Chrome put out, the Chrome team put out a lot of support for progressive web apps, very much as a attempt, I think, to make web pages viable as competitors to native apps, and it just kind of never really happened, I think in large part because we never got cross compatibility With all the browsers for those capabilities.

[01:00:54] And I don't even know that we, as an ecosystem, as web developers, have a shared understanding of what makes a progressive web app, you know, what defines a progressive web app? How do you distinguish that what you've made meets all the criteria? So, I don't know. I just, it was lamenting our lack of those sort of litmus tests for, I guess, bringing a Technical definition to some of the terms that we throw around frequently.

[01:01:21] Mark Erikson: It's, it's not quite what you're asking for here, but I can point to a couple ways that there's been more efforts to do interoperability efforts. One is I think the latest version of the speedometer benchmark for JS engines was specifically built to include a bunch of different things.

[01:01:38] Reasonable, plausible example applications using various JavaScript frameworks. Like I know that there's like a React, Redux, Todo application as part of the benchmark sequence. So that's been an attempt to semi standardize things and make things a little more plausible. Also, I believe the last three or four years, all the major browser Vendors have done, I don't remember the exact term but like an interoperability effort where they identify like the top five or six pain points of places we know where browser behavior is differing and we're all going to make a push this year to make sure we all work the same way for these things.

[01:02:15] So it's, it's not quite the same as having like the ACID3 test or, you know, a named version of CSS that we're all trying to implement, but it is, it is kind of along those lines.

[01:02:27] Carl Vitullo: Right. Yeah. I don't know. I guess I, I, I think the branding that used to be baked in to those sort of releases served, I think to me, it served a valuable function in developer education. And I think that we've lost something through not having it.

Web Platform Tests dashboard

[01:02:41] Carl Vitullo: Like there was a web platform tests dashboard that like, yes, here is a single place that compares all of the features, accessibility, all of the compatibility across browsers, but it's not actually, you know, as a developer, it doesn't tell me what features are grouped together? What features go well together? What capabilities are unlocked by supporting this thing? We're going well beyond the scope of a lightning round link right now.

HTMX: Simplicity in an Age of Complicated Solutions

[01:03:09] Mark Erikson: all right, and last one we got on the list. HTMX is a library for basically adding attributes to HTML tags that do things like data fetching and automatically inserting the results into the page without having to explicitly write JavaScript yourself, and they put up a blog post entitled Simplicity in an Age of Complicated Solutions, where they have some examples of handling inputs and data fetching with VanillaJS or with React code.

[01:03:37] And they point out and say, look at how complicated this is. Whereas if we just slap HTML into the page and we add a couple attributes, look at how simple this is. And there's, there's some valid trains of thought to this. Certainly you're writing less code as an application developer. I questioned a little bit some of their arguments on general principle, but it is worth reading for an alternate viewpoint on how application behavior should be implemented.

[01:04:00] Carl Vitullo: Yeah, definitely interesting from a perspective of just considering expansion of complexity too. I thought that was, I thought it was cool to read from that lens too.

[01:04:08] Cool. All right. That is all of the, all the links we have. Thanks everyone for joining us. We'll be back on the last Wednesday of the month in here in the live stage of Reactiflux or in your podcast feed as soon as we can after that.

[01:04:20] Mark Erikson: Thank you for listening. Plug, please check out Replay. io for debugging your tests and trying to fix flakes. And also, I'm almost done with a very large revamp of the primary Redux tutorial to make it TypeScript first and explain more things. Carl just pasted a link to the draft PR in there. I would appreciate feedback.

Revamp "Redux Essentials" tutorial

[01:04:43] Mark Erikson: I'm hoping to have this done within the next couple weeks. Like, I'm almost done with the first draft, and then hopefully there's not too much more work to do. So, feedback, please?

[01:04:52] Carl Vitullo: For sure. Awesome. Yeah. Mo, anything you want to add?

[01:04:55] Mo Khazali: Nothing. Just thank you again for having me and always a lovely time chatting with you all and going over everything that's been happening.

[01:05:02] And yeah, looking forward to the next one.

[01:05:03] Carl Vitullo: Most definitely. Yeah. Always good talking to you guys. Cool.

[01:05:07] we, we gather links from, um, a bunch of different sources, including thisweekinreact, bytes. dev, reactstatus, nextjsweekly, the reactjs subreddit. Right here in Reactiflux from the Tech Reads and News channel, um, and directly from people publishing articles, usually on like Twitter or Blue Sky.

[01:05:26] If you see anything that you think that we should be paying attention to, definitely feel free to email us at hello at reactiflux. com with T M I R in the subject line. That's acronym for the show. I read every email that comes in, even the ones marked as spam. If this is the show you get value from and want to support, the best way to do so is to send it to someone.

[01:05:45] Send it to your co workers, help them learn how you know so much about React. Otherwise, you know, submit a review, do stuff like that. But yeah, thank you so much for joining us. Appreciate it. See you next month.