TMiR 2025-03: Next had an auth vulnerability, TypeScript is porting to Golang

Transcript from Thursday March 27th, 2025

Carl: Thank you everyone for joining us for the March edition of this month in React, where we recap and digest the recent developments in the ever evolving react and web ecosystem. We are coming to you live here in Reactiflux, the place for professional react developers. [00:00:14]

And we are supported by infinite red, but more on them later. I am Carl. I'm a staff product developer and freelance community leader here in Reactiflux, where I run community programs like these events and build tools to help keep the community operating. [00:00:28]

Mark: Hi, I'm Mark. My day job is working at Replay io, where we're building a time traveling debugger for JavaScript, and also trying to find ways to make AI developers smarter by giving them access to replay runtime data and in my copious amounts of spare time. Outside of that, I do redux stuff. [00:00:45]

Job market: FRED data, Layoffs.fyi

Carl: Some early quick hits. My general temperature check on the job market is that it's not good. It seems bad. Layoffs for March are higher than they were in every month, except last month since September, 2024. So that's five months, yeah, that's not great. It seems like hiring is down. Oh yeah. Look at that. The Fred economic data is a continued decline, so that's not ideal. I guess that is software development, job posting, so I wonder if maybe there's like some kind of title shift leading to that decline as well. [00:01:20]

But yeah, job market not good. So yeah, if you are on the market, I hope you are. I don't know. Good luck. Sorry. [00:01:28]

Conferences (React, Javascript)

Carl: Upcoming conferences. [00:01:29]

React Native Connection April 3 + 4, 2025 Paris, France

Carl: There is React Native Connection April 3rd and fourth in Paris. So if you're in France, definitely check that out. [00:01:36]

React Miami, Apr 17-18

Carl: React Miami. A beloved conference that I have attended several times but will not be at this year. [00:01:41]

Is April 17th and 18th in Miami, Florida. [00:01:45]

Mark: I'll be hanging out there. [00:01:47]

Carl: now go see Mark. He'll say, Hey . [00:01:49]

CityJS London April 23-25 London, UK

Carl: There's City Js London on April 23rd through 25th in London, the uk. [00:01:55]

App.js Conf May 28-30 Kraków, Poland

Carl: We've also got App JS Conf May 28th through 30th in Cacao Poland. I've heard good things. I looked at going, but it's just can't swing it. Too big of a trip. [00:02:06]

CityJS Athens May 27-31 Athens, Greece

Carl: CDJS Athens is also gonna be May 27th through 31st in Athens, Greece. [00:02:13]

SquiggleConf 2025 CFP closes May 23

Carl: And I'm helping organize squiggle conf, which is coming up much later this year. But their CFP is open, so if you are interested in speaking go ahead. Submit. It's gonna be open until May 23rd. [00:02:26]

Mark: I, I got to attend Squiggle Con last year. I, I also know the organizers, Dmitri and Josh, they're wonderful people. They did a fantastic job for a first year conference last year. Squiggle Conf was great. You should totally try to go. It's in, it's in Boston. [00:02:40]

Carl: It is in Boston. Yeah. Dmitri, his most recent accomplishment that made pretty big waves is he got doom running in TypeScript types, which is bananas, and took like a year and a half and he had to learn all sorts of like compiler and like processor stuff. Yeah. Unbelievable. [00:02:56]

Mark: we should totally toss a link to that in here on general principal. [00:02:59]

Carl: Yeah, we probably should. I don't have one handy. But yeah, super cool. Super impressive. Unbelievable maniacal in fact. But yeah. [00:03:06]

Yeah, our sponsor you know, bear with us through all of our setup stuff before we get to the real news. We, there's so much news. We've got like a pretty major security vulnerability in next. [00:03:17]

There's like a couple of new releases to talk about, but yeah. [00:03:19]

Carl: We are sponsored by Infinite Red. They are an expert react native consultancy that's been around since 2015. And I actually just saw a post that they put up on LinkedIn where in 2015 they hired 21 people and 14 of those 21 are still there, like 10 year tenure for two thirds of the organization. Like that's impressive. [00:03:38]

I've been laid off and fired a lot and I appreciate a company that is willing to get let its people stick around. Yeah. They're currently our only sponsor, in part because so few companies do as much as they do for the ecosystem. They host the largest React native podcast. They host the largest US-based React Native conference. Yeah, lots, tons of React native stuff. They very meaningful ecosystem investment. [00:04:04]

They only do React native and have built over 75 apps for companies from startups to the biggest in the world. And they will work with your team in order to help you develop expertise, not just get code running and dip out. [00:04:16]

So, yeah. if your company is looking to start a new React native project, definitely check them out. They are at Infinite Red, [00:04:24]

New releases

Carl: into some new releases. [00:04:26]

TypeScript 5.8

Mark: last month we mentioned the TS 5.8 beta, and so now it's come out as final. The biggest thing here is probably the erasable syntax only flag, which ensures that you're only using TS types that can just be stripped away without having to go through with transation step useful for use with node, for example. [00:04:45]

Carl: Yep, super great. I'm already using something like that in code that I run. It's just nice. I don't know it's nice to not do like a full compilation step. It just lets me cut an entire thing an an entire build tool out of my, outta my local development, which I like. [00:05:00]

Typescript Release with Go

Mark: Although on that note, and we'll talk about this more later the TS team has announced that they have finally rewritten the TypeScript compiler itself in another language go instead of TypeScript still in an early preview stage, but they're seeing 10 x speed up and compilation time. And so the trend of converting JS build tools into other languages continues, and we'll, we'll talk about this more in depth later. [00:05:26]

Carl: Probably, we'll talk about it later and we'll then probably continue talking about it later and later and later, because they have said that this is really gonna ship in like TypeScript seven, which by current release cadence [00:05:40]

