This Month in React, March 2024: React canary is 19, New ShadCN bits, Astro looks like Wordpress. Wiz??

Transcript from Thursday March 28th, 2024

[00:00:00] Carl Vitullo: Thanks for joining us for March's This Month in React! Coming to you live from Reactiflux, the Discord for React professionals. I'm Carl. I'm a staff product developer and freelance community manager here at Reactiflux.

[00:00:13] Mark Erikson: Hi, I'm Mark Erikson. My day job, I work at Replay. io, where we're building a time traveling debugger for JavaScript, and outside of that, I do Redux stuff.

[00:00:22] Carl Vitullo: We got a lot of good stuff to discuss and digest here. Lot more details coming out for React 19. We got TypeScript 5. 4, and lots of interesting stuff kind of at the margins. Not really core tools or libraries within React necessarily, but a lot of things all over the place.

Layoffs (seems better!)

[00:00:39] Carl Vitullo: I'm going to start off with some layoffs news. At time of recording, you know, it's the 27th, so we'll have to see if anything else happens, but layoffs.fyi is showing 33 companies with layoffs, which is the fewest layoffs by count in that way in close to two years, since April 2022. So nice to see that number go down.

[00:00:58] This month has about 7, 200 laid off so far, which is on the lower end, it's not the lowest of the last year, but it's towards the lower end of the average range. Last March, so one year ago, there were 122 layoffs with about 38, 000 affected. So, 33 layoffs with about 7, 000 affected is a large decline, so that's nice. That's pretty good.

New releases

[00:01:20] On to some new releases. We have a pretty big list this month.

[00:01:23] Carl Vitullo: We've got some news from React Native. They are going to be putting out a 0. 74 release soon. They've had a really cool post up , or I guess like a docs page, talking about their new architecture. Not a ton of super concrete items coming out in there. But they did talk a lot about the general new architecture, re architecting how React Native works. We're going to talk a little bit about some of that, too, later on, talking about React Strict DOM, that package that they released last month.

[00:01:53] Moving on a bit, TypeScript 5. 4, sounds like it's not a huge release, but One thing that I thought was super notable, worth taking note of, they are recommending against using the compiler options paths configuration flag in favor of package. json imports. Since you use the paths for import aliases, moving that out of a TypeScript specific configuration option and into a general module configuration option I think is absolutely phenomenal.

[00:02:23] Getting that standardized I think is going to simplify a lot of things.

[00:02:26] Mark Erikson: It's particularly interesting because I've seen other tools actually start to use TypeScript's own paths option as the source of truth. So, I guess, you know, switching over to a package. json setup is making it more tool agnostic, in a way, but the question as always is, how long will it take for other tools to also support that kind of configuration?

[00:02:47] Carl Vitullo: I am just excited to see something go out from, I don't know, kind of move from TypeScript into standards, but yeah, generally seems like a quieter release.

[00:02:56] NoInfer is one of the biggest things they called out and sounds like it's mostly useful in library contexts. Mark, you did point out something coming up in 5. 5 that looks really interesting though, you want to introduce that?

[00:03:10] Mark Erikson: TypeScript has the idea of, I'm always a little hazy on the terminology, typeguards or predicates, which are functions that take some object and you assert at the type level that if the function returns true, then the type of the value must be this thing.

[00:03:25] And so it's a way to mix together control flow and telling TypeScript what a thing looks like at compile time. And the problem is that when you do an operation like array filtering, that has not actually done the type narrowing that you might expect. So, you might be filtering to ensure that, you know, the returned array only contains real values and removes null or undefined, but TypeScript wouldn't actually pick up on that so far.

[00:03:51] And so you might have to do, like, an extra cast or some other check to make sure that the output array has the correct type. Well, TypeScript 5. 5, which should be out in a few months, actually now has a PR merged that uses TypeScript's existing inference in new ways inside of filter functions so that you can do normal logic when filtering and TypeScript will try to narrow down the returned array type based on the logic in the filter callback.

[00:04:18] It's not a huge deal, but it's gonna be a nice little quality of life thing. And then I also saw a tweet mentioning that the TypeScript team is continuing to do work on the publishing process to try to shrink the install size. I think as of, like, TS 4. 9. Installing TypeScript was around 50 megs. They did a lot of work with TS 5. 0 to change their internal setup, which dropped it to like 30. And it looks like as of 5. 5, it might be down to 20 ish or so. So, you know, hey, smaller install size, always a good thing.

[00:04:50] Carl Vitullo: Much, much later, I'm going to talk a little bit about a Node. js 2023 year in review, and that has the opposite trend. It has a chart in there showing the binary size for the Linux binary for Node. js, and it is much, much larger than it used to be. So, good to see that TypeScript is going the other direction. Maybe they can cancel each other out a little bit.

[00:05:09] I'm just going to run through a bunch of other releases pretty quick.

[00:05:12] Remix released 2. 8. Looks like it's just a bunch of minor changes, configuration stuff.

[00:05:17] Mantine has 7. 7 out. I didn't see any changes in there that really jumped out to me. It looks like a bunch of new components, a couple new hooks. useStateHistory looks neat, undo is always a challenge.

[00:05:29] RSBuild released a version, 0. 5, which they say it's most of a 1. 0 release that will happen approximately in Q3 of this year, but it'll be much, much later this year.

[00:05:40] I saw a cool fringe language inspired by Elm. Gleam, released a version 1. First stable release of a new experimental language. I always need to see how people play around with different languages. It says it's inspired by languages such as Elm, OCaml, and Rust. Experimental languages. Lots of stuff going on there.

ShadCN March 2024 update

[00:05:58] Carl Vitullo: Okay, here's another big one. We've got some ShadCN new updates. They put out a March 2024 update, which is the first time they have done one of these update posts since I think December. So definitely worth calling out. It looks like the single biggest new thing that they have is blocks, they call it.

