This Month in React (January 2024)

Transcript from Thursday February 1st, 2024

[00:00:00] Carl Vitullo: Thanks everyone for joining us for January's this month in React. I'm Carl. I am a staff product developer and freelance community manager here at React Tofl, the Discord for React Professionals. And Mark, you wanna introduce yourself?

[00:00:14] Mark Erikson: Hi, I'm Mark. My day job is at Replay io where we're building a time, traveling demographer JavaScript.

[00:00:20] And in my copious amount of spare time, I maintain Redux.

[00:00:23] Carl Vitullo: Seems like it's been a big month. I don't know if that's just January, but yeah, let's dive right into it. I'm going to start off with a couple of, like, quick hits of small news.

Reviewing layoffs

Layoffs.fyi

[00:00:32] Carl Vitullo: I've been keeping track of layoffs. fyi. The first month of 2024 is looking not great. January layoffs have picked up a decent amount compared to last month, but compared to last year, January 2023, they're down like 70%. So, seems like it's trending in a good direction on an annual basis, but my instinct is that the next year is going to still be pretty rough.

[00:00:58] Getting more specific, in January, 2022, there were five layoffs with about half a thousand affected. 2022 had a pretty steady upward trend for the rest of the year, which spiked really sharply in November. And then again, in January of 2023. Uh, so 2023 in January, there were 277 layoffs with about 89,000 affected. Jumping ahead to this year. January, there were 118 layoffs with about 31,000 affected. So this January is significantly less bad than last January, but compared to two years ago, it is... not even close it is super super high, still.

[00:01:38] But looking at this annually as part of a cycle, um, I attribute some of this, I'd attribute the spike in November to businesses wanting to avoid holiday layoffs and sort of front-loading those.

[00:01:49] So instead of splitting that same number of layoffs across two months, just doing it all at once in November. Um, and then. In January with new financial fears, starting new budgets. Uh, Annual decisions being made. In this fearful atmosphere management is biasing towards reducing expenses and lengthening runways, which I think is why there was such a large spike in January.

[00:02:17] I also want to note that the first time the us fed hiked interest rates was in March of 2022. So looking at how. Low layoffs were in the first months of 2022, and then seeing how they spiked, or rather how they grew over time through the rest of the year. I think that a large part of the thrashing, ensuring that we're seeing right now in layoffs and, um, poor job climate is due to really national and global scale economic conditions.

[00:02:49] Uh, you know, there's no more zero interest rates, so no more zero interest rate phenomenons, and nobody quite knows what the. Important financial metrics to optimize for, and even what to target are in this new funding environment. So I think that's really important context to keep in mind when thinking about layoffs.

Conferences

[00:03:06] Carl Vitullo: Conferences coming up in the next two to three months. I'm just going to run through a couple.

[00:03:11] We've got React Paris going on in March, towards the end of March 22nd, in fact.

[00:03:17] Epic Web, which is hosted by Kent C. Dodds. That's going to be going on in April 11th in Park City, Utah.

[00:03:24] React Miami, April 19th and 20th, in Miami, obviously.

[00:03:29] Another Paris conference it looks like, or, I guess conference.

[00:03:33] Mark Erikson: It's an actual conference, and in fact, I will be speaking at React Connection Paris.

[00:03:37] Carl Vitullo: React Connection, React Native Connection, April 22nd in Paris. That's two Paris conferences exactly one month apart. So that's neat.

[00:03:46] And React Conf, the React Conf, is happening for the first time in three or four years. So that's, we're going to talk more about that later, but definitely pretty excited to see what they've got to share.

Library releases

[00:03:58] Carl Vitullo: All right, continuing on. Some more quick hits before we dive into the real proper link discussion. A number of new releases, just like smaller libraries, that don't quite merit a full discussion round in the main segment. Just thought I'd run through them real quick.

[00:04:13] React ARIA from Adobe, which I As far as I understand is a component library more specifically aimed like the value proposition of it being accessibility, an area I always think of as an accessibility thing. That is a huge advantage of using a component toolkit like that is getting the long tail of smaller benefits like accessibility. So definitely interested to see that.

[00:04:36] Mark Erikson: The important bit to distinguish there is React Aria, the original form of it is actually a whole bunch of hooks that are kind of like the headless data type management. Here's a hook for managing slider data or something. And this specifically, I believe they've then built their own component library on top of that. You've always been able to use the hooks yourself in your own components, but they've now also built a set of components that make use of those hooks as well.

[00:05:04] Carl Vitullo: Starting from the core primitives, ironing out the functionality there and then exposing it for, through a different means of accessing it. That sounds really cool. I'm really into it.

[00:05:13] There are new ShadCN UI components. I don't have a list prepared to read off. Oh, yes I do. Carousel, drawer, pagination, resizable, a toast component called sonner, and a bunch of CLI updates. Yeah, love ShadCN UI. Love the concept. So, check it out.

[00:05:30] ESLint has a new version 9 alpha 0. Don't have anything prepared to speak about there. It's not ready for production use just to get feedback right now, but it caught my eye that there's a new major version of ESLint coming.

[00:05:44] Speaking of major versions, there is a major version of jQuery version 4 that is in the works. It's not released yet, but I caught discussion of the announcement blog post and upgrade guide, so cool! jQuery, blast from the past, love to see it.

[00:05:59] Two more here for you. There's date-fns v3. date-fns is definitely a great library. Good replacement tool for Moment, if you're still using Moment. And yeah, I love it. It's great. Major version.

[00:06:11] And last one. This is a little bit more of a stretch, but Rescript has Major Version 11 coming out. It's a compile to JavaScript typed language that I saw described as TypeScript the good parts. I haven't used it. I'm not super familiar with what its value proposition is, but yeah. New version. Seems cool. Love an experimental language.

[00:06:32] Mark Erikson: There is some amount of buzz around what was originally known as, let's see, what was it before Rescript? Something else that started with RE, and I can't think of it right now. The language itself started as a fork of OCaml with more JavaScript like syntax.

