This Month in React, September 2024: Async Components??, a React 19 cheatsheet, static Hermes, and trademarks drama

Transcript from Thursday September 26th, 2024

New releases

Main Content

⚡ Lightning round ⚡

Conferences (React, Javascript)

Carl: Hello, everyone. Thank you again for joining us for the September edition of This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem. We're coming to you live in Reactiflux, the place for professional React developers, and we're supported by Infinite Red, a little bit more on them. I'm going to do something different this month. I'm going to do the ad read after our You know, quick hits at the start. [00:00:21]

Hello, I'm Carl. I'm a staff product developer and a freelance community manager here at Reactiflux, uh, where I run community programs like these events and help keep the community operating. [00:00:31]

This month we don't have Mark, sadly. He's in Turkey, um, I think. Not sure if he did a conference, but he just couldn't swing it this month. [00:00:37]

Mo: And I am Mo. I head the mobile team at Theodom. I'm quite active in the React Native ecosystem. Get very involved in a bunch of different conferences and some open source here and there. [00:00:47]

I organize the React Native London, community. And basically oversee a team of different developers who are specialized in React Native. So, happy to be here to chat, as always. [00:00:56]

Carl: All right, straight into some new releases. [00:00:57]

Node v22.8.0

Carl: We've got Node version 22. 8. I didn't see anything super big that caught my eye in this change. New Node, minor version released. [00:01:06]

Deno v2 RC

Carl: We've got Deno v2 release candidate coming out. It looks like this is coming out in Continuing the trend over the last couple months that we've discussed of Deno kind of walking back some of its opinions, they have gone pretty hard on Go style dependency management and a couple of other Go and other highly opinionated back end languages. [00:01:25]

They're kind of walking those back. Stuff like, they had been Encouraging people to use window instead of process. They are changing that in order to be more compatible with existing NPM modules. Just generally be more compatible across the ecosystem. Yeah, a couple of other things like that too, like making it easier to use with NPM. [00:01:41]

Generally making it more compatible, which I think is why they're walking back some of their highly opinionated opinions. [00:01:47]

Relay v18

Carl: We've also got Relay version 18. Are people still using Relay? I don't really have a good sense for its, I don't know, usage. I know, obviously, Facebook still uses, Meta still uses it, but, yeah, not sure how much community uptake it's had over the last three or so years. [00:02:01]

Mo: Not much on our side. [00:02:03]

Carl: But a change that should make it a little bit easier for people to start using, they have added IntelliSense for the Relay config file. Just getting started, I've tried to get started with Relay two or three times over my career, and just never got over that initial hump of figuring out how to get it working. [00:02:17]

So, uh, maybe some stuff like that will help. Make it a little easier to use. Not having used it, I can't really speak to the other changes they have, but you know, improve validation of argument types, an alias, catch, throw on field error. Cool. [00:02:28]

Redwood v8

Carl: There's also Redwood with a major release, version 8. Redwood is sort of trying to be the Laravel of the React ecosystem, sort of an all in one framework that does all the things that you need. Instead of making you find all the packages yourself to glue the bits together, which seems pretty cool. Yeah, this major release upgrades a lot of dependencies, adds Docker support, which I was a little surprised to see. I, I think of Docker support as not something a framework needs to, like, explicitly add, but cool. [00:02:53]

I guess maybe they're making it a little bit easier to just get running in that environment, which since Docker is such a widely used primitive, that makes a lot of sense. Seems cool. They talk about an experimental SSR and RSC setup, so if you're doing server side rendering, or if you're interested in server side rendering and server components, might be, should be easier. [00:03:12]

As well as adding support for background jobs, which is definitely something that an all in one framework, I think, I would expect to provide. So that's cool. [00:03:20]

Mo: The Docker support is really interesting because It's almost in direct, I want to say, almost opposing to how Next does it, which it seems to me like Docker is like, hey, you have a Docker image and you can basically use it to deploy your full stack web app into, into whatever cloud platform you want to use. [00:03:38]

Super easy, primitive, that's agnostic to whatever cloud provider you want, you self host it, you scale it up yourself, however you want, and our batteries included framework will just work. Whereas Next is notoriously difficult to be able to, uh, self host. So I just find that interesting. Maybe it's directly done as sort of a distinguishing factor compared to Next. [00:03:55]

I don't know, but I find it quite interesting. [00:03:57]

Carl: Yeah, makes sense. I have preferred to host anything I do in Docker for most of the last 10 years, so it's, that will make it easier. I'm interested in trying out Redwood, so having it better support my preferred environment will definitely help with that. [00:04:09]

Epic React v2

Carl: There's a new release of Kent C. Dodd's Epic React, version 2. The overview of the course, it's going to teach you React fundamentals, hooks, advanced APIs, suspense, advanced patterns, performance, and server components. I was a little surprised I couldn't easily find like a diff of what is being covered and what they're focusing more on, uh, between the old version and the new version, which I had been hoping to see. [00:04:33]

I have not bought it. I consider myself an epic React dev already, so I don't feel like the target audience. But yeah, they're doing a 40 percent off promo right now, so if you have an educational budget at work, definitely consider spending some of it on this. it's about 420 right now. Nice. [00:04:48]

Full price is 700, and I think it's jumping up there in about two weeks from time of recording, which is on the 25th. [00:04:55]

RsPack v1

RsBuild v1

Carl: Some kind of big news. RS Pack and RS Build both released 1. 0 in the last month, about two weeks apart. RS Build is like a Rust based build tool, if you have not paid attention to previous episodes where we've discussed it. [00:05:10]

A decent amount. And RSPack builds on top of that to provide a Webpack compatible bundler. I feel like this was all the way back to like 2014 15 when Webpack was new. I mean, Webpack really replaced tools like Gulp. I think I went straight from Gulp to Webpack, and it was a massive just step change improvement. [00:05:28]