[00:06:15] Which looks like it's basically template pages for very common and like very low differentiation application pages like a settings UI, or two factor, an authentication page, some other things like that, so it's basically just, copy these out, use it yourself. It looks neat. It looks exactly like every instance of those pages that I've done many times over my career.

[00:06:36] So having a nice copy paste target for that is, seems super helpful. They also had one for an input one time password, like the classic, you know, paste in these six digits and it will appear in nice pretty blocks. Again, something I've implemented many times and there's never any variation, but for some reason you can never use the last one you did, so nice to see that.

Astro 4.5, AstroDB

[00:06:55] Carl Vitullo: One more big one here that I'm just going to kind of blast through because I find it interesting. So Astro, the static site generator, I guess. I don't know if that's quite accurate, but.

[00:07:05] Mark Erikson: Close enough for now.

[00:07:07] Carl Vitullo: They released 4. 5, improved developer experience, a dev audit UI for site performance and accessibility issues, which is cool. They are announcing that they're offering a hosted database in conjunction with their site generation, the site building tool. They're calling it "the database platform for content driven websites" and also describe it as "Astro DB is a fully managed SQL database designed exclusively for Astro." it's got Drizzle built in and uses LibSQL.

[00:07:37] Apparently Lib SQL is a fork of SQLite, which, they posted a deep dive that goes into a lot of the sort of the history and how this whole thing unfolded. And they talk about trying to make it work spring of last year with SQLite, but they ran into constraints with the fact that SQLite relies on compiled components within it, the C native code produced performance constraints that didn't really work very well within serverless environments. So they then tried again with this fork of SQLite that does not use those same native compiled, subcomponents within it. that's super cool, I think this is neat.

[00:08:11] It sounds like they're very much positioning themselves as a WordPress competitor. So it's, you know, content driven websites with an included database. Like, that sounds like WordPress to me. So I think that's pretty cool. Astro's been doing a lot of things, this really does seem like a substantial change to the core offering.

[00:08:29] Mark Erikson: And purely from a technical perspective, it is interesting to see that there's been a number of tools and services that are being built using SQLite as more than just like a local datastore as of late.

[00:08:40] I think Cloudflare Durable Objects, are built on SQLite. You've got this AstroDB, I think I've seen a couple other tools as well. A lot of tools that are basing themselves around SQLite in some way.

[00:08:52] Carl Vitullo: Yeah, definitely. I read a really good blog post talking about why SQLite makes sense in a lot more contexts than we've generally given it credit for.

[00:09:01] And, yeah, it seems like people are really experimenting in real meaningful ways with different places to use it, which I think is awesome. I think it's a great project. You know, co locate your database with your executing code because it's small and fast, keep it a single binary.

[00:09:15] Yeah, this is not quite directly related, but while we're talking about databases, I also heard about, PGLite, which is a Postgres implementation packaged as a WASM module, which, that's neat.

[00:09:27] It's not quite SQLite, but if you need a database in your browser app, it seems like a cool new option.

[00:09:34] Mark Erikson: There's probably also some kind of application for, I don't know, running end to end tests in the back end with that as like an in memory database or something like that?

[00:09:43] Carl Vitullo: Yeah, that's actually, that blog post I mentioned about SQLite, that was one of the things that they've said that SQLite has been relegated to just being like the test database because it's, you know, super fast and, you know, super easy to spin up. So, yeah. Definitely makes sense in those sorts of contexts.

Upcoming conferences

[00:09:58] Carl Vitullo: Blasting through conferences.

[00:09:59] Epic Web is coming up April 10th and 11th in Park City, Utah.

[00:10:03] React Miami, Mark and I will both be there, is April 19th. We actually have a discount code. So if you are interested in going to React Miami, make sure to, one, get your ticket soon, cause it's in like three weeks, and get your ticket with the code REACTIFLUX4EVER with number 4.

[00:10:21] Very much looking forward to that though. There's React Connection and React Native Connection on April 22nd and 23rd in Paris.

[00:10:27] Mark Erikson: And I will be speaking there going straight from Miami.

[00:10:30] Carl Vitullo: Haa, wonderful, yeah, 20th to 22nd, that's a quick turn for an international flight across the Atlantic.

[00:10:36] There's PostCon April 30th and May 1st. That's from Postman. So they're doing like an API conference, they're calling it.

[00:10:42] And then the big one, React Conf, is happening May 15th and 16th in Henderson, Nevada, just outside Las Vegas. Cool.

[00:10:50] Alright, whew, we finally made it to the main bulk of the content. Yeah, Mark, you want to take us off with our first set of discussions?

React 19 and React Compiler

[00:10:58] Mark Erikson: Alright, so there's a number of pieces of news around React 19 and the React compiler tool that was announced a couple months ago. So first off, I saw a PR go up just a day or so ago. React's codebase has lots of feature flags because they build React for many different use cases. There's internal Facebook builds, public open source builds, React Native builds, experimental builds, canary builds, lots of different combinations.

[00:11:23] And so the React team is constantly adding new feature flags, altering the feature flags, changing the default value. And so this PR makes it sound as though what's in Canary right now is what's expected to go into React 19. So that sounds like a, you know, fairly meaningful step towards a potential React 19 release.

[00:11:43] Also, if you've just been keeping an eye on the list of pull requests in the repository, there have been a ton of internal cleanup PRs where they've been changing over a lot of the existing tests to actually use some of the more modern React APIs, like, uh, React on client slash render, instead of the old React render, et cetera.

[00:12:01] One thing that wasn't entirely clear from the React labs blog post in February is that React 19 and React compiler are not directly tied together. They're both things that are in progress, but React compiler is a separate project. And it probably will come out sometime after React 19 is released. So, different projects, separate schedules, but still both very much in flight.

