TMiR 2025-10: Post-conf; React 19.2, React Foundation, React Native removing old architecture. Next.js has too many directives의 전체 녹취록

so that makes sense. 00:03:47.801 --> 00:03:52.301 He is basically already doing that role and expanding what the core team 00:03:52.331 --> 00:03:55.841 means to an intercompany organization. 00:03:55.961 --> 00:03:59.111 But yeah, it's a lot of the details that I was most curious about, like what 00:03:59.111 --> 00:04:01.786 does, what does this mean for governance? 00:04:01.786 --> 00:04:05.746 Like how will decisions be made are not yet answered right now from 00:04:05.746 --> 00:04:08.326 the, from the various posts on this. 00:04:08.746 --> 00:04:11.836 A quote is, the React team is actively working on this new technical 00:04:11.836 --> 00:04:14.566 governance structure, and we'll share more details in a future post. 00:04:14.656 --> 00:04:18.136 So this is an announcement of a future announcement in some 00:04:18.136 --> 00:04:19.441 ways, but it's pretty real. 00:04:19.621 --> 00:04:22.766 So this is in collaboration with the Open JS Foundation, which is 00:04:22.766 --> 00:04:24.356 a partner to the Linux Foundation. 00:04:24.356 --> 00:04:30.896 So like th these are very large, pretty well-founded organizations that the React 00:04:30.896 --> 00:04:37.526 team is glomming onto in support of like a neutral home for React, as they call it. 00:04:38.036 --> 00:04:42.776 It's sounds like they're in incorporating React Native into this as well, which 00:04:42.776 --> 00:04:44.276 I think is not necessarily a given. 00:04:44.276 --> 00:04:48.056 You know, if you're talking about the governance of React, what that means for 00:04:48.056 --> 00:04:50.456 React Native is not necessarily implied. 00:04:50.906 --> 00:04:54.266 But just looking at the founding members like Amazon, Call Stack, 00:04:54.266 --> 00:04:58.586 Software Mansion, and Expo, and I guess Microsoft too, like those are 00:04:58.586 --> 00:05:00.926 all heavy React native investors. 00:05:01.316 --> 00:05:05.096 Mo: I think it's quite surprising in that sense because it's more 00:05:05.096 --> 00:05:07.106 heavy on the React native side. 00:05:07.586 --> 00:05:12.326 Like Vercel is really the key sort of non-react native player. 00:05:12.326 --> 00:05:16.646 The rest are really heavy on React Native and there's like noticeably 00:05:16.646 --> 00:05:20.846 missing membership from like Shopify on the Remix side as an example. 00:05:21.341 --> 00:05:24.056 I, I actually find it's very skewed towards React Native, almost shockingly. 00:05:24.566 --> 00:05:25.376 Carl: Yeah, I'd agree with that. 00:05:25.436 --> 00:05:27.261 It's, it is almost shockingly skewed towards React. 00:05:27.266 --> 00:05:32.936 React Native, given that it was not really pitched as the React Native foundation. 00:05:33.356 --> 00:05:34.016 That's true. 00:05:34.316 --> 00:05:38.366 I guess Software Mansion does do a fair amount of web React work. 00:05:38.801 --> 00:05:42.101 But I, I believe Call Stack is predominantly a React native shop as well. 00:05:42.281 --> 00:05:46.301 Mark: So I'll do my usual thing where I, I step back and provide historical 00:05:46.301 --> 00:05:48.911 context and what matter at all. 00:05:49.421 --> 00:05:52.241 So React was invented at Facebook. 00:05:52.631 --> 00:05:57.221 It has always been a project owned by Facebook and Meta. 00:05:57.731 --> 00:06:00.461 The code has been open source, but. 00:06:01.026 --> 00:06:05.526 You know, for years the entire development team was Facebook meta 00:06:05.526 --> 00:06:09.096 employees paid by Meta to work on React. 00:06:09.666 --> 00:06:15.686 And I've said even in my conference talks this year about Meta, Vercel, React 00:06:15.976 --> 00:06:19.866 ownership, that the React team has had the freedom to work on what they want. 00:06:19.926 --> 00:06:24.816 And that's true, but I've, I was reminded in some conversations with 00:06:24.816 --> 00:06:30.486 React team members at React Con, how much their work is constrained by, 00:06:30.906 --> 00:06:35.226 like the fact that their performance reviews are, "what have you done 00:06:35.226 --> 00:06:38.316 to further meta's goals this year?" 00:06:38.856 --> 00:06:44.646 And so in some ways their ability to push React in the technical directions that 00:06:44.646 --> 00:06:49.986 they think are right, are limited by how much they can make the case for that. 00:06:50.421 --> 00:06:55.281 Inside Meta, even something like the Concurrent Stores work is 00:06:55.281 --> 00:06:59.481 essentially being pitched as, how can we make Facebook's Ads Manager 00:06:59.481 --> 00:07:01.851 app faster in a lot of ways? 00:07:02.571 --> 00:07:07.041 So we saw multiple React team members move over to Vercel. 00:07:07.101 --> 00:07:11.001 Like people used to complain that this is all a Facebook app, all 00:07:11.001 --> 00:07:12.651 the meetings are inside Meta. 00:07:13.041 --> 00:07:16.161 There's no public roadmap, it's only meta. 00:07:16.671 --> 00:07:20.451 And then we had team members move to Vercel, and then it became, well, now 00:07:20.451 --> 00:07:24.441 Vercel is applying too much ownership to React and all the stuff we've talked 00:07:24.441 --> 00:07:28.821 about with Next and server components and Vercel and how that's supposedly 00:07:28.821 --> 00:07:30.261 driving the roadmap, et cetera. 00:07:30.821 --> 00:07:34.751 And so the team itself has been split across two companies, 00:07:35.261 --> 00:07:36.761 and they're working together. 00:07:36.821 --> 00:07:40.691 It's one team, but it's kind of within these two companies. 00:07:41.201 --> 00:07:46.061 And so because of Reacts widespread usage, there's been calls for many, 00:07:46.061 --> 00:07:50.771 many years that there ought to be some kind of an independent foundation 00:07:51.221 --> 00:07:56.411 that would own the trademarks, the rights, the development process. 00:07:56.846 --> 00:07:58.226 To React itself. 00:07:58.736 --> 00:08:00.866 And it always seemed kinda like one of those pipe dreams.

00:08:01.106 --> 00:08:04.376 The calls on Twitter to build, React into the browser. 00:08:04.496 --> 00:08:06.446 And obviously there's no way that's going to happen. 00:08:06.671 --> 00:08:09.566 And, and this felt like much of the same kind of idea. 00:08:10.046 --> 00:08:14.696 And so they, they did the initial React and the initial keynote at 00:08:14.696 --> 00:08:17.426 React Con, and they were mostly focusing on technical things. 00:08:17.426 --> 00:08:22.856 Like last year we, we fixed the, the sibling preloading bug. 00:08:22.856 --> 00:08:26.636 That was the suspense gate problem that everyone was talking about last year. 00:08:26.636 --> 00:08:30.116 And 19.2 came out and the compiler is 1.0. 00:08:30.626 --> 00:08:34.226 And then Seth came out and he did the one more thing routine 00:08:34.736 --> 00:08:40.526 and as soon as he put the React Foundation slide up, my jaw dropped. 00:08:40.766 --> 00:08:44.006 And I think I even said out loud, oh my word, they actually did it. 00:08:44.546 --> 00:08:49.256 And my first reaction was, even without knowing. 00:08:49.796 --> 00:08:53.906 Any actual details about what the foundation is or how it's going 00:08:53.906 --> 00:08:57.086 to work or whether this is even going to work out in practice. 00:08:57.596 --> 00:09:02.426 The fact that they have taken the time to do the legal preparation work to try 00:09:02.426 --> 00:09:08.486 to make this happen and are actually attempting to execute on that is a 00:09:08.486 --> 00:09:11.996 huge deal for React and the ecosystem. 00:09:12.446 --> 00:09:17.906 It, it is a statement of good faith and intent for how they want 00:09:17.906 --> 00:09:20.066 React to proceed in the future. 00:09:20.456 --> 00:09:25.526 Like without any details, my immediate reaction is, yes, finally, 00:09:25.526 --> 00:09:27.206 this is a good step forward. 00:09:27.716 --> 00:09:32.396 We'll see what it means in practice, but this is a really big deal. 00:09:32.936 --> 00:09:34.616 Carl: Yeah, I would agree with that. 00:09:34.676 --> 00:09:37.466 It's a really big deal that they're moving in this direction. 00:09:37.766 --> 00:09:41.396 I'm really curious about the details because I think there's a lot of, I 00:09:41.396 --> 00:09:44.996 don't know, like in the past they've done working groups and et cetera. 00:09:45.401 --> 00:09:48.671 And my understanding of the takeaway is generally, has generally been 00:09:48.671 --> 00:09:54.101 that they found it really difficult to manage participation in those 00:09:54.101 --> 00:09:56.321 like open access kind of arenas. 00:09:56.771 --> 00:10:01.121 So maybe the, this is kind of like adding a new layer of abstraction perhaps with 00:10:01.811 --> 00:10:08.291 administrative support from currently thriving independent foundations. 00:10:08.591 --> 00:10:08.681 Mm-hmm. 00:10:08.921 --> 00:10:13.391 So that, that definitely makes me think that this has a real chance 00:10:13.391 --> 00:10:17.471 of being something real and valuable that goes on for a long time. 00:10:17.981 --> 00:10:22.091 I'm curious what it means for things like, like in practice, it's not 00:10:22.091 --> 00:10:23.891 like anyone's employer is changing. 00:10:23.951 --> 00:10:25.391 No details have been shared yet. 00:10:25.391 --> 00:10:29.441 At least that anyone is being paid from this new foundation. 00:10:29.771 --> 00:10:34.061 I, I don't know whether to call it meta or Facebook 'cause it's on the fb.com domain. 00:10:34.241 --> 00:10:34.361 Mm-hmm. 00:10:34.601 --> 00:10:37.721 But in the Facebook engineering announcement here, they do say that Meta 00:10:37.721 --> 00:10:41.531 has committed to a five year partnership with over $3 million in funding. 00:10:42.146 --> 00:10:43.586 I don't know what other funding they might have. 00:10:43.586 --> 00:10:45.986 I don't know what other sources of funding they might have in the future, 00:10:45.986 --> 00:10:51.896 but like just looking at five years, $3 million, like that's 600,000 per 00:10:51.896 --> 00:10:56.816 year, which is like, you know, for meta engineers, that's like free engineers. 00:10:57.296 --> 00:10:58.826 So I don't know. 00:10:58.826 --> 00:11:01.556 I don't know what that means for people's incentives and where they 00:11:01.556 --> 00:11:04.736 will work and how their focus and performance will be evaluated. 00:11:04.796 --> 00:11:05.006 Yeah. 00:11:05.366 --> 00:11:10.136 Mo: What that rules out is that effectively the React Native or React and 00:11:10.136 --> 00:11:14.246 React Native Core teams will definitely not be unemployed by the React Foundation. 00:11:14.531 --> 00:11:14.881 Right. 00:11:14.886 --> 00:11:18.236 'cause that would basically cover three salaries, which is far smaller 00:11:18.236 --> 00:11:19.466 than what the React teams are. 00:11:19.826 --> 00:11:22.436 Carl: I think the React core team has like 10 engineers. 00:11:22.486 --> 00:11:23.446 Mo: And RN is about the same. 00:11:23.446 --> 00:11:24.586 So you're talking 20 engineers. 00:11:24.586 --> 00:11:28.066 It's definitely not going to cover those employees to move them 00:11:28.066 --> 00:11:30.436 over, which is in some capacity. 00:11:30.796 --> 00:11:32.386 And then details are to be fleshed out. 00:11:32.386 --> 00:11:35.416 But in some capacity it is a bit disappointing because it would be great 00:11:35.416 --> 00:11:40.666 if they had more freedom as the React Native Core team to play around without 00:11:40.666 --> 00:11:43.756 the restrictions, like you mentioned, of the reviews that Meta has internally. 00:11:44.131 --> 00:11:47.401 And so it's gonna be interesting to see how that Dyna dynamic plays 00:11:47.401 --> 00:11:49.741 out effectively because there is still gonna be that same team. 00:11:49.981 --> 00:11:50.551 At Meta 00:11:51.016 --> 00:11:54.151 Mark: I, I have three sources of information that I'm piecing 00:11:54.151 --> 00:11:57.901 together for some of

