TMiR 2025-02: Updated new project docs

Transcript from Tuesday February 25th, 2025

Carl: All right. Hello, everyone. Thank you for joining us for the February edition of This Month in React, where we recap And digest the recent developments in the ever evolving React and web ecosystem. Coming to you live from Reactiflux, the place for professional React developers, and supported by Infinite Red. [00:00]

But I am Carl. I'm a staff product developer and freelance community leader here at  Reactiflux, where I run community programs like these events and build tools to help keep the community operating. [00:16]

Mark: And I'm Mark. My day job is working at Replay. Io. We're building a time traveling debugger for JavaScript and figuring out how to integrate that with AI DevTools. And in my copious amounts of spare time, I both work on Redux and spend entirely too much time complaining about the React ecosystem. [00:26]

Carl: And also now writing documentation and long, enormous blog posts. I actually printed out your blog post that I offered to help you edit, and it was 50 pages long. 50 sheets of paper. [00:42]

Mark: I apologize to the forests that suffered for that one. [00:53]

Carl: It's entirely your fault. [00:56]

Yeah, our third co host, Mo, is off this month. He is very busy with work and things, and just needed to take some time, not in the right space to have this conversation this month, so he'll be back next time. [00:58]

Job market: FRED data, Layoffs.fyi

Carl: Some quick hits. Job market. I was hoping around December, January, it was looking like, I don't know, new quarter, new year, new budgets. I was cautiously optimistic from seeing activity in the job board, yada yada. But sadly that has not borne out. [01:11]

Microsoft Performance-Based Job Cuts Have Started

Carl: I guess, you know, maybe some small companies were hiring, but like, Meta is doing performance based layoffs. Microsoft is doing performance based layoffs. And talking to someone about the job market and the ecosystem, and they shared something that made me think differently about layoffs that are happening right now. [01:29]

Like, when the company is signaling that it is performance based, That is a very different situation than when you just get laid off. Like, was pointed out to me that like, if you have on your resume that you worked at Meta and that you got laid off January 2025, that is no longer, like, the golden ticket. You know, like, for many, many years, if you worked at one of these big tech companies, that was, like, pretty much, not a free pass, but, like, it opened a lot of doors. But now a lot of people are getting let go when the public messaging is we're letting go of low performers. And that is a very different environment to lose your job in. [01:46]

So that's, yeah, I hadn't really thought about that, but yeah, how the company messages, how they're letting people go definitely can have a huge impact. And I saw a quote from a Bloomberg article about the Microsoft layoffs. [02:23]

Microsoft Performance-Based Job Cuts Have Started

Carl: " Employees losing their job will see health care benefits end immediately. In three specific cases, employees were told that they weren't getting severance." [02:35]

So like, not only is, are they publicly signaling that these are like performance based and therefore really doing harm to the like future employment prospects, like they're not, they're being pretty stingy about these severance deals. [02:43]

Losing your health insurance with no notice. It's pretty brutal, like, that's, that's just rough. Especially, like, yeah, hopefully they weren't getting any active treatments. Ugh, anyway, that's all I'll say on that. [02:56]

Conferences (React, Javascript)

Carl: some upcoming conferences in March and April, [03:07]

React Paris March 20-21 Paris, France

Carl: we've got React Paris. March 20th and 21st. [03:10]

React Native Connection April 3–4 Paris, France

Carl: We've got React Native Connection, April 3rd and 4th, also in Paris. [03:14]

React Miami, Apr 17-18 Miami, FL, USA

Carl: we've got React Miami, coming up in April 17th And 18th. [03:19]

CityJS London April 23-25 London, UK

Carl: there's also CityJS London, April 23rd to 25th in London. [03:25]

Mark: Then whole slew of things in late May and early June. Conference season kicking off. [03:30]

Carl: Yeah, definitely. I need to actually book things. I don't have anything, I'm going to render Atlanta in June, but I don't have anything booked before then. Yeah, going to Brazil for 12 days is really kind of complicated by Soaked up a lot of my logistical planning. [03:35]

, Um, yeah, our sponsor. We are sponsored. We have a sponsor. [03:49]

Carl: Infinite Red is an expert React Native consultancy. It's been around since 2015. So basically the entire time that React Native has been around. They are our only sponsor in part because very few companies do as much as they do for the ecosystem. [03:53]

, and I just don't know Too many other companies that have done quite so much for quite so long. So very happy to be partnered with them in that way. They only do React Native and they've built over 75 apps for companies from startups to the biggest in the world. And other than being kind, great people who have done great things for the ecosystem, like hosting podcasts and organizing conferences, They are generally just a small team that focuses on like building for the long term. [04:07]

So if you are working at a company that's spinning up a new React Native project and needs to get build some expertise, definitely give them a call because they will actually not just build it, but they will work with you to help develop expertise and hit the ground running. Cool. [04:34]

New releases

Carl: onto some new releases. [04:48]

React Router 7.2

Carl: We've got React Router, putting out a minor release, 7.2. Looked pretty minor. The headline for me here is that they have a type safe HRF tool, which sounds pretty interesting if you can have type safety. That your links work like that's just neat. They have a new way of doing that how well it works remains to be seen, but it seems cool [04:50]

TS 5.8

Carl: We've also got TypeScript version 5. 8 with a bunch of stuff. Of course TypeScript new version [05:11]

