This Month in React, February 2024: React 19 (but more details), Apple tries to kill PWAs

Transcript from Thursday February 29th, 2024

[00:00] Carl Vitullo: Thanks everyone for joining for February's This Month in React, where we recap and digest recent developments in the ever evolving React and web ecosystem.

I'm Carl. I'm a staff product developer and freelance community leader here at Reactiflux, the Discord for React professionals.

[00:16] Mark Erikson: Hi, I'm Mark Erickson. My day job is working at Replay io, where we're building a true time traveling debugger for JavaScript. And in my free time I do redux stuff.

Layoffs and job market

[00:25] Carl Vitullo: We're gonna start off again, as we have been the last couple times with just some quick hits, layoffs that FYI, it looks like it's peaked, hopefully.

There were just about 15,000 layoffs in February this year, which compares to 34,000 from last month. So that's down a little bit more than half, which seems pretty good. Pattern holds from last year as well, in 2023, numbers for January and February followed about the same pattern of dropping by half. But those numbers were 90,000 and 40,000.

So that's down substantially year, over year, uh, 90,000, January last year to 34,000 january of this year. So that's down like 60%. So that's pretty great. Not out of the woods yet. But definitely comparing to 2023, it's looking a lot less grim.

Here, I found a new resource that looks pretty cool, trueup.io/job- trend. It shows a number of open jobs in tech over time. It's not super clear where these are coming from. So, uh, take it with a grain of salt for sure. Don't know if this includes sales or product roles or if it's just engineering, but it looks like it peaked at 475, 000 jobs in April 2022, uh, down to a low of 163, 000 one year later, April 2023. And back up to about 200, 000. So the creeping back up, seems pretty good.

New releases

[01:46] Carl Vitullo: I'm just going to run through a couple of new releases real quick. We've got React Email v2. Cool. Always a little bit tricky sending email from React. Email is always a pain in the butt, so I love new tools coming out for that.

Tamagui 1. 88, which is a cross platform UI toolkit. The big selling point seems to be that it's seeking parity between web and React Native, which we're going to talk about a lot more later. There's been some cool new developments there. Yeah, they're supporting Expo 50, better types, and they tease a upcoming reduction in generated CSS size. So, seems cool. I know that's a reasonably widely used library. So, cool. New release.

I heard about a cool new project doing syntax highlighting. It looks really good, actually. It's called ExpressiveCode. Definitely check that out if you're doing any sort of project that needs to highlight syntax.

Relay. This is a little bit late, but Relay released version 16. 2. I've never been a big Relay user, so I don't fully understand what changes they just shipped, but if you use Relay, cool. There it is, new version.

And again, something we're going to be talking about later, but Remix released actually two versions, released 2.6 and 2.7. We'll go into a little more depth on that later, but wanted to give it a shout out.

And another, a little bit related, Isograph, which is a new take on doing GraphQL. Just announced a early 0. 1 release. We actually had the maintainer of that, Robert Balicki, on for an Office Hours last week. I think he released this version like an hour before we started the Office Hours event, so that was cool.

Upcoming Conferences

[03:24] Carl Vitullo: All right, moving on from releases, there are a bunch of conferences coming on in the next two months or so.

We've got React Paris, which is going to be March 22nd. It's in person, Paris, France, with a remote option as well.

There is also Epic Web Conf coming out, or that's going to be in April 10th and 11th in person in Park City, Utah. Kent C Dodd's conference. So he always does great stuff. I'm sure this conference is going to be pretty cool.

React Miami coming up April 19th and 20th as well in person in Miami. I went last year. It was really lovely. Reactiflux with a bit of an affiliation in that it's. The React Miami conference is organized by G2I, uh, which is run by Gabe, one of our admins. So definitely check it out. It was really great last year.

There's also another conference in France, React Connection. That's going to be April 22nd, so exactly one month after React Paris. So, you know, great reason to get out to France.

And one more in the next two months is React Native Connection. I guess that's also Same people, next day, also in France. So yeah, man, a lot of stuff going on in Paris.

[04:34] Mark Erikson: I will be attending React Miami and then I'm actually speaking at React Connection in Paris. So I'm actually going to be directly, if you look at the timing, React Miami is actually like Friday, Saturday, and then React Connection is the next Monday. So I'm going to be. Going to Miami and then flying directly over there.

[04:53] Carl Vitullo: That is going to be fun. We'll see if I can make it to any of the conferences this year. Not sure which ones I'm going to be going to. Yeah, that's all the quick hits we got. So let's go into our main content. Mark, you want to start us off?

React Labs, React 19

[05:06] Mark Erikson: We have some really big news from the actual official React team posted on the actual official React team blog.

They've put up another one of their React labs, what we're working on posts. And it's been 11 months since the previous post in March of 2023. And the good news is that there is a lot of details on what they've been working on, and a lot of pretty big pieces of news.

Most of this is stuff we've actually talked about in previous episode, it's not like most of this is hidden, but it's good to get official confirmation of what they've been up to and where things stand.