[00:06:49] Jordan Walke and Chung Lo and some other folks in the React community were really trying to push this around like 2017 or so. And it felt like there might be enough bleed over from the React community to make it a thing. And there was a whole series of forks around the tool and the language syntax that really killed any actual momentum it had.

[00:07:12] And that combined with TypeScript really taking over as the definitive way to write types for JavaScript. I feel like it's moment passed around 2017, so there's, you know, apparently some, still some development work ongoing, and there's, there's always arguments of, use a better language, and it fixes some of the issues with TypeScript and JavaScript, but I think in practice TypeScript is good enough at this point, and, and the ecosystem momentum is there.

[00:07:40] Carl Vitullo: Tile to JavaScript language is a pretty hard sell on starting. If you're going to start a new product that they're going to maintain for years, it's a big swing to try and use a brand new language. But I always appreciate seeing experimental languages. I think that's where a lot of the experimentation happens.

[00:07:56] And then maybe some of the learnings from running a language like that will be brought back into JavaScript, the ECMAScript process, or into TypeScript itself. Love to see it.

[00:08:07]

React Libraries for 2024 by Robin Wieruch

[00:08:08] Carl Vitullo: We're going to start off talking about React libraries for 2024 from Robin Wieruch, which I hope I'm not butchering that too badly.

[00:08:16] Mark Erikson: I don't know how to pronounce his last name either.

[00:08:18] Carl Vitullo: Robin has been publishing very high quality blog posts and explanations and Just great content for years and years. I remember reading his stuff way back in 2015, 16, I want to say. And this is yet another in the same vein. It's a huge, very comprehensive list of recommended tools for all sorts of different aspects of building a real production website.

[00:08:45] I mean, the table of contents, it's A full page on its own. Starting a new project, package manager, state management, data fetching, authentication, database, testing, rich text editor, drag and drop, mail. Just, it's a great list. Definitely worth reading, definitely worth checking out, especially if you're in a position of spinning up a new Greenfield project.

[00:09:05] Something like that.

[00:09:07] Mark Erikson: And, and actually on, on that note, uh, Robin also just put up a post, um, talking about how to actually create a new React project in 2024. His argument, not surprisingly, is start with Vite, especially if you're learning, it's, it's simpler, there's Fewer concepts to learn at once, and then here's when you would consider Vite, here's when you would consider Next, here's when you would consider Astro.

[00:09:31] Carl Vitullo: What I have found myself reaching for personally when I'm starting out has been either just whatever Next or Remix. They both ship starter kits, but I've been using React for 10 years. I appreciate the concept of a novelty budget when working with a, uh, starting a new project. So, limiting the number of new concepts you're exposing yourself to is definitely smart advice.

Rising Stars on GitHub

[00:09:54] Carl Vitullo: Very cool. Somewhat related, I came across a Rising Stars Annual award thing. It's a tracking open source projects that gained the most stars on GitHub over 2023. Pretty cool. Top 10, I think, for the React ecosystem were ShadCNUI, Excalidraw which I don't know, it's a, it's not a library. It's not really a React tool.

[00:10:21] I know it was created by. Christopher Chedeau . Christopher Chedeau, thank you. So I think that's why it's in here. I love it, but it's not, I don't know if I would call it a React project. Anyway, it did beat out Next. JS though, that's number three. Zustand, number four, Refine, Docusaurus, love Docusaurus, CreateT3App, NextUI, Tremor, and Serverless stack.

[00:10:42] So that's the top 10. There's a whole lot more, and they had a bunch of different ecosystems represented. It's a pretty cool list, pretty neat to see. Yeah, I've seen a comment in the chat, sad not to see UnoCSS. That's a new one to me. Wanted to check out though.

Bytes.dev 2024 Predictions

[00:10:56] Carl Vitullo: Cool, yeah, another, keeping the thread of 2024, I don't know, analysis, predictions, Bytes, the Bytes. dev newsletter, which is one of the places that I pull links from to discuss, it put out a a list of predictions for 2024 and This is put out by Tyler McGinnis. He's been huge in the React ecosystem for years and years. I think bytes. dev is like one of the largest developer newsletters. Definitely a great source.

[00:11:23] Some of his predictions though,

[00:11:25] bun becomes the default runtime for the front end. That seems like a big swing. I don't know. Mark, what do you think about that?

[00:11:30] Mark Erikson: So the caveat here is that the Bytes newsletter is written in a very intentional tongue in cheek humorous style.

[00:11:38] There's real links and real thoughts, but Bytes is very much a sarcastic humor kind of newsletter rather than a strict straight to the point newsletter. So most of these predictions are very tongue in cheek.

[00:11:51] Carl Vitullo: Second prediction was more than three of your favorite open source software slash dev tool startups will die.

[00:11:57] Mark Erikson: I mean, that one's pretty much a given, right?

[00:11:59] Carl Vitullo: Yeah, right. Fair. But you could make that about any startup class over an annual timescale, but fair enough. AI will replace no code, low code tools. Seems plausible. Maybe not this year. Netlify gets acquired by GoDaddy. Yeah. Well, I don't know. I won't go through every single one, but I, one, another one that I did was no one will figure out what local first actually means.

[00:12:19] I have opinions there. I feel like local first is a good thing to strive for, but hopefully more people figure it out this year.(chuckles) Cool. Mark, you want to tell us about React 19?

Speculating on React 19

[00:12:29] Mark Erikson: Yes, so when we did this last month and we were doing some predictions for this year, saying that I expect React 19 to probably happen this year because we were seeing some initial discussions and mentions from the React team, and while we still don't actually have a timeline, there is a lot more activity going on.

[00:12:50] On that front, item one, Satya, one of the React Forget team members, happened to drop by one of our discussion threads over in the Tech Reads and News channel and said that the general discussion of the React team seems to be that the next stable release of React will be React 19, there hasn't been any specific discussions or plans around a React 18. 3 minor version, and that generally matches just the other bits and pieces of discussion I've seen so far.

[00:13:20] So we can probably expect that the next actual release will be React 19. One really big thing that came out In some Twitter threads is the idea that React might finally ship a form of context selectors.