Mark: Is like two years from now. [00:05:42]

Carl: Yeah. [00:05:42]

two and a half, three years. So yeah, we, this is gonna be a topic for a very long time. [00:05:47]

But yeah, they are continuing the trend of rewriting build tools in native and they are disrupting the trend of rewriting JavaScript build tools. rest. Yep. [00:05:55]

But yeah apparently they chose Go not Rust because the like general ethos, you know, the, the way you write code in Go is more similar than Rust. So they can do like more similar patterns in the code they're offering. So it's more of a one-to-one rewrite rather than like different enough code that it would have different semantics and different, you know, challenges there. [00:06:19]

Mark: And we have a mo. [00:06:20]

Carl: Ammo welcome. That's okay. We're gonna throw you immediately into the hot seat with React Native 78. [00:06:26]

React Native 0.78 - React 19 and more

Mo: So React native 78 is out. Bunch of small things, but we're getting smaller releases and so this one is mainly focusing on React 19 support. So you can get all the React 19 features that you know and love on the web now working on Native World. And we finally get our logs back in Metro. [00:06:44]

Next 15.2

Carl: Cool. Yeah, There's next. 15.2, which, you know, we're gonna talk a lot about next and more later. But um, this looks like not too crazy. A release they redesigned error ui, more streaming metadata, performance improvements, yada yada. Some experimental features as well. [00:07:02]

And ooh, experimental node js middleware. A lot more on middleware later. [00:07:07]

Tanstack Form 1.0

Mark: Tan Stack Form is a brand new form library in the vein of libraries like formic and React Hook form. This one I, I believe, was started by Tanner Winsley himself. The current maintainer is Corbin Crutchley who'd worked on a previous library, I think, called House Form, I believe. But like some of the big selling points are things like type safety, you know, being able to infer that, you know, like when you pass in the name of a field as an argument that all the other callbacks and everything else know exactly what the, you know, the proper value type for that field is. [00:07:41]

Lotted, different validation options a lot. And working with SSR and other scenarios haven't used it, but it looks fairly comprehensive and worth taking a look at as a, you know, form solution for your apps. [00:07:54]

Zeego v3

Mo: Yeah, so Zeego is a library that I quite appreciate. So it's made by Fernando Roho, who very recently actually joined Vercel as their head of mobile, which is going to, which tells us a lot about the direction that Vercel is going in terms of some of their mobile offerings. But Zeego released a new sort of major release. [00:08:13]

And so the, the big points with this is and just just for a little bit of context, we have talked about Zeego before in the podcast, but just for anyone who might have missed it, Zeego is a library that allows you to create context menus that are native to each platform and it's universal. So what that means is that it will let you create context menus on the web and it defers that to something like rad. [00:08:34]

Then on native platforms like iOS and Android, you actually get the native context menus that you get on the platform. So those are native elements that are rendered. And it's, it's a really good example of using the same API but getting very different looks and feels that are native to each platform. [00:08:49]

So it's, it's, it's a, it's a cool library. It's a very nice like utility library that you might need to use when you wanna get some native functionality inside of your mobile app. But the major things with this is just supporting the new architecture and React native and working with some of the new versions of Expo. [00:09:04]

Material UI v7

"Slot pattern" for overriding internals

Carl: Yeah. Material UI has version seven out. Main thing that caught my eye here is they have a slot pattern for overriding the internals of their different, you know, components. Customizing component library components is like the number one reason why I have not extensively used component libraries in my career. [00:09:25]

I just, like every company I've worked for, they have wanted a greater level of customization than is achievable just by doing things with the component library. I've been very interested in Chad CN for that reason, because it's just like, it's a co generator, not a library. [00:09:40]

You use it to make components and then you customize those components to your needs. But this looks like a really interesting alternative pattern for it. Basically, it looks like they have a pair of props slots and slot props where a component will specify different slots that you can override. [00:09:59]

So you can give it different components to put into places where, you know, like in, in a tab or a dropdown or whatever. That's really interesting. That seems good. Generally, it's nice that they are like trying to standardize it a little bit and like have a specification. I appreciate that and it's, yeah. [00:10:20]

I've seen a lot of libraries do things like add in. Sort of slots. They don't call it that, but like they let you pass in a component that it will use in place of something else or whatever. But I've always seen that as very like ad hoc and like there's no standardization or structure around it. [00:10:37]

So seeing this as a pattern is interesting to me. It's definitely, definitely interesting. Yeah. That's all I gotta say. [00:10:45]

Parcel v2.14

Mark: The Parcel Bundler released version two point 14, and this is kind of a big deal because it actually adds built-in React server component support. I was actually just looking at the download stats. So parcel has been around for several years. The primary author, Devin Govet, also works on React Aria and React Spectrum and a couple other component libraries. [00:11:05]

He's put a ton of effort into building it, but it's, it's very much an also ran in terms of actual usage. Like last month, Webpac had 116 million downloads. V had 85 million downloads. Parcel only had 800,000, so non-zero, but obviously not like, you know, anywhere near the level of the other tools. [00:11:25]

That said it is a, an actual tool in the space and so it is interesting to see what's more of a bundler rather than a framework. Adding React server component support and looking at the examples the usage pattern here looks to be a whole lot simpler than what Next has and, and has put together, you know, next is the, the defacto standard implementation of React Server components at this point. [00:11:52]

And so I think a lot of us have tended to assume that the way server components work in NEXT is the way that they work, whereas it, it's really more like React exposes the primitives and it's up to the framework or bundler to decide how they get used. So in this case, apparently parcel actually supports using server components, like just within a, like a, like a basic express request handler, which actually looks a lot simpler conceptually. [00:12:20]