[05:40] Carl Vitullo: Yeah, you heard it here first, hahaha.

[05:42] Mark Erikson: Very true. So, the first and probably the biggest piece of news is that the React team has been working away for the last couple of years on what they previously codenamed as React Forget. And the idea is it's a compiler that will auto optimize the content of your React components.

Now, they talked about it initially at React Conf Online two years ago. They went kind of quiet for a while. They did a couple of talks in React India and React Advanced last fall.

And so the big updates now are that 1. The name has changed. It's no longer React Forget. It's now officially just called React Compiler. And then also that they consider it no longer an experiment, it's effectively production ready.

They are still working to finalize it and get it ready for use and release to the public, but it's a real thing that they effectively consider good enough that it's not just a will this work kind of situation.

[06:50] Carl Vitullo: Yeah, and it's good enough that they are using it on Instagram's website right now is what I hear.

[06:56] Mark Erikson: Yeah, when they did the talk at React Advanced in October, I believe they said that they were trying it out in production on Instagram Web's profile page, and then some kind of a React Native product page somewhere in Meta's code base.

They might have expanded it to other parts of Instagram since then. I'm not entirely clear if it's being used more broadly than just the one profile page. But it, it, certainly the numbers and the results that they talked about back in October were very good. And they've had another five or, five plus months to try to iterate on this.

Very encouraging to hear that this is progressing forward. Along with that, the React team said that the next official version of React will indeed be React 19. There will not be like an 18. 3 or 18. 4 minor release. I've, I've seen a number of people say that there are bug fixes that they wish would go out in a minor version, just to get them out sooner.

I think I've seen some of the Remix Community talk about some bits and pieces that are in canary builds that they wish were already in a stable build. But certainly what I've seen over the last couple of months had been that they were working towards what they considered to be a React 19 major version, and this blog post confirms that is what they are actually planning.

I do want to talk about the, a couple more bits about the React compiler. The most obvious thing that people will think about is that I don't necessarily need to put in the dependency arrays for things like useMemo and useCallback and maybe even useEffect. Because, you know, as the React team has said since Hooks first came out, if we just have a sufficiently smart compiler, It can figure out what variables you're actually using and fill in the dependency arrays automatically at compile time.

But, the bigger thing, and this is the point that I've tried to make in our last couple discussions, is React has always had some built in optimizations if you memoize the JSX elements that your component returns. And so, the biggest benefit of React Compiler is that it will auto memoize chunks. of the elements that your component returns.

So if your component returns, like, I don't know, three separate divs, and they depend on some combination of four or five different variables, it would auto memoize each of those chunks, so that the element only gets recreated when the input values change. And at that point, React's render optimizations kick in.

And it just skips re rendering those child components, unless they change. You know, React has always had the mental model that we're actually gonna, we're gonna pretend like your entire application just got recreated every time. In practice, what it does is, when a parent component renders, everything inside of that renders by default.

So you can kind of think of React Compiler as flipping that on its head. So that it's not just re rendering all children by default, but only children where their data actually changed. So, in a sense, it's actually kind of taking a common misconception and making that the default behavior.

[10:14] Carl Vitullo: Yeah. Always good to if people hold expectations about how something will work, uh, nice to match that.

This is a very high effort way to match people's expectations, but cool that they are confident enough in it working that they're starting to use it themselves on production apps.

[10:31] Mark Erikson: And so Brad Westfall from the React training team had, or company, had a good post called React will be compiled, where he goes over some of the implications for that.

Along with that, the React team has always been very big on trying to keep backwards compatibility. You know, you can still even use, you know, the original legacy create class API just as an extended package. React 19 will drop a lot of pieces that have been deprecated for years. They're finally killing StringRefs, they're killing LegacyContext.

And a couple other pieces. Along with that, there's some iteration on how you're intended to use some of the existing functionality. Andrew Clark had a tweet where he's like, You know, we've got a lot of things that have been built in, but with React 19 and the compiler changes, You're actually going to access some of this functionality in a different way.

So, you know, you won't have to worry so much about trying to memoize things. The compiler will take care of it for you. You won't have to use React. forwardRef because now components can just get ref as a prop directly. Apparently you won't need to use React. lazy much anymore. You can just have a promise that represents the component and put the promise directly in your JSX output as a child.

The useContext hook will get replaced by the new use hook that accepts a context directly as an argument. It also will be the replacement for the undocumented but everybody knows about it technique of throwing a promise for triggering suspense. And finally, context objects themselves will now be considered the provider components that you render.

So you can just render angle brackets, myContext. Instead of angle brackets, my context dot provider. Most of those are not huge changes. It's not like it's adding necessarily new functionality, but it is making some existing functionality nicer to work with.

[12:33] Carl Vitullo: It really reduces the, you know, surface area of React's APIs quite a lot.

Like, no more UseMemo, UseCallback, or the, you know, React. memo. The number of APIs that React exports is now dropping by like, what, six or seven? It's a lot. That's a lot. That's a lot fewer. Pretty cool.