[00:13:36] This was a proposal that was first done back in 2019 by Josh Story, who at the time was just a community member. He now currently works for Vercel building server side React stuff. Andrew Clarke played with a prototype of building context selectors in like 2020 and then it's the concept sat around and hasn't gone anywhere, especially with all the focus on suspense and server components.

[00:14:01] But in this discussion thread, the React team has said that their approach for implementing quote, context selectors And optimizing re renders when a component only needs one piece of data from a context will actually be to use the new named use, which is still horribly confusing. Like, you're going to be able to call the use hook inside of use memo, and that basically becomes like your selector function, in a sense.

[00:14:34] And that will actually allow React to look at the contents of what you've returned, and maybe even call the memo callback itself, separately from rendering, determine that, look, nothing actually changed, and actually be able to skip out of potential re renders that way. I don't know if this will actually be in React 19 yet, I don't know if it's Something that they've proof of concepted already, but that's, that is a pretty big deal.

[00:15:04] We've been waiting for that one for a while. Another one that we've been waiting for a very long time is proper web component support. React allows you to render web component elements. They're just, HTML string tags in that sense, but there's been lots of complexity around being able to accurately pass props into web components because of the differences between React passing around JavaScript values as props.

[00:15:31] Versus web components having attributes that are strings versus properties that have to be set via JavaScript. And I don't understand all the nuances there, I have not used web components. But a, like an issue was filed back in like 2017, complaining that React did not have correct support for interacting with web components.

[00:15:55] It took four years until someone from Meta finally went through all the arguments and proposals of what the exact semantics should be, and finally implemented An experimental feature that made them work right for React, but that feature has sat inexperimental for the last two plus years. And so they finally commented on that thread a couple weeks ago and said, this will be in React 19, finally.

[00:16:24] Carl Vitullo: I've never really used Web Components either. In a lot of ways, they felt like they were trying to solve the same challenges, or a similar set of challenges that React did. But in many ways, React seems to take on a much larger scope. I mean, I think that's exemplified by the emphasis on React Server Components now, where you Like web components are trying to componentize web and that's cool, that's great.

[00:16:50] But React has componentized UI across, I mean, it's used in mobile, it's used in web to make the UI for video games. It's crossing the server client boundary now in a very meaningful way. So I mean, that's why I've, that's why I have never used web components is because I have never felt a pain that they seem to solve that React was not already trying to solve on its own.

[00:17:14] Yeah, so I don't know. Cool to see it coming in though. It'll be interesting to have, cool to have it as another option. But I'm skeptical that it's going to be that meaningful in the grand scheme of things just because, okay, It's kind, it's, it's the new render target in a way.

[00:17:29] It's like not the normal DOM. You'd need a compatibility shim make it work with React Native. So I guess maybe that's a good analogy.

[00:17:39] Mark Erikson: There's been lots and lots of arguments. I mean, like a lot of web component fans hate React, you know, because it's too, it's too big. It's too much JavaScript.

[00:17:47] It tries to take over the, the browser, et cetera.

[00:17:49] Carl Vitullo: It doesn't use the platform. Yeah.

[00:17:51] Mark Erikson: Right, right. I think the best pitch for web components plus React that would benefit from this new support is maybe your company has. The Vue apps and Angular apps and React apps, you're trying to have a unified design system and you build that design system as web components, so you only have to implement it once.

[00:18:14] And then you can now use those design components properly from within React.

[00:18:20] Carl Vitullo: Intuitively makes sense to me. I strongly suspect that the technical realities of making that work are going to be pretty painful. But yeah, cool. It sounds like a large team. kind of challenge. I don't know. But yeah, I think it, I think to me the mental model that makes sense for it is it's a little bit like dropping down into native code on React Native, but on the web.

[00:18:43] If you're using web components, you're, you're working at a lower level of abstraction than, than most components you would write in React.

[00:18:51] Mark Erikson: Yep. I've been complaining about the React teams, you know, seemingly single focus on server components to the Somewhat detriment of new features for the client side.

Upcoming client features in React

[00:19:01] Mark Erikson: Having said that, Rick Hanlon from the React team did recently put up a Twitter thread where he pointed out that there are a number of new features that work in the client and in some cases can be considered client side only. There's a, these are primarily a new series of built in hooks. poorly named UseHook, which can accept a promise and will be the new official trigger for suspense behavior.

[00:19:26] You could, you will also be able to call the UseHook and pass in a context object to grab the context value, and apparently you can actually call that inside of loops and non rendering functions like callbacks, and so there will be some very interesting flexibility out of that. There's some improvements to StartTransition and FormActions, and then some new hooks for FormState, FormStatus, and OptimisticUpdates.

[00:19:56] All those do exist in the latest Canaries, so if you're using Next. js, those are probably available, but they will hopefully actually become stable as part of React 19. So I do have a link under here where someone wrote a follow up article that actually gives some further details about some of those.

[00:20:15] And then, while it's not specifically listed in there, some other things we can expect are they will finally be removing some deprecated features like the Legacy Context API. Given that it's been deprecated for multiple years, I expect that very few people listening have ever actually used it. People have asked the React team to clean up dead features for a long time, and they're finally going to be doing some of that.

[00:20:38] And React 19 should also include the source maps work that I did.

[00:20:44] Carl Vitullo: Yeah, I mean I guess that's the big advantage. That's what you do with a major version release, is you remove all the things you deprecated over the, since the last release. So, with, what, 5 years? Since 18?

[00:20:56] Mark Erikson: No, 18, 18 came out in 21, sometime in 22, I think.

[00:21:03] Carl Vitullo: Oh, was it that recently? Okay. Yeah. I guess I'm conflating with hooks, so cool. Yeah. And just to enumerate the upcoming client features that Rick was excited about, there's use in two contact or. Two settings. There's usePromise, which, like you said, is the, uh, how we're going to be interacting with suspense or, yeah, interacting with suspense from now on.

[00:21:25] UseContext. I don't know, I don't, I appreciate this simplicity being added by this use hook, but calling it a use hook and then not having it follow the rules of hooks as has been established for many years. It just seems like it adds confusion to me. I don't know. We'll have to see how that shakes out.