[00:12:29] Speaking of React Compiler, there's been a couple good posts discussing how it works and what practical effects it'll have. Nadia Makarevich has done multiple great blog posts about React rendering somewhat similar to the post that I had written a while back. And she put up a post talking about React 19 and React Compiler and, you know, some of the practical benefits like not having to write code that does a lot of your own memoization logic because the compiler will do it for you and it will help with rendering performance.

[00:12:59] And then, Satya, who is on the actual React compiler team, and has popped in and hung around Reactiflux a decent amount, put up a couple really good posts talking about the internal implementation details of the compiler itself. The compiler is currently exposed to the world as a Babel plugin, but that's more for ease of integration with the existing build tool ecosystem.

[00:13:24] The way I understand it is that the Babel plugin basically acts as just kind of like an outer shell and then all the real logic is like a full blown compiler from scratch that the Babel plugin kind of forwards everything to.

[00:13:38] So, you know, perhaps at first to make use of it. You would need to have Babel set up, but with the way they've got it designed, they would eventually be able to, you know, maybe expose it as, you know, an SWC plugin, or its own standalone tool, or something like that. Also, sort of tied to React 19, there was, I don't know, maybe controversy is a little strong, but kerfluffle? Annoyance? Frustration back and forth?

[00:14:03] Carl Vitullo: A joke that didn't land.

[00:14:04] Mark Erikson: Yeah. So, a little bit of background. The React Three Fiber ecosystem is pretty large. uh, DRCMDA, however you pronounce his username, uh, I think his name's Paul Henschel, and a bunch of other folks have done some amazing work over the last few years to create a React renderer that wraps the three.js 3D WebGL library so that you can write React components that render full blown 3D scenes and control them. And while I have not played with this myself, I've seen lots of examples and snippets and videos of some incredibly impressive demos and apps and tools that they've built over the last few years.

[00:14:44] Now, one issue is that React three fiber is its own separate React renderer different from React DOM. Like, they both have their own copies of React's core logic embedded in them. And React has a limitation that different renderers in the same program don't actually know about each other. And so, if you think about a typical web app, you're probably using React DOM to render the outer page, and then you might be using React Three Fiber to render, you know, like a 3D animated scene or a game or something inside of the page.

[00:15:22] And the problem is that if you try to render a context provider, In, like, React DOM, React Three Fiber will not see it, because they are effectively totally separate worlds that just happen to be nested in each other. And so, there was a PR, there was an issue request all the way back in 2019, where some folks like the React Three Fiber people were asking, " Can React add a way to try to share context?"

[00:15:48] between renderers. And that PR has been open for a long time, er, issue, and nothing's happened with it. So, the React Three Fiber folks ended up writing a very intentionally hacky package called its-fine, which, you know, references that goofy little, like, dog in the fire meme. It very intentionally reaches into React's internals and accesses fields that you're not supposed to be able to grab context instances from.

[00:16:15] And pass them across the renderer boundary so that you could have like your context provider with user data or something at the top of the whole application and both React DOM and React Three Fiber could read from it. Well, a few weeks ago, Sebastien Mårkbage from the React team put up a tweet where he linked to the dependents of the it's fine package and said, " yeah, this is a list of Packages and tools that will break in React 19," which is fair.

[00:16:41] I mean, it's a package that intentionally reaches into React's internals. You have to expect that there's going to be breakage. So that's a very legitimate observation.

[00:16:50] But then it kind of went off the rails a little bit. Another one of the React team members, Rick Hanlon, actually posted a PR in the React repo that he labeled, " it's not fine," and that PR literally just looks for the existence of the it's fine package in your project and throws an error if it's detected. Now, while he didn't explicitly say it in the initial version of the PR, it was obvious this was a joke and it was never going to be merged. But, I'll be honest, speaking personally, I found that joke to be in very bad taste.

[00:17:23] To me, as a library maintainer, if people are writing code in a way that reaches into my own library's internals, that usually says to me that there's some use case that I haven't considered that I ought to at least think about trying to handle. and make a public API for. As an example, with React Redux, up through version 5, used the old style React context system.

[00:17:50] And everybody knew that you could reach in and grab the Redux store by accessing this.context.store, but it was never part of our public API. And so when we switched over to the new context API in version 6, Number one, all those old usages broke. And number two, we actually publicly added a useStore hook, that, you know, just grabs the store off of new context and returns it. And so it's not something we recommend using, but it's a thing people sometimes had a reason to do. And so we provided an API to do it.

[00:18:26] So my stance as a maintainer and a community person here is that, number one, the joke PR was a bad idea. The React team has had enough issues with marketing and PR and DevRel.

[00:18:39] Mistakes in the last few years and this really did not help the situation. And number two, you know, making the original observation that, hey, these things are going to break is fine, but maybe instead of making a joke, Pierre saying, "haha, we're going to ban this package", maybe you should be trying to address the legitimate request for a way to use React that does not officially work right now.

[00:19:02] Carl Vitullo: It looks like this did turn into that as well. In a reply on that, you know, joke PR, Sebastien Mårkbage did come in with some like real analysis on, you know, he said, I spent some time investigation or investigating. "The proper solution behaves like a portal should forward the value during a concurrent render into the child."

[00:19:26] Yeah, it's, it basically, it sounds like what he was saying is, " it's tough, it would require some adjustment to these other guarantees that we make, will take a fair amount of time to evaluate whether this is going to be actually possible. It's not our top priority because of the bit of a fringe need."

[00:19:42] Which, all very fair. So I'm glad this did come back and get some, like, real technical back and forth. it just felt like it felt a little bit like targeted and kind of mean spirited. So, you know, glad it came back and had some more meaningful discussion about the problem and what the right solution—

[00:20:00] Mark Erikson: the technical feasibility aspect of it. Yeah.