[12:55] Mark Erikson: And then, finally, the blog post talks about a lot of the features that they've been working on, especially in relation to suspense, and server actions, and forms.

And, part of the reason why they came up with this Canary version release concept is they had features that were mostly ready, or close to being ready, and in theory, they were ready enough that frameworks like Next, or Remix, or, you know, something else, could make use of them, but they didn't have all the pieces ready yet, so they couldn't go into a public, stable release.

They've had some of these new, you know, pieces like server actions, or the use optimistic hook, or use form status, available in Canary builds for a while. The key line from this blog post is that they said, the current set of features in React Canary are complete and ready for release. So that's actually a pretty big deal.

One thing that I thought was interesting, which I hadn't really seen talked about anywhere else, and I did not actually understand the first time I read the blog post, React DOM is now going to support rendering metadata tags Anywhere in the component tree. And this means that if you render a title tag or metadata or link, number one, it'll automatically insert those into the head of the document.

And two, you can render those from anywhere, which. As they said, basically replaces the need for a library like React Helmet. I have not had much need to do that myself in my own career, but it's, that's actually a pretty big deal to build in that kind of functionality. And along with that, they're adding support for suspense for things like assets, like script tags and style tags.

So, there's a lot of moving pieces here, and it looks like a lot of this stuff is about ready for release. So that's pretty big news. And my assumption is that React 19 will probably either go final, or at least be in beta plus like a release roadmap at React Conf in May.

[14:59] Carl Vitullo: Yeah, that seems like a safe assumption.

They tend to make pretty major announcements at their conferences, so the lack of conferences for the last, what, four or five years? Yeah, definitely seems like Enough pieces have come together that they're comfortable saying like, yes, this is, here we go.

Yeah. And on the React Helmet stuff, that is something I have had to do quite a number of times in my career. And pretty much every time I set up React Helmet, get bit by some bug, some weird quirk in how it works. Look for an alternative, find nothing, and then, you know, begrudgingly make do with whatever weird things React Helmet is doing.

So this seems like a really great small tweak to make the experience of developing a new project in React just that much easier. So pretty excited for that.

A PR for Server Components support in Parcel

[15:47] Carl Vitullo: Cool. All right. Let's talk about React server components, suspense, and server actions. There's a, an initial PR for parcel support for React server components. It looks like React Server Components needs like an external package to do things that I don't really understand because I have not looked at how you implement it from scratch in a framework.

But so it looks like Parcel is now getting that support. So I think that's going to be the second. You know, Bundler that officially supports React server components. So that's, you know, going from one to two, that's a pretty major improvement here. But that's, that's pretty much all I know about it.

[16:25] Mark Erikson: Got to have the Bundler build framework integration to actually hook up the pieces and make them do something useful.

[16:30] Carl Vitullo: Right, yeah, this crosses a lot of boundaries, and one of the, one of those boundaries is from your app into however that app is being bundled into a production asset. So, do you want to introduce this blog post it looks like?

[16:43] Mark Erikson: Yeah, so Sam Selikoff has done some, a couple different blog posts and talks related to how to actually make use of server components in more realistic applications.

I haven't had a chance to go through this post in detail, but I saw Dan retweet it. So it's a discussion of how you would actually use server components and implement logic for things like filtering and displaying pieces and components and pieces of data, primarily based on search parameters. And so it goes through and shows examples of using a lot of the new pieces like some of the form state hooks, server actions, actually being able to control the behavior using suspense.

So it feels like it's a pretty good example of how all the different pieces actually play together in practice. Super cool, yeah.

On the flip side, I also saw a couple articles that are maybe just a little bit skeptical of how to use a couple of these pieces. One was an article called, Is Suspense Worth the Squeeze? And the author basically says, you know, suspense is useful, but in the end, like, showing loading states isn't necessarily, like, The greatest thing in the world. And it feels like, you know, maybe the React team's focus could have been better spent on some other things.

This was at least a little bit more of like a technical set of complaints than some of the articles we've seen recently, where it's just like, I have bad vibes about React. So it's, you know, not necessarily like, you know, a big argument one way or the other, but I thought it was at least a little more of a reasonably technical focused.

Similarly, there was another post called, Avoid using React's new UseFormStatus hook, where the author points out that you can only make use of the hook inside of a form component, and he had some use cases where he wanted to be able to deal with form status outside of the form tag.

I think I also saw some discussion with Dan about this on Twitter, I don't have a link to it. Right this minute, but Dan's reply was that it was something about being able to properly compose pieces of the forms together as to why that limitation exists. So it's good, you know, discussion of, you know, some of the trade offs and understanding the actual limitations of available APIs is important.

[19:01] Carl Vitullo: That reminds me of some of the things we've discussed about, like, context dependent APIs that React has started relying on. It seems sort of adjacent to the, you know, use server, use client directives, where you sort of opt into different behaviors in different parts of the tree. So, yeah, definitely having different bits of functionality only available in certain contexts, where it's not always super intuitive what those contexts will be.

Yeah, that's a little bit funky.

react-strict-dom package