[00:21:45] Mark Erikson: That plus the literal naming and how carefully I had to word that sentence for it to make any sense.

[00:21:52] Carl Vitullo: So, I don't know. We'll see. But yeah, async transitions in the start transition. Function, form actions for React server components, useFormState, useFormStatus, and useOptimistic. So there's our enumerated upcoming client features, so keep an eye out for those. I think those are currently available in a Canary release, so if you want to play with those.

[00:22:13] And very cool to have your source maps PR ship out. Finally! Ha ha ha. Looking forward to seeing that. Hopefully, I just want to see, I'd like to see people react like, oh my god, you can do this now! Ah, debugging got so much easier! Yeah.

[00:22:26] Mark Erikson: For the ten of us who actually try to debug into React.

[00:22:30] Carl Vitullo: Well, hopefully it'll make the stack traces easier to read anyway.

[00:22:33]

Remix SPA mode

[00:22:34] Carl Vitullo: Let's move on to some framework updates. Remix is working on a single page application mode, which I think is interesting. I think this makes a lot of sense as a general framing for things like Intuitively, I think my mental model for, like, different forms of complex web applications, there's solutions like Gatsby that did full static generation.

[00:22:57] Like, you can only, you do a build time and then you publish a bunch of HTML and JavaScript. Then the opposite of that would be like Next and Remix, which are full server client frameworks that help you figure out how to write code across that seam. So, Remix adding more flexibility to cover different areas in that spectrum, I think is really interesting.

[00:23:20] It's like a single page application, fully static assets shipped from a CDN to the client's browser. That has real use cases. That is the simplest way to host an application. Lowest cost, lowest upkeep, lowest deployment complexity, all of that. That's still a real niche that has real reasons to reach for that.

[00:23:39] Then, one step advanced from that is something that has a build time generation step. Then, up to the full server, able to respond to requests individually, that is sort of classic Remix or Next. So, I'm excited to see this. They mentioned that it's likely to stabilize as the Vite plugin that they, that we'd talked about, I think, last time, maybe November.

[00:24:04] But yeah, so SPA mode likely to stabilize alongside the Vite plugin. They're also looking at server component support. It sounds like they're going to be having some different Approaches from how Next is doing it. Yeah, curious to see what they come up with. Ryan Florence has been a little bit on a tear with some good tweets lately.

[00:24:24] Yeah, I don't know. It feels like something changed. It feels like he's been, uh, a little more visible, at least in my feed lately.

[00:24:31] Mark Erikson: He'd actually take it. 6 months mostly off Twitter, and at least I might have actually deleted his account at one point.

[00:24:37] Carl Vitullo: Yeah, that scans, because I had just felt like I didn't see anything from him for a long time, and I was wondering if that was, I don't know, my consumption habits changing, the algorithm giving me different things, but yeah. Good to see him back because a lot of this is top tier, really great info, really great news.

Next 14.1

[00:24:53] Carl Vitullo: Yeah. Okay. Moving on to from Remix to Next. Next shipped 14. 1. Just going to run through some of the changes. I haven't played with this myself, so just going to, I'm basically summarizing the blog post here. But yeah, they talk about performance improvements, lots of faster local server startup.

[00:25:12] Faster code updates, a lot faster, say up to 96. 3, very precise. Faster code updates with fast refresh. Faster initial route compiled without caching. And they mentioned that they're, it's not so okay. It looks like they've been adding a lot of caching to get rebuilds faster. They talk about. Adding, in the future, disk caching.

[00:25:32] So right now you start up the server, and every time you rebuild, the cache is there. The cache is warm. But starting the server has a cold cache, so it's slower. So a disk cache would dump that memory cache to disk, so that when you restart the server, it Still has a warm calf, so it starts up faster. Major trade off there is that you introduce a whole new category of caching bugs.

[00:25:55] I know when, many moons ago, when I was developing very actively on a Gatsby project, I remember one of my debugging steps. Once one A step less desperate than deleting node modules was deleting the cache. It will be cool to see if performance improvements come out of that. That is always something I'm aware of, just the increased complexity of additional layers of caching.

[00:26:18] They talk about improved self hosting, new documentation. for some custom cache handling. And I'm going to bring in another tweet that I saw, I don't know if I'll be able to get the link quickly, but I did see, um, a tweet from Dan Abramov in the context of Next. He mentioned that he thought it would be very valuable if Next shipped like a simple mode that did not have any of the advanced features that require The host, to be aware of it.

[00:26:47] So right now, a lot of things, a lot of features in Next only work exactly as advertised if you're also hosting on Vercel. And that's been a criticism, that's been a criticism especially in the context of Yes, thank you, Mark. Especially in the context of Next and Vercel having a lot of core team members for React, it being tightly coupled to a paid hosting provider rubs some people the wrong way.

[00:27:15] So I, that makes sense. I think that would be really cool to see, just make it a little bit more portable, especially as like the bleeding edge of React development. It would be nice if that was not required to be hosted on a specific platform.

[00:27:28] There's some other improvements, TurboPack improvements, developer experience improvements. One that I thought was minor but significant is push state and replace state support in AppRouter. I didn't realize this was missing or something you couldn't do, but yeah, sounds like now you can use the native browser history APIs while you're using the next AppRouter. Not specifically sure what that will enable, but Intuitively, it feels like it should open some new doors.

Annoyed at React roundup

[00:27:56] Carl Vitullo: Can we talk about all the people who are annoyed at React?

[00:27:59] Mark Erikson: Yes, let's. One of the hazards of being part of a large tool community, and especially one that is in some ways as controversial as React is, is that there's inevitably waves of discontent that come out. And we've seen this pop up in different ways over the years.

[00:28:18] I mean, 2017, 2018, there were a lot of people who were posting comments about how much they hated Redux and wanted to kill it. So this is not a new phenomenon, but there has been a very definite series of posts and sentiment from people over the last month or so expressing annoyance with React. And, I'll say this as a meta comment, the real problem at the moment is that there are 30 different overlapping semi related things that people are complaining about.