It was clearly better in just doing everything. Uh, but It was really complicated to configure, uh, not the fastest tool. So like, almost immediately people were talking about ways to make it faster, ways to make it do the great things that it did in a better manner. I feel like, uh, especially in the web ecosystem, we love our tools to be fast and snappy. [00:05:50]

so a counterpoint to that, people have been interested in having a faster, better solution than Webpack, but the flip side is that Webpack does so much that it's just really hard to actually make a replacement. So I feel like this is a culmination of like a decade long process. [00:06:05]

project to produce something like that. So to get a Rust based natively compiled language build tool that provides drop in compatibility with an existing massively complex, massively used tool. Awesome. Seems really cool. [00:06:20]

Metro 0.80.11

Mo: So, speaking of bundlers and staying on the same thread, as you will know, React Native has its own bundler that, uh, is purpose built. [00:06:28]

or the use of React Native apps. Um, and it's called Metro. So, Metro just released a more of a patch than a minor although React Native's versioning is a little bit confusing because everything is a minor because they want to be able to do as many breaking changes as possible, but they released a patch and there was some insane performance benefits here, so They took the resolver step, which was a bit slow within Metro, and they made it around 15 percent, sorry, 15 times faster, and that made a massive difference. [00:06:56]

So when they ran it on the, uh, Expensify app, which is notoriously a large scale, open source React Native app, the total build time, was brought down from around 13 seconds down to about 3. and that's about 4 times faster for the whole build process, right? So resolving is just one step of it, they've made that significantly faster, but that makes a big impact on the overall build time. [00:07:16]

And so this is really cool, but one of the added benefits of this is because it's, it's, it's a, it's a patch here, it's actually not a breaking change at all. So you can use it 3 versions back, 3 major React Native versions back, and it kind of works. So all you need to do is just bump your dependencies and you'll get the faster resolving times, which is really cool. [00:07:34]

So big shout out to the Metro team, specifically, uh, Rob Hogan's been working on this. They did a really good job, and hopefully it just makes our dev tools a little bit faster, which we all love. [00:07:42]

Carl: Yep, yeah, right. Like I just said, we love our fast dev tools in the web ecosystem. Cool. 15 times faster in a patch release. That is rare. Very cool. [00:07:52]

Effect 3.8

Carl: Wish I could say more about this, but Effect has released version 3. 8. Cool. Effect seems really cool, but it's also got a really steep learning curve because it's basically an entire new, like, standard library and programming paradigm all at once. It seems really cool. What I've seen in it, it seems to take a lot of inspiration from functional programming tools like languages and environments like Elixir. [00:08:15]

Just encouraging you to build more like composable APIs? Yeah, we, again, we've talked about this a little bit in the past, so it, I, I won't fully rehash everything, but it's a huge, massive, steep learning curve that seems really cool and possibly worth it. So it's, you know, it's, I feel like I say this so many times every episode, but this is something that I'm really curious about, learning more about and using more and yeah. [00:08:39]

if you like functional programming in web, definitely. Consider looking at effect. [00:08:43]

Astro 4.15

Carl: We've got Astro 4. 15. Big change, they say that Astro actions are stabilized. Um, and it looks like they've swapped out how those actions are configured so that it's a little bit more concise. [00:08:54]

Uh, you describe the shape of the data that it receives and what to do with that data when you get it. Rather than treating it like a whole request where you then, like, do the validation and the error handling yourself. That's adding some opinions to it, but doing a validation schema and then providing a handler that receives valid data that conforms to the schema that you provided. [00:09:16]

Seems like a pretty solid abstraction point there. There's also some other things like, the astro islands pattern. you could previously configure it to load those islands asynchronously, idly, when the, when the tab is idle. Uh, and they've now added a timeout so you can set a maximum time that it will wait for your page to go idle. [00:09:36]

Uh, which seems like a nice, you know, 99th percentile performance improvement. If, if, if you're on a slow device that never goes idle, that's going to cause problems if you're only loading when idle. [00:09:45]

React Email v3

Carl: So we've also got a new major version of React Email, uh, version 3. 0. Looks like this is another, you know, release getting ahead of React 19. [00:09:54]

They have swapped out their rendering. So it's now async by default. as well as adding a new component library, improving performance. They added a superbase integration so that you don't have to manually, like, render and then copy the output into superbase, which seems nice. I'm a little surprised to see a new component library here, but I guess in an email environment there are just so many ridiculous constraints that, uh, I guess it makes sense that you need a specialized component library for that environment. [00:10:20]

But yeah, uh, React Email, if you're doing anything with emails, that seems like a pretty solid tool to use. [00:10:26]

React Native 0.76 RC2

Mo: So, I've kind of stuck the next one in. It's not really a release, but it's a release candidate, so it's kind of a blurred line, but we'll just go with it. The second release candidate of React Native 76 is out. [00:10:38]

So, when I say, for those who aren't in the React Native ecosystem, when I say 76, I mean 0. 76. It's just, it's so far up that we've just We just get rid of the zero because it's easier to say. But anyway, React Native, 0. 76, Release Candidate 2's out. Um, now, this will still take a few more weeks, at least, to, to land, but, this version of React Native is going to be, quite monumental because the new architecture will be the default. [00:11:02]

Going forward from this version. Now this new architecture is nothing new. It's been around, it's been talked about for years now. Um, contrary to the name, uh, it was new a while ago. Um, but it was a, it was a massive undertaking because you're basically gutting the internals of React Native, replacing it with React. [00:11:18]

Something that's totally different in terms of how the native layer is handled. And so you're needing a new rendering engine, you need a new way to interact with native code and the native APIs. And so what that's meant is that this, it's had this long tail of getting library maintainers, 3P libraries, and, and, All of these things ready so that app developers don't have that much of a pain with some of their libraries not working if they switch over to the new architecture. [00:11:43]

