WEBVTT 00:00:12.540 --> 00:00:16.020 Scott: Welcome to the Bikeshed podcast, where we talk about all things software engineering, 00:00:16.700 --> 00:00:18.820 Scott: food, vacations, and keyboards. 00:00:19.640 --> 00:00:26.740 Scott: I'm your co-host, a gargoyle of Golang, CSS-obsessed, and HTML honor roll student, Scott Kaye. 00:00:27.500 --> 00:00:32.680 Scott: And alongside with me and my co-hosts, his longest relationship was his Gitlog history. 00:00:33.680 --> 00:00:35.940 Scott: He commits to prod more than any TV series. 00:00:36.860 --> 00:00:40.580 Scott: He's not here to argue, just resolve conflicts, Matt Hamlin. 00:00:41.520 --> 00:00:47.960 Scott: And my other co-host, the man who never simmers down, Dillon Spicy Take Curry. 00:00:49.120 --> 00:00:51.540 Scott: Fellas, what's on our agenda today? 00:00:53.240 --> 00:00:54.680 Matt: Another solid intro, Scott. 00:00:56.340 --> 00:01:00.640 Matt: Yeah, today we're talking about all about React server components, RSCs. 00:01:01.960 --> 00:01:05.580 Matt: They've been a thing maybe for five years now, I think. 00:01:05.820 --> 00:01:08.400 Matt: I was actually going to go back and kind of look at some of the commits in the React repo 00:01:08.460 --> 00:01:11.300 Matt: to see when they started doing some of the early experiments for it. 00:01:12.160 --> 00:01:14.140 Matt: But I think it's coming up on five years. 00:01:14.920 --> 00:01:18.380 Matt: I mean, some of the early stuff, like suspense, was 2016. 00:01:18.760 --> 00:01:22.220 Matt: So that's almost 10 years, which is kind of wild to think about. 00:01:23.960 --> 00:01:25.620 Matt: But yeah, today we want to talk about React server components. 00:01:27.080 --> 00:01:28.220 Matt: we might talk about Next. 00:01:28.740 --> 00:01:30.320 Matt: Next is sort of like the de facto 00:01:30.660 --> 00:01:32.100 Matt: implementation for RSCs, but 00:01:33.479 --> 00:01:34.520 Matt: yeah, maybe we save that 00:01:34.620 --> 00:01:35.260 Matt: for a spicy take. 00:01:37.420 --> 00:01:38.160 Scott: Oh, we're talking 00:01:38.160 --> 00:01:38.460 Scott: about 00:01:38.640 --> 00:01:39.160 Scott: next, baby. 00:01:40.460 --> 00:01:42.480 Dillon: Before we get into it, Matt, I just want to give a 00:01:42.600 --> 00:01:44.060 Dillon: shout out to one of our listeners, Will. 00:01:44.940 --> 00:01:46.760 Dillon: He's been saying that my takes are too spicy, 00:01:47.100 --> 00:01:48.280 Dillon: so I'm going to tone it down this week. 00:01:49.920 --> 00:01:50.180 Matt: Perfect. 00:01:50.580 --> 00:01:51.060 Matt: That's what we needed. 00:01:52.899 --> 00:01:53.299 Scott: Dillon, 00:01:53.299 --> 00:01:53.980 Scott: sleepyhead curry. 00:01:58.680 --> 00:02:03.200 Matt: i think it's fitting that you guys are both like sipping on coffee and i've been a bit awake for 00:02:04.240 --> 00:02:04.800 Matt: three hours now 00:02:04.800 --> 00:02:08.360 Dillon: this is coffee with most chili powder so yeah 00:02:08.360 --> 00:02:10.479 Matt: there you go 00:02:08.360 --> 00:02:10.479 Scott: you 00:02:10.479 --> 00:02:11.039 Scott: seem the most 00:02:11.220 --> 00:02:13.660 Scott: awake too matt i 00:02:13.660 --> 00:02:15.160 Matt: don't know how but yeah 00:02:15.160 --> 00:02:19.000 Scott: you got code running through your veins 00:02:21.980 --> 00:02:28.880 Matt: Scott you had sort of thrown this topic into our discussion channel that we have for these 00:02:29.020 --> 00:02:32.660 Matt: recordings and like curious like if you want to provide some background on like why you thought 00:02:33.000 --> 00:02:35.600 Matt: RSCs would be a good topic for us to dig into this week 00:02:35.600 --> 00:02:39.460 Scott: yes I think this would be a unique 00:02:39.880 --> 00:02:45.120 Scott: topic for us because we all have some experience with this we will probably get into this but we 00:02:45.080 --> 00:02:46.640 Scott: We did this at Wayfair, the three of us. 00:02:47.280 --> 00:02:56.500 Scott: We also, we did this at Wayfair, the three of us, but it was not very easy to get to the end result. 00:02:56.640 --> 00:03:02.900 Scott: I don't know if RSC was necessarily the culprit that made it hard, but I want to get into that a little bit. 00:03:03.100 --> 00:03:10.500 Scott: And we also did this at Fireworks, Matt and I, where we, it was a lot more of a streamlined process to get to done. 00:03:11.200 --> 00:03:12.660 Scott: And things were a little bit more fleshed out. 00:03:12.900 --> 00:03:18.160 Scott: So at Airbnb, they're talking about, or folks are talking about trying to get us to React server components. 00:03:18.300 --> 00:03:20.380 Scott: We want to talk about, are they worth it? 00:03:20.580 --> 00:03:22.120 Scott: What's the benefit we get from it? 00:03:22.640 --> 00:03:23.640 Scott: Is there a true benefit? 00:03:24.180 --> 00:03:29.780 Scott: How do you take a monorepo or a giant code base migrated over to React server components? 00:03:31.220 --> 00:03:35.840 Matt: Yeah, and I think, and like, you know, it's not just, you know, Dillon's experience wasn't just at Wayfair. 00:03:35.920 --> 00:03:41.420 Matt: I think at Whoop, you guys are also leaning a little bit into some server components, correct me if I'm wrong there. 00:03:42.440 --> 00:03:51.060 Dillon: Maybe we can dig into this as we get more into the topic, but I think there's a little bit of like people glance at the documentation about like, this is a server component. 00:03:51.780 --> 00:03:53.120 Dillon: All right, that's all I need to know. 00:03:53.530 --> 00:03:54.340 Dillon: That kind of made sense. 00:03:54.850 --> 00:03:57.860 Dillon: And they just start trying to integrate it into their code base. 00:03:58.680 --> 00:03:59.820 Dillon: And they don't really know what they're doing. 00:04:00.100 --> 00:04:06.460 Dillon: I'm kind of self-reporting, but I've seen this as well, where people are just like, it seems like we need this. 00:04:06.860 --> 00:04:07.520 Dillon: Let's try to use it. 00:04:08.740 --> 00:04:12.260 Dillon: And I feel like things are feeling a little bit like discombobulated. 00:04:12.320 --> 00:04:13.700 Dillon: because we're not using it correctly. 00:04:14.460 --> 00:04:15.180 Dillon: We're holding it wrong. 00:04:15.690 --> 00:04:16.320 Matt: You're holding it wrong. 00:04:16.519 --> 00:04:17.040 Matt: Yeah, exactly. 00:04:18.600 --> 00:04:21.040 Scott: Yeah, so something I will want to dig into 00:04:21.359 --> 00:04:24.160 Scott: is at Wayfair, we migrated over 00:04:25.160 --> 00:04:28.840 Scott: what was a CSR app to be an SSR app 00:04:29.000 --> 00:04:30.180 Scott: with the server components, right? 00:04:31.200 --> 00:04:33.960 Matt: Well, it was like we supported server-side rendering 00:04:34.030 --> 00:04:35.320 Matt: for a number of different pages already. 00:04:36.900 --> 00:04:37.300 Scott: Right, but the 00:04:37.300 --> 00:04:38.300 Scott: pages on Next.js 00:04:38.910 --> 00:04:42.040 Scott: we currently had over were CSR, right? 00:04:42.220 --> 00:04:42.360 Scott: category 00:04:42.360 --> 00:04:46.900 Matt: no it was client-side rendered or service-side rendered rather 00:04:46.900 --> 00:04:49.700 Matt: sorry 00:04:46.900 --> 00:04:49.700 Scott: well we did a 00:04:49.780 --> 00:04:54.060 Scott: lot of work to change services those services were just being migrated 00:04:54.060 --> 00:04:54.720 Matt: well i 00:04:54.720 --> 00:04:55.340 Scott: thought they were also 00:04:55.740 --> 00:05:01.480 Scott: well some of it was ssr'd through express right but the app itself was still client-side rendered 00:05:01.750 --> 00:05:09.259 Scott: in next 12 not next until next 13 we didn't truly have ssr hydration again right i thought we well 00:05:09.280 --> 00:05:10.320 Matt: - Okay, yeah. 00:05:11.250 --> 00:05:12.620 Matt: I mean, it might be worth talking about like, 00:05:12.780 --> 00:05:14.180 Matt: yeah, so our migration at Wayfair, 00:05:14.550 --> 00:05:16.480 Matt: we, before we adopted Next, 00:05:17.910 --> 00:05:20.100 Matt: you know, sort of like, if we go way back, 00:05:20.340 --> 00:05:21.380 Matt: we were using like a home rolled 00:05:21.680 --> 00:05:22.520 Matt: service side rendering service. 00:05:22.820 --> 00:05:23.120 Scott: - Correct. 00:05:23.580 --> 00:05:24.260 Matt: - For applications. 00:05:25.100 --> 00:05:27.460 Matt: And then, and that was like built on Express 00:05:27.800 --> 00:05:30.480 Matt: and like an internal library that handled SSR for us. 00:05:30.980 --> 00:05:32.300 Matt: You know, really just calling, yeah, react, 00:05:33.210 --> 00:05:33.500 Matt: what is it? 00:05:33.680 --> 00:05:35.520 Matt: React DOM render string or whatever. 00:05:37.240 --> 00:05:38.960 Matt: And that integrated with a PHP layer. 00:05:40.120 --> 00:05:43.260 Matt: As soon as we started to look at adopting Next, 00:05:43.850 --> 00:05:47.040 Matt: that was before Next had supported server components. 00:05:47.920 --> 00:05:49.400 Matt: They were starting to experiment with it, 00:05:49.520 --> 00:05:53.020 Matt: but primarily the pages router in Next, which 00:05:53.020 --> 00:05:56.580 Matt: is the pages directory, was the only way you build apps. 00:05:56.720 --> 00:05:59.100 Matt: So that supported `getServerSideProps` and things like that. 00:05:59.220 --> 00:06:02.800 Matt: So our initial adoption of Next was using `getServerSideProps` 00:06:02.950 --> 00:06:05.160 Matt: in the pages router for some early pages. 00:06:06.860 --> 00:06:09.220 Matt: We tried to experiment early with server components, 00:06:10.580 --> 00:06:11.900 Matt: what, in 2021, I think. 00:06:13.320 --> 00:06:14.900 Matt: But there were just like a few other blockers. 00:06:14.960 --> 00:06:17.400 Matt: It wasn't like fully baked, didn't really work yet. 00:06:18.480 --> 00:06:21.480 Matt: But we talked to the team, like the Next.js team, 00:06:22.040 --> 00:06:25.060 Matt: and even like talked to some of the React maintainers 00:06:25.200 --> 00:06:27.440 Matt: also about it, and just to get their perspectives 00:06:27.640 --> 00:06:28.400 Matt: on how we build that out. 00:06:29.400 --> 00:06:36.780 Matt: I think it wasn't until 2023 that we started to actually say, 00:06:36.800 --> 00:06:40.760 Matt: okay, server components are viable for us to start adopting, 00:06:40.980 --> 00:06:42.800 Matt: viable for us to adopt in production. 00:06:43.820 --> 00:06:47.000 Matt: And we started to do the migration to the app router, 00:06:47.220 --> 00:06:50.200 Matt: which is like the server component enabled for early pages. 00:06:51.640 --> 00:06:53.760 Scott: So we should talk about how we adopted them, 00:06:53.920 --> 00:06:56.020 Scott: but I want to dig a little bit deeper here 00:06:56.160 --> 00:06:58.700 Scott: because I was under the guise that, 00:07:00.420 --> 00:07:02.060 Scott: or maybe I should talk about this first, 00:07:02.300 --> 00:07:03.520 Scott: but I remember we lost, 00:07:03.880 --> 00:07:06.760 Scott: so we used to flush the header basically inline 00:07:06.780 --> 00:07:13.060 Scott: things so the header would load faster. This is something we lost when we adopted Next12 with 00:07:13.700 --> 00:07:20.300 Scott: what I thought was CSR rendering. And when we were migrating back to Next13, 00:07:21.000 --> 00:07:27.480 Scott: we wanted to get that back with server components and streaming. That was a big push. But also, 00:07:29.000 --> 00:07:36.740 Scott: how did we look at the difference between the speed in which and performance we gained from 00:07:37.520 --> 00:07:42.880 Scott: next 12 to next 13 and and like i guess what were the differences between what we server-side 00:07:43.050 --> 00:07:45.880 Scott: rendered and what we client-side rendered 00:07:43.050 --> 00:07:45.880 Matt: yeah 00:07:45.880 --> 00:07:48.500 Matt: so i guess like and you know maybe first we back up a 00:07:48.550 --> 00:07:52.840 Matt: little bit just for maybe folks that might be unfamiliar with rsc or you know find like that 00:07:53.020 --> 00:07:56.800 Matt: a little bit confusing to balance like csr ssr rsc like how they all interact 00:07:56.800 --> 00:07:57.660 Scott: sure um 00:07:57.660 --> 00:07:59.540 Matt: so yeah so like 00:07:59.840 --> 00:08:04.840 Matt: for the longest time wayfarer had been a like strongly sort of server-side rendered application 00:08:05.000 --> 00:08:08.980 Matt: Like we just like sort of the trade-offs of supporting SSR, 00:08:09.120 --> 00:08:12.120 Matt: like even when we were using PHP and like mustache templates before we 00:08:12.120 --> 00:08:12.320 Matt: adopted 00:08:12.620 --> 00:08:12.680 Matt: React, 00:08:12.840 --> 00:08:15.560 Matt: we were server-side rendering for the performance of it. Right. 00:08:15.720 --> 00:08:19.420 Matt: So like we could deliver a page before client-side JavaScript booted up. 00:08:21.120 --> 00:08:21.880 Matt: You know, we adopted React. 00:08:22.070 --> 00:08:24.980 Matt: We also adopted server-side rendering for React. We adopted Next. 00:08:25.160 --> 00:08:29.340 Matt: We leaned into server-side rendering for Next with like the pages router, 00:08:29.640 --> 00:08:30.080 Matt: like we were saying. 00:08:31.920 --> 00:08:48.540 Matt: One of the things though, before we adopted Next, like one of the things we heavily optimized within our PHP setup at Wayfair was like a rough streaming implementation that would flush down the header, like Scott was saying, it's like the top navigation on the page, and then flush down the rest of the page after. 00:08:48.800 --> 00:08:52.760 Matt: So that way we could like start showing something on the user's browser before the whole page 00:08:52.760 --> 00:08:53.660 Matt: is ready to be shown. 00:08:55.240 --> 00:09:01.700 Matt: We lost that in Next because like in the pages router, there wasn't a way to like say like, 00:09:01.760 --> 00:09:04.680 Matt: hey, like flush this chunk first and then flush the rest of the page later. 00:09:05.200 --> 00:09:09.860 Matt: And that's just like a fundamental sort of limitation of sort of the 00:09:09.860 --> 00:09:11.100 Matt: synchronous, 00:09:11.400 --> 00:09:11.760 Matt: like 00:09:11.760 --> 00:09:13.740 Matt: the synchronous server-side rendering that Next uses. 00:09:15.060 --> 00:09:17.880 Matt: in the sense that you can fetch data asynchronously, 00:09:18.000 --> 00:09:20.440 Matt: but then the actual server rendering, 00:09:20.700 --> 00:09:22.520 Matt: like rendering out the React tree to HTML 00:09:22.980 --> 00:09:25.000 Matt: is a synchronous process at that point. 00:09:26.920 --> 00:09:30.000 Matt: And so, yeah, so that's a feature we launched 00:09:30.120 --> 00:09:31.640 Matt: with that regression on some pages 00:09:33.740 --> 00:09:35.420 Matt: just because we were getting other benefits 00:09:35.560 --> 00:09:36.200 Matt: out of using Next, 00:09:38.140 --> 00:09:40.740 Matt: just in terms of other performance vitals 00:09:40.940 --> 00:09:42.160 Matt: outside of time to first byte. 00:09:43.200 --> 00:09:57.580 Matt: And so like at the, our, our like interest in adopting service server components was primarily for the incremental streaming that we get out of like, or like, you know, that, that react sort of like offered that as a capability with RSC. 00:09:58.040 --> 00:10:01.980 Matt: You could have done incremental streaming before RSC and react, but next JS didn't support it. 00:10:02.540 --> 00:10:04.300 Matt: And so that was kind of like our constraint there. 00:10:05.740 --> 00:10:10.520 Scott: I guess the thing I'm trying to find out is, and you two were there a little longer than me, 00:10:11.120 --> 00:10:18.720 Scott: what are the performance benefits or wins we actually saw from the two differences 00:10:20.700 --> 00:10:24.600 Scott: in migrating from server-side rendered to server-side rendered in that case? 00:10:26.720 --> 00:10:31.520 Matt: Or you mean like migrating from our previous setup to Next or from Next 00:10:31.520 --> 00:10:32.300 Matt: Pages Router to 00:10:32.300 --> 00:10:32.800 Matt: App Router? 00:10:33.440 --> 00:10:44.020 Scott: Well, I guess I'd be interested in both, but pages pages to app would be the more linear, but I, I guess at the same time, all, all irrelevant. 00:10:45.980 --> 00:10:46.180 Matt: Yeah. 00:10:46.820 --> 00:10:46.900 Matt: This 00:10:46.900 --> 00:10:48.660 Matt: feels like basically 00:10:46.900 --> 00:10:48.660 Scott: what did we, what 00:10:48.660 --> 00:10:50.760 Scott: did we get from react server components? 00:10:51.240 --> 00:10:52.580 Scott: Like it was their clear benefit. 00:10:54.840 --> 00:10:54.980 Matt: Yeah. 00:10:55.180 --> 00:11:00.460 Matt: The, the primary benefit, I guess at that point in time was to unlock that streaming rendering, right? 00:11:00.600 --> 00:11:00.940 Matt: Like we can 00:11:00.940 --> 00:11:01.360 Matt: flush the. 00:11:01.370 --> 00:11:01.500 Scott: Correct. 00:11:02.040 --> 00:11:03.040 Matt: We could flush the top half 00:11:03.040 --> 00:11:03.500 Matt: of the page. 00:11:04.200 --> 00:11:05.600 Matt: We could flush the bottom half of the page. 00:11:05.600 --> 00:11:06.360 Matt: We could flush the footer. 00:11:06.800 --> 00:11:09.560 Matt: So we can do this sort of chunk up the page. 00:11:11.960 --> 00:11:16.060 Matt: And primarily it's because we had more maybe heavier features, 00:11:16.460 --> 00:11:17.380 Matt: if you can call it like that, 00:11:17.420 --> 00:11:19.000 Matt: like the features that depend on more data 00:11:19.260 --> 00:11:21.380 Matt: or hit a service that's a little bit more difficult 00:11:21.580 --> 00:11:26.260 Matt: to compute the data that you need deeper down on the page. 00:11:26.560 --> 00:11:29.360 Matt: So it's relatively easy to flush some of the stuff of the header 00:11:29.700 --> 00:11:31.440 Matt: just because we've heavily optimized that over the years. 00:11:31.660 --> 00:11:33.680 Matt: But the features in the page itself 00:11:33.890 --> 00:11:36.420 Matt: are usually a little bit more difficult to collect the data 00:11:36.540 --> 00:11:38.860 Matt: for and render, just because they're more complex. 00:11:39.800 --> 00:11:42.480 Matt: And so the incremental streaming gives us the ability 00:11:42.680 --> 00:11:47.740 Matt: to break that work out, do it later in the request cycle. 00:11:51.120 --> 00:11:53.760 Matt: Yeah, when we were there, when we moved to Next, 00:11:53.870 --> 00:11:56.340 Matt: our time to First Byte, that performance vital, the web 00:11:56.440 --> 00:11:58.860 Matt: vital, is the thing that took the most hit when we first 00:11:58.990 --> 00:12:01.040 Matt: went to the Pages Router because we didn't do that streaming. 00:12:01.540 --> 00:12:02.580 Matt: Right, our time to first byte 00:12:02.580 --> 00:12:03.080 Matt: was waiting 00:12:03.080 --> 00:12:06.860 Matt: until the entire page was ready to flush before we get that first byte. 00:12:07.720 --> 00:12:18.720 Matt: When we adopted AppRouter, that time to first byte went, like, sort of right down to the ground, like, you know, pretty instant in terms of, like, being able to flush the header and then, like, get the first byte there, basically, as soon as possible. 00:12:20.720 --> 00:12:26.720 Dillon: I feel like we're getting, like, super far into the history of Wayfair's journey into, like, server components. 00:12:27.220 --> 00:12:31.040 Dillon: And I feel like, Matt, your understanding of this is, like, advanced. 00:12:31.740 --> 00:12:32.480 Dillon: in a way. 00:12:33.480 --> 00:12:35.440 Dillon: You know more about this than the average developer. 00:12:36.520 --> 00:12:36.800 Dillon: So I'm 00:12:37.660 --> 00:12:39.360 Dillon: kind of hoping maybe we can step 00:12:39.420 --> 00:12:40.160 Dillon: back a little bit 00:12:41.340 --> 00:12:43.420 Dillon: and talk about this 00:12:43.600 --> 00:12:45.080 Dillon: from the standpoint of what is a 00:12:45.500 --> 00:12:47.060 Dillon: typical developer's understanding of Next.js 00:12:47.760 --> 00:12:49.380 Dillon: and how are they using RSCs 00:12:50.520 --> 00:12:51.120 Dillon: and also 00:12:51.900 --> 00:12:53.060 Dillon: kind of get Matt's take on 00:12:53.460 --> 00:12:55.600 Dillon: what's the fundamental understanding people should have 00:12:55.780 --> 00:12:57.280 Dillon: before they start implementing them 00:12:57.320 --> 00:12:57.920 Dillon: into their apps. 00:12:59.080 --> 00:13:01.100 Dillon: I don't want to completely derail you 00:13:01.640 --> 00:13:03.360 Dillon: from your history lesson, but 00:13:03.920 --> 00:13:05.400 Dillon: I feel like some of what you're saying 00:13:05.470 --> 00:13:07.060 Dillon: is going over my head, so I want to like 00:13:07.340 --> 00:13:09.320 Dillon: I'm afraid that people listening are probably 00:13:09.440 --> 00:13:10.080 Dillon: feeling the same way. 00:13:11.260 --> 00:13:13.020 Matt: It's also, it also, like it's 00:13:13.660 --> 00:13:15.240 Matt: what I've been talking about is basically 00:13:15.550 --> 00:13:17.100 Matt: only interesting or valuable to 00:13:17.350 --> 00:13:19.560 Matt: like three or four listeners that still work at Wayfair. 00:13:21.100 --> 00:13:21.240 Dillon: Alright, 00:13:21.370 --> 00:13:23.040 Dillon: keep talking about it. Those are all 00:13:23.400 --> 00:13:24.120 Dillon: only listeners anyways. 00:13:26.360 --> 00:13:27.180 Scott: Well, what I really wanted 00:13:27.520 --> 00:13:27.980 Scott: to try 00:13:27.980 --> 00:13:29.660 Scott: to get out of it is like 00:13:31.919 --> 00:13:34.980 Scott: what can you expect to gain from using React Server Components? 00:13:35.140 --> 00:13:37.780 Scott: I did remember, it's funny, I don't know how you remember this. 00:13:38.300 --> 00:13:39.140 Scott: It's been so long. 00:13:40.580 --> 00:13:41.980 Scott: It's obviously been branded in your head. 00:13:42.300 --> 00:13:45.360 Scott: But for me, you brought up the time to first bite. 00:13:45.480 --> 00:13:47.220 Scott: And then I'm like, oh, yeah, it was abysmal. 00:13:47.400 --> 00:13:52.200 Scott: And then I remember our interaction to next paint was abysmal at first as well. 00:13:52.680 --> 00:13:57.440 Scott: So basically, yeah, I wanted to kind of dig deep on that. 00:13:57.600 --> 00:14:03.200 Scott: But I do think it's important, like you're saying, Dillon, we should run through React 00:14:03.320 --> 00:14:04.900 Scott: server components at a high level as well. 00:14:05.920 --> 00:14:09.460 Matt: Yeah, let's talk a little bit more general purpose things, right? 00:14:09.640 --> 00:14:16.760 Matt: Like why, if you have a React app today, maybe using like a vanilla Vite React app that's client 00:14:16.880 --> 00:14:20.740 Matt: side rendered, or maybe you're still using create React app and you're wondering where 00:14:20.800 --> 00:14:25.180 Matt: you go from there, why would you want to consider adopting server components? 00:14:25.620 --> 00:14:28.780 Matt: I think that's an interesting general topic for us to talk about. 00:14:31.000 --> 00:14:37.500 Matt: I think one of the benefits I've seen from it is it lets you sort of... 00:14:37.500 --> 00:14:40.000 Matt: And people might look at this and say, that's a bad idea, 00:14:40.100 --> 00:14:43.860 Matt: but it lets you kind of couple your back end with your front end a little bit more. 00:14:44.899 --> 00:14:48.919 Matt: A lot of teams that are maybe more sort of... 00:14:49.540 --> 00:14:53.460 Matt: I've worked a lot with code bases that are really separate from their back end to their front end. 00:14:54.520 --> 00:14:58.080 Matt: I think RSC's gives you a nice way to say, my front end 00:14:58.220 --> 00:14:58.920 Matt: cares about this data. 00:14:59.540 --> 00:15:01.680 Matt: And it's a lot more tight coupling than-- 00:15:02.680 --> 00:15:04.800 Matt: GraphQL is probably the closest thing to it, 00:15:05.260 --> 00:15:07.320 Matt: in a sense of here's the exact data 00:15:07.440 --> 00:15:09.080 Matt: that this front end component cares about. 00:15:09.720 --> 00:15:11.960 Matt: RSC's let you do that same thing without needing 00:15:12.100 --> 00:15:14.000 Matt: to use GraphQL if you don't want to use GraphQL. 00:15:14.180 --> 00:15:16.840 Matt: You still can use GraphQL with it, but you don't have to. 00:15:17.160 --> 00:15:18.320 Matt: So I think that's a nice benefit, 00:15:18.520 --> 00:15:22.339 Matt: is a better cohesive view of your application 00:15:22.360 --> 00:15:24.840 Matt: and the data dependencies that you have for your components. 00:15:26.540 --> 00:15:27.720 Matt: But I think like we were talking about 00:15:27.860 --> 00:15:29.460 Matt: with like Wayfair's case, 00:15:29.680 --> 00:15:33.880 Matt: it's like there are some additional like performance 00:15:34.100 --> 00:15:37.680 Matt: or like web vital benefits of adopting RSCs, 00:15:37.840 --> 00:15:39.720 Matt: primarily I think from the streaming aspect 00:15:39.940 --> 00:15:44.640 Matt: of like being able to flush incrementally your webpage. 00:15:46.060 --> 00:15:47.160 Scott: - Yeah, those all make sense. 00:15:47.300 --> 00:15:49.000 Scott: I assumed also a big part of it 00:15:49.060 --> 00:15:51.579 Scott: is to try to have like smaller client side bundles 00:15:52.140 --> 00:15:55.680 Scott: with solutions, things like, if I remember correctly, 00:15:55.860 --> 00:15:57.800 Scott: don't we get automatic code splitting 00:15:58.070 --> 00:15:59.160 Scott: from React serving components? 00:16:00.030 --> 00:16:02.160 Scott: And also if we server render HTML 00:16:02.440 --> 00:16:04.580 Scott: that provides like an SEO benefit. 00:16:05.030 --> 00:16:08.620 Scott: Those are the things that I could think of off of hand, but. 00:16:10.080 --> 00:16:12.060 Matt: Yeah, I mean, like the server rendering, 00:16:12.220 --> 00:16:14.100 Matt: it's like technically you can adopt RSCs 00:16:14.190 --> 00:16:16.260 Matt: without server rendering, which is like, 00:16:16.779 --> 00:16:19.480 Matt: I think at this point, it's mostly just a technicality. 00:16:19.480 --> 00:16:21.280 Matt: It's like kind of like a thing that, 00:16:21.580 --> 00:16:25.980 Matt: the React team sort of sells as a concept, but it like very little, very few implementations 00:16:26.760 --> 00:16:30.620 Matt: that I've seen in the wild, like use RSC's without also server rendering. 00:16:32.360 --> 00:16:35.880 Matt: It's just sort of like a, like you already have a server that's doing this stuff, like why not 00:16:36.040 --> 00:16:41.080 Matt: also server renderers basically, at least the way I've internalized the concept. But like, 00:16:41.240 --> 00:16:47.300 Matt: so you don't, so like from that lens, like the benefits of server rendering aren't always like, 00:16:47.320 --> 00:16:51.880 Matt: aren't always the same things as using RSCs, but sometimes they come packaged together, 00:16:52.180 --> 00:16:53.240 Matt: I guess the way to describe it. 00:16:54.080 --> 00:16:57.340 Dillon: Matt, when you say using RSCs without server rendering, 00:16:57.440 --> 00:17:00.800 Dillon: are you saying like using RSCs to get all your data on the server and then 00:17:01.440 --> 00:17:04.939 Dillon: pass it to client components and then do all your rendering on the client with that data? 00:17:05.400 --> 00:17:06.720 Dillon: Is that like kind of what you're getting? 00:17:07.420 --> 00:17:12.100 Matt: Basically, yeah. You client-side render an app 00:17:12.140 --> 00:17:14.780 Matt: and the app fetches from an RSC endpoint. 00:17:15.550 --> 00:17:17.120 Matt: So instead of usually like you would fetch 00:17:17.130 --> 00:17:18.000 Matt: and you would get some JSON, 00:17:18.780 --> 00:17:21.280 Matt: like you actually fetch and you get like a RSC payload, 00:17:21.449 --> 00:17:24.880 Matt: which is like sort of a custom data type, 00:17:25.459 --> 00:17:28.260 Matt: basically that React and then parse 00:17:28.430 --> 00:17:30.060 Matt: and then hydrate some HTML from. 00:17:30.960 --> 00:17:31.200 Dillon: Okay. 00:17:32.000 --> 00:17:33.200 Dillon: So you're not passing the data down 00:17:33.400 --> 00:17:34.440 Dillon: from the component to component. 00:17:34.840 --> 00:17:36.920 Dillon: You're just like, you have your RSC there 00:17:37.010 --> 00:17:40.200 Dillon: as sort of an API endpoint through a server. 00:17:40.400 --> 00:17:40.520 Matt: Yeah. 00:17:41.700 --> 00:18:08.440 Matt: Yeah, I mean, it's you, you, but you don't necessarily in that setup, you wouldn't necessarily sort of use that response and pass it to client components in order to render you sort of like, that response is like, it's almost like you're dumping like HTML into a client component, but not necessarily using it as props for a client component, like you don't get back obviously, like, you know, like with a JSON API, you might fetch something like a like count or something like that and gives you back a number. 00:18:08.900 --> 00:18:12.500 Matt: Whereas with this, it gives you back a sort of a RSC rendered, 00:18:13.180 --> 00:18:15.960 Matt: like a thing that looks like could be translated into HTML 00:18:16.720 --> 00:18:19.100 Matt: of the counter for the likes or whatever. 00:18:21.040 --> 00:18:22.680 Matt: So that's maybe an interesting distinction. 00:18:23.320 --> 00:18:26.920 Matt: I think there's a number of different other benefits from RSCs. 00:18:27.380 --> 00:18:30.780 Matt: But I think an interesting sort of, 00:18:31.100 --> 00:18:32.160 Matt: we're covering some of the benefits, 00:18:32.270 --> 00:18:35.420 Matt: but there's some trade-offs with adopting RSCs, 00:18:35.670 --> 00:18:36.500 Matt: as with every solution. 00:18:38.580 --> 00:18:44.940 Matt: You know, fundamentally, like one of the maybe the big ones for a lot of React developers out there is that you need a server layer, right? 00:18:45.120 --> 00:18:48.500 Matt: Like a lot of React apps today don't use server-side rendering. 00:18:48.670 --> 00:18:50.720 Matt: Like they're, you know, completely client-side rendered. 00:18:51.500 --> 00:18:55.200 Matt: You know, they started with Create React App or Vite or whatnot. 00:18:56.640 --> 00:18:58.220 Matt: And so they didn't need a server for any of that. 00:18:58.540 --> 00:19:06.740 Matt: You know, they obviously have like a CDN or something serving those assets, but no actual like sort of server processing going towards the React app. 00:19:06.820 --> 00:19:08.120 Matt: it's like probably all for the backend. 00:19:08.420 --> 00:19:10.220 Matt: So like you need to adopt something like that, 00:19:10.640 --> 00:19:11.000 Matt: generally speaking. 00:19:11.420 --> 00:19:13.120 Matt: I mean, you can do build time RSC, 00:19:14.800 --> 00:19:17.220 Matt: which is like, you know, your server is your build server. 00:19:19.460 --> 00:19:21.740 Matt: But yeah, you know, you don't necessarily get, 00:19:23.400 --> 00:19:23.520 Matt: you know, 00:19:23.620 --> 00:19:24.600 Matt: in 00:19:24.600 --> 00:19:24.980 Matt: that setup, 00:19:25.040 --> 00:19:26.520 Matt: you probably, you don't really get service-side rendering. 00:19:26.600 --> 00:19:29.680 Matt: You get sort of like, what, you know, 00:19:29.760 --> 00:19:33.820 Matt: a static site generation sort of approach with RSCs. 00:19:34.320 --> 00:19:35.720 Scott: - So we talked a lot about, 00:19:36.380 --> 00:19:39.500 Scott: starting anew with React Server components. 00:19:41.580 --> 00:19:43.840 Scott: Something I wanted to facilitate early was, 00:19:45.810 --> 00:19:48.680 Scott: can we talk about adopting it in a code base that already exists? 00:19:49.180 --> 00:19:52.720 Scott: And I guess this is more of an interview for Matt. 00:19:54.159 --> 00:19:56.460 Scott: What are your thoughts on some of that? 00:19:57.740 --> 00:19:59.520 Scott: What's an approach for something like that, 00:19:59.740 --> 00:20:03.480 Scott: especially maybe, you know, monorepo architecture, 00:20:04.500 --> 00:20:08.480 Scott: architecture, I guess, multiple mono repos, poly repos, whatever you want to say here. 00:20:09.300 --> 00:20:16.640 Scott: How would you go about taking an application that's already server side rendered and with 00:20:16.840 --> 00:20:21.480 Scott: maybe some internal solutions, maybe some open source solutions and migrate it towards 00:20:21.490 --> 00:20:22.920 Scott: a React server component architecture? 00:20:24.559 --> 00:20:29.520 Matt: Yeah, I think that's probably one of the bigger questions around RSC these days is like, how 00:20:29.520 --> 00:20:30.380 Matt: do you adopt it? 00:20:31.140 --> 00:20:34.380 Matt: You know, very early on, the story of adoption for React 00:20:34.860 --> 00:20:37.280 Matt: was that you can do it from the leaf nodes up, right? 00:20:37.420 --> 00:20:39.280 Matt: I remember watching a lot of talks about it, 00:20:39.440 --> 00:20:45.160 Matt: saying you can replace your backbone-powered application 00:20:45.860 --> 00:20:47.220 Matt: with React incrementally, 00:20:47.960 --> 00:20:49.320 Matt: sort of like working your way up the tree. 00:20:50.940 --> 00:20:54.880 Matt: I think one of the things that you can't easily do with RSCs 00:20:54.900 --> 00:20:56.140 Matt: is you can't really do that. 00:20:57.800 --> 00:20:58.660 Matt: Technically, you could do it, 00:20:58.740 --> 00:21:01.100 Matt: but generally the thinking is that 00:21:01.640 --> 00:21:04.660 Matt: RSCs sort of want you to flip the mental model of how you adopt React. 00:21:05.020 --> 00:21:07.140 Matt: You start from the server and you work towards the client, 00:21:07.710 --> 00:21:10.980 Matt: whereas normally it's like a client up to the server sort of approach. 00:21:12.900 --> 00:21:15.320 Matt: You can kind of see this obviously in Next implementation, 00:21:15.740 --> 00:21:19.240 Matt: where it's like every page starts as a server component 00:21:19.340 --> 00:21:22.040 Matt: and you have to opt into it being a client component with use client. 00:21:24.480 --> 00:21:29.640 Matt: So I think that's an interesting pain point with an existing app 00:21:29.660 --> 00:21:34.640 Matt: migrating to RFC is that you can't easily swap out a small little subsection of your page with 00:21:34.640 --> 00:21:39.320 Matt: an RFC, right? Like you, you sort of need to start at the top and work your way down. Um, 00:21:40.500 --> 00:21:43.620 Matt: I think, you know, if you already have server-side rendering setup, then you're kind of in a good 00:21:43.800 --> 00:21:48.120 Matt: spot because you already have a server. So you have some infrastructure to start building off of. 00:21:48.460 --> 00:21:53.020 Matt: If you don't have that setup, then it's like maybe a little bit more difficult to start moving to it. 00:21:53.640 --> 00:22:00.880 Matt: Um, and another sort of pain point for legacy apps migrating to it is like, does their bundler 00:22:01.060 --> 00:22:02.080 Matt: support RSC? 00:22:02.500 --> 00:22:05.600 Matt: Like RSC is not necessarily a thing you can do without a bundler. 00:22:06.500 --> 00:22:09.500 Matt: So that's like a, another sort of complex pain point, right? 00:22:09.540 --> 00:22:13.680 Matt: If you're using a custom bundler, um, you're going to have to spend quite a bit of time 00:22:14.080 --> 00:22:15.860 Matt: building out your own RSC integration for it. 00:22:16.760 --> 00:22:24.600 Matt: Um, you know, uh, Webpack supports RSC's, um, uh, Vite loosely supports, you can kind of 00:22:24.610 --> 00:22:26.440 Matt: like hack it into Vite apps. 00:22:27.020 --> 00:22:28.660 Matt: Um, Parcel now supports it. 00:22:29.220 --> 00:22:34.000 Matt: Um, but, uh, you know, outside of, you know, Parcel and Webpack, basically there's not 00:22:34.120 --> 00:22:38.480 Matt: really a bespoke, like a sort of solution for the rest of the bundlers out there. 00:22:39.300 --> 00:22:44.400 Matt: Um, so I think that's like more, maybe sort of like the, some of the initial pain points 00:22:44.480 --> 00:22:49.860 Matt: in terms of like how would you like like what blocks the legacy app from adopting it um you 00:22:49.860 --> 00:22:53.560 Matt: know maybe we talk a little bit about strategies of how we get how like how do you actually do that 00:22:53.700 --> 00:22:57.720 Matt: let's assume that you're using a bundler that supports it already let's assume you have some 00:22:58.120 --> 00:23:03.840 Matt: infrastructure for doing it during builds or or from like server-side rendering um you know my 00:23:03.940 --> 00:23:08.560 Matt: recommended strategy is like start page by page right like that's the because that's the sort of 00:23:08.700 --> 00:23:14.380 Matt: the easiest place you can insert it right you start at an entry point um and you go page by page 00:23:14.400 --> 00:23:15.140 Matt: to adopt it 00:23:15.140 --> 00:23:15.340 Matt: which 00:23:15.340 --> 00:23:15.660 Matt: is the same 00:23:15.660 --> 00:23:18.100 Matt: way approach we took at wayfarer right like we took a single page we 00:23:18.340 --> 00:23:25.200 Matt: migrated it and then we took another page we migrated it etc um so i don't know that's i i 00:23:25.330 --> 00:23:27.440 Matt: feel like i've been talking quite a bit about it but uh 00:23:27.440 --> 00:23:31.440 Matt: yeah 00:23:27.440 --> 00:23:31.440 Dillon: one thing i'm gonna call out is one 00:23:31.440 --> 00:23:37.900 Dillon: thing i've seen when people start to adopt it and i i'm kind of i've seen myself do this is you sort 00:23:37.840 --> 00:23:44.640 Dillon: of adopted at the top level in a single component per page and then we we kind of like get stuck 00:23:44.770 --> 00:23:48.920 Dillon: there we don't like really know how to integrate server components at different levels in the tree 00:23:49.640 --> 00:23:55.240 Dillon: i guess what's your recommendation to sort of better get our mind like set our mindset correctly 00:23:55.500 --> 00:23:56.920 Dillon: so we can start to do that that's 00:23:56.920 --> 00:23:59.540 Scott: a that's a really good point so i want to bring up at wayfair 00:24:00.050 --> 00:24:04.299 Scott: uh the three of us kind of were like all right we'll have some server components at the top 00:24:05.000 --> 00:24:11.860 Scott: um there'll be some client components that are our state providers within that tree uh but we told 00:24:12.040 --> 00:24:17.820 Scott: like all of our feature consuming teams you just got this one big uh i think it was the page.tsx 00:24:17.840 --> 00:24:22.560 Scott: you probably remember this matt but we're like you own this or we created like a page.client.tsx 00:24:22.660 --> 00:24:27.460 Scott: something like that and like you own this it's just one big client component uh however at 00:24:27.700 --> 00:24:34.920 Scott: fireworks i think we kind of were able to just work out when it should be a client component versus 00:24:34.980 --> 00:24:41.420 Scott: a server component and it was mostly just driven by state uh let's have the state and maybe this 00:24:41.540 --> 00:24:47.260 Scott: sounds obvious or clear but like components that can be the state can be as close to the component 00:24:47.260 --> 00:24:53.180 Scott: it needs to be in so that like client components can be drilled down as far as possible and 00:24:53.440 --> 00:24:57.880 Scott: essentially that was kind of the pattern we used and we we migrated more towards server actions 00:24:58.200 --> 00:25:03.960 Scott: for form solutions and whatnot so that we made sure that we were like using as much server benefit 00:25:03.980 --> 00:25:05.440 Scott: as we could at fireworks. 00:25:05.800 --> 00:25:07.620 Scott: And I just want to also add, 00:25:08.340 --> 00:25:10.800 Scott: Matt definitely understands this stuff the best. 00:25:10.810 --> 00:25:13.380 Scott: He helped really blueprint how we built this 00:25:13.890 --> 00:25:15.580 Scott: in a large space. 00:25:16.620 --> 00:25:18.540 Scott: I feel like with using Next.js, 00:25:18.940 --> 00:25:21.020 Scott: a lot of this has just been kind of handed to me 00:25:21.260 --> 00:25:22.260 Scott: and spoon-fed, 00:25:22.710 --> 00:25:26.240 Scott: but I've also felt that there was never really 00:25:26.420 --> 00:25:27.440 Scott: like a clear paved path. 00:25:27.440 --> 00:25:29.540 Scott: I feel like they're building towards that now. 00:25:30.880 --> 00:25:32.280 Scott: Like Next will kind of say like, 00:25:32.460 --> 00:25:33.440 Scott: this is how you do a thing. 00:25:33.640 --> 00:25:34.560 Scott: This is how you do that thing. 00:25:35.720 --> 00:25:38.660 Scott: React has been very hands-off in the sense they've been like, 00:25:39.020 --> 00:25:41.600 Scott: you kind of figure out the implementation you want, 00:25:42.120 --> 00:25:46.720 Scott: which I guess I understand from a perspective of they want to allow you to 00:25:47.080 --> 00:25:50.660 Scott: own that part and the patterns for what you do. 00:25:51.340 --> 00:25:57.880 Scott: However, I guess I've been isolated more in the next Vercel ecosystem 00:25:58.560 --> 00:26:01.140 Scott: where they're kind of like, this is the pattern, use this pattern. 00:26:01.260 --> 00:26:03.340 Scott: So it's been easier for me to apply those principles. 00:26:04.180 --> 00:26:09.760 Scott: whereas when you're doing this for the first time and it's brand new back in 2023 i know you said 00:26:10.270 --> 00:26:14.920 Scott: react server components had been around but them being introduced as like the main part of a 00:26:15.080 --> 00:26:21.860 Scott: framework it was very new when we were starting to do it um it was very much figure it out and 00:26:22.240 --> 00:26:30.520 Scott: the only real complication we ran into was uh Luke Reisch realized that we had we had followed the 00:26:30.500 --> 00:26:37.220 Scott: GraphQL suggested pattern of attaching fragments to components as statics. And some of those 00:26:37.500 --> 00:26:42.940 Scott: components, if I remember correctly, were client rendered components, and that would break the 00:26:43.070 --> 00:26:48.600 Scott: bundle because they needed to be rendered server side. So we hijacked the typegen plugin we were 00:26:48.650 --> 00:26:54.020 Scott: using. We also had a ton of packages in our monorepo, which may have been different than how 00:26:54.040 --> 00:26:55.740 Scott: other people were building their fragments. 00:26:57.520 --> 00:27:01.140 Scott: Regardless, it caused us to have to generate files 00:27:01.300 --> 00:27:02.160 Scott: for them to come out of 00:27:02.580 --> 00:27:05.360 Scott: and basically making sure we didn't have server client 00:27:05.840 --> 00:27:06.720 Scott: mismatches like that. 00:27:07.200 --> 00:27:11.180 Scott: So my background is more so coming from a framework 00:27:11.380 --> 00:27:12.960 Scott: where I was a little bit more protected from that. 00:27:13.680 --> 00:27:16.260 Scott: But yeah, Matt, sorry, I derailed kind of 00:27:16.380 --> 00:27:17.340 Scott: where we were going with this, 00:27:17.540 --> 00:27:19.180 Scott: but to Dillon's question, 00:27:19.730 --> 00:27:21.400 Scott: whatever that might've been, go for it. 00:27:22.760 --> 00:27:30.040 Matt: Yeah, like one of the fundamental things with React Server Components is like you basically need to think about two environments when you're writing your application, right? 00:27:30.050 --> 00:27:33.460 Matt: You have a server environment, which is like server components or server functions. 00:27:33.770 --> 00:27:35.680 Matt: And then you have a client environment, like client components. 00:27:37.360 --> 00:27:39.300 Matt: And you can have client actions and things like that. 00:27:39.610 --> 00:27:41.560 Matt: But that's just like regular React, right? 00:27:41.570 --> 00:27:44.540 Matt: The client side of the React Server Component 00:27:44.540 --> 00:27:45.820 Matt: split is 00:27:45.820 --> 00:27:50.000 Matt: like basically your React app today if you aren't using RSCs, right? 00:27:50.120 --> 00:27:57.280 Matt: And so that fundamental split is the conceptual model that a lot of people are new to with React Server components. 00:27:57.380 --> 00:28:01.460 Matt: And so it takes a while to figure out how do you use these two environments? 00:28:01.640 --> 00:28:03.640 Matt: How do you properly stitch an app together? 00:28:04.680 --> 00:28:13.080 Dillon: I feel like something worth calling out that Matt's sort of getting into is Next.js is being given to all these front-end engineers 00:28:13.320 --> 00:28:15.500 Dillon: who are used to just working in a client-side environment. 00:28:15.680 --> 00:28:18.020 Dillon: And then all of a sudden, they have all these controls to work on the server. 00:28:18.880 --> 00:28:24.460 Dillon: And they don't really have the experience with server, like back-end development. 00:28:24.780 --> 00:28:25.840 Dillon: It's basically that's what you're doing. 00:28:26.840 --> 00:28:32.080 Dillon: And so there's a lot of new considerations in terms of security as like the primary thing. 00:28:32.170 --> 00:28:40.820 Dillon: But there's other things too where you need to like just think about like, is this going to be shared across different instances on the server? 00:28:40.870 --> 00:28:46.880 Dillon: And you can cause like caching issues where you're sharing data across different customers, which can be really, really bad. 00:28:47.620 --> 00:28:56.580 Dillon: And I don't think most engineers that are front end really consider that when they get thrown into the Next.js framework and they start working in server components are like, oh, what the hell is going on here? 00:28:57.160 --> 00:28:57.260 Scott: Yeah. 00:28:57.260 --> 00:28:58.180 Dillon: They can really start to 00:28:58.180 --> 00:28:58.960 Dillon: shoot themselves in the foot. 00:28:59.840 --> 00:29:00.000 Scott: Yeah. 00:29:00.280 --> 00:29:01.560 Scott: I think you're nailing that. 00:29:01.760 --> 00:29:09.300 Scott: Like you and Matt kind of called about this is like you called out the this is like the marriage of front end and back end and where we blur the lines. 00:29:09.680 --> 00:29:09.740 Matt: Yeah. 00:29:11.520 --> 00:29:16.420 Scott: But I also felt like deciding when we use a client component, sorry, just a quick point, 00:29:17.400 --> 00:29:19.660 Scott: reminded me of how do we use hooks in React? 00:29:19.840 --> 00:29:24.480 Scott: I remember we had been like, oh, we don't want people to just use hooks everywhere, 00:29:24.600 --> 00:29:29.540 Scott: which ironically, maybe I don't remember correctly, but I didn't feel like hooks were crazy at Wayfair. 00:29:29.620 --> 00:29:32.100 Scott: I've seen client-side apps with crazy hooks. 00:29:33.860 --> 00:29:40.180 Scott: But you kind of naturally develop where you think it's best. 00:29:40.280 --> 00:29:44.700 Scott: Like what, what do I want to server render versus what I want to client render and like 00:29:45.000 --> 00:29:48.820 Scott: creating this large level paradigm, there might be some like basic building blocks to 00:29:48.940 --> 00:29:55.480 Scott: it, but less so that, um, you need to have like defining guidelines around that. 00:29:55.820 --> 00:30:00.180 Matt: I think it's also worth like noting, like, yeah, I think we got to be careful with our 00:30:00.400 --> 00:30:01.000 Matt: terminology also. 00:30:01.260 --> 00:30:07.419 Matt: Like the, it's not the two, that two concept thing of like server and client isn't, isn't 00:30:07.440 --> 00:30:13.620 Matt: necessarily meaning server rendered versus client rendered, right? You can have a server rendered 00:30:14.060 --> 00:30:18.460 Matt: client component, which again, like this like adds to the general confusion that a lot of people have 00:30:18.540 --> 00:30:21.580 Matt: with RSC. So it's like, you know, I don't know if I'm doing justice in terms of like trying to 00:30:21.780 --> 00:30:27.480 Matt: explain it because it's like, it could be confusing. But like you have like, just because you choose a 00:30:27.560 --> 00:30:31.700 Matt: client component doesn't mean you're de-opting to client side rendered only, right? So I just, 00:30:31.810 --> 00:30:37.400 Matt: I just wanted to like make sure that's clear for listeners because it can be confusing, right? It 00:30:37.420 --> 00:30:53.360 Matt: We call this a client component, but it's more of like a presentational component versus a container component for those that have remembered Redux from decades past, where you have a container component that wraps presentational components. 00:30:53.400 --> 00:30:58.960 Matt: The container component handles data fetching or state management, and your presentational component just presents it. 00:30:59.480 --> 00:31:06.700 Matt: So it's very much that same mental model, if you're familiar with it, where your container components are server components and your presentational components are client components. 00:31:07.520 --> 00:31:11.960 Dillon: one thing you said is this is kind of confusing it can get confusing and i feel like a lot of 00:31:12.060 --> 00:31:15.720 Dillon: people when they're thrown into these that's into next js and they're thrown they're given all these 00:31:15.720 --> 00:31:21.800 Dillon: new features they're just confused and they're misusing them so i i want to kind of like ask you 00:31:22.740 --> 00:31:30.160 Dillon: what can people do to to like slow down the firehouse and step back and like take some time 00:31:30.260 --> 00:31:33.820 Dillon: to get some better understanding before they start using these tools yeah 00:31:33.820 --> 00:31:36.040 Matt: something we're messaging 00:31:36.060 --> 00:31:42.320 Matt: on the side about this is like the blog post or like the talk by Dan Abramov called React for 00:31:42.320 --> 00:31:47.640 Matt: Two Computers. I think that's a really good like from first principles sort of understanding of 00:31:47.920 --> 00:31:52.840 Matt: the mental model of these like two environments right like it sort of talks about it from like 00:31:52.900 --> 00:31:58.780 Matt: building up from very basic concepts up to you have the server and client environment. So that's 00:31:58.780 --> 00:32:06.020 Matt: like a good like sort of fundamental starting point. I think it's also interesting to look at it 00:32:06.580 --> 00:32:11.400 Matt: you know obviously Next.js is sort of like the de facto industry leader in RSC right now 00:32:11.980 --> 00:32:19.380 Matt: for better or worse sometimes it can be useful to look at alternative RSC frameworks just to 00:32:19.480 --> 00:32:25.980 Matt: understand that like you know what you use with Next isn't isn't the React version of RSC it's 00:32:25.980 --> 00:32:30.980 Matt: the next it's like the Vercel or the Next.js version of RSC right like it's not necessarily 00:32:31.000 --> 00:32:38.020 Matt: that RSC, the implementation or the, you know, the standards, if you will, of RSC change. It's more 00:32:38.020 --> 00:32:43.300 Matt: so just like, how do you, how is it leveraged within your framework of choice, right? So like 00:32:43.700 --> 00:32:49.500 Matt: parcels implementation is a lot more basic, you know, and you can say, you know, not necessarily 00:32:49.650 --> 00:32:54.960 Matt: basic in terms of like doesn't provide or like doesn't support the same complexity as Next, 00:32:55.500 --> 00:32:59.540 Matt: but it's more so it like gives you the control over a lot of the same stuff that Next doesn't. 00:33:00.160 --> 00:33:03.520 Matt: So Parcels implementation, you need to provide your own server and handle the requests. 00:33:04.380 --> 00:33:05.660 Matt: You can adopt Express or 00:33:05.660 --> 00:33:05.900 Matt: Hona 00:33:05.900 --> 00:33:06.060 Matt: or 00:33:06.060 --> 00:33:08.940 Matt: whatever your favorite server routing framework is, 00:33:09.680 --> 00:33:18.520 Matt: and then hook into Parcels implementation in order to server render or render the RSC side of things or handle actions or whatnot. 00:33:18.840 --> 00:33:20.240 Matt: Whereas Next, that's all a black box. 00:33:20.980 --> 00:33:22.240 Matt: Next handles that for you. 00:33:23.920 --> 00:33:25.500 Matt: And so, yeah, I think those two things. 00:33:26.820 --> 00:33:29.660 Matt: That blog post or that talk by Dan Abramov is a great starting point. 00:33:29.860 --> 00:33:39.100 Matt: And then also like starting to look at, try to look at some of the other framework implementations just to understand that like, you know, there's things that are next features and there's things that are RSC features. 00:33:40.040 --> 00:33:41.620 Matt: And that's like always good to break down. 00:33:42.200 --> 00:33:42.820 Scott: I have a question. 00:33:43.040 --> 00:33:54.900 Scott: So if I remember correctly with both server components are rendered on the server, client components are pre-rendered on the server and then hydrated on the client. 00:33:55.580 --> 00:34:00.340 Scott: Is that a full-on RSC concept, or is that just how they were working within Next? 00:34:00.420 --> 00:34:04.580 Matt: Well, server components don't really get server rendered in the same way that a client component 00:34:04.580 --> 00:34:05.200 Matt: gets server rendered. 00:34:05.700 --> 00:34:16.679 Matt: Again, we're digging into nuance here, but Next.js generally follows the setup of server-side 00:34:16.860 --> 00:34:17.480 Matt: rendering everything. 00:34:18.100 --> 00:34:23.159 Matt: You can opt in through client-side render, but you can't do a client-side rendered React 00:34:23.220 --> 00:34:24.820 Matt: server component, if that makes sense. 00:34:25.280 --> 00:34:26.980 Matt: in next right 00:34:26.980 --> 00:34:30.360 Scott: because it's server rendered first unlike tan stack which is like the opposite it's 00:34:30.460 --> 00:34:35.240 Scott: client side first so you'd have to opt in it's server it's clients right yeah but 00:34:35.240 --> 00:34:35.919 Matt: you can't with 00:34:36.020 --> 00:34:43.300 Matt: next you can't like um you can't expose and at least not out of the box you can't expose like 00:34:43.300 --> 00:34:46.620 Matt: a server component like an api endpoint like we were talking about earlier where it's like you 00:34:46.700 --> 00:34:52.640 Matt: could technically have a client like client react app that fetches a server component and then 00:34:53.000 --> 00:34:53.460 Matt: renders it. 00:34:54.860 --> 00:34:57.460 Matt: Next doesn't really give you a native solution for that. 00:34:57.920 --> 00:34:59.800 Matt: They sort of force you-- if you're using RSC's, 00:34:59.940 --> 00:35:01.620 Matt: you're in a server-side renderer. 00:35:03.140 --> 00:35:05.000 Matt: Or you could immediately opt out. 00:35:05.160 --> 00:35:07.800 Matt: But basically, you can't really fetch from a client-side rendered 00:35:07.840 --> 00:35:12.200 Matt: app a server component in Next without some hacky solution. 00:35:16.040 --> 00:35:17.100 Matt: We've been talking a lot about Next. 00:35:17.300 --> 00:35:18.620 Matt: I just brought up Parcel. 00:35:18.640 --> 00:35:22.620 Matt: But yeah, Next and Parcel are not the only two 00:35:22.640 --> 00:35:26.700 Matt: use server components. There's like a number of different like sort of esoteric options out there 00:35:26.900 --> 00:35:32.520 Matt: but I think like in my mind like the top four right now are you know next obviously but then 00:35:33.120 --> 00:35:38.500 Matt: parcels implementation is like kind of the next after webpack the next sort of stable implementation 00:35:39.600 --> 00:35:44.500 Matt: for server components like they have a an integration within the react repo and it's like 00:35:44.500 --> 00:35:49.740 Matt: sort of you know for lack of better terms like blessed by the react team but then outside of 00:35:49.740 --> 00:35:54.380 Matt: those two, the next two that I would sort of like look at or recommend if people are interested 00:35:54.600 --> 00:35:59.200 Matt: is Waku, which we've talked about in the past a little bit, which is like a Vite-based server 00:35:59.340 --> 00:36:03.880 Matt: component framework. It's a little bit more baked than Parcel. Like it sort of comes with a default 00:36:04.060 --> 00:36:09.160 Matt: router and, you know, handles the server-side route, like sort of route matching for you. 00:36:10.740 --> 00:36:16.220 Matt: Where versus Parcel, you sort of need to do that by yourself. And then after those three is, 00:36:16.640 --> 00:36:19.880 Matt: and it's still pretty new, so it's not stable as much, 00:36:19.940 --> 00:36:23.620 Matt: is Redwood SDK, which is another Vite-based solution. 00:36:26.860 --> 00:36:28.700 Matt: And yeah, again, it's pretty fresh. 00:36:28.940 --> 00:36:30.500 Matt: I've only used it once or twice, 00:36:30.620 --> 00:36:32.360 Matt: so I don't have as much context about it. 00:36:32.760 --> 00:36:35.260 Matt: But those four are the places that I would recommend 00:36:35.480 --> 00:36:38.440 Matt: starting with if you're starting with a fresh app. 00:36:39.700 --> 00:36:41.740 Matt: If we talk about the legacy app migration, 00:36:41.920 --> 00:36:44.380 Matt: it becomes a little bit more nuanced in terms of what's 00:36:44.400 --> 00:36:48.240 Matt: your current bundler situation if you have one what's your current server situation if you have 00:36:48.340 --> 00:36:50.320 Matt: one and like what fits best there 00:36:50.320 --> 00:36:55.840 Dillon: so matt if i'm working in an Next.js app do you still recommend 00:36:56.650 --> 00:37:00.460 Dillon: that i go and spend some time learning about these other frameworks to get some better context around 00:37:00.530 --> 00:37:02.440 Dillon: the topic is that what you're saying 00:37:02.440 --> 00:37:06.460 Matt: i mean i i recommend it no matter what like even if you're 00:37:06.560 --> 00:37:10.200 Matt: not using next it's like i think it's always interesting just explore with what what options 00:37:10.360 --> 00:37:13.180 Matt: are out there right but that's just like the way i sort of operate you know i think 00:37:14.460 --> 00:37:18.060 Matt: it could be useful. Obviously, if you're using Next, you probably want to just keep leaning 00:37:18.340 --> 00:37:27.820 Matt: into Next features. I wouldn't recommend that people go out there and just decide to rewrite 00:37:27.920 --> 00:37:33.580 Matt: their app from Next to something else just on the whim. You could look at those other options and 00:37:33.580 --> 00:37:39.460 Matt: say, actually, these are providing better trade-offs for us. But I wouldn't recommend that everyone go 00:37:39.480 --> 00:37:43.480 Matt: out there and rewrite their app from next to Redwood SDK or Parcel, for example. 00:37:45.380 --> 00:37:46.280 Matt: There's trade-offs, obviously. 00:37:46.950 --> 00:37:47.420 Matt: It depends. 00:37:47.620 --> 00:37:48.360 Matt: That's Scott's favorite saying. 00:37:49.260 --> 00:37:55.320 Scott: So, yeah, I wanted to bring up one other thing we did do is, so we knew the bundler situation. 00:37:56.760 --> 00:38:00.700 Scott: You basically prepped all of Wayfair for RSC. 00:38:01.480 --> 00:38:04.720 Scott: It's fair to say this was kind of your blueprint and plan. 00:38:06.820 --> 00:38:14.120 Scott: So we had a monorepo for the design system, essentially. 00:38:14.190 --> 00:38:19.260 Scott: You delegated to those folks that we needed to get a runtime solution for styles. 00:38:19.770 --> 00:38:22.700 Scott: We needed to mark the right components, use client. 00:38:25.200 --> 00:38:27.720 Scott: How did you do that for the existing monorepo? 00:38:28.710 --> 00:38:31.400 Scott: Did you do that yourself or did you actually tell teams? 00:38:31.840 --> 00:38:39.480 Scott: Or was it that we set up basically a template as a team and you just set the parts to it as used client? 00:38:39.590 --> 00:38:43.340 Scott: How did you build out a template that was successful in a large scale monorepo? 00:38:43.680 --> 00:38:44.900 Matt: That's a good question. 00:38:46.120 --> 00:38:56.980 Matt: We talked a little bit about the two different conceptual domains you need to think about with RSC, like server and client side, or client components, not client side. 00:38:58.400 --> 00:38:58.700 Matt: But it is, 00:38:58.880 --> 00:39:00.100 Matt: RSC, 00:39:00.160 --> 00:39:01.360 Matt: because it sort of demands 00:39:01.580 --> 00:39:03.620 Matt: that you sort of start at your root and you're working way down, 00:39:03.740 --> 00:39:05.580 Matt: you do need-- if you are working with a legacy app 00:39:05.700 --> 00:39:07.080 Matt: or an existing code base, you need 00:39:07.180 --> 00:39:10.040 Matt: to think about how to migrate that over and make it compatible. 00:39:10.440 --> 00:39:12.300 Matt: Like, Scott, you were touching on this with the GraphQL setup. 00:39:15.519 --> 00:39:20.140 Matt: And yeah, our code base wasn't ready to just jump right 00:39:20.220 --> 00:39:21.040 Matt: into server components. 00:39:21.980 --> 00:39:23.020 Matt: We had to do a decent amount of work. 00:39:24.220 --> 00:39:25.680 Matt: Some of the patterns that we did is like, yeah, 00:39:25.740 --> 00:39:27.380 Matt: so the way we started at Wayfair was basically, 00:39:29.079 --> 00:39:31.760 Matt: what I call the naive server component adoption strategy, 00:39:32.100 --> 00:39:35.120 Matt: where we have basically two server components per page. 00:39:35.740 --> 00:39:38.240 Matt: One is the header, which fetches data for the header. 00:39:38.350 --> 00:39:39.500 Matt: And it has a, like, there's a header, 00:39:39.930 --> 00:39:41.620 Matt: you know, presentational component or client component 00:39:42.250 --> 00:39:43.400 Matt: that renders that header. 00:39:44.000 --> 00:39:46.060 Matt: And then we did the same thing for the rest of the page, right? 00:39:46.060 --> 00:39:48.440 Matt: We had a page server component with page.tsx and next. 00:39:49.260 --> 00:39:50.080 Matt: And then we had a client, 00:39:50.250 --> 00:39:52.140 Matt: like a sort of a sidecar client component 00:39:52.620 --> 00:39:55.140 Matt: that did all the rendering for the rest of the page, right? 00:39:55.300 --> 00:39:59.800 Matt: So very naive, just sort of two RSC component strategy, sort of. 00:40:01.260 --> 00:40:04.000 Matt: And so that limited the blast radius of the impact, right? 00:40:04.120 --> 00:40:07.600 Matt: Like we didn't need to worry about some deep leaf component 00:40:09.000 --> 00:40:11.920 Matt: adding use client to it because it uses a client API like use 00:40:12.060 --> 00:40:13.640 Matt: state, for example, because we already 00:40:13.820 --> 00:40:15.100 Matt: sort of accounted for that at the root. 00:40:16.640 --> 00:40:18.500 Matt: But yeah, as you were saying, before this, 00:40:20.000 --> 00:40:22.900 Matt: we had kind of loosely started to adopt styled components 00:40:23.140 --> 00:40:24.220 Matt: in our component library. 00:40:24.420 --> 00:40:26.020 Matt: but then we moved that to vanilla extract. 00:40:27.720 --> 00:40:29.880 Matt: So that kind of gives a little bit of a benefit 00:40:29.960 --> 00:40:34.680 Matt: in terms of being able to generate styles at build time 00:40:34.860 --> 00:40:35.340 Matt: instead of at 00:40:35.340 --> 00:40:35.720 Matt: runtime, 00:40:36.220 --> 00:40:38.000 Matt: which works better with server 00:40:38.160 --> 00:40:41.800 Matt: components in Next versus style components 00:40:41.900 --> 00:40:44.580 Matt: or other things in terms of being de-opted to a client component. 00:40:47.040 --> 00:40:48.540 Matt: But yeah, in other places, we basically 00:40:48.720 --> 00:40:50.580 Matt: had to go around and find these cases where we needed 00:40:50.600 --> 00:40:54.380 Matt: to add a used client because the component was being 00:40:54.760 --> 00:41:00.000 Matt: imported into a server component and was using a client API, like useState or useRef or whatever 00:41:00.090 --> 00:41:04.900 Matt: it is. And the GraphQL topic that you were talking about, you know, like how we compose fragments 00:41:05.180 --> 00:41:09.780 Matt: was also like probably the largest thing that we had to worry about, right? Like, yeah, the strategy 00:41:09.790 --> 00:41:14.400 Matt: we had used before is like, you just sort of like accompany each component with its data fetching 00:41:15.180 --> 00:41:19.220 Matt: context, you know, the fragment that it cares about. But we wouldn't be able to like sort of 00:41:19.400 --> 00:41:22.500 Matt: stitch those together into the server component because it would end up pulling in the client 00:41:22.520 --> 00:41:24.140 Matt: proponents along with it because they're statics. 00:41:25.400 --> 00:41:26.500 Matt: So we had to work around that. 00:41:27.919 --> 00:41:28.800 Matt: Luke and team 00:41:28.870 --> 00:41:30.040 Matt: did a great job in terms of 00:41:30.800 --> 00:41:32.680 Matt: building out a simple 00:41:32.900 --> 00:41:34.620 Matt: implementation that allowed us to split that out easily, 00:41:35.420 --> 00:41:36.120 Matt: which is really nice. 00:41:36.920 --> 00:41:38.420 Matt: We could also talk about our express layer, 00:41:39.180 --> 00:41:40.700 Matt: which is non-standard 00:41:40.780 --> 00:41:41.800 Matt: for most next apps, but 00:41:43.279 --> 00:41:44.380 Matt: maybe we save that 00:41:44.650 --> 00:41:46.440 Matt: for the end if we want to get into it. 00:41:46.960 --> 00:41:48.660 Scott: I remember when we first got it together 00:41:48.800 --> 00:41:50.640 Scott: and I think our metrics were a little fucked 00:41:50.860 --> 00:41:52.360 Scott: for the lack of a better term. 00:41:52.780 --> 00:41:58.500 Scott: uh we talked about INP which was something Dillon had introduced we talked about time to first bite 00:41:58.800 --> 00:42:03.460 Scott: although we brought that number down if i remember correctly and i think like largest contentful 00:42:03.700 --> 00:42:09.940 Scott: paint first input delay cumulay layout shift were on par but if i remember correctly you guys again 00:42:10.080 --> 00:42:13.440 Scott: were there a little longer than me we ended up getting those numbers down i don't want to put 00:42:13.580 --> 00:42:20.940 Scott: hard numbers on it but we did see metric benefits at the end of the day in all areas correct yeah 00:42:20.960 --> 00:42:43.340 Matt: Our first, like, yeah, once we fully adopted that server component strategy, even just that naive sort of two component setup, every measured web vital that we had, comparing our previous framework, which used sort of like a PHP backend and like a home-rolled server-side rendering setup, every metric for that 00:42:43.340 --> 00:42:44.160 Matt: versus the 00:42:44.160 --> 00:42:46.660 Matt: app router implementation on Next had improved. 00:42:48.000 --> 00:42:56.220 Matt: And so I think, I don't know, order, scale, magnitude or whatever, but I think everything there improved. 00:42:58.240 --> 00:43:09.180 Matt: And like, yeah, I think some of that could have been just like, you know, better bundler strategy in terms of like, we're like sort of letting Next do the hard work for us in terms of bundling our code. 00:43:10.720 --> 00:43:13.740 Matt: or just streaming rendering or anything like that. 00:43:15.240 --> 00:43:17.340 Matt: There are too many factors at play, I guess, 00:43:17.440 --> 00:43:20.600 Matt: in order to directly say just RSC adoption 00:43:20.860 --> 00:43:22.400 Matt: was the thing that made it better. 00:43:24.020 --> 00:43:26.900 Dillon: I'm going to add, I keep coming back to practical application 00:43:26.980 --> 00:43:27.700 Dillon: for the listener. 00:43:29.660 --> 00:43:32.960 Dillon: What's a good way when people are implementing server components 00:43:33.140 --> 00:43:35.820 Dillon: to keep track of what sort of improvements 00:43:36.900 --> 00:43:39.640 Dillon: they're hopefully seeing across the board on their application? 00:43:40.940 --> 00:43:44.360 Dillon: And I think I have a pretty good answer for this, but I can give it a shot. 00:43:45.440 --> 00:43:51.800 Dillon: And I think it's monitoring core web vitals on like a daily basis at a minimum. 00:43:52.220 --> 00:43:53.720 Dillon: I think that's the way we did it at Wayfair. 00:43:54.420 --> 00:43:58.740 Dillon: I'm currently not doing this at my current job, and I'm wishing that we had something like this set up. 00:43:59.640 --> 00:44:04.080 Dillon: And maybe we do, and it's just not part of my workflow right now, but I'm also curious what you guys think about it. 00:44:04.860 --> 00:44:07.840 Matt: Yeah, I definitely think monitoring Web Vitals, 00:44:09.020 --> 00:44:10.160 Matt: even if you're not using RSC, 00:44:10.500 --> 00:44:13.680 Matt: it's something most teams should probably start thinking about. 00:44:14.940 --> 00:44:17.880 Matt: Web Vitals is, at least from what I've found, 00:44:17.880 --> 00:44:24.960 Matt: is the best way to quantify how good your user experience is 00:44:25.240 --> 00:44:26.540 Matt: or how bad your user experience is. 00:44:26.940 --> 00:44:28.200 Matt: Just quantify your user experience, 00:44:28.800 --> 00:44:29.800 Matt: make it something that's measurable, 00:44:29.920 --> 00:44:32.580 Matt: and then you can start to see improvements from there. 00:44:34.220 --> 00:44:42.000 Matt: Yeah, I don't know, Scott, if you have any hot takes or opinions on RSC performance or just general performance or whatnot. 00:44:42.520 --> 00:44:49.100 Scott: Every engineer should be concerned about the performance of their or impact on performance of what they're building. 00:44:49.980 --> 00:44:52.520 Scott: I don't think a team should just be dedicated to it. 00:44:52.560 --> 00:45:00.220 Scott: it needs to be, I guess, a cultural norm that you're not going to destroy performance and that 00:45:00.220 --> 00:45:06.420 Scott: there are some sort of easy indicators for a team to be able to just see the impact of what they're 00:45:06.580 --> 00:45:13.460 Scott: building. So the guy who's building an epic client side visual diff. But yeah, I do believe, 00:45:13.670 --> 00:45:16.040 Scott: I do believe you need to find ways to do that. 00:45:17.270 --> 00:45:19.440 Matt: Yeah. I mean, 00:45:17.270 --> 00:45:19.440 Scott: back 00:45:19.440 --> 00:45:21.780 Scott: in my day. 00:45:19.440 --> 00:45:21.780 Matt: Sorry. 00:45:22.260 --> 00:45:22.520 Matt: I 00:45:22.520 --> 00:45:25.420 Matt: was going to remark generally on this episode. 00:45:26.980 --> 00:45:30.960 Matt: It's kind of ironic that maybe I'm talking the most about server components 00:45:31.260 --> 00:45:35.380 Matt: when I work at HubSpot and every single app that we maintain at HubSpot 00:45:35.440 --> 00:45:36.140 Matt: is client-side rendered. 00:45:37.720 --> 00:45:40.960 Matt: We talked about potential server component, 00:45:41.040 --> 00:45:43.020 Matt: like what a server component strategy would look like. 00:45:43.960 --> 00:45:45.340 Matt: But yeah, everything is client-side rendered, 00:45:45.540 --> 00:45:46.680 Matt: so we don't even do server-side rendering. 00:45:46.780 --> 00:45:49.660 Matt: And well, there's a few places in the product that you serve server rendering. 00:45:49.920 --> 00:45:51.760 Matt: But yeah, I don't know. 00:45:51.820 --> 00:45:54.340 Matt: it's kind of ironic that you guys are both like, you know, Dillon, you, 00:45:54.480 --> 00:45:57.920 Matt: you're already sort of deep in server component land a little bit in terms of 00:45:58.000 --> 00:46:02.440 Matt: you guys are using next Scott, you guys are considering it. But yeah, 00:46:02.440 --> 00:46:05.480 Matt: I don't know. It's a little ironic in my mind because of that. 00:46:05.980 --> 00:46:07.200 Dillon: So since you're like, 00:46:07.480 --> 00:46:10.560 Dillon: do you find that you're like the expert in server components where you're, 00:46:10.760 --> 00:46:15.520 Dillon: where you're at? And I mean, maybe that doesn't really matter, 00:46:15.720 --> 00:46:18.200 Dillon: but you, you see the importance of like how, 00:46:18.360 --> 00:46:20.140 Dillon: what sort of benefits they can bring. 00:46:20.980 --> 00:46:24.520 Dillon: Is it like in the back of your mind that a large goal of yours is to, 00:46:24.800 --> 00:46:29.240 Dillon: to like introduce that into HubSpot in the future? 00:46:30.600 --> 00:46:34.620 Dillon: And like, do you see that as being like accomplishable, I guess, 00:46:34.700 --> 00:46:36.580 Dillon: with their current legacy applications? 00:46:38.980 --> 00:46:43.920 Matt: I think maybe there's like a number of interesting variables to play. 00:46:44.040 --> 00:46:44.480 Matt: Like sort of, 00:46:44.840 --> 00:46:48.739 Matt: I'm not necessarily on the team that maintains the framework side of our 00:46:48.760 --> 00:46:50.100 Matt: our front end applications at HubSpot. 00:46:50.200 --> 00:46:52.780 Matt: So that sort of provides a gap of like, 00:46:53.020 --> 00:46:55.860 Matt: I'm not that closely related to some of that work. 00:46:57.600 --> 00:47:00.160 Matt: I think also like HubSpot has a very long tail of like, 00:47:00.600 --> 00:47:03.040 Matt: like we support sort of the long tail 00:47:03.540 --> 00:47:05.400 Matt: as opposed to like being more leaning 00:47:06.140 --> 00:47:08.960 Matt: and like sort of forward on like, 00:47:10.520 --> 00:47:12.640 Matt: like instead of like basically HubSpot would choose 00:47:12.820 --> 00:47:14.700 Matt: to maintain an existing system 00:47:14.980 --> 00:47:16.700 Matt: because thousands of apps depend on it 00:47:16.700 --> 00:47:21.020 Matt: versus start to POC a net new system for, you know, 00:47:21.360 --> 00:47:23.040 Matt: a initial like sort of small batch 00:47:23.070 --> 00:47:24.200 Matt: and then work our way out basically. 00:47:24.540 --> 00:47:26.700 Matt: Like, you know, the migration story here is like very, 00:47:27.299 --> 00:47:28.480 Matt: like that's something that's like, 00:47:28.580 --> 00:47:30.400 Matt: has to be considered for everything we do. 00:47:30.760 --> 00:47:32.200 Matt: It's like, how do we migrate the existing apps 00:47:32.320 --> 00:47:33.160 Matt: that we support? 00:47:33.820 --> 00:47:35.560 Matt: So I don't know, it's, yeah. 00:47:36.960 --> 00:47:38.540 Matt: You know, maybe in the future, 00:47:39.040 --> 00:47:42.080 Matt: but at this point it's like kind of hard to see us doing that 00:47:42.360 --> 00:47:44.420 Matt: in the near term, at least, unfortunately. 00:47:45.820 --> 00:47:48.660 Scott: Do we want to talk at all about the express layer? 00:47:48.750 --> 00:47:49.280 Scott: It doesn't matter. 00:47:49.390 --> 00:47:50.200 Scott: We mentioned it. 00:47:50.450 --> 00:47:51.500 Scott: Should we just high level it? 00:47:52.180 --> 00:47:53.760 Matt: Without necessarily needing to get into specifics, 00:47:54.070 --> 00:47:56.520 Matt: I think Next is nice, 00:47:57.200 --> 00:48:01.060 Matt: but as with most things that are like off-the-shelf solutions, 00:48:01.400 --> 00:48:02.960 Matt: they're not going to hit 100% of your use case. 00:48:03.760 --> 00:48:07.340 Matt: At Wayfair, I think the primary reason we adopt Next 00:48:07.460 --> 00:48:08.940 Matt: was just because it was so popular, 00:48:09.380 --> 00:48:11.900 Matt: and it was basically the only solution out there 00:48:11.880 --> 00:48:14.500 Matt: that sort of provided the things, 00:48:15.380 --> 00:48:16.400 Matt: some of the core things we care about. 00:48:17.260 --> 00:48:19.760 Matt: But with that, obviously came trade-offs of like, 00:48:19.880 --> 00:48:21.400 Matt: it didn't give us all the flexibility we needed. 00:48:22.220 --> 00:48:25.080 Matt: And so we ended up needing to do some hacks, 00:48:25.640 --> 00:48:26.540 Matt: as maybe a way to say it, 00:48:27.200 --> 00:48:28.740 Matt: in order to support our use cases. 00:48:31.260 --> 00:48:32.900 Matt: If we were in the same position, 00:48:33.220 --> 00:48:35.080 Matt: I doubt we would choose something I'll do the next 00:48:35.240 --> 00:48:36.540 Matt: just because of its market dominance. 00:48:36.860 --> 00:48:38.320 Matt: But like Parcel probably, 00:48:38.500 --> 00:48:41.640 Matt: like if Parcel had a solution four years ago, 00:48:41.720 --> 00:48:47.780 Matt: five years ago, we probably would have jumped on onboard Parcel, even if it meant a little bit more 00:48:48.480 --> 00:48:53.660 Matt: of a jump from our existing webpack setup, potentially. I say that just because Parcel 00:48:53.680 --> 00:48:57.580 Matt: gives us a lot more flexibility on the server layer versus Next, for example. 00:48:58.700 --> 00:48:58.940 Matt: But yeah, 00:48:59.780 --> 00:49:06.320 Matt: it's definitely a depends sort of thing of what are your trade-offs that you're willing to accept. 00:49:07.760 --> 00:49:10.720 Dillon: I feel like if you're at a small enough company, you can kind of do whatever you want. 00:49:11.280 --> 00:49:13.160 Dillon: Like if you only have five engineers at your entire company, 00:49:13.280 --> 00:49:16.980 Dillon: it's like choose whatever tool everyone that you're working with is happy with. 00:49:17.500 --> 00:49:21.100 Dillon: But at a larger company, you usually just have to adopt whatever 00:49:22.000 --> 00:49:26.780 Dillon: is the industry standard or market, like has the most in the market 00:49:26.980 --> 00:49:29.200 Dillon: because it's just going to be so much easier to hire people 00:49:29.860 --> 00:49:31.040 Dillon: that have experience with it. 00:49:32.080 --> 00:49:34.880 Dillon: And it's a little bit, maybe that's where we're hiring incorrectly. 00:49:35.300 --> 00:49:38.280 Dillon: If we're like, oh, you just need to have this specific framework experience. 00:49:38.520 --> 00:49:40.520 Dillon: I mean, you'd be hiring people more based on just like, 00:49:41.160 --> 00:49:44.420 Dillon: their ability to take any sort of tool and work well with it. 00:49:45.400 --> 00:49:49.340 Dillon: So maybe I'm just like learning for myself on the spot 00:49:49.980 --> 00:49:51.520 Dillon: that we need to be assessing people better. 00:49:53.420 --> 00:49:55.860 Matt: Yeah, I think also like maybe we should do a whole episode 00:49:56.040 --> 00:49:57.900 Matt: on small company versus big company dynamics. 00:49:58.280 --> 00:50:01.360 Matt: I think it's like sort of like, I don't know, 00:50:01.480 --> 00:50:04.260 Matt: there's a lot of interesting things for us to talk about there. 00:50:06.700 --> 00:50:07.960 Matt: You know, like you were saying, Dillon, 00:50:08.040 --> 00:50:09.820 Matt: like a small company could probably pick something else, 00:50:10.040 --> 00:50:12.860 Matt: but it's like also that you have like sort of the competing demand of like, 00:50:13.440 --> 00:50:15.760 Matt: you're small and you just want to ship your product ASAP, right? 00:50:15.770 --> 00:50:20.840 Matt: So it's like, yeah, there's like interesting dynamics there. 00:50:20.930 --> 00:50:24.080 Matt: But yeah, maybe we save that for a following, another episode in the future. 00:50:25.320 --> 00:50:30.760 Dillon: All I felt is like, we're very like, we're using RSCs and we're, 00:50:31.340 --> 00:50:33.760 Dillon: some of us are using Next, we've used Next in the past. 00:50:34.480 --> 00:50:37.759 Dillon: I'm just thinking of this from like the standpoint of a listener who just uses 00:50:37.780 --> 00:50:40.500 Dillon: Ruby on Rails, then they're just like so mad. 00:50:41.520 --> 00:50:43.100 Dillon: They're just in their head. 00:50:43.180 --> 00:50:46.680 Dillon: They're thinking, guys, if you just do these Rails, you wouldn't have any of these issues. 00:50:47.280 --> 00:50:51.000 Dillon: It'd be crazy to bring in somebody who's an expert on that side of things and just like 00:50:51.240 --> 00:50:56.220 Dillon: argue back and forth on why you should use one versus the other and see what we can learn 00:50:56.290 --> 00:50:56.740 Dillon: from each other. 00:50:59.040 --> 00:51:01.660 Matt: Yeah, yeah, I think it would be an interesting perspective. 00:51:03.460 --> 00:51:04.100 Matt: Yeah, yeah. 00:51:04.700 --> 00:51:12.820 Matt: I think maybe, I think we've like sort of covered the majority of the main topic, but I think just like for me, like one of the closing notes is like, I think Scott, you were alluding to this. 00:51:12.880 --> 00:51:21.200 Matt: Like, I think our setup at fireworks was probably the, the most like leaning into the framework setup as I've seen so far. 00:51:21.660 --> 00:51:25.660 Matt: Like we heavily lean into sort of like deep server component trees, right? 00:51:25.780 --> 00:51:28.480 Matt: Like don't sort of de-opt immediately to a used client component. 00:51:29.640 --> 00:51:31.860 Matt: But we sort of lean into like only use that when we need it. 00:51:32.200 --> 00:51:32.300 Matt: Absolutely. 00:51:32.900 --> 00:51:35.020 Matt: And we use server actions and forms. 00:51:35.650 --> 00:51:40.820 Matt: And I think many ways, I was relearning a lot of the basic HTML things, right? 00:51:40.900 --> 00:51:47.180 Matt: Like HTML form submissions, input type checkbox submits as on or off and not true or false. 00:51:47.780 --> 00:51:50.360 Matt: All these sort of, these are just basic web things. 00:51:50.650 --> 00:51:54.540 Matt: And so I think that was kind of neat that React Server Components sort of brought us a little bit back towards that, 00:51:55.620 --> 00:51:57.960 Matt: sort of building off of what the web gives us. 00:51:58.680 --> 00:52:01.720 Matt: So many people have talked about in the past of use the platform. 00:52:02.100 --> 00:52:09.600 Matt: Like, I think ironically, those people probably wouldn't agree, but I think ironically, like server components is basically using the platform to the best extent. 00:52:11.560 --> 00:52:15.020 Matt: So I don't know. Yeah, I think that was like a really cool experience, I think, for us as a team. 00:52:15.200 --> 00:52:20.340 Matt: Like, I think also just like we just like iterated so fast with that setup and it worked pretty well for us. 00:52:20.370 --> 00:52:25.000 Matt: But obviously, different teams scale differently and like sort of adopt technology differently. 00:52:25.130 --> 00:52:28.580 Matt: So it's yeah, it's sort of like a defense case. 00:52:30.060 --> 00:52:34.100 Matt: Yeah, Scott and Dillon, any sort of closing remarks, other thoughts you wanted to cover? 00:52:35.220 --> 00:52:46.200 Scott: I just want to comment on, like, I think it was like in that, maybe this is more obvious, but when the three people there, you, me, and Ian have familiarity in doing this in a really large scale place. 00:52:46.510 --> 00:52:55.260 Scott: And then we're just like, oh, we're going to introduce this across a really small repo that we're all like kind of already aligned on how we're doing things. 00:52:55.400 --> 00:53:00.400 Scott: although there were a lot of new paradigms and a bigger paradigm shift to what we were doing there, 00:53:01.020 --> 00:53:08.820 Scott: like it was much easier to just adopt it straight up at that scale. Whereas like when you have maybe 00:53:08.960 --> 00:53:14.500 Scott: like a hundred or a couple hundred developers that you need to learn this shift and they're relying 00:53:14.520 --> 00:53:18.999 Scott: on the platform team to like teach it, even though it's an open source concept, it's a little bit 00:53:19.960 --> 00:53:22.760 Scott: more of a fluid dynamic situation to work with. 00:53:22.980 --> 00:53:25.840 Scott: So I think just us all having an understanding 00:53:26.480 --> 00:53:28.940 Scott: or kind of alignment and have worked together, 00:53:29.550 --> 00:53:31.660 Scott: you know, empowered our team to be able to move fast 00:53:31.840 --> 00:53:33.580 Scott: and try out all those new things. 00:53:34.920 --> 00:53:37.160 Dillon: I just had like one quick example or point 00:53:37.420 --> 00:53:39.700 Dillon: from recent experience with server components 00:53:40.740 --> 00:53:43.560 Dillon: where I, like my team decided like, 00:53:43.560 --> 00:53:45.560 Dillon: we're going to just do server components, 00:53:46.140 --> 00:53:47.120 Dillon: everything all the way down. 00:53:47.260 --> 00:53:51.720 Dillon: We're going to try to just be server component first in our development. 00:53:53.220 --> 00:53:57.700 Dillon: And one of the examples is you would click an option on a product display page. 00:53:57.740 --> 00:54:03.600 Dillon: It would set a query parameter, and then the server would react to that query parameter re-render. 00:54:05.300 --> 00:54:08.620 Dillon: And I found it to be like, it's fine on a really fast connection, 00:54:09.100 --> 00:54:11.720 Dillon: but you are making a server hop just to update based on an option. 00:54:13.120 --> 00:54:15.000 Dillon: And then everything worked great locally. 00:54:15.420 --> 00:54:22.960 Dillon: And when we deployed this to Cloudflare, we ran into issues where it would just blow up. 00:54:23.620 --> 00:54:29.820 Dillon: And I think this is sort of an issue with some cloud hosting adapters for Next.js. 00:54:30.540 --> 00:54:31.600 Dillon: Don't support everything. 00:54:32.100 --> 00:54:35.760 Dillon: And it's not always clear what they support and what they don't. 00:54:36.810 --> 00:54:42.340 Dillon: So we're in the midst of trying to adopt OpenNext Cloudflare's adapter. 00:54:43.140 --> 00:54:46.920 Dillon: Or potentially decide to just give in and use Vercel. 00:54:48.320 --> 00:54:50.040 Dillon: So that's something I've seen with server components. 00:54:50.240 --> 00:54:58.160 Dillon: Not every hosting environment out of the box will support every feature that you think you should be able to use. 00:54:58.280 --> 00:55:00.640 Dillon: So it can be a bit confusing. 00:55:02.460 --> 00:55:04.220 Matt: Yeah, I agree. 00:55:06.100 --> 00:55:09.120 Matt: I've been intentionally moving off of Vercel. 00:55:09.520 --> 00:55:11.500 Matt: And I originally wanted to keep using Next. 00:55:11.720 --> 00:55:14.540 Matt: but the story of using Next on Cloudflare, 00:55:15.290 --> 00:55:16.360 Matt: which is, in my mind, 00:55:17.060 --> 00:55:18.180 Matt: was just a nice to have 00:55:18.210 --> 00:55:19.120 Matt: just because it seemed 00:55:19.120 --> 00:55:19.280 Matt: like 00:55:19.560 --> 00:55:20.340 Matt: sort of the best offering 00:55:20.430 --> 00:55:23.580 Matt: of free server opportunity 00:55:23.930 --> 00:55:26.640 Matt: versus deploying on Render or Railway 00:55:27.550 --> 00:55:28.360 Matt: or Fly or whatever. 00:55:30.540 --> 00:55:31.940 Matt: Using Next on Cloudflare 00:55:31.990 --> 00:55:34.340 Matt: just came with so many caveats 00:55:34.540 --> 00:55:36.120 Matt: that I've moved most of my apps 00:55:36.170 --> 00:55:37.940 Matt: over to Waku at this point. 00:55:38.100 --> 00:55:39.120 Matt: But yeah. 00:55:41.080 --> 00:55:45.120 Matt: Yeah, should we jump into our spicy takes? 00:55:46.380 --> 00:55:46.680 Scott: Absolutely. 00:55:46.830 --> 00:55:48.480 Scott: And I want to just stress this. 00:55:48.600 --> 00:55:52.680 Scott: We do have the Spice-o-meter™ that we need to use to rank the takes. 00:55:53.180 --> 00:55:56.380 Scott: I have a picture of all the spices or the Taco Bell spices. 00:55:56.890 --> 00:55:57.520 Scott: Are they spices? 00:55:58.780 --> 00:56:05.760 Scott: Salsa packets on my screen so I can tell you it's mild, hot, fire, Diablo. 00:56:06.460 --> 00:56:06.860 Scott: All right. 00:56:07.820 --> 00:56:08.080 Matt: All right. 00:56:08.230 --> 00:56:08.940 Matt: Who wants to go first? 00:56:09.920 --> 00:56:10.900 Scott: I mean, I have one. 00:56:11.300 --> 00:56:14.260 Scott: I have one. I'm happy to go. Do you folks want me to go first? 00:56:14.320 --> 00:56:14.920 Matt: Go for it, Scott. 00:56:16.560 --> 00:56:19.540 Scott: All right. So this is a mild take between the three of us, 00:56:19.760 --> 00:56:23.600 Scott: but I feel like it's got some spice out there to other developers. 00:56:24.260 --> 00:56:28.680 Scott: Maybe it doesn't anymore, but I'm going to give a quick round of context. 00:56:30.060 --> 00:56:33.640 Scott: So we've used Storybook here at, sorry, 00:56:34.120 --> 00:56:35.820 Scott: the three of us use Storybook at Wayfair. 00:56:36.560 --> 00:56:38.320 Scott: We use Storybook here at Airbnb. 00:56:39.320 --> 00:56:40.940 Scott: A lot of people think you 00:56:40.940 --> 00:56:42.060 Scott: could just move your design 00:56:42.060 --> 00:56:44.980 Scott: system into, I feel sorry for me. 00:56:45.900 --> 00:56:51.160 Scott: A lot of people think you could just move your design system into Storybook and like that's good enough. 00:56:51.880 --> 00:56:59.460 Scott: And basically my hot take is Storybook for design systems, Storybook for UI libraries is hot trash. 00:57:00.300 --> 00:57:05.520 Scott: And again, I know this is a mild take between the three of us, but let me just explain a little bit longer. 00:57:06.120 --> 00:57:10.520 Scott: You know, something I've noticed with Storybook here is, yeah, we have it for like every UI library. 00:57:10.900 --> 00:57:12.640 Scott: They all live in one big Storybook. 00:57:12.760 --> 00:57:14.880 Scott: You can basically switch between Storybooks. 00:57:15.380 --> 00:57:19.100 Scott: The Storybook doesn't give you a path on how to use anything. 00:57:19.680 --> 00:57:22.840 Scott: It's just like, here's a panel and you can configure the crap out of it. 00:57:23.220 --> 00:57:24.340 Scott: Here's the code. 00:57:24.640 --> 00:57:27.000 Scott: Here's like an example of what it can do. 00:57:27.560 --> 00:57:33.620 Scott: So it's really on the user to actually care about it and build stories and write about those stories. 00:57:34.280 --> 00:57:36.220 Scott: And it does not incentivize that. 00:57:36.660 --> 00:57:41.620 Scott: Whereas in, for example, the Wayfair design system, we used to govern it. 00:57:41.620 --> 00:57:44.600 Scott: We used to write use cases that we expected you to use. 00:57:44.720 --> 00:57:47.020 Scott: We had prop trees already there. 00:57:47.540 --> 00:57:51.360 Scott: Yeah, maybe Storybook has these features, but no one owns and governs it. 00:57:51.640 --> 00:57:52.560 Scott: It's hot trash. 00:57:52.980 --> 00:57:54.960 Scott: It does not help you figure anything out. 00:57:55.760 --> 00:58:01.740 Scott: Having a thousand props on something that could do anything, especially ones that configure each other, 00:58:02.220 --> 00:58:05.020 Scott: does not help an engineer spend 45 minutes 00:58:05.380 --> 00:58:07.520 Scott: learning how to do it specific use cases 00:58:07.720 --> 00:58:08.540 Scott: that are catered to you. 00:58:08.980 --> 00:58:14.140 Scott: So there's value in having a better mechanism to do it. 00:58:14.640 --> 00:58:17.200 Scott: Storybook is just a mechanism 00:58:17.520 --> 00:58:19.280 Scott: that gives you maybe all of the tools, 00:58:19.540 --> 00:58:20.680 Scott: but doesn't configure it. 00:58:20.900 --> 00:58:23.240 Scott: And people treat it like it's a replacement 00:58:23.240 --> 00:58:25.640 Scott: for a team of folks who tell you, 00:58:26.060 --> 00:58:27.820 Scott: this is how you govern and use our tools. 00:58:28.440 --> 00:58:31.140 Scott: So I know this is a mild take between the three of us. 00:58:31.300 --> 00:58:32.020 Scott: I know we've talked about 00:58:32.020 --> 00:58:32.780 Scott: Storybook before, 00:58:33.340 --> 00:58:35.140 Scott: but it's been top of mind lately. 00:58:35.620 --> 00:58:44.320 Scott: And I do think it's kind of – Storybook does seem like the de facto go-to solution in this space, and I think it should be challenged. 00:58:44.560 --> 00:58:46.100 Scott: I think you guys probably feel that way. 00:58:46.460 --> 00:58:51.900 Scott: I think this is at least a hot take in front end, but here I know it's mild, so 00:58:51.900 --> 00:58:52.380 Scott: I'm done. 00:58:52.580 --> 00:58:55.820 Matt: Dillon, what's your – what's your rating of that? 00:58:56.440 --> 00:59:04.700 Dillon: I'll give it a hot take in that I don't really know what people are using otherwise. 00:59:06.210 --> 00:59:11.640 Dillon: And if you're saying this is hot trash, what's not hot trash as an option? 00:59:11.810 --> 00:59:19.600 Dillon: And is it just building your own little in-house component library website like we did at Wayfair? 00:59:19.630 --> 00:59:23.480 Dillon: Is that the most recommended approach to this? 00:59:23.760 --> 00:59:25.000 Dillon: is just kind of like set up your own thing. 00:59:25.030 --> 00:59:27.640 Dillon: And that way you can get all the information, 00:59:28.140 --> 00:59:30.020 Dillon: architecture for your design system built the way 00:59:30.140 --> 00:59:31.460 Dillon: that makes the most sense for your company. 00:59:31.900 --> 00:59:32.280 Dillon: Is that what you're saying? 00:59:33.460 --> 00:59:35.480 Scott: Yeah, I guess yes and no. 00:59:35.550 --> 00:59:38.020 Scott: Like, I mean, like any markdown solution, 00:59:38.300 --> 00:59:41.580 Scott: any like quick dock solution is better. 00:59:42.100 --> 00:59:45.320 Scott: I just think that the way Storybook presents itself 00:59:45.720 --> 00:59:48.300 Scott: as like a way to create things, 00:59:48.750 --> 00:59:52.359 Scott: the API isn't driven in such a way 00:59:52.400 --> 00:59:58.000 Scott: that it pushes the user to really think through what they're building, but rather it just presents 00:59:58.220 --> 01:00:03.120 Scott: it. We've got a story and there's no governance to it. Whereas when you actually have like dedicated 01:00:03.520 --> 01:00:11.220 Scott: folks who own this part, like it packages away the need to own this by a team. And it's just like, 01:00:11.240 --> 01:00:16.700 Scott: well, it's all here, but nobody looks at all the things of value that it should provide. 01:00:17.000 --> 01:00:19.260 Scott: or at least in the examples I've seen. 01:00:19.660 --> 01:00:21.740 Scott: Like, sure, we've had stories at Wayfair 01:00:22.220 --> 01:00:24.340 Scott: where it's like, here's a bunch of use cases 01:00:24.560 --> 01:00:25.140 Scott: and story names, 01:00:25.620 --> 01:00:27.600 Scott: but nobody wants to write about like 01:00:27.780 --> 01:00:28.920 Scott: when you would use A or B. 01:00:29.600 --> 01:00:32.300 Scott: We make these kitchen sink things 01:00:32.560 --> 01:00:34.080 Scott: where you can turn knobs on, 01:00:34.280 --> 01:00:36.460 Scott: but those don't do like what we did it 01:00:37.200 --> 01:00:38.780 Scott: on Homebase at Wayfair, 01:00:38.900 --> 01:00:39.360 Scott: where it was like, 01:00:39.740 --> 01:00:41.540 Scott: this prop has these options 01:00:42.040 --> 01:00:43.320 Scott: and this is when you use it. 01:00:43.680 --> 01:00:46.099 Scott: Like, it doesn't give, like, teach 01:00:46.120 --> 01:00:50.380 Scott: or push the user to document the API 01:00:51.020 --> 01:00:54.020 Scott: in a way that a first-time user can just look at it 01:00:54.420 --> 01:00:56.600 Scott: and understand and go through a flow. 01:00:57.060 --> 01:00:59.420 Scott: What it does is it gives you the kitchen sink of options 01:01:00.320 --> 01:01:02.180 Scott: and it puts the onus on the team 01:01:02.180 --> 01:01:03.400 Scott: to figure out how to do that. 01:01:03.670 --> 01:01:06.360 Scott: And what we need is a path that allows you 01:01:06.840 --> 01:01:08.040 Scott: to go like straight down 01:01:08.260 --> 01:01:10.040 Scott: and make it easier for a first-time user. 01:01:10.960 --> 01:01:11.620 Scott: So maybe 01:01:11.620 --> 01:01:12.700 Scott: Storybook can be that, 01:01:13.040 --> 01:01:16.440 Scott: But I don't think right now it presents that. 01:01:16.980 --> 01:01:18.420 Dillon: I can tell that you're passionate about this, Scott. 01:01:18.480 --> 01:01:20.840 Dillon: I feel like we just got teleported into a different dimension 01:01:21.120 --> 01:01:22.800 Dillon: and we're in the Design Systems Part 2 01:01:22.800 --> 01:01:23.760 Dillon: episode. 01:01:25.520 --> 01:01:26.500 Matt: Well, I like how this is... 01:01:26.500 --> 01:01:27.680 Scott: The coffee's kicking in. 01:01:27.680 --> 01:01:31.220 Matt: The spicy take section is basically just Scott rants for an hour. 01:01:31.740 --> 01:01:34.060 Matt: And then we try to cut it down to fit it into the episode. 01:01:35.980 --> 01:01:36.680 Scott: It was four minutes. 01:01:36.840 --> 01:01:37.520 Scott: It was four minutes. 01:01:38.600 --> 01:01:39.480 Matt: Yeah, after the cut. 01:01:39.800 --> 01:01:40.740 Matt: Yeah, it felt like an hour. 01:01:43.340 --> 01:01:47.220 Matt: i was gonna say uh you know you were saying like there's no alternative storybook i think you know 01:01:47.280 --> 01:01:51.720 Matt: just like ShadCN just just point to the ShadCN docs there you go there's your storybook done 01:01:52.050 --> 01:01:53.720 Matt: problem solved no that's uh 01:01:53.720 --> 01:01:55.440 Matt: yeah i 01:01:55.440 --> 01:01:56.580 Matt: think my rating of your hot take 01:01:56.580 --> 01:01:57.960 Matt: though scott 01:01:56.580 --> 01:01:57.960 Scott: why the web sucks 01:01:58.250 --> 01:01:59.740 Matt: i think your take is about as 01:01:59.740 --> 01:02:03.360 Matt: spicy as white bread soaked in lukewarm milk 01:02:03.360 --> 01:02:04.160 Matt: i think 01:02:04.160 --> 01:02:04.820 Matt: that's about as 01:02:04.860 --> 01:02:06.640 Matt: as spicy as it is 01:02:06.640 --> 01:02:09.240 Dillon: on the spicy scale it's just taco bell we're sponsored 01:02:09.240 --> 01:02:10.900 Matt: we're 01:02:10.900 --> 01:02:11.520 Matt: sponsored yeah 01:02:12.720 --> 01:02:13.460 Scott: it's just it's 01:02:13.460 --> 01:02:17.360 Scott: just that great minds think alike matt you just you just doesn't agree with doesn't 01:02:17.420 --> 01:02:19.020 Scott: taco bell you just know that i'm right 01:02:17.420 --> 01:02:19.020 Matt: doesn't taco 01:02:19.020 --> 01:02:20.940 Matt: bell uh give you like ranch now as an option 01:02:21.050 --> 01:02:22.700 Matt: so like maybe that's the spice of 01:02:22.700 --> 01:02:28.780 Scott: your take salsa verde boys breakfast salsa 01:02:22.700 --> 01:02:28.780 Matt: all 01:02:28.780 --> 01:02:30.260 Matt: right uh who else 01:02:30.280 --> 01:02:33.960 Matt: is a hot take Dillon do you have a hot take you want me to go my 01:02:33.960 --> 01:02:35.160 Dillon: i'll give a hot take real quick 01:02:35.500 --> 01:02:42.640 Dillon: my hot take is that in the last like five to ten years um react and next and all these frameworks 01:02:42.820 --> 01:02:47.380 Dillon: have added so many new features that most of the community doesn't know how to use and now we're in 01:02:47.380 --> 01:02:55.820 Dillon: a spot where um i don't know people don't know what the hell they're doing and maybe that's like 01:02:56.160 --> 01:02:58.920 Dillon: that's just engineers that I've worked with. 01:02:59.800 --> 01:03:00.660 Dillon: Maybe I'm calling them out, 01:03:01.900 --> 01:03:03.260 Dillon: but they don't have the proper, 01:03:03.440 --> 01:03:07.280 Dillon: like they're not reeducating themselves on new things coming out. 01:03:07.440 --> 01:03:08.260 Dillon: So I feel like, 01:03:09.300 --> 01:03:09.520 Dillon: I don't know, 01:03:09.580 --> 01:03:12.620 Dillon: we're in a weird spot where we have all these great tools, 01:03:13.020 --> 01:03:14.000 Dillon: but nobody knows how to use them. 01:03:14.460 --> 01:03:15.340 Dillon: So it's a bit of a mess. 01:03:16.320 --> 01:03:17.820 Scott: I just agree with that take. 01:03:17.960 --> 01:03:18.340 Scott: So like, 01:03:18.920 --> 01:03:19.180 Dillon: so it's, 01:03:19.820 --> 01:03:20.120 Scott: I mean, 01:03:20.440 --> 01:03:20.580 Scott: I, 01:03:20.840 --> 01:03:21.000 Scott: again, 01:03:21.020 --> 01:03:22.100 Scott: like if we step back, 01:03:22.440 --> 01:03:22.680 Dillon: it's not, 01:03:22.900 --> 01:03:23.180 Dillon: there's no, 01:03:23.320 --> 01:03:24.380 Dillon: like there's no scale. 01:03:24.540 --> 01:03:25.260 Dillon: It's just mild. 01:03:25.360 --> 01:03:27.540 Matt: it's just true or false 01:03:27.540 --> 01:03:28.180 Scott: no i feel 01:03:28.180 --> 01:03:28.300 Scott: like 01:03:28.300 --> 01:03:32.000 Scott: if we step out of the context of the three of us who 01:03:32.220 --> 01:03:38.600 Scott: just align on all this i guess you could say that's a hot take like i agree it ain't it ain't 01:03:38.600 --> 01:03:44.780 Scott: the diablo take matt's been brewing since five in the morning when he woke up for his coding shift 01:03:45.820 --> 01:03:51.160 Scott: but but like i do agree that there's there's just so many tools coming at you but i i just have to 01:03:51.080 --> 01:03:57.220 Scott: say this, I feel like it comes from the step or stems from like, we're going to give you all these 01:03:57.440 --> 01:04:06.200 Scott: tools. You figured out how to use them is like the new way react teaches. Um, and I think that causes 01:04:06.480 --> 01:04:13.880 Scott: folks not to want to try. I don't, I don't know. Like, I like Matt has instilled, okay, we can't 01:04:13.940 --> 01:04:21.180 Scott: turn this into another matt glazing episode but matt has instilled in in us to like try apis try 01:04:21.180 --> 01:04:28.160 Scott: to understand when you might use a thing look into what it's for but like i can't stress enough that 01:04:28.220 --> 01:04:33.080 Scott: like every engineer needs to just try something they need to spend sat an hour on saturday saying 01:04:33.200 --> 01:04:39.099 Scott: they're going to try some api they've never used so they can find a use case for it uh hot take 01:04:39.120 --> 01:04:39.960 Scott: Dillon. I love it. 01:04:40.160 --> 01:04:43.960 Matt: Yeah. I mean, try something. I think, uh, this is why I always say like, 01:04:43.960 --> 01:04:50.560 Matt: I think fuck around, find out is like, should be everyone's life motto. Like you should be 01:04:50.730 --> 01:04:56.440 Matt: messing around with new things and learning. Uh, that's not my hot take though. My hot take is that 01:04:56.859 --> 01:05:04.260 Matt: RSCs are actually good. I think I, which is maybe odd to hear in this episode, I think like, 01:05:04.340 --> 01:05:08.319 Matt: cause we've been kind of glazing the concept of RSCs the whole time. But, uh, I think a lot of 01:05:08.240 --> 01:05:10.960 Matt: people said like saw react server components and said, this is trash. 01:05:11.230 --> 01:05:12.040 Matt: I don't want to do this. 01:05:12.040 --> 01:05:14.140 Matt: I want to go back to client side rendered apps with Vite. 01:05:15.340 --> 01:05:17.180 Matt: I think actually RSCs are like worth it. 01:05:17.740 --> 01:05:19.660 Matt: Like, I think we should, I think more teams should adopt them. 01:05:20.320 --> 01:05:21.480 Matt: Um, that's my hot take. 01:05:21.570 --> 01:05:24.780 Matt: Uh, but along with that, I think you should adopt them, but don't use next. 01:05:25.110 --> 01:05:28.360 Matt: I think that's maybe the lukewarm side of the take for the, at least the three of us. 01:05:30.920 --> 01:05:33.200 Scott: I feel like that was the hotter thing you said. 01:05:33.340 --> 01:05:33.900 Scott: It's so funny. 01:05:34.080 --> 01:05:37.560 Scott: You just, we're all, I don't even know how to rank this take. 01:05:37.700 --> 01:05:38.600 Scott: I'll give you a hot take. 01:05:40.320 --> 01:05:41.300 Scott: Don't use Next. 01:05:41.660 --> 01:05:43.580 Scott: Especially if you're at Wayfair, you should actively 01:05:44.280 --> 01:05:44.940 Scott: be writing. 01:05:46.500 --> 01:05:46.740 Scott: Yes. 01:05:47.300 --> 01:05:49.640 Scott: You should be actively pushing for any other framework 01:05:50.280 --> 01:05:51.560 Scott: and that's what you should be pushing for 01:05:51.560 --> 01:05:52.080 Scott: a promotion. 01:05:54.120 --> 01:05:55.740 Scott: Yair, I know you're listening. 01:05:56.900 --> 01:05:57.440 Scott: Just be like, 01:05:57.500 --> 01:05:57.760 Scott: why 01:05:57.760 --> 01:05:58.580 Scott: are we using this? 01:06:00.540 --> 01:06:01.480 Scott: Come up with an alternative 01:06:01.760 --> 01:06:03.500 Scott: solution and tell them that 01:06:03.500 --> 01:06:03.920 Scott: we're doing 01:06:03.920 --> 01:06:04.060 Scott: it. 01:06:04.060 --> 01:06:06.300 Dillon: We're going to get a cease and desist from Wayfair after this episode. 01:06:09.260 --> 01:06:09.720 Matt: but we're giving them 01:06:09.720 --> 01:06:10.340 Matt: so many good ideas 01:06:10.340 --> 01:06:11.420 Dillon: true 01:06:11.420 --> 01:06:12.420 Scott: we 01:06:12.420 --> 01:06:15.700 Scott: are we're giving them free work this is free labor 01:06:17.040 --> 01:06:20.640 Dillon: most people would think what you said is a hot take matt but i don't think it is i feel like 01:06:21.260 --> 01:06:29.340 Dillon: any new like large change to the way we do things is always met with like outrage and then people 01:06:29.580 --> 01:06:29.780 Dillon: sort of 01:06:29.780 --> 01:06:30.480 Dillon: see 01:06:30.480 --> 01:06:35.340 Dillon: its benefits over time and and changes are made to it based on people's reactions 01:06:35.920 --> 01:06:37.160 Dillon: so it gets better usually 01:06:37.160 --> 01:06:42.620 Scott: yeah i i agree with Dillon like i do think there was a lot of pushback 01:06:42.660 --> 01:06:47.240 Scott: at first i remember like uh you know tan stack was like well we're client side first and we 01:06:47.340 --> 01:06:55.880 Scott: believe in client side uh and then i don't know what happened to uh remix or react router or 01:06:56.360 --> 01:07:02.640 Scott: whatever we're gonna call it again um but i do think there was early pushback and it was like 01:07:03.240 --> 01:07:18.380 Scott: I think I heard, oh, this is why we've been taking a slow, cautious approach to implementing React server components in Remix slash React Router 18, 7, whatever version we're on. 01:07:19.680 --> 01:07:22.340 Scott: I think a lot of people have been like, oh, skeptical about it. 01:07:22.340 --> 01:07:28.100 Scott: But I do think it's starting to marinate that, like, hey, this is becoming the standard, the early pushback. 01:07:29.120 --> 01:07:33.200 Scott: But yeah, I still think it's kind of a hot take because I don't know. 01:07:33.980 --> 01:07:37.220 Scott: I think the whole reason we did this episode is I don't think people know like what is like. 01:07:38.140 --> 01:07:46.560 Scott: We just want one recommended path approach with maybe some nuance we can engineers can make and just be like, this is how you should adopt it. 01:07:46.920 --> 01:07:48.660 Scott: And we're not really seeing that anymore. 01:07:49.440 --> 01:07:53.580 Matt: Yeah, maybe my hot take should have been you should be using Parcel's RSC integration. 01:07:54.180 --> 01:07:55.220 Matt: Maybe that should have been the hot take. 01:07:56.220 --> 01:08:01.700 Matt: Or, maybe this is down to sidetrack, maybe we cut this from the episode, but I like how 01:08:01.840 --> 01:08:07.120 Matt: the Remix guys, Remix team were like, hey, instead of building a good framework, let's 01:08:07.140 --> 01:08:11.900 Matt: just go back to basics and build something that's complete trash and it's complete LLM 01:08:12.100 --> 01:08:15.040 Matt: only centric solutions, which is basically what they're building with Remix v3. 01:08:15.900 --> 01:08:17.759 Matt: They're throwing out, they're saying, we don't want to bundle anymore. 01:08:18.180 --> 01:08:20.339 Matt: We want to use the basics of the web platform. 01:08:20.600 --> 01:08:23.259 Matt: We're going to make your application slower because of it. 01:08:24.380 --> 01:08:25.299 Matt: And they're just leaning into that. 01:08:25.759 --> 01:08:26.040 Matt: They've 01:08:26.040 --> 01:08:27.560 Matt: gone off the rails. 01:08:27.880 --> 01:08:28.020 Scott: It's wild. 01:08:30.980 --> 01:08:32.000 Scott: I like lost 01:08:32.640 --> 01:08:32.759 Scott: context. 01:08:34.500 --> 01:08:36.000 Dillon: That's the best hot take 01:08:36.120 --> 01:08:37.380 Dillon: we've had is just blasting 01:08:37.839 --> 01:08:40.319 Dillon: some out in the wild, 01:08:40.480 --> 01:08:41.200 Dillon: calling them out. 01:08:42.040 --> 01:08:42.680 Dillon: That's Diablo. 01:08:43.920 --> 01:08:45.180 Matt: It's crazy too because they were 01:08:46.100 --> 01:08:47.120 Matt: loved by the industry. 01:08:48.120 --> 01:08:49.779 Matt: But I think they're on their 01:08:49.839 --> 01:08:51.779 Matt: villain arc. People are going to hate them. 01:08:53.600 --> 01:08:54.420 Scott: But they've just gone 01:08:54.440 --> 01:08:59.660 Scott: they've just 360'd around the concept of react server components and like what they were building 01:08:59.670 --> 01:09:04.759 Scott: a framework to compete with next and then they're you know like i just i don't want to call anyone 01:09:04.770 --> 01:09:09.740 Scott: out specifically but i was like there's all these tweets about this is why we haven't implemented RSC 01:09:10.020 --> 01:09:14.940 Scott: yet and like we're working on it we're working on it we're working on it and then the most recent 01:09:14.970 --> 01:09:20.740 Scott: thing i heard is like we're no longer remex we're react router again and i was like i don't know 01:09:20.660 --> 01:09:21.700 Scott: what's going on man well 01:09:21.700 --> 01:09:25.180 Matt: well i think the interesting part also is that the those two guys 01:09:25.880 --> 01:09:29.279 Matt: you know we're putting them on blast but i don't want to say the name but they basically 01:09:29.279 --> 01:09:30.120 Scott: no not 01:09:30.490 --> 01:09:36.040 Matt: they basically didn't have anything to do with the rsc integration for react router v7 as far as i can 01:09:36.160 --> 01:09:41.440 Matt: tell it was done by like other people on the team and so it's like hilarious that everyone's like 01:09:41.580 --> 01:09:45.000 Matt: tagging them and like what's going on with this and it's like they haven't really been doing it 01:09:45.020 --> 01:09:46.420 Matt: so I don't know. 01:09:49.160 --> 01:09:50.640 Scott: I mean, you just totally put them on blast. 01:09:51.299 --> 01:09:54.020 Scott: Let's just say they've done some great work in the past with React Router. 01:09:54.120 --> 01:09:57.120 Scott: It was a great paradigm when it was great. 01:09:57.780 --> 01:09:58.020 Scott: I 01:09:58.020 --> 01:10:02.580 Scott: just honestly was expecting to see like a real, I don't know. 01:10:02.700 --> 01:10:05.900 Scott: I feel like I got hyped up to a real next competitor from them. 01:10:06.460 --> 01:10:08.920 Scott: And then I was going to try it out when I started a Tollbit. 01:10:09.020 --> 01:10:13.180 Scott: And then I pushed it off and now I feel like it's died and I got to get 01:10:13.520 --> 01:10:15.140 Scott: caught up in all the drama that matches 01:10:15.420 --> 01:10:15.880 Scott: like kind of 01:10:17.380 --> 01:10:18.860 Scott: unleashed here and I'm 01:10:19.280 --> 01:10:19.440 Scott: still 01:10:19.440 --> 01:10:21.640 Scott: pontificating 01:10:21.720 --> 01:10:22.640 Scott: that's not the right word 01:10:23.640 --> 01:10:25.200 Scott: app receiving I guess 01:10:25.340 --> 01:10:25.960 Scott: what he just said 01:10:27.000 --> 01:10:29.080 Matt: I think Tanner 01:10:29.260 --> 01:10:31.220 Matt: Lindsley with Tanstack just came in and ate their lunch 01:10:31.240 --> 01:10:32.740 Matt: and provided a far better 01:10:33.360 --> 01:10:34.180 Matt: alongside React 01:10:35.200 --> 01:10:37.140 Matt: environment ecosystem that 01:10:37.340 --> 01:10:39.080 Matt: everyone latched onto but anyway 01:10:39.240 --> 01:10:40.020 Matt: maybe we should have saved this 01:10:40.020 --> 01:10:40.901 Matt: for a different episode 01:10:40.920 --> 01:10:41.300 Dillon: Oh, yeah. 01:10:42.620 --> 01:10:43.140 Scott: Let's do that. 01:10:43.540 --> 01:10:43.660 Scott: All right. 01:10:44.460 --> 01:10:47.520 Dillon: Whether we should use React Query or TanStack Query. 01:10:50.040 --> 01:10:50.180 Dillon: Yeah. 01:10:50.500 --> 01:10:51.180 Scott: Yeah, we should 01:10:51.180 --> 01:10:52.000 Scott: talk about that. 01:10:52.320 --> 01:10:54.280 Scott: We're a little bit behind Syntax on that one, but we should. 01:10:55.720 --> 01:10:57.100 Scott: Maybe we can get Tanner on, too. 01:10:57.680 --> 01:10:58.580 Scott: Maybe we can get Syntax 01:10:58.580 --> 01:10:59.140 Scott: and Tanner on. 01:11:00.240 --> 01:11:00.960 Matt: All of them. 01:11:01.540 --> 01:11:02.380 Scott: At the same time. 01:11:02.440 --> 01:11:03.380 Matt: And the React Router team. 01:11:03.820 --> 01:11:04.400 Matt: Those other guys. 01:11:05.760 --> 01:11:05.980 Scott: Yeah. 01:11:06.700 --> 01:11:08.860 Scott: We're just going to start an internet brawl. 01:11:10.000 --> 01:11:10.400 Matt: All right. 01:11:11.940 --> 01:11:13.940 Matt: we've been ranting for maybe far too long 01:11:14.540 --> 01:11:15.760 Matt: let's quickly do our stand up 01:11:16.380 --> 01:11:17.160 Matt: try to keep it short 01:11:17.700 --> 01:11:18.320 Matt: don't go on a rant 01:11:18.780 --> 01:11:20.740 Matt: Scott, don't go on a rant 01:11:22.480 --> 01:11:23.640 Scott: shots fired dude 01:11:25.080 --> 01:11:26.340 Matt: Dillon, stand up update 01:11:26.760 --> 01:11:27.940 Matt: what have you done in the last week 01:11:28.020 --> 01:11:30.720 Matt: what shareholder value have you delivered in the last week 01:11:31.420 --> 01:11:32.440 Dillon: I was just going to give 01:11:32.760 --> 01:11:33.300 Dillon: personal updates 01:11:34.560 --> 01:11:35.160 Matt: go for 01:11:35.160 --> 01:11:35.260 Matt: it 01:11:36.200 --> 01:11:36.500 Dillon: that's fine 01:11:37.160 --> 01:11:40.400 Dillon: recently started trying out this product called 01:11:40.420 --> 01:11:49.060 Dillon: Zello, S-T-E-L-O, from a company called Dexcom, D-E-X-C-O-M. And it's a continuous glucose 01:11:49.540 --> 01:11:56.040 Dillon: monitor. I've had issues in the past with migraines, which I think are caused by like a form of 01:11:56.500 --> 01:12:01.560 Dillon: hypoglycemia, which means my blood sugar can tank. And I don't have it like my appetite doesn't kick 01:12:01.680 --> 01:12:04.780 Dillon: in. And next, you know, I have a migraine that literally ends my day. I can't work. 01:12:05.960 --> 01:12:09.620 Dillon: And it's been super helpful to be able to know my glucose levels. 01:12:11.300 --> 01:12:11.420 Dillon: Yeah. 01:12:11.840 --> 01:12:12.920 Dillon: So really cool. 01:12:13.160 --> 01:12:19.260 Dillon: Hopefully I don't have to wear this the rest of my life to keep this from happening. 01:12:19.580 --> 01:12:27.600 Dillon: But it's been super helpful to understand how different foods affect my sugar levels. 01:12:28.120 --> 01:12:29.300 Dillon: So it's super cool. 01:12:30.980 --> 01:12:31.780 Dillon: And then other standards. 01:12:32.180 --> 01:12:32.540 Dillon: I'm getting 01:12:32.540 --> 01:12:34.460 Dillon: over a cold this week. 01:12:34.920 --> 01:12:37.820 Dillon: happy to be almost over that crap. 01:12:39.660 --> 01:12:40.800 Dillon: I think the former really 01:12:42.740 --> 01:12:44.920 Dillon: explains your docile attitude sometimes. 01:12:45.520 --> 01:12:47.980 Dillon: Dude, I don't get hungry sometimes 01:12:49.880 --> 01:12:52.200 Dillon: and I don't know why I'm feeling bad 01:12:52.260 --> 01:12:54.680 Dillon: and then all of a sudden, I've had it get really bad. 01:12:56.020 --> 01:12:59.120 Dillon: Where my hands have gone numb, my face went numb, it's scary. 01:12:59.880 --> 01:13:01.180 Dillon: So being 01:13:01.180 --> 01:13:01.699 Dillon: able to 01:13:02.240 --> 01:13:09.200 Dillon: understand your health better is super super important yeah try to follow that all right 01:13:11.380 --> 01:13:13.460 Scott: yeah no that's sad that's really sad but i'm gonna 01:13:14.780 --> 01:13:17.520 Dillon: meant to be like a happy thing 01:13:20.180 --> 01:13:23.700 Dillon: well even though i'm 35 years old and i'm still improving myself 01:13:25.900 --> 01:13:27.200 Matt: Dillon downer back that is a 01:13:27.200 --> 01:13:27.900 Dillon: blessing part 01:13:27.900 --> 01:13:28.360 Scott: is over 01:13:31.180 --> 01:13:38.420 Scott: spicy take Dillon sleep yet all right all right all right so uh life update uh my groomsmen 01:13:38.860 --> 01:13:44.580 Scott: one of them is matt uh are getting our suits this weekend for our wedding all right that's 01:13:44.660 --> 01:13:45.260 Matt: for your wedding 01:13:45.260 --> 01:13:46.140 Matt: not our 01:13:46.140 --> 01:13:52.000 Matt: wedding 01:13:46.140 --> 01:13:52.000 Scott: oh yeah sorry freudian slip matt and i are getting married 01:13:52.699 --> 01:13:53.900 Scott: it's my wedding 01:13:56.200 --> 01:14:01.360 Scott: enough I'll say about that we got to move on shareholder value uh we've been migrating off 01:14:01.560 --> 01:14:08.540 Scott: of Datadog to um well an internal system called telescope but it's powered by Grafana monitors 01:14:08.930 --> 01:14:09.080 Matt: shout 01:14:09.080 --> 01:14:09.820 Matt: out to Eric about 01:14:09.820 --> 01:14:10.880 Scott: that I 01:14:10.880 --> 01:14:16.400 Matt: at Grafana what shout out to Eric 01:14:10.880 --> 01:14:16.400 Scott: oh yeah Eric Jacobson 01:14:17.180 --> 01:14:19.140 Scott: shout out Eric I just immediately went to 01:14:19.140 --> 01:14:19.980 Scott: Hermanson I was 01:14:19.980 --> 01:14:20.940 Scott: so lost all 01:14:20.940 --> 01:14:21.820 Scott: right yeah so 01:14:21.840 --> 01:14:24.500 Scott: So actually, I had to bite my tongue. 01:14:25.400 --> 01:14:30.940 Scott: I was like, you cannot message Eric about how to use a Grafana monitor. 01:14:31.560 --> 01:14:32.660 Scott: That is not okay. 01:14:33.680 --> 01:14:34.640 Scott: There are docs for a reason. 01:14:35.100 --> 01:14:35.240 Scott: Okay. 01:14:35.600 --> 01:14:39.840 Scott: So delivered zero shareholder value with that, but I'm trying. 01:14:40.560 --> 01:14:44.100 Scott: And we'll be working on the visual diff for a long time. 01:14:44.200 --> 01:14:44.720 Scott: Stay tuned. 01:14:45.120 --> 01:14:45.500 Scott: I'm done. 01:14:45.820 --> 01:14:46.000 Scott: Matt. 01:14:46.620 --> 01:14:47.500 Matt: yeah I've been 01:14:48.180 --> 01:14:49.660 Matt: I've been in this migration like 01:14:49.960 --> 01:14:51.540 Matt: lyaml migration translation 01:14:51.840 --> 01:14:53.780 Matt: migration pit 01:14:54.120 --> 01:14:54.860 Matt: for the past few weeks 01:14:55.900 --> 01:14:57.160 Matt: it feels like it just keeps going on 01:14:57.440 --> 01:14:59.720 Matt: I feel like I haven't been productive so I haven't delivered 01:14:59.760 --> 01:15:01.560 Matt: any shareholder value hopefully 01:15:01.600 --> 01:15:02.900 Matt: my manager doesn't hear me say that 01:15:03.800 --> 01:15:05.120 Matt: no I'm joking 01:15:06.240 --> 01:15:07.960 Scott: I'm sending this directly to Andrew 01:15:09.200 --> 01:15:09.760 Matt: no no 01:15:09.840 --> 01:15:10.600 Matt: I think it's been good 01:15:11.480 --> 01:15:12.100 Dillon: let me save these 01:15:12.100 --> 01:15:12.920 Dillon: updates for the end 01:15:13.220 --> 01:15:13.820 Dillon: so if you 01:15:13.820 --> 01:15:14.060 Dillon: can 01:15:15.800 --> 01:15:17.280 Dillon: None of your managers made it to the end. 01:15:17.760 --> 01:15:18.460 Matt: Yeah, exactly. 01:15:20.960 --> 01:15:22.680 Scott: Only Yair's making it to the end. 01:15:23.740 --> 01:15:24.020 Matt: Let's see. 01:15:24.140 --> 01:15:26.000 Matt: And then outside of that, yeah, like I've been, 01:15:26.440 --> 01:15:28.260 Matt: so I've been messing around with Parcel's RSC integration, 01:15:28.440 --> 01:15:29.440 Matt: which I know we talked a little bit about, 01:15:29.720 --> 01:15:30.880 Matt: but like it's pretty cool. 01:15:31.220 --> 01:15:31.820 Matt: It's pretty dope. 01:15:32.780 --> 01:15:35.820 Matt: And then Redwood SDK is like another RSC integration 01:15:36.040 --> 01:15:37.280 Matt: that I messed around with just last night 01:15:37.520 --> 01:15:39.560 Matt: to build like a quick little to-do demo app, 01:15:39.700 --> 01:15:40.520 Matt: which we'll link in the show notes. 01:15:42.200 --> 01:15:43.660 Matt: But it's pretty cool too. 01:15:43.960 --> 01:15:48.100 Matt: it's a pretty neat take on server component setup and it's like completely cloudflare native it's 01:15:48.140 --> 01:15:53.000 Matt: like support for d1, Durable Objects it's like everything else under the sun which is pretty 01:15:53.040 --> 01:16:03.160 Matt: dope um yeah i think that's about it um just wanted to uh yeah like uh uh another reminder 01:16:03.280 --> 01:16:06.940 Matt: that uh you know if you enjoy this episode or episodes like this share this with your friends 01:16:07.120 --> 01:16:12.100 Matt: that's how we get most of our listeners uh join our discord community um where you can talk about 01:16:12.120 --> 01:16:13.240 Matt: the episode and 01:16:14.300 --> 01:16:15.860 Matt: with other people to enjoy the show also. 01:16:16.740 --> 01:16:18.000 Matt: We had some pretty good conversations 01:16:18.260 --> 01:16:19.840 Matt: that I think have spurred some topics that we'll cover 01:16:19.920 --> 01:16:20.300 Matt: in the future. 01:16:22.240 --> 01:16:23.500 Matt: And yeah, I think that's about it. 01:16:25.000 --> 01:16:25.320 Matt: Peace out. 01:16:25.920 --> 01:16:26.580 Scott: Give us feedback. 01:16:28.040 --> 01:16:30.120 Scott: Give us feedback. We'll shout you out in the episode. 01:16:30.640 --> 01:16:32.000 Scott: If we haven't shouted you out yet, 01:16:32.080 --> 01:16:33.360 Scott: let us know in the Discord. 01:16:33.700 --> 01:16:33.820 Matt: We'll 01:16:33.820 --> 01:16:36.200 Matt: give you a Bike Shed merch. 01:16:36.840 --> 01:16:37.640 Matt: Bike Shed pod merch 01:16:38.480 --> 01:16:39.360 Matt: when we make it. 01:16:39.400 --> 01:16:40.020 Scott: Coming soon. 01:16:40.780 --> 01:16:41.700 Matt: Within the next 10 years. 01:16:42.100 --> 01:16:43.560 Dillon: we'll make it we'll get some t-shirts 01:16:43.670 --> 01:16:43.820 Dillon: and 01:16:43.820 --> 01:16:45.680 Dillon: we'll send you some merch 01:16:46.980 --> 01:16:47.080 Matt: yeah 01:16:49.800 --> 01:16:50.000 Matt: alright 01:16:51.640 --> 01:16:52.940 Matt: see you guys next week maybe 01:16:53.070 --> 01:16:53.180 Scott: peace 01:16:54.440 --> 01:16:55.540 Dillon: see ya then