[00:28:51] And the problem is, everyone is complaining about a slightly different subset of problems, and It's making it impossible for anyone to actually have a clear and specific discussion about what things this person is actually upset about versus what someone else is upset about. There's complaints about React being tied to Vercel.

[00:29:14] There's complaints about React's versioning strategy. There's complaints about how the React team does marketing and DevRel or not. There's complaints about the fact that Next and Remix are highly listed in the React docs as tools to start projects. But Vite is relegated to an expandable details section that literally says, Well, I guess if you want to use this, we can't stop you.

[00:29:43] There's complaints about server components not being sufficiently documented in the actual React docs. And a lot of these complaints are very vibe related. Like, a lot of this stuff isn't specific, technical concerns, and so it's really hard for anyone to meaningfully and coherently discuss a lot of these complaints.

[00:30:09] So some of the current wave kicked off with Cassidy Williams. Very smart person, well known in the community, has been around for a while. Put up a post where she said she's kind of annoyed at React. It, it is a very, there's a lot of vibes in there. She's very real, she's very actually frustrated. At the same time, if you look at the list of things she says, it's several different pieces, and a lot of it isn't even technical.

[00:30:34] And, and I'm not discounting her frustration, I'm noting that it's the kind of frustration that can't be solved with. Let's put out a new release. Or something. There was another post that came out a couple days later in response called React, where are you going? Very well written, and it was actually, I believe Published by someone who works on a tool called React Cosmos and some of his complaints came because they'd been trying to update the tool to work properly with the next app router and server components and they got it working but it was a very hard effort and they had to make changes to the API that actually made it less, harder to work with. This person put up a post that expressed a different set of grapes, and among other things, actually suggested that maybe what we need is a new React framework That is owned by the community, and it has like, a steering committee of prominent React community members as like a starting point before we even actually begin any development.

[00:31:39] And the author actually tagged a whole bunch of people by name on both Twitter and the article, and I was one of the people tagged. So I went in and I wrote a pretty long comment where, you know, I was doing, trying to actually respond to some of the points in the article, but then also saying, look, there is a lot of confusion and miscommunication going on right now.

[00:32:01] And to be like, to be entirely frank, this has been frustrating for me. I'm, I read discussion. I want people to have meaningful discussion. And, okay, look, fine, it's, it's Twitter, it's, you know, Reddit, it's comment threads, I know too many people talking in too many places for it to be real discussion, but it would be nice if we could at least agree on what we're discussing, and the meta problem right now is that no one is.

[00:32:25] I have seriously considered writing a 5, 000 word blog post that is just, Here is the definitive list of the 30 different topics the React ecosystem is arguing about right now. Now that we have this list, please continue arguing, just know that you're, here are the specific things that we're discussing.

[00:32:44] Carl Vitullo: At the beginning of the argument, please make sure to enumerate which of these you are arguing about (both laugh). Yeah, yeah, I think the vibes you were talking about, especially in Cassidy's post, is, I think that's very real, but also the vibes are so important and impossible to measure that it's, I don't know, I think she had a really, One of the things that she talks about was it's frustrating that diversity efforts visibly took a backseat with React leadership, and there's just not as many voices from a variety of different people anymore.

[00:33:13] And, you know, like, how do you, like, what a vibe. That is such a vibe check kind of complaint, and Speaking of vibes, I picked up on a vibe that there were, there was a lot of frustration from within the core team about how the React documentation rewrite went, and yeah, that took a couple of years, and seemed like it really burned out quite a number of people on the core team.

[00:33:35] And if you are burned out from Social, political aspects of this technical work, then you don't have as much energy to bring to that technical work. So it's like, if there's problems with the vibes, then I don't know what the solution there is, but it feels like it's gonna just have a, like, downstream detriment across the board.

[00:33:53] Mark Erikson: There's a few other good articles and bits of discussion out there. Ryan Florence made a tweet saying he's still very much all in on React as the best way to build apps, but, you know, Remix is working on trying to Have an alternative vision for how do you build a full stack app other than Next?

[00:34:11] Tom McWright put out a post where he measured the times between React stable releases and noted that the time from 18. 2 until now, is going on a year and a half, I think, and that's the longest we've ever gone between official stable releases of React, and meanwhile you've got Next using Canary builds And so there's definitely frustration over how the versioning strategy is going right now. Andy Bell just put up a post, uh, in the last day or so, saying that React's getting a bit of a kicking lately.

[00:34:44] So a little bit of the meta commentary there. But it was actually a very well balanced post that said, Look, there's, there are different tools and different trade offs. Certainly the ecosystem, the web dev ecosystem has first swung hard in the direction of Client side rendering and now we're kind of back in a server side thing and where do web components fit in this?

[00:35:04] But it was actually a pretty decent take some time and think about the trade offs for your situation. In practice, none of this actually necessarily affects you, the individual developer, working on an app for your day job. But there is some value in having a sense of what the big conversation is.

[00:35:21] Because, honestly, my goal out of all this would be that the React DevRel team does a bunch of work to improve the React docs. I have repeatedly griped that there's a bunch of things that I think should be done in the React docs that I'm shocked that they haven't done yet. If there's anything that comes out of this discussion, I'd like to see a lot of docs improvements.

[00:35:43] Carl Vitullo: All of this conversation, all of this kind of annoyed, where are you going? Increasingly miffed, a bit of a kicking. Last month I went off on a little bit of a rant. I would say in defense of the React core team, like, I think they are truly at the bleeding edge of the web ecosystem.

[00:36:00] And I think that in a very real way, they have been setting the tone, setting the subject of discussion that everyone else then builds on. And in so many different dimensions, like, Hooks came out of nowhere and invented this new approach to designing an API for web frameworks. Like, nobody else, I can't think of another project and hooks came out that shipped an ESLint plugin as part of using it correctly.

[00:36:34] Okay, this has enough weird little trade offs of how we've made it work that we need supporting tooling in order to help you. use it correctly, use it well. And now, that's very common. Like, now that's something that, like, Tailwind does. So I, to me, that was something that the core, the React core team introduced to the ecosystem that, as part of API design, you also think about it more holistically, not just, okay, I import this module, what's the function signature?