Mark: thing that I'm interested in here is the new erasable syntax only flag. And for background on that, so TypeScript has always been described as, you know, a types only layer on top of JavaScript. But there are a few TypeScript features that actually do have some runtime code. Enums, I think a couple of the, a couple of the old legacy, um, syntax features as well. [05:18]

And so, there are a number of tools today which work to strip out TypeScript types. But if your code uses some of those features that do have some runtime code, they, they don't work right. And this actually matters a lot for things like Node's new TypeScript, Stripping support. [05:43]

And so, to try to work better with those tools, TS has added this erasable syntax flag, which I believe actually throws an error if you are using any of the syntax that has runtime output. So it's basically like a, an extra enforcement check to make sure that you're not using any of those features. And that way you can ensure that your code is compatible with just stripping the types as opposed to like a transpilation. That's actually a really big deal. [06:01]

Carl: Yeah, super helpful. And it's actually, that's like a reasonably large build time optimization if you can get away with it. Because if you're not actually analyzing the types while compiling the code, you're just doing the parsing and the output. Like that's a lot less work. And your, like, VS Code, our IDEs, our language servers are already surfacing most of those type errors. [06:29]

So, like, I think it's really neat to, for one, I have used this just Because it's less effort to stand up a new project. You know, if I can just lean on the language server, then that's just less code, fewer moving parts, fewer things to go wrong, fewer things to break when I pick the project back up in four months. [06:52]

but yeah, it's also like if you can move the actual type checking into like CI or something like that and just do it less frequently, that's, that can be a lot less work overall. Yeah, there was a relatively subtle thing, slightly smarter return types when generic arguments are used in conditional types. [07:08]

It's really specific and only a partial solution, but I've run into some problems like this. And the overall like pattern that they were showing off for this was like not super familiar with to me and looked useful. So like, I that caught my eye as like a kind of subtle but useful thing. [07:27]

They are adding support for using require to get ESM modules. Which is interesting, like this is, you know, a continuation of the long tail of complexity that the switch over to ES modules, standardized modules, is having. But like, cool, now we have one more way to run into fewer problems when In an ESM environment, but needing to depend on CommonJS code. [07:43]

it still does not allow you to require an ESM file that contains a top level await. [08:10]

Mark: Because require() is synchronous. [08:16]

Carl: yes, facts. Also added a new flag that just caught my eyes, like a nice, I don't know, LTS feature. They have a --module node18. So you can tell TypeScript what module, like parsing, what determines what modules to use, how it evaluates what modules are being imported? You can tell it to use specifically the behavior for node 18. [08:18]

I've done a lot of maintenance of legacy apps and weird edge cases like that, like, Oh, in the last five versions, they have changed in what order or in what manner modules are crawled. Stuff like that can cause so many weird, obnoxious, difficult to debug errors. [08:42]

Prettier 3.5

[09:01]

Carl: Cool, new version of Prettier. I saw they're adding an option, which they do not do very frequently, so that's cool. [09:01]

Mark: Looks like they're trying to let you configure how it formats collapsing objects. [09:07]

Carl: Useful. [09:12]

RTK Query v2.6.0

Mark: I am very pleased to announce that yesterday I shipped Redux Toolkit 2. 6, which now has infinite query support for RTKQuery. This has been our single most requested feature since RTK Query came out, and I started working on this back in October, after another user had submitted a draft PR to get a first proof of concept going. [09:12]

There was a lot of discussion, a lot of trying to figure out what the problem space is, and how to implement this properly. We ended up adopting the React Query public API design for this. And I had some discussions with Dominic Dorfmeister, the, you know, TK Dodo, the React Query Maintainer, who specifically gave us advice on why they ended up with this API design and how they implemented it. [09:34]

So, worked on this intermittently when I had time over the last few months and very happy to get this out the door. [09:58]

Standard Schema

Mark: There's also a, project or a standard, I guess, called Standard Schema, which is an attempt to, you know, sort of unify or find a common denominator between a bunch of the different TypeScript validation tools out there, like Zod and Valobot and Archetype. So apparently you can now say that your project needs Just the standard schema definitions, and then the end users can then swap in their preferred validation library where and where they want to. [10:04]

Astro 5.2 (also Astro 5.3)

Carl: there's also two Astro releases. There's 5. 2 and 5. 3. Looks like it's You know, relatively. Small iterative improvements. I was just reading a little bit more. Astro 5. 3 is talking about automatic session storage setup. And as someone who has opinions about off, And prefers, you know, session storage to jWTs for authentication, that caught my eye. [10:34]

I don't know a ton about this, but definitely anything that makes sessions a little bit easier to like wrangle and manage, is definitely nice. I've been, as an exercise, I've been building my own. Authentication from scratch in session storage with React Router v7. So that's just fresh on my mind. [10:59]

I would love to be able to tell you more about what the experience of using Astro is like, but I, I have tried and failed to start several projects because I just don't have time. I have too many different projects going on. But It always crosses my mind when I'm thinking about, like, a blog, or a static site, or things like that. Seems like a very good tool for those purposes. [11:18]

Turborepo 2.4

Carl: There's also TurboRepo 2. 4. TurboRepo is a great tool for managing monorepos. From the next team, and they've got a number of improvements to enhance your repository as they say Boundaries, watch mode caching, continuing the trend of Vercel dealing with caching issues and Versioned configuration validation from within your repository, interesting. And they've also got circular dependency recommendations for adopting Turbo repo in large repos more easily. That's interesting. I've run into so many circular dependency issues throughout my career that just very much catches my attention. Very neat. Cool. [11:35]