[19:30] Mark Erikson: Moving on to the next section. There was another fairly big announcement from Meta within the last month. A new project called React Strict DOM. And this is really about taking React Native and giving it compatibility with web APIs. So let's back up and give a little bit of context on this one.

You know, React Native came out in like 2014. It's, I think it's, it's been a while. Part of the principle of React Native has been, you get to use all the same concepts of React, you know, the components and state and rendering, but because it's targeted to native, and, you know, native could be Android, iOS, or even other platforms like Mac or Windows.

React Native has its own set of abstractions. It doesn't use divs and spans and, you know, lowercase b buttons. It has its own abstractions like a view. And, you know, a view maps to whatever the underlying operating system primitive is for I want to draw a rectangle on screen and do something with it. And so you get to reuse the same concepts that you know from React DOM on the web, but the types of components that you render are completely different.

And so there's been various attempts to make it easier to reuse code across both web and native platforms over the years. And one of the biggest ones was called React Native Web by, created by Nicholas Gallagher, I believe while he was originally at Twitter, and then he eventually left and went to Meta.

React Native Web tried to recreate the names and types of the React Native components, but they rendered to DOM elements. So you would import capital V View from React Native Web in your web app, and you would render it, and on the web it would actually output a div instead. And so the idea is that you would always render a view instead of a div.

And that made your source code compatible with both React Native on native platforms and React on web platforms. And so this is useful, but also had its limits. And so I believe this new project, React Strict DOM, has actually been worked on by Nicholas Gallagher and a bunch of other folks. And it basically takes the opposite approach.

So rather than trying to make, to write web apps Where you're using something that looks like React Native component types. Instead, the goal is to make React Native look and feel more like the web. So they've been working to fill in, you know, various missing pieces of web compatibility behavior. And React Strict DOM gives you tags like HTML. div, and at usage time, those actually turn into a React Native view under the hood. So the idea is, you would now write your React components as if they were web based on both platforms. On the web, of course it outputs an actual div, and on native, it would actually map to a React Native view under the hood.

So the idea is now, let's just pretend we're writing web style code everywhere, and it's just that on React Native it turns into the underlying native view instead. So this is brand new, but it sounds like it is actually being used in production at Meta, and it's gotten to the point where they felt they could open source this.

[23:08] Carl Vitullo: I saw a tweet from Dan describing it as a spiritual successor to React Native Web, and like you said, you know, from the opposite direction, which makes a lot of sense. I, it, I have worked on React Native exactly once professionally. I tried to do a couple of side projects that never really got off the ground.

It always struck me as just a little bit weird that like the view to div, you know, they're functionally almost exactly the same. It's just that one doesn't work and, they don't work in each other's contexts. So, trying to unify that just a little bit, trying to get rid of some of those weird edge cases that prevent compatibility from working. Yeah, sounds really cool.

I had been really excited about React Native Web, what, five years ago, six years ago when it was new, but it just never really, never quite fulfilled the promise, the, you know, the vision that it had set out to. So cool to see another take, taking what people already do and making it compatible in the native context seems a lot easier than trying to get everyone to change how they write code to fit better with how React Native is authored. So yeah, pretty excited to see.

Yeah, there was a great announcement thread from Lorenzo Sciandra, Kelset. Who, I think he works on this stuff. He's a senior software engineer at Microsoft working on React Native. Really great thread. Definitely goes into a lot of details, links out to a lot of great resources and RFCs and GitHub issues. So definitely check that out for a lot of details.

There was also a wonderful compatibility chart showing the progress that they're, they've made so far. Look, it's a, it's a little bit rough at the moment. There, there's no green, but a lot of yellow and not too much red. So I think where the red is mostly on the, you know, more fringe side of HTML, although it looks like inputs are not super well supported yet, but I guess inputs are going to be tricky on. Just a little bit more functionality going on there, a little bit more behaviors to replicate.

Apple announce no more PWAs

[25:09] Carl Vitullo: Cool. All right. I guess I'll move us on. This is a bit of a news, I don't know, a broader ecosystem news, but Apple has announced that they are dropping support from, for progressive web apps in response to regulatory challenges in the EU markets. I am pretty disappointed to see this. I had always, I've always been.

Excited about progressive web apps. I love the thought of being able to author web applications in ways that are more meaningfully competitive in terms of user experience in a native context, you know, going back for years, Apple has not meaningfully supported a lot of the deeper functionality that would make this, more meaningfully, you know, work like a native application.

Look, I dug deep on refreshing my memory of how these were, what the original vision for progressive web apps were and how it was meant to unfold. And in like 2014, 15, the Chrome team from Google really put out a lot of effort on doing a cross platform standard for essentially an app store.

If there, you know, if you look at the MDN docs for the progressive web app manifest. It references a lot of things like, you know, screenshots and, you know, install methods. Where does this live? How do you access it? So this ultimately, Apple dropping support for progressive web apps, really it comes out of a series of lawsuits that have, that they, that have been unfolding in Europe around anti competitive behavior in the app store.