how the foundation is supposed to work. 00:11:58.381 --> 00:12:02.641 Seth Webster answered a few questions about this during the q and a session 00:12:02.731 --> 00:12:05.291 that was broadcast at React Conf. 00:12:05.731 --> 00:12:11.041 I had a conversation with a couple React team members and the topic came 00:12:11.041 --> 00:12:12.541 up about how things would be governed. 00:12:13.081 --> 00:12:17.011 And then there was an article on the new stack where Seth Perry was 00:12:17.131 --> 00:12:21.421 interviewed and was giving some further details about some of the governance. 00:12:21.871 --> 00:12:24.841 So as best I understand it, so you've got kind of the corporate 00:12:24.841 --> 00:12:28.591 level stuff that's Meta, Amazon, Callstack, Vercel, et cetera. 00:12:29.131 --> 00:12:33.091 They will then elect a technical steering committee. 00:12:33.421 --> 00:12:38.431 Which is, I guess sort of similar to how Node and other projects work, 00:12:39.061 --> 00:12:45.181 Seth said in the q and a, that meta will start with five votes on that 00:12:45.181 --> 00:12:50.041 corporate board, and then it will go down to one over the next five years. 00:12:50.131 --> 00:12:53.191 So you kind of a decreasing amount of influence in that sense. 00:12:53.581 --> 00:12:57.751 The technical steering committee, I assume, would be able to make decisions 00:12:58.261 --> 00:13:02.911 themselves, but obviously the fact that they are employees of the companies 00:13:03.151 --> 00:13:08.071 elected by those companies, et cetera, they would be taking their company's 00:13:08.071 --> 00:13:09.876 interests into account in the process. 00:13:10.861 --> 00:13:15.211 The article says that the technical governance will be in 00:13:15.211 --> 00:13:17.071 the open more than it once was. 00:13:17.071 --> 00:13:20.341 Request for comments, sets of stages, et cetera. 00:13:20.641 --> 00:13:23.881 But a lot of the process is still to be figured out. 00:13:24.391 --> 00:13:28.681 The article also talks about the foundation doing things like investing 00:13:28.681 --> 00:13:34.891 in React hubs, helping boot camps teach React better, possibly some things with 00:13:34.981 --> 00:13:37.621 conferences and alignment and such. 00:13:38.041 --> 00:13:43.651 So it sounds like the foundation is going to be doing more outreachy things. 00:13:43.651 --> 00:13:47.581 So there, there's a lot of this that is not clear what it means 00:13:47.581 --> 00:13:49.981 in practice yet, but certainly. 00:13:50.776 --> 00:13:55.516 React is not solely a meta owned thing at this point. 00:13:55.876 --> 00:13:58.096 There are multiple companies that are invested in it. 00:13:58.486 --> 00:14:04.096 There is a, a future for React independent of META'S ownership and goals. 00:14:04.576 --> 00:14:10.606 And this all feels like the people who care are trained to do the right thing. 00:14:11.116 --> 00:14:11.326 And 00:14:11.656 --> 00:14:14.596 Mo: on the conference side, I mean, I hope that's the case because one of the, 00:14:14.896 --> 00:14:18.676 as a conference organizer, one of the things that's perhaps challenging is 00:14:18.676 --> 00:14:24.106 that Meta doesn't necessarily sponsor any conferences beyond just React conf, right? 00:14:24.136 --> 00:14:26.776 And so, look, it's well known that that's sort of the case. 00:14:26.776 --> 00:14:31.516 And so maybe the React Foundations that is going to be able to sponsor 00:14:31.516 --> 00:14:36.046 those conferences, even if it's not a meta badge to speak, which 00:14:36.046 --> 00:14:38.536 would be very, very interesting if some of that is used for that. 00:14:38.716 --> 00:14:40.486 So I'm sure it's not just Meta who's investing, right? 00:14:40.486 --> 00:14:43.516 Like I, I suspect that there's funding coming in from. 00:14:44.101 --> 00:14:47.341 Amazon and Microsoft, at least from the bigger, bigger sort 00:14:47.341 --> 00:14:49.051 of established enterprises 00:14:49.531 --> 00:14:50.071 Carl: hopefully. 00:14:50.071 --> 00:14:50.911 And that's interesting. 00:14:51.121 --> 00:14:55.591 And the new Stack article interviewed Seth and has a bunch of poll quotes 00:14:55.591 --> 00:14:58.561 from him and they do talk about that, that like the foundation will look 00:14:58.561 --> 00:15:00.481 at expanding the annual React conf. 00:15:00.511 --> 00:15:03.271 I guess that's not sponsoring other conferences, but they're 00:15:03.271 --> 00:15:04.621 talking about conferences at least. 00:15:04.921 --> 00:15:06.601 But also something that caught my attention. 00:15:06.631 --> 00:15:09.721 They say while React Comp is one of the few conferences that actually makes a 00:15:09.721 --> 00:15:12.121 profit, it basically only paid for itself. 00:15:12.721 --> 00:15:14.971 And also it's a thousand dollars a ticket conference. 00:15:14.971 --> 00:15:20.881 So like hopefully the mode of making conferences self-sustaining is not 00:15:20.911 --> 00:15:22.381 making them cost a thousand dollars. 00:15:22.891 --> 00:15:23.221 Mo: Yeah. 00:15:23.311 --> 00:15:27.541 I mean conferences are from experience a very, very expensive endeavor. 00:15:27.541 --> 00:15:30.631 And if you don't have companies backing them, they will make a loss. 00:15:31.121 --> 00:15:34.451 Carl: I do wanna shout out, as we mentioned at the start, Seth says 00:15:34.481 --> 00:15:36.701 "We have lots of boot camps out there that are doing their best, but they're 00:15:36.701 --> 00:15:39.911 also sending people out into the world misinformed about how React works." 00:15:40.211 --> 00:15:41.561 This is interesting there. 00:15:41.621 --> 00:15:44.021 It's a, it's funny, they're actually hitting on a couple of points 00:15:44.021 --> 00:15:49.181 that I've investigated myself about how to do businesses in 00:15:49.181 --> 00:15:53.831 like a community since like I had previously connected with a bootcamp. 00:15:53.981 --> 00:15:57.911 Somebody was working

there as the curriculum lead and they 00:15:57.911 --> 00:15:59.291 were doing a curriculum overhaul. 00:15:59.321 --> 00:16:01.931 'cause they hadn't changed what they were teaching in three or four years. 00:16:01.931 --> 00:16:03.701 And they were like, is this still relevant? 00:16:03.731 --> 00:16:05.111 Is this what the industry's using? 00:16:05.596 --> 00:16:06.406 And I was like, cool. 00:16:06.406 --> 00:16:07.426 I help run a community. 00:16:07.426 --> 00:16:08.566 I know lots of experts. 00:16:08.926 --> 00:16:12.526 I would be happy to facilitate some kind of professional review. 00:16:13.006 --> 00:16:17.176 And then the bootcamp curriculum lead got laid off because that was 2022 00:16:17.206 --> 00:16:18.976 and lots of things were not happening. 00:16:18.976 --> 00:16:22.006 So it's interesting to see them talk about things that I've thought a lot about. 00:16:22.636 --> 00:16:27.766 And also a lovely shout out, Seth says there are also cohorts such as meetups 00:16:27.796 --> 00:16:29.236 and local groups that could be assisted. 00:16:29.266 --> 00:16:32.566 One meetup actually led to the creation of the conference React Native London. 00:16:32.986 --> 00:16:34.276 So that's super cool. 00:16:34.336 --> 00:16:35.326 Love that for you, Mo. 00:16:36.226 --> 00:16:39.016 Mo: Yeah, I didn't, I, I did not have that on my Bingo card to get 00:16:39.016 --> 00:16:42.436 a shout out from Seth Webster on an interview, which is awesome. 00:16:43.006 --> 00:16:44.176 Yeah, it was good to have him last year. 00:16:44.656 --> 00:16:48.166 Carl: Mo is the organizer of React Native London and that one 00:16:48.166 --> 00:16:49.516 meetup that led to the creation. 00:16:49.516 --> 00:16:51.106 So that, that's just fun. 00:16:51.106 --> 00:16:51.616 That's cool. 00:16:51.796 --> 00:16:54.496 We have actual players in the ecosystem in the podcast right now. 00:16:55.726 --> 00:16:56.416 Mo: Well, you got Mark. 00:16:56.416 --> 00:16:59.386 So I'm stepping up to very, very, very high standards. 00:16:59.731 --> 00:17:00.361 Pretending to. 00:17:00.811 --> 00:17:01.231 Carl: Cool though. 00:17:01.231 --> 00:17:01.351 Yeah. 00:17:01.351 --> 00:17:02.041 So I don't know. 00:17:02.071 --> 00:17:03.301 I don't know if there's more to say there. 00:17:03.631 --> 00:17:04.891 Mark: Some of the more technical stuff. 00:17:04.981 --> 00:17:08.371 So they, they talked about React 19.2 coming out, which if you've been 00:17:08.371 --> 00:17:10.981 paying attention to this podcast for the last several months, you would've 00:17:10.981 --> 00:17:12.631 known all the details already. 00:17:12.991 --> 00:17:17.401 Like the new activity component for being able to hide components while persisting 00:17:17.401 --> 00:17:23.431 state use effect event for hopefully fewer use effect related bugs, et cetera. 00:17:23.941 --> 00:17:27.541 React compiler hit 1.0 and then 00:17:27.601 --> 00:17:31.891 Mo as like as usual, you wanna

talk about the React Native-y things? 00:17:32.371 --> 00:17:37.876 Mo: So a few updates that they did, one of which was quite surprising was that 00:17:38.041 --> 00:17:43.771 the next release of React native version 0.82 is going to be new architecture only. 00:17:44.071 --> 00:17:46.891 So obviously earlier on a few months ago, we talked about how they 00:17:47.071 --> 00:17:50.011 deprecated the old architecture than they froze the old architecture. 00:17:50.221 --> 00:17:52.231 Now they're dropping the old architecture. 00:17:52.591 --> 00:17:55.921 And so to me that was a much faster deprecation cycle 00:17:55.921 --> 00:17:57.571 than I, I would've expected. 00:17:57.991 --> 00:18:02.491 Specifically when it comes to the fact that there are still a fair few libraries 00:18:02.761 --> 00:18:06.391 that are using the old architecture and only support the old architecture. 00:18:06.391 --> 00:18:10.351 So to give you a very concrete example, we had our monthly meetup 00:18:10.411 --> 00:18:15.031 literally yesterday, and there was a talk about Arrive, which is this 00:18:15.031 --> 00:18:17.791 animation engine that a lot of people are using to animate websites and 00:18:17.791 --> 00:18:19.021 make really, really cool stuff. 00:18:19.351 --> 00:18:24.091 But what we learned surprisingly was that Rive only supports the old architecture. 00:18:24.361 --> 00:18:28.171 So what that means is that this company who's a very popular healthcare company, 00:18:28.171 --> 00:18:31.921 really don't have a path to sort of migrate to the new architecture and 00:18:31.921 --> 00:18:36.871 hence version 0.82 until Rive starts to support the new architecture. 00:18:37.231 --> 00:18:41.131 So there are still libraries, albeit the majority of major libraries have 00:18:41.131 --> 00:18:44.701 been ported to the new architecture that are still hanging behind. 00:18:44.701 --> 00:18:47.731 So I'm quite surprised by this, but we'll see how it goes. 00:18:47.731 --> 00:18:50.821 It probably means that these library maintainers really need to like step up 00:18:50.821 --> 00:18:52.471 in the next month or two and get ready. 00:18:52.921 --> 00:18:56.731 The second big thing, which I have a little bit about later on, but 00:18:56.791 --> 00:19:02.551 just a quick one, is that Amazon did the Vega Os announcement earlier. 00:19:02.611 --> 00:19:04.771 It was towards the end of September that they actually announced it, 00:19:04.771 --> 00:19:08.281 but they formally talked to the React and React native communities 00:19:08.281 --> 00:19:10.011 about it during React Conf. 00:19:10.291 --> 00:19:15.601 This is a completely new operating system that's fully built from scratch by Amazon 00:19:15.601 --> 00:19:18.211 folks and React Native is the UI layer. 00:19:18.211 --> 00:19:21.931 It's the only way that you can write apps for it, which is quite a big 00:19:21.931 --> 00:19:26.641 investment from Amazon's perspective into React Native as

a technology. 00:19:27.121 --> 00:19:29.371 So Amazon makes a lot of devices. 00:19:29.401 --> 00:19:32.581 For a little bit of context, you might've seen their Fire TV devices, some of the 00:19:32.581 --> 00:19:37.111 Kindle fire devices that they had, but also like Echo dots and a whole slew of 00:19:37.111 --> 00:19:39.151 different devices that they manufacture. 00:19:39.511 --> 00:19:43.111 And previously a lot of these were running on Android or a variety of Android 00:19:43.111 --> 00:19:46.741 called Fire Os that they had adopted from the Android open source projects. 00:19:47.191 --> 00:19:50.821 And so now they've kind of completely ditched that and they're betting 00:19:50.821 --> 00:19:55.141 long term on React native now at our company at Theo and a bunch of other 00:19:55.141 --> 00:19:58.351 companies have been sort of working with Amazon behind the scenes on this. 00:19:58.351 --> 00:20:01.141 And we're aware of this but weren't really allowed to speak about it. 00:20:01.291 --> 00:20:02.401 So it's now out in the public. 00:20:02.401 --> 00:20:06.271 But it has been a good while, which I cannot specify how long that duration is 00:20:06.541 --> 00:20:09.631 that I have been aware of this, but just not able to talk about it and have been 00:20:09.631 --> 00:20:12.781 working with the Amazon folks to make sure that things are ready for their launch. 00:20:12.931 --> 00:20:15.391 So they have an introduction video at React Con, which I think is 00:20:15.391 --> 00:20:21.271 interesting because TV apps need to run on very, very limited specs. 00:20:21.271 --> 00:20:24.391 You're talking like a few gigs of Ram one or two gigs of ram and like 00:20:24.391 --> 00:20:28.111 very, very, very slow CPUs and some of them are even worse than that. 00:20:28.381 --> 00:20:32.911 So effectively they really had to optimize the living crap out of their 00:20:32.911 --> 00:20:36.811 operating system and make sure that React plays nice with it and is like the 00:20:36.811 --> 00:20:38.761 first class citizen when it comes to it. 00:20:38.761 --> 00:20:40.921 So it's, it's very interesting how they had to optimize it and 00:20:40.921 --> 00:20:42.031 it was a big undertaking for them. 00:20:42.031 --> 00:20:42.271 So. 00:20:42.691 --> 00:20:45.691 I guess congrats to the Amazon team, but beyond that, it's quite interesting 00:20:45.691 --> 00:20:48.361 for people that are interested in performance and React and React native. 00:20:48.811 --> 00:20:51.991 Carl: Yeah, I was just scanning this to see if I could find any details 00:20:51.991 --> 00:20:55.021 about what they built on top of, because like, I don't know, nobody 00:20:55.021 --> 00:20:57.211 builds a whole OS from scratch anymore. 00:20:57.211 --> 00:20:59.101 And this is on top of Linux? 00:20:59.521 --> 00:21:01.381 Mo: Yeah, it's c plus plus on top of Linux. 00:21:01.381 --> 00:21:02.551 Basically it's a Linux. 00:21:03.211 --> 00:21:04.861 Or is a Unix based system. 00:21:05.401 --> 00:21:07.321 Carl: Right, like, and so is Android. 00:21:07.711 --> 00:21:14.401 Like, I'm curious to what extent this is a locked down, stripped back version 00:21:14.401 --> 00:21:16.561 of Android that they're calling Vega. 00:21:16.831 --> 00:21:20.221 They don't say that anywhere, but like reading the tea leaves here, 00:21:20.221 --> 00:21:23.641 I, my assumption is that the, I don't know, Android was such a 00:21:23.641 --> 00:21:28.141 massive undertaking that Google then acquired and commercialized. 00:21:28.561 --> 00:21:32.551 Curious to hear more technical details about the OS layer here and how it… 00:21:32.611 --> 00:21:35.131 Mo: I can tell you a little bit about that because I've known about it for a while. 00:21:35.311 --> 00:21:37.771 It's not on top of Android in any capacity. 00:21:38.071 --> 00:21:41.341 It is fully, the Android open source project components of 00:21:41.341 --> 00:21:42.301 it are fully stripped out. 00:21:42.301 --> 00:21:46.771 It's built from scratch, which means that compatibility with old apps is. 00:21:47.281 --> 00:21:49.231 Limited and there's other solutions. 00:21:49.291 --> 00:21:51.931 It's not that you can run Android apps on it as an example that 00:21:51.931 --> 00:21:53.851 we're the old Fire OS apps. 00:21:54.151 --> 00:21:57.931 Carl: So wait, it sounds a little bit like you're saying there is a shared lineage 00:21:57.931 --> 00:22:02.731 with Android, but it's different enough that its own technically distinct thing. 00:22:02.821 --> 00:22:07.141 Mo: They share a technical lineage in the same capacity that like Mac Os and 00:22:07.141 --> 00:22:11.011 Androids here, which is, they are both unique systems and that's pretty much it. 00:22:11.011 --> 00:22:15.331 Like they serve the same kernel but like so does 90% of devices out there. 00:22:15.451 --> 00:22:19.306 So it's as Android, as IOS's, Android, if that kind of makes sense. 00:22:19.996 --> 00:22:21.796 Carl: The Tree of Life, kingdom Family order. 00:22:21.796 --> 00:22:23.686 Like this is not shared genus. 00:22:23.686 --> 00:22:25.546 This is shared order maybe? 00:22:25.756 --> 00:22:26.146 Yes. 00:22:26.236 --> 00:22:26.776 Okay, cool. 00:22:26.776 --> 00:22:27.166 Good to know. 00:22:27.166 --> 00:22:27.556 Thank you. 00:22:27.796 --> 00:22:30.976 Mark: I do wanna highlight a couple talks in particular, and again, you can look at 00:22:30.976 --> 00:22:35.446 the whole React con recap blog posts to get links to the different talks and the 00:22:35.446 --> 00:22:36.676 different portions of the live stream. 00:22:36.946 --> 00:22:40.846 A lot of good talks that were worth watching, but two that I liked in 00:22:40.846 --> 00:22:45.316 particular, Joe Savona did a talk on some of the React team's performance 00:22:45.316 --> 00:22:49.906 experiments, and there's a bit of controversy because he showed a bunch of 00:22:49.906 --> 00:22:54.856 hypothetical, semi