[00:37:02] But, okay, I install this package, I import it, what does the error message look like? In my IDE, just a very user centered framing of how to do API design and thinking of what tools are they likely to already use, everything possible to give them the best experience we know how to do.

[00:37:22] Ryan Florence's tweet, he says, React is still the best rendering library for the web and the people behind it are doing are just doing their best and actually doing a great job. And I think that's extremely true. They are doing a really great job, but what they're trying to do is so advanced and so new that it's just really hard to get every detail of it right. And I think that part of the reason that they are now subject to so much criticism is because of how much they've gotten right in the past, and they've elevated the bar repeatedly, and so now the bar is super high and people have very high expectations.

RSC updates

[00:37:55] Carl Vitullo: Should we go on to RSCs? A lot of stuff there. What a month!

[00:37:59] Mark Erikson: Similar to some of the complaints, there was a really good post a few weeks ago called RSCs, the good, the bad, and the ugly. And one thing I appreciated was this was largely focused on technical aspects.

[00:38:09] Someone tried to use RSCs and gave a bunch of very specific feedback on here's what they're trying to do. Here are some of the pain points I ran into in terms of understanding, like, where do I put the use server versus use client markers? And then, I think there were some additional mentions at the bottom of bigger piece complaints about some of the direction of React and Next, but it was a good article overall, very well written, not Not flame bait, like this was a substantive technical discussion and criticism.

[00:38:42] Worth reading through that to get a sense of some of the pain points with Next and server components specifically. Which is part of the picture, the issue right now. Is there still really only one real production way to use server components right now. So, Lee Rob, uh, Lee Robinson, who's the primary dev rel.

[00:39:02] for Vercel and Next did put up a post responding to some of the points that were raised in the Good, Bad, and Ugly post. So, some back and forth there. You can get a, have a chance to compare the thoughts there. Dan Abramov has resumed blogging, and if you've been watching him on Twitter, he has been iterating in public, trying to figure out, like, what is, what are the best analogies and metaphors and tools.

[00:39:29] To try to get people to wrap their head around server components and the mindset shift that's involved. And in some ways this is kind of frustrating because he is rapid tweeting lots of different ideas, lots of different catchphrases. Server components are like this. Well, server components are like that.

[00:39:48] And he's been building on some of that and he's got a couple different blog posts up. And I think we probably linked one of them last time where he's building up a series of posts. lead you to think about server components, but he literally hasn't even mentioned the word server component yet. He's been trying to help you understand, where does code run?

[00:40:10] Sometimes code runs on one computer, sometimes code runs on another computer. What if we had a way to control where that code runs? so he's working up to a metaphor to help people understand the mental model behind server components. And so I know he said that this is turning into an actual blog post series, he's got a few more posts he wants to write, and so this post, the two Reacts, is trying to work towards that train of thought.

[00:40:41] There was another explainer post from someone else completely. called RSC is React Server Plus Component. One of the other debates on Twitter, and tying into the people are confused or annoyed, is that the term React Server Components is highly confusing, because they don't always have to run on a literal server.

[00:41:05] Like, not on a web server as we think about it. Like, they can be used at build time and generate static output. They are not strictly a server side rendering concept, and Dan has been frantically trying to make the point that, depending on how you use the technology, like, you could even use it, like, inside of a web worker or something?

[00:41:27] Like, what, server components really are, like, a pre rendering method that spits out Serialize, React, as JSON. It just so happens that most of the time, and especially with Next, that happens in response to an API request. This blog post is trying to make the argument that rather than saying React Server Components with the implication that it runs on a web server, it's think of your code as like a React Server, React Client split, and the code for React Server could run At anywhere, at any time, depending on the bundler and the system architecture.

[00:42:09] I realize there's a lot of semantics and technical nuance there, but I thought this was actually one of the better posts. And then there's, again, like I said, Dan has been trying to make the point that they don't require a literal web server. And then there's been a number of other different articles and discussion about this as well.

[00:42:25] So the mental model and how do you teach server components, I think, is. One of the biggest outstanding questions. And again, I would love to see more of this in the actual docs.

[00:42:35] Carl Vitullo: But, okay, so hopefully this is the putting it out there, ideating phase that then gets brought back in the rough draft, first pass.

[00:42:45] So hopefully this does get brought back into the documentation as well, but I don't know if that's been I don't know how consistently that's happened over the last year or two. Something about Dan's, the two Reacts posts that stood out to me, I think that he had something really good to say.

[00:43:00] I mean, just like the opening line of it was, I suppose I want to display something on your screen. Whether I want to display a web page, an interactive web app, or a native app you might download, at least two devices must be involved. Your device and mine. I think that is such a great, useful framing for what they're doing here.

[00:43:17] Why React server components? It's, there are always at least two machines, the developer's machine, whether that's a local computer that they're running a build on or a server or a serverless function being executed somewhere, and the client machine. There's always a client machine. There's always something else.

[00:43:38] So because of that, there's always going to be. Communication between those two and so that's my mental model for React server components is they are iterating on what that communication bridge looks like and how to interact with it.

[00:43:53] Mark Erikson: There's been lots of arguments about what would be a better name for server components.

[00:43:57] People have suggested dozens of different options. My vote would be React serialized components. I think that is the best retrofit for the acronym RSC and I think it's the best explanation technically in terms of what it does rather than the literal word server. You are serializing a component's output.

[00:44:19] What it does, what happens after that depends on the environment. Maybe you're going to turn it straight into HTML on the server. Maybe you're going to output a file to disk. But ultimately what's happening is there's a pass that serializes the element output and then does something with it.

[00:44:36] Carl Vitullo: Yeah, that actually makes a lot of sense.

[00:44:38] I don't know if I, I don't know if we want to coin a brand new Well, I don't know if this is coined, but anyway, that's interesting. That's a, that is a good framing for it. Serialized is a little bit more evocative of The benefits and constraints, then server. Of course there's a server. Yeah, okay. That's interesting, I like that.