So parcel may not have a lot of actual real world usage, but this looks like a, a, a nice example of what can be done with server component support. [00:12:32]

Carl: That's cool. Oh, nice. [00:12:33]

XState Store v3

Mark: Meanwhile, the, the X State and people, AKA, mostly David Khourshid has released X State Store. Version three. X State Store is meant to be a, a much wider weight state management tool. Kind of more along the lines of a, of a zoo stand, but with a little bit more of a, a state machine twist on it. So there, there's some updates to make the usage and the developer experience a little nicer. [00:13:00]

Carl: Yeah. Love X State. I don't know, I've just always had an affinity for it. They had a, they've always had a great state machine design tool and I found that useful even while not using the library. So I dunno, I just like them. [00:13:11]

Better Auth v1.2

Carl: There's Better Auth version 1.2, which is interesting and cool. I have been following Better Off for a while. I haven't actually used it myself yet. But they've been, [00:13:21]

Mark: Theme of this podcast? [00:13:23]

Carl: yeah, a little bit. There's just so many things. It's hard to stay, it's hard to, staying on top of it is hard to know. Actually using all of it as well is uh, impossible. [00:13:31]

Yeah, I, I, I like the general vibe of it. [00:13:34]

I have been let down by literally every auth tool that I've ever used. I have written my own auth far too many times because I'm so irritated with trying to use all of the authentications libraries. And yeah, this seems good. I'm just gonna read what bytes.dev said, 'cause they summed it up very well. [00:13:51]

"It's got Stripe subscriptions, recapture API, keys teams and sub orgs and a new init CLI, and they rewrote the core library to fix TypeScript editor lags. So like, it just seems really good. They've really been on a tear with shipping improvements. Like I, I subscribed to GitHub notifications for them and I slightly regret it because I swear to God I got like five a week with just like beta releases and new minor releases. [00:14:18]

So it's, it's, I'm impressed at their pace of development. They seem to be doing a really good job of shipping pretty major upgrades as they go. So, if you're doing a greenfield project that needs authentication, consider it. [00:14:31]

Main Content

Carl: Mo can you tell us about Lynx? [00:14:33]

Lynx released

Release blog

Mo: SO this is, this is not specifically React native related, but it's React native adjacent and definitely react related. So, you may have heard that bite Dance, the team behind TikTok released links, and links is effectively sort of a competitor to React Native. They've created another way that to build native applications using JavaScript tooling and using React as the way that you define UIs, which is really cool. [00:15:01]

And so, the, the real sort of reason why why this is exciting is because this is actually what's powering TikTok behind the scenes. So this is what they're using internally for TikTok. And you know, TikTok is as large scale of an application as comes. And so it's actually quite a. Quite a big deal to have something like this release and it brings healthy competition to the space of sort of cross-platform native applications where it's been traditionally just rack native and flutter. [00:15:27]

So I think there's some really interesting stuff here. The TLDR is that they have a sort of multi-threaded a multi-threaded architecture in place. And that's one of the things that they really, really empathize, em, emphasize on. And so the whole idea is that this architecture and this multi-threaded runtime allows you to take priority on sort of synchronous UI tasks that are high priority so that the app feels snappy and responsive. [00:15:52]

And things like event handlings are done sort of with a high priority. This is getting quite similar to the space of sort of what the React native team is trying to achieve with the new architecture, which was trying to. Targets similar benefits. And so they, they give a lot of examples on things like instant first frame rendering, which is one of the metrics that they're trying to target with this architecture to make sure that the first time you open up your app, you get as quick to instant as possible launches. [00:16:18]

And sort of multi-threaded scripts for when there's a you know, important scrolling event or something that requires really good responsiveness. Having those sort of concepts embedded into the architecture, which is really, really quite cool. And one of the nice things about this is that their JavaScript layer functionality is not actually react specific. [00:16:36]

So in theory, down the line, albeit React is really the only main way that you can define UIs right now down the line, they may create other versions of it. So currently there's links, which is the core, and then there's React links as well, which is the sort of the React library that you can use to define UIs for links currently. [00:16:54]

There could be in the future initiatives where it can allow you to use other UI libraries to do this, which can be really quite cool. [00:16:59]

Mark: I think I saw even at least a mention or like someone at least asking like, when can you use Vue with this? And it sounded like that was a thing that they were trying to work on. [00:17:07]

Carl: Interesting. [00:17:08]

Mo: but you know, that in itself is quite powerful because, you know, one of the, you know, there is nothing like rack native or there wasn't anything like rack native where you could use web-based UI libraries to define a mobile app. And so this actually opens up the door for people to use view to make actual native apps rather than sort of PWAs or hybrid web view based apps that are not gonna be good experiences. [00:17:31]

So, quite exciting stuff. [00:17:33]

Carl: That is really interesting. And it, it's, it's funny that I feel like over the last year we've talked about a couple of projects that we're exploring different ways of authoring react and getting some form of mobile app out of it. And I'm surprised that there's still like new approaches. This, we've seen so many with like, I don't know, react native web and I'm forgetting the names of all of them, but I swear to God [00:17:55]

Four of React strict dom. [00:17:56]

Yep. So, okay. Interesting. That sounds really cool. And I like that there's a way, I don't know, just like it, I love the web. I secretly wish that Web os from like 2012 had been a viable option. So it's just, I'm, I'm, I love seeing the web expand more meaningfully into the native arena. That's really cool. [00:18:17]

Cool. Alright. Into the headline. [00:18:20]

Security vulneratibility in Next.js: CVE-2025-29927[00:18:20] Original researcher report