hypothetical benchmark numbers without any real details on the 00:22:54.856 --> 00:22:56.746 actual implementation of the benchmarks. 00:22:56.806 --> 00:23:00.886 And then some of them were like, versus we built NAP with signals 00:23:00.886 --> 00:23:05.986 and compared it with one with React and then ex a highly prototype 00:23:05.986 --> 00:23:07.696 React and a bunch of other stuff. 00:23:08.026 --> 00:23:12.136 And then people were saying, well, we tried to mimic this and we think you're 00:23:12.136 --> 00:23:13.576 probably using signals the wrong way. 00:23:13.846 --> 00:23:18.271 But it was still interesting to hear the discussion around, we agree 00:23:18.271 --> 00:23:22.141 that performance has been a problem and we've tried prototyping some 00:23:22.141 --> 00:23:26.161 different ideas to see what's possible and where bottlenecks might be. 00:23:26.671 --> 00:23:30.991 The other one I really wanna point to though, Rick Hanlon did a talk called 00:23:31.051 --> 00:23:36.331 Async React and he had a few major, he had a couple different points out of this. 00:23:36.631 --> 00:23:40.531 One was that the React team has been talking about things like suspense and 00:23:40.531 --> 00:23:47.071 concurrency since 2018, and if it's been hard to follow where the React team is 00:23:47.071 --> 00:23:51.931 trained to go with this, it's 'cause the React team itself really didn't know 00:23:52.021 --> 00:23:53.431 where they were trained to go with this. 00:23:53.431 --> 00:24:01.021 He even pulled out meeting notes from a React team weekly meeting in like 2015 or 00:24:01.021 --> 00:24:08.851 2016 where they started having the first initial ideas for, we think we want to go 00:24:08.851 --> 00:24:13.831 in this direction, but they really didn't know what the final result ought to look 00:24:13.831 --> 00:24:15.391 like or how they were going to get there. 00:24:15.886 --> 00:24:20.626 And so showed a diagram with a whole bunch of back and forth wavy 00:24:20.626 --> 00:24:24.946 lines like we, we don't know where we're going, but now it's 2025. 00:24:25.006 --> 00:24:26.956 We've gotten through the confusion. 00:24:27.316 --> 00:24:32.086 We've now built all the main concurrent pieces that we were trained to build. 00:24:32.446 --> 00:24:37.066 We are seeing the results of even like the React 16 fiber rerate. 00:24:37.576 --> 00:24:42.646 And now we can actually say, we've built these pieces and here's 00:24:42.646 --> 00:24:43.966 how they ought to fit together. 00:24:44.476 --> 00:24:49.456 And so the second half of his talk was a demo where he took a badly 00:24:49.456 --> 00:24:53.296 written but viable React app, which uses use effect for data fetching 00:24:53.296 --> 00:24:56.626 and manual setting, state for loading states and things like that. 00:24:56.926 --> 00:25:02.296 And he first refactored it to have a bunch of transitions for better 00:25:02.296 --> 00:25:08.056 loading animations, using suspense for the data fetching, and he showed the 00:25:08.056 --> 00:25:10.906 visible improvements in user experience. 00:25:11.476 --> 00:25:17.206 And then his point towards the end was that, yeah, the, so like this is how 00:25:17.326 --> 00:25:21.226 modern Async React code ought to work. 00:25:21.736 --> 00:25:26.236 But in fact, you shouldn't even have to write most of this code in your 00:25:26.236 --> 00:25:30.916 own app because the transitions and the loading states and everything else 00:25:31.186 --> 00:25:36.316 really ought to be embedded in your router and your data fetching library. 00:25:36.796 --> 00:25:41.356 Now, unfortunately, his actual talk got interrupted for stupid technical reasons. 00:25:41.626 --> 00:25:46.426 So he came back at the end of day two and picked up with his demo and actually had 00:25:46.426 --> 00:25:48.106 a chance to do a better version of it. 00:25:48.631 --> 00:25:53.191 And so I think the key points are, one, the React team has now built 00:25:53.191 --> 00:25:55.771 the concurrent async features that they've talked about for years. 00:25:56.251 --> 00:26:02.949 Two, a lot of us, including myself, are still kind of stuck in like a 20 16, 20 00:26:02.949 --> 00:26:06.841 18 era mindset of how to use React three. 00:26:06.871 --> 00:26:11.701 These things make writing React apps better and better user experience. 00:26:12.211 --> 00:26:17.671 Four, we need to get these things embedded in component libraries and 00:26:17.671 --> 00:26:22.651 data fetching libraries so that a lot of this stuff just works outta the box. 00:26:23.041 --> 00:26:26.371 So I highly, highly recommend watching Ricky's talk. 00:26:26.641 --> 00:26:28.861 He also put up the demo code as well. 00:26:29.281 --> 00:26:30.031 Carl: That was a good talk. 00:26:30.091 --> 00:26:30.871 It was a good demo. 00:26:31.441 --> 00:26:34.141 I will say, while watching him write the code. 00:26:34.711 --> 00:26:36.811 I was like, man, this looks really complicated. 00:26:37.021 --> 00:26:37.381 Mark: Yeah. 00:26:37.381 --> 00:26:39.631 And that, and that's another point that we're going to touch on here with a 00:26:39.631 --> 00:26:41.191 couple of the, the other things as well. 00:26:41.401 --> 00:26:45.661 One other thing that really caught my attention, so if you've been listening 00:26:45.661 --> 00:26:49.471 to podcasts for a while, you've heard me agitating, saying that we really 00:26:49.471 --> 00:26:55.171 need is a new React working group where folks from the community can 00:26:55.171 --> 00:26:58.441 officially communicate to the React team for things like, Hey, we think there 00:26:58.441 --> 00:27:00.211 should be more docs to cover this topic. 00:27:00.631 --> 00:27:03.121 Or, oops, create React app just broke. 00:27:03.121 --> 00:27:05.191 I think you should fix it, and things like that. 00:27:05.701 --> 00:27:11.161 And Ricky was actually the person who drove most of the React eight team.

00:27:11.491 --> 00:27:12.001 Working group. 00:27:12.721 --> 00:27:16.051 And so at the end of his talk, Ricky actually announced that there is 00:27:16.051 --> 00:27:19.711 now a new Async React working group. 00:27:20.401 --> 00:27:26.371 And this is sort of a catchall, it's meant to cover discussions of things like how 00:27:26.371 --> 00:27:32.576 do we get async React features into major ecosystem libraries and, what kind of 00:27:32.576 --> 00:27:34.826 docs should we have to cover this stuff? 00:27:35.216 --> 00:27:39.626 And so the, even the first discussion thread is a lot of discussion between me, 00:27:39.656 --> 00:27:45.566 Ricky, Dan Aberman of Corbin Crutchley, about a whole bunch of possible docs, 00:27:45.566 --> 00:27:50.126 pages that we could add that would cover things like transitions and 00:27:50.126 --> 00:27:52.586 suspense and how to use them correctly. 00:27:53.066 --> 00:27:57.206 And getting people from the community to contribute those new docs pages 00:27:57.206 --> 00:27:58.796 rather than waiting on the React team. 00:27:59.086 --> 00:27:59.566 To write them. 00:28:00.166 --> 00:28:03.496 So I am actually genuinely, genuinely excited. 00:28:03.556 --> 00:28:09.226 Like I've done a lot of complaining and this is the answer to my complaints 00:28:09.256 --> 00:28:14.776 that we have working group and docs plans and an agreement that people 00:28:14.776 --> 00:28:16.516 outside the team can contribute. 00:28:16.996 --> 00:28:20.746 So like I am actually legitimately thrilled by this. 00:28:21.316 --> 00:28:21.766 Carl: Nice. 00:28:22.156 --> 00:28:26.506 I do appreciate more, I don't know, open participation more, more discussion. 00:28:26.986 --> 00:28:27.406 That's great. 00:28:27.796 --> 00:28:29.446 Should we get into Remix V three? 00:28:29.956 --> 00:28:30.796 Mark: Yes, we should. 00:28:31.036 --> 00:28:35.176 Alright, so usual caveat, I still have not had time to actually watch 00:28:35.386 --> 00:28:39.346 the announcement, but I, I think I can give a fair summary of it 00:28:39.406 --> 00:28:43.186 from having seen the discussion on Twitter and the articles afterwards. 00:28:43.366 --> 00:28:46.756 We have mentioned for the last several months that they were teasing 00:28:46.786 --> 00:28:51.616 Remix V three is going to be, not pre-ACT, its own component model, 00:28:51.766 --> 00:28:54.046 something with iframes, whatever. 00:28:54.436 --> 00:28:58.246 And our last comments on it were just show us some code already. 00:28:58.906 --> 00:29:02.806 Well, at the Remix Jam conference, they did actually show us the code. 00:29:03.376 --> 00:29:09.466 There was a, a repo put together that did timestamped links to all the appropriate 00:29:09.466 --> 00:29:11.626 pieces of the announcement video. 00:29:12.136 --> 00:29:16.906 So if you'd like to be able to jump in and see the examples of what Remix 00:29:16.906 --> 00:29:19.786 V three code is supposed to look like, that should