And so hopefully it's going to result in a lot more stability, some performance gains. We're waiting to see, but this is going to be a big release and you can still use the old architecture, but new one is the default. And it will be going forward. So, very exciting times, very monumental times. It's probably going to come with some teething pains as it does when you do such a major rewrite, but we're keeping our fingers crossed. [00:12:02]

They've put a lot of work into this. [00:12:04]

Carl: For sure, yeah. And as we've discussed many times on here, especially Mark, nobody tries really as candidates. So if you're using React Native, just At least give it a shot. See if there's any, like, obvious failure points, because, uh, open source maintainers love hearing about those growing pains as you're trying to switch over. [00:12:20]

This is a great opportunity to do it. We're RC2. We're running out of candidates. [00:12:24]

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

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

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

Upcoming conferences

Carl: Moving on to some upcoming conferences. There's a lot, so I'm gonna just do, like, half of these, because we're already 15 minutes in. Mark and I will both be at SquiggleConf in Boston, Massachusetts, October 3rd and 4th. it's organized by a conference buddy of mine, Josh Goldberg. [00:13:32]

I'm looking forward to it. It should be, should be a great time. It's going to be at the Aquarium in Boston, which seems great. there's also going to be RenderCon in Nairobi, Kenya, October 4th and 5th. React India is in Goa, India, October 17th through 19th. And React Brussels in October, uh, 18th, Brussels, Belgium. [00:13:51]

There's also Next. js Conf in San Francisco on the 24th of October. [00:13:55]

Mo: And then, if you're in London, ReactiveLabs London is happening on the 25th of October for the in person day and the 28th of October for the remote day. I will be there. I'll be doing a talk about React Native there, so if you're around, come and say hi. [00:14:07]

Carl: Uh, I think Mark will be there too. Sadly, I will not. I will be in Mexico City, having a great time. There's also Halfstack London in London on November 13th. [00:14:16]

Mo: And then this is the announcement that I've been waiting a long time to make on this conference, but we have the two month rule, so we're trying to remain impartial. [00:14:23]

We are doing the first ever React Native conference in London. So, RNLConf, React Native London conference, effectively, is happening on the 14th and 15th of November. in London, central London at the Brewery, which is this like old building from the 1800s, uh, where a bunch of the monarchs of the UK went and visited, and it was a big festive place. [00:14:42]

Anyway, it is now an events venue that we have gotten, and we're gonna have a lot of core people from the React Native ecosystem there. Charlie Cheever, the founder of Expo, is gonna be there. we have a lot of different cool folks from Meta, from Amazon, and from a bunch of different places coming to share. [00:14:54]

Ideas and talks with everyone. If you are interested in joining, we have also, I've just made a discount code for anyone who listens to the podcast, so it's TMIR. Feel free to just grab a ticket that way, and hopefully you'll save a little bit of cash as well. [00:15:05]

Carl: All right, into our main content. [00:15:08]

Bulletproof React updated to include Next.js

Carl: Bulletproof React got updated for Next. js. This is a simple, scalable, and powerful architecture for building production ready React applications, it describes itself as. Um, so this, I guess it's a set of example apps, to help you get started. I wanted to call this out because it seems like a pretty good resource. You know, it's a question we get in, you know, Reactiflux all the time. [00:15:30]

It's like, hey, where can I find a, production grade application to use as a reference? I want to learn. I want to learn more about how they do it. and yeah, this seems like a good resource. It's, it's a whole ass. They have an example app written in a couple of different frameworks, so they have updated it to use the app router, I believe, and yeah, seems like a great resource. [00:15:52]

New React Native Debugger

Mo: Cool. So, this month we had React Universe Conf happening in Wroclaw in Poland. I was there hosting the conference and there was a lot of React Native stuff that was announced. now they were kind of s I want to say soft announcements in some capacity because people kind of knew about them already. It wasn't anything like mind blowingly new, but it was really cool to see the output of a lot of hard work that people have been anticipating for a while. [00:16:14]

So the first one was the new React Native debugger. just a little bit of context on some of this. Debugging in React Native has been a pain. Anyone who's built with React Native knows that, like, debugging has been a mess. Like, you could use a bunch of different tools in conjunction with one another. [00:16:29]

Some of them worked for certain things, other ones worked for other things. there was a point where, you know, you used Flipper for a while, and Flipper wasn't great. everyone really did not like Flipper, and so it got deprecated because it was just not really usable. so it was a lot of different tools that you needed to have in your tool belt to be able to effectively debug. [00:16:45]

the new, the team at Meta tried to kind of, go from a fresh blank slate and say, hey, how do we build a really good debugger that resembles some of the experiences that people are used to with other frameworks and other other languages? And so they built a completely new debugger that's fully built on the Chrome DevTools protocol. [00:17:00]

And it looked like it was, from what we saw at the conference talk, it looked like it was a lot more reliable. It addressed a lot of the minor pain points that you felt when you were trying to debug. And I guess the big thing was that we finally have reliable breakpoints. Which was a real pain to get working within React Native. [00:17:16]

So, really, really, exciting stuff to, to, to get. And it should be public soon. So we're excited to get, get our hands dirty with it and, uh, and try it out. [00:17:25]

Carl: Getting into the Chrome debug protocol seems like such a massive improvement here. Instead of using some kind of like bespoke debugging system, I love that you can just actually tap into a widely used tool that a lot of people are familiar with. [00:17:38]

Mo: And it makes sense in terms of the direction that, you know, React Native is going, which is they want to make it more friendly for the web devs to be able to come in and build native mobile apps, right? So you don't want to force React web devs to learn a totally new dev tool framework or a model. You just use the tools that people are familiar with. [00:17:55]

And so I think it was a great choice, and it looks good. So we'll wait for it to come into the hands of all of us, and then we'll play around with it and make it better over time, and it'll be a great time. Oh, yeah. Cool. [00:18:05]

Hermes new Runtime Bytecode Translation