Mark: I spent time trying to squash those as well. [12:16]

Carl: Just the worst. So painful. [12:19]

Main Content

Carl: Cool. Into our main content. Mark, you wanna start us [12:20]

Sunsetting Create React App

Mark: All right, yes, yes, I, I have thoughts and opinions on this topic. So, in our last episode, as a Relatively brief recap. When React 19 came out, it broke Create React App because of a peer dependency version mismatch, where the old templates wanted React 18, but CRA tried to install React 19. So I spent a chunk of January griping about this and trying to say, this is broken and it needs to be fixed. [12:23]

That led to several heated discussions on Blue Sky with the React team about, and trying to convince them to fix it. And so, right before our last episode, I had filed an issue that recapped what was broken and why, and pointed to a couple of PRs that other people had filed to both fix the CRA templates and actually mark the Create React App repo and command line tool as deprecated, and the React team had actually taken action on that and merged the initial PRs And they hadn't actually put out a new release of Create React App that fixed the brokenness, but the changes were in there and they were trying to figure out the process for doing the releases. [12:53]

Along with that, though, I had specifically said that I felt the React Docs setup page ought to recommend Vite as, you know, the equivalent replacement tool. So that people being told, CRA is dead, don't use it, would have a direct equivalent tool to try to use. So that's where we left off a month ago. [13:38]

And the entire topic has continued significantly over the last few weeks. So, from my perspective, there were several additional debates going on, on, you know, BlueSky and Twitter and in the docs about, you know, what ought to be done as follow ups and, you know, what should be recommended as tools. [13:59]

And on my side, I had actually started writing a rather lengthy blog post that tried to cover a bunch of topics from how has React been developed over the years to erecting some community confusion, like. You know, the ongoing claims that Vercel is driving React development just to make money on servers, which is wrong. [14:20]

but also describing sort of my take on the history of interactions between the React team and the community and frustrations and miscommunications and docs problems and frameworks and all these different things. So I'd been working on that. In, you know, over the course of a couple of weeks and kind of like teasing my progress online. [14:42]

And I'd also been having discussion with some other maintainers and without having given specific details publicly, the React team actually reached out to folks like Tanner Linsley and myself and specifically said, we can, like, we can tell you're frustrated. We would like to hear your feedback directly. [15:04]

And so I know that, Joe from the React team had a call with Tanner Winsley, where Tanner expressed a lot of thoughts about, I think especially some of lack of new client functionality in React as well as where React was headed. And so, Joe and I had a call. In early February ish, where I summarized all my different concerns, and then there were a couple follow up calls, and, Carl and I actually were on one with, both Joe and Matt, where the React team talked about what they're trying to work on. [15:25]

In response to a lot of these discussions and feedback. One of the things they said was we're, we're preparing a blog post and some docs updates in response to CRA being dead. As well as even things like they've been talking about trying to have a new community working group for a while, but they've kind of gotten bogged down in what the logistics should be. [15:59]

So, based on that, I could see that the React team was very actively trying to listen to feedback and trying to take some actions in response. And so, I think it was later that week that the React team finished the draft of the blog post and the docs updates. They gave me a chance to review it and offer feedback and a bunch of other folks as well. [16:20]

And so they published that blog post and they, I did actually see that they had applied some of the feedback that I'd suggested. They did not apply all of the feedback that I suggested. [16:45]

Original “Sunsetting CRA” post vs Build a React app from Scratch

Mark: And this actually kind of got rather controversial again as I rather predicted that it would. They put up a blog post labeled Sunsetting Create React App, where they said, CRA is dead, here's all the things that it didn't include. [16:59]

There's better tools, but also we really, really, really, really, really think that people should be using frameworks that have routing and data fetching and everything else built in. And the first version of this blog post really, really emphasized the framework part. And they did make changes to the setup docs, but they also put up a new blog post that was called Building a React Framework. [17:14]

And so, you know, what, what everyone's been clamoring for is just recommend VEET in the setup page, please. And they didn't actually do that with this first update. They instead, what they said was, well, when you pick your own build tool and your own router. And your own data fetching library. What you're really doing is building your own framework badly. [17:39]

And I can understand the mindset behind that, but frankly, this was not a helpful approach for anyone actually reading the framework. If you are a learner or a beginner, or want to try to choose some other tools, what would be helpful is instructions that say, you can use one of these two or three build tools, you can use one of these couple routers, and one of these data fetching libraries, and at least giving people a valid direction to go with it. [18:07]

And instead, what we got was a pretty straightforward, page that said, if you don't want to use a framework, you can build your own framework. Step one, install Vite or Parcel. Step two, you're going to have to think about routing and data fetching and code splitting, and boy, these are complicated and you will never be able to do this by yourself. [18:35]

Don't do this, please! Use a framework instead. And that really was not helpful for the audience that was going to be reading it. And so I had tried to offer feedback saying I don't think this page is good before the post went up, and that was one of the things they did not listen to me on. [18:57]

Carl: Yeah, And it, it definitely feels like that the fe it seems like the feedback that you gave is in line with like community expectations. Just seeing the Reddit response to, you know, the comments on the Reddit post for this blog. I, you know, I saw like Rick Hanlin had replied to something and got down, voted to like, you know, minus 20, something like that. So, it does, just like for more data points coming, rolling in in real time around, the core team is out of step with expectations for the community. [19:16]