make it easier. 00:29:20.296 --> 00:29:25.336 My first impressions, again, just having seen screenshots of the code in 00:29:25.336 --> 00:29:30.496 following the discussions, is that Remix v three's component model is sort of a 00:29:30.496 --> 00:29:34.756 mixture between React, view and backbone. 00:29:35.446 --> 00:29:38.806 So it's kind of like React in that you have function components 00:29:38.866 --> 00:29:40.456 and they, and that uses JSX. 00:29:41.056 --> 00:29:45.856 It's kind of like view and the composition API, where you're 00:29:45.856 --> 00:29:48.676 given a closure as the setup. 00:29:49.151 --> 00:29:53.741 It's a little bit like backbone in that the function component 00:29:53.741 --> 00:29:58.241 you're rating still sort of is organized like as if it were a class. 00:29:58.571 --> 00:30:03.641 It passes in a reference to the instance rather than getting 00:30:03.641 --> 00:30:08.111 the props as an argument, and you're supposed to call it this. 00:30:08.591 --> 00:30:12.401 And part of that is to make use of a TypeScript typing trick that 00:30:12.401 --> 00:30:15.881 lets you declare the type of this as an argument to a function. 00:30:16.481 --> 00:30:23.351 But also you manually trigger updates by first mutating a variable 00:30:23.471 --> 00:30:28.811 in the setup closure, and then you manually call this update. 00:30:29.411 --> 00:30:34.901 And so Ryan Florence even said, this is basically old school React class 00:30:34.901 --> 00:30:36.821 component, this dot force update. 00:30:37.306 --> 00:30:42.766 Essentially, so I, I can see bits and pieces of parallels and influences 00:30:42.766 --> 00:30:45.076 between all three of those frameworks. 00:30:45.076 --> 00:30:49.396 When I look at the Remix code, it's also supposed to come with a 00:30:49.396 --> 00:30:54.196 bunch of utilities for being able to compose event handlers together. 00:30:54.856 --> 00:30:59.086 And yeah, so we, we have finally seen the code. 00:30:59.476 --> 00:31:03.646 I believe they also gave some demonstrations of what the server side 00:31:03.646 --> 00:31:05.986 loading story is supposed to look like. 00:31:06.286 --> 00:31:12.136 Some kind of an I frame alike component that has its own URL and 00:31:12.136 --> 00:31:14.416 can automatically re fetch HTML. 00:31:14.476 --> 00:31:18.976 I haven't looked into those pieces as much, so very big picture. 00:31:19.126 --> 00:31:23.206 I saw a lot of people arguing about having this dot update. 00:31:23.831 --> 00:31:28.121 A lot of people saying it feels like a step backwards, it's manual update code. 00:31:28.691 --> 00:31:33.101 But some people demonstrated that you can very quickly write your own wrappers that 00:31:33.101 --> 00:31:34.811 just call this DOT update internally. 00:31:35.081 --> 00:31:38.771 I have seen wrappers that mimic like the used state hook. 00:31:39.101 --> 00:31:43.391 I've seen wrappers for other state management libraries like Redux. 00:31:43.751 --> 00:31:48.551 So it's a primitive that can clearly be abstracted if you really want to. 00:31:48.911 --> 00:31:53.291 I saw some good posts and articles from James Long and a couple other 00:31:53.291 --> 00:31:58.421 people with thoughts on the ability to compose interactions together. 00:31:58.961 --> 00:32:03.131 Carl, to your point that modern React and all the new async 00:32:03.131 --> 00:32:06.131 features feel very complicated. 00:32:06.431 --> 00:32:11.981 Like there's good reasons why methods like transitions exist to try to give 00:32:11.981 --> 00:32:17.411 better user experiences, but it's just all these additional concepts and behaviors 00:32:17.411 --> 00:32:19.661 you have to keep track of in your head. 00:32:20.176 --> 00:32:27.226 And Remix is trying to go for a less magic, less abstraction approach. 00:32:27.706 --> 00:32:31.156 So we'll see what it means in terms of adoption. 00:32:31.276 --> 00:32:36.496 Again, this is non-reactive, so different framework, different ecosystem. 00:32:36.496 --> 00:32:40.366 Who knows what the actual adoption will look like, but I get the sense 00:32:40.366 --> 00:32:44.356 of what they're trying to go for and I, I think it will appeal to 00:32:44.446 --> 00:32:49.306 some number of users out there that want to have that kind of behavior. 00:32:49.816 --> 00:32:53.026 Carl: Yeah, I'll definitely keep paying attention to it 'cause 00:32:53.026 --> 00:32:58.066 they're thoughtful about things and historically have just done a lot. 00:32:58.456 --> 00:33:00.496 So I'm very curious to see where this goes. 00:33:00.496 --> 00:33:07.336 But my gut feeling here is that this is going to end up more as an API exploration 00:33:07.696 --> 00:33:13.876 and that any great ideas that come out of it will be a fresh exploration and then 00:33:14.656 --> 00:33:19.696 maybe validate some ideas that get brought into React or view or other big tools. 00:33:19.786 --> 00:33:22.756 But yeah, I, I could be wrong, could be, could be more 00:33:23.086 --> 00:33:24.496 independently successful than that. 00:33:25.006 --> 00:33:28.216 They, they did stress in the video that I watched, that this 00:33:28.216 --> 00:33:29.956 is all like prototype phase. 00:33:29.986 --> 00:33:33.976 So they, like right now apparently there's splitting it all up into 00:33:33.976 --> 00:33:35.176 a bunch of different packages. 00:33:35.176 --> 00:33:39.136 They can iterate independently and explore a bunch of different things. 00:33:39.136 --> 00:33:43.231 But the, the final intended usage would be from one package, 00:33:43.231 --> 00:33:44.881 not from 20 different packages. 00:33:45.361 --> 00:33:48.361 Just to throw that out there as a a thing that will change. 00:33:48.841 --> 00:33:49.861 Yeah, I don't know. 00:33:49.921 --> 00:33:50.371 We'll see. 00:33:50.881 --> 00:33:51.241 We'll see. 00:33:51.451 --> 00:33:54.331 I think the component model is just gonna be really hard to

disrupt. 00:33:54.421 --> 00:34:00.001 One, one thing I did see in the video of Ryan Florence talking about just talking 00:34:00.001 --> 00:34:04.351 while he was demoing, he like compared and contrasted with like, here's how we 00:34:04.351 --> 00:34:08.251 do state changes and you just call the dispatch function instead of set state. 00:34:08.551 --> 00:34:10.891 And I was like, I dunno, you can do that in React. 00:34:10.891 --> 00:34:14.701 Like they've been encouraging people to do that for years, for like six years 00:34:15.001 --> 00:34:18.991 basically Ever since hooks came out and you could do a state reducer, they were 00:34:18.991 --> 00:34:24.211 like, please, except for trivial uses of state, all of your state should be in 00:34:24.211 --> 00:34:25.801 a reducer and you should use dispatch. 00:34:25.801 --> 00:34:26.461 Not set state. 00:34:26.971 --> 00:34:30.271 So just like calling that out as a point of comparison, like React has been 00:34:30.271 --> 00:34:31.951 trying to do that for a long time too. 00:34:31.951 --> 00:34:34.921 It's just nobody actually does, I dunno, just caught my attention. 00:34:35.431 --> 00:34:37.981 Mark: Well least we have an actual code to critique now and argue 00:34:37.981 --> 00:34:39.661 about instead of the vague teasing. 00:34:40.111 --> 00:34:41.311 True facts. 00:34:41.641 --> 00:34:44.011 Carl: I will happily continue reading code and critiquing. 00:34:44.551 --> 00:34:48.001 Speaking of which , I love this project. 00:34:48.031 --> 00:34:50.881 I have thought about doing this so many different times and I 00:34:50.881 --> 00:34:52.171 never have because it's hard. 00:34:52.471 --> 00:34:57.631 Somebody built the same app 10 times in a variety of different frameworks 00:34:57.631 --> 00:35:04.141 and tools and benchmarked them and compared and contrasted their performance 00:35:04.141 --> 00:35:05.371 in a bunch of different metrics. 00:35:05.431 --> 00:35:10.141 It seemed like they focused pretty heavily on like bundle size to me, very wordy. 00:35:10.141 --> 00:35:12.361 I, I will say I got a little bit lost in the 00:35:12.361 --> 00:35:12.661 Mark: instruction. 00:35:12.661 --> 00:35:17.371 Very wordy and very, also, a lot of the article was very clearly AI generated. 00:35:17.371 --> 00:35:20.371 I saw some comments from the author saying he had written pieces of it in 00:35:20.371 --> 00:35:22.411 sections and used AI to help with it. 00:35:22.651 --> 00:35:25.861 So like there, there was clearly human involvement in it, but the, 00:35:25.981 --> 00:35:29.701 the AI generation of the article itself was a critique point. 00:35:30.271 --> 00:35:30.451 Carl: Yeah. 00:35:30.451 --> 00:35:33.151 Just like as I'm scrolling, it's got so many paragraphs in a row 00:35:33.151 --> 00:35:34.801 that are all like identically long. 00:35:35.281 --> 00:35:36.841 Just a little bit of a wall of text. 00:35:36.841 --> 00:35:38.341 I definitely skimmed this pretty hard. 00:35:38.611 --> 00:35:42.511 All that aside, like I just love the idea of doing the exact 00:35:42.511 --> 00:35:44.071 same thing with the exact same. 00:35:44.071 --> 00:35:46.861 Like, well, I don't know that they use the same test suite, but that, 00:35:46.861 --> 00:35:48.001 that was always my idea is build. 00:35:48.031 --> 00:35:52.651 You build an end-to-end test suite and then you get a passing app for that test 00:35:52.651 --> 00:35:54.121 suite in a bunch of different tools. 00:35:54.641 --> 00:35:57.511 I meant to do more of a deep code review on a couple of 00:35:57.511 --> 00:35:59.071 the different implementations. 00:35:59.311 --> 00:36:03.421 It's a CanBan board, it's, you know, a Trello clone type project 00:36:03.421 --> 00:36:06.001 where you're doing task management with cards and drag and drop. 00:36:06.151 --> 00:36:10.111 I guess it, it's a great and a parable comparison because drag 00:36:10.111 --> 00:36:12.601 and drop is really hard to do and so it's very frequently something 00:36:12.601 --> 00:36:14.491 people try to lean on libraries for. 00:36:15.031 --> 00:36:20.521 So if you are implementing it yourself, that's kind of cha, that 00:36:20.521 --> 00:36:23.791 makes it a little bit challenging to use as a point of comparison. 00:36:24.301 --> 00:36:29.941 But the tools that were used here, he built it analog, which I guess is 00:36:29.941 --> 00:36:31.831 vanilla js is what I'm assuming, or 00:36:31.921 --> 00:36:36.421 Mark: analog is actually a, a next like tool for Angular. 00:36:36.991 --> 00:36:37.291 Carl: Oh great. 00:36:37.321 --> 00:36:37.621 Okay. 00:36:37.891 --> 00:36:38.131 Okay. 00:36:38.131 --> 00:36:41.251 So you built it an analog, which is an angular type thing. 00:36:41.701 --> 00:36:45.091 And HTMX, Marco, which I'd never heard of. 00:36:45.301 --> 00:36:46.351 Next.JS, of course. 00:36:46.351 --> 00:36:46.951 Next. 00:36:47.041 --> 00:36:47.461 Sure. 00:36:47.851 --> 00:36:49.871 Qwik City, which is Qwik. 00:36:49.891 --> 00:36:51.931 I've heard of Qwik City I had not heard of. 00:36:51.931 --> 00:36:53.191 So this is I guess 00:36:53.191 --> 00:36:55.591 Mark: probably another solid versus solid start type thing. 00:36:55.741 --> 00:36:57.091 Carl: Qwik city to qwik Sure. 00:36:57.571 --> 00:37:02.851 Solid start spelt Kit Tan Stack with solid and then Tan Stack with React. 00:37:03.451 --> 00:37:07.081 Yeah, one of the first tables, one of the first actual like points of 00:37:07.081 --> 00:37:11.761 comparison of the output tables is just on bundle size and how much 00:37:11.761 --> 00:37:14.191 JavaScript was served in order to. 00:37:14.851 --> 00:37:15.931 Get this app running. 00:37:16.261 --> 00:37:22.471 They used Next.JS version 16 as the baseline and that was about 500 00:37:22.471 --> 00:37:24.241 kilobytes gzipped, which is huge. 00:37:24.241 --> 00:37:25.561 It's big hand stack. 00:37:25.561 --> 00:37:27.541 Start with React.

00:37:27.721 --> 00:37:32.071 Clocked in at about 300 kilobytes a little bit more with solid 00:37:32.071 --> 00:37:33.571 was a half of that hand stack. 00:37:33.571 --> 00:37:36.601 Start with solid was 150 ish kilobytes. 00:37:36.871 --> 00:37:39.331 The smallest was Marco. 00:37:39.826 --> 00:37:43.906 12. At 12 kilobytes followed by quick city at 88. 00:37:44.146 --> 00:37:47.506 Oh, I just realized there's parenthesized compressed. 00:37:47.506 --> 00:37:49.306 I thought I was reading the compressed and I was not. 00:37:49.816 --> 00:37:53.626 Mark: There's also the board page versus the homepage sizes. 00:37:53.866 --> 00:37:54.286 Carl: Yeah. 00:37:54.286 --> 00:37:54.616 Okay. 00:37:54.706 --> 00:37:54.976 Alright. 00:37:54.976 --> 00:37:57.076 This is more confusingly presented than I realized. 00:37:57.466 --> 00:38:00.226 Mark: I think the biggest picture takeaways, number one, it's worth noting 00:38:00.316 --> 00:38:04.006 that the author of this article previously put up a post a month or two ago saying 00:38:04.006 --> 00:38:08.566 that React by is the default choice and it's killing innovation in the ecosystem. 00:38:08.956 --> 00:38:11.116 So that kind of to where they're coming from. 00:38:11.506 --> 00:38:12.406 But I do think they did. 00:38:12.406 --> 00:38:16.966 They were legitimately trying to do a real meaningful comparison, even 00:38:16.971 --> 00:38:19.906 if the results were sort of what they were hoping they would be. 00:38:19.906 --> 00:38:21.706 IE reacted big and bad. 00:38:22.306 --> 00:38:28.576 So yeah, the big takeaways are like React itself is huge and so any React app is 00:38:28.576 --> 00:38:31.756 going to be very large bundle size wise. 00:38:32.236 --> 00:38:37.186 And look, if we do like Tan Stack with Solid instead of Tan Stack 00:38:37.186 --> 00:38:38.866 with React, it gets smaller. 00:38:39.256 --> 00:38:45.256 But also if you do these other frameworks, it gets even better smaller and then it 00:38:45.256 --> 00:38:48.856 kind of ends with a bit of a, another rant about React is a bad choice. 00:38:49.396 --> 00:38:51.106 Carl: Yeah, I, I will validate that. 00:38:51.316 --> 00:38:55.936 To me it also looked like they really tried to give React a fair shake here. 00:38:55.936 --> 00:38:58.126 Like, you know, if you wanted to, if you were wanting to complain about 00:38:58.126 --> 00:39:01.876 bundle size, if React apps, like there are so many easy ways to bloat 00:39:01.876 --> 00:39:03.586 this up to a couple of megabytes. 00:39:04.096 --> 00:39:08.086 So like the fact that they didn't do that is indicative enough to me that 00:39:08.086 --> 00:39:09.316 they tried to give this a fair shot. 00:39:10.246 --> 00:39:10.756 It's cool. 00:39:10.756 --> 00:39:11.236 I love this. 00:39:11.236 --> 00:39:13.366 This is a great project, great effort. 00:39:13.756 --> 00:39:17.056 I don't know that, to me, at the end of the day, this is interesting 00:39:17.056 --> 00:39:21.556 and fascinating and a great point of comparison, and also like not that 00:39:21.556 --> 00:39:26.026 meaningful because the performance metrics that you measure here that are 00:39:26.026 --> 00:39:31.366 easily measured by comparing the outputs of identically functional applications, 00:39:31.876 --> 00:39:38.146 that's really only like maybe a third of the reason why you would choose to build 00:39:38.146 --> 00:39:41.146 an app with any particular set of tools. 00:39:41.176 --> 00:39:45.316 Like really, if you're starting a company and hiring engineers 00:39:45.316 --> 00:39:47.266 and doing a greenfield project. 00:39:47.941 --> 00:39:51.811 Like some of the most important things are how much will this cost? 00:39:52.141 --> 00:39:53.101 Mark: How well is everything? 00:39:53.101 --> 00:39:54.781 How well is everything documented? 00:39:54.781 --> 00:39:57.541 How easily can we spin up engineers who know these things? 00:39:57.541 --> 00:39:59.551 I mean, the, the ecosystem argument is a real thing. 00:39:59.911 --> 00:40:03.661 Carl: And like, you know, if it takes you two months to find a developer, 00:40:03.721 --> 00:40:08.041 you know, a senior developer who can build your app in Marco, you 00:40:08.041 --> 00:40:09.721 know, you could do that in a week. 00:40:09.841 --> 00:40:10.231 I don't know. 00:40:10.471 --> 00:40:14.131 The hiring for React is much easier than hiring for some niche tool. 00:40:14.131 --> 00:40:16.891 And I have seen writeups of people saying like, yeah, we built our 00:40:16.891 --> 00:40:20.281 startup on this niche framework and we couldn't hire for it. 00:40:20.281 --> 00:40:22.771 And that ended up contributing to the death of the company. 00:40:23.011 --> 00:40:25.711 So like, you know, these performance metrics are important, they're really 00:40:25.711 --> 00:40:27.301 useful, it's great to have them. 00:40:27.301 --> 00:40:31.441 So we know where opportunities to improve are like tying this 00:40:31.441 --> 00:40:33.061 back mark to your Immer work. 00:40:33.061 --> 00:40:36.211 Like if somebody hadn't complained about performance, you wouldn't 00:40:36.211 --> 00:40:37.351 know that it needed to get better. 00:40:37.351 --> 00:40:37.501 Pretty 00:40:37.501 --> 00:40:37.741 Mark: much. 00:40:37.741 --> 00:40:38.011 Yeah. 00:40:38.281 --> 00:40:41.431 Carl: So this is great and I love it, but it's also not the end all, be all 00:40:41.431 --> 00:40:44.431 of like decision making for, things. 00:40:44.431 --> 00:40:44.731 Yeah. 00:40:45.271 --> 00:40:48.121 It's also, man, this, it's just so hard to read because of how long it is. 00:40:48.181 --> 00:40:49.891 I wish they'd stripped this down a bit more. 00:40:49.951 --> 00:40:53.581 Mo: And if we take like a step back out of our like web ecosystem bubble for a 00:40:53.581 --> 00:40:59.371 second, like you go to like the backend world and like enterprise business 00:40:59.671 --> 00:41:04.411 companies or