React Strict DOM, Why is it so Great?

[00:20:02] Carl Vitullo: Yeah, most definitely.

[00:20:04] Next one, there was a really great post called, React Strict DOM, Why is it so great? From Syzmon Rybczak? I am so sorry if I'm murdering that, but, interestingly, he, he claims to be 17 and working at Callstack. So, wow, cool. This is a great post flat out. And this is a phenomenal post for a 17 year old developer. Like, wow, cool. Somebody to keep an eye on.

[00:20:24] But, talking about, React Strict DOM, and, sort of the, Technical background of where it came from and contrasting it with React Native for web. Actually, as I was reading this, it reminded me of some of the discussion we've had, but this is a really great long form write up of, that hits a lot of the same notes that we discussed previously, but with added benefit of pretty great technical diagrams made with Excalidraw . Yeah, definitely good to check out.

[00:20:52] It talks about how React Native Web is It's ultimately a shim that offers compatibility with the React Native API, which the big downside of that is because of the approach it took, it is necessarily a relatively large shim, and adding A large core package to a web app, just it, it inflates the bundle significantly, more significantly than not using it, which is just the extra friction, which makes it just that much harder to get adoption.

[00:21:23] And since React Native Web didn't really get adoption. So the React strict DOM approach sort of comes at it backwards, where it takes web APIs to render components out and, because it is taking such a different approach to a similar problem, it is able to keep the size of this shim, this compatibility layer, much, much smaller.

[00:21:44] So it looks like the core of it is coming from these two CSS and HTML exports from the ReactStrict DOM package, and those are how React Native would then understand how to handle these UI primitives.

[00:21:59] Mark Erikson: Yeah, another way to put it is that the React Native web package gave you what looked like React Native components, so you would write your web code as if it were targeting React Native.

[00:22:12] With React Script Dom, it's flipped, so that you're You write React Native code as if you were targeting the web, and so you write, you know, your components return a, quote, div on both platforms, but now with React Strict DOM, what you said was a div on native actually becomes a React Native view instead.

[00:22:33] Carl Vitullo: Yes. Thank you for that. I guess I didn't realize that the React Strict DOM package is built on StyleX? Like it looks like that is very core to what is enabling this, I guess? I know you have explained StyleX to me at least once before and I just don't have a, it doesn't, it didn't stick in my brain.

[00:22:50] Mark Erikson: As usual, I've only glanced at it myself.

[00:22:52] It is yet another CSS in JS type tool. It was developed internally at Meta, like many of the other tools that they've put out there. As I understand it, some of the defining features are it's more of a compile time tool instead of runtime. And I believe it compiles down to more of an atomic CSS setup so that it.

[00:23:14] Like over time, the amount of extra styles that get generated stay pretty limited because, you know, like everywhere you use like a certain margin size or something that only ultimately adds one rule to the code base.

[00:23:28] Carl Vitullo: It's definitely similar ish to the like compiler for the Tailwind compiler works ish, but operating on a different set of, uh, underlying primitives.

[00:23:37] Very interesting. Didn't realize that it was so connected to React strict DOM. So that's pretty cool.

Server Components updates

[00:23:42] Mark Erikson: Moving right along, we have a few different articles and bits of information related to server components. There was A couple articles that discussed kind of like some of the philosophical or conceptual model of React and server components.

[00:23:57] There was one article in particular that tried to go back to React's, early selling point of your UI is a function of state. And, when we say state, we normally think about state in components, or maybe state in, you know, You know, an external state library like Redux or Jotai or something. The article makes the point that there could actually be lots and lots of sources of state in your application.

[00:24:22] You know, there's the URL, there's server files, there's the current time, operating system settings, environment variables, You know, lots of different potential sources of state. And so, you know, kind of walking back philosophically about, you know, how do these concepts tie together. And the author goes in a couple different directions.

[00:24:40] On the one hand, extrapolating some of React's principles, you know, the React team has always been very focused on composability. And that's why we ended up with the custom hooks model that we did, because it enables arbitrary composition of hooks. On the other hand, the author also put up a follow up post saying that they think that Next actually kind of breaks some of these React fundamentals with the way that server components work and some of the way you have to actually structure your code base and your data flow.

[00:25:10] I don't have a particularly strong opinion here, but it's always nice to see people actually kind of thinking through the concepts and the consequences involved.

[00:25:18] Carl Vitullo: Yeah, and I really like the focus on. Discussing what state is. I feel like the, you know, the React ecosystem has been talking about state and state management for so long that, you know, there's always a game of telephone that happens in trying to communicate concepts out.

[00:25:34] And I feel like where that has ended up over the years in the React ecosystem is people think state is a single blob of JSON. You know, that their app uses. But what this article is bringing back up is like, no, that's not the only type of state. State is something that your app needs to track in order to function correctly.

[00:25:55] So yeah, I just wanted to call that out. I think that's a really useful clarification.

[00:26:00] Mark Erikson: There was also a pretty good post over at Builder. io entitled, Why React Server Components are Breaking Builds to Win Tomorrow. I actually didn't quite catch the where in this it's talking about the breaking builds concept specifically, but it does a pretty good job of talking about the different concepts of rendering on the client, versus rendering on the server, versus streaming HTML, and how suspense and server components actually make some of these capabilities possible. So it's a pretty good kind of like technical architectural walkthrough.

[00:26:31] Moving on a little further to the ecosystem. The Waku project from Daishikado, who's the author of Jotai and Valtio and Maintainer as Zustand, is making good progress. They've announced that they're working on a Pages router.

[00:26:44] And I believe they're up to version 0. 20. Not sure what the roadmap is to 1. 0, but it's definitely a nice alternative approach to what we've seen with Next. And I believe they're pretty serious about trying to make it like a full blown, meaningful, usable framework based on server components. Similarly, Lee Robinson from Vercel actually just tweeted out a list of at least a half dozen different projects that are working on server component support in some fashion.