Mark: All right. The biggest news story of the month occurred just a few days ago, and that was that there was a major security vulnerability with next's middleware implementation that ultimately allowed any external attacker to send a fairly simple set of headers and force next to skip the middleware. [00:18:46]

And if you, your app used the middleware to provide authentication to. You could actually just bypass the entire authentication process. So the assumption here is if you're using next to do middleware, and then there's some other caveats around where your app's actually hosted. But ultimately this was rated as an extremely high concern security vulnerability. [00:19:11]

So Next has released actual, actual fixes across a couple different major versions to try to patch up the issue. There's been. You know, breakdowns of, you know, what the actual bug is and why this is a concern and how it works. And then there's been a lot of fallout from this issue in terms of how did Vercel handle communicating the vulnerability to the general public as well as other partners. [00:19:38]

And follow on questions like, you know, how does Vercel and next actually kind of handle their development processes? associated pieces to go through with this. So let's, let's try and break some of this stuff down. [00:19:49]

Carl: Let's see what we can do. Yeah. So you, you mentioned how many versions that they shipped. So they, in, in their, you know, blog post, it's very. I don't know, no details, no extra explaining what happened. They explaining the advisory, I guess they, they then put out a, like timeline of the thing and gave a lot more details. [00:20:09]

But so they released patches for version 12, 13, 14, and 15, which means that this has been a vulnerability since at least 2021, which is wild [00:20:19]

Mark: It sounds sounds like Al, almost exactly, almost since like the, the middleware feature probably came into existence. [00:20:26]

Carl: Which I guess that makes sense. Like you add a new feature and it has vulnerabilities and until somebody notices it, you don't fix it. But wow, four years for an auth bypass based on a header. [00:20:36]

CVEs and the NVD Process

Carl: So I want to lead in a little bit breaking down like the CVE process, which I am not sure. I feel like everyone, I feel like a lot of people will have a general, I. [00:20:47]

Awareness of what, of what A CVE is. I didn't quite realize that it was like an NIST national Institute of Standards and Technology Program. Like this is a government program established in 1999 to track, [00:21:02]

Mark: known security bugs. [00:21:04]

Carl: Right. So like, yeah, and it has a, there's a calculator that lets you figure out the severity of a vulnerability. [00:21:12]

And it has criteria like the attack vector, the attack complexity, the requirements of the attack privileges required, user interaction are required, and then the impact of the vulnerability. It's confidentiality, integrity, availability. It's basically like how do you do the attack and if you execute the attack, what are the impact, what are the effects of it? [00:21:35]

So this. You know, the scoring criteria for this vulnerability is it's a network attack vector, which means you don't need to be physically present which is bad if you can do it over the network that's like a high level of access. The attack complexity is low, the privileges required are none. [00:21:54]

The user interaction required is none. And the impacts confidentiality are high, integrity is high but no impact on availability. So you can, you know, get into confidential spaces and, you know, violate the integrity of the data. [00:22:09]

You so it, it's, it's basically an attack you can do from anywhere in the world that's very simple. That gets you a high level of access, which is why this is a, you know, critical severity bug. That's so bad. Oh my God. Just for a, a bug of that severity to exist for four years before anyone noticed is oof rough. [00:22:30]

Mark: The general concept here is that, you know, middleware can be chained together. But there's, there's internal implementation details around like possibly needing to rerun middleware or possibly needing to skip middleware. [00:22:43]

And so at some point Versel opted to implement skipping, running middleware by looking for a specific header that they could attach to the request. And the intent was that this would only be an internal thing, that the header would only ever get added by next itself in response to, some piece of code saying, Hey, we're, we're good. [00:23:09]

We can just keep going. Or I guess maybe to, to, to get rid of loops in the middleware chain. And someone figured out that. You know, wait a minute, I could, I could attach this kind of a header as part of an external request. And the piece of information that next was looking for the, in the header is just a name of the middleware itself, which is pretty much always based on the file you would've added in your next project, which is apparently in some cases like just the literal word middleware. [00:23:44]

And so you could end up like having a header value of middleware, colon, middleware, colon, middleware, colon or something like that. the end result is that someone could send a request to a next base server, add this header to their original external request, and end up convincing next, skip all the middleware and never run them. [00:24:07]

And. And so if some of the were trained to do authentication, then the request would end up just skipping that entire process. I believe Vercel said that the way they have their systems architecture set up it was not really possible to have that be a problem on if your app was hosted on Vercel infrastructure. But then there was questions of, okay, well what if you're running on Netlify or CloudFlare or using one of the Open Next adapters? So the bug exists in next, and then there's the question of, well, how is next being hosted and what requests could actually get through? [00:24:46]

Carl: Right, so. I think what I saw is that they're saying if you hosted on Vercel, you were never vulnerable to this because of how we set up our system, which is great. I guess this. Certainly fuel on the fire of like Vercel is privileging itself in the ecosystem. [00:25:03]

Postmortem on Next.js Middleware bypass

Carl: And I guess building on that a bit, so they put out, you know, their postmortem breaking it down and breaking down the response. [00:25:11]

Mark: Which, which came out about like, like two to three days after the actual announcements. [00:25:16]

Carl: Right. And it looks like, you know, in the timeline they talk about like receiving emails and like multiple reports, which delayed the triaging. But like, you know, the core of the timeline, I. [00:25:27]

Mark: A month or something. [00:25:28]

Carl: it looks like somebody reported this at the end of February on the 27th, and then it didn't get triaged until two weeks later, which seems not good. [00:25:38]

I don't know. I, I, I have done triaging of security vulnerabilities. I was the point person for that at my last job for like two years, a year and a half, something like that. And there's a lot of noise. There's a lot of garbage that comes in. There's a lot of, you know, quote unquote security researchers who are just like running automated tools like nmp. [00:25:58]

