This Month in React, April 2024: So many new releases, React 19 featureset
Transcript from Wednesday May 1st, 2024
- Quick hits
- [00:46] Upcoming conferences
- React Conf 2024 May 15 - 16, 2024. In-person in Henderson, NV, USA
- App.js Conf 2024 May 22 - 24, 2024. In-person in Kraków, Poland
- Local First Conf 2024 May 30, 2024. In person in Berlin, Germany. Followup hackathon on the 31st
- Render ATL June 12-14, 2024. Atlanta, GA, USA
- Future Frontend June 13-14, 2024. Helsinki, Finland
- React Norway June 14, 2024. Larvik, Norway
- React Summit June 14 + 18, 2024. Amsterdam, Netherlands (+remote)
- New releases
- [02:32] React 18.3
- React 19 beta
- [03:15] Node.js v22
- [04:02] Expo SDK 51 beta
- React Native 0.74.0
- React DevTools 5.1
- Next v14.2
- Bun v1.1 (discussion later)
- Pnpm v9
- Biome 1.7
- Supabase goes GA after 4 years in beta
- Docusaurus 3.2
- Gulp v5
- Pragmatic Drag and Drop
- RedwoodJS 7.3
- React on Rails v14
- [00:46] Upcoming conferences
Main Content
- [12:43] New React development
- React Blog - React 19 Beta
- React Blog - React 19 Beta Upgrade Guide
- React 18.3 changelog : dev-only warnings for string refs,
findDOMNode
, default props, legacy context,test-utils
- Internal changes:
- Rename SECRET INTERNALS to __CLIENT_INTERNALS_DO_NOT_USE_OR_WARN_USERS_THEY_CANNOT_UPGRADE
- Fast JSX: Don't clone props object
- Remove defaultProps support (except for classes)
- Ship optimized-but-unminified prod bundles and drop sourcemaps (current package contents)
- Don’t patch
fetch
anymore - Future: patching Date object?
- [33:29] React Native 0.74.0 release
- [38:17] Kotekan
- [39:02] Bun v1.1
- [39:37] JSR
- ⚡️ Lightning round ⚡️
- ⚡️ [45:09] Why I like React (Even in 2024) ⚡️️
- ⚡️ [45:46] Netlify: Introducing the new Next.js Runtime ⚡️️
- ⚡️ [47:18] Design Principles behind the Next.js App Router ⚡️️
- ⚡️ [48:04] Diving into the Node.js Website Redesign ⚡️️
- ⚡️ [48:44] How does
useOptimistic
work internally? (and many other code dives) ⚡️️ - ⚡️ [49:27] Node.js: The Documentary ⚡️️
- ⚡️ [49:56] New Flow Language Features for React ⚡️️
- ⚡️ [50:26] Vercel cuts prices a lil ⚡️️
- ⚡️ [51:28] Redwood Blog: Techniques for Fetching Data: Comparing Next, Remix, and Redwood ⚡️️
- ⚡️ [52:02] Kuto, “reverse JS bundler” ⚡️️
[00:00] Carl Vitullo: Thanks people for joining for April's This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem.
[00:09] Mark Erikson: And boy, is it evolving right now.
[00:11] Carl Vitullo: Boy, is it evolving. Oh my God. There's so many releases. It's so much to get through.
[00:16] So I guess let's try and run through it quick. Coming to you live from Reactiflux, the place for professional React developers.
[00:24] I'm Carl, a staff product developer and freelance community manager here at Reactiflux, running community events like these.
[00:31] Mark Erikson: And I'm Mark Erikson, my day job, I'm a senior front end engineer at Replay where we're building a time traveling debugger for JavaScript with some amazing test analysis features coming your way in the near future.
[00:42] And outside of that, I do Redux stuff.
[00:45] Carl Vitullo: So much Redux stuff.
Upcoming Conferences
[00:46] Carl Vitullo: There's so many conferences coming up in the next, like, two months.
[00:49] We've got this month, why I'm in Vegas. So if you're coming to React Conf, hit me up. If you're local and not attending the conference, come on down and we can do a watch party. Otherwise, I'm probably going to try and organize a couple of pre conf Things, post conf, after parties, ReactConf, May 15th and 16th in Henderson, Nevada.
[01:09] AppJSConf is May 22nd through 24th in Krakow, Poland. The local first conf, I love local first stuff.
[01:18] I think it's just a really powerful way to develop applications that is Kind of complicated. So I love seeing a conference dedicated to it. That's going to be May 30th in Berlin, Germany with a follow up hackathon on the 31st.
[01:31] There's Render Atlanta in June 12th through 14th in Atlanta, Georgia.
[01:36] Future Frontend, June 13th and 14th in Helsinki, Finland.
[01:40] React Norway, June 14th in Larvik, Norway.
[01:45] And React Summit, June 14th and 18th it looks like in Amsterdam with a remote option there.
[01:51] Mark Erikson: I'm still crossing my fingers that I might at least be able to attend ReactConf here in a couple weeks and then I will be speaking at React Summit in Amsterdam as well.
[02:01] Carl Vitullo: Awesome. Very cool. I can't believe how many are crammed into the middle of June. It's, it's a lot of good looking conferences. I know FutureFrontend
[02:09] Mark Erikson: Is he the one who has been involved in like writing a webpack book years ago?
[02:14] Carl Vitullo: I think so. He was involved in Reactiflux pretty actively a number of years ago.
[02:18] I just wanted to give him a shout out because he's been deep in the React community for a very long time and seems like a cool dude.
New releases
[02:25] Carl Vitullo: We're going to move on to a bunch of new releases. This has been a crazy dense month for new releases.
React 18.3 + 19
[02:32] Carl Vitullo: The big ones, obviously two new React versions have been announced at least. There's React 18. 3. Which I think it's just sort of a pro forma release, getting ready for React 19. No behavior changes, just some extra warnings, a bit of improvements to developer experience to facilitate upgrading to React 19.
[02:54] React 19 beta. Ooh, new major. Definitely excited to see all of the stuff going on there. I don't know. We've talked a lot about all of the development going on into React 19 with stuff like Form Actions, useActionState, RSC is obviously going to be big. Lots of form helpers and stuff.
[03:12] Mark Erikson: We'll cover that in detail in a few minutes.
[03:14] Carl Vitullo: For sure.
Node.js v22
[03:15] Carl Vitullo: Yeah, new Node. js major version.
[03:18] Mark Erikson: And I'm not sure where the versioning ties in, but I know I saw an announcement that some version of Node, probably this one, now has support for importing ESM files via Require, which is gigantic. I don't know what it was they had to do to finally make that work, and why they couldn't have done that like eight years ago, but hey, better late than never.
[03:42] Carl Vitullo: Better late than never. Yeah, that, oh man, the ESM versus CommonJS has been such a troubling split in the web ecosystem. So seeing Node finally supporting native ESM import through Require, hopefully will lessen a lot of that pain. Definitely very excited to see that.
Expo SDK 51 beta
[04:02] Carl Vitullo: Okay. Blasting through. We've got Expo SDK 51 is out in beta.
[04:06] That looks interesting. They are including the new React Native release, which we're going to talk about later too. And just lots of other improvements to like cameras and SQLite APIs, iOS privacy manifest, definitely looks like a pretty big one.
React Native 0.74.0
[04:21] Carl Vitullo: React Native 0. 74, definitely pretty big release. We're going to talk about it.
[04:26] A lot more in depth later. Uh, they've got a new version of the yoga layout engine and using yarn three in the default community CLI. But yeah, more details later on.
React DevTools 5.1
[04:36] Carl Vitullo: New DevTools version as well. For React, the React DevTools put out version 5. 1. There's a bunch of changes there, but you know, I don't know. It's the DevTools.
[04:47] Mark Erikson: Mostly related to support for the new features like use action state.
[04:52] Carl Vitullo: Right, love some better DX there. The DevTools have always been pretty powerful and excited to see what the new experiences there look like.
Next 14.2
[05:02] Carl Vitullo: Next, 14. 2. Gonna chat more on that later, of course.
Bun v1.1
[05:07] Carl Vitullo: Same with Bun, version 1.1. New Bun minor. Again, gonna get deeper into it later on.
pnpm v9
[05:12] Carl Vitullo: PMPM put out a new version 9, so a major version of a pretty significant package manager. I didn't quite realize that the P in PMPM stands for performant. The whole idea is there is that it just is MPM, but faster and better. I've heard from a number of people that it's their package manager of choice.
[05:33] I've never substantially used it. I had used Yarn for a long time, but then I never upgraded from version 2. As I understand, the big improvement for PMPM is that it does sort of what Yarn 3 does similarly with not installing duplicate versions of packages when you have them already installed on disk somewhere.
[05:52] So, That seems really cool. They're also adding like CorePack compatibility, which I understand to be a node standard for better supporting different types of different package managers. So, cool to see them supporting that standard. Always good to see behavior become more standardized, as well as improvements to the lockfile.
Biome 1.7
[06:12] Carl Vitullo: We got Biome 1. 7. I have a soft spot in my heart for Biome. I was an early supporter of Rome and it was very sad to see that, I don't know, kind of go into vaporware mode. So I was excited to see that many of the maintainers of Rome forked the project and came out with Biome. They're advertising single command migration from ESLint as well as Prettier.
[06:34] So I guess two commands, one for ESLint, one for Prettier. And looks like a bunch of smaller developer experience improvements for using it. Like, you know, checking staged files with a command flag. And good default linter configuration. Love the project getting a sort of a bundling. Well, how to disambiguate the term bundling.
[06:55] It sort of bundles up a bunch of behaviors from other tools like linting and. Formatting and all those sorts of things. So I like that. I think it's a very interesting project. Definitely check that out.
Supabase leaves beta
[07:06] Carl Vitullo: Okay. Supabase, which is a, I guess, Postgres as a service. I always have conceptualized it as an open source Firebase competitor.
[07:14] I guess Supabase, yeah, Firebase. I didn't realize that they're still, they had been still in beta, but earlier this month they went general availability, so definitely check out the launch event. Week that they did. I have heard it as, you know, sort of an open source darling. I've seen it all over, you know, Twitter, used by many people who do lots of side projects and smaller greenfield work.
[07:35] So if you're considering something like Firebase, if you're considering a back end as a service, definitely check out Superbase because it is generally available. No longer in beta.
Docusaurus 3.2
[07:45] Carl Vitullo: Docusaurus put out version 3. 2, looks like it's mostly performance improvements, a better table of contents from partials, which I guess is, you know, if you stitch together a bunch of documents into a single page, they now have better support for generating a table of contents.
[08:02] And this is a silly thing that I have always had on my mind, but one of the things they advertised was An accurate last mod time in the sitemap. I have found that tricky. I think that makes a reasonably big difference in SEO. You know, you're signaling to Google or whatever search engine that your content is fresh, is up to date.
[08:21] And in the past, I have generally found sitemap generation tools they just seem to not care about that, like they just put together a list of all the URLs. So just seeing that taken seriously by Sebastien, by Docusaurus, I like it. They also mentioned in their release post that they have overtaken Gatsby in NPM downloads, which seems like a pretty significant milestone.
[08:43] Changing of the guard a little bit.
[08:45] Mark Erikson: That is interesting because we use DocuSource for the Redux documentation sites, and it's not like it's getting downloaded continuously in our case, we only do docs updates kind of intermittently. And so for it to actually be getting downloaded frequently suggests there's a lot of people using it for like a non library documentation site kind of use case.
[09:06] You know, more of that static like website beyond just Docs.
Gulp v5
[09:11] Carl Vitullo: This is a bit of a throwback, but Gulp, the now at this point quite long in the tooth build tool, script runner, just released version 5. Man, I haven't thought about Gulp in a number of years, so seeing it cross my path again was just like, oh, Gulp. Nice.
[09:26] Mark Erikson: I'm genuinely surprised it's being actively maintained, much less putting out major versions. I mean.
[09:32] Carl Vitullo: A little bit!
[09:33] Mark Erikson: Admittedly, my own experience is biased. I've been in the React ecosystem where we, you know, webpack, blah, blah, blah, but very surprised to see that it's getting actively developed.
[09:42] Carl Vitullo: Would generally agree.
[09:43] They say in the release post, this release contains four years worth 60 projects. The team closed over 200 issues and pull requests. Cool. It's neat to see. Doing a major version seems like maybe a big ask for a project that is, I think, most likely to be used in a maintenance mode capacity. So, major version there seems like a little bit of a hard sell. Nice to see an old name resurface.
Pragmatic Drag and Drop
[10:07] Carl Vitullo: I'm going to shout this out because it's related to a project that we had the maintainer on as a guest a number of months ago, but Pragmatic Drag and Drop from Atlassian. Drag and drop is brought. I've always found it to be kind of challenging to implement.
[10:23] I remember when I spoke with the, the, the maintainer, Alex Reardon a couple of months ago, he had a lot of really interesting things to say about serving the different use cases in drag and drop. And I think he has been involved in maintaining like three different drag and drop open source libraries. So he's been just very deep in it for a very long time. And it sounded like he really pulled a lot of learning from those different types of uses into this project, made it more like pluggable and, only pull in what you need to get the behaviors you want and things like that.
[10:54] So definitely check that out. If you're considering some drag and drop stuff.
Redwood v7.3
[10:58] Carl Vitullo: Redwood JS released version 7. 3. It's the app framework for startups. I'm familiar with the name, but I've never really worked on it too much.
[11:08] Mark Erikson: Their big sales pitch was that they did single file component setups where you export a GraphQL vary as a variable.
[11:17] Like, conceptually, think of like a view single file thing, where both the component and other pieces were in a single file. By convention, you export a named variable with a GraphQL query, and all the rest of the pieces just hook together from there. However, they had announced about a year ago that they were going to, quote, go all in on server components.
[11:36] I've seen a lot of chatter from their developers who have been actively working on trying to figure out the mysteries of making server components work for anyone not named Vercel. And so, like I said, I haven't even looked at the release notes here, but from what I've seen, they're getting pretty close on having that working.
[11:53] Carl Vitullo: Yeah, that's right. I think I mostly remembered the name from hearing you talk about them as people who are investing pretty seriously in server components. So yeah, new version there. Looks maybe like it has a little bit of overlap with Superbase. Just a little bit closer to the front end half of the stack.
[12:11] But full stack JavaScript application framework, batteries included, backend, React, all that stuff. Definitely interesting.
React on Rails v14
[12:17] Carl Vitullo: And our last new release that we're going to shoot through, React on Rails version 14. This is not something that I've ever made significant use of. I think one of the companies I worked at was using it because they were deeply invested into Rails.
[12:32] But yeah, I mean, you know, if you're using Rails, if you are trying to use React with your Rails app, this seems, as far as I understand, this is the way to do so. So I thought it was worth shouting out a new major version.
New React release details!
[12:43] Mark Erikson: All right, let's roll into a couple of the bigger items from this week. And by far the biggest one is, hallelujah, after two years, we finally have new actual releases of React itself.
[12:57] Literally, there was a guy who had put up a website that was like, what was the time breakdown between consecutive React releases? And, you know, some of these 16 or 17 releases had been like a few months apart, and it had been two years between 18. 2 coming out and today. So, the biggest news is that React 19 is finally in beta, and the React team has an extensive blog post that covers what's actually included.
[13:25] And if you've been paying attention to, you know, the discussions of the canaries and what's been available in Next. js, most of this stuff should not be a surprise. But it's worth briefly summarizing what's there.
[13:36] There's what they're calling actions, which admittedly as the Redux maintainer is a little bit frustrating for me because the word action now has like 15 different overloads. There's what Redux means by it, what MobX means by it, what server components now means by it, but oh, well, whatever.
[13:51] There's a lot of stuff that has to do with forms and async behavior. So if I have a form and I want to send some data to the server and I want to track pending state related to that form submission, React 19 now has multiple new features around being able to provide a callback As the action prop on the form tag itself, there are hooks for tracking form status and trying to handle transitions related to that.
[14:22] As, I unfortunately keep having to say, like, I've read about this stuff, I sort of have the picture in my head of what these things roughly do. I certainly have not had time to play with them, and honestly the kind of apps that I work on today don't even necessarily benefit from this myself. But it is very interesting to see the React team investing in, like, this, this kind of overlaps with a couple of things.
[14:45] One is server components in general, because, you know, Dan's pitch is that server components extend React's one way data flow model to the server. So a server component fetches some data, passes it as props to a child component, which then renders, but if you want to go back to the server component and make it actually do something to force a re render and fetch new data, you have to have some way to reach back to the server.
[15:12] And so my understanding is that server actions are the equivalent of a callback from the parent, except now it's crossing the network boundary And going back all the way to the server. So there's that aspect. There's a hook for optimistic updates and a whole bunch more pieces. It's also interesting because basically all of React's lifetime, we had certain conventions.
[15:33] React was a primarily single page client side app tool, although you could always use it for what we now refer to as the islands architecture, little bits of React inside of an existing page. And you're supposed to use controlled inputs. You were supposed to have a state field for, you know, your first name, your last name, field, et cetera.
[15:56] And you were supposed to keep that data in state and control the input because that matched reacts concept of the UI is always based on your state. And, that still exists, and React still has a ton of logic to make controlled inputs work, but it looks like with React 19, and the new emphasis on forms and actions, that conceptually the React team is now sort of going back to the, well, okay, fine, let's use the platform and have uncontrolled inputs as a default, and grab values from the form, using a form data object. Which is also basically what the Remix team has been telling us for the last two or three years.
[16:40] I, I know that the new React docs now actually have an API reference page for the HTML form tag. Like, there isn't like a usage guide page that says here's how you're supposed to use forms in React, but I believe there is an API ref page that talks about what you can do with the form tag in React. Clearly forms and data inputs are a big emphasis as part of React 19 as a whole.
[17:08] Another big piece is the new use hook, which I guess this means it's finally stable? Maybe? This is the replacement for the long known but always technically internal trigger suspense by throwing a promise.
[17:24] So, instead, now you call the use hook, you pass in a promise, the promise needs to be cached so that you're passing in the same promise reference across renders of the component, but that is what will trigger the suspense boundary in some parent component and make this component wait until the promise is resolved for the data.
[17:44] There's a lot of stuff around the actual. RSC functionality, and there's improvements with things like, with React 19, we now actually get ref as a prop, which means that forward ref can actually go away, finally. And this required a number of changes to React's JSX transform that actually had a lot of internal tweaks that had to be made, like we don't really think about compilation or behavior step of going from JSX tags to React element objects.
[18:18] React originally had the CreateElement API, eventually that got replaced with a somewhat more sophisticated compiler based JSX transform, which still did roughly the same job. And for React 19, they've done a number of changes to the internals of that to make things like passing through ref directly possible.
[18:36] On that note, there was also a PR to change some of the internals where they used to always have to clone. Whatever props object was getting passed into element creation. And that's a hot path because every render is calling this element creation logic thousands of times. And I'd seen some issues filed that complained, like this is a noticeable part of React's performance overhead.
[19:01] So, they've done some optimization work there, and that means that React 19 should have lower overhead in the overall rendering process because it's having to do, less object copying as part of the actual rendering step.
[19:16] A couple other things, you can no longer apply default props to function components. You're now supposed to just use ES6 destructuring defaults. Apparently that still exists for classes, because you can't destructure anything there. There's also been a couple interesting changes on the build tooling side. So, one that I have a personal vested interest in.
[19:37] Early last year, I had done a lot of work to modify React's build pipeline to generate source maps, because React had never shipped with source maps. That meant that any time there was an error message in production, you got a totally unreadable stack trace. And, if you were in the hopefully rare situation of needing to debug and step out of React, like outside of a function component and into the React bundle, well, React's source code is hard enough to read.
[20:09] In its original form, once it's been bundled and minified, it's literally completely unreadable. And for companies like Replay that care about source maps and debugging, that was a problem for us. So I'd done the work last year to add source maps to React's build pipeline. So, in an interesting twist, a week or two ago, Andrew Clark removed my changes from the build pipeline BECAUSE React is no longer going to ship pre minified bundles.
[20:38] Now, to understand some of this, React has always used a very advanced minifier called the Google Closure Compiler. It's like Terser, but much, much more powerful. And it is like the best tool for optimizing and minifying JavaScript bundles, and they wanted to shrink it as much as possible and like really do a good job of inlining functions to make things fast.
[21:01] So when I did the source map work last year, I was capturing a copy of the source code right before it went through closure. But, that didn't have some of the other optimizations that Closure does besides the final minification step. So, what they've done is they've dropped shipping source maps and they've stopped pre minifying the bundle, but they are still doing the optimization and inlining step with Closure. So, in the future, as a, or actually as of the latest beta, what's in the bundle is no longer react dom. production. min. js, which is what it's always been, but rather a react dom. production. js that's still like 500k, un minified, but it's got all the source code optimizations applied.
[21:52] So, your application build step will now do the final minification process out of that. One other interesting side effect here is that if you look at this, strictly speaking, actually ReactDOM. production is now like a six kilobyte file. And this is unexpected. And in fact, if you look at BundlePhobia for ReactDOM 19 beta, it thinks that ReactDOM is now only six, like, like three and a half K minified.
[22:19] Which is clearly not the case, and it's because the Reconciler logic is now in a separate file, React dom client . If you think about writing web apps now, ever since React 18, when we switched over to the new CreateRoot method, that comes from the react-dom/client entry point. So, they've re architected the bundles so that the bulk of the code is in that slash client file, and because of that bundle phobia, it doesn't actually trace through and connect the dots to see that both these files end up getting used in a real app.
[22:55] Finally, a couple other bits that are stirring up some controversy. So a couple of years ago, the React team announced that they were patching the fetch method in order to allow caching in case, you know, multiple components are trying to make similar requests on the server side.
[23:09] And many people got pretty justifiably angry about this because we learned back in the mid tens, patching global objects in JavaScript is a really bad idea. So the React team has finally given up on that and they've reverted those changes for the final release. And they've said. If you want to make sure you're deduplicating requests, wrap your request logic in the cache method.
[23:32] Which makes it really ironic that Andrew Clark just tweeted today that they might actually end up patching the date object down the road in order to prevent hydration mismatches. I don't know. I understand why he says that. I am not sure this is a good idea. I don't have a better solution. So, we'll see how this one pans out.
[23:53] Carl Vitullo: Yeah, I am empathetic to that. And he does talk about, as long as it's standards compliant, nobody has cared about patching internals, people haven't complained about polyfills, and dates are such a pain in the butt when you're doing hydration. Just, you know, it's so easy to have them accidentally rely on current time, which then causes a hydration warning and is just super annoying.
[24:14] So I can understand the motivation for doing it, but yeah, agree, it's, you know, patching stuff is scary, it's risky.
[24:19] Mark Erikson: So we've got a beta out, and I actually was not even expecting a beta this soon. I did not expect that we would see a beta for another couple weeks, and it would actually be announced at React Conf.
[24:31] I do not expect a React 19 final at React Conf. I could be surprised, but the fact that it's only been in beta for a couple weeks, Plus, I'm still seeing lots and lots of PRs flying through in the React repo. I, I would not expect React 19 final for at least another three or four months, but I have no specific info on that either way.
[24:54] Carl Vitullo: Yeah, I also want to call out a couple of other less conceptual changes, they seem a little bit more like pragmatic, use the platform kind of adjustments. React 19 adds support for document metadata directly in rendered React output. Previously, this is the sort of thing that you would use a tool like React Helmet to render.
[25:14] You know, if you're putting document metadata, title, link, meta tags, stuff that normally lives in the head. Part of your HTML. Now React is adding support for rendering that pretty much anywhere. And then React will do the work to figure out that it needs to go in the head, and putting it there at all. That's pretty interesting. I have been routinely let down by React Helmet, which it just has a lot of bugs.
[25:39] It was one of the first open source React libraries that I ever remember coming across like way back in 2013 14. And it was written by the NFL, which always struck me as like, what? The NFL? So it Great name, like the NFL putting out something that renders to the head and calling it helmet is just like, oh my God, that is the perfect name.
[26:01] So I love that. But then I just, oh man, I ran into so many weird bugs and edge cases every single time I tried to use it, which often I ended up compromising on behaviors because it just didn't work and there was no viable alternative. So excited to see. First party support for that without having to use a janky out of date library from eight years ago.
[26:21] So that's nice. Kind of related to that, so, you know, keeping the theme of dumping stuff in your rendered output, they're also adding better support for style sheets in rendered output. They call this out in the release page saying, Style sheets require careful positioning of the DOM due to style precedence rules.
[26:38] And I guess this is going to be a little bit related to the patching platform things. They've got a precedence prop on these link tags. So you know, so not only can you now render link tags in your output instead of having to figure out how to put them in your head, then you can just put them in your rendered output anywhere, signal what level of precedence they should have, and React will do the work to figure out.
[27:04] Where it should live. Interesting. Seems to unlock a lot of new ways of using CSS in your React projects. It strikes me that it may inspire a new wave of, like, maybe not CSS in JS libraries, but may inspire new ways of Making use of CSS from your React components, of scoping your styles to your logic.
[27:29] Definitely find that interesting. And another slightly related feature is the port for async script tags they talk about. Previously it was considered kind of, actually I don't know that I ever saw enough discussion of this to say considered an anti pattern. Just didn't feel right to render a script tag from your React component like you're already in JavaScript.
[27:48] Why would you then load more JavaScript from your rendered output of your component? It feels weird, but they're calling out support for async scripts normal. They say normal scripts and deferred scripts, load and document order, which makes rendering these kind of scripts deepen your component tree challenging, you know, that's kinda the problem I was articulating there in React 19.
[28:05] We've included better support for async scripts by allowing you to render them anywhere in your component tree without having to manage relocating and duplicating script instances. So, that's, again, a little bit interesting. I can imagine, I have run into situations where using React is maybe not the best tool for a specific type of UI.
[28:25] You know, like, things like A complex map, or a highly complex and interactive data visualization, or there's a lot of things that you might want to render to like a canvas, or to WebGL, or in an iframe, or things like that, where React either can't do it because of security limitations, or because, you know, you can't render A component in WebGL or Canvas.
[28:50] So there are circumstances where I've either bailed out of using React and just said like, Nope, everything inside this component renders once, and then some other script takes over for it. So in circumstances like that, I could see this being a significant experience improvement. And again, building on that, they're also adding support for preloading resources.
[29:09] So the React DOM package now exports a couple of new, I guess I'll call them helper functions, listing them here. PrefetchDNS, Preconnect, Preload, and Preinit, which are similar to like the link or meta tags. You give it a URL and. Sort of a configuration object, and it signals to React that you will want these assets, but not right now.
[29:30] It's not like rendering out a style tag or a script tag, but it's saying, here's a resource. I want you to resolve the DNS, or connect to the resource, but don't start loading it yet, or start loading it, but don't start parsing it yet. So it looks like a lot finer grain control over external resources.
[29:49] So combined with greater level of control over how resources get loaded, and then clearer, simpler semantics around taking those resources and rendering them from a component, It does seem like it unlocks a lot of really powerful behaviors. I think it's going to introduce some churn into the ecosystem, but I can at least see, I have run into a lot of problems where I can see this set of tools being a pretty big unlock.
[30:17] So excited to see it.
[30:18] Mark Erikson: And then one more item that's all the way down at the very bottom of the beta release notes is support for custom elements aka web components finally work properly inside of React. I've never used web components. I've tried to read the threads that have had hundreds of comments and complaints.
[30:40] I have a vague partial sense of what the problem space is. In general, like with React, we pass props and we pass real JavaScript values, objects and numbers and whatever. But with web components, there's the issue that, you know, like there, there's something about the attributes versus properties distinction.
[30:59] Like HTML is you're defining attributes that are strings. DOM objects have properties that can be mutated and these are not always the same thing. So like you, you can't just always directly pass real objects into a custom element, the same way we would pass a prop from a parent to a child in React.
[31:21] And there's been like a whole bunch of other interop issues trying to render web components inside of a React component and pass data and handle events between these. And so the web components community has complained for years that, well, every other UI framework manages to make this cooperate. Why can't React do it?
[31:43] it's a reasonably fair complaint, but there'd been an issue filed all the way back in like 2016, 2017 saying, so React, are you finally going to make this just work? And it took another four or five years before an engineer from Meta actually sat down and implemented it. Now, apparently part of the problem.
[32:02] It was unclear what the exact behavior semantics should be. I guess there is no single specification for how Web Components define, like, what kind of event props they take. And a lot of questions about the exact mechanisms for passing Props from a React component to a web component. So like the React team's like, well, okay, there's like a half dozen ways we could do this, and these are kind of mutually exclusive.
[32:27] We're not the experts here. How would the web component community like us to build this? And everybody had very different opinions. So that was part of the reason why this took multiple years to happen. But, eventually, there was some adequate kind of consensus reached, and so a meta engineer actually went in and did a ton of work, a couple massive PRs to implement the support, and it got merged, like, two years ago, but it was always in, you know, under a feature flag, just in the experimental branches.
[32:56] So, React 19 now finally ships with, quote, proper support for web components, and all three people who care cheered.
[33:06] Carl Vitullo: Well, one of them is in the chat here, definitely interesting, I don't know. Like you said, I've been loosely paying attention to it for years at this point, and generally loosely paying attention to web components for even longer than that, and Cool.
[33:18] I don't know. Good to see. I will continue to loosely pay attention to see what kind of effects it has on the ecosystem, but I'm a little bit skeptical it's gonna make big waves.
React Native 0.74.0
[33:29] Carl Vitullo: Cool. Okay, React Native. They have officially released their 0. 74 version, which is gonna be I actually talked to someone when I was at React Miami about some of the work they've been doing.
[33:40] So the, the One of the things included in this is Yoga 3. 0. Yoga is the Flexbox layout engine re implementation that powers React Native. It's, it's one of the core technologies that facilitated React Native approximating web layout. And I had, I had spoken with someone at React Native who said that it took them a long time to sort of spin back up on development, you know, some internal priorities and, people moving, they lost some expertise on that. So they had to reinvest, re relearn how to develop it.
[34:15] So cool to see that in here. It looks like it fixes a couple of layout bugs that were, you know, non standard. They were different from the semantics on web. It was something about. Like, you know, row reverse columns with like start and end edge was not behaving correctly previously, and now it is. So you may find some weird margins.
[34:34] They're also removing a tool called Flipper by default. You can still add it back in. Inspecting React Native layouts, network requests. Uh, it sounds like it has a lot of overlap with the React Dev tools in, browsers. Uh, it was deprecated in 0. 73. Thank you, Cedric and chat. And is now being removed by default.
[34:52] Mark Erikson: I'm very curious what the debugging story is. As usual, I have not worked on React Native. I don't know what the debugging process is overall.
[35:00] But if they're removing Flipper, I'm curious what the intended workflow is for debugging tools. And I see someone says Chrome DevTools.
[35:07] Carl Vitullo: Yeah. I think when I was using React Native, this is now close to three years out of date. I believe I was already using the Chrome DevTools at that point. So it sounds like this shouldn't be too impactful on too many people.
[35:19] Yeah. Community CLI for React Native, I guess, to make an analogy, sort of the create React app for React Native is now. Using Yarn 3 for new projects by default. So that's a reasonably opinionated change. I know that Yarn 3 has very different semantics from Yarn 2.
[35:38] Mark Erikson: My, I would assume that they're going with Yarn's node modules behavior by default rather than the attempt to do the plug and play, don't extract everything on disk approach that Yarn 2 tried and failed to get out there.
[35:52] Carl Vitullo: Can confirm using node-linker/node-modules.
[35:55] Mark Erikson: I actually got to meet the primary maintainer of Yarn, Emil Nusson in Paris.
[36:00] We talked a bit about, you know, where Yarn stands. Like Yarn 4 is out, but apparently kind of, Came out a little past, you know, whatever preparation deadline the React Native team had for trying to figure out things on their end. I don't think there were too many big changes between Yarn 3 and Yarn 4, but it is interesting.
[36:18] You know, we mentioned earlier that, you know, PNPM has gotten a lot of popularity. And so, like, a segment of the ecosystem is going to be pretty, you know, pretty much set on Yarn 3 for the foreseeable future.
[36:30] Carl Vitullo: Whoa, I consider myself a Yarn user, and I didn't even know they had a version 4. 0. Looks like it was released in October of last year. Interesting. Cool.
[36:38] React Native Navigation version 7 is out, which looks like some of the major improvements there are around the configuration of it. Previously, talked about how previously there were of difficulties with Types, and basically you needed to keep your types manually synced with your route configuration.
[36:57] So it looks like they've made some general architecture improvements, such to where TypeScript types can now be inferred from the root navigator with a static param list type, and it'll be available anywhere UseNavigation hook. So that's cool. Needs a, like, one line script. Global namespace adjustment in TypeScript in order to enable.
[37:16] But that seems like a really big improvement. Type support in your navigation is definitely a lot more safe. So that's really good. And last React Native thing I'll do is just a small shout out. There's a Vision Camera package that just released a 4. 0. Looks like it supports a lot of Powerful camera stuff, you know, like QR codes and like some other visual recognition stuff.
[37:41] looks like a really cool project and definitely some big React Native relevance.
[37:46] Mark Erikson: On the note of React Native, I was at a React Connection and React Native Connection conference in Paris last week.
[37:53] And I've always been a web dev, but it was interesting to me just sitting through the React Native talks and half of the material was familiar, half of it was like a completely different ecosystem that I'd never heard of. It was very interesting to see how there's just this entire different branch of the React ecosystem that I basically didn't almost even know existed in terms of mindset and what they're dealing with.
Kotaken, RSCs with just Bun
[38:17] Mark Erikson: So, rolling through a few items very quickly. A new experimental server component framework that I had never even heard of until I saw it pasted in the links like an hour ago called Kotaken. And the interesting sales pitch here is what would a React framework look like if Bun we re the only tool in the tool chain.
[38:37] This sounds very interesting in a lot of ways. Certainly the tool setup makes it sound like it's a lot simpler. It sounds like it has some interesting variations in how they're trying to use server components. I assume based on the description that it's brand new and highly experimental, but you know, another example of playing with the baseline ideas of server components and seeing how a different framework makes different choices around it.
Bun 1.1
[39:02] Mark Erikson: On that note, Bun 1. 1 is out and it actually has Windows support. And as the, you know, the 1 percent of web developers who is actually a Windows user, cool. Yay. I'm excited by this. I actually played with Bun briefly on a very small work project a couple of weeks ago.
[39:19] I was trying to prototype some SQL changes and Bun has SQLite support built in. So rather than try and mess with Postgres adapters or whatever, I just used that and it ran, it worked. I don't have further experience to report on, but I'm very excited to see BUN support getting fleshed out.
JSR, by Deno
[39:37] Carl Vitullo: I wanted to talk about JSR, the JavaScript registry being put out by the Deno team. New registry is pretty interesting to me. We've seen a lot of experimentation in package managers, but ultimately all of them still hit NPM.
[39:52] And the Deno team was talking a little bit about how that's a bit of a shame. We've had so much experimentation happening, but so little of it happening At that level, where a lot of behaviors are ultimately driven from. A couple of notable changes that they've done, this is ESM only, which is definitely going to be a pretty big level up for React. The ecosystem as a whole, I think, just, you know, ESM versus CommonJS has been such a pain for so long. I think a clean break in a new package registry might be a bit of a kick in the pants, as it were, just to kind of force the issue and say like, nope, clean break, new stuff.
[40:33] They do say that JSR is backwards compatible with NPM, so that should facilitate migration at least. Obviously moving to a whole new package registry is a bit of a tough sell. Maybe not as tough as something like switching from Angular to React. As it were, but I think it's, I think it's up there. You know, if you are trying to use a new registry, but like, oops, there's no express, like that's just pretty hard.
[40:58] A lot of the assumptions that you have about what open source code is going to be available. It may not be available. So I think that's going to be a little bit tough. They also said some interesting stuff like TypeScript has emerged as not only a way to write JavaScript with compile time type checking, but as a test bed for the latest JavaScript language features coming out of TC39.
[41:17] That rang really true to me. So seeing a team push the boundaries of something as, you know, maybe a little bit esoteric and like less thought of as a package registry is, I don't know, I appreciate that they are also following the cutting edge Broadly across the rest of the ecosystem as well. They talk about Node is no longer the only relevant JavaScript runtime outside the browser.
[41:40] Some other really cool stuff. I think something I saw was package provenance through a tool called SIGstore, this is sort of like, Supply chain attacks, if you're familiar with that, where how do you know that the code you believe you're installing on NPM is actually what you expect?
[41:58] So provenance is dealing with that sort of end to end guarantee that something is what it claims to be. There have been a couple of notable Vulnerabilities, actually not even vulnerabilities, just straight up attacks where an open source project solicits a new maintainer, has malicious intent and publishes some kind of script, some kind of backdoor.
[42:19] You know, whether that is trying to attack the end application that is consuming the library, or I think more frequently they have been attacking developer machines to then try to gain access to other parts of the system. I know there was a notable example a couple of months ago. Maybe years at this point ago, where somebody installed a crypto miner into a install script.
[42:42] So people's developer laptops started mining crypto for them. So all that to say, package provenance as a core part of the package registry, I think is a really important area to explore. And contrasting something like package provenance Verifying contents with the, I would say, kind of failed attempt NPM did of doing like NPM audit.
[43:05] You know, that was so unsuccessful that like Dan Abramov put out a post talking about how it was broken by design, like just the fundamental assumptions it made about security and how you address security issues being so wrong as to be harmful.
[43:18] I have a reasonably high degree of confidence in the Deno team generally. You know, it's a project started by Ryan Dahl, who created Node in the first place. So having him come back and say, I got some things wrong. I'm going to try again in a new context with Deno. And then now expanding that into, I think that The Node ecosystem got some things wrong with how packages work.
[43:40] I'm going to try that again. I think that's very exciting. I am not going to immediately jump on it and start using it for everything, but I am going to be paying pretty close attention because I think this is a serious attempt at a very complex and large problem space. Let me just run through a couple of guarantees, expectations that the JSR team has put out.
[44:02] As for what a package manager should do, they say it should embrace ESM as the web standard for JavaScript modules, should be designed for TypeScript from first principles, should be simple, fast, provide excellent developer experience, should be free and open source and work anywhere that JavaScript does, and should build on the success of NPM, not fork it.
[44:20] Seems pretty good. There's a couple other really good posts that I'm just going to dump in chat here. Those will be in the show notes as well. Some other things that I think are important, every module must be scoped, which I think is a positive change. It's always a little bit funny, you know, on NPM modules that don't have a scope feel somehow more official in some way.
[44:39] It's so just requiring that all packages are scoped kind of eliminates that funny little. Bifurcation in the ecosystem. Like, is it scoped or is it not scoped? It also has a concept of multiple scopes per account. I saw a mention of four scopes per account as a limit. So being able to manage different scopes without having to set up like a dummy account, which I believe is how that has to work on NPM.
[45:02] It's been a while since I've had to deal with that myself, but that seems like a really good idea. Interesting, useful, evolution of the ecosystem.
⚡️ Why I like React (Even in 2024) ⚡️
[45:09] Mark Erikson: And then hitting a couple of the lightning items really fast. We've commented how there's been a whole series of articles and tweets and complaints about, you know, being, people being frustrated with. React as a technology, based on the slow pace of development, or, you know, poor communication from the React team, or, you know, React just doesn't feel as modern as other frameworks that are adopting things like signals, etc.
[45:36] And so, I thought this post on why I like React in 2024 was well written, and just a decent alternative train of thought to some of the negative chatter.
⚡️ Netlify updates their Next.js runtime ⚡️
[45:46] Carl Vitullo: Netlify put out a blog post introducing a new Next. js runtime, which I was pretty surprised about.
[45:52] I think of Netlify as a static site host. When I think Netlify, I generally think Buildstep. Static assets, essentially static HTML and JavaScript served by a CDN. So seeing them talk about a runtime for a framework that I consider to require a server, it's pretty interesting to me. That seems like a pretty large evolution in their product offering in a pretty interesting way.
[46:18] And. You know, Vercel's level of influence on React and it's coupling to the cloud runtime environment has been a little controversial to say the least. So seeing some more competition there is definitely pretty interesting. I guess relevant to that, I also saw somebody wrote a blog post discussing how Cloudflare is the best alternative to React.
[46:40] Vercel, which I'll share as well while we're talking Vercel competitors. Definitely interesting. I guess this is not a new thing from Netlify. They say this is Next. js runtime version 5, so definitely pretty cool. Supports the app router, fine grain caching, on demand and time based revalidation. Oh, maybe a big one.
[46:59] This is a problem that I've run into on Netlify using Next. They now support the Next image component. By default, so being able to optimize your images automatically through the next image package is definitely a pretty big, like, performance and user experience win. So that seems pretty good.
⚡️ Design Principles behind the Next.js App Router ⚡️
[47:18] Mark Erikson: There was also a really good tweet from one of the Vercel devs, I think just like a day or two ago, talking about design principles behind the Next. js app router. And frankly, it was an extended length tweet that really was a miniature blog post, and it talked about some of the ideas that it's really about layouts. and being able to identify which pieces of the page need data and which can be pre cached. And the fact that they actually don't expose things like the request object directly so that they can better detect which pieces could be cached versus which pieces have to be fully re rendered on the server side.So, whether or not you like the approach, it's clear that they've put a lot of actual thought into it. .
⚡️ Node.js website redesign ⚡️
[48:04] Carl Vitullo: I saw a blog post from Node. js about their website redesign. I thought this was a fun, technical write up to white paper, relevant to a lot of, relevant to our jobs. You know, like we do lots of website redesigns. I thought it was pretty cool. Just to see, you know, they talk about a failed attempt at restarting it with a nodejs.
[48:25] dev domain. In retrospect, this might have unintentionally doomed the project from the start. Yeah, it seemed like a really good breakdown of the technical challenges and organizational struggles of Doing a major website overhaul. So yeah, definitely check that out. They talk about reassembling the airplane while in flight. Always a fun metaphor.
⚡️ Dives into React features ⚡️
[48:44] Mark Erikson: There's a website I've run across that has been doing a whole series of dives into the actual React codebase and picking out specific features like the new Use Optimistic hook. And talking about how they actually are implemented in React.
[48:59] And one of React's strong points has been that it is a black box and you don't need to know how it works internally to be able to use it. You need to understand the mental model of the data flow. But you don't have to dig into the code and worry about the actual implementation details. But, I frequently see people asking, how does such and such a feature in React work?
[49:20] And so I appreciate that the person behind this site has been doing dives into the codebase to try to explain things.
⚡️ Honeypot releases Node.js documentary ⚡️
[49:27] Carl Vitullo: The people behind the React. js documentary, Honeypot. io, which I believe is a recruiting platform, put out a documentary on the origins of Node. js. I haven't been able to give it a watch yet, but their React. js documentary was. Very good. Got to watch that at, on the big screen at React Miami last year, and I got a chance to speak with the filmmaker who put it together, who did all the recording, and found her very impressive. She's very skilled. So definitely check that out.
⚡️ Flow ships React features ⚡️
[49:56] Mark Erikson: The flow type system, which was a competitor to TypeScript and then in a sense, basically died outside of Facebook like three or four years ago, because the flow team didn't ship often and they didn't really, frankly, care about the community, has still been working on things and they recently announced some new language level features for React components. I think we might've touched this briefly last time, but they've added some actual syntax for defining components and prop types in React, which is interesting
⚡️ Vercel updates pricing ⚡️
[50:26] Carl Vitullo: Another small update, Vercel is cutting prices a little bit, or they are updating their Infrastructure pricing, which they expect to reduce costs for most users. So, cool. Looks like it's not a major alteration. It's not going to be like an order of magnitude fix, but it's include some like finer granularity on bandwidth costs.
[50:48] So instead of per hundred gigabytes of bandwidth, it's per gigabyte. Well, which should help a lot. I saw it discussed, you know, if you use 105 gigabytes of bandwidth, now you'll be billed for 105, not 200. So a couple of little things like that. I saw some chatter about a limited number of people who had costs shoot up quite a bit, but that seems to be relatively rare.
[51:11] if you have a very particular performance characteristic on how you're using the Vercel platform, it may not be a big cost savings, but it just, you know, as I was reading these, as they're breaking down the price changes, it looks generally like I would expect it to reduce costs.
⚡️ RedwoodJS compares data fetch methods ⚡️
[51:28] Mark Erikson: And then finally, the last one I'll mention is the Redwood JS, which we mentioned earlier, you know, had originally been focused on using GraphQL to define data fetching needs for React components.
[51:40] And over the last year, they've been doing work to adopt server components. And they just put up, they put up a blog post that. Showed some comparisons in data fetching between the next AppRouter, the next PageRouter, Remix, and Redwood. there are some variations in how the tools work and some of the trade offs. I always appreciate posts that actually try to cross compare things.
⚡️ Kuto, reverse JS bundler ⚡️
[52:02] Carl Vitullo: I saw a neat project called Kuto. They called it a reverse JavaScript bundler. And it's around reusing your code as you're shipping updates to your application. This is something I've thought about a number of times at different companies I've worked at, but never made any significant headway on actually addressing.
[52:22] You do a production build, you produce your new set of bundles, you upload those to the, to your production server. And you know, like most of that code didn't actually change. Like presumably just made, A bunch of small alterations. Like, I can't imagine that any new production release affects more than like, what, like one to five percent of your overall code?
[52:43] Maybe even less when you start including dependencies and, you know, vendored code. So it looks like this is trying to sort of do a diff, kind of ship a diff on production releases, which is super cool. Like, if you can Do a new production release and know that much of the code that didn't change is still going to remain cached by your existing users, then that seems super cool.
[53:06] They say, you know, just really quick, like first line of the page, for a real world site with three megabytes of JavaScript, updating the React dependency resulted in a 71 percent smaller download and a 28 percent faster startup time on an old phone. So I don't know exactly what the process of using this tool looks like, but.
[53:24] Seems like a pretty compelling performance improvement. Reverse JS bundler, new category of infrastructure maybe.
[53:31] That's everything I got, thank you everyone for joining us. We'll be back at the end of this month because we're recording late. We record on the last Wednesday of every month here in the live stage of Reactiflux, and we'll try to get back in your pod feed as soon as we can after that.
[53:45] We gather sources from This Week in React by Sebastian Lorber, from Bytes. dev, Reactstatus, React JS Weekly, react Digest, the React JS subreddit here in Reactiflux, and direct from people publishing articles. If you see anything newsworthy, definitely let us know in the #tech-reads-and-news channel in Reactiflux, or you can email me directly at hello@reactiflux.com. Send that with TMIR in the subject line just to help me find it. It's an acronym for the show.
[54:13] I read literally every email that comes in, usually even the ones that are marked as spam, so if you send me an email, it'll go in my brain.
[54:20] If this is a show that you get value from and want to support, best way to do so, share it, send it to your co workers, say, hey, this seems like a really useful way to stay on top of everything.
[54:29] And if you could leave us a review on Spotify or whatever platform that you listen on, that would be super helpful as well. I'm also seeking sponsors for this. I'm trying to professionalize. I've got a new logo. Looks all nice and fancy. If you are interested in getting your product or company in front of a group of professional React engineers, definitely reach out.
[54:50] Thanks so much. Talk to you next month.