[00:27:14] And so there's definitely work being done in the ecosystem. More specifically, the Redwood project. which originally went all in on GraphQL as the back end, just announced that they have finally managed to succeed in integrating server components. And I think they actually put up a post a few months ago saying that we are all in on server components as a concept.

[00:27:36] So, server components have been out in Next for a while. We know that Remix is working on them, but there's other tools and frameworks that are trying to adopt them as well. And finally, I, one slight counterpoint, found an article just a little bit earlier where a company said, you know, we've tried server components and we like them, and we tried the new React server actions support.

[00:27:57] But they ran into a few technical details, or technical issues. They didn't get a lot of details. It looked like something about some bundle problems, and then they felt that there was too much magic going on at the architectural level, and so they actually dropped server actions and went back to using tRPC instead.

[00:28:13] Carl Vitullo: Interesting. Yeah. Too much magic is a very hand wavy type of complaint that can be used for all sorts of different, uh, underlying problems. So I'm curious what some more of those technical details would have been. But it's cool to see more experimentation and a wider range of experiments being done with server components generally.

[00:28:33] When we first talked about WACU, I kind of expected it to be like just sort of an experiment, just sort of a like trial, because we'd seen a couple of those. We've seen, we had seen a couple of people just throwing together a project, doing it for learning, doing it to just explore. There's been. Pretty consistent development on Waku, so very interesting to see.

[00:28:52] We'll have to see if it grows into a, like, serious competitor framework for, you know, okay, like, if it makes it to Remix or Next tier, then I would be very impressed. But, you know, they're definitely working on it in a much more meaningful way than I was anticipating originally.

Apple walks back on PWAs, neat Safari features

[00:29:06] Carl Vitullo: A bit of a follow up to something we talked about last month of, uh, Apple's Attempted undoing of PWAs attempted.

[00:29:15] I don't know how to frame that, but the last month. Apple announced they were going to drop support for progressive web applications for installing a web app to your home screen. They very quickly walked that back. And actually now, like I was just checking in on WebKit updates and they're adding more support for progressive web apps.

[00:29:32] They are most specifically, they're going to be supporting the shortcuts manifest property, which allows you to add context items for the home icon. So, you know. On a Mac, if you add it to the dock, you can right click on it and it will show up a couple of options that take you to specific URLs within the app.

[00:29:51] So, you know, it's a shortcut. It's a context item for your home screen icon that takes you to somewhere specifically within the app. Like, these are the kind of things that Like what progressive web apps have been a thing for like a decade now. Like there was never a technical reason why Apple could not support shortcuts in this.

[00:30:08] So this feels like a shift of tack to more meaningfully support progressive web apps so that they can entrench themselves and say like, no, look, we are, we do support alternatives. We're not a monopoly while they're defending lawsuits against the iPhone and app store. So cool. You know, if that ends up bringing more meaningful support of progressive web apps. Uh, I'm pretty excited. You have to see how that shakes out though.

[00:30:32] Another small, interesting thing coming from here, not related to progressive web apps, just Safari web kit features. They added a like progressive enhancement type option for checkbox. So they added a switch attribute to the input in Safari.

[00:30:48] So if you say input type checkbox switch. It will render as a switch. It was one of those solutions that felt really obvious in hindsight, and I have implemented so many switches in my career, and they are a pain in the butt to get to work correctly. So having a native option, like, now I want Chrome and Firefox to roll it out, like, immediately, because it is Just a great improvement.

[00:31:08] It's a very small, but very meaningful improvement. I love to see, it's not even like innovation in form inputs. It's just like fixing a problem, fixing something that's been missing for 15 years at this point.

[00:31:21] Mark Erikson: Nicole, who had been heading up a lot of Chrome's work around interacting with frameworks, I know that she had spearheaded a lot of efforts to try to improve native form controls as a concept.

[00:31:33] I also know there's a project called Open UI, which is somewhere between let's build another set of web components, but also let's kind of like prototype and experiment with what additional built in browser forms and features would look like. And what if there were a tabs or a carousel kind of control built into browsers natively?

[00:31:56] And so they've been doing work to try to spec those out.

[00:31:59] Carl Vitullo: Oh, very cool. In some ways, I feel like in trying to be agnostic and provide maximum flexibility to developers, I feel like we used to have, like, the operating systems, before everything moved into being web based, operating systems provided, like, a very limited toolkit of, like, here are your UI elements.

[00:32:18] Mark Erikson: And bring back the styled win Windows XP Common Controls, Doug on it. .

[00:32:23] Carl Vitullo: Right, right. Where's the, where's the Windows 95, you know, tab list? Like, okay. Sure. Uh, we've had a lot more experimentation in different types of UIs and different types of ex uh, different types of user experiences. But like, man, you know, it's, I feel like it's also gotten super fragmented.

[00:32:38] And so maybe this is the pendulum. Maybe, you know, it went, it started by technical necessity on a super constrained set of core components that you just added. And then we went all the way, maximum flexibility. You can do anything you want, anything and everything. And now people are going like, uh, I'm tired of figuring out new unfamiliar UIs.

[00:32:57] I'm tired of implementing things from scratch. So, uh, yeah, I, maybe we'll. Consolidate a little more back on a simpler set of UI primitives.

Mental Health in Open Source

[00:33:05] Mark Erikson: All right, changing topics completely. There was an excellent article this week from Anthony Fu, who is a prolific maintainer and developer within the Vite and Vue ecosystems.

[00:33:17] And, you know, strictly speaking, this has nothing to do with React, but it is an excellent article. And so he wrote about mental health in open source. And he talked about, you know, he got involved in open source kind of by accident. Thanks And he made a lot of great points that absolutely resonated with me.