You know, it's like, you know, you are an NPM audit and it's like 63 critical violations and like, none of them actually matter at all. So like, there is a lot of noise and I can understand how triaging might get delayed, but you know, like even just reading the headline, you know, if somebody submits like authorization bypass, like that would wake me up. [00:26:17]

So, I don't know, just waiting for two week lag time on that is not ideal. [00:26:22]

Mark: One, I mean, one, one bit of that is, it sounds like the initial submission just said, this looks like it's a problem in next, in, next next 12, which was out of date. And so like it sounded like someone may have glanced at it and said, oh, we don't even support next 12 anymore. It's not a big deal. [00:26:38]

And then the researcher came back and said, actually, it's a problem in like every version of next. And that finally got someone to wake up. [00:26:46]

Carl: for sure right? So, like, okay. Devil's in the details on this as always, but yeah, it's not a great situation. And what's more is that, it sounds like they did no coordinated disclosure. [00:27:00]

Next.js and Coordinated Disclosure

Carl: This person talks about some other CVE environments or disclosures that they've either, you know, been a part of seen and for instance, you know, like heart bleed, some of those other like large scale mass impact vulnerabilities, like this is not obviously of that scale, but it is large. [00:27:21]

So the, the, those ones like heart bleed, they had like multiple months of coordinated disclosure where behind the scenes in secret. You know, once these vulnerabilities are known, the companies are coordinating with each other to say like, are you vulnerable? Yes. Here's how we fix that. Are you? Yes. Okay, let's fix that too. [00:27:40]

And. What they're claiming is that Net or Vercel did nothing like that. They received a report, they validated it, they pushed their own fixes, and then they went public with it and basically caught other platforms like Netlify, cloud Flare, et cetera, with their pants down. And it was just like, oh shit. [00:28:02]

You what? What? We're vulnerable. And so now everyone's scrambling. And it's been publicly, it is, it's been publicized. So like now many websites are vulnerable, it's public knowledge and the a patch isn't ready. So like, that's, that's just not nice. it's not collaborative at all for sure. [00:28:22]

So it, it just means that like, it became a race to fix this before it got exploited in the wild. That's definitely not ideal that like that's, I guess I can understand how a company might say like, this is a problem with our product. We are fixing it. We have fixed it. It is time to go public. I guess I can understand that thought process, but man, as far as like being a participant in a broader ecosystem, that's a big blind spot. [00:28:49]

Mark: yeah. The, that, that link about coordinated disclosure is really good. It, it breaks down what did happen at what times, and then talks about like what are, what are the proper practices for handling a security disclosure? What did, like, what actually happened instead? How did this, like, how did other people end up finding out about it? [00:29:09]

And then like, what, what would have been a proper sequence of results? Instead, I. So like ultimately, you know, things have sort of been handled here, but really, really badly along the way. [00:29:24]

Carl: Yeah, and I guess one more detail that I'll highlight as part of like, this response was not handled well and maybe went through the wrong channels, the wrong internal channels. when they announced the vulnerability, I. One of their claims as part of it, which is accurate as best I can tell, is that you as our customers of Vercel, were not vulnerable because you were protected by our firewall. [00:29:47]

So it's like, it feels like it went through the marketing department rather than like, I don't know, engineering, security, whatever, where they were making an honest claim about a differentiating factor. But like part of the differentiating is that they were not collaborating with anyone else to help protect end users. [00:30:08]

So it's like, yeah, sure that's true, but it's also kind of mean that you did that. So, I don't know. It's not ideal. Not great. [00:30:17]

You should know this before choosing Next.js

Mark: And then one other good blog post related to this somebody who works at Netlify and has spent a lot of their engineering time trained to reverse engineer some of the somewhat more proprietary features of Next to make sure that they work on Netlify. Wrote a very long blog post that. Digs into both, you know, some of the, some of the vulnerability aspects, but then also just general concerns about the way next is developed and deployed and, you know, does not necessarily work with the ecosystem as well as it ought to. [00:30:54]

Describing a lot, a lot of the concerns, you know, that there, that there aren't, official adapters to run on other platforms that it doesn't have serverless support, that there's certain code paths that really only work on versal. And then also kind of talking about, you know, some of the security aspects. [00:31:11]

It's not like, it's not a, it's not a flat out indictment, but it's a, it's a very fairly written post from, you know, someone who acknowledges, you know, the own biases upfront, but like, it's a, it's a very valid set of concerns from someone who deals with next, from an external ecosystem perspective. [00:31:29]

Carl: Sure. [00:31:30]

Yeah. Not a great situation overall, but it's out, it's fixed. That's good. Onto the next [00:31:35]

um, okay. [00:31:37]

React Native 0.78 - React 19 and more

Mo: We are back with another release of React Native. And so this one is is focused again, we're, we're going through faster releases now. So you might've noticed if you've been staying tuned for a little while that our release cadence within the React native ecosystem is becoming shorter and shorter, which is great news because it means we get updates quicker. [00:31:58]

And that's largely due to the new architecture being out now. And so that allows us to basically the, the core of React native is a lot more stable. And so there is there's, there's more of a foundation to release a lot faster, which is great. Other highlights for this release is React 19 is now available on React Native, which is great. [00:32:17]

So if you, you know, followed along with the previous React 18 implementation for React Native, you will have been aware that it took years to get it up to date with all of the React 18 features, largely because of the new architecture not being out fully. And so now you can see there's much of a smaller lead time to get React 19 support. [00:32:38]

So all of the new sort of features of React, things like actions use, optimistic, the use hook, all of that stuff, and, you know, not needing to use forward ref anymore. All of that stuff is there now. On top of that the React compiler support is is now there. So you can actually install the compiler, configure it, and it should be able to work just as you would on the web, which is awesome. [00:32:59]