You know, it kind of goes back to their 30%, you know, the Apple tax on all purchases in the iOS ecosystem. So, you know, the slightly conspiracy theory minded take on this is that fully supporting progressive web apps would meaningfully cut into their app store dominance. And so they had a strong disincentive from supporting them.

So just, disappointing to see, if you are working on a progressive web app, especially in a European context, there's an advocacy organization called the Open Web Advocacy that is doing a, you know, action. So, if you are based in Europe and maintaining a progressive web application and would be impacted by this, definitely check that out.

Going a little bit more, sort of broadly, back it up into, like, what is a progressive web app, why would this be meaningful? I think there's a lot of overlap there with local first as well. Um, just sort of the general idea of building a website that functions in ways similar to how people expect native applications to work.

So for, like, local first, I think a wonderful example of that is, like, your email client. You know, Gmail on my phone, I can go in airplane mode and I can use it exactly as if I was online. I can archive things, I can recategorize them, I can draft replies, I can send things, and then once I'm back on network, it all works as I expected it to.

So, the original vision for progressive web apps was providing a series of tools and platform features that enable that sort of thing. So, you know, the manifest is a way for web applications to say, these are the files I support. These are the, you know, domains that should open in this app.

Then there's supporting features as well, like service workers. That's how you can provide a programmatic CAF from the web browser context. If they like, okay, if there's no network, here's how to respond. Unfortunately, mostly, it seems like the service workers mostly got used to serve 404 pages that look pretty, which like, okay, yes, that is something you can do with them.

But it would be much more interesting if it would do synchronization of data in the background and queue up updates that you make while you don't have network. So I'm disappointed to see this. I had always been really excited for the potential of progressive web apps. And if this decision by Apple to meaningfully reduce support doesn't get changed, then kind of seems like a, maybe not the final nail in a coffin, but definitely a pretty big nail in the progressive web app coffin.

Very sorry to see.

[29:22] Mark Erikson: I haven't read through this in detail, but it seems like some of the claims are about, like, well, if we're, if you're forcing us to support multiple browser engines, we can't guarantee 100 percent perfect security and all the safety guarantees that we want to enforce on our own platform, but frankly, it sounds like, uh, well, if you're not going to let us do what we want, we're going to take our ball and go home.

Kind of a temper tantrum.

[29:44] Carl Vitullo: I'd agree with that, generally.

All right in between recording this and publishing it, Apple has announced that they are actually changing tack and will be allowing home-screen web apps as they refer to progressive web apps which honestly is probably a better name.

They're still going to be requiring that progressive web apps be authored in WebKit. So they're not allowing for alternate browser engines to fully integrate progressive web apps on iOS. They're claiming that this is to align with the security and privacy model for native apps. Uh, which to me, I interpret that as they have complete control over how notifications and device access work in iOS, and they're not going to give up any bit of that control to a third party, namely their largest competitor, Google. Apple's also very much in a very real way, hamstrung the way progressive web app notifications function in iOS for years now. They have never really made a serious effort at allowing developers to fine tune the user experience of how notifications are delivered. Which again I take as a subtle indicator that they don't like the operating model of a progressive web app because it is in competition with their other business interests. We're veering out of news and into, you know, I don't know, history, but there was a really great, somewhat satirical talk from 2013, given by Gary Bernhardt, called The Birth and Death of JavaScript, where he takes, it's sort of like a sci fi retrospective of JavaScript.

So, yeah. He, he, he takes the perspective of someone in like 2035 discussing the arc of JavaScript and how it took over the world. And it's actually, it's a really good talk and it really got me excited about the potential for JavaScript in the world. And a lot of that really hit, I think it's very, it was very prescient and I think it got a lot of things very right.

It has a funny bit where he, through the entire talk, pronounces it, "yava" script, uh, which I always found entertaining, but I would recommend that, um, I. Even though it's now 11 years old, um, I think it's, it talks a lot about like WebAssembly and the Browser taking over as the default runtime from the operating system.

Um, it just, it, it, it takes a very broad, interesting perspective on programming and where we write apps and how they run. Definitely really interesting. And yeah, it's from the same guy who did that very famous "wat" talk with. you know, making fun of JavaScript. So definitely, definitely check it out. He's, I think he's been a little bit less active over the last 10 years, but he had a, he was very influential early in my career. So if I can direct any attention his way.

Next App Router: The Good, the Bad, and the Ugly

[32:24] Carl Vitullo: All right, Mark, you want to take us on to talk about Next?

[32:27] Mark Erikson: Sure. There were a couple of good articles that came out that discussed different companies attempting to migrate to Next and the Pages router and server components. And it's interesting to kind of look at them and compare and contrast some of the opinions and responses.

So, Flight Control, which is a startup that does a different AWS dashboard, basically, talked about migrating some of their apps over to the app router. They had a number of things they did like. Layout and loading states. And some of the data loading patterns that they were able to use. They also ran into a lot of problems.

They felt that they had to kind of duplicate data fetching code in order to handle live updates on the server. They didn't like issues like lack of routing type safety or some error handling situations. They really struggled a lot with the performance of the development mode server. I saw Brandon Bayer, the founder.

