This Month in React, October 2024: React DevTools update, React Native 0.76 (new architecture dropped), Web Components are(n't) the future

Transcript from Thursday October 31st, 2024

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

And we're supported by Infinite Red, a consultancy that exclusively works with React Native, but we'll do a little ad read for them later. [00:00:21]

Hello, I'm Carl. I'm a staff product developer and freelance community manager here at Reactiflux where I run community programs like these events and the star helpers, and do other stuff to keep the community running smoothly. [00:00:33]

Mark: Hi, I'm Mark. My day job is at replay. io, which we're going to have a slight tangent on the io part of this later on. And other than that, on Redux stuff. [00:00:43]

Mo: The mobile team at Theodo which is a global consultancy and I'm active within the React Native ecosystem, organizing the React Native community and here and there dabbling in some open source. Happy to be here as always. [00:00:56]

Job market: FRED data, Layoffs.fyi

Carl: Yeah. First up, some quick hits while people start filtering in. We did not do a job market update last month. It was actually pretty quiet. Not a lot of news. It seems kind of back to baseline. data for posts made to Indeed is still, like, two thirds of what it was at the beginning of 2020 before pandemic hit. [00:01:14]

that might have been a high watermark for the industry, so it's, it's kind of hard to say. Layoffs at least have been, look very low for the last two months in a row. So that seems good, but yeah, the hiring has not really picked up. But not sure it's going to. [00:01:29]

I wonder about that. Definitely the vibe I've been getting is that most of the roles being hired for are more on the seniors end of the scale, which is Not ideal, not great, but yeah, seems to be where it's at. [00:01:40]

New releases

Carl: Yeah, into some new releases. [00:01:41]

Moe, you want to tell us about React Native? [00:01:43]

React Native 0.76 proper

Mo: Yes, indeed. I feel like this is years in the making, so I've got to really drum this up as much as possible. But, the new architecture is finally here, [00:01:54]

New Architecture is here

Mark: Woohoo! [00:01:55]

Mo: So this is React Native version 0. 76. And if you go back into likethe history of React Native over the last five years, the first mention of the new architecture publicly was in 2019. [00:02:08]

And really what the whole purpose of the new architecture was, was to make a more stable Baseline for React Native interacting with native platforms. How components are rendered. How does JavaScript code trigger native code and native modules? And how do we move different things around different threads and make sure that everything is optimized and consistent? [00:02:28]

A lot of people think that the new architecture is like a performance oriented update. It doesn't really have that many major performance improvements. There's minor ones, but really what it's trying there for mainly is, I think, for library maintainers and for framework authors to be able to create a more consistent pattern of communicating between native and React Native. [00:02:47]

So, for a little bit of context, React Native's old architecture used this thing called the bridge. So it was basically a messaging bridge where you could pass in serialized JSON from the JavaScript layer and from the native layer and it would kind of get communicated across this bridge. But the issue with a bridge is that it can have some traffic, right? [00:03:03]

So you can bombard it with a lot of JSON and suddenly because it's asynchronous it has limits in terms of how much it can communicate if you were trying to update things frequently or send a lot of data through that bridge you would block that, and what we would call that is that the JS thread is blocked, and so your app would basically drop in its frame rate, the CPU usage would spike, and everyone would be unhappy, and your users would be like, Hmm, this is not quite native feeling to me. [00:03:30]

But, as of now, there's been a lot of work that's been done. React Native has a bunch of different stuff that I'm not going to go into too much detail about. But the bridge has been replaced with what we call the JavaScript interface. And so what that means is JavaScript code can get a reference to a C object that communicates with a native layer, and it can directly invoke methods within that C layer that would live on the native layer. [00:03:51]

So it removes the bridge and it's just direct communication via JavaScript interface to the native layer. So that makes things significantly more efficient. It's not just that, the new architecture is a lot of different parts. There's the new event loop, there's the new renderer and then there's the new native module system, and of course the JSI, which is kind of underpinning all of that. [00:04:11]

the article that you shared in the chat has a lot of details and it's a good summary, so I would start from there if you've been kind of under the rocks. In the React Native ecosystem and not,really hearing much about the new architecture. I think it's a really good summary about why it matters, what you can achieve. [00:04:25]

And ultimately, I think one of the biggest things is that it's giving you parody with React behaviors, because a lot of things that were in React before just didn't work in React Native properly and people were figuring that out on usage. Basically, it wasn't really documented very well anywhere. very exciting times. [00:04:40]

it's finally happened. [00:04:42]

Carl: Yeah, I feel like this is an update that's a little easy to be, you know, under a rock on. If it's been in progress for literally five years now, I could see how that might slip into the back of your mind as something like, There's a lot of things I waited five years for, and by about the third or fourth year, I started wondering if it was ever going to actually happen. [00:05:01]

Mo: exactly, and you know, it's one of those things where yeah, it's been happening for five years, but you do get new architecture talks every conference that's a React Native conference or like React Native adjacent. So it's been the topic of conversation and everyone's like, Oh, that'll probably come at some point. [00:05:15]

And it feels quite surreal to have it actually here. [00:05:18]

BlueSky and Expensify

Carl: Cool. I saw a post from Software Mansion, which is a React Native focused, consultancy as far as I know, talking about bringing the new architecture into the Expensify app, and I understand that the Blue Sky native app is doing a release candidate for it that's like, opt in, and they say it's, you know, it's a release candidate, it's unsupported, try it at your own risk, please report bugs. [00:05:41]

But like, those are real apps, like Expensify is widely used enterprise app. So that's some real usage. That's pretty cool. [00:05:48]

Mo: props to the meta team, they actually spent a lot of time with real apps that are large scale apps that, you know, were popularly React Native. They approached the developers of those apps and said, Hey, can you turn on the new architecture before we release and make sure that it's working and behaving and functioning in a way that doesn't really have regressions and is actually better than it was before. [00:06:06]

So they've really tested this out and drawn it out. They've worked with library maintainers one on one to get them on to the new architecture boat. So, this is as good as it ever will get in terms of just biting the bullet and releasing. [00:06:19]

Carl: Nice. Yeah. [00:06:22]

React Compiler Beta

Mark: The first one is that the React compiler is now in beta. The first, you know, early adopter, I guess, releases came out at React Conf back in May. And it's now in beta you can actually meaningfully try it out, they've done a lot of work to try to improve the behavior against real world applications. [00:06:42]

Along with that, there's a couple different ESLint plugins the Rules of React Hooks plugin has been updated, and it's got some additional checks for whether things are actually components. Along with that, the compiler has its own associated plugin that tries to check for the rules of React behavior. [00:07:02]

You know, basically, are you doing anything that is considered illegal, even if it technically runs inside of your React component? And so they're highly recommending that people start trying to use the rules of React plugin in your applications to find places where you're doing things that you're really not supposed to in React. [00:07:23]

React DevTools v6

Mark: Along with that, there's a new React DevTools extension release. They did a lot of shuffling around of the internals, but what is probably most relevant here is that the DevTools now actually have support for showing server components in the tree. And this is a big deal, because up until now there really hadn't been any way to atsee what server components were actually, being used when you were looking at the code on the client side. [00:07:47]

So that's a pretty distinct improvement there. [00:07:50]

Zustand v5

Mark: Flipping away from that over into state management, Zustan just came out with version 5, and it doesn't have any new features, but it does drop some, legacy backwards compatibility changes, default exports, a couple other things, and it now requires React 18. [00:08:08]

So if you're using Zustan, you may want to look at picking that up. [00:08:11]

Carl: Yeah. Hang on. The Redux guy talking about another state management library. Hold up. [00:08:15]

Mark: I'm allowed to. ( laughter) [00:08:17]

Carl: For sure . [00:08:17]

eslint-plugin-react-hooks v5

Carl: There's also a new major version of the ESLint plugin for React Hooks. Looks like it supports ESLint v9, and it doesn't look like there's a lot of changes, I think it's mostly just compatibility for latest versions. But, they did change how the rule works for component names. [00:08:33]

So now, previously it used to require a non lowercase letter. So it'll let you do things like an underscore in front, and now it doesn't. Now it has to be an uppercase letter. they kind of flipped the bit on that. [00:08:44]

Mark: Picky, picky. [00:08:45]

Carl: Cool. [00:08:45]

Announcing Deno 2

/r/bun: Deno 2 vs Bun? What are your thoughts? /r/deno: Deno 2 vs Bun? What are your thoughts?

Carl: Deno released version 2 as well. We've covered Deno sporadically over the last couple of episodes, but the highlights here that they shout out are backwards compatibility with Node. [00:08:56]

js and NPM, native support for the package. json and Node modules. I guess that's part of backwards compatibility. More package management, I know, you know, the original idea behind Deno dependencies was just like a little bit more URL based and kind of free for all like no registry just like install code very like go Inspired and I guess they're walking that back pretty hard. [00:09:21]

Mark: they've walked [00:09:22]

back a lot of things around NPM compatibility. [00:09:25]

Carl: Yes, I feel like they started out heavily opinionated and are walking back a lot of those opinions, which okay I mean, I guess fair enough. They did also do a lot of work on the standard library and things So it could well be that some of those opinions were just like this is less work. [00:09:40]

We're gonna launch it they've got a standard library Support for private NPM registries. Yeah, a lot of these things are just kind of like details on backwards compatibility with node and NPM they're doing LTS releases. They've got their own JSR, JavaScript, something registry. [00:09:57]

And there were a couple of threads that I wanted to shout out of exact same title posted in the Bun and Dino subreddits, Dino2 vs Bun. What are your thoughts? I won't summarize them. It's just like a bunch of Reddit commenters, you can see, see the two, the two camps reacting to the news, [00:10:14]

Tauri 2.0

Mark: The Tari framework, which lets you build desktop apps using web technologies as an alternative to Electron just came out with version two. They have some improvements around HMAR and plugins and various other internal improvements. If you're building desktop apps, probably worth taking a look. [00:10:32]

Carl: Yeah, I thought it was neat that they added a permissions model. I guess they used to have like an allow list of things that your app was allowed to do. And they talked a little bit about enhancing that with, you know, a permissions model, which seems like a good improvement. Yeah, they also mentioned mobile support, which was like, what? I feel like they buried the lead on that. It's like, I want to know a lot more about that. I feel like Rust based native app framework where you can use React on Android and iOS. Like, huh, I want to know a lot more about that, but they didn't say too much in the announcements. [00:11:04]

Mo: Yeah, it's, as with all things with thisso it's not official yet with Taure. I think they're just kind of working on it, so I,suspect they're kind of saying, hey, we're working on it. The general gist with all of these Electron like frameworks it ultimately ends upbeing something like Cordova with Ionic. [00:11:22]

it's a web view that triggers some native functionality. It won't be a truly native app, which is, I guess, one of the distinguishing factors of React Native. But it'd be very interesting to see how they play this out. And how it works in practice. It might be something a bit different, but they're being very cryptic about it so far. [00:11:38]

So, remains to be seen. [00:11:40]

One the new RN framework

Creators of Tamagui

Built on ZeroSync

Mo: Moving on. So, earlier this year the React Native Core team came up with this big announcement saying, Hey, we think you should use frameworks. And not build your own frameworks every time you initialize a new React Native app. And so at that point they introduced Expo as the only option to, as a pre built framework. [00:11:57]

They said, you know, you're either using Expo, or you've built your own framework by building on top of the core of React Native. And so now we have finally gotten a second framework that's come in and said, Hey, I I'm a contender for that spot as well. the framework is called one. I'm not too sure why there's, that's the naming, but, there we are. [00:12:16]

You have a theory. All right. [00:12:17]

Carl: so it looks like they're built on a sync engine that's called Zero. ZeroSync. so I guess this is, you know, they're built on Zero so they are one. [00:12:26]

Mo: Cool. So, this is an interesting development because the person who's behind this is behind the library called Tamagui. So Tamagui is a styling library within the React Native Ecosystem. the whole spiel with Tamagui is that it's an optimized view layer library that you can use not just for your React Native apps, but also in things like Next. [00:12:46]

js. So you can kind of share your UI across the board between React Native and the web. it's used to build these universal apps. Tamagui is quite an interesting project. It's actually a very heavyweight library, because it comes with things like a styling solution, a compiler that, does view flattening. [00:13:05]

Next. js optimizations out of the hood. it's a very heavy styling solution when you're using it just for React Native, and it's notoriously complicated as well. they've taken Tamagui, paired it with a whole bunch of other stuff, like a file system routing based solution, and the most interesting part, I'd say arguably, is the fact that this is beat based.previous to this, you couldn't use Vite for React Native because you'd have to use either Metro or in some cases you could use Webpack, but it was quite a pain to actually get that working. the creator of this, Nate, has been working on seeing if Vite can become a compiler for React Native. [00:13:42]

React Native, and it seems like there's some good movement on this. So, it uses Veep by default to kind of standardize the bundler across web and mobile. So, it's a very interesting proposition and they have a lot of experience but it's still going to be interesting to see how this plays out. [00:13:58]

It's very early days. So, I would Tread with caution until it's reached some point of stability and it's being used. But it's very interesting to see how it's forming. [00:14:09]

Carl: Yeah, definitely early days, but like, I'm taking this reasonably seriously. It seems like a pretty clever and opinionated take on how to do a framework on React Native. I guess, you know, like, my rough mental model for this this feels to me like the React Native equivalent for Remix. [00:14:28]

in large part because it's beat based, you know, okay. [00:14:31]

Mo: but it has a lot of, like, very similar ideas, right? Like, they've kind of introduced this concept of loaders as well. it's very Remix esque. so I can see why you take that comparison. [00:14:42]

Carl: another thing that I find fascinating here is they put local first and sync engine very heavy in their homepage marketing for this. they talk a lot about this being built on zero sync, which is built by a company that I've heard of and that the CEO follows me on Twitter. [00:14:57]

I think that's cool. it's being built by a team that worked at a decentralized exchange that I had heard of. Six years ago. So they worked on decentralized tech that I took seriously as someone I also worked in decentralized tech six years ago. So I think it's really interesting that that's the Opinion they're bringing to this company that they named that they worked at Uniswap I viewed as one of the serious contenders in web 3 before it became overtaken by scams So it looks like they have now moved out of Web3, taken that decentralized technology experience, and are building a React Native framework that is based around local first, you know, data on your device, primarily synced to a backend. [00:15:40]

And I think that's really cool. I am pretty bullish on local first generally, I'm very curious to see how this works. Early days, like you said, it's interesting to me. I am intrigued. [00:15:51]

Mo: and Uniswap is built with Tamagui. So the web and the mobile app is built with Tamagui which kind of is a real implementation, real world production app that's using the universal app paradigm. they know how to do it. It's just a matter of how, easy to use it is for other developers who aren't that familiar with this sort of framework or this [00:16:10]

Carl: it's Yeah, right. It's easy to say how powerful and useful something is when you are the person who made it. [00:16:15]

Cloudflare Workers updates

Carl: Cloudflare Workers released a bunch of new updates, and a lot of them look really cool to me. So I'm using Cloudflare Workers a little bit in like, a side project or two. [00:16:24]

I would like to use it more for ReactiFlux projects, but actually Discord does not allow the gateway to connect to like, the Cloudflare Workers durable objects. For some reason, I don't know why, that seems weird. than the fact that you just can't connect to the API, they seem like a really powerful way to interact with Discord. [00:16:43]

So, I would love to use them for that. Sadly, I can't. ButI think Cloudflare released, yeah, 18 big updates to the workers platform is the headline here. Literally the title of release. Something that I found really interesting is they are advertising CICD with PR preview releases for workers. [00:17:01]

I think that's not going to be quite as like turnkey, instantly useful as it is in like Netlify or you know, Vercel where, you know, like, you get a PR preview on your website, you just get a new domain, boom, done, everything kind of works. Assuming you didn't like actively screw something up and how you are doing, you know, base URLs. [00:17:22]

I think for a backend service like this, it's just not going to be quite so simple and like zero effort to take advantage of PR previews. Like you, you need to have a staging environment where you can be notified of a new URL being available and then dynamically swap out the, like, base route for this. [00:17:39]

And then like other stuff, like what about. Seeding test data and things like that. So I don't think this is quite so like Mind blowingly immediately useful as it is on a web deployment CICD, but that's still super cool Like that's you know, like for it for a discord bot, which is mostly where I've tried to use these like that's still pretty Accessible. [00:18:00]

Yeah, so I think that's pretty pretty useful some other smaller stuff Logging on the dashboard for your workers. I have run into issues with like Observability was not easy before this, so I have actually already enabled logging on the dashboard in one of my projects because I needed it, and I was like, oh, cool, great, now I can just do it's not effort. [00:18:17]

Better Node. js compatibility, they have, because it's a serverless runtime, they don't have stuff, like FS or HTTP or things like that. It was a little bit more Sandbox, like, Request Lifetime, they give you the entire environment in the request handler. So, when they say greater Node. [00:18:35]

js compatibility, I'm not quite sure how to interpret that. The, they had like a compatibility chart, and it included like 100 percent on, you know, NodeFS. But like, I don't know what that means when you don't have a file system, you know. I don't think they are actually emulating a file system where you can read and write. [00:18:52]

Maybe they are, I don't think they are. [00:18:54]

Mo: [00:18:54]

they're slowly going through the list of Node APIs, And I think they support like only 50 percent of them. So they still don't support like file system in any capacity, just because it doesn't make sense for the runtimes they have, because our workers kind of just run in a V8 isolate. [00:19:11]

just running somewhere on their edge network [00:19:13]

Carl: That's what confused me though, because the compatibility thing said 100 percent coverage for FS. And so it's like, I know you don't support this because of the environment, what does that mean? I don't know how to interpret this chart. [00:19:24]

Mo: yeah, I think some of them are probably just weird polyfills or just like shimmed values. I'm [00:19:30]

Carl: Yeah, I mean, I guess even like, doesn't immediately explode is an improvement, you [00:19:36]

Mo: Is it an improvement yet? [00:19:38]

Carl: Which is where it's been for me, like, oh my god, there were some weird things that happened when I was trying to develop that. Like, CommonJS imports and things, yeah, so, yeah, I have to play around with that a little bit more. [00:19:48]

Yeah, they also have Next. js support. via open next, which they've open sourced. So like, cool, here's an open source runtime that they are using themselves in production to provide next support. And like, that's enormous. I think I saw when this was announced Vercel, some of the big Vercel DevRel folks who are active on Twitter seemed a little bit like they were nervous. [00:20:12]

Mo: I've used Cloudflare Workers quite a lot recently, and they had some, like, Next. js support, limited. They've been increasing it for the past few years. They started off with just, like, you can static export Next sites. Great. You can do that with anywhere and host it anywhere. Right? Then it was like, we'll support some limited sub features of Next. [00:20:28]

And I think they're now supporting it almost fully with the OpenNext runtime. And I can see why some of the Vercel folks would be a little bit on edge, because if you support Next to that degree, yes, Vercel has a lot of nice DevEx features, but when you look at the cost for a large scale site, and where Vercel would make a lot of their money you can get the majority of those functionalities, or like 80 percent of those functionalities on CloudFlare pages. [00:20:52]

it kind of works similarly. You get those preview branches and all of that. So I can see why they'd be a little bit anxious about that, but I suspect they'll do what Vercel usually does, which is introduce a new, like, runtime dependency, and then it'll take everyone six months to basically get on the same compatibility. [00:21:11]

So we'll see. [00:21:12]

Carl: They'll just dig that moat a little bit deeper, maybe. Yeah, they also have per worker SQLite, which is neat. Previously, I guess it had only been, like key value store based, so it was kind of like having local storage available per worker, which is great, but, you know, you can't query it.you can't really do structured data in a situation like that. As well as blue green deployments, incremental rollouts. And queues, and a vector database, performance improvements, like, you know, one of the performance improvements is faster time to first token on their AI, platform. [00:21:41]

like you were saying, Mo, about Vercel getting maybe a little nervous aboutCloudflare workers with real Next support for things like the dynamic images, some of their, longer tail of server based functionality with PR previews, incremental rollouts, and, a queuing system, like,that starts to sound a lot like the offerings that Vercel offers. [00:22:03]

But yeah, [00:22:05]

Zeego 2.0

Mo: Cool. I'll quickly just give a shout out to version Zgo. So for those of you who aren't familiar, Zgo is a wrapper, it's almost like an abstraction, on top of context menus on both native and web. So again, going in that universal app trend you can use a single API in your code base to create context menus for your web with Radix, and then it'll hook into the native layer context menus on iOS and Android. [00:22:26]

So it's a nice little library to use as a utility when you do want to have context on certain elements of your app. [00:22:32]

Carl: Cool, seems useful. [00:22:33]

Conferences

Carl: Alright I'm gonna fly through some conferences. [00:22:35]

HalfStack London London, UK Nov 13

Carl: Halfstack London is happening in two weeks. November 13th. [00:22:40]

React Native London London, UK Nov 15

Mo: Yes, and another shameless plug React Native London conference, this will be the last announcement before it actually happens in Just over two weeks now. So, this is happening in London, of course on the 14th and 15th of November. Tickets are gonna probably start closing soon, in the next week and a half, roughly, so grab your ticket if you're interested, and there's a discount code with TMIR for this month in React. [00:23:03]

Where you can get 10 percent off. So come along, say hi to me if you're there, shoot me a message if you do plan on attending. We'd love to host you. [00:23:10]

React Summit US New York, USA Nov 18-21

Carl: There's also React Summit in New York November 18th through 21st. [00:23:14]

React Africa Casablanca, Morocco Nov 29

Carl: React Africa in Casablanca, Morocco at the end of the month in November 29th. [00:23:19]

React Day Berlin Berlin, DE Dec 13 & 16

Carl: And React Day Berlin December 13th and 16th. [00:23:23]

Mark: I will be speaking at React Summit. [00:23:25]

Carl: Cool. Yeah, go to React Summit in New York and go meet Mark. I live in New York. [00:23:31]

I will try and make it if I can. [00:23:34]

Carl: So we are exclusively brought to you by Infinite Red. That's very tongue in cheek, but yes, they are our only sponsor right now. Infinite Red is an expert React Native consultancy. They've been around since 2015 uh, and are owned by Jim and Holmgren. [00:23:47]

Todd Wirth and Gant Laborde. They've been super active in the community for literally my entire career. I got my start like professionally with React around 2014 or so. So like, I have been aware of them for a really long time. And yeah, I connected with them in a conference and just great vibes. So good. [00:24:04]

They only do React Native and have built over 75 apps for companies from startups to like huge enterprises. And just like, other than being good people who do a lot of good things for the React and React Native ecosystemsthey seem to be very good to their people because they, like their average tenure of employees at their company is more than seven years. [00:24:23]

Which is wild to me. That's double the tenure I've ever spent at one company. So that seems great. They are not a like feature factory. They work alongside your developers at your company and help you develop your own expertise there. So if you are spinning up a new product with React Native and want some help hitting the ground running, definitely give them a ring. [00:24:41]

And uh, you do let them know that you heard about them from us. Not that we get anything out of it. Just, you know, Maybe help us in the next contract negotiations. He he he. [00:24:48]

Main Content

Carl: Into our main content though. [00:24:50]

Some React 19 progress, but no ETA

Lazy Context Propagation

Mark: So we've been attempting to track the progress of React 19 and there were a couple of progress that I saw happening in the last month or so. The. Big thing is that we're still waiting for them to finish work on the changes related to the parallel suspense rendering behavior that caused an outcry earlier this year. [00:25:13]

And I saw a couple PRs from Andrew get merged. I later saw one of them get reverted. And then, just in the last week or so, I think I saw one of them get unreverted or a feature flag get landed around that. So, there is work going on, I have no evidence to say how much more work is needed to be done. I also think I saw someone from the React team, possibly Sophie, mention that they're hoping to get it out by the end of the year, but, you know, nothing concrete either way. [00:25:46]

So, stuff's happening, stand by, and wait. It's all we can do. [00:25:51]

“Server Actions” renamed to “Server Functions”

Carl: Hurry up and wait. Yeah. And I guess one concrete change that has happened is server actions have been renamed to server functions, which I don't know, I guess that seems good. There's a lot of things in the ecosystem that were called actions. So one less thing called action seems good. [00:26:07]

Mark: Probably. [00:26:08]

React Native Bottom Tabs library using native bottom tabs

Mo: Cool. So, the next update is that there's this library called react native bottom tabs that's made by one of the developers at Callstack, Oskar Kwaszynewski. Who I've known for a little while. And This is quite an interesting development. Because The current library that you use for navigation within React Native Is called React Navigation. [00:26:28]

And React Navigation has bottom tabs within it. But they're not fully native backed bottom tabs. And so it means when there's updates Or specific Styling applied to certain platforms Let's say onLet's say on iOS Where if you're on like tvOS, the tabs go on the top. And if you're on tablet, you can have them as like a sidebar. [00:26:47]

But on mobile, they kind of just look like a normal tab bar. Those changes wouldn't be reflected because they were just basically JavaScript views that were customized. And so the whole purpose of React Native bottom tabs is to create native based navigationOn React Native apps using a JavaScript API. [00:27:05]

So this will hook into the native layer and it'll look and be styled as a native layer bottom tab, which is quite cool. And a lot of work's being placed into it. One of the things that I've been thinking about with this is could this possibly be introduced and upstreamed into React Navigation because It's a really good alternative. [00:27:27]

So in React Navigation, we've got native stack navigators, which is the stack navigator that you can use. And it uses the native functionality for the stacks. This could also be introduced as some sort of native tab navigator. So still to be seen, but quite interesting as an update. [00:27:45]

Meta Connect showcasing new AR/VR apps built with RN

Mo: Cool. Next up, we have MetaConnect happening, and there was a whole bunch of AR VR showcases, which was cool. Obviously, Mark Zuckerberg went on stage and showed off the Orion headsets, which are not really going on sale, but they're kind of showing the future of where Meta wants to go, which I'm personally quite excited about, I really like AR, I hate massive VR goggles, but I really like the form factor of the uh, Google Glass. [00:28:09]

And I was quite gutted that Google Glass was, was basically chopped. I think it was just a bit too early for its time. But, on the side of that demo there some sort of, like, engineering blogs that were released. And they showcased at the event the Instagram and Facebook apps for the new MetaQuest. [00:28:25]

interestingly despite Instagram being a native application and despite you know, parts of the Facebook app also being backed by native the Instagram and Facebook apps for the MetaQuest have been rebuilt with React Native, which is quite a big step forward. win for the React Native ecosystem because it's being used on more and more platforms and powering more of Meta's apps that is part of the core business. [00:28:50]

So this was quite cool to hear and they've built some incredible apps. Like if you, if you look at the demos, there's really swift animations there. Everything looks really buttery smooth and looks really nice. So, it's a really cool showcase of, what they've been able to achieve by rebuilding some of this stuff in React Native. [00:29:06]

Cool. [00:29:07]

Static Hermes Updates

Mo: Just a quick update on Static Hermes. Not much is happening here. There's a lot of discussions around like how compatible it would be and you know, what challenges it would introduce with the existing ecosystem. Svetlan Mikhov, who's one of the people behind Static Hermes and who first introduced it last year at React Native EU actually talked about some of the limitations that they were facing trying to take Static Hermes to production with the wider ecosystem. [00:29:30]

A few people have been playing around giving him some feedback. He's been going on long threads on Twitter explaining some of the details of the implementation, especially with assembly code. So he's been like pasting assembly code in Twitter threads which is quite interesting and he's been styling them like, he's been going through a lot of effort to try to really like explain to the community, which is props to him. [00:29:48]

But Evan Bacon, as Evan Bacon does came up with a demo of using Static Hermes with Expo dev clients on iOS. So Software Mansion's been working on some stuff around trying to take Static Hermes to production, and Evan Bacon's been trying to see if he can find a way to make it work with a basic Expo app. [00:30:07]

There's still some limitations it's not anywhere near production ready, but it's just, things are being done in that space, which is quite cool to see. [00:30:14]

Carl: Yeah. Super cool. Nice. [00:30:16]

Anyone else feel burnt by Epic React? : r/reactjs

Carl: This is maybe a little bit of a small note, but I think we've plugged it before. So I wanted include some follow up from the ecosystem. Folks on Reddit have been sharing about feeling burnt by Epic React, which is Kent C. Dodd's React course. I empathize. I get it. Their criticisms are pretty legit. [00:30:34]

Some of them are legit. Some of them feel like, you know, reddit commenters having strong opinions about how the world works, which are not necessarily based in economic realities. [00:30:42]

Epic React V1 => V2 Upgrade & Deception.

Carl: Butsome of the complaints that seemed a little more legit to me were, like, people who had bought the, version one, the old version a couple of years ago, were upset about having to pay almost full price to get the upgrade. [00:30:54]

Marker

Carl: And on the one hand, like, if you bought a course and you learned the course, why do you need to buy it again? I can understand wanting it. And I guess I can understand, like, wanting to, I don't know, it feels a little bit like folks, Feels a little entitled. Feels a little bit like wanting stuff for free. [00:31:13]

Like I don't know, he put in a lot of effort to update it. I think the previous version came out like four years ago and that's a long time. A lot of things have changed and been updated and the ecosystem has moved on a lot. So I don't know that it is a reasonable expectation to get a brand new course for free or for extremely cheap just because you paid for it a couple of years ago. [00:31:37]

If you paid for a course that is intended to like help you kickstart a career using the technology, I don't know that you should necessarily need to buy another course targeting people who are trying to kickstart careers in the industry several years later. If you do, like, maybe you didn't take full advantage of the first course. [00:31:55]

I don't know. So I empathize with that. People were also criticizing the cost of it as being very expensive. It is like, you know, it's several hundred dollars. Like, I think full price for it is like 700. [00:32:05]

Mark: my train of thought on that one is that Kent is entitled, it's a free market, Kent is entitled to put whatever price on, you know, something he's selling, and you are free to ignore it if you don't feel like it's going to be useful or provide enough value. there were maybe some comments about, like, folks not liking his teaching style. [00:32:24]

That's more of a valid concern, but if you don't want to pay that much money for his course, if you feel like a 20 Udemy course is better, then go pay 20 for that course and move on. [00:32:36]

Mo: Yeah, I'm inclined to agree as well with Mark there. It's just, you do your research before you purchase something. I think he's abundantly popular where you can watch some videos online of Kent. See if you like his teaching style, if you don't like his teaching style, and then make an informed choice as to whether or not you want to spend several hundred dollars for it. [00:32:53]

I think trying to argue after the fact to say, hey, this wasn't great, it wasn't worth the price, well, cool, but, you know, leave a review for it, I guess, and move on. It's, a free market with this type of thing. Yeah. [00:33:04]

Carl: what? Like, I dropped out of college after a year. Each of those college credits was like 1, 500, 15 years ago. So I feel like I would have gotten much more value out of a course like this than I did out of any individual college course that I took. I don't know, I left that comment on Reddit and they did not find it compelling or I got a negative score. But that's my opinion on it. Like, education, in general, costs so much money. And the value to Cost for something like this to me seems pretty clearly at least worth trying I don't know if you're going for it Yeah, and in the comments to joshwcomo has a course out as well. [00:33:47]

Also seems really great Also a pretty similar price point, like curated education material from an industry leading expert. You don't get that for free. It's a lot of effort. It's hard to be an industry leading expert. It's hard to design a course syllabus. It's hard to produce that content. [00:34:03]

It's hard to distribute it. It's hard to, yeah. So I don't know. It's,they're doing it all on their own. These are independent educators in general. Like they are doing their own thing on their own time. Yeah. [00:34:15]

Mark: And, I mean, just, just as a related point, so I did all that work in the first half of this year to update the Redux Essentials tutorial in the Redux docs, which I did all that work for free, and I'm not charging any money for it. And, for the first time I actually tried tracking my hours. And I put in 80 hours of actual focused time, which on the one hand feels like it's not much, you know, like my first instinct is, well, that's only two weeks of work. [00:34:44]

On the other hand, let's face it, across a typical two week period, I don't actually put in 80 hours of focused effort in my day job. you're in your seat for eight hours, maybe, but you're getting maybe four or five hours of productivity tops. And like, that was, quote, just building off of an existing tutorial where I'd written the content and written the example app. [00:35:05]

I wasn't coming up with that stuff from scratch. I was converting it to TypeScript, figuring out how to add a couple new features to teach a couple new ideas and then, you know, doing the work to get the right commit sequence, and then turning that into code. Updated content. So, I mean, it was effort, but like, I wasn't doing all this stuff from scratch and that still took me like multiple weeks worth of focused time that I did for free. [00:35:33]

And so, I got a sense of the amount of work Kent was putting into version two of his course and like he was significantly revamping things. [00:35:42]

Mo: there's a comment in the Reddit thread, which I actually agree with quite a lot and I think it's the right approach with this, which is The person says, well, it is expensive and you can go through YouTube and find each of those topics and find like a tutorial video on them for free on YouTube. [00:36:00]

But if you have the money, what you're basically paying for is someone to curate that content for you. Summarize it, create a syllabus for you, and give it to you on a silver platter, right? instead of searching for that material, you're paying for that person's time to curate that material for you. [00:36:15]

The information is there for free, but you are paying for Kent's time and organization to come in and create something valuable for you so that you don't have to spend the time searching. So if you got the money for it, great, go for it. There's someone else in the chat as well that mentioned, which I think is a good point to put it into perspectivea lot of companies will let you expense stuff like this on like a training budget or, an upscaling budget that they have. [00:36:36]

So when someone like probably prices something at several hundred dollars, I don't think he's expecting indies to come in and all shell out several hundred dollars. I suspect the goal is to find like a midpoint price point where it's. Expensive for indies, but quite cheap for corporates to pay for a large number of licenses. [00:36:58]

And he does have a option to select multiple licenses and buy for your team. So I think that's probably where the pricing is coming into place. [00:37:05]

Mark: Yeah, sort of the training equivalent of targeting the enterprise market. [00:37:09]

Mo: Exactly. [00:37:09]

Mark: moving along touching on some drama. [00:37:12]

Web Components Are Not the Future

Followup to this from March 2020: Maybe Web Components are not the Future?

Mark: I think we might have mentioned some previous bits of the web components versus React thing that's been going on the last couple months. This started with a post from Ryan Carniato, the author of the Solid Framework. Where he said that Web Components aren't the future. [00:37:27]

And that spawned a whole lot of discussion after that. A lot of folks from the Web Components community were upset. [00:37:34]

Web Components Are Not the Future — They’re the Present

Mark: Someone wrote a post called, Web Components are not the future, they're the present. Which made a bunch of arguments, both technical and sociological, about how Web Components should be fitting in. [00:37:46]

Lots of debate in Twitter threads, Mastodon threads. I'm not on Blue Sky, but I bet there was probably some debate over there, too. [00:37:53]

Liskov's Gun: The parallel evolution of React and Web Components

Mark: there was one other article that really stuck out to me called the Parallel Evolution of React and Web Components. It's stupidly long, even by my standards. [00:38:01]

It's 11, 000 words. It's a very long read, and I had mixed thoughts on it. I thought the first third of this was a really good technical discussion about, Some of the web component's early specs came out even before React did. Both of them have evolved over time. The middle third devolves into the author kind of bashing on React for a while, and then it kind of finishes up with some more decent thoughts about technical aspects and how they fit into web application architectures. [00:38:31]

I'm not gonna suggest that everyone should read it, but there was some interesting background material, and at least the author put in actual time Writing this post as opposed to just, you know, random bashing of things purely on Twitter if you want to see some of the web components discussion that stuff's out there [00:38:48]

Carl: my understanding is that one of the biggest problems of web components, I've never used them, I understand them to be in, you know, Intended to be used as like leaf nodes, kind of like your, your design system. Like if you are going to build a design system in React, I think that web components advocates would say, no, no, no, don't build those components with React, build them with web components. [00:39:10]

And then you can use them in many, many places and many frameworks and yada, yada. My understanding is that web components have many of the same problems as trying to build your own design systems, where the hardest part is things like versioning. And if you don't get it exactly right the first time, it's kind of difficult to ship new changes to them. [00:39:29]

So it sounds like web components are still hit a lot of the same problems. They just kind of shift the context. And so you have to figure out like, when you're doing a design system in React, The problem is around versioning and like packaging. Like, do you do many sub libraries? Like, do you make your own like React modal component and your own tool tips and your own buttons and your own accordion tabs, whatever, or do you do one big bulk package? [00:39:54]

But then it's like, you end up with these like, well, okay. If you ship a change to this. Low level component used within this design system, like, how do you migrate all of the clients that are using that design system without doing like a big bang rewrite across dozens of clients? [00:40:11]

And like, that's hard. It's not trivial and it sounds like web components have that same problem But instead of versioning happening through semver in npm, it happens in this entirely bespoke Web component standard system and like that doesn't seem better to me. It's like you have to learn a whole new, Context, as well as dealing with the same problem. [00:40:32]

So, like, I haven't seen that discussed at all in any of these, you know, discussions. These, you know, when people are talking about the technical merits of Web Components, I'm not seeing, like, and here's why it works better for this reason. I also just really, like, the Web Components are not the future, they're the present article. man, I did not like it. I thought it was good. So, this is not a compelling argument. Like, you know, a quote from it that I pulled was like, they're not solid components, they're not React components, they're not Svelte components, they're not Vue components, they're standards based web components that work in all of the above. [00:41:04]

And that seems like a big assertion to make when the maintainers of solid, React, Svelte, and Vue are all saying, they don't work for us. So, I feel like you can't just say, they work in all of those, when the maintainers of those frameworks are saying, they don't work. And it doesn't really argue why they work, it just kind of asserts that they do. [00:41:21]

Mark: it's a little bit like a lot of the React arguments that were happening earlier this year, where there's like 30 different partially overlapping topics. And people are arguing about a different subset of them. [00:41:33]

So, in this case, the concerns are technological, some of them are ideological. Folks who prefer web components or advocate for web components tend to be the kind of people who like frameworks. They feel that frameworks are too heavy, they feel that frameworks have bad results on the industry, they prefer to, you know, kind of stay closer to the browser, you know, they use the platform mentality, and so they see large frameworks as sort of the enemy, and so anyone who is using a framework is kind of a bad person. a lot of the vocalness here is coming from these people who's like, it's a standard,therefore it's better.These frameworks aren't standards. I don't see a lot of people in the React ecosystem, like, actively advocating against web components. more of a, whatever, we don't care.So, worth noting that, you know, Ryan's article, came from his perspective more as a framework author, and similarly, Rich Harris, the author of Svelte had a number of complaint threads on Twitter recently, where he was talking about there's a bunch of really, really weird behaviors in browsers that only exist because the web component specs demand those, and that has caused problems for him as a framework author. [00:42:58]

Things like, Cloning domnodes requiring you to pass in an additional flag, but that makes the cloning process 30 percent slower, [00:43:08]

Carl: Right. And in contrast to that, the present article says, towards the back half of it, it says, I'm not a conspiracy theorist, but I find interesting the number of people who are and have been sponsored and or hired by for profit companies whose platform rely heavily on said frameworks. [00:43:25]

So it's like, I feel like the web components aren't working for us. Framework authors are making arguments like that. I'm taking a 30 percent performance hit because of the spec requirements to support these. Like that's a very precise technical argument. Not, I'm not a conspiracy theorist, but [00:43:42]

Mo: [00:43:42]

that sounds like, here's my friend's opinion about these guys. They're awful people. Not my opinion. I'm just quoting what my friends, I'm not a conspiracy theorist. That sounds pretty conspiracy theorist to me. [00:43:52]

Carl: Yeah. It's big, just asking questions energy. we should move on though. I think Mo, you said you have to duck out. [00:43:57]

Mo: I do have to leave, so I guess I can just say goodbye hereand hopefully see you all next month. So it's been a pleasure in all things react and react native and I'll see you all in the next one. [00:44:08]

Mark: we've got a bunch more stuff to get through, [00:44:10]

Announcing VoidZero Next Generation Toolchain for JavaScript

Mark: Evan Yu, the author of View and Veet and a number of other things, Has announced a venture backed company called VoidZero, which is quote working on the next generation of JavaScript tooling This might sound a little bit familiar. [00:44:24]

That was sort of the pitch behind the Roam tool set So in this case some of the things that VoidZero is working on correlate a lot with Things that were already in progress with the VEET framework. [00:44:37]

Oxc Transformer Alpha

OXC compiler

Mark: There's a Rust based JavaScript compiler called OXC, which also includes a linter and reusable parsers and things like that. [00:44:46]

So I believe that's now gonna be sponsored under Void0. There's a project called Rolldown, which is going to be a Rust based re implementation of the Rollup build toolset. So eventually the goal is to really make Vite a whole lot faster, ultimately. Vite currently uses a mixture of, I believe, ESBuild for local dev builds and Rollup for production builds. [00:45:12]

And so they're also trying to make the behavior more standard, or more similar across dev and production as well. [00:45:18]

Carl: Yeah, definitely seems interesting. Always down for stuff to core dev tools to be made faster. All right, cool. [00:45:23]

Updates from the 104th TC39 meeting

Carl: I'll move us on some new TC39 news. They just had a meeting and blog post I saw said four new proposals advanced to stage four and the list had five items in it. [00:45:33]

Promise.try

Carl: so there's promise. try, which is now stage four. It seems neat. It looks like it's basically a likeconvenience so that if you don't know whether a function is going to return a promise or not, you can give it to promise. try and then you can handle any errors that it emits as though it were a promise. [00:45:53]

And the advantage of that is that, you know, if you did something like promise. resolve. then and then execute that function, which would be a great way to achieve this behavior without a change to the language that would process it on the next tick. [00:46:06]

So it doesn't execute synchronously as, you know, line by line. It gets thrown to the event loop and then event loop comes back and executes it. So, you know, that's. Not always what you want. If you are trying not to do that, now you have a new tool to do so, which is promise. try. [00:46:21]

Sync Iterator Helpers

Carl: I also liked the sync iterator helpers. [00:46:23]

I think we mentioned this in a previous episode. Maybe not the last one, maybe the one before. But it's. Basically letting you do stuff like map, filter, reduce on iterable objects without Spreading it into an array first Which I think creates a copy. So like this seems great. You can now map over without the cost of Producing an array from it first. [00:46:47]

I love it. Here for it. [00:46:48]

Import Attributes

Carl: Some other ones that I didn't talk about Think about as hard there's import attributes which I think is like metadata for describing what you're importing, something like that. [00:46:58]

JSON modules

Carl: JSON modules. So you can import JSON files as modules without, you just kind of natively. It seems good. [00:47:05]

RegExp Modifiers

Carl: as well as regex modifiers. couple of new changes, five new things to the language. Seems good. [00:47:11]

Language Evolution “JSSugar” proposal

NullVoxPopuli on X

NullVoxPopuli on X

BrendanEich on X

Daniel Ehrenberg thoughts

Mark: And one other thing that came up at that meeting there was a presentation I think co authored by a number of JavaScript engine implementers at Google and Mozilla and a couple other companies. That is very long and complicated, and it's worth reading through, but as a high level summary, we've had the TC39 process for, like, 15 some years now, and, you know, we had the big bang change to the language with ES2015, and then a steady stream of new language features since then. [00:47:45]

And the expectation is that once TC39 finishes standardizing a given feature, Every JavaScript engine out there. Is going to end up fully implementing this. Now in practice, if it's basically V8 and spider monkey from, you know, from Mozilla, that's the majority of people as far as browsers are concerned, but there are other JS engines out there as well, and implementing all these new language level features takes time and effort, some of these engine implementers were actually saying, you know what, we actually. [00:48:19]

are thinking that maybe we shouldn't be required to implement every feature that is added to the JS language spec. Sometimes these things have performance implications, sometimes these things have actually caused security related concerns, It's not like a full blown proposal, but it's kind of like a what if we considered this kind of a thing. [00:48:42]

what if we sort of split the JavaScript language spec into things that are actually going to be implemented by runtime engines, versus things that are in the spec, and we agree it's part of the language, But would only ever be implemented by transpilers, like Babel or ESBuild or something like that. [00:49:05]

So that, the JS engines don't have to literally implement every finished feature ever. a number of folks felt this was probably a bad idea. I can understand some of the concerns that are being raised by the engine folks. But, splitting the language feels problematic. You know, certainly the folks who are, you know, kind of in on that, like, I don't want to have to use build tools to write my JavaScript are, are not happy about this. [00:49:34]

But, even knowing that, you know, some of these things won't make it into the engines and might not be able to take advantage of, you know, built in optimizations feels kind of sketchy. [00:49:43]

Carl: Yeah, I can definitely understand that though, like so many things, I feel like, I mean there are so many lingering polyfills and transforms and whatever that Babel and all of them are like still implementing, even though they are now part of the language, just because how do you know when it's okay to remove stuff like that? [00:50:03]

I can understand the motivation of saying like, look, this is the reality. We are still transforming this even though technically by the spec, we don't have to. I can definitely understand why they would see, just start saying like, this is a practical reality, pragmatically, this is what's happening. the standardization process should reflect that and acknowledge that some things will just live in the transformer. [00:50:25]

I can definitely understand that argument. But yeah, I guess that's also weird. Like it introduces a new like point of abstraction in the standardization process and like, what is JavaScript? that's weird. [00:50:38]

Mark: Alright, so, now we're in and we haven't started the lightning round. So, let's try to actually make this a [00:50:43]

lightning round, shall we? [00:50:44]

⚡ Lightning round ⚡

The Disappearance of an Internet Domain – .io

Mark: Moving along. So there was an article titled Disappearance of an Internet Domain. the TLDR here is that the io domain is associated with a set of islands in the Indian Ocean owned by Great Britain and Great Britain just signed a treaty to eventually hand those islands over to you. [00:51:05]

I think the island of Mauritania. And so based on international law, there's a chance that once this 3D handover is complete, there is no longer a separate territory. And if there's no longer a separate territory, then there's no legal reason to have a io domain associated with that. And so the article says that, you know, if we, if we've, Assume that these laws and practices get followed strictly, then hypothetically, five years from now, the io top level domain might go away completely. So that's up for grabs, but it's a legitimate concern. [00:51:46]

Carl: The intersection of geopolitics and tech debt seems bad. [00:51:51]

flying through a little bit. [00:51:51]

How to control a React component with the URL

Carl: So I saw a great blog post by Sam Zelikoff called How to Control a React Component with the URL. blog post makes the argument that it's a very common feature request. [00:52:00]

I think that it is not as common a feature request as it should be because it is the power of the web. URL addressability, deep linking, being able to open a URL and have it, represent the same page that somebody else is seeing. So I think that is a phenomenal goal to seek, and so more things should behave that way. [00:52:17]

just a pull quote from it that I think summarizes What makes that hard is the fundamental reason why we're heading down a bad road, he says that we now have two sources of truth for the search text. And that's exactly it, like, when you are writing React, you tend to have your source of truth be something in React state. [00:52:35]

But if it's in the URL state that it exists outside of React's Awareness, you know the universe that you've created for your app that is within react the URL state lives outside of that So it's very easy to accidentally duplicate state then you have a state synchronization problem and I also want to call out that problems like that are a Wonderful example of why dogmatic best practices can really easily lead you to broken apps [00:52:59]

Then if you use a form library, it's going to keep track of its own state. Then you have to do state synchronization between the URL and the form. That's a really easy way to get a lot of bugs. So if you follow the rule of always use a form library, you're going to run into state synchronization bugs if you try to implement this feature. [00:53:16]

If WordPress is to survive, Matt Mullenweg must be removed

Mark: one more drama related item, I'm really gonna TLDR this. The WordPress community is basically blowing up right now. WordPress founder and project company CEO Matt Mullenweg went on a seemingly unprovoked rampage. [00:53:35]

He is basically upset that one of the biggest WordPress hosting companies, quote, isn't giving back enough to the project. And there's all kinds of issues where Matt is both simultaneously the CEO of Automatic, one of the other bigger hosting companies. And the leader of the open source project and the nonprofit foundation. [00:53:58]

And it turns out that in some cases, he's the sole person who controls some of the key websites. There's been issues with him, basically hijacking a plugin that was developed by this other company blocking people from the Slack and all kinds of other Like, he's basically blowing up their community single handedly, and seemingly for no reason. [00:54:22]

And a lot of folks who had been very involved with WordPress are like, I can't be involved with this anymore. So, a lot of WordPress folks are actively looking to stop using WordPress and find something else. There's an extremely long, very well written post that lays out a lot of the details linked in the chat, called, If WordPress is to survive, Matt Mullenweg must be removed. [00:54:45]

It's long, it's complicated, but it's also a very thorough look at everything that's happened. [00:54:50]

Carl: Yeah. Oh man, there's so much to get into. There's so much that could be said about this, but yeah, it's,oh, this has been, this has built its own cottage industry of podcasts and interviews and blog posts. Yeah. It's also not really React. WordPress developer is like an entirely separate thing from web developer. [00:55:06]

So yeah, it's kind of not related to our main topic. [00:55:09]

Web Without Walls — Dan Abramov

Carl: we've had a couple of tangential references to Blue Sky. I love Blue Sky, I think it's really cool, I've been on it for like over a year because Twitter sucks and meh, I have opinions. [00:55:20]

But so Dan Abramov, who I'm sure some of you may have heard of once or twice, gave a really great talk. he's currently working at BlueSky as an app developer which is, I'm actually interested to speak with him a little bit more about that kind of transition because he went from core team, building React to now React consumer and I think that is just such a relatively rare Transition to make and I'd be really curious to hear not just like what he thinks about that transition as someone who's made it But also what Dan Abramov thinks of that as a very clear thinker and clear speaker butwe gave a really great talk about the app protocol, which is the underlying technology that BlueSky is built on top of and it hits a lot of really cool things that I personally have been thinking about for a decade about the future of social media and data portability and federated access. [00:56:14]

not just social graphs, but also to the actual data. I just think it's really cool. Like, I saw some people talking about, like, Oh, it doesn't matter if you have You know, you can always export the social graph because you have your contacts list. And like, that doesn't really matter. [00:56:28]

It doesn't matter if you have the social graph, if you have the connections between the people. If the people are not producing content, you know, if they're not interacting with each other on that platform. And I would boil down this hour long talk that Dan gave that is really good. And I think you should watch if you're interested in social media and building apps on social platforms. [00:56:47]

It really comes down to, like, it's not just an open source Twitter clone. It is an open network that people are publishing Twitter like data to, and no one can close your app off. You know, there is no way for something like the, Twitter X API Shut down, the Reddit API shut down. [00:57:10]

You can't do that because it's built on a federated decentralized protocol. it's not just a proprietary API. So yeah, I think that's really cool. This is a really interesting thing. I think this is going to be a generational shift in how social media operates. So yeah. [00:57:23]

Preact compat discussion

Mark: There was a Reddit discussion thread going and was looking into the compatibility of Preact with, you know, actual React and debating some of the pros, cons, and trade offs. And since Preact has been traditionally pitched as a React compatible library, worth looking at. [00:57:43]

Carl: Yeah. [00:57:44]

Content-visibility in CSS

Using CSS containment

Carl: There's some interesting stuff with CSS containment. It seems pretty, like, wonkish, deep in the weeds stuff to properly understand, but it looks really interesting as, like, a performance optimization for rendering. [00:58:00]

contain CanIUse

Carl: The bulk of it, as I saw in researching it for, you know, an hour and a half, I haven't really used it yet, is there's a contain and a contain visibility, you know, a CSS attribute now, that let you signal more precisely to the browser renderer, how much effort to dedicate to rendering a particular part of the page. [00:58:19]

So, you know, like, how I'm making sense of this is in React, if you're trying to choose whether or not to render something, for a long time the decision has been kind of like, conditional rendering, like, is the DOM in the page at all, or, like, display none. [00:58:34]

And you know, there's a lot of other, like, subtle variations around that, like, should it live in the accessibility tree as well, like, You know, there's a lot of subtle nuances to that. So this adds a lot more subtle nuances. Very exciting. But yeah, so it looks really interesting. It lets you constrain So that's kind of part of it, but it's also a little bit on like sandboxing. Like, I guess the contain element is maybe a little bit more on sandboxing. It's like, if you were to like render an ad into your page, you might be able to do it using this instead of an iframe. [00:59:07]

So, and still maintain the same kind of strong guarantees about how it behaves on the page, how it looks on the page. [00:59:16]

Mark: someone in the chat just said it's like, it's kind of like Shadowroot, and I think that's a little bit, like, along the right lines. Like, you're telling the browser that elements inside here aren't going to have layout interactions with the rest of the page. [00:59:28]

So, like, whereas, a normal element, depending on your CSS, might, interact or overlap or something with other parts of the page, might cause the browser to do, a bunch of additional checks against other DOM nodes to see if they in some way. And so contain tells it, nope, anything under here is scope, you don't have to waste time and effort checking locations versus the rest of the page. [00:59:50]

content-visibility CanIUse

Carl: Yeah, and something else they shout out in the docs about it is, like, really long pages using it to optimize, you know, rendering performance. If you've got a massive, massive amount of HTML, then just saying, like, nope, this is off screen, like, don't render it. If that makes sense they were saying that that would help you maintain performance on a huge page. [01:00:07]

But it also talks about like reducing layout shift. So I wonder if that is actually going to be like practical and useful, or if it just would just be like too weird to have to, I've, I've had to do that kind of performance optimization and. Cracking the size of the content being rendered so that you don't have it, like, you scroll down, something goes out of view and then like gets, stops being rendered and then everything on the page shifts. [01:00:31]

So you have to keep like scroll because what you were looking at just changed. I, I don't know. I don't know if that advertised benefit will actually be real. I don't trust it. [01:00:39]

How I Built My Blog • Josh W. Comeau

Carl: We mentioned Josh W Comeau earlier. He has put out a great blog post. How I built my blog. Looks pretty interesting. [01:00:45]

I, I just always appreciate little technical write ups of things like this. [01:00:49]

Mark: and like, it's more than just the blog. I mean, I think he goes into some details about the developer, the education platform and whatnot. But Josh always puts such care and effort into everything he builds. [01:01:03]

Carl: Yes, a consummate crafts person. So yeah, it's a good write up. He's very thoughtful about how he builds and how he writes. So this is really great. I have also built a large documentation site for a previous employer. And as I was reading this, I just saw so many problems that I remember dealing with in that. [01:01:19]

Like he talks about, you know, authoring content in MDX and the kind of weird errors you get when doing that. He talked about like doing syntax highlighting with Prism and how it can really explode complexity of, you know, just the amount of HTML on a site, which is a problem I had I built this whole thing, put all of this documentation on a single like API reference massively tall site and oops, it's 12 megabytes of just HTML. [01:01:45]

So I ended up having to like totally re architect how the syntax highlighting was happening because just it totally exploded the amount of HTML on the page. so he talked about using, like updating to the latest version of MDX and using Sheeky which is like a server side, Syntax highlighting tool that seemed pretty interesting and definitely sounded like it would have solved some problems. [01:02:04]

I had a couple years ago And he also referenced he's got a like interactive rainbow on the home page And You can edit how it behaves and that behavior gets synchronized across all viewers of the site simultaneously through PartyKit, which is near and dear to my heart. I helped set up their community a couple years ago. [01:02:23]

cool. It's a good read, [01:02:24]

Mark: All right. [01:02:24]

Types of React Components [2024]

Mark: And the final item for today Robin Wierich is another prolific React educator and author of useful tutorial learning blog posts. Thanks. And he put up a post called Types of React Components in 2024. it's actually a bit of a history lesson. It goes back and looks at the old style create class and mixins, the still newer but by now out of date class components, the higher order components pattern, and then the relatively modern function components, server components, and async components. [01:02:58]

So it's not something that's necessarily going to teach you to do things, but it's a useful look at and sort of like the evolution of React over the years. [01:03:06]

Carl: And apparently this is part of a whole series that he's doing updating his most popular blog posts for 2024. generally, I saw a couple of other ones and I wanted to add them, but I, oh god, we already had so many links. So, yeah. Definitely go check those out. he's a great writer. I have been reading his blog for 10 years and he just keeps putting out bangers. [01:03:29]

So yeah, definitely check it out. [01:03:31]

Mark: right. I think we're actually at the end. [01:03:33]

Carl: We are at the end. We've made it. Oh my God. You guys, you're still here with us. Thank you for sticking around for 80 minutes. Thank you so much for joining us. We'll be back on the last Wednesday of next month here at the live stage in Reactiflux or back in your podcast feed just as soon as we can. [01:03:48]

Lennart, [01:03:49]

Mark: Yeah. I got nothing this week other than I am diving into working on some RTK query features, specifically infinite queries, which is a complex thing that I didn't know about and I'm thankful that we're basing it off of how React query works. So My side project for a while. [01:04:08]

Carl: That was fun. Cool. We gather sources from ThisWeekInReact, Bytes. dev, React Status, Next. js Weekly, React. js, Subreddit and here in Reactiflux, mostly from the tech reads and news, If you see anything that you feel like we should talk about feel free to send it to us via email to hello at reactiflux dot com T M I R in the subject line. [01:04:28]

Job market: FRED data, Layoffs.fyi Help them know how smart you are. Alright, see you later.