finance or whatever, and like they employ a lot of developers, right? 00:41:04.411 --> 00:41:07.531 Like thousands, thousands and thousands of developers. 00:41:07.861 --> 00:41:11.791 And like there's a reason they're all on Java and .Net is because like 00:41:11.971 --> 00:41:15.091 they can hire for those and it's pretty easy to build a team around. 00:41:15.091 --> 00:41:16.051 That's the top priority. 00:41:16.051 --> 00:41:20.146 Even like this stuff is quite minuscule when people are, companies 00:41:20.146 --> 00:41:21.571 are hiring at a large scale. 00:41:21.751 --> 00:41:25.321 And then the second thing, which is like not accounted for, I think in this 00:41:25.321 --> 00:41:30.001 like approach of looking at like just the bundle size that's outputted is the 00:41:30.001 --> 00:41:34.711 fact that like your productivity with the fact that most of the AI tools are 00:41:34.711 --> 00:41:39.901 really like optimized around React is not something that you should not look at and 00:41:39.901 --> 00:41:41.431 consider when you're choosing something. 00:41:41.821 --> 00:41:45.901 There's so much training data and so much like tooling around building React 00:41:45.901 --> 00:41:50.941 apps quickly and prototyping React features or React apps that with AI 00:41:50.941 --> 00:41:54.841 that is just a bit, it feels a bit moot some of some of these conversations. 00:41:54.841 --> 00:41:55.291 It feels. 00:41:55.351 --> 00:41:58.231 Mark: To be clear, like React has got itself has gotten 00:41:58.231 --> 00:41:59.371 much bigger over the years. 00:41:59.371 --> 00:42:02.191 In fact, even just 18 to 19 it got notice will be bigger. 00:42:02.761 --> 00:42:05.221 Bigger bundle sizes are not a good thing. 00:42:05.221 --> 00:42:08.341 We are not sitting here saying Your bundle size does not matter. 00:42:08.671 --> 00:42:12.781 Alex Russell, as much as I disagree with his communication style is right 00:42:12.841 --> 00:42:16.981 to point to the technical receipts saying that big bundle sizes are 00:42:16.981 --> 00:42:21.511 bad, but also it's not the only single metric you should care about. 00:42:21.931 --> 00:42:22.651 Carl: Yeah, right. 00:42:22.741 --> 00:42:23.071 Yep. 00:42:23.191 --> 00:42:24.781 And also, last thing I'll shout out here. 00:42:24.781 --> 00:42:30.391 I think the author of this blog post also mentions that he tried not 00:42:30.391 --> 00:42:32.341 to pull in too many dependencies. 00:42:32.341 --> 00:42:40.471 So like did not pull in fetch wrappers or data fetch tools like React Query and. 00:42:40.981 --> 00:42:45.091 Axios, the data fetch thing, which many people still use, I don't know. 00:42:45.451 --> 00:42:49.651 They still have a fair amount of utility just for things like observability and 00:42:49.651 --> 00:42:51.991 security and various guarantees like that. 00:42:52.291 --> 00:42:57.271 Like Axios itself is 36 kilobytes ified like 14 compressed. 00:42:57.631 --> 00:42:59.881 React Query is 55 kilobytes. 00:42:59.911 --> 00:43:05.431 I guess to say that the way he did it is actually better quote unquote 00:43:05.431 --> 00:43:09.871 for React in terms of the bundle size argument, but it's also not representative 00:43:09.871 --> 00:43:11.311 of how people actually build apps. 00:43:11.371 --> 00:43:16.171 It's a challenge of these types of articles is that by necessity it has 00:43:16.171 --> 00:43:20.221 to be the level of scope that a single developer can execute on their own, and 00:43:20.221 --> 00:43:21.481 that's just not how most apps are built. 00:43:21.511 --> 00:43:23.551 Like most apps are not passion projects by one person. 00:43:23.551 --> 00:43:24.241 So yeah. 00:43:24.721 --> 00:43:25.261 Super cool. 00:43:25.261 --> 00:43:26.251 Love this post. 00:43:26.911 --> 00:43:29.851 It's interesting more than it is authoritative, I think. 00:43:30.361 --> 00:43:30.931 Mark: Good way to put it. 00:43:31.141 --> 00:43:32.921 Mo, tell us about Solito. 00:43:33.501 --> 00:43:34.831 Mo: Yes, Solito. 00:43:35.101 --> 00:43:36.871 So go back a few months. 00:43:36.871 --> 00:43:40.001 You'll remember that we said Fernando Rojo joined Vercel. 00:43:40.321 --> 00:43:42.631 And he joined as the head of mobile firm Vercel. 00:43:43.081 --> 00:43:46.851 This was significant because he's the author of this library called Solito 00:43:47.161 --> 00:43:49.171 and a few other libraries like Ziga. 00:43:49.471 --> 00:43:52.801 So he's really, for the last few years, has been focused on. 00:43:53.341 --> 00:43:56.911 Using React native on the web as well, especially with Next.JS. 00:43:57.301 --> 00:43:59.461 So he built his own startup in that sort of tech stack. 00:43:59.821 --> 00:44:03.721 It is from experience and having built with this tech stack quite a lot, 00:44:03.991 --> 00:44:09.331 it's a challenging approach because you are always balancing oversharing 00:44:09.331 --> 00:44:14.461 between your native components and your React native code and the web 00:44:14.461 --> 00:44:16.111 functionality that you import in. 00:44:16.111 --> 00:44:20.281 And oftentimes that comes at a detriment of performance or ux, 00:44:20.581 --> 00:44:22.321 depending on if you do it right. 00:44:22.651 --> 00:44:27.241 And the more that you share, the more chance there is that you're 00:44:27.241 --> 00:44:29.461 not, you're sharing something that you probably shouldn't share. 00:44:29.971 --> 00:44:33.661 And so there's a lot of libraries in the secret system, but Solito is 00:44:33.661 --> 00:44:37.411 probably one of the key ones where it lets you share navigation across 00:44:37.411 --> 00:44:39.061 Next.JS and React native apps. 00:44:39.421 --> 00:44:42.451 Now, we've talked a bit about Toledo in the past. 00:44:42.691 --> 00:44:46.711 One of the big limitations that any library in this space has is 00:44:46.711 --> 00:44:49.591 that it relies on React Native Web Now, React native web was

00:44:49.591 --> 00:44:50.941 made several, several years ago. 00:44:50.941 --> 00:44:52.231 I think it was back in 2015. 00:44:52.756 --> 00:44:55.036 And it was made by Nicholas Gallagher. 00:44:55.036 --> 00:44:58.336 Now, he also did a talk at React Conf, which I would recommend 00:44:58.336 --> 00:45:00.406 you watch about React strict dom. 00:45:00.646 --> 00:45:04.126 But the key thing with React Native Web is that it's not really receiving 00:45:04.126 --> 00:45:07.366 as much love because Nicholas is working more on React strict dom, which 00:45:07.366 --> 00:45:11.506 is sort of like the future path for sharing code across the web and mobile. 00:45:11.986 --> 00:45:15.646 And so React native web is, is a little bit bloated, and what that means is 00:45:15.646 --> 00:45:19.006 that any library that you really use, especially your, something like your 00:45:19.006 --> 00:45:23.326 navigation and routing library will import in large portions of React Native Web, 00:45:23.326 --> 00:45:25.036 even if you're not using all of the APIs. 00:45:25.396 --> 00:45:28.246 And so that means that your bundle size goes through the roof. 00:45:28.696 --> 00:45:33.586 And what the Vercel team slash Fernando Roho have now been able to do is actually 00:45:33.586 --> 00:45:38.836 remove React Native Web as a dependency from from Solito, which is pretty massive. 00:45:39.196 --> 00:45:43.936 It sets us up in a foundation where you can effectively get ready for React 00:45:43.936 --> 00:45:48.676 strict dom adoption more easily in the long run, but also means that if you 00:45:49.066 --> 00:45:53.686 pick and choose your libraries well, when you're building a UniVercel app and you 00:45:53.686 --> 00:45:58.486 really think about what you're using on the web platforms, you can really start 00:45:58.486 --> 00:45:59.986 to tackle that bundle size problem. 00:46:00.586 --> 00:46:03.616 It doesn't help if you're using libraries like let's say Reanimated, which has a 00:46:03.616 --> 00:46:05.326 pretty heavy reliance on React Native web. 00:46:05.851 --> 00:46:09.301 But if you're going really vanilla and you're very careful, it means that 00:46:09.301 --> 00:46:14.041 you can actually achieve much better performance on the web by using this new 00:46:14.041 --> 00:46:15.961 version of Solito, which is very exciting. 00:46:16.321 --> 00:46:19.711 So yeah, if you're already using Solito, give it a look and if you're 00:46:19.711 --> 00:46:22.501 thinking of building a uniVercel app, it's a really good candidate if 00:46:22.501 --> 00:46:25.441 you wanna build a highly performant web variant of your application. 00:46:25.711 --> 00:46:26.251 Carl: I love that. 00:46:26.311 --> 00:46:29.461 It definitely makes a lot of sense to start moving away from 00:46:29.461 --> 00:46:32.971 React Native Web, given that we've compared and contrasted React Native 00:46:32.971 --> 00:46:35.011 Web with like React strict dom. 00:46:35.141 --> 00:46:37.911 I guess it makes sense to move away from React native web, 'cause 00:46:37.911 --> 00:46:42.591 the guy who made it is now doing a different thing in the exact same 00:46:42.591 --> 00:46:44.691 space from a very different angle. 00:46:44.721 --> 00:46:47.601 So yeah, that's a pretty strong argument for changing. 00:46:49.056 --> 00:46:56.376 Mark: Okay, the last major topic for the day next 16 and directives. 00:46:56.616 --> 00:46:58.506 So next 16 came out. 00:46:58.956 --> 00:47:03.606 The headline feature is they now have what they're calling cash components. 00:47:04.146 --> 00:47:08.256 This is the, I don't know, second, third, fourth iteration on how 00:47:08.256 --> 00:47:11.766 to do caching in next, across the last couple major versions. 00:47:12.276 --> 00:47:14.976 I'm not gonna pretend that I understand what, how this works. 00:47:15.336 --> 00:47:19.056 No one does, but thing is that they introduced. 00:47:19.351 --> 00:47:21.391 Another new directive. 00:47:21.451 --> 00:47:25.981 Now to recap a directive is these little strings that you just put in your code. 00:47:26.521 --> 00:47:33.721 Originally we had use strict back in the ES 2015 days and then React server 00:47:33.721 --> 00:47:40.341 components introduced, use server and use client, and now we have 'use cache'. 00:47:40.681 --> 00:47:44.851 And the idea is that by slapping this directive on certain components, that 00:47:44.851 --> 00:47:48.871 tells the next bundler and compiler that, Hey, this is the output of this 00:47:48.871 --> 00:47:50.461 component is supposed to be cached. 00:47:50.491 --> 00:47:51.631 I don't understand the details. 00:47:51.631 --> 00:47:53.821 From there, go read the documentation long. 00:47:53.821 --> 00:48:00.301 With that, they also announced a new long-lived workflow product, kind of 00:48:00.301 --> 00:48:02.636 similar to what the temporal company. 00:48:03.311 --> 00:48:07.661 Has built where you can have a function, for example, that implements a billing 00:48:07.661 --> 00:48:13.931 workflow by sweeping for 30 days and you've written what looks like one 00:48:13.931 --> 00:48:18.851 function, but under the hood it's actually like saving its status to a database and 00:48:18.851 --> 00:48:22.961 then a time job wakes it up and continues executing the code, that sort of thing. 00:48:23.591 --> 00:48:30.521 And I believe they opted to implement this also with a use workflow directive 00:48:30.521 --> 00:48:32.441 and like a use step directive. 00:48:33.271 --> 00:48:37.411 And I think there may have even been one or two others related to 00:48:37.411 --> 00:48:42.781 variations on caching, like use Cache, remote, something like that. 00:48:43.261 --> 00:48:46.891 And meanwhile, we've also got the React compiler has opted to use 00:48:46.891 --> 00:48:48.691 directives for a couple things. 00:48:48.691 --> 00:48:52.321 So there's a use no memo directive. 00:48:52.321 --> 00:48:57.571 If you