Complaining about this repeatedly on Twitter, and asking, like, what can we do to try to speed this up? And, I know at the time that they were on the Next 13, I think he later said they did switch to Next 14, and it didn't seem to get any better. So, whatever specific problems they were running into with the speed of the dev server and memory usage, They considered those to be really major pain points.

One of the comments in the article was it was marketed as production ready way too early. And it's been, it's a year later and we're still running into all these sorts of issues. So their final conclusion was, we would actually choose Remix if we could have gone back and started over.

There was another article from a company called Medusa where they switched over their own next starter template to use the app router and server components. Medusa is apparently an e commerce framework. Their response, their opinion seems to be fairly positive overall. They thought that, you know, data fetching and caching was pretty good. They liked being able to use server actions to update state on the server. Talked about some different cases like static pre rendering and managing server versus client components.

So they said, you know, it does take some getting used to, but, you know, once you switch over to it, it actually feels pretty natural. So, you know, always good to see some real world examples of people actually train these out in practice.

[34:48] Carl Vitullo: Yeah, super cool. I see that Medusa post also talks about moving state to the URL, which I have worked on a couple of apps that did that, where they meaningfully kept application state up to date in the URL as you click around and navigate.

The first time I worked on an app that did that. It just, it blew my mind. It was like, oh my God, every app should do this because then you can share, you can, you know, get the app into a certain state and then send it to somebody and they can, you start using the app from exactly that state. Really interesting concept. So cool to see it discussed in the context of Next 14. Cool. Cool.

Remix 2.6, 2.7

[35:22] Carl Vitullo: I'll move us on to Remix. Like I said earlier, they put out two minor versions. There's 2. 6, which looks like it's mostly a sort of bookkeeping release where they, they made a breaking change to the unstable Vite plugin. So I guess. There you go. There's a minor release necessary to do that.

2.7, they shipped VEET support, so they are now calling their, you know, internal usage of VEET stable, which also unlocks their single page application mode, which is pretty cool. That seems like it makes it meaningfully compete with Well, I don't know.

I don't know. It's interesting to see. I was going to say meaningfully compete with something like Astro or Gatsby, but you know, actually, no, it's not quite that. It's not static generation. It's a single page application. That's a new context. Single page application is still like, I know the enthusiasm for that mode of publishing has dropped off in the last, you know, two or three years, Jamstack and all that kind of stuff has kind of lost mindshare, but it's still the simplest way to ship a web application.

You know, if you're going to be hosting something, putting up static assets and letting it, you know, render entirely in somebody's client browser is lowest cost, lowest number of moving parts way to ship a product. So definitely still has use cases, I think. So cool to see Remix adding support for that.

There was also an interesting feature that I don't quite know if I fully understand, but they called it server bundles, which looks to be support for basically sharding out a backend into multiple servers. So it looks like you can, at build time, communicate to Remix that this part of the backend. needs to be isolated from this other part of the backend.

I could be mis explaining that, so don't take my word as gospel on this. I have not played around with it extensively. They mention that if you make use of this feature, you need to have something in place in front of Remix to direct the traffic and make sure that the correct backend gets, or rather, that the correct bundle gets the requests it expects.

So it seems like, you know, a very niche feature that, like, large teams, large products with a lot of engineers making changes, a lot of performance characteristics to fine tune will need to take advantage of. So that seems cool. You know, one way of, I don't know, dealing with growth.

It also looks to support a React router feature for base names, which is basically just a pre pended route segment. So you can say, this entire web app lives under this part of the path, and then, you know, routing will still work. That is something I have done a couple times in my career, and it has been fiddly every time. So, nice. Good to see.

They also open sourced Remix. run, the, you know, Marketing website for the whole project. So that's pretty cool. They discuss some of the trade offs of, you know, why wouldn't you open source a site like this? Why would you want to? And I guess, why would you want to is basically open source is good and making the website code available is great. Uh, and why wouldn't you want to is sort of vague security risks and, you know, risk of leaking information and things like that. Nice to see the code for the site getting released.

They also put up some good first issues on their, on the GitHub. So if you are looking to bust an open source, there's. There's some options.

State of React Native

[38:44] Carl Vitullo: Moving on to our next set of links. There's been some good stuff coming out for React Native. Software Mansion, who does, they're, they're a consultancy that does a lot of React Native work.

They maintain quite a number of open source projects. I always see them coming up in discussions of new React Native projects. They put out a state of React Native survey, similar to the like state of JS, state of React, state of CSS. But not organized by the same people, just to be clear.

They had like 2, 500 respondents, it looks like. Just going to run through some quick stats here. Like two thirds of those have a higher ed degree, which I was a little surprised by. I thought it would be, as someone without a bachelor's degree, I. Was just surprised to find myself in such a small minority. One sixth of their respondents have no degree at all.

It looks like the median, you know, I, this is a bit of a guess, I didn't have access to the data, so I'm just kind of like looking at percentage respondents. It looks like about the median engineer who responded has two, between two and six years of experience with React Native. Between five and 11 years of experience professionally programming in total, and 95 percent of the respondents were male over half between 25 and 34 years old.