Mark: Yeah, so, you know, I, I understand what the React team is trying to accomplish, and in fact, actually, one of the, one of the most interesting data points that came out of those couple conversations with the team. So, they've said, since they started this frameworks emphasis that, Part of the goal is that, you know, they, they don't want people to start off with a single page app and then have to do like a major tool migration in order to add SSR functionality. [19:48]

What I didn't realize was a lot of their goal and mindset around this is actually around React app performance. And they are actually very sensitive and I've heard a lot of the criticism. From folks like Alex Russell that, you know, single page apps and the average React app are horribly performing tens of megabytes of JavaScript. [20:14]

Like, they're actually very, very sensitive to that criticism, and I don't think I'd realized how sensitive it was. Turns out that part of their reason for emphasizing frameworks Is, they feel that if most apps start with a framework by default, then on average, more React apps will have somewhat better loading performance, data fetching, code splitting performance, etc. [20:38]

That is actually one of the big drivers for why they recommend Framework so strongly, and I didn't realize how big a driver that was until they told me that themselves repeatedly. [21:05]

Carl: Yeah, I can understand that, and like, I don't think that's wrong. Like I have worked on so many different apps and so many of them have been like badly broken in different ways. Like shout out to the company I worked at that had a 45 minute Docker build that produced 36 megabytes of webpack output. Had six different copies of the app because every, Each of their six pages was a different entry point, so you literally had to download six copies of the app as you clicked around. [21:16]

So, like, I've lived that. I've seen that. That is true. Just facts. Also, I don't know, I guess it's maybe just like in this, I feel like it's an inherent tension to the goals of encouraging deep learning and, setting up default incentives that produce better outputs, better outcomes. [21:43]

Like, I feel like they're going very hard at, um, We know that this will produce better outcomes in aggregate. And I don't think they're wrong. I think they're correct to say that. But I don't think it's The ideal path for many individual developers. So I feel like this is, this is a tension between micro and macro. [22:04]

You know, they are taking the macro perspective of in aggregate, this will produce more good. And you and I maybe are looking at the micro of this is not filling the needs for these people specifically. Yeah, [22:23]

Mark: Yeah, so like, you know, I, I understand the, you know, make, make sure that you use a tool that has all the features you will ever need. So you don't have to migrate and make sure you use a tool that has all the optimizations built in. So you're getting good default performance. What it leaves out and ignores, though, is that. [22:39]

if you're a learner or a beginner, having fewer knobs and having fewer concepts to worry about is going to make it easier to learn. A lot of companies are in positions where they can't or don't want to use Node on the back end. They just want a very simple SPA. Um, there's a lot of people who, for good or bad reasons, don't like Node. [22:59]

The React team's emphasis on frameworks. They're suspicious of, you know, the, the incentives in Vercel. And so the React ecosystem is very large and for better or for worse, a lot of people are very happy building React apps the way we have for years. And so my perspective is that the thing that the maintainers should do is Provide recommendations, but also recognize that it is a broad ecosystem and at least say The way you're using react is valid and we recognize you and support you Even if you've made choices that we don't think are the most optimal and the problem is the one line emphasis on frameworks And the tone of the statements in the docs has basically told half the ecosystem, We don't care about you, and we think you're doing it wrong. [23:23]

Which is not very helpful. [24:17]

Carl: Yeah. For sure. Right? Like, I wanna, I wanna bring in a strong opinion I have, which is that the world is held together with shoestrings and duct tape. Like, everything in the world barely works. If you look too closely at anything, like, it's a miracle that things are functional. And, My impression is that the core team is kind of railing against that a little bit. [24:18]

Like, they wish things worked better. They wish that the world were a little bit more ordered. And they are meaningfully trying to shift, you know, they are exerting their influence on the world as the caretakers for a tool used by literally millions. So, yeah, I don't know. I guess, circling back a little bit, you had brought up, like, community working group and some chats. It's very early, but you and I and Jack Harrington and maybe some other folks are talking about what that might mean. What that might look like, what processes might be involved, and what outputs might be produced. [24:39]

So yeah, I don't know, maybe ReactiFlex can play a larger role in that conversation, in that, I don't know, activity. [25:19]

Backlash and confusion over initial version

Mark: Yep. So ultimately what happened was they put up the new docs PA and the new blog post and the docs page, and this spawned a bunch of controversy and outcry, lots of arguments on Reddit and Twitter and Blue Sky. And, you know, one ex, one example of this was, Evan You, you know, the Vite creator. Um, putting up a couple of tweets where he said that, you know, like, I, I just don't understand why the React team is refusing to reasonably recommend Veep. [25:26]

And, like, I'm, I'm happy to work with them, I just don't understand where they're going with this and why. And that actually got kind of a positive response. Rather, strongly worded initial response from a couple of React team devs that later got retracted and there were a bunch of follow on discussions. [25:56]

But, it's like, from my perspective, the React team has pretty explicitly stated what their goals are, and no one wants to take those statements at face value, which is Interesting. So last weekend, after like two days after the blog post and the docs updates had gone live, I was sitting around on a Sunday night and I'm like, I could try to offer more feedback and suggestions, but I did that once already and I knew what some of the responses would be and that's why I offered this feedback and they didn't take it and apply all of it. So what if I just take this into my own hands? [26:13]

Mark filed a PR to rewrite the docs, the React team closed that but based a new one off it