[00:33:34] Like, as a fellow open source maintainer, I 100 percent absolutely agree and endorse and stamp and repeat every single thing that he said in this post. So we talked about, you know, not being prepared, like, as a maintainer, you are a developer, and tech support, and marketing, and docs writer, and team leader, and project manager, and, you know, a whole bunch of other hats, and nobody teaches you how to do any of this stuff.

[00:34:03] But there's also a really big problem with expectations, both internal and external. You know, users file bug reports, and they expect their bug to be fixed right away. But then, as a maintainer, you also put a lot of pressure on yourself to try to get stuff done. And I unfortunately am very guilty of this.

[00:34:21] I routinely have put far too much expectations and self responsibility to get certain things done. And then I feel bad when I don't live up to my own expectations. As an example, I've said that this year I want to do a refresh pass on the Redux docs tutorials. And I've sat down like three different evenings and made some progress on it, but I've been otherwise focused on some different things and my brain is yelling at me because I quote, haven't made as much progress as I should have made by the end of March.

[00:34:54] Nobody's watching me. Nobody is keeping track. Like, I've tweeted that I was gonna do this, but like, no one is watching me. It's my own head that is yelling at me because I don't feel like I've gotten enough done. And so Anthony has, you know, some similar points that he makes in his post. And then he also talks about, you know, in some ways your dream of working on this tool can become its own entire second job.

[00:35:17] So there's not like a specific solution that he discusses, but everything he said on that post, like is absolutely my own experience and it's very much worth reading.

[00:35:28] Carl Vitullo: Definitely worth reading. You have a lot of good things to say about like making your hobby, your job, that definitely resonates with me because that's kind of what I've been trying to do with the community stuff here in Reactiflux, part of why we are doing this podcast is because I thought, you know what, podcasts, that's the way to make money, not that it's worked yet, but you know, hey, sooner or later.

[00:35:48] But yeah, this is, I definitely thought this was a really great and, I think it's a pretty vulnerable post. He's being very open about the difficulty of taking on this category of work. So yeah, also he talks, he says in the beginning, it's been about four years since I started doing open source and that's like, man, that puts him at.

[00:36:07] 2019, 2020? 2020? That's four years ago? What? I don't know. This blew my mind a little bit. I have never been an open source maintainer, really. I did briefly take over a, you know, abandoned project and did a little bit of work on it. But, you know, it was so small that I don't feel like I can meaningfully claim the open source maintainer.

[00:36:27] But, you Even just, even a very small library that was, ultimately was functionally replaced by a browser standard, it was a sticky, you know, Sticky banner library. Even just doing that for a couple of, I guess it was close to a year, just fielding issues and diagnosing and figuring out the, whether the answer to a question is yes, this is the bug that needs to be fixed or no, this is a

[00:36:49] Mark Erikson: Intentional design limitation or something.

[00:36:52] Carl Vitullo: There we go. Yes. This is an intentional constraint that. The trade offs are such that this is the correct decision. That's a lot of mental energy to expend. Like, you know, separate from, and I never did any blogging on it. I never, you know, spoke at any conferences. It was like a, an extremely small part of my, Attention.

[00:37:09] And it still wore on me a little bit. So yeah, definitely a really good post to read. Really good projects alive that all of us use to do our jobs. Yeah, definitely recommend reading it.

Angular, meet Wiz

[00:37:20] Carl Vitullo: I'll move us on. This is even farther afield from React, but, um, I saw Sarah Drasner tweeted that the Angular is going to be merging with a heretofore unopensourced internal Google framework called Wiz.

[00:37:36] Wiz was brand new to me, I had never heard of it. So. Hearing that, you know, Angular, one of these huge projects, one of the projects in web is going to be internally combining with a never open source project. That's a pretty big statement. That's a pretty big plan.

[00:37:51] It looks like this ultimately came from a exploration of using signals within, you know, signals and reactivity within Angular and drawing inspiration from this well understood internal framework called Wiz that I believe it is.

[00:38:07] No. Okay. So the combination of Angular and Wiz is already rolled out to 100 percent of YouTube traffic. So like, this is not, you know, an abstract. Intent to, like, no, this is done. This is, you know, I took this as a similar in weight to when the React core team announced that server components were being used on the Instagram web property, you know?

[00:38:29] So this is a meaningful investment. One of the big reasons that I think this is worth discussing on our React news show, Malte Ube, he is currently working at Vercel. He did a lot of work on Wiz. Back in the day at Google, he, and he had a really good post where he talked about like, why was that? Why was Wiz developed?

Designing Very Large Javascript Applications

[00:38:49] Carl Vitullo: What problem was it trying to solve? And so he put up this blog post called Designing Very Large JavaScript Applications, which is ostensibly about Wiz and about, you know, these frameworks. But I found it to be a really clear and cogent articulation of a lot of the challenges that React. is trying to solve as well.

[00:39:08] It's, you know, it talks about like the challenges of centralizing configuration and how, you know, things like a routes configuration file or the webpack configuration file, when you start maintaining a Enormous web application begins to be such a large constraint as to be like prohibitive. Like it just, it doesn't work.

[00:39:29] You can't scale it. It ends up being append only. And so then you end up loading the bundle, like it becomes fragile because nobody wants to remove things. So then nobody wants to change, make certain categories of changes. Definitely a really good post discussing a lot of the finer points around bundling and architecture limits of current tooling and the most challenging.

[00:39:49] Parts of large and complex applications. Uh, specifically he talks about Google search results and you know, now they serve up lots of little, uh, widgets as the first result. Like, you know, you search some math and it will spit out a calculator. You search a currency conversion and it puts up.