Top three industries represented here, finance, education, entertainment, with below then was consulting, social media, and web three, and. Something I found interesting, the vast majority of respondents, like well over 50%, work on a team with less than five engineers. And one in four people who responded to this survey are solo developers.

So pretty cool to see. Just, I found those, you know, demographic Breakdowns of who is using React Native and how are they using it to be pretty interesting, just macro level. What's going on? But yeah, state of React Native survey definitely has a lot of really cool details that I did not get into. Lots of stuff about usage and opinions and what supporting libraries are being used, what features are being taken advantage of, what aren't. So that was pretty cool.

React Native Frameworks RFC

[40:41] Carl Vitullo: Also a bit on react Native Frameworks. It looks like there was, I was a little bit confused by this, it seems, as I was reading through it, I guess they're more sharply defining the boundary between React Native and Expo.

I'm not sure that there's another Similar framework to Expo. As I was reading it, I was thinking like, Oh, would like React Native web fit into this, would, you know, the React Native Windows, React Native Mac, you know, the VR support and all that, but it looks like they don't. Those are not frameworks by this definition.

So I believe the only framework this is, you know, connected to defining would be Expo. The rest of those are, all of the other runtimes are described as an out of tree platform where, you know, tree there references the Git repo. So React Native. It has first party support for iOS and Android and everything else is an out of tree platform.

So, this is interesting, it just seems like they're being a little bit more thoughtful and proactively communicating about responsibilities, saying, we are responsible for this, and a framework like Expo is responsible for this category of things. So, it seemed like a minor, but significant shift. in how things are, I don't know, defined (chuckles). Seems cool.

[41:59] Mark Erikson: That was basically my takeaway. I mean, I think with the general React emphasis on, you should be using React built into a framework and most of the framework's being web focused, I think the React native side of the house was trying to get ahead of the game a little bit and say, Okay, here's what that would look like on our side if anyone else tries to build an RN based framework.

[42:19] Carl Vitullo: I'd agree with that. It does seem like a compliment to, like, how Remix and Next are shaping up, but we don't have a sharply defined criteria for what is a framework responsible for in React. So, hey, maybe this is a proof of concept. Maybe we'll see something like that in the web context too. Ha, we can dream.

Cool. One more thing to share on React Native, there is semi official support for. The Vision OS, which is pretty cool. Always cool to see. I'm impressed at how quickly they got that out. I got to say, it looks like they started working on it in June, 2023. They got a group of concept working in like compatibility mode, but that was like super stripped down, like technically it worked, but you could not, you know, the, what it, what behaviors it supported were, the list of that was very short.

So this is now a much more full featured way of writing apps on the Vision OS with React Native. They described it as essentially a fork of the React Native core, which, whoo, that's a lot of work, haha. And something I found pretty cool, pretty impressive, is they got it working without even having access to a hardware device.

So this is all just on the Vision Pro Simulator. Like, wow, that's hard, haha. All right, that's all of the main news items we, we have so far. Mark, take us away with the first lightning round.

⚡Bun shell support ⚡

[43:34] Mark Erikson: All right. So the Bunn JavaScript runtime has announced that they now have built in shell support. You know, it's always been kind of hard to kick off.

external programs from within a, like a node JavaScript application. Like you can do it, but you have to call, you know, functions that capture standard in, standard out. And it's, it's not really ergonomic or intuitive. So bun now has a built in dollar sign variable. And when you use it, you just pass in like a command that you would have run in a bash shell, like, you know, LS star dot JS, or, you know, the infamous RM dash RF.

And it just automatically executes it and hands back the results as a nice neat async await. I've actually got a little bit of prior experience with something like this. I had used a Python package years ago that did something very similar. So you could write Python scripts that It felt very shell scripty in terms of executing other commands and getting the output back. So I can definitely see some nice advantage of this.

Working with scripting in a language like JavaScript is a lot nicer than dealing with Bash. The issue here is that being able to use commands like ls or rm, assume that you're running inside of a Bash shell. Which normally means that you're running on Linux or Mac, because Windows doesn't have those by default.

A lot of people, like myself, might be using a WSL Linux environment on Windows, or at least the Git Bash version ported to Windows. But they've apparently gone and polyfilled a lot of the common shell commands you would be using, as well. This is not the first attempt to do that. There's an existing library called Shell. js, which provides JavaScript only implementations of common bash commands. I believe the Yarn package manager has already done something similar as well, so that you could, I believe, I haven't looked at this in a while. But I believe if you're using scripts in your package. json, Yarn will automatically fill in some commands like rm or setting environment variables to be cross platform and work on Windows and not just on Linux or Mac.

So there's some prior art here, but it's nice to see this built into Bun.

[45:46] Carl Vitullo: Yeah, super cool.

⚡Deno 2023, 2024 ⚡

[45:46] Carl Vitullo: The Deno team had a pretty cool looking Summary of what they've been up to in 2023. And I'm just going to roll straight into, they also did a blog post about their, they did a survey and announced a bit of a roadmap for 2024.