The, probably the most, important feature for the community though is that they've brought back JavaScript logs in your metro bundler. So this was one of the things that the react native team did last release was they removed logs being shown in your JavaScript bundler. So they were trying to push people to use the react dev tools that they released, or the new dev tools that they released for the React native ecosystem only to face the most crazy amount of backlash from the community because their logs had moved. [00:33:27]

And people were very unhappy about that. So, they rolled back that. you can pass on a flag now and basically get the logs showing in your bundler once again, like it was for the last. However many years React native has been out for. And so they have said that they will eventually remove this again. [00:33:43]

But they're trying to give a little bit more time for people to adjust to using the new dev tools. So we'll see how that goes when that happens. Once again, there's some other minor changes, but those are really the big things that's worth mentioning. And I think we're gonna get a lot more React native releases happening a lot more regularly since the new architecture is up. [00:34:00]

Mark: Sounds like a pretty substantial set of changes. [00:34:02]

Carl: And it's cool that they are able to release more quickly, to keep better aligned with the, you know, main mainline react version. I hadn't really registered that as a benefit that would come out of the new architecture, but it makes sense, especially while they are effectively maintaining two versions, you know, new architecture, old architecture, suddenly only have to do the new architecture. [00:34:25]

That makes a lot of sense. That's super cool. [00:34:27]

React Native Core Contributor Summit 2024 Recap

Mo: So the, the next thing that I, I thought I'd just drop in here. it was technically published in February, but I think we missed it and I, I wasn't around in February is the React Native Core contributor Summit for 2024. The recap was finally released. So this is an article on the rec native dev blog. [00:34:43]

I actually co-authored this. So last year in SLA in in Poland, I think it was around September we had the React Native Core Contributor Summit, which is a, a full day workshop. Talking about a bunch of different. Things that are strategic to React native in general. And one of the things we talked about was the release process. [00:35:02]

We talked about, you know, what's the next big thing after the new architecture. So there was a bunch of different sessions and we split off. There was a session about how do we bring web APIs into, into to, to the React native world to standardize some of the APIs for interacting with the native layer. [00:35:15]

So a lot of really interesting stuff. We talked about Nitro modules, which is sort of, we've talked about several times in the last few sort of podcast episodes outta tree platforms and react native on desktop. I held a session as well, so I led a session during this during this core contributor summit lean Core 2.0. [00:35:31]

So just for a bit of context lean core, was an initiative in the React native ecosystem back in 2019. And so the goal of Lean Core was to bring down the surface area of React Native's, core APIs because there was just so much stuff in there. Like somebody needed access to something in IOS's specific APIs and they just create a component and pop it into React Native Core and that would just be a part of maintenance burden for the core React native team. [00:35:56]

So there wasn't much strategic direction around what goes into core and what goes into sort of community packages. And so they went through this effort in 2019. But the goal of the session this time around was actually, I think we we're due for another cleanup. 'cause there's a lot of random stuff there that is either props in certain core components that are tying specifically to Android or iOS, or there's just some components that don't get used anymore because there's much better components in community libraries that you can use. [00:36:23]

And most people end up using those. So it was a good conversation around what should be deprecated in the long run. And so that's one of the sessions that I think was quite fruitful. And I say that probably being quite biased because I was the person who hosted the session. But yeah, that's a, that's a summary about the uh, the React Native core contributor Summit from last year. [00:36:39]

If you're interested please feel free to go and, and read the article. [00:36:42]

TypeScript compiler Golang rewrite??

Mark: Alright, so the other really big piece in and piece of news for not just the React ecosystem, but the web development ecosystem as a whole is the, the TypeScript team has officially announced that they have created a fort, not a rewrite of the TypeScript compiler, the current version of TypeScript itself is written in TypeScript, which means it's actually, you know, in the end it's the, it's just JavaScript executing and they have ported the compiler itself to be written in. [00:37:14]

Go. And what they say in the announcement is that they're seeing like generally 10 x speedups in the actual TypeScript compilation stage of processing people's programs. I saw at least one post on Reddit where someone was complaining that people are gonna be confused. That this means that they think that this means their code runs faster. [00:37:34]

It's like, no, this is just compiling the TypeScript types 10 times as fast. And this is a really big deal. this trend over the last five, six years of all these different JavaScript ecosystem build tools being rewritten in native languages, mostly rust, and getting a lot of speed ups that way. [00:37:53]

So, you know, es e es build as in go you know, RS pack and roll down are both written in rust, et cetera. I mean, a lot of tools being rewritten in native languages to try to speed things up, but a lot of them have still, like the actual build pipelines still get bottlenecked on TypeScript compilation time because it doesn't matter how, how fast you can process all these different, you know, individual module files and bundle them together if you're still doing a full type script type check during that section of the build phase. [00:38:29]

And so there's been a bunch of attempts to rewrite the TypeScript compiler. I. Into native languages from random people in the ecosystem. The author of SWC had tried to do a couple different attempts at porting. One in rust, one in go. I saw somebody who had done one with trying to, trying to create some kinda like a stack based virtual machine to process the types, and he'd gotten like a baby example working that seemed way faster, but it was only for, it only worked for very, very simple types. [00:39:01]

So, I mean, there, there's been attempts from individuals, but none of these got anywhere past, like a modest proof of concept stage, like they proved they could work, but then it's a massive amount of effort just to catch up with where the TypeScript compiler is much less keep up with where it's going on a month to month basis. [00:39:21]