[00:44:56] Okay, we're down to our last link, which I guess we'll just go right on

[00:45:00] Mark Erikson: ahead. Yes, so I have been happily highlighting the progress of the React Forget compiler over the last few months. So, there was a blog post in March of last year. Where they said, we're working on it. There were two different conference talks at React India and React Advanced where the React team actually said, we're working on it and here's some of our progress.

[00:45:20] There was a bit of very interesting discussion on Twitter a couple weeks ago where they talked a bit about some of the technical implementation. So, it is currently implemented as a Babel plugin. Having said that, the Babel plugin is basically just acting as a front end for the actual compiler logic.

[00:45:41] The compiler itself is currently written in TypeScript, I believe, and not strictly tied to Babel itself. So, there were some thoughts about, I mean, there was some discussion of, well, how fast is it to run? Can you use it for fast refresh? Could it be translated to Rust someday? And one of the other possibilities that came up, Meta has been working on something that they call Static Hermes.

[00:46:07] Hermes is the JavaScript engine that's used for React Native. It's a completely separate JavaScript implementation. And they've got a research project where they use the Hermes engine to compile your JavaScript or TypeScript code to a native binary. And have seen some interesting early results from that.

[00:46:29] One other possibility for maybe making the Forget compiler execute faster. Instead of translating it to Rust, maybe they compile the TypeScript code to native with Static Hermes. We'll still know ETA on when this comes out. I have my fingers crossed that we'll see you some more details about it at React Conf in May.

[00:46:47] But it was interesting to hear a bit more of the technical details of what it's taking to actually build this.

[00:46:54] Carl Vitullo: Yeah, definitely. I have not been following it super closely.

[00:46:57] Mark Erikson: That's why I'm here.

[00:46:58] Carl Vitullo: Yeah, right? Thank you. We can pay attention to slightly different things that overlap and have a great conversation (laughs).

[00:47:05] Yeah, my general M. O. on a lot of these experimental features is keep an eye out, know what they're called, check in once in a while, and then when they're released, cool, I have a framework for understanding why it exists. Excited to see what comes out of it, but I know this is I don't know. I've seen skepticism that it will be released in a timely manner, though it's not yet.

[00:47:26] I mean, I'm still catching up on server components, so I just don't have the mental bandwidth to also pay attention to a whole optimizing compiler as well. On to the lightning round. We've got a bunch of links here. I think we should just pick and choose rather than going fully down the list, but

⚡ Ryan Carniato, JS Frameworks into 2024

[00:47:40] Carl Vitullo: Ryan Carniato had a solid write up on JavaScript frameworks as we head into 2024.

[00:47:48] Mark, tell us what that giggle was about.

[00:47:50] Mark Erikson: So he's the author of SolidJS.

[00:47:52] Carl Vitullo: Okay. I did, I, okay. I did not recognize the name. I, sorry, but a lot of talk about signals. And so that makes a lot of sense.

[00:48:01] Mark Erikson: Yeah. Ryan's articles are always excellent. He is so good at. Discussing both technical details and trade offs and nuances. So his posts about what's going on in the front end ecosystem are always worth reading.

⚡ RSPack

[00:48:15] Mark Erikson: Next up, so, there's a tool called rsPack, and it is a of Webpack to Rust. Literally, they've implemented all of Webpack's public API in Rust. I think the engineers behind it work at ByteDance, a company that does TikTok.

[00:48:34] There's a second layer called rsbuild, which is like basically more of an ES builds API, but using rspack as. The implementation layer underneath and I recently saw a tweet suggesting that talking about they've got documentation on how to migrate from create React app to using RS build and I actually had a like my presentation slide tool set.

[00:49:02] I was using React App with Craco to override the webpack config. And I thought for several years, like, I should switch this over to Vite. But, one, I'm too lazy. Two, that's a rabbit hole. Three, I, my setup uses a webpack plugin in order to parse the markdown that I use to write my slides. And so, I was actually curious about this, and in about one hour, I was able to switch from my CRA setup to using RSBuild, and the compile time went from 30 seconds to one second.

[00:49:38] I then made it harder on myself and spent and burned like two hours trying to upgrade the version of the MDX markdown syntax that I could use. But that was a separate problem from doing the actual switch. So I know there's a lot of people who are trying to switch from create React app to Vite, and that's absolutely a thing you can do, but you might also want to look at using rsbuild instead, because it's webpack compatible and you might actually have to do less work to switch over.

[00:50:08] Yeah,

[00:50:09] Carl Vitullo: very cool. Very nice.

⚡ Benchmarking React Native styling

[00:50:10] Carl Vitullo: I saw a cool post on Reddit. Somebody made a project benchmarking different CSS and stylesheet implementations. It's basically a microbenchmarks list. I don't really know how applicable these are. I don't really know exactly what this would mean from a broader performance.

[00:50:27] perspective. But, you know, it looked like they put some real work into benchmarking a variety of different approaches in React Native for applying styles, and not sure how much more there is to say on that, though.

⚡ Weird things engineers believe about Web development

[00:50:40] Mark Erikson: Uh, one article that I really liked, a, an engineer who used to work on the internals of Mozilla Firefox, developing the browser itself, put up a post talking about weird things engineers believe about web development, and it was actually kind of a, here's the stuff that browser engineers think people care about, and then there's the stuff that web developers actually care about, and these are not necessarily the same thing.

[00:51:04] So, it was just an interesting check on the mindsets of the people using the browsers vs the people building the browsers. I think

[00:51:14] Carl Vitullo: this is a super important read. I think these are, I don't know, there's just this, you get this feedback cycle in knowledge where somebody learned something, they write about it, and then other people learn that from the people who wrote about it. And so you get like a game of telephone going on.

[00:51:31] So then several, multiple years later, everyone knows all of these things. But if you go back to the actual primary source, some of them are a little warped. Some of them are outright wrong. So this feels like that going back to the primary source. Somebody's up to date on what people claim they know, what the common knowledge is, but they have experience with the actual underlying technology that provides those constraints. So definitely, we recommend reading this.