Mo: So more stuff from React Universe Conf. Another announcement, almost like a thing that we saw into, was, Hermes, which is the JavaScript engine that's used with React Native on most apps, now has a new runtime sort of bytecode translation. [00:18:19]

Now it's very complicated and complex, and the talk explains it far better than I do, because it's some really low level stuff, so you kind of need to wrap your head a little bit around assembly and some, some stuff like that. A little bit of context, just to contextualize this, I think helps. last year there was a talk by the Hermes team at React Native EU called, uh, talking about this, this new concept of Static Hermes, which was, could we take JavaScript code and, uh, Make it typed native code, and sort of compile that down so that you get near native, if not just native performance, using C Um, and so that was a really cool concept, and the benchmarks that they ran from their early tests was showing that it was massively faster to execute JavaScript code because you were basically executing native code there. [00:18:59]

it was a really cool approach of, you know, How you bypass the restrictions of JavaScript's runtime. But there were some limitations in the sense of how people use React Native in practice. And, you know, people use a lot of different features like over the air updates, which means you can kind of replace your JavaScript bundle. [00:19:17]

with a server and add new code to a mobile app without going through an app store. So that's like a big feature that a lot of people use in React Native. And so this wouldn't work with the current model of static Hermes. a lot of different build tools. when you, when you pass your code through something like Babel, it loses the type annotations. [00:19:32]

So how does that then get compiled down to, you know, typed native machine code. It was hard to really wrap it into the ecosystem and how people are using and developing React native apps. So, Intermediately, the Hermes team's been working on sort of runtime bytecode translation, which means, Okay, well, if we can't do this at compilation time, could we? [00:19:52]

Find ways to boost performance at runtime and compile things to native instructions without needing to necessarily rely on things that you might only have at compilation time, like your type annotations. whilst being able to still let people do things like over the air updates. And so that's this. [00:20:08]

concept of the runtime bytecode translation. This isn't landed anywhere and it will take a long time. It will probably first go through Meta's internal process of testing and seeing how it works within their apps. And then if it's stable, it'll phase, in a phased approach, get drip fed to the rest of the community. [00:20:24]

So it's going to take a little bit of time, but it's really interesting stuff and it can have massive performance gains when you're running really computationally heavy tasks that you would previously run in JavaScript, using this bytecode translation. [00:20:35]

Carl: Interesting. Okay. So I remember Hermes. That's like, that was like a V8 competitor. It was a runtime for JavaScript optimized for React Native. So it sounds like this is going to be doing. Like, you know, all these JavaScript runtimes, they always have various levels of, JIT, just in time compilation happening. I remember, you know, V8 has like TurboFan, and I don't remember any of the other brand names. [00:21:00]

But, okay, so this is sort of a new type of JIT sort of thing, where it, like, over time will create a I don't know, like codify the bytecode so that it doesn't need to do the JIT every single time? Is that, am I understanding that right? [00:21:14]

Mo: That's what it seems like to me. Again, there's a blurred line between static release that happens at compilation and this, which is kind of JIT. [00:21:22]

And this is a little bit, there is some level of caching that you can do, right, because those instructions don't change commonly. They're changing once every time you kind of do an over the air update. So, um, a lot is still unknown. it's just more, showing the possibility of if you have unannotated JavaScript code, how much could we, compile it down to bytecode and still get some of the performance gains that you can get out of something like Static Hermes. [00:21:46]

Which would be a lot more aggressively, compiling things down and, and it has a lot more context because of having access to the source code and being able to run this at compilation. So it's a more practical step that they're trying to address with how the community uses React Native and how probably Meta uses React Native internally as well. [00:22:03]

Carl: That makes sense. My mental model here is aggressive caching of JIT bytecode. Definitely will be curious to see how that shakes out as it starts to roll out. Exits idea stage and enters production stage. [00:22:14]

React 19 Cheat Sheet

Carl: All right. A bit of stuff on React 19. Man, I'm a little sad Mark isn't here today because there's a couple of new resources and some, some new info that I'd love to get his take on. [00:22:23]

But yeah, so Kent C Dodds put out a React 19 cheat sheet and it looks pretty great. You know, even just kind of casually skimming this, I learned several new things that I hadn't realized. Even, even as someone who considers himself to put a decent amount of effort to stay on top of things as they happen. [00:22:40]

I still learned about like four or five new things from this cheat sheet. Probably the single biggest one is that since when could we use async functions? Like we apparently in React 19 you can do if you know you're doing a function component like you do now you can just mark that as async and it will return a promise like async functions do and React just like knows how to handle that. [00:23:01]

That makes a lot of sense. I am curious how that, I guess where I really wish I had Mark to talk about. This instead of me is, I don't really understand the difference between the suspense primitive of like throwing a promise versus now this where you can just return a promise. Yeah, this is a really great single page cheat sheet, you know, eight and a half by 11 with a bunch of great resources. [00:23:25]

You know, it talks about like what the use hook is for, talks about the better error reporting, resource preloading APIs, so you can make sure that You know your fonts and your images are available. Loading style sheets with precedence. Uh, I, something I had known was that React 19 will let you render like scripts and style sheets just within your output and it will hoist them up to, you know, be Loaded as appropriately, something I didn't know is that you can signal their precedence, their relative precedence. So, you know, default precedents or high precedents. This is, this is a base level style sheet that needs to apply to everything versus this is a, you know, could override those base styles, things like that. Really great resource. Kent C. Dodds, of course, putting out lovely educational resources. [00:24:10]

What’s new in React 19

Carl: There's also a great, What's New in React 19 blog post put out by Vercel. Mostly the bulk of the content talks about how the rendering model for React has evolved over the years. Uh, I thought this was just a really great breakdown of why. [00:24:25]

We've gone from why React is pushing server components and like what the value proposition there is. It has a really great series of diagrams showing like, all right, this is how, this is how data fetch and resource loading happens in a single page application versus an SSR application versus now what React server components unlock. [00:24:47]