And so, you know, a lot of people had said that, well, it feels like the only way this would actually happen is if the TypeScript team themselves actually decides to do it. Well, it turns out the TypeScript team decided to do it about a year ago, and they've been working on this in secret, and now they've gotten this far and proven it works and are actually intending to push this forward to become, you know, the actual TypeScript compiler down the road. [00:39:49]

as Carl mentioned, so right now we're on TypeScript 5.8. They put out quarterly ish releases, I think. So basically four, four releases a year. They also follow a kind of a, a, a decimal based versioning system where it's not really SemVer, but they just roll over from 5.8, 5.9, 6.0, 6.1. So they've said that the plan is that the new native go compiler will probably officially become TypeScript 7.0. So that means we probably have about two to three years before that actually happens officially. [00:40:26]

Carl: But they may also just release it like when it's ready. I, I don't believe that the version seven is a firm commitment. So it, maybe, it will, maybe validating it, maybe making sure that it won't break. Everything will happen faster than they expect, and it may be [00:40:42]

Mark: I mean, they, they, they might like, they, they might end up going from like a six four to a 7.0 instead of having to get through 6, 4, 5, 6, 7, 8, 9. [00:40:52]

Carl: Okay. I don't know. I thought they just did straight up incremental and when they got to nine they incremented, [00:40:57]

Mark: right, right, Like, so my, my point is that if it's ready in say one year from now, we would be at TypeScript 6.2, and rather than officially waiting another two years and eight more releases to get to 7.0, they might just say, okay, yeah, this is the end of the line for the old compiler here. [00:41:15]

Carl: yeah. Hard to say. Who knows? I do wanna, I wanna highlight a couple of, you know, comments from the people who worked on this. [00:41:23]

Github discussion and on reddit too

Carl: Ryan Cavanaugh put out a great Reddit comment describing why they chose go, basically. And, you know, we kind of talked about it a little bit, but I, I wanted to enter his words into the cannon a little bit here. [00:41:36]

Mark: I was shocked at how much pushback there was, especially from the C sharp folks. Oh my word. The C sharp community was up in arms about why the Microsoft engineers did not pick C Sharp as the language for the new compiler, [00:41:51]

Carl: Yeah, sure. I, the amount of space in my brain that C sharp developers occupy rounds to zero. So anytime they come on, I am a little surprised. But yeah. So like, I wanna, I wanna try and pull out a good quote here. So, like, really their primary goal here was portability. They don't wanna rewrite anything. [00:42:09]

They would like to adapt it into a new faster language. So they really say portability was always a key constraint here. As we thought about how to do this, we tried tons of approaches to get a representation that it would've made the port approach tractable and rust. But all of them either had unacceptable trade-offs or devolved into write your own garbage collector style strategies. [00:42:28]

So right, like they, it looks like they really genuinely validated trying to use multiple languages here at least between Rust and go. And they say, [00:42:38]

Mark: I think I saw mention they also tried in c as well, okay, in this post, but elsewhere. [00:42:42]

Carl: yeah, sure. That makes sense. I saw a quote that I liked. " In our opinion, rust succeeds wildly at its design goals, but quote is straightforward to port to rust from this particular JavaScript. Code base is very rationally not one of its design goals. It's not one of goes either, but in our case, given the way we've written the code so far, it does turn out to be pretty good at it." [00:43:01]

So like basically they chose to write code in a style that happens to align thematically with Go. And so when they chose to port it, it ended up working out pretty well. [00:43:11]

Mark: one of the key points here is that like anyone who's actually worked with a lot of TypeScript types or has dared to peek inside the TypeScript compiler, I. Is aware that there, there are a lot of very complex and very subtle behaviors of TypeScript and you know, one of the complaints about TypeScript for years is that there is no official spec for the language itself and how everything should work. [00:43:36]

It's pretty much just, well, the spec is what the compiler does for this release and that's it. So in other words, the, the spec is the tests that they have. It's not an official language design document. because of that, if you try to rewrite the compiler in another language and you kind of start from scratch, you run the risk of ha of like trying to do things the same way. [00:44:05]

But the code ends up being kind of different. I. Then you end up getting literally different output from the rewrite of the compiler, which would be really bad for the entire ecosystem that is depending on the compiler to return consistent type results. And so one of their conclusions was go allows us to make an almost literal one for one line for wine port of the exact data structures and the exact logic that we already have written in TypeScript. [00:44:36]

And so that guarantees that we should get exactly the same calculation results from the new compiler just faster. Faster. So that was a really, really big consideration here. [00:44:49]

Carl: Definitely makes a lot of sense. [00:44:50]

⚡ Lightning round ⚡

Carl: Cool. Okay. Onto the lightning round. [00:44:52]

JSC being extracted from RN Core

Mo: first one JSC is being extracted from React Native Core. So, several years ago there was a custom JavaScript engine that was introduced into React Native called Hermes. [00:45:01]

That's what everyone has been using for the last several years, or most people have been using for the last several years. There are some people who still use JSC for very specific niche use cases. And so it was inside of the reactive core package up until recently when it's been extracted out. [00:45:16]

So if you want to use JSC instead of Hermes, it is now an external package and you're gonna need to install it separately. [00:45:22]

node-modules.dev v0.4.0

Carl: This is very small, but seems neat. I'm just going to call it out. Anthony Fu put out a node modules dev, which just seems kind of cool. It's like a way of analyzing the dependency tree for a specific node module. It seems cool. I have had to do various ways of visualizing dependency trees a number of times throughout my career, and it's always been a pain in the butt. [00:45:47]

So just seeing a tool that's online, on the internet where you can just like plug it in and analyze it visually is very cool and interesting to me. Seems good. I like it. [00:46:00]

Fernando Rojo joining Vercel as Head of Mobile