want to tell the compiler, don't try to auto optimize this component. 00:48:58.111 --> 00:49:03.301 And so all of a sudden we've gone from the JavaScript language specifying. 00:49:03.681 --> 00:49:04.881 One directive. 00:49:05.241 --> 00:49:10.821 There was also the unofficial, oh, was it use a SM directive that 00:49:10.821 --> 00:49:15.951 was part of a SM js, the precursor to web assembly, but like one 00:49:15.951 --> 00:49:17.931 official directive in the language. 00:49:18.411 --> 00:49:22.341 And now we have a couple for bundlers, and now we have more for workflows and 00:49:22.341 --> 00:49:23.961 the compiler and all these other things. 00:49:24.531 --> 00:49:28.131 And so the Twitter discourse over the last couple weeks has 00:49:28.131 --> 00:49:31.281 been our directives, good or bad. 00:49:31.341 --> 00:49:34.911 And they're so confusing and they are changing the language. 00:49:34.911 --> 00:49:39.951 And you have all this bundler defined behavior that is not 00:49:39.951 --> 00:49:41.151 part of the language spec. 00:49:41.661 --> 00:49:45.321 And so Tanner Linsley, again, creator of all the different Tan Stack 00:49:45.321 --> 00:49:50.541 libraries, put out a blog post where he expressed his opinion that he does 00:49:50.541 --> 00:49:53.151 not think directives are a good idea. 00:49:53.496 --> 00:49:58.386 Because they are unofficial, because they're not standardized, because make 00:49:58.386 --> 00:50:03.456 it not clear what the actual intended behavior ought to be, as opposed to 00:50:03.456 --> 00:50:08.856 like explicitly importing a function that says, turn this into a client 00:50:08.856 --> 00:50:11.196 server function or something like that. 00:50:11.676 --> 00:50:16.206 So there there's been a lot of arguing about directives 00:50:16.236 --> 00:50:18.366 and are they understandable? 00:50:18.366 --> 00:50:19.386 Are they good or bad? 00:50:19.386 --> 00:50:20.466 Are they too much magic? 00:50:20.916 --> 00:50:22.176 So that's been happening. 00:50:22.536 --> 00:50:23.106 Carl: I'll say it. 00:50:23.166 --> 00:50:23.736 They're bad. 00:50:23.826 --> 00:50:24.576 It's too much magic. 00:50:24.576 --> 00:50:25.146 I hate it. 00:50:25.231 --> 00:50:25.926 I'm not a fan. 00:50:26.461 --> 00:50:27.751 Mark: I understand the thought process. 00:50:27.776 --> 00:50:29.371 I, I can't say I'm thrilled. 00:50:29.701 --> 00:50:33.241 And so on that note, two article articles that are related enough 00:50:33.241 --> 00:50:34.561 to throw them into this section. 00:50:34.891 --> 00:50:41.341 I've seen lots of different article articles upset at Next or critiquing next. 00:50:41.341 --> 00:50:45.451 Most of them are frankly very badly written, but I saw one come out last 00:50:45.451 --> 00:50:49.651 week that I thought was very well written and focused strictly on the technical 00:50:49.831 --> 00:50:52.231 pros and cons of using the App Router. 00:50:52.651 --> 00:50:56.161 The title is Clickbait, everyone Hates Next, but the article itself 00:50:56.161 --> 00:50:57.541 is actually very well written. 00:50:57.541 --> 00:51:01.531 It discusses technical aspects of using Next, some of the problems his 00:51:01.531 --> 00:51:06.421 team went in, ran into, and how and why they ended up migrating from the 00:51:06.421 --> 00:51:08.671 App Router over to 10 Stack Start. 00:51:08.911 --> 00:51:13.051 And then Nadia Vic, who has done a bunch of very excellent articles on 00:51:13.051 --> 00:51:18.871 React rendering behavior, put together a very data-driven look into do server 00:51:18.871 --> 00:51:23.761 components actually help with things like First Contentual Paint and various 00:51:23.761 --> 00:51:25.471 other White House style metrics. 00:51:26.066 --> 00:51:27.266 So very worth reading. 00:51:27.836 --> 00:51:31.796 Carl: As I'm trying to think about how you might solve problems of caching 00:51:31.856 --> 00:51:35.216 and runtime things without directives. 00:51:35.696 --> 00:51:38.366 And I'm thinking about, you know, my experiences using like CloudFlare 00:51:38.366 --> 00:51:44.996 workers or other runtimes where it's not a traditional process scope. 00:51:45.356 --> 00:51:48.926 And I don't know, I guess like it is a really challenging question 00:51:48.926 --> 00:51:52.496 of like, how do you signal to a developer that the file they're editing 00:51:52.736 --> 00:51:55.856 runs in a certain type of context? 00:51:56.336 --> 00:51:59.516 And I guess I understand why directives are an appealing thing to 00:51:59.516 --> 00:52:04.886 reach for, but man, just the state we're in right now is really a lot. 00:52:05.366 --> 00:52:09.676 I found the Next.JS docs page with directives and it lists 'use cache', 00:52:09.896 --> 00:52:13.846 'use client', 'use server', and then two sub variants of 'use cache'. 00:52:14.396 --> 00:52:19.706 And that's not all of 'em that, so there's missing ones here and. 00:52:20.426 --> 00:52:20.786 I don't know. 00:52:20.786 --> 00:52:26.306 When you start getting into like many different contexts, just naming 00:52:26.306 --> 00:52:30.266 them at the top of the file doesn't really seem like enough for me. 00:52:30.296 --> 00:52:30.656 I don't know. 00:52:30.656 --> 00:52:35.696 And then like the implication for that code can import other code that will not 00:52:35.696 --> 00:52:40.016 have it flagged what context it's running in via a directive at the top of the file. 00:52:40.806 --> 00:52:41.646 And I don't know. 00:52:41.676 --> 00:52:42.426 It's a tough problem. 00:52:42.426 --> 00:52:47.766 It's a weird unanswered question in the industry, like not even the 00:52:47.766 --> 00:52:49.296 ecosystem, but like the industry. 00:52:49.296 --> 00:52:54.756 How do you flag code that might run on your browser, a real server, serverless 00:52:54.756 --> 00:52:57.126 environment, and yeah, I don't know. 00:52:57.816 --> 00:52:58.506 It's a challenge. 00:52:58.986 -->

00:53:02.376 Mark: I think it really does speak to the overhead and mental complexity 00:53:02.646 --> 00:53:04.266 of trying to juggle all these things. 00:53:04.566 --> 00:53:09.906 We said earlier that React 19 has, 18, 19 have introduced a whole lot of things 00:53:09.906 --> 00:53:15.036 like transitions and other pieces to try to let you write better user experiences. 00:53:15.546 --> 00:53:19.476 But now you're having to juggle in your head like, here's the current version 00:53:19.476 --> 00:53:24.516 of my app in its display state versus a work in progress rendered version 00:53:24.906 --> 00:53:27.996 versus a future output rendered version. 00:53:28.536 --> 00:53:33.111 On the server side we're having to deal with, this is server code, this is client 00:53:33.111 --> 00:53:36.231 code, sometimes they're mixed together in the same file, sometimes they're 00:53:36.231 --> 00:53:37.941 mixed together in the same component. 00:53:38.241 --> 00:53:39.351 Which code is running? 00:53:39.351 --> 00:53:44.181 In which context do I have to worry about accidentally leaking security 00:53:44.181 --> 00:53:45.681 tokens or something like that. 00:53:46.071 --> 00:53:50.991 We're building tools to solve real problems, but there's more and more 00:53:50.991 --> 00:53:53.271 to juggle in your head as you go. 00:53:53.661 --> 00:53:57.621 Carl: Well, I'm gonna plug effect one more time because I saw it come up in the chat. 00:53:57.951 --> 00:53:58.521 Oh, man. 00:53:58.551 --> 00:54:04.611 It just like talking about different ways of signaling facts about the code. 00:54:04.611 --> 00:54:06.651 The code you're writing has certain dependencies. 00:54:06.651 --> 00:54:08.841 Certain dependencies is too loaded. 00:54:08.841 --> 00:54:11.661 That's, that carries too much context with it, but the code you write 00:54:11.661 --> 00:54:16.446 has a certain amount of assumption baked into it about what will be 00:54:16.446 --> 00:54:20.106 available and what it can rely on. 00:54:20.466 --> 00:54:23.286 The thing I love about a fact is that it makes that more explicit 00:54:23.316 --> 00:54:26.196 and brings it into the type system. 00:54:26.706 --> 00:54:32.346 So I think the challenge right now is that we are missing a like platform 00:54:32.346 --> 00:54:38.346 and language level abstraction to express information like this. 00:54:38.916 --> 00:54:41.886 And yeah, I don't think we're gonna get it anytime soon. 00:54:41.976 --> 00:54:46.536 And I think these explorations will lead to something like that and 00:54:46.536 --> 00:54:47.646 hopefully converge into something. 00:54:47.646 --> 00:54:51.426 But I think this is gonna be like a real state-of-the-art problem 00:54:51.426 --> 00:54:55.176 for a couple of years and still, which I hate, but it'll get better. 00:54:56.136 --> 00:54:57.966 Mark: Alright, moving on to the lightning round. 00:54:58.386 --> 00:55:03.036 In addition to React Con and Remix Jam, we also had Vite Conf and the V 00:55:03.036 --> 00:55:06.966 team gave a bunch of updates on all the different tools they've been working on. 00:55:07.356 --> 00:55:12.366 Some of the highlights to me were that OX LT now supports ES lint and JS 00:55:12.366 --> 00:55:19.266 plugins via some really awesome tricks for interop between js and rust without 00:55:19.296 --> 00:55:21.456 the the cost of serial serialization. 00:55:21.996 --> 00:55:28.116 They announced a combined tool chain called v plus, which basically pulls 00:55:28.236 --> 00:55:33.696 all the different tools, VIOX lint, OX format, Vitest, everything else together. 00:55:34.056 --> 00:55:37.656 That'll be their enterprise sales targeted tool set. 00:55:37.986 --> 00:55:41.436 And then Vitest four is out with browser mode support. 00:55:42.006 --> 00:55:45.606 You basically just put a flag in your Vitest config and suddenly 00:55:45.606 --> 00:55:48.936 your tests are running in a real browser instead of a node plus js. 00:55:49.446 --> 00:55:55.866 Last week, AWS east went down and the internet died and they put out the 00:55:55.866 --> 00:56:02.736 postmortem and it was DNS apparently they, their internal DNS system for 00:56:02.736 --> 00:56:08.046 dynamo DB had like three different instances of the DNS updater running 00:56:08.556 --> 00:56:13.326 and one of them got stuck and was taking a long time to complete, and the other 00:56:13.326 --> 00:56:17.766 one came along and updated and then said, well, these, some of these plans 00:56:17.766 --> 00:56:19.296 look out of date, let's delete them. 00:56:19.776 --> 00:56:23.766 And next thing you know, DNS goes down, dynamo DB goes down 00:56:23.766 --> 00:56:26.076 and the internet goes down. 00:56:26.586 --> 00:56:28.056 So, oops. 00:56:28.386 --> 00:56:31.326 Mo: It's funny that the, uh, internet is backed by Dynamo db. 00:56:31.506 --> 00:56:34.266 Mark: A lot of people like us East One is the default. 00:56:34.356 --> 00:56:37.116 A lot of people have tried to get away from US East one, but when a lot 00:56:37.116 --> 00:56:39.276 of Amazon's own stuff depends on US. 00:56:39.276 --> 00:56:39.906 East one. 00:56:40.236 --> 00:56:40.536 Yep. 00:56:40.596 --> 00:56:40.986 You all 00:56:40.986 --> 00:56:43.416 Mo: of your certificates can only be issued in US East one, 00:56:43.416 --> 00:56:45.006 so that doesn't really help much. 00:56:45.336 --> 00:56:50.106 Side note, if you end up working in a consultancy one day, just hope nothing 00:56:50.106 --> 00:56:53.406 like this happens because the morning of was fascinating reaching out and 00:56:53.406 --> 00:56:56.976 getting reached out to by a bunch of clients being like, my site is down. 00:56:57.486 --> 00:57:00.966 And then having to figure out what's going wrong, which is US East one on AWS. 00:57:01.056 --> 00:57:02.226 So it was a fun Monday, 00:57:02.856 --> 00:57:05.916 Carl: but at least the uh, at the end of it was a vendor is out. 00:57:06.066