And just showing like the data flow of like server to client. And it really does a good job of illustrating those waterfalls and how those waterfalls end up hap end up being imposed by the rendering model and how server components change that rendering model to enable fewer waterfalls to happen. another good resource talking about new things unlocked. In React 19, there was a good post talking about build time components, which is distinct from like server side rendering or server components, pretty related to like, you know, SSG, static site generation. Yeah, static site generation. [00:25:22]

If you say that acronym SSG, the presumption is that that refers more to something like Gatsby, which is a one time, it doesn't have a server, it has static generation. so this, this discusses build time components, I think sort of as a complement to server rendering or server components, where as part of the build step, as part of, you know, your transpilation and compilation and whatever, you can statically generate. [00:25:47]

Some of your, some of your resources, some of your pages, some of your components. I thought that was a good call out as new technical capability. Returning back to my earlier thought on the cheat sheet, I saw in real time Kent C Dodds learning that you can return a Promise from a component. So just like earlier this month, he put out on Twitter like, oh, you can, you can just do this. [00:26:08]

You can just mark it as async. Amazing. So just to drop the link to a good thread in there, but really good. I'm not sure what the difference is between that. You know, classic suspense, throwing a based thing and just doing an async function. [00:26:22]

A milestone for TypeScript Performance in TanStack Router

Carl: Moving on. TanStack had a really great post discussing a performance optimization they did for TanStack Router. [00:26:29]

This is a very different type of performance optimization than most that we see discussed. This is not like runtime performance. This is not, you know, how the library works while you're using it. This is an optimization they did in your editor. So like, as your site grows larger, because their routing is type safe, it's actually doing a lot of, it's actually throwing a lot of work at the language server, at the TypeScript language server that your IDE is running. [00:26:56]

In this blog post, they break down a pretty complicated site that has, I think they say, This example has 400 route definitions with validated search parameters, and I, you know, it takes like three seconds for the language server to get back to you. So, like, if you're writing code and you, like, open IntelliSense to see, like, oh wait, what, what query strings can this receive? [00:27:17]

Like, sitting and waiting for three seconds as it parses that. Not great. but yeah, they talk about improvements they did for that. And just because, like, type safe routing is super cool and super difficult, and like, how often do you think about the performance of the TypeScript language server in your IDE? [00:27:34]

For me, never. so just seeing this, like, Deep technical write up of how they've improved the performance of something that I have never thought about is pretty great, pretty interesting. [00:27:46]

"we’ve decided to make a few changes to ease the adoption of Next 15"

Carl: Cool, an update on Next 15, which is not out yet. Yeah, they said, we've decided to make a few changes to ease the adoption of Next 15. [00:27:54]

We'll relax the React 19 requirement for the Pages router so you can upgrade in your own time. I appreciated this because my read on the Next. Ecosystem right now is that there's a lot of attention being paid to the app router, but technically that's Bleeding Edge. That's the newest, still experimental grade, kind of. [00:28:14]

So they encourage you to use it in the same way that open source maintainers encourage you to use release candidates. But strictly speaking, the Pages router is still where the business is. So seeing them talk about sending support for that into React 19 seems good. Bethany, for the app router, we decided not to block on the general release of React 19. [00:28:34]

So I guess that they are looking to release. Finished non-experimental app router, before or, or they're decoupling released app router from the React 19 release. [00:28:45]

Mo: Does that mean that they would ship the app router apps if you start a new app, router app with Next, that it would just be using like an RC of React 19, or would it just be using React 18 unless re 19 gets launched? [00:28:59]

Carl: There was some confusion a while ago because they were using release candidates by default. Uh, I don't remember where that landed off the top of my head right now, but I think that's right, but I can't answer you definitely. I'm just looking at this thread again and I see someone ask a very similar question. [00:29:15]

How do you relax the React 19 requirement when React is bundled into Next? Do you maintain a release for 18 and 19? Did not get a response, so not sure. This is kind of continuing the trend of version confusion with Next and React, like, it's not very clear. [00:29:33]

Mo: I wouldn't personally feel comfortable using an RC with Next, if, Next 15, if they say, we've tested it, it's stable, but then at the same time, I wouldn't trust it to work well with React 18 either, because I would suspect they haven't tested that enough. [00:29:46]

So, you're in this no man's land where you're like, do I just stay on Next14 until it's actually, you know, stable and React 19 is launched and out of our seat? Interesting questions. [00:29:57]

Carl: Yeah. Confusing, but a similar, you know, vein of confusion as we've had for like most of 2024. That confusion has not been cleared up. Confusion remains. [00:30:07]

Trademark disputes!

Oracle, it’s time to free JavaScript

Carl: There's been a couple of trademark dramas this month. Like, I don't know why all the trademark stuff is coming out of the woodwork right now, but um, the Deno team put out a, like an open letter requesting that Oracle release the trademark for JavaScript. and this is one of those like, Funny, weird like quirks of history that not that impactful, but it is still a thing. [00:30:27]

Like Oracle owns the trademark for JavaScript. Like the reason that the TC39 standards body that determines what JavaScript is technically They are not building JavaScript. They're building ECMAScript, which ECMA is an international standards body. And the reason it's called that is because Oracle owns the trademark on JavaScript. [00:30:47]

And they have done nothing with it. They have not enforced it, as far as I know, in a decade. They have not They haven't done anything with it. So, yeah, the Deno team is asking people to sign a letter. so, I would encourage you to do so. I have signed this letter. I think it's great. I would love for Oracle to be less in the web ecosystem. [00:31:04]

Please. [00:31:05]

Mo: I don't think I knew that Oracle had the trademark for JavaScript until I saw this. I don't know if you did, but it was, uh [00:31:11]

Carl: I did know that. I mean, it's one of those stupid things. Like, it's called JavaScript because they were trying to, like I don't know. Ape on the popularity of Java back in the 90s, even though there's no relation. [00:31:23]