[00:40:03] A calculator. Or all sorts of those things. Like each of those is basically its own tiny web app, and so if you just pull up Google, obviously they cannot serve up dozens and dozens of these tiny web apps that you're not using. So that's sort of the category, that's the backdrop and the framing for this architecture that's gotten.

[00:40:21] Yeah, definitely really interesting. Definitely recommend giving it a read.

[00:40:24] Mark Erikson: One other small tangent off that is, you know, we've heard the discussions and the arguments about front end development doesn't get the respect that it deserves for being its own very complicated domain. And I think that post is a very good example of, you know, real world apps have a lot of complexity and there are, they have their own unique sets of constraints and concerns and potential problems they have to work through.

[00:40:47] Yeah,

[00:40:48] Carl Vitullo: very true. And on that note, something that struck me reading it is that is an entirely different set of constraints than I personally have ever experienced in my career. So of all of the weird, quirky, you know, specific reasons why like this tool doesn't work for this product or whatever, That was a whole new category that I've never encountered, like, I, you know, I don't work on a Google type app where there might be one of a hundred and fifty different things served on the same page.

[00:41:16] So I just thought that was really interesting. It was a glimpse into a different part of the web world. Just broadened my perspective just that little bit much more.

[00:41:23] Mark Erikson: I mean, similarly, you were talking earlier about like, you know, I've implemented, you know, a half dozen input widgets or something in my career.

[00:41:30] Like, I've never done anything like that. I mean, I've never worked on a project that really made meaningful use of a router. At all. Like everything I've worked on in my career has basically been the equivalent of a desktop app that runs in a browser that, you know, it's an app, not like pages or routing.

[00:41:51] So like I've barely ever used routing in my own career because the products I've worked on just haven't required it.

[00:41:58] Carl Vitullo: Yeah. I think that is so true and very underappreciated even within frontend. I think that so like you said, I've implemented a lot of checkboxes. That's because I've jumped around to a lot of different startups and I've worked on a lot of greenfield projects.

[00:42:11] So I actually think that I have a relatively rare perspective on the industry of, you know, I didn't spend six years at, you know, Google. Four years at Facebook. In, in my, over my 10 year career, I worked at nine different companies. Like, you know, I've seen a lot of different types of products. I've worked in advertising tech, agriculture tech, cryptocurrencies, done brochure sales sites for credit card companies.

[00:42:34] So like, I have worked in a bunch of different contexts. And what I've learned is that Well, something I experienced was that surprisingly little of what I used in one company was immediately relevant at the next company. Like, the architectures were just so different that the assumptions I couldn't bring any of my past assumptions.

[00:42:53] I had to leave all those assumptions at the door and just rediscover a new problem space every time I joined a new company. And so here's Malte discussing an entirely new type of architectural constraint that I have never encountered, despite my wide range of encountered problems. Last thing I'll say on that, he gave a talk at JSConf Australia in 2018.

[00:43:13] Speaking about Wiz and talking a little bit about his decision not to open source. He says at the time didn't want to compete with React. There were already so many options, adding another one seemed unnecessary. And like, yeah, I, 2018, I feel like that was about peak JavaScript fatigue era. Um, but now he describes that decision not to open source as a misread of the market demand.

[00:43:36] So that's interesting. So just bringing it back to Angular meets Wiz. I think, yeah, I'm going to be paying attention to that to see how that shakes out a little bit more. It seems like it's, he regards it as a correction to a mistake made like five or six years ago.

Lightning round

[00:43:51] Carl Vitullo: We're into the lightning round. We are over an hour.

[00:43:53] Mark Erikson: Lightning the lightning round.

[00:43:55] Carl Vitullo: Yeah, lightning the lightning round. Cool.

⚡️ Interaction to Next Paint, new Core Web Vital ⚡️

[00:43:56] Carl Vitullo: First off, there is a new Core Web Vital, which are the, like, lighthouse, Performance characteristics that are measured by Google. I believe the Core Web Vitals are one relatively significant input to search ranking for like search engine optimization.

[00:44:12] Interaction to NextPaint, INP, is replacing first input delay as a Core Web Vital. So really quick overview, uh, first input delay was You open up a new website, how long until that code responds to the first input you give it? You know, a click, a scroll, a keystroke. That is no longer going to be a Core Web Vital, and instead it will be how long between an interaction and the next paint.

[00:44:36] Notably, that's A change from measuring like startup responsiveness to ongoing responsiveness, which I think is very important. 'cause you know, it's much easier to do a, a one-time optimization of the app as it's loading versus a just optimizing the entire app so it's more responsive and just faster, better. So yeah, definitely seems like a much more meaningful metric.

⚡️ RSPack charts a path to 1.0 ⚡️

[00:44:56] Mark Erikson: Next up, there's been a plethora of rust based javaScript build tools as of late. One of those is called RS Pack, which is a rust based reimplementation of the entire web pack tool being built by ance. RS Build is a layer on top of that from the same team that makes the web pack layer easier to use.

[00:45:20] So conceptually this is like a CRE React app equivalent, and they actually have how to migrate from CRA in their docs. They have announced plans for their roadmap to a 1.0 release. For what it's worth, I tried out RS build in one relatively small CRA project that I had, and it worked great. Like the build time dropped from like 30 seconds to one second.

⚡️ Remix might merge React Router in?? ⚡️

[00:45:42] Mark Erikson: Entirely other news, Ryan Florence has been talking about how the Remix team has been continually adding more features to React Router, things like loaders and such. And so he's now tossing out the idea that they might end up effectively merging the Remix and React Router projects in some way. Details TBD. But it's something that they're thinking about.

⚡ Declarative Shadow DOM in all major browsers ⚡️

[00:46:08] Carl Vitullo: I have another broad web update here. Declarative Shadow DOM is now available in all major browsers. This is related to web components. I know that one of the major criticisms in the past several years, many years, has been Of web components has been that it is not possible to use them without JavaScript.