Mark: And I actually try rewriting the docs page and the blog post myself to try to get across the same message but with a better tone and actually provide better guidance and instruction on using React without a framework. So, I actually filed a PR a week ago that rewrote the docs page. [26:52]

And the next day the React team actually closed that PR, and I actually got a message on the side from Matt Carroll on the React team who said, you know, like, actually do thank you for doing the work on this, but it's not quite the direction we want to go with it. [27:14]

However, they did then open up a new PR that was explicitly intended to address a lot of the feedback from over the weekend. They did copy and paste several of the sections that I had had in my PR, as well as tweaking some other sections. And this did actually get merged. So, it did not have some of the phrasing and the writing approaches that I felt should be in there, but it is legitimately an improvement. [27:30]

And it does actually meet, I think, a minimum acceptable bar where it says, like, they changed the build a React framework page into build a React app from scratch, which is roughly the phrasing that I had used. And it does actually say, you know, you can use V or Parcel or RSPack and a data fetching library and a router. [27:59]

And so it's giving actual instructions And that is linked prominently from the intro paragraph on the main setup page, and it's linked at the bottom. And the setup page actually explicitly uses the word VEET in a paragraph. And so it's not ideal, it's not the exact phrasing I would want, but they did make a second round of changes. [28:24]

And they did listen to feedback, and I do think it meets a reasonable minimum bar of recognizing that you can use React without a framework, and here are steps to do so. So it's been painful, it's still not exactly what I'd like to see, but I think we've actually reached an acceptable state at this point. [28:47]

Carl: Heck yeah. All right, nice that it's ended in that spot. We haven't talked about this, but where have you landed on your giant blog posts? Are you still sitting on those? [29:09]

Mark: Yeah, I'm sitting on it, so Like I said, part one was a recap of the history of how the React project has been developed, the influences like Meta and Vercell, as well as, you know, dispelling conspiracy theories like Next is dr or Vercell is driving it just to make money. Part two was all the history of, you know, frustrations and good and bad interactions and everything else. [29:18]

And, you know, part of my goal was to document things, and part of my goal was to drive change. And it's ended up helping with the change, but indirectly. I did show the draft to the React team after a couple of our conversations, they, you know, frankly, they asked me not to publish it. [29:43]

they didn't tell me not to, they said I should consider not publishing, which is. But like, my goal with this was not to burn bridges. Instead, I wanted to push them to make changes to the docs, to make changes to the messaging. And, we talked, and they were listening, and they were in the process of making changes. [30:04]

So I felt that at a minimum, I ought to at least give them a chance to publish the doc updates and see how things would work out, because they were in the middle of that. And so now that they've done some of that, I feel like publishing the post in its current form would be like slamming, hitting them with a sledgehammer after they did some of the thing that I already asked them to do. [30:25]

And that doesn't feel good. So where I'm at right now, is I, I still think the first part the history and the conspiracy theories part is probably worth publishing stand alone, and I can probably just extract that. I feel like there's a lot of useful content in the second part, but I would, I would need to extract and restructure a lot of it, and I haven't had time to sit down and think about it, and frankly, after, I would actually like to think about something else for a while. [30:44]

So, I expect to end up publishing some of that content at some point, but it's not top of my priority list right now. [31:08]

Carl: That makes sense. Yeah, I actually did sit down with it and four highlighter pens and I feel like there's like four posts in there. I feel like there's your personal [31:17]

experiences of trying to make changes. There's the, like, summary. Oh, man, just like the oral history you captured of like, here's how things have evolved over the last, like, nine years. [31:25]

I feel like is really useful. But Yeah. So cool. Yeah, go sit on it. Don't think about it. I will come to you with thoughts that I have in a, in a number of weeks. [31:36]

Mark: Yeah. So overall, it's been a couple months of, you know, a lot of kind of painful discussion and, and a lot of drama and arguing, but I think we've ended up in a fairly good place by the end of it. So Create React app's officially dead. The docs have been updated. The docs say both, you know, use a framework and those recommendations are updated. [31:47]

But they also say you can build an app from scratch and here's concrete instructions on how to do so. The tone is a lot better. So we've, we've ended up in a fairly good point, but a lot of this has shown that there is a really big gap between, you know, the React team's vision of where they want to go with React versus how a lot of the ecosystem wants to use React and I, I don't think that's going to go away anytime soon. [32:07]

Yeah. And I, [32:37]

Carl: Yeah, would agree. That reminds me of, uh, Posts that I put on Blue Sky. Opinions. I feel like the current, like, conflict is a, an example of the different, perspectives, really. Like, in this post, I say it's a clash between the indie hackers, the corporate cogs, and the academics. [32:38]

Where, like, by background, I'm a corporate cog, like, I have always had a large team supporting me. And so, like, I was usually the guy, like, playing around in this code base, trying to make it work better for my colleagues, who were then the ones actually shipping, like, individual features. That's a very different setting than if you are, you know, an indie hacker doing your own things and just trying to ship features and functionality. [32:59]

Which is, again, a very different perspective from, the core team, who I'm considering the academics here. Like, I've said before in this podcast, like, I strongly feel that the React core team is managed more like a research project than anything else. And, you know, I, some signal in that, in that I got some, I think like two or three of the core team members responded to this. [33:24]

It was just like a, like, I'm just going to brag that they saw it and engaged. But yeah, like they have, the core team has had a very stable vision for what React could be really since 2013. Like from the beginning, they've talked about stuff like algebraic effects and functional programming and, you know, encapsulation component models. [33:47]