They're targeting a major release this year, which they say will offer, third party framework compatibility, the ability to use any npm module, and all while having the best in class developer experience.

I love all the explosion of alternate runtimes that we've been getting. I remember watching the Deno talk a couple years ago and just thinking that it was a really interesting take on What did we get wrong in Node?

Deno is from the originator of Node. So he, this is very much a take two on a JavaScript runtime on the server. So I, I've been following him pretty closely just to see what's going on there.

⚡JSR.io ⚡

[46:35] Carl Vitullo: I guess I'll roll straight into another one that I had queued up for later, but it's closely related.

The Deno team is doing a new JavaScript registry called jsr. io. I just got access to it and it seems pretty neat, I gotta say. For one, it's ESM only, so there's There is no longer going to be a CommonJS option for publishing to this registry, which that alone has me interested. The CommonJS vs.

ESM split has been an absolute nightmare and a huge blight on the JavaScript ecosystem. So, that alone seems like a pretty good reason to try a new registry. It does look like they are starting from scratch. Um, I have I poked around just a little bit, and I don't see any familiar modules published there, but I'm excited to see where it goes.

It's waitlisted right now, so if you are, if that sounds interesting, hop in the waitlist. I got off of it in like two or three weeks, so I have no idea what that means. But yeah, Deno, a lot of stuff going on.

[47:36] Mark Erikson: I know I saw an article or two somewhere that was talking about using it.

I think one of the interesting changes is it looks like they actually want you to just publish your TypeScript source code and the registry takes care of doing the compilation, I think, was something I saw. That would be a very significant change.

[47:57] Carl Vitullo: Yeah, oh that's super cool.

⚡How Hot Module Replacement works⚡

[47:59] Mark Erikson: Alright, next up, there was an article talking about how are the hot module replacement feature is actually implemented inside of the Vite bundler.

This is long, it's detailed, frankly this is all information you will never need to know in order to use or build applications. But it's a really good article that actually digs into the technical details of what does it take to implement the, you know, you know, module graphs and swapping and all the specific APIs that actually make hot module reloading possible.

[48:29] Carl Vitullo: Yeah, really good post. I love deep dives into obscure parts of the ecosystem.

⚡pmdrs WebGL uikit⚡

[48:33] Carl Vitullo: Cool. The, the Poimanders, never quite sure how to pronounce that. They shared a fully functional WebGL UI rendering engine. It seems pretty cool, it's basically a layout engine for React 3 Fiber, which is pretty neat. If you're trying to work in WebGL, like that's about as close to bare metal as you can get in the browser from a, you know, like rendering engine side of things, you know, set aside web assembly and whatever you, so, but just like.

Any kind of layout, you don't get any support for. So, pretty interesting to see somebody taking advantage of work done on React Native, actually, because this relies on the Flexbox engine that was built in order to facilitate React Native, the Yoga layout engine. So, super cool, definitely check that out if you are experimenting with WebGL on a side project.

Should make some of these things a little bit easier.

⚡Updates from the 100th TC39 meeting⚡

[49:25] Mark Erikson: Alright, and the last item on the list is some updates from TC39 as potential new JavaScript syntax features make their way through the pipeline. Not a lot of huge news here, a lot of items at stage 1. There's a proposal called Promise. try, which is basically like a, almost, like a try catch for running any kind of function, sync or async, and getting back a promise for the result.

One other thing that I saw, let me go find the details on this. I believe I saw mentioned that they've actually added a new stage number to the TC39 process. So traditionally it's been like stage 0 is just, we have an idea, stage 1 is we've proposed the idea. Stage 2 is, we, we think this idea could work, but it needs to be fleshed out. Stage 3 is, this basically works, we've got it implemented in a couple browsers, it's just Nailing down the final details and then stage four is it's good to go.

They've actually added a new stage, which is, and this appears to be a real official thing, Stage 2.7 because it's more than stage two, but less than stage three. And I think I actually saw a comment that stage 2.7 is a little bit like what stage three used to be and now stage three is slightly more involved. This actually appears to be a real Thing.

[50:46] Carl Vitullo: I love that. It's more than halfway, but. Cool.

Alright, that's all we got. Thank you so much for joining us. We'll be back on the last Wednesday of the month here in the live stage of Reactiflux or back in your podcast feed just as soon as we can.

We gather sources from all sorts of newsletters like React Status, bytes.dev, Next JS Weekly, React Digest, This Week in React, love that one, as well as like the React JS subreddit, here in Reactiflux. We do check the #tech-reads-and-news channel. So definitely if you see any news coming out, let us know. Put it in that #tech-reads-and-news channel, or if you like, you can send it to hello@reactiflux.Com. But make sure to include TMIR in the subject line. It's an acronym for the show.

And we are starting to professionalize. We're trying to grow and find some sponsors. So if this is a show that you get value from and want to support, best way to do so is by giving us a review or telling your friends about it.

Thanks so much. Excited to see what happens in March. Bye all.