[00:46:27] How they get added to the page is through JavaScript. And so if you are trying to make, there are many categories of web products, web properties. Where that just doesn't work. You can't use JavaScript, you can't rely on it, many reasons it doesn't work. And so, this is a declarative version of Shadow DOM that is now supported in all major browsers.

[00:46:46] And, theoretically, maybe this will unlock a new era of experimentation in web toolkits. Now that we can use Web components without JavaScript. I think that we might start seeing some more experimentation. This kind of feels like what web components have always been meant to be. So yeah, interesting.

⚡️ React Native community map ⚡️

[00:47:05] Mark Erikson: Okay, next up, there's a developer named Lorenzo Sciandra, who works at Microsoft, I believe, on Microsoft's maintenance of React Native for Windows and React Native for Mac, and he's put together a repository list that points to lots of community resources for React Native. Discords and servers and discussions. So if you're interested in React Native and other possible community resources, that's useful.

[00:47:31] Carl Vitullo: Yep, we're on there. Woo! (chuckles)

⚡️ Node.js 2023 Year in Review ⚡️

[00:47:34] Carl Vitullo: As mentioned much earlier, there was a Node. js 2023 year in review post.

[00:47:39] It's mostly just sort of talking about, like, Technical overview of how Node itself has changed over the years. So it's not so much like how you use it or, you know, performance. It's here is how usage of different versions have, has trended over time as different ones have gone end of life or been released.

[00:47:58] It has a great chart of the binary size per version over time, which let me just call out. So version 10. 24. was about 40 megabytes or mebibytes. I'm just going to call it megabytes. Version 21. 6 was 98. So that's a long time. Version 10 versus version 21. I think that's Like close to 10 years, something like that.

[00:48:22] But yeah, seeing it 2. 5X in size over that time is, yeah, I guess it's been kind of append only. So yeah, like we discussed earlier, TypeScript has been focusing on reducing its install size. It sounds like there might be growing appetite to do so in Node as well. But this is just sort of like a, it's a pretty deep in the weeds discussion of how Node has evolved, and specifically some of the changes in 2023. So I found it was a good read. Not immediately actionable in any kind of way, but just sort of broad context. Stay on top of what's going on.

⚡️ Tailwind preview of 4.0 ⚡️

[00:48:57] Mark Erikson: Next up, Tailwind is working on a new version and they've put up a post talking about some of the changes that they're making for version four. The biggest one is they've got a whole new CSS engine.

[00:49:08] Apparently it's built on top of Lightning CSS, a Rust based CSS parser and translator from the author of Parcel, but they're working to make it the whole thing smaller, faster, built in. They're also making some potential changes to the configuration so it actually kind of looks and feels more like CSS in the process.

⚡️ Vercel adds Remix+Vite support ⚡️

[00:49:26] Carl Vitullo: So, Vercel has announced that they are now supporting Remix with Vite. Pretty cool. Just especially because they maintain Next. It seems nice that they would pretty quickly jump on adding support for some new features coming out of Remix. They say in this post, they collaborated with the Remix team to add server bundles to Remix, which we discussed really briefly last month as a kind of confusing, deep optimization.

[00:49:52] So just to see that. Vercel is meaningfully working to support some kind of fringe, niche features within one of their major competitors. Cool. That seems really nice. Very glad to see that. Also adds support for Remix features like the streaming, server side rendering, API routes, more advanced caching, data mutations.

[00:50:13] Yeah. Happy to see that.

⚡️ Navigating the Future of Frontend ⚡️

[00:50:15] Mark Erikson: And finally, there's an author named Rem, uh, I don't know any more details about them, that's just their handle, who has put up a series of very good posts at a site called Frontend Mastery, talking about various aspects of React and frontend development. And the latest one's called Navigating the Future of Frontend.

[00:50:32] And it talks about some of the aspects of JavaScript frameworks, and their capabilities, and what are some of these tools even doing for you. And talks about some of the directions that they are going these days in terms of routing, and mingling backend and frontend, and dealing with caching, and components that can be used on the server or on the client, and in a mix of some way.

[00:50:55] So it's not like a specifically actionable post, but it's a useful guide to, like, where have we been and where are we going.

[00:51:02] Carl Vitullo: Yeah, definitely looks like a really interesting post. And I just realized, just now, that it's not on Frontend Masters, it's Frontend Mastery, which is not an educational platform hahaha.

[00:51:12] Mark Erikson: It looks like it's basically this one person's blog.

[00:51:15] Carl Vitullo: Interesting. Yeah, I, I saw the link and I had assumed that it was really the front end masters, which makes perfect sense because they've been doing web education for my entire career, insofar as I learned React by taking a front end masters class. But yeah, no, this is front end mastery.

[00:51:29] It's just somebody's blog. Still, it's really good, really good post to echo everything Mark just said.

[00:51:34] That's everything we got. We'll be back on the last Wednesday of next month in April on the live stage here in Reactiflux or back in your podcast feed just as soon as we can. We gather sources from This Week in React, Bytes. dev, React Status, Next. js Weekly, React Digest, the React. js subreddit, here in Reactiflux, and directly from people publishing articles on Twitter or whatever.

[00:51:57] If you see anything newsworthy, definitely let us know in the Tech Reads News channel here in Reactiflux, or let me know by sending an email to hello at reactiflux. com with T M I R in the subject line. It's an acronym for the show.

[00:52:11] I read literally every email that comes in, including spam and all sorts of other things. So yeah, if you send an email to hello at reactiflux. com, I will read it. And if this is a show you get value from and want to support, the best way to do so is submit a review or tell your friends and co workers about it.

[00:52:26] Just drop it in Slack. And I know that I will personally thank you if I am ever made aware of you broadcasting us. Cool. Thank you so much. See you next month.