And if you're like, I've been paying close attention to that. So I feel like I have a reasonably clear understanding of what that vision is and has been. And so like, I can see that it's stable, but I think if you're not paying close attention to what they're doing, you're not watching this research team go. [34:08]

You're off dealing with your own projects, shipping code, building features. You know, setting up processes for your team, then I think that. Vision is actually really hard to gather, like just from resources, from reading the documentation, from reading, from following their social media feeds. I think it's really hard to catch up on what the vision is. [34:27]

So that's maybe a gap currently in like what's available. [34:48]

Mark: And I think that ties a lot into something that the team mentioned to us in the couple calls I had with them. So, like, we just said that they have a vision, and that's, that's very accurate and valid. And yet, in a lot of ways, I've learned that the vision is almost like a vague, amorphous thing that they're figuring out as they go. [34:53]

You know, it's not that they have, apparently it's not that, like, literally everyone is driving towards the one true vision all the time. It's that, in a lot of ways, are individuals going off and experimenting with things, and then it's almost every so often they get together and figure out, okay, we've played around with a lot of ideas. [35:13]

do we have a consensus on where we're going? And like, one of the things they said was that, you know, like, I've complained that they put up very infrequent updates on the blog, on, in terms of like, roadmaps and where they're going. Like, they've put up three React Labs posts almost like a year apart. [35:32]

And my assumption reading those was that, oh, well, like, clearly they already know what they're doing, and the blog posts are just documenting that plan. And Matt Carroll said it's actually the opposite. Like, they sort of look around at each other, it's like, we probably ought to put up an update post. What are we working on and do we have agreement on where we're going and so that the blog posts actually take them multiple months to write because it's almost like a forcing function to figure out like and actually nail down where they're headed. [35:51]

So that was actually really really surprising for me to hear. [36:26]

Carl: Yeah, and you know what it made me think of? The valve management structure, the flat Non hierarchical, anyone can work on whatever interests them, and if you want to get a project done, you have to pitch it to your colleagues. Which was famously, I don't know, Valve has its own vibe, and I don't know, it's like the vibe of Valve is not super far off from the vibe of React releases. [36:30]

You know, the uh, indefinite delays and lack of communication. So, yeah. [36:51]

Mark: So, you know, I, I think we're going to see them continue to push forward. I mean, even just in the last few weeks, seeing Sebastian working on implementing Vue transition support and some other pieces like that, they're going to keep building on these things and it's great to see the forward 19's out, but you know, there, there's a lot of people out there that are just very happy to keep using React essentially the way they have. [36:58]

And there's going to continue to be a mismatch because what they're, well, what they're doing is absolutely valid and fine at a technical level. It's not the direction that the React team is trying to push. And so that leaves a lot of people feeling. You know, left out, unsupported, on the outside, and in the worst cases, concerned that somehow, like, client side React is going to stop functioning someday, just because it's not part of the server emphasis. [37:25]

And I mean, anyone can look at, like, you want to be able to look at that and realize it'll never happen, but it shows you some of the, the vibes and the extrapolation happens that leave people concerned. Um, [37:57]

Between the Wires: An interview with MooTools contributors

Carl: Yeah, I feel like I re share this every couple of months, but I want to share again this resource from FreeCodeCamp where they interviewed a bunch of the React core team through the lens of let's talk about your past work on MooTools. So, like, this is, a now 8 year old interview with, Sebastian Morkabug, whose name I'm sure I'm saying incorrectly, but it's as close as I can get, Tom, Tom Acino and Christoph Poyer, now, Christoph Nakazawa, I believe. Those are still Major players in the current React world, and they have been collaborating since 2009. So, like, they are coming up on 16 years of working together on foundational tools for the web. Like, I never personally used Mutools. But it was a, you know, meaningful minority use tool competing with jQuery. [38:09]

And it remained relevant because I think in like 2014, 15, something like that, they wanted to do, wanted to release a new array tool, you know, an array primitive. And they couldn't because MooTools hadn't yet been released. But yeah, FlatMap, that was it. That was the one, FlatMap. SmooshGate. They couldn't release the standard because Mutools had monkey patched the Array object with its own FlatMap that was incompatible with the standard, and so releasing this would have broken the web. [39:09]

So, like, this team, the core team, has, more than ten years ago, First hand experience with what it means to engage with standards and what it means to break the web. So, like, that's part of why I give them so much leeway and, like, kudos on their approach. Because, like, they know how bad it is to get it wrong. [39:40]

They know that a decision you made 15 years ago can have lingering echoes. That prevent future work from happening. [40:04]

And like, that's a really hard lesson to learn. It's a really hard lesson to apply. [40:13]

Mark: The web is forever. [40:16]

Carl: The web is forever. [40:18]

Mark: So, it's, one of the other interesting points that came out of the discussions with Matt is that the React docs are very much aimed at beginners. And it's not just the tutorial, it's the setup guides. And I think that's, that's also some of the tension here is that people are not looking at the setup instructions page and saying, Oh, this list of tools is especially oriented for beginners. [40:19]

I know what I'm doing. I can make, make my own choices. And that's fine. People have been looking at that page and saying, well, it doesn't explicitly list VEET. Therefore, the React team must have something against Vite. It's somehow bad to use Vite, et cetera. And in my, in my own draft PR, I had tried to rework some of their, their own paragraphs and phrases into a page on web app architectures to provide some guidance on like, what is a server, like a single page app versus multi page versus SSR versus SSG. [40:48]