--> 00:57:07.056 This is not our fault. 00:57:07.986 --> 00:57:09.606 Mo: At least it was that, which was great. 00:57:09.846 --> 00:57:10.266 Cool. 00:57:10.266 --> 00:57:10.986 Moving on. 00:57:10.986 --> 00:57:14.406 So a couple of React native lightning route items. 00:57:14.436 --> 00:57:18.516 Firstly ra, which is really cool because we've talked a little bit about live 00:57:18.516 --> 00:57:22.086 activities on iOS and iOS extensions, all of the little widgets and stuff 00:57:22.086 --> 00:57:24.126 that you can now use on your iPhone. 00:57:24.306 --> 00:57:28.476 And you were able to use iOS extensions within a React native app. 00:57:28.626 --> 00:57:30.846 But the challenge was you had to write SWIFT code to be able 00:57:30.846 --> 00:57:32.016 to actually implement those. 00:57:32.136 --> 00:57:37.866 And so a independent developer named S has been working on building an MPM 00:57:37.866 --> 00:57:42.246 package that allows you to ship these custom widgets and extensions without 00:57:42.246 --> 00:57:47.496 needing to use Swift X code or extra js, which is so cool because he's basically 00:57:47.496 --> 00:57:54.756 had to like write a translation layer or a render that takes React UI code. 00:57:55.311 --> 00:58:00.921 And converted to Swift UI code, which is not trivial because many 00:58:00.921 --> 00:58:02.811 have tried before him and failed. 00:58:03.081 --> 00:58:06.441 So this is a really cool project and like it's one of those things 00:58:06.441 --> 00:58:07.911 that's like kind of mind blowing. 00:58:08.151 --> 00:58:09.951 So kudos to him for making this. 00:58:10.371 --> 00:58:13.341 Secondly, and I thought this was an interesting article to link to. 00:58:13.491 --> 00:58:20.001 On the expo blog, they publish an article about building fully native apps with EAS. 00:58:20.031 --> 00:58:22.491 So EAS is expo's application services. 00:58:22.791 --> 00:58:28.971 Typically, this is being used to build React native apps that are usually 00:58:28.971 --> 00:58:33.741 running on Expo, but actually a lesser known fact, and one that we've actually 00:58:33.741 --> 00:58:37.131 used on some of our apps is that you don't need to be on Expo and you don't 00:58:37.131 --> 00:58:38.511 even need to be on a React native app. 00:58:39.081 --> 00:58:43.971 And so EAS is really great and it's become super mature and it's a really just good 00:58:43.971 --> 00:58:45.531 build tool for building mobile apps. 00:58:45.861 --> 00:58:49.251 And so people have started to use it in the wider mobile community rather 00:58:49.251 --> 00:58:51.831 than it just being a React native thing, which is quite cool to see. 00:58:52.311 --> 00:58:57.801 And lastly, this was something that Tzveton from the Hermes team in Meta 00:58:57.801 --> 00:59:00.261 actually, uh, published a week or so ago. 00:59:00.561 --> 00:59:05.241 And this was actually something he linked me on a DM because we were chatting about 00:59:05.241 --> 00:59:08.541 interesting things that could be talked about at a conference by a Hermes team. 00:59:08.961 --> 00:59:10.371 And this was quite cool to see. 00:59:10.371 --> 00:59:16.581 So for those who don't know, Imgui is like a very light UI layer that is powering a 00:59:16.581 --> 00:59:18.201 lot of sort of debugging for video games. 00:59:18.786 --> 00:59:21.516 And it's used in a bunch of other places, but like the key thing is that it's just 00:59:21.516 --> 00:59:23.976 like a very, very lightweight UI layer. 00:59:24.276 --> 00:59:29.736 And so he made a puck of basically using React and then rendering 00:59:29.736 --> 00:59:31.416 it on Imgui, which is quite cool. 00:59:31.806 --> 00:59:33.846 And it runs obviously like fully natively. 00:59:33.846 --> 00:59:36.186 It's fully running on c plus plus. 00:59:36.276 --> 00:59:41.706 And all it really needed was some typed JavaScript and it's basically just 00:59:41.706 --> 00:59:43.566 React really, which is quite cool. 00:59:43.836 --> 00:59:47.286 So yeah, it's just a little cool fun POC, but it shows the power 00:59:47.286 --> 00:59:51.696 of using React and how it can be applied to different contexts, which 00:59:51.696 --> 00:59:52.896 I thought was quite cool to include. 00:59:53.301 --> 00:59:57.681 Mark: Okay, Lodash has powered much of the JavaScript ecosystem for years. 00:59:57.771 --> 01:00:00.711 Those of us who have been around for a while, remember its predecessor, 01:00:02.031 --> 01:00:05.481 but low, has also been relatively unmaintained for a while. 01:00:05.811 --> 01:00:09.171 The author John David Dalton, said there was going to be a low dash 01:00:09.171 --> 01:00:13.941 version five, and then that never really happened, and so some announcements 01:00:13.941 --> 01:00:15.231 came out in the last week or two. 01:00:15.261 --> 01:00:21.141 That low dash is being taken over by a new maintenance foundation, and they're 01:00:21.141 --> 01:00:25.731 going to be doing work to update the ci, put out some new maintenance releases, 01:00:26.121 --> 01:00:31.041 and then apparently when low dash V five happens, it'll be more about stripping 01:00:31.041 --> 01:00:35.991 out a lot of the internals that tried to polyfill platform behavior and 01:00:35.991 --> 01:00:40.071 try and make it lighter and make use of platform built-ins at this point. 01:00:40.491 --> 01:00:43.581 So Lodash is still around, it ain't going anywhere, and good 01:00:43.581 --> 01:00:44.871 to see it being maintained. 01:00:45.381 --> 01:00:50.211 And then there was a really good post unrelated to React, but cool on building 01:00:50.211 --> 01:00:56.631 your own key value database system that walks through a whole bunch of pieces on 01:00:56.661 --> 01:01:01.071 what a key value database actually has to track and how the internals would work. 01:01:01.071 --> 01:01:03.801 And I believe it's actually pretty interactive, which is cool. 01:01:04.101 --> 01:01:07.371 Carl:

This build your own database post, I love, this is so good. 01:01:07.371 --> 01:01:10.701 I love when people rebuild foundational building blocks. 01:01:11.151 --> 01:01:14.001 And this is also something I've thought about a little bit because he talks 01:01:14.001 --> 01:01:17.361 about in a file, you know, if you need to store something, put it in a file. 01:01:18.021 --> 01:01:21.531 And this is something I've thought about a little bit because I have been 01:01:21.531 --> 01:01:25.521 using SQL Light pretty extensively in my own work the last couple of years. 01:01:26.001 --> 01:01:27.951 And at the end of the day, sequel light is a file. 01:01:28.161 --> 01:01:31.791 So like when I realized that like most of the time. 01:01:32.466 --> 01:01:35.616 If I want to store something in a file, like I should just use sql, 01:01:35.886 --> 01:01:38.346 you put something in a file and then the file gets too big and you need 01:01:38.346 --> 01:01:42.096 to optimize it, and you need a better way to access it and like, oh, maybe 01:01:42.096 --> 01:01:44.706 I could use a more descriptive query language to get things out of it. 01:01:44.706 --> 01:01:50.376 And like the end result is that you will recreate a shittier less performant 01:01:50.616 --> 01:01:53.406 version of SQLite that doesn't use sequel. 01:01:54.006 --> 01:01:54.846 And so, I don't know. 01:01:54.846 --> 01:01:58.206 I just like reading this that was very strongly on my mind and 01:01:58.626 --> 01:02:00.936 everyone should do SQLite if they start putting things in a file. 01:02:00.966 --> 01:02:01.896 'cause it's just a file. 01:02:02.256 --> 01:02:02.706 It's cool. 01:02:02.736 --> 01:02:03.156 I like it. 01:02:03.606 --> 01:02:07.866 Mark: The SQL Light website even has a page that says why, why you should 01:02:07.866 --> 01:02:14.076 consider just using SQL L as your app's file format rather than inventing 01:02:14.076 --> 01:02:16.356 another new binary format from scratch. 01:02:16.566 --> 01:02:17.196 Carl: A hundred percent. 01:02:17.196 --> 01:02:20.766 If you start right, if you start thinking I should put this in a binary 01:02:20.766 --> 01:02:22.776 format on disc, like no, stop it. 01:02:22.986 --> 01:02:23.646 Use SQLite. 01:02:23.856 --> 01:02:24.306 It's great. 01:02:24.816 --> 01:02:25.086 Mark: Alright. 01:02:25.146 --> 01:02:28.956 Jared Palmer, the creator of the Formik Library, has had 01:02:28.956 --> 01:02:30.786 been at V at Vercel for years. 01:02:30.876 --> 01:02:35.026 He worked on turbo repo, v0. 01:02:35.046 --> 01:02:37.896 And he announced just a month or two ago he was leaving Vercel. 01:02:38.166 --> 01:02:44.856 He has then announced that he has joined Microsoft as a senior VP at GitHub. 01:02:45.576 --> 01:02:50.376 And the first thing he did was post on Twitter saying, how can we make 01:02:50.376 --> 01:02:53.166 the GitHub PR experience better? 01:02:53.676 --> 01:02:57.996 And he got like eight or 900 replies,

and he was pretty actively 01:02:57.996 --> 01:02:58.986 engaging with a lot of 'em. 01:02:58.986 --> 01:03:03.036 A lot of them were people asking for things like Stacked Diff support, so 01:03:03.036 --> 01:03:06.636 you could have multiple PR branches that depend on each other and be 01:03:06.636 --> 01:03:08.406 able to automatically update them. 01:03:08.961 --> 01:03:12.681 He actually came back even just a couple days later and gave some 01:03:12.681 --> 01:03:17.631 technical details that he had found after internal discussions on here were 01:03:17.631 --> 01:03:23.391 some previous prototypes of stacked diffs at GitHub and how, like how far 01:03:23.391 --> 01:03:25.431 they got and what the blockers were. 01:03:25.911 --> 01:03:30.951 So I have no idea how long it'll take to roll out any of this stuff, but like 01:03:30.951 --> 01:03:35.811 he seems pretty serious about trying to improve the PR experience, whether 01:03:35.811 --> 01:03:40.341 it's paper cuts or new functionality and is trying to look into that stuff. 01:03:40.431 --> 01:03:43.731 So given that we all pretty much depend on the GitHub PR experience, 01:03:43.731 --> 01:03:45.201 I'm happy to see improvements. 01:03:45.711 --> 01:03:46.071 Carl: Yep. 01:03:46.071 --> 01:03:46.701 Love that. 01:03:46.851 --> 01:03:47.061 Wow. 01:03:47.061 --> 01:03:48.231 This is very jargon heavy. 01:03:48.321 --> 01:03:50.341 Mark: Yeah, I, I know, that's why I was happy to see it. 01:03:50.751 --> 01:03:51.411 Cool. 01:03:51.891 --> 01:03:53.751 Carl: Sounds like a technical roadmap. 01:03:54.141 --> 01:03:59.061 Mark: Couple other bits, node 25 is out and so another development line branch 01:03:59.061 --> 01:04:02.541 for node and the biggest thing there is they've updated the version of V 01:04:02.541 --> 01:04:07.731 eight and that includes those faster js ON string of FI improvements that we, 01:04:07.761 --> 01:04:09.321 we talked about a couple months ago. 01:04:09.801 --> 01:04:12.951 So given how much everything depends on JSONs string offi, it's 01:04:12.981 --> 01:04:14.781 nice to see that being sped up. 01:04:15.306 --> 01:04:20.256 And speaking of more optimization work, I believe Theo put out a benchmark 01:04:20.406 --> 01:04:25.206 where he was comparing CloudFlare in Vercel in Building Next versus 01:04:25.206 --> 01:04:26.916 Vanilla versus a couple other things. 01:04:27.366 --> 01:04:32.016 And it pointed out places that both Vercel and CloudFlare were slow and 01:04:32.046 --> 01:04:35.976 CloudFlare jumped on this and they found a bunch of places in their system. 01:04:36.246 --> 01:04:38.046 Where things could be optimized. 01:04:38.526 --> 01:04:42.246 They did a excellent blog post detailing some of the improvements. 01:04:42.546 --> 01:04:46.476 They also went in and they looked at next itself and they found a bunch of places 01:04:46.476 --> 01:04:54.216 where Next is doing like useless request copying like 1500 or 1700 request streams 01:04:54.666 --> 01:04:56.976 per request or something like that. 01:04:57.276 --> 01:05:01.086 So basically everybody is getting faster as a result of 01:05:01.086 --> 01:05:01.841 this, which is a good thing. 01:05:02.681 --> 01:05:04.841 Mo: CloudFlare folks are just doing some great work recently, 01:05:04.931 --> 01:05:07.871 especially with the whole like workers rebrand as well is really cool. 01:05:07.991 --> 01:05:12.821 Mark: So Interop is an attempt to get all the different browsers on the 01:05:12.821 --> 01:05:17.051 same page in terms of what features they're working on, especially around 01:05:17.051 --> 01:05:19.391 compatibility with each other each year. 01:05:19.811 --> 01:05:25.061 And so this year the Firefox folks put up a rather nifty interactive 01:05:25.061 --> 01:05:29.231 suggestions thing where they list dozens, like 50 or a hundred different 01:05:29.231 --> 01:05:35.261 potential features or technical areas of emphasis that they could spend time on. 01:05:35.771 --> 01:05:39.431 And it's got a neat drag and drop interface where you can basically use that 01:05:39.431 --> 01:05:44.261 as a way to vote for which features do you want browser manufacturers to work on? 01:05:44.751 --> 01:05:45.171 This year. 01:05:45.801 --> 01:05:46.311 Carl: Love that. 01:05:46.551 --> 01:05:46.761 Yeah. 01:05:46.761 --> 01:05:49.821 They say they're gonna publish the final selection of proposals 01:05:49.821 --> 01:05:52.341 in February, so I'll, I'll keep an eye out on that, I guess. 01:05:52.851 --> 01:05:53.181 Cool. 01:05:53.241 --> 01:05:56.691 Chris Chedeau, vjeux, he has been really prolific in the 01:05:56.691 --> 01:05:58.461 React ecosystem for many years. 01:05:58.461 --> 01:06:02.961 Was really influential in React becoming open source and was the original 01:06:02.961 --> 01:06:07.971 author of Prettier, which changed my professional experience significantly. 01:06:08.271 --> 01:06:12.621 He put out a blog post titled The Birth of Prettier earlier this month. 01:06:12.681 --> 01:06:15.111 I'd spent almost 10 years since Prettier was released. 01:06:15.111 --> 01:06:16.851 He says, which is wild. 01:06:17.241 --> 01:06:21.261 I like his introduction of this is the story of how the tabs first spaces 01:06:21.261 --> 01:06:23.796 Holy War ended, and yeah, it did. 01:06:23.931 --> 01:06:24.681 I appreciate that. 01:06:24.711 --> 01:06:28.231 I actually just did a little DX PR for a code base. 01:06:28.231 --> 01:06:33.301 I maintain to make better use of prettier because somebody created a plugin to 01:06:33.301 --> 01:06:36.271 sort imports and like, yes, I love that. 01:06:36.271 --> 01:06:39.121 I hate sorting my imports and I hate when of my imports are not sorted. 01:06:39.601 --> 01:06:43.801 The introduction of automated formatting into the JavaScript ecosystem 01:06:43.801 --> 01:06:46.351 was, oh, what a, what a blessing. 01:06:46.591 --> 01:06:48.121 Like what