⚡ Tea.xyz

[00:51:59] Carl Vitullo: I came across a cool project by the guy who created Homebrew, which is like the de facto dependency manager for macOS. It's like apt for Unix. But, so he is launching an open source software funding project that is I think blockchain based and whatever, so all of the whatever skepticism you have for that is probably warranted, but I'm always interested in new approaches for improving the economic situation of open source maintenance.

[00:52:32] It is notoriously a very thankless job kind of situation. Yeah, I don't know, Mark, I'm curious if you have any thoughts on this as the only open source maintainer between the two of us. But yeah, it's broadly interesting to me.

[00:52:45] Mark Erikson: I saw this mentioned, I didn't glance at it, so I don't have a lot of thoughts on this tool itself. The flip side is there's another tool in the same sort of space called thanks.

[00:52:57] dev. One of the complaints about How do we fund open source maintainers has always been the trickle effect. If I provide, if my project uses Jest, ESLint and Webpack and Babel, do I send funds just to those projects? What about all the dependencies those projects are built out of? And so there's been a couple of different attempts over the years to figure out like, how do you divvy this up?

[00:53:24] And one that I'm actually getting a little bit of something out of is this thanks. dev thing. So, companies like Sentry are donating chunks of money to this intermediary and the intermediary is scanning all the package JSONs and using a particular algorithm to figure out, like, what, what percentage each of the dependencies and sub dependencies that you would actually get, and, you know, full transparency, I'm not getting much out of this, but, you know, like, 15, 20 bucks every now and then, it's okay, it's non zero, okay, cool, thank you.

[00:53:58] Carl Vitullo: I get a similar amount of money from the Medium blogging I did five years ago. It's not nothing, it's not that much. Whether it's enough money to warrant the additional need to remember to add it as income when I file my taxes is debatable.

[00:54:11] But, yeah, I don't know. It's a hard problem. It's as yet unsolved. I'm always interested in seeing a new approach, trying to solve it. Analyzing package. json and things like that is cool. I kicked around the thought of trying to do a business in this space a number of years ago. Hey, we're Reactiflux. We have so many people donating their time to answering questions.

[00:54:32] Open source maintainers, but ultimately where I came down on it is it's just so hard to attribute relative value between different projects that like, okay, you can scan thousands, millions of package. json files to understand the dependencies and what depends a lot on this and but then there's also there's so many deep utility functions, deep utility modules that You look at the MP M and they're downloaded like billions of times and it's like that real, is that, should that get the most money outta this?

[00:55:06] I don't know. When I, when I was doing my own thought exercises and this never left thought land, I never did anything with these thoughts, but when I was thinking about it, it's, I don't know if you can get to the socially understood value versus. Any of the metrics that are available from analyzing dependencies, it seemed like too big of a gulf between the two of them to be obviously valuable to me, but I'm very cool to see anyone who is taking hard problem of open source funding and trying, building code, doing marketing, taking revenue and distributing it back out.

[00:55:41] Anyone doing that, I will support 100%.

⚡ everything on npm

[00:55:44] Mark Erikson: Yep, and then the last one I got is, there was a recent, I don't know, issue, problem, whatever, with the npm registry, where some folks were experimenting with, Is it possible to make a package that literally depends on every other package in the entire npm registry? And they actually ran into some problems doing this, because there's like a maximum size in your package, or maximum number of dependencies you can have for one package, and what they ended up doing was chunking it up, so the top level package depended on 15, 20 other sub packages, and each of those depended on 5 to 8 packages in all of the npm registry.

[00:56:26] What this resulted in, though, was it made it impossible to unpublish anything. From the entire NPM registry. Yet another weakness in both how NPM works and how people use NPM. First we had LeftPad, where we found out that unpublishing something dependent on by thousands of other libraries breaks everything.

[00:56:49] We've had a few other issues over the years, and now this one. It was dealt with, but people continue to find more ways to break NPM.

[00:56:57] Carl Vitullo: Alright, I'm gonna run through a couple here at the very end.

⚡ CodePen top 10

[00:57:00] Carl Vitullo: I loved this, CodePen put out a Top 10 CodePens of 2023. Love creative coding, love people just making little fun visual things.

[00:57:10] Just for the joy of it, just to explore a new concept or to make something pretty. Creative coding is not a, an aspect of software development that we have in Reactiflux, had a lot of, people do that in CodePen, people do that in Glitch, people do that in, there's other platforms that are very well suited to it, and we've just never gotten a lot of that energy in Reactiflux.

[00:57:30] But yeah, really cool, I loved some of these projects, definitely check it out, especially if you're looking for inspiration on a project to work on yourself.

⚡ V8 performance improvements

[00:57:37] Carl Vitullo: And last link from me, V8 Performance Improvements. This is, like, extremely nitty gritty, like, close to the metal kind of knowledge. It's probably not going to be very practical in, you know, you as a software developer.

[00:57:52] But they're adding yet another new level of optimizer, which is interesting. I don't know, I thought it was a good read. It's nice to understand a little bit more about how your code is being executed. There are specific people who will need to know implementation details like that. I know that the, I'm sure that the React core team has done a lot of performance optimization to ensure that the way their code is being interpreted and optimized and the way it runs through these processes results in a as close to optimal performance as possible.

[00:58:25] I have an affinity for this type of low level post about where our code runs. But yeah, I just thought it was interesting to go through a little bit of history. It's also been 16 years since V8 was released. 16 years since Chrome came out, which is wild. What an era. It's the new era of the web. Definitely check that out if you're interested in bare metal stuff.

[00:58:48] Thank you so much everyone for joining us. We'll be back on the last Wednesday of February here in the live stage or back in your podcast feed just as soon as we can. If you see anything newsworthy, definitely let us know in the tech reads and news channel of Reactiflux, but yeah, we also check. Quite a range of newsletters and other sources.

[00:59:08] Mark and I both moderate the React. js subreddit. I love bytes. dev, React Status, ThisWeekInReact. There's close to a dozen sources that I pull links from here. Thanks for joining us. See you next month.