So it's like, I think because I, I think it was something like in those early days, Oracle was like, no, no, no, no, hang on. You can't call it JavaScript. We own Java. And so I think that's how they ended up owning it, but then they didn't do anything in JavaScript or in the web because they're Oracle. And yeah, so it's just one of those like weird quirks of history. [00:31:40]

So this feels like writing a wrong to me in a way that like, yes, please, let's resolve this tech debt, like get out of there. [00:31:46]

WP Engine v Automattic

(https://x.com/justinferriman/status/1838356417482514842)

Carl: And this is a little far afield from React, but there's been some WordPress drama. my, I don't do WordPress. I've never worked as a WordPress developer. So this is a little bit of me catching up on stuff. [00:31:59]

But so my understanding of this is that there's. the WordPress maintainer is Automatic with two T's, and then there's a, another company called WP Engine that seems to, I think they're like a services business, I think, so I guess it's, it's a little bit like If there were two Vercels, like an official one that was actually maintaining Next, and then another one that, like, didn't actually do very much of the maintenance, but also provided all of the same, like, hosting, just with a different set of defaults. [00:32:26]

And if that other actor that did not do all the maintenance work and the development work was making way more money than the people actually building on it. So, that's my understanding of the difference between Automatic and WP Engine. Is that WP Engine makes a lot more money and contributes less. so the CEO of Automatic has gone on a bit of a tear and it seems not great to me. [00:32:48]

They are now accusing WP Engine of like infringing on the trademark of WordPress by way of introducing confusion. Like people think that WP Engine is, you know, WordPress engine and they think that they play a larger role in the ecosystem than they actually do. But they've done so, Automatic has done this by sending a cease and desist that doesn't, I don't know, it seems not great. [00:33:10]

Trademark diff seems targeted

Carl: There's, um, the trademark page, I saw a diff, like, just in the last week, like, as they sent the cease and desist, Automatic updated the trademark information page from saying, you can do whatever you want with the abbreviation WP, to you can do anything you want That doesn't add confusion to the ecosystem, and also WP Engine is not great and we don't like them. [00:33:30]

And so it's just like they specifically called out this organization that they are sending a cease and desist to in updating their trademark guidelines. It's just like, Oh, Oh, okay. I feel like if you wanted to make that argument and you needed to make it 10 years ago when they started. So it's drama, some big drama happening in WordPress right now. [00:33:49]

"You're writing a vite-based SPA. You need to add a few API routes (i.e., for authentication). What do you do?"

Carl: I saw a great. Twitter post from someone who is doing like a sync engines and lots of other like local first type development that I find very interesting. He posed the question, you're writing a Vite based SPA. You need to add a few API routes like for authentication. What do you do? And got a lot of engagement and I thought it was just a really good discussion. [00:34:11]

I wanted to draw a little bit of attention to it just because a lot of great opinions coming out in there. I have recently been playing with. Cloudflare workers. And to me, they hit this really great niche that is perfect for this. Cloudflare workers are basically like serverless architecture. You, you know, set up a handler, and like, you don't do any of the infrastructure administration yourself. [00:34:31]

It just, you know, starts up and stops. But they do it way better than anyone else that I've played with so far. Like, you know, I've used Lambdas and some other similar, you know, serverless architecture things, and all of them have, you know, Awful, terrible, brutally bad developer experience. Like, uh, this is a couple years out of date, so I think it's changed, but I don't think it's changed that much. [00:34:53]

I, I just remember having to upload a zip file into AWS in order to test, in order to deploy changes to a, to a lambda function that I had written. And like, There's no environments, there's no way to say like, this is in test, this is in production, there's no way to test locally. So then like, this entire serverless framework spun up around that to try and make it better, but like, oops, it didn't actually work that way. [00:35:14]

It didn't, it didn't match functionality, so it didn't serve the purpose. So yeah, I think for me this, the answer to what do you do if you need to add a few API routes is set up Wrangler, and then in locally and use Cloudflare Workers. [00:35:28]

Mo: You stole the words from me, basically, which was I would use Cloudflare Workers for a few reasons, like AWS's serverless model means that you're still managing your infra to some degree, like what region do you place your serverless function? [00:35:41]

How does it scale? How does it, you know, uh, how do you do API routing? Maybe you'll need to add another layer, with API gateway in front of it. It's not, like, Straightforward. And so Cloudflare Workers for me was like truly serverless because it's just a function that runs close to the users, somewhere on a CDN, and you get access to run some JavaScript somewhere on the edge, which is really quite cool. [00:36:03]

there's some stuff around, you know, like I think that there's some trade offs, like you can't use Node packages, it's a custom runtime, and you know, if you want to use a specific router, like there is Hono as an example that you can use within Cloudflare Workers to do API routes. Auth is not as straightforward, I'd say. [00:36:19]

So, like, for small tidbits And, you know, tasks that I just need something that runs without me worrying about it, definitely Cloudflare Workers. And so, shameless plug, I did a talk with, a very close friend of mine, Samuel McLeod, who now actually works at Cloudflare and is on the Wrangler team, so he works directly on Workers, and we were talking about how do you Move your front end code to live on the edge in Cloudflare Workers with minimal effort. [00:36:43]

Mo's talk at Future Frontend 2024

Mo: So it's a, it's a, it's a talk that we did in Finland this year. Um, so, I'll share the link. but basically the gist of this was what if you could just take your use states that you have inside of your app and change it to use server state with a different import from a third party library and it would automatically just pop it inside of a durable object on the Cloudflare Worker environment. [00:37:02]

And so there's a lot of cool magic and a lot of cool primitives that they've got that lets you build on top of, and I really like it. If I wanted to build a little bit more full fledged, you mentioned Auth as an example, maybe. I quite like Superbase these days. It's relatively simple. You know, you can run Deno functions within it. [00:37:18]

It also has a database model, which, you know, is managed for you. It's kind of, for mobile devs, I think it's The better Firebase, which, you know, Firebase promised to be the way that you don't have to write back end code for a mobile dev, and then it really wasn't great. and I think Superbase is a little bit nicer, and it's also relational DBs, which I prefer personally, so. [00:37:38]

It kind of just works. [00:37:39]

Carl: Pretty much the major constraint of a serverless runtime is they pretty much have to be stateless because, you know, they start up and they spin it down. So if you want to persist state, you need to maintain some kind of other infrastructure to, you know, some kind of database or something like that, which like, as soon as you start running your own server for a database or something like that, like, well, why not just put the code on there too? [00:38:01]

And Cloudflare workers give you both durable objects. Which are interesting and cool, and I haven't played with them very much, because they also have a key value store that is like this. Dead simple. It works basically like local storage with shared context between invocations of your workers, which just like, if I'm doing something small that I don't want to spend like a week setting up new infrastructure and then don't want to have to maintain that over time, like something that I can just forget about for two years and then come back to and go like, what, how, how the hell does this work? [00:38:33]

Workers. Love it. I guess I should while hyping Cloudflare and workers so much, I should probably mention that they are like basically the only stocks that I individually own that isn't in an ETF, because I like Cloudflare. But yeah, that's, I don't know if I have a conflict of interest, but. [00:38:50]

Mo: That is a vote of confidence, Carl. [00:38:51]

Carl: I'm trying to put my money where my mouth is. Or, you know, now I'm putting my mouth where my money already was. ( both laugh) [00:38:57]

Mo: is this some sort of, like, ramping up stock prices? I don't know. Yes, yes. [00:39:03]

Nitromodules released to the public

Mo: There's just a very quick update on NitroModules, which we talked about last month. And so, uh, NitroModules is this way to run faster native code from React Native. [00:39:12]

And, uh, it's now been released to the public. And so a few people have been playing around with it. William Candillon, who builds React Native Skia and now React Native WebGPU, or WGPU, so to speak, is now using it on his project, and a few other people I know are experimenting with it. So we'll see some cool results, and I think it'll hopefully improve the performance of the React Native ecosystem as a whole. [00:39:31]

NodeJS adds an experimental permission model

Carl: Um, Node. js is taking a cue from Deno and they are adding a permissions model. I think this is super cool. I thought the permissions model is something that Deno got right. I think it's just very interesting to, rather than just allow all the permissions that your process has, being able to signal to the process, what this code is going to need to access. [00:39:56]

Um, I think that's a, I think that's really good and interesting and useful, especially in alternate runtime environments like workers, like serverless environments and things like that. An example where this would be useful. I remember a couple of years ago, uh, someone in Reactiflux set up a little five project allowing anyone to execute code from within the chat. [00:40:15]

Yeah. Um, so you could just, you know, like, use some chat command with a code block. They had set up a bot that would pull that code block in, execute it, and spit out the output. They were able to do that, I believe, because of Deno's permissions model. Because they could guarantee that the code only had access to this very tight sandbox. [00:40:32]

You know, if you're running code from arbitrary people in a chat room, that's very dangerous. So you need an effective permissions model. So, um Now we have that. Now Node. js has that. Uh, maybe not relevant for most people, but especially if you are working on something that would allow, or that would benefit from allowing your users to run code, run arbitrary code, Node. js now supports that better, at least. [00:40:54]

TypeScript with React styleguide

Carl: This isn't new. I don't think I, I have, no, it's undated. I don't know when it came out. but I just crossed my radar and I like it. It's a TypeScript style guide. they have a, they have a react appendix that I, I thought was pretty neat. And just, I love a good style guide. [00:41:09]

Another common question in Reactiflux is like, what are the best practices? Well, there's a lot of practices. Some of them are worse than others. Some of them are good generally in all circumstances. Some of them only make sense in a very narrow range of circumstances. [00:41:23]

So just like, what are the best practices is a very difficult question to answer. And I think this TypeScript style guide does a pretty good job of Outlining a decent range of them. You know, some of them are opinionated, like it talks about project structure and like how to organize your source code and like, okay, there's a lot of ways to do that acceptably. [00:41:40]

but something in the, you know, the first thing it talks about in the React Appendix is like required versus optional props. And. It calls out props as a discriminated type, which is, it's so good. Instead of having a props object with a bunch of optional values, doing it as a group of different, you know, fully formed Types. Uh, so like, you know, the example they give is like a status indicator. Instead of saying like data, you know, error, status as like optional props, just saying like, no, no, the success status has a status value of success, data with this type, whatever. Then the loading status has, says this That's so much better. Like that is absolutely a best practice. So, um, Good resource, I enjoyed it. it had a couple of, maybe it's just because its opinions align with my own opinions, but I thought it was a really good resource. Definitely recommend it. And also, more generally, on the subject of style guides, I think a style guide is a wonderful resource to bring into your company. [00:42:44]

Uh, the most effective teams I've been on have had a style guide document that was routinely updated. Just, uh, if. I think it's a really great anchor point for technical discussions. Like, if you have a technical argument with your team about, like, we should not be doing this, this is bad. Argument should have an output in the form of a PR to a style guide. I think that's really great. [00:43:05]

Inside ECMAScript: JavaScript Standard Gets an Extra Stage

Carl: Not new news, but a good resource. We've talked briefly in previous months about the TC39 ECMAScript standardization process. You know, there's four stages, you can present an idea in stage one, then if you do X technical work, it gets to stage two. Stage three is like, basically standardized, but it's not shipped yet, and stage four is like, fully shipped. [00:43:27]

There has been a problem over many years of a lot of things getting stuck at stage two. The transition between Stage 2 to Stage 3, and then like, oh, we found a new problem in Stage 3, so we gotta ship it back to Stage 2. Just like, the delta between Stage 2 and Stage 3 has turned out to be very, very large, in a way that has made it difficult to ship some of these proposals. [00:43:50]

Just like, If it gets shipped back down to stage 2, that has some problems. So this article from The New Stack just did a really good job of explaining more of that history than the half assed summary that I just gave, and talks about the stage 2. 7, you know, sub stage that they added relatively recently. [00:44:09]

It sounds like the gist of it is that if you've written tests for your thing, then getting bumped back all the way back down to stage two, like, calls into question the validity of those tests. And stage 2. 7 resolves that problem to make it a little bit clearer about what that means. If you're curious about, you know, if there's like, if there's a, proposal that you've been following and are curious about the standardization process. [00:44:30]

Um, I just think this is a pretty solid resource explaining the history. [00:44:34]

Remix The Web from mjackson

Carl: cool. I came across a fun project from Michael Jackson, from the Remix team called Remix the Web. Michael Jackson, Ryan Florence have been so involved in the web React, in the React ecosystem for so long. I have always. I've respected them greatly as people who, like, they don't just try to solve a problem. [00:44:55]

They try to solve a problem in a way that makes sense, given the primitives available on the web. So it's not just trying to do everything in JavaScript. Like a lot, a lot of Java, a lot of React libraries I've seen, they end up, re solving a lot of problems in JavaScript that you might not need to if you just leaned on the web platform a little bit harder. [00:45:14]

And some of that is because of aspirational support for React Native. If you solve it in JavaScript, then it can work not on the web platform. So like, there's trade offs to doing that. The trade off is that If you write in JavaScript, like, it's probably going to be slower. It's probably going to be worse in some way than if you can use a native, you know, web platform feature. [00:45:34]

That is the backstory for why I'm particularly interested in this. So, Michael Jackson is putting together a monorepo of modules that are narrowly scoped to do one thing and do that thing well. An example of this that I remember him talking about Years and years ago, in the context of React Router, is they built React Router on top of a primitive, on top of a wrapper they made around the history API. [00:45:59]

So it's like, in trying to make a router, they found all of these weird, nasty edge cases around managing history, managing scrolls position, things like that, and found the platform feature to be highly deficient. as a, you know, mode of interacting with that. And so they made a wrapper abstraction around that to make it easier to deal with. [00:46:19]

And so my understanding is that this Remix the web monorepo project is a bunch of those. So like in, if they find, A rough and grody, web platform feature, they write a wrapper around it, and into this repo it goes. So, uh, I'm interested, it seems curious, it seems pretty cool to me, I have certainly found a lot of platform features that don't do quite what I want, so, uh, I'm, yeah, I'm paying attention to it. [00:46:41]

Seems cool. [00:46:42]

Replacing React code with CSS :has selector

Carl: And somewhat related to the idea of solving things with JavaScript, I saw a good blog post titled, Replacing React code with CSS colon has selector. The gist of it is, I'll pull a quote. Until recently, we couldn't select objects in the opposite direction of the CSS cascade. You know, CSS is top down. [00:47:06]

You can get, you can start from the top and it gets more specific. So you can say, in all of these elements that are under this type of parent, style it this way. But you can't, you couldn't say previously, in this parent, if it has this type of element within it, style it this way. It was a, it was sort of a, you know, unidirectional control flow in that way. You could style descendants based on their parents, but you couldn't style parents based on their descendants. And the CSS Has Selector enables you to do that, which I have run into so many situations where I wanted to do that, and you just can't. You just couldn't. So, uh, you end up having to solve it with JavaScript to like add a little bit of state to communicate whether some element is within it. [00:47:51]

And yeah, so the CSS has selected something I've been wanting for a really long time, and I really appreciated that. I'm seeing it framed as, here's all the things you can stop doing with React because of this CSS feature. And yeah, it's written by Nadia Makarevic. I hope I'm not mispronouncing that. She also wrote a great book on React as well. Yeah, just really, I really enjoy her writing. She seems like a great writer and seems to pick good topics. I like it. [00:48:19]

Performance Optimization Strategies for Large-Scale React Applications

Carl: And last lightning round link, just going to call out a Reddit thread. I've started, I set up a thing to pull in top posts from Reddit into the tech reads and news channel, and it's served us some good stuff. [00:48:31]

I like it. But yeah, somebody asked the question, somebody asked about. Performance optimization strategies for large scale React applications and it got a decent amount of response. So I just thought that was a good, I just wanted to call attention to a cool thread full of a lot of opinions. It seemed like a good thing. [00:48:47]

I didn't really see anything that like massively caught my eye as like, this is the right thing to do. But it did get quite a few Lengthy explanations of how some person or another has done performance optimizations at work. Uh, and that was always a big part of my work. My career has always, I've put a lot of emphasis on performance optimizations. [00:49:08]

Wanted to call that out. Go read it. It's good. [00:49:10]

Outro

Carl: Cool. Alright, that's everything we got. thank you for joining us. We will be back on the last Wednesday of October here in the live stage or back in your podcast feed just as soon as we can, if that's how you listened. We gather sources from This Week in React, Bytes. [00:49:23]

dev, React Status, Next. js Weekly. The React js subreddit here in Reactiflux and direct from those publishing articles. usually on Twitter, maybe on blue sky, maybe on RSS feed. Lots of things. If you see anything newsworthy, uh, definitely let us know in the tech News and reads channel of Reactiflux. [00:49:39]

Or send it directly to me hello@reactiflux.com, uh, with TMIR in the subject line. It's an acronym for the show. I read literally every email that comes in, even the spam. So yeah, if you've got a hot tip, send it to me and I'll read it. if this is a show that you get value from and want to support, best way to do so is by submitting a review on Spotify, which helps us, Rank? [00:50:01]

I'd say stay in the rankings, but like, we don't rank, so, you know. Or, you know, post it on Twitter, send it to your co workers, stuff like that. Appreciate it. Thanks for listening. [00:50:08]

Mo: Always fun to do this every single month. Thanks, for having me, and hopefully I'll see you all at some point in person, somewhere, maybe at the, uh, RNLConf. [00:50:15]

Till next month.