hours? 01:06:48.301 --> 01:06:51.781 The years of my life that have been saved from arguing over 01:06:51.781 --> 01:06:55.741 formatting is just really lovely and this is a great retrospective. 01:06:55.861 --> 01:06:58.351 Looking into just the whole process of how it came out. 01:06:58.381 --> 01:07:00.361 Mark: There's some fascinating details in there. 01:07:00.571 --> 01:07:04.501 Carl: Yeah, like one of the challenges of this that I remember in the moment a 01:07:04.501 --> 01:07:10.351 little bit, but like if you're gonna start formatting things, the format needs to 01:07:10.351 --> 01:07:15.141 be something relatively unobjectionable to the people who are evaluating 01:07:15.141 --> 01:07:16.491 whether they want to use it or not. 01:07:16.551 --> 01:07:23.931 Like, yeah, so, and then figuring out what options should be exposed, 01:07:23.931 --> 01:07:25.851 what is actually configurable, because if you make it too 01:07:25.851 --> 01:07:27.921 configurable, then it's not helpful. 01:07:28.371 --> 01:07:35.361 If it's too much manual thing, then it's not actually consistent enough to 01:07:35.361 --> 01:07:37.371 be valuable at its intended purpose. 01:07:37.371 --> 01:07:40.191 So lots of really interesting details throughout here. 01:07:40.401 --> 01:07:41.271 Definitely recommend it. 01:07:41.511 --> 01:07:45.741 I always love a great technical white paper, a writeup of implementation, 01:07:46.131 --> 01:07:48.051 and this is, oh boy, is this that. 01:07:48.051 --> 01:07:48.561 It's great. 01:07:49.011 --> 01:07:51.591 Mark: One of the most interesting bits I saw was he was talking about 01:07:51.591 --> 01:07:55.401 how they started rolling it out and like Prettier has some options, 01:07:55.521 --> 01:07:59.001 but they wanted to minimize them and he wanted everyone to basically 01:07:59.121 --> 01:08:02.001 agree on a single set of options. 01:08:02.451 --> 01:08:05.721 And so he said the strategy I used to figure out how to make this work was 01:08:05.721 --> 01:08:10.191 lining up incentives so that it took a ton more work to use a different 01:08:10.191 --> 01:08:12.111 set of options if you wanted to. 01:08:12.801 --> 01:08:16.791 It said Prettier is either in this, in CI or in your IDE. 01:08:17.091 --> 01:08:20.361 So I made it so that they read them from different places with a 01:08:20.361 --> 01:08:23.841 different rollout schedule to make it harder to choose one or the other. 01:08:24.651 --> 01:08:25.521 Carl: Oh, that's incredible. 01:08:25.701 --> 01:08:26.391 That's some good details. 01:08:26.391 --> 01:08:30.801 Reading this a little bit more is it's got lots of fun non-technical details 01:08:30.831 --> 01:08:34.461 that like they're not the engineering work, but they are absolutely essential 01:08:34.461 --> 01:08:40.176 for actually making a thing that is successful and sustainable and thriving. 01:08:40.266 --> 01:08:43.926 Like it also talks about money and like ongoing maintenance is 01:08:43.926 --> 01:08:45.036 a thing that you have to pay for. 01:08:45.546 --> 01:08:48.336 You don't have to, I guess most open source does not, but if you don't, 01:08:48.336 --> 01:08:49.866 then it has its own challenges. 01:08:49.866 --> 01:08:54.276 So like not only is this a great technical writeup, but it's also a great, I don't 01:08:54.276 --> 01:08:55.536 know, like entrepreneurial writeup. 01:08:55.596 --> 01:08:57.876 Mark: How do you do the, the real work to make stuff happen? 01:08:58.146 --> 01:09:01.716 Carl: People talk about the difference between like senior and staff 01:09:01.716 --> 01:09:04.746 engineering being, the difference between junior and senior is how 01:09:04.746 --> 01:09:06.546 much English you're asked to write. 01:09:06.816 --> 01:09:10.086 And the difference between senior and staff is like how much non-technical 01:09:10.086 --> 01:09:12.306 things you're asked to account for. 01:09:12.636 --> 01:09:16.806 And so this is a phenomenal, I would say, staff engineer writeup. 01:09:16.806 --> 01:09:21.456 Like, this is how you take an idea and you make it an industry level impact project. 01:09:21.546 --> 01:09:21.756 Yeah. 01:09:21.876 --> 01:09:22.331 Great Writeup. 01:09:23.061 --> 01:09:25.821 Mark: I can even point to a couple personal examples of how 01:09:25.851 --> 01:09:28.971 prettier has affected my work just within the last few days. 01:09:28.971 --> 01:09:34.251 One is that I'm jumping between the Redux repo, which is two spaces, 01:09:34.251 --> 01:09:36.591 single quotes, no semicolons. 01:09:36.921 --> 01:09:41.811 The Immer repo, which is four spaces, double quotes, and I can't, and may, 01:09:41.871 --> 01:09:46.731 maybe no single semicolons, Replay.io repo, which is four spaces, double 01:09:46.731 --> 01:09:51.651 quotes, semicolons, and I don't think about any of that anymore. 01:09:52.131 --> 01:09:59.511 And then also just yesterday, I was trying to tweak some of ER's exports and tried 01:09:59.511 --> 01:10:07.326 to put in an export type keyword, which I was pretty sure was a legit thing except 01:10:07.326 --> 01:10:09.486 that when I hit save, it didn't format. 01:10:10.176 --> 01:10:14.196 And I have learned that if it doesn't format, I have put in invalid 01:10:14.196 --> 01:10:16.776 syntax somewhere for a moment. 01:10:16.776 --> 01:10:21.276 It was like, oh, export type must not be a valid TS keyword. 01:10:21.666 --> 01:10:25.696 And then I finally realized, oh wait, this is on prettier 1.19. 01:10:25.716 --> 01:10:29.406 That must predate that syntax being added to TypeScript. 01:10:29.646 --> 01:10:34.296 And so I had to update prettier, but like that's how much I have learned to lean on. 01:10:34.296 --> 01:10:37.086 You hit save and it formats and it's valid. 01:10:37.721 --> 01:10:38.891 Carl: Yep, a hundred percent. 01:10:38.976 --> 01:10:40.571 I, I recognize that in myself as well. 01:10:41.051 --> 01:10:41.411 Okay.

01:10:41.471 --> 01:10:42.971 Let's wrap it up with some conferences. 01:10:43.241 --> 01:10:44.201 Mo: Let's jump into it. 01:10:44.201 --> 01:10:47.951 So we've hinted a few times and I can now say that we've 01:10:47.951 --> 01:10:49.601 got Seth Webster's endorsement. 01:10:49.601 --> 01:10:54.461 So the executive director of the React Foundations talks about my conference. 01:10:54.461 --> 01:10:55.361 I'm very happy today. 01:10:55.691 --> 01:10:58.781 We've been organizing this for the second year, so React Native London 01:10:58.991 --> 01:11:02.861 for anyone who's a React native enthusiast in London and beyond. 01:11:02.861 --> 01:11:05.231 We have people from Brazil and India last year, so that's like the 01:11:05.231 --> 01:11:08.411 furthest extent that we have people coming in from around the world. 01:11:08.741 --> 01:11:11.861 But if you are interested, we've got our conference on 01:11:11.861 --> 01:11:13.631 the 13th and 14th of November. 01:11:14.046 --> 01:11:17.766 In Central London, we've got a beautiful venue, some great talks from Meta, Amazon, 01:11:18.216 --> 01:11:22.656 Microsoft, and just a bunch of community people from expo and independent app 01:11:22.656 --> 01:11:25.596 developers who are gonna come and give some really, really phenomenal talks. 01:11:26.046 --> 01:11:31.116 Use the code TMIR 10 and you should get a 10% discount on checking out, which 01:11:31.116 --> 01:11:37.056 will, if I'm doing my mental maths right, make the ticket price 330 ish pounds 01:11:37.356 --> 01:11:41.826 for a two day conference to be able to attend workshops and the conference day. 01:11:42.276 --> 01:11:46.686 Carl: Um, other ones we've got coming up are Wey Wey Web November 01:11:46.686 --> 01:11:48.996 17th and 18th in Malaga, Spain. 01:11:49.206 --> 01:11:54.006 We've also got React Summit November 18th through 21st in New York. 01:11:54.096 --> 01:11:56.496 Mark: There's JS Nation on the 17th. 01:11:56.556 --> 01:12:00.456 There's in-person React Summit in person on the 18th, and then they 01:12:00.456 --> 01:12:02.196 have an online day the next week. 01:12:02.271 --> 01:12:02.301 Okay. 01:12:02.991 --> 01:12:03.921 Carl: Oh, oh, oh yes. 01:12:03.921 --> 01:12:06.291 I see it's 18th and 20th, not through. 01:12:06.441 --> 01:12:06.951 Interesting. 01:12:07.191 --> 01:12:08.091 One day in person. 01:12:08.091 --> 01:12:08.841 One day online. 01:12:09.051 --> 01:12:09.351 Okay. 01:12:09.381 --> 01:12:09.831 Makes sense. 01:12:10.341 --> 01:12:13.041 There's also React Advanced November 28th, also 01:12:13.041 --> 01:12:15.921 Mark: in London the day after Thanksgiving. 01:12:16.311 --> 01:12:18.291 Someone in England didn't think about that part. 01:12:18.861 --> 01:12:19.491 He, he, he, 01:12:19.701 --> 01:12:19.941 Carl: yeah. 01:12:19.941 --> 01:12:20.931 It's not for Americans. 01:12:21.471 --> 01:12:24.381 Mo: It's not just React Advance, it's also Tech Lead Conf, which is 01:12:24.381 --> 01:12:27.501 also organized by the Ation folks on the same day in London as well. 01:12:27.501 --> 01:12:31.161 So, no, I would doubt that there's gonna be a lot of people from 01:12:31.161 --> 01:12:32.511 the states there, unfortunately. 01:12:32.961 --> 01:12:33.381 Carl: For sure. 01:12:33.891 --> 01:12:38.541 Well, I'll, I'll also add, I just saw like two days ago, the organizer of 01:12:38.541 --> 01:12:43.551 React Paris posted in the events channel here that CFP is open, so we gotta React 01:12:43.761 --> 01:12:45.861 Paris if you want to submit a talk. 01:12:46.161 --> 01:12:48.621 But that's gonna be in like March though, so not anytime soon. 01:12:49.191 --> 01:12:49.911 That's all we got. 01:12:50.241 --> 01:12:53.061 Thanks so much for sticking around for a whole 90 minutes. 01:12:53.151 --> 01:12:54.651 Mark: It was a very busy month. 01:12:54.681 --> 01:12:55.161 Okay. 01:12:55.521 --> 01:12:55.881 Carl: Yeah. 01:12:56.001 --> 01:12:59.751 We'll be back next month, on the last Wednesday here in the live 01:12:59.751 --> 01:13:02.721 stage or back in your podcast feed just as soon as we can. 01:13:03.201 --> 01:13:03.531 Yeah. 01:13:03.591 --> 01:13:04.161 Thanks so much. 01:13:04.641 --> 01:13:07.401 Well, normally we gather sources from a variety of newsletters. 01:13:07.401 --> 01:13:10.401 We actually had so many things that Mark shared in the tech 01:13:10.401 --> 01:13:14.211 reads and news chat this month that I don't think any of us did. 01:13:14.641 --> 01:13:15.376 So that's cool. 01:13:15.706 --> 01:13:18.466 Mark: And I pasted a lot more links in the discussion threads too. 01:13:18.766 --> 01:13:20.026 Carl: That's something I should be better about. 01:13:20.026 --> 01:13:21.496 That would be lovely and helpful. 01:13:21.856 --> 01:13:24.616 But yeah, if you see anything newsworthy, definitely let us know 01:13:24.616 --> 01:13:26.986 in the Tech News and Reads channel, just like Mark has been doing. 01:13:27.376 --> 01:13:30.616 You can also email us at hello@reactiveflex.com. 01:13:30.676 --> 01:13:33.766 But you know it's a community like Join, participate. 01:13:34.186 --> 01:13:36.856 I do read every email though, so if you send something I, I will read it. 01:13:37.096 --> 01:13:39.736 If this is a show that you get value from and want to support, best way 01:13:39.736 --> 01:13:43.546 to do so is by submitting a review wherever you listen and by telling 01:13:43.546 --> 01:13:44.626 your friends and coworkers about it. 01:13:44.776 --> 01:13:47.476 And go to a meetup and say, Hey, there's this great podcast I love. 01:13:47.806 --> 01:13:48.226 Cheers. 01:13:48.556 --> 01:13:49.186 See you next month.