Mo: next up on the lightning round is that, as we mentioned a little bit earlier on in the episode, a little bit of a, of a spoiler. Fernando Roho has joined Vercel as the head of mobile. [00:46:10]

And so this is a very interesting development because Vercel traditionally was very web focused. Expo was traditionally mobile focused. So those were the two frameworks. And it seems like they're starting to bleed into each other's territory, which is gonna get really, really interesting. So that is that's gonna be quite an interesting one to see because maybe Vercel is working on a framework for React Native. [00:46:32]

And we know that the Expo folks have been working on sort of web-based support as well, so we will see on how this develops. But it's just an interesting signal from the Vercel folks. [00:46:41]

Next vs TanStack (Router + Vite)

Carl: Kyle Gill put out a next JS versus Tan Stack article, which he at the very start says, was inspired by a 2019 post from Jared Palmer contrasting Gatsby with next js. [00:46:55]

I highlight that because Jared Palmer currently works at Versal. Fun fact, I interviewed with him for a job in 2017. I did not get it. And 2019 when Jared Palmer wrote that Gatsby versus Next Post I feel like was about the turning point for Gatsby enthusiasm starting to die off. That's when mine started to die off for sure. [00:47:17]

So that, it's, it's interesting seeing that he is calling back to that moment, in this moment in a pretty different direction. So we'll see, you know, who, who knows if that same trend will continue, but it's, it's, it looks like a great comparison of functionality between Next and Tan Stack. And Tan Stack is certainly getting a lot of interest in mind share. [00:47:42]

So yeah, if you're thinking about it, definitely check that out 'cause it seems nice. [00:47:46]

Expo’s AI Strategy

Mo: Cool. Next up there's a blog post that the CTO of Expo did on their AI strategy. it's quite a short blog post so you can kind of skim through it. But really the point they're trying to make is that we're in an age that you can use AI to democratize building apps. And so they talk about how they're gonna take efforts to make sure that their docs and, you know, all of their material is well suitable for things like the model context protocol, the MCP that philanthropic released but also other sort of, protocols and interfaces that AI agents may use. And then they talk about how Expo is being used by tools like Repli by Bolt and other tools already to build apps from prompts so that, you know, non-technical people can sort of, as we say today, vibe code their apps. But I think they, they're really seeing this as a uh, as an opportunity to, to get people to build apps. [00:48:37]

The everyday person who's not a developer to be able to build apps. [00:48:39]

Laravel launched “starter kits” including React

Carl: Laravel just released starter kits this month including some for React. So that's interesting. They're doing, like, I, it looked like it included server-side rendering. I'm not sure if that is owned by Laravel or React but just interesting. [00:48:54]

I don't know. I, Laravel is maybe on my mind because I was seeing a number of months ago some conversation discussing what you get out of the box with tools like Laravel and the general lack of anything comparable in the React ecosystem. Specifically around auth. I saw people talking about what you need to, what you get for free with a tool like Laravel. [00:49:18]

And I was a little bit surprised because you do not get that for free. In my experience when you're building an app with React, so that just gave Bit, gave me a bit of a respect for the, the, the tool. So it seems neat. It's a new major version, version 12. It's got starter kits. One of the starter kits uses React. [00:49:34]

It claims server-side rendering support. [00:49:36]

React Native Enterprise Framework

Mo: So next up, call stack, the folks behind React Universe Conf and libraries like React Native Paper, have announced that they're creating a new React native framework that's specifically targeting enterprise. [00:49:49]

Now, this is very early days. They're trying to target some of the pain points that enterprise clients with large, large number of you know, devs and with restrictions on where they can host their infrastructure are facing. And so they want to try to target that niche of React native apps which is quite interesting. [00:50:07]

And so, this is still very much in sort of waiting list stage. So it's, it's early days. But their, that, their start focus is that you can have reusable cloud builds that run on anywhere. Potentially GitHub actions but potentially also other pipeline providers. And also a nice way to be able to integrate Brownfield into existing iOS and Android apps so that you have an incremental migration path. [00:50:30]

So, very early days, we'll see. We'll see where we, where we, where this kind of develops and, and, and where this goes. [00:50:36]

State of React Native 2024

Mo: And last on our list is the State of React native 2024. So this is a survey that the folks at Software Mansion do every single year and they touch on a whole bunch of stuff like dev backgrounds, demographics, what libraries people are using, and what you use for state management and all of that. [00:50:52]

And so, this year the main things that they're that they basically concluded, which is, is kind of no surprise whatsoever, is the um, expos becoming sort of the main way to build react native apps. And they see momentum with tools like Chrome, the, the, the Chrome dev tools, protocol based new React native dev tools that Meta's announced and tools like Expo Atlas. [00:51:14]

But take a look into it if you're interested in. Analyzing the trends in the React native ecosystem. [00:51:19]

Carl: Alright, thanks everyone. That's everything we got. We will be back on the last Wednesday of next month in April on the 30th. come join us on April 30th here in the live stage, or we will be back in your podcast feed just as soon as we can. [00:51:33]

Mo: Yeah, well, always a pleasure guys, and looking forward to jumping on in April to see you all there. [00:51:40]

Mark: Likewise. [00:51:41]

Carl: Cool, see you then. We gather sources from this week in React bys.dev, react status next JS weekly, the React JS subreddit here in reactive flux, and sometimes even directly from those publishing articles. If you see anything newsworthy, definitely let us know in the Tech reads, tech News and Reads channel here in reactive Flux. [00:52:00]

Or you can send me an email at hello@reactiflux.com. I read everything that comes in, even if it gets marked as spam, so don't worry. If this is a show that you get value from and would like to support, best way to do so is by telling people about it or by submitting a review on whatever platform that you listen to it.

Thanks for listening. See you next month. [00:52:16]