When might you want to use one versus the other? As a way of, like, applying some guidance to choosing a build tool. And they don't seem to want to go that direction yet, because it's not, in essence, it's not something a beginner should be worrying about immediately. And so I think that's another piece of the tension. [41:24]

In what people want to see listed in the docs recommendations versus React team actually is willing to cover, which then ties back to the thing that Carl and I have been tossing around, which is, what if we had, A fully community written set of recommendations and docs and guidance for using React in the real world as a supplement to the beginner oriented, getting started level official React docs. [41:46]

So we're still trying to figure out what that might look like and what the content might be. In fact, we're supposed to be talking about it literally right after this, [42:20]

but that's sort of a pitch. Like if the React docs are going to explicitly focus on the beginner use case, then it's kind of up to the community to officially, to quote unquote, officially document what it's like to expand beyond that. [42:28]

And how to use React properly in the real world. It's something that I, I had played around with trying to pitch this kind of a community doc site idea a few years ago. It didn't get off the ground and I'm, I'm hopeful that maybe this time around we can make something like that work. [42:43]

How to start a React Project [2025]

Mark: So as an example of this, Robin Weirich, who's a prolific React author and, tutor, Has put up a number of blog posts over the years with advice on, you know, common React libraries and tools. And so he's updated his post on how to start a React project for 2025 with a set of recommendations. And it's interesting to note how this is different than the actual React Docs setup page, because this one actually starts with prefer using Vite as the starting point. [42:58]

, actually discusses some trade offs, both pros and cons, for all the different tools. Talks about using Next, talks about using Astro, which the React docs don't mention at all. And so it's the same problem space, but a very different approach to describing what your choices are than the actual setup page. [43:30]

And on a similar note, So, with Create React app itself actually being officially deprecated. [43:50]

Jack Herrington published create-tsrouter-app under the Tanstack umbrella

Mark: Jack Harrington actually put together a Vite based starter kit called Create TS Router App with the idea that it would be a, basically a drop in replacement. For the old create react app command that you get a basically like instead of running create react app, you run create TS router app, you get a Vite based project with TanStack router built in. [43:56]

It has the same starting. Application component content and basically equivalent features, but you're starting with a modern set of functionality. You have routing built in, whereas CRA didn't come with a router. You can expand to file based routing if you want to. So, this has been moved into the TANstack organization, and it's now an official TANstack project, and it feels like a pretty useful tool. [44:23]

Carl: Yeah, I actually had talked to Jack, just coincidentally, not about this, shortly before he released that tool. And he, just talking to him about, like, create react app and the legacy of it, I realized that, like, the original, promise of create react app was for it to be an abstraction over your build tool. [44:49]

Over all of the build tools, and I hadn't really considered that that was really kind of, that promise never really realized, like, we, yeah, we had it for a while, but It took years for it to update from Webpack 4 to 5, for instance, and then it never released again. So it would, like, I remember at work arguing in support of using create react app instead of doing our own tooling, because, like, let's just never think about tooling again and just stay within the sandbox and get better. [45:09]

What we need out of it. And that promise just never quite happened. So yeah, I don't know that just Hearing it, hearing this TS router, create TS router tool Build as like sort of a drop in replacement for it It is a drop in replacement for the functionality But it does not even attempt to provide that same kind of like social contract promise of future maintenance Just inaccurate, correct. [45:38]

I mean, Create React app never lived up to that promise either, [46:03]

Mark: I would actually have a slightly different opinion. I would say it mostly fulfilled that promise. I would, I would agree that it never, it didn't achieve the goal of eliminating the need to think about build tools. In the cases of like the Webpack upgrade or, you know, the fact that the, The blackboxing of the webpack config meant you needed third party tools to alter the config, etc. [46:05]

So like, it didn't make those parts go away, but it did succeed in giving you a single command that would start a project without having to spend time on creating the build config yourself. Or using a boilerplate project or copy pasting it from your last working config. And that did enable tutorials to just say, run, create React app, and now let's start learning React, which was a big goal, as well as making it actually useful for real world, real world projects. [46:30]

So it didn't eliminate those concerns entirely, but I think it sufficiently succeeded in the goals of not having to think about it just to get started. [47:01]

Carl: I would agree with that. I understood it to be, to have a larger scope in mind of being an enduring abstraction that would evolve over time. And that didn't happen. Yeah. Anyway, Yeah. [47:10]

⚡ Lightning round ⚡

Carl: Oh man, we have so many lightning round links [47:24]

Mark: Lightning Round! [47:25]

Carl: Yeah, cool. All right, we're going to fly through this a little bit. [47:26]

Vercel acquires Tremor

Carl: Uh, Vercel bought an open source React, toolkit, which is interesting to me. Like, I hadn't heard about this in advance, but like, Tremor is apparently a open source React dashboard tool that was funded by Y Combinator in 2023, and now Vercel has bought them. So like, I don't really understand what it means for an open source library to be venture backed. [47:29]

, but like I'm generally supportive of it. Like I would love it if open source maintainers could paid for the work that they do, which is meaningful and impactful and takes a lot of effort. It's a little bit unfortunate to me that the model by which you can get paid for that work seems to be rich dudes in tech decide that they're going to give you money and then other rich dudes in tech buy that work from you. [47:53]

But yeah, that was just interesting. That seems like an outlier. I have not heard of very many open source tools either getting VC funding or getting acquired. Really, Remix is the only other example that comes to mind. [48:18]

Things people get wrong about Electron

Carl: Yeah, I saw a fun post titled, Things People Get Wrong About Electron. And just sort of a fringe at, you know, a fringe post talking about tech kind of at the margins. [48:29]

Like, I have written a re an Electron app in, like, 2015. Oh my god, 10 years ago. Ugh, I'm so old. But yeah, just, it's neat. It's fun to see such a different context for the web. Definitely recommend checking that out. Just as a, as a curiosity, really. [48:41]

Initial Observables support in Chrome 135, Observable API

Mark: So, there's been a decade long effort to try to get some form of observables baked into the browser. Ben Lesh of RxJS has been beating this drum for years, and it looks like they've finally succeeded in getting some of it. Some form of observables actually baked into the browser. It seems partially limited in scope, partially related to, event handlers, but I think it's at least a starting point for adding this kind of an API directly. [48:57]

And so Ben's pretty excited about that. Also on, also on the note of just, you know, really good deep dive technical articles. [49:25]

Why I rebuilt ProseMirror’s renderer in React

Mark: someone who used to work for the New York Times talked about taking the pros mirror rich text editing library, which is partially react related, but partially independent. [49:33]

, and rebuilding the ProseMirrorRenderer directly in React on top of the data structures. Great article, very well written. [49:43]

JavaScript Temporal is coming

[49:52]

Carl: Mozilla had a post at the end of January, about Temporal. JavaScript Temporal is coming. Dates in JavaScript are garbage. They are awful. My favorite example of a specific way they're awful is that they have no concept of time zone. And so every date uses your local system time zone, Which is absolutely awful. [49:53]

If you're trying to do anything involving time in two different locations, [50:13]

Mark: is why we've had Moment and DateFunctions and Lexon and who knows how many other libraries. [50:18]

Carl: All fine. So Temporal is a new, date standard tool, standard library for JavaScript doing dates and it's coming. I hope it's good. I haven't really played with it. I tend, I don't want to think about dates, so I don't want to think about them any more than I have to. And so I haven't really looked at this. [50:24]

It's coming. It's soon. That was a good post. [50:41]

Do JavaScript frameworks still need portals?

Carl: this was kind of neat. Do JavaScript frameworks still need portals? React has had portals for a long time for like, rendering stuff like modals or tooltips or popovers that exist like, outside of the hierarchy, quote unquote. Just sort of as a way of rendering something within the component tree, but not having the DOM output be in the same hierarchy. [50:44]

And that comes with all sorts of quirks and weird bits. Like z index can get really weird. Think it's awkward and funky for like cross platform stuff. I don't know how well it works in React Native or, you know, other contexts to make use of these portals. So just like this was a kind of fringe topic, like how often do you think about using React portals? [51:07]

And so just like reevaluating, like, are they still necessary? Do they still, is the problem that they were introduced to solve Still relevant in 2025. And I thought that was a good question to ask regardless of what the answer is. [51:33]

What Do We Do with You, Old React?

Mark: we've had years of migrating from other frameworks to React, and we've now had two or three different eras of different styles of React code. So, now you can migrate and modernize your old React code to modern React code. And so there was a good post called, what do we do with you old React that just gave some quick examples of migrating from things like class components to function components and old Redux to modern Redux and old testing approaches to React testing library. [51:46]

, nothing fancy. A lot of this has been covered elsewhere, but it was a good, useful summary. [52:14]

“Records and Tuples” proposal is now “Composites”

Mark: And finally, for the last couple, last few years, we've had a work in progress TC39 proposal called records and tuples, which was an attempt to build fully deeply equal objects and arrays directly into the runtime so that you don't have, so that you could just use like the triple equals operator and it would do like a deep equality comparison of all the fields rather cheaply, rather than having to use a library like immutable. [52:18]

js. And this proposal has apparently just undergone a significant revision. It's, I guess it's no longer even called records and tuples, and instead they're calling the objects composites instead, and you would need to call a specific composite. Equals method to compare them. I saw the tweet, I skimmed through the readme of the summary of the changes, I have not had a chance to look through the slides yet, but it's interesting to see how this proposal keeps evolving. [52:48]

Carl: Neat. Super cool. Oh yeah. That was all of our lightning round links in like less than 10 minutes. For sure. Proud of [53:19]

Mark: us! [53:24]

Carl: Cool. Thank you everyone for joining us. That's all we got this month. We'll be back on the last Wednesday of the month, for real this time, I think. [53:25]

, uh, we'll be back at the end of the month in the live stage here in React to Flux or back in your podcast feed just as soon as we can after that. I try to get it by the first of the month, but not always. We gather sources from This Week in React, Bytes. Dev, React Status, Next. Js Weekly. The React. Js subreddit, here in  Reactiflux, and directly from those publishing articles as well. If you see anything newsworthy, definitely let us know in the tech news and reads channel here in  Reactiflux, or shoot us an email at hello at  Reactiflux dot com, with TMIR in the subject line if you can. I read literally everything that comes in, even spam and whatever, so if you send it, I'll read it for sure. [53:32]

And if this is a show that you get value from and want to support, the best way you can do so is by either submitting a review or telling your friends and coworkers about it. Like, if this was useful, just like, send it to one other person. That would actually do a lot for us. Cool! Thank you so much for joining us! [54:09]

Mark: Thanks, appreciate it, and hopefully we'll have less drama to talk about next month. [54:24]

Carl: Maybe. [54:28]