895: React Server Components: Where are we at?

Scott and Wes break down the current state of React Server Components — what they are, how they work, and why they’re so controversial. From framework support to bundling complexity, it’s everything you need to know about RSC in 2025. Show Notes 00:00 Welcome to Syntax! 01:01 Brought to you by Sentry.io. 01:55 What exactly are React Server Components? 02:18 Server components rendering. 03:17 Server components are async. 03:45 Server components can be suspended. 05:05 Server components send RSC payloads to the browser. 06:08 This feels like HTMX? 06:54 Client components are still server rendered. 07:58 Server Functions. 08:52 useActionState. 09:12 Frameworks and React Platforms. 09:16 NextJS. 09:42 Waku. 12:26 candycode.com Daishi Kato 14:23 React Router. Michael Jackson Tweet. 19:29 Vite. vite-plugin-react-server 20:54 Tanstack. Syntax Ep 833. 22:39 Bun. 23:01 DIY. 23:39 Why so much hate? 25:28 I want it my way. 27:46 React Server Components lock-in. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Scott Tolinski?

  Welcome to Syntax. Today, we're going to be talking about React Server Components. It is April of 2025. I just had to look at my clock to know that. It is April of 2025, and you might not know where we're at with these things. You know, some people might still view React Server Components as this next JS feature. So what is the status of them? How could you use them? Even what are they to a degree? And just generally, what's up with React Server Components? What's the deal? What's the deal with React Server Components?

• 0:35Wes Bos?

  What's the deal? Like, they've been around, they've been around since like, like for five years? But also, they're still haven't, I don't feel like they have fully caught on yet. So we're gonna try to attempt to explain why and what they are and sort of where you can use them right now. And it's not just next JS.

• 1:01Scott Tolinski?

  And what's the deal with bad websites? Your website shouldn't be bad. You, you should be able to have a tool like Sentry. If your website's bad, it's probably because you're not using Sentry. [email protected], the perfect place to make sure your application is running as good as it possibly can. It's fast, it's friendly, it's not crashing for users, there's no errors, and it's, it's even functioning at all, period. So if you want to make sure your application is working, and I don't want to just make sure, but let's get this straight, it's about fixing it fast. You have things like session replay to see exactly a video of what happened, what went wrong when the thing crashed. You have all kinds of tools to make solving the bugs really, really fast. There's even some AI assistant tools in there as well. It's the best. It's seriously the best.

• 1:46Scott Tolinski?

  So this podcast is presented by Sentry. Head on over to sentry.io/synthesis. Sign up and use the coupon code TASTYTREAT, all lowercase, all one word, and get two months for free. Let's give a quick rundown of what React Server Components actually are. Because I do feel like even today, when people talk about them, there is some misunderstanding, maybe a little bit about what exactly they do.

• 2:09Wes Bos?

  Yeah, a lot of people think, well, my...

• 2:13Wes Bos?

  Client components are already server rendered. So like, isn't that good enough? So server components in React are components that are rendered either as as part of a build step, which is like ahead of time, like server components don't require a server, which is kind of funny. But in most cases, you're probably going to be rendered on demand entirely on the server. That differs from client components, which client components are often rendered, obviously in the client, but they can also still be be server rendered. The difference between the two is that server components simply just send their output

• 2:56Wes Bos?

  to to the browser, similar to how server rendering HTML works. Versus client components, they bring everything they need in order to render themselves on the client, which it's not really one or the other. In most cases, you you'll be using both of them together. Server components are a sync, meaning that you can simply just await before you return data, which is amazing API for many use cases. So you don't have to do like a weird loading state. And if it's loading, then return nothing. You can simply just await like a database

• 3:36Wes Bos?

  call. And then right, once that await is resolved, you can go ahead and render out your your markup, your JSX.

• 3:45Scott Tolinski?

  Yes. Server components, they can also be suspended. So basically, you can continue rendering the rest of your app while these things are working on their their render. So it's not like it's going to hold up if you are awaiting them.

• 4:02Wes Bos?

  Yeah. Modern React is is often streamed, meaning that the browser will start to to render pieces of the website. And then if you have something that might take a little while, for example, on my new website, it's probably by the time you're listening to this, westboss.com, there's a like a Twitter. Twitter in the footer, right? And I don't want to hold up the entire page while I'm fetching Twitter. What if that takes takes a while? So you can suspend that and then the rest of the website will get sent. And then when that one component is done, it's no longer suspended. And then it will, it will send the markup from the server to the client and render it on out.

• 4:46Scott Tolinski?

  You got a Twitter in the footer, my guy?

• 4:47Wes Bos?

  Yeah, I had to, I had to do some somewhat seedy, sketchy stuff in order to get the Twitter API working. But I've, I've, I've got it entirely reverse engineered. I'm pretty, and it's been working solid for a couple of months now.

• 5:03Scott Tolinski?

  Nice. Yeah. Server components, basically the way that it sends a, an R, an R S C, a React server component payload to browser. It's basically sending text, right? Which is then, is it, it's rehydrated, right? Is that the word you would use in this?

• 5:22Wes Bos?

  No, because, because rehydrated assumes that things are bound to it.

• 5:29Scott Tolinski?

  Okay.

• 5:30Wes Bos?

  Rehydrated means that the browser is then setting it up. So server components are simply just sending either their HTML to the browser. Or if you are doing something, refreshing one of the components, it is simply just sending the outputted React payload. You can think of it as a server sending HTML. It's not technically HTML. It's technically React code that is used to embed it. But it's not, no, it's not fair to say that it's rehydrated because there's no, there's no client side stuff happening on a server function unless you're explicitly using a client component.

• 6:08Scott Tolinski?

  Gotcha. That, that tracks. Okay. Forgive me if I'm a little off on some of these things. This felt way of doing things doesn't have any of this stuff. So I, I am like, my understanding of this stuff is definitely from a React developer who hasn't used React server components beyond the very basics. And so because of that, like,

• 6:30Scott Tolinski?

  You could think of this conceptually, like you said, it's not HTML that's being sent from the server. But you could think of it conceptually as if you were, you know, like when we're doing HTMLX stuff.

• 6:41Wes Bos?

  Yeah.

• 6:41Scott Tolinski?

  People say you have something and it just returns HTML instead of data and swaps out that HTML.

• 6:48Wes Bos?

  Exactly.

• 6:49Scott Tolinski?

  Conceptually, it's similar to that, except for it is React code and not HTML straight up.

• 6:54Wes Bos?

  Yeah, exactly. But it's not bringing anything else with it, you know? So if you had, like, an expensive library to do, like Markdown parsing or code highlighting is a good example, where in order to do code highlighting in the browser, you either have to use a smaller library that's not as good, or you can use a very large library, you have to download the entire thing on in the browser, which is not awful in some cases. But in the case of a server component for my code blocks, I render it 100% on the server and it simply just sends the HTML to the browser.

• 7:38Wes Bos?

  And I don't have to worry about how large any of my plugins are for Markdown parsing or for code highlighting or anything like that, because it all happens on the server and just a thin little markup is sent to the client.

• 7:52Scott Tolinski?

  Yeah, it sends the result.

• 7:55Wes Bos?

  Exactly.

• 7:55Scott Tolinski?

  Not the library. Yes, yeah.

• 7:57Wes Bos?

  Exactly. Server functions, which were previously called server actions, are functions that run on the server and sort of work with React server components. So this could be like a database call, could be, like I said, Markdown code highlighting. Server functions are functions that can be called either from the client or on a form submission, meaning that you get the, you essentially get RPC, meaning that you can write a function that runs on the server and then you can simply just call that from your UI and instead of it import-

• 8:39Wes Bos?

  That server function into your client side application. It will just run the RPC back and forth commands between the two and send the data from from one to another. And then there are several hooks you can use for maintaining. Use action state is the big one for maintaining the return, what comes back from the response, any pending, like if something is waiting. Clearing caches, all that stuff.

• 9:06Scott Tolinski?

  Word.

• 9:07Wes Bos?

  That's like a very quick rundown of what React server components are. So where are we at now with all of the the different frameworks?

• 9:16Scott Tolinski?

  Yeah, so I guess the joke of it being just a next JS feature doesn't really track these days, but you will see that there is not a ton of support still out there with like two major platforms supporting it well. And then other things, you know, potentially so next JS full support. It's it's, you know, the first one to really embrace React server components. The Waku, which is honestly really exciting framework, waku.gg. It's the minimal React framework, does have full support for React server components. And the documentation I found on these to be very good in terms of how to use them with.

• 10:00Wes Bos?

  Yeah.

• 10:01Scott Tolinski?

  So Waku is enticing to me, honestly.

• 10:03Wes Bos?

  So I built, I moved my entire website, which was on Gatsby. I moved it to next JS and I I found myself frustrated, not with React server components, but just with like having to do things in a very specific next JS way, which normally I don't mind because I'm building stuff from scratch. But having to try to shoehorn my like Gatsby code into next JS specific way. It was just, it was a bit too frustrating for me and the builds kept breaking and stuff like that. So I was like, you know what? I'm gonna try Waku. So Waku is from the developer behind Zoo Stand and what's the other one?

• 10:49Scott Tolinski?

  Joe Tai.

• 10:50Wes Bos?

  Joe Tai, yeah.

• 10:51Scott Tolinski?

  Yeah.

• 10:52Wes Bos?

  And I'm really happy with it. So almost all of the code from the next JS ported over to Waku because it was just React server components, right? It just worked a little bit nicer. It uses VIT, which I'm pretty happy about. It's like three or four VIT processes sort of put together because there's a client-side VIT process, there is a server-rendered client VIT process, there's a React server component VIT process, and I think there's, there's one more, which is a little odd, but it works. And I've been, been really happy with it. It still is early, like it's not out of 1.0 yet.

• 11:34Wes Bos?

  The documentation is, you said the documentation is great. It looks nice, but the documentation is sparse. You have to do most of your learning from examples. Yes.

• 11:45Scott Tolinski?

  Clear, maybe not complete.

• 11:47Wes Bos?

  Yeah, there's, there's no like, I don't, I would go as far to say there's, there's like no docs. It's just like a bunch, like one page showing all the, how, all the APIs. And then there's like 30 or 40 examples, which I really like because you can dip into the examples directory and go in. But like, I'm a bit of an idiot and I figured it out and I've been, been really happy with it. I got it hosted on CliveFlower workers. The whole thing is building in like, like two minutes. Like that's the build process from next to Waku went like in half, which is, was unbelievable. So I was really happy with that.

• 12:26Scott Tolinski?

  Yeah, I want to take a brief sidebar here. They have a little thing in the bottom corner of the Waku website saying designed by Candy Code, candycode.com. Man, what a cool little site this was. They, they've designed a lot of things that we like, like the payload CMS, man, Joe Ty's website, but just a lot of cool little websites. If you go through their kind of general thing, but also the website itself is just really pleasant, pleasant and modern in a, in a great way, while not looking like anything you've really seen before. So big fan of this website.

• 13:04Wes Bos?

  They have a gradient scroll bar. Is that possible?

• 13:10Scott Tolinski?

  Is that even possible?

• 13:11Wes Bos?

  Is that? How are they doing that? I didn't know you could put a gradient scroll bar. Or have they re-implemented it?

• 13:17Scott Tolinski?

  They they possibly re-implemented the scroll bar. I don't know. I haven't I haven't examined that. There's a lot of interesting gradient stuff here on this website, whether that's gradient text.

• 13:27Wes Bos?

  Oh, yeah. Scroll bar, thumb, background image, linear gradient. Yeah, you can put a background image on a scroll bar thumb. I didn't know you could do that.

• 13:38Scott Tolinski?

  It looks good. Yep.

• 13:40Wes Bos?

  I've never seen that before. Well, today, today I learned what about? What does it look like in Safari? Hold on.

• 13:47Scott Tolinski?

  So.

• 13:48Wes Bos?

  The scroll scroll bar APIs were different in every. Oh, it works in Safari. Let's try it on Firefox.

• 13:55Scott Tolinski?

  Firefox is the.

• 13:58Wes Bos?

  But everybody standardized. No, there was a standardization of the scroll bar CSS API. But from what I remember, it's it was relatively limited.

• 14:08Scott Tolinski?

  OK, no gradient on my Firefox.

• 14:11Wes Bos?

  No, no gradient on Firefox. This it's still using the older like colon, colon, webkit scroll bar.

• 14:17Scott Tolinski?

  Webkit, yeah.

• 14:18Wes Bos?

  Big fan. That looks cool.

• 14:20Scott Tolinski?

  Yeah, cool site. Candy code. Nice work.

• 14:23Wes Bos?

  React Router not shipped yet. React Router has been talking about React Server Components for probably like well, a couple of years now. It was supposed to be shipped with the like the remix to React Router 7. And then it never got its way in. There's been a pull request open for a long time. It's a very hard thing to get right. And I think that it's it's very hard for these these library authors to to try to figure out how to bring it in. Alongside that, Michael Jackson, who's one of the creators of of React Router. He put out a tweet that says React Server Components are nice in theory, but five years in, it's not working out. It's been fun.

• 15:08Wes Bos?

  Yeah, you taught me a lot, but I'm done. And he says, have fun with your React Server DOM, ESMP, client server bundles. And I think that that's what it is, is that building a framework that supports React Server Components.

• 15:25Wes Bos?

  Goes so deep into the bundler realm. Like I said, wackos, three or four B processes. It's just problems all the way down. I can't imagine all the headaches. The headaches, myself using it, have been been high. I can't imagine trying to build the the framework that it does. Even something as simple as a singleton in next JS is just like not possible because there's several bundles and you cannot share a singleton between the two. Like, it's just, it's not possible at all. It's, it's really frustrating.

• 16:01Scott Tolinski?

  Even to be clear, people are asking, are you done with React or just React server components? And he says, the whole thing. Onto greener pastures. So it seems like he's done with React. This has been like the straw that broke the camel's back.

• 16:14Wes Bos?

  Yeah, I, I'm curious. I, maybe we should have Manda to talk about this because I've been following his GitHub for about a year now and he's been cranking out all kinds of standards based modules, things that are based on ESM, things that are based on web standards, things that are based on browser built ins and just like something that I've been kinda, I've been beating this drum as well. I did, I did a couple of conference talks about this. It's just like standards based JavaScript is, is the future. And a lot of this React server component stuff is not that. It's very heavy on bundlers.

• 16:57Wes Bos?

  And I like, I like React server components, but it's not the like, the standards that that we, we know and love. So I'd be curious to see. He's cooking. He's cooking on something. No, you can tell. Cause like they, they said that something will come of remix and like they haven't announced what that is. He's been cranking out all these tiny little modules, which he's doing that for a reason. He's, he's definitely, they're definitely cooking on, he's cooking. I'm curious.

• 17:25Scott Tolinski?

  Wasn't there some new HTML or a new JavaScript API for swapping DOM elements or something just somewhat recently?

• 17:34Wes Bos?

  Yeah.

• 17:35Scott Tolinski?

  What was that called? I'm like trying to Google it and I cannot find the name of it.

• 17:39Wes Bos?

  Yeah, it's, it's moved before. And this is a new JavaScript API which will allow you to

• 17:47Wes Bos?

  Move parts of your DOM somewhere else without, normally what happens is if you move a DOM element, you take it out of the DOM, you lose all of your state, you lose all of your bindings, all of your event listeners, everything, and then you put it back in and it has to re-render it and it's got to re-add your bindings and all of that. And this new move before API will allow you to simply just move things in the DOM without having to detach any of that. So, why are you asking about that? What are you thinking?

• 18:18Scott Tolinski?

  Oh, just that like, you know, the ways that we work in in front-end frameworks, they seem to be being aided a little bit more by newer JavaScript APIs and even newer CSS APIs, like whether that is, you know, view transitions, you know, easier ways to swap our elements that are more, less needing of a shadow DOM type of situation. I don't really know. It just feels like, it feels like the web platform itself is getting more friendly towards the types of things that we've been really leaning on things like the virtual DOM for.

• 18:56Wes Bos?

  And React itself is, is working on something called React Activity. It used to be called, I think, React Offscreen. I haven't looked into it too much, but I think the, I think it's going to use that API. And I think the idea with that is you can pre-render things

• 19:15Scott Tolinski?

  Yes.

• 19:15Wes Bos?

  off-screen. And then when it comes time to having to show them, you can swap them in lightning fast without having to do any of the reattaching that we talked about.

• 19:28Scott Tolinski?

  Interesting stuff.

• 19:29Wes Bos?

  Yes. Veet. Can you use React Server components with Veet? Kind of. That's, Waku has figured it out, or Wakku. But Veet 6 has this new API called the Environment API. And the whole idea with the Environment API is that you can run Veet in multiple environments. Veet was simply a browser-based bundling tool. And now with the Environment API, it can, it can work in Node, it can work in, on Cloudflare workers, it can run on the browser. And that then opens up

• 20:04Wes Bos?

  A lot more for framework authors because now you can control the whole stack of like both my server and my client all are running through Veet. Instead of having to do some weird like bundling, you know, the running, running that on the on node has always been tricky. So Wakeu doesn't use that this just yet. I'm assuming they will move over to that and then that will get rid of the three or four Veet processes. There's a couple of plugins, a couple of people have taken stabs at plugins for Veet. Using React Server Components, but nothing that is like simply, you know, how, how easy Veet is to get up and running.

• 20:44Wes Bos?

  I bet we will start to see that soon where there'll be like a quick little starter that gives you a server and a client all running through Veet.

• 20:53Scott Tolinski?

  Yeah, let's hope so. Tanstack, a lot of people use Tanstack Query, you can use React Server Components via Next.js with Tanstack Query currently. There is something called Tanstack Start, which is their whole platform. Tanstack Start itself does not support React Server Components just yet. It does do SSR. I know we talked to Tanner and there's an emphasis on like client side stuff within Tanstack Start, but you can do SSR with it. Start does have React Server Components planned. But like you said, it's, it's also like React Router been delayed many times. I personally don't know the status of where it's at right now.

• 21:31Wes Bos?

  Jumped into the Discord a couple of weeks ago when I was like rethinking Next.js and I was like, hmm, what should I, I was like, maybe Start? And I was like, hey, like, where are you, where are you at with this type of thing? And it seems like they're more focusing on getting like a solid start. Not solid start, but like getting everything with Tanstack Start just to kind of like figure it out and finish and out the door. Because then adding server components to that is, is just another thing. So I think they want to get everything else stabilized first and then they will move on to it. But they are planning on it and Tanner is a big fan of server components, he said, so eventually.

• 22:12Wes Bos?

  But it is, it is kind of interesting that like, yeah, we're a couple of years in and really only Wakeu and Next.js are like the two.

• 22:21Scott Tolinski?

  Usable.

• 22:21Wes Bos?

  Like solid ways and like and even Waku is I maybe would say don't don't build a huge application, personal website, uh, which is relatively large, but I don't mind fussing with with it, but it's still it's moving quick and things are breaking, right? It's pre 1.0.

• 22:38Scott Tolinski?

  Yeah, word.

• 22:39Wes Bos?

  Bun, nothing really there on Bun just yet, but Bun is big on on like running JSX on the server and they have quite a few demos of kind of similar ideas. So we I wonder if we'll see something like that or we'll see something similar to React Server Components come out of Bun. Um, and then and DIY, you can try to do it yourself. I I got it running with like Express at one point, highly not recommended. It's it's bundler problems all the way down. So I.

• 23:16Scott Tolinski?

  Good luck with that. Yeah.

• 23:17Wes Bos?

  Yeah, yeah. It's a little bit of exhaustion on on some people's, I think, with with all of the different bundling and everything. And a lot of people want to get back to just standards. I'm somewhere in between where I I just want everything to work together. But then when it is too tight, sometimes you hit these these issues, you know, and and that's maybe my my next thing is like, why the hate? Why do some people not like, uh, React Server Components? Bundling complexity, probably, uh, a big one. Limitations. Um, there's no like explicit methods, you know, get, post, put, uh, middleware, all these

• 23:59Wes Bos?

  things. Like, these things are very simple with like a 10 stack start, where they're just not possible. Um, and if you build things in the React Server Component way, you're probably fine. But a lot of people have existing code. A lot of people want to do things in the way that they understand them. And if you just don't have those knobs to turn or, uh, in the React Server Component world.

• 24:23Scott Tolinski?

  Yeah. I mean, and in that case, I mean, it's still pretty much just. NextJS is the, doing it the, the way.

• 24:30Wes Bos?

  Yeah. And like NextJS has like a whole bunch of like weird limitations around Redux and cookies and what you're allowed to do here and there. And a lot of those, as I moved from Next to Waku, I realized that a lot of those limitations are not Next's fault. They are simply just because of limitations in streaming.

• 24:53Scott Tolinski?

  Oh, streaming.

• 24:54Wes Bos?

  And you, you simply cannot do things like set a cookie when you have already started streaming. A lot of that hate gets put on NextJS, also just because a lot of people weirdly hate React and Next in general. But there's that. And then there's also just like, NextJS is very opinionated about, about the way that they, they do things, right? And that's fine. You can use whatever it is that you want. A lot of people much prefer that because there's not as many foot guns of doing, doing potentially expensive things.

• 25:28Scott Tolinski?

  Yeah. I think another reason that people hate this is because there's just like a lack of parity amongst React frameworks, as we've talked about here. You aren't getting the, the same React in all of the frameworks. And so React Server Components, a React core feature is only available in NextJS and Waku and, you know, these, these kind of fragmented ways. So because of that, it is like fracturing the React landscape completely. There's no parity. You're not using React as a platform. You're using parts of React at any given, at any given point. And I think for me, the, the features that exist within RSC are all things that I would have said, yes, yes, give me that, give me that, give me that.

• 26:12Scott Tolinski?

  And now I'm like, oh, but not like this. Uh, you know, not like this. I would, I wanted these features, but, uh,

• 26:17Wes Bos?

  But my way.

• 26:18Scott Tolinski?

  Yeah.

• 26:19Wes Bos?

  And the hilarious thing about that is that React Server Components, if

• 26:25Wes Bos?

  The whole point of it is that there's not going to be a way to do it in every single framework. And like, I was able to move over 98% of my next JS code to Waku because it is a standard. But the frustration, like you said, is that all the, a lot of these routers and frameworks have not yet implemented them. So in an ideal world, we would all get along and, and we would all have a single way to do things like data fetching is now and like loading, those are now in React Core. How do you, how do you fetch data? How do you inject data into a component? How do you, how do you do caching? A lot of this stuff is built into

• 27:10Wes Bos?

  React Core, but it's not yet been implemented in all of the frameworks. So there's a lot of that frustration out there. You should be able to just npm install some random component and that component will bring your client side, your server side, your data fetching, it bring, it should, it should bring them all. And you don't have to worry about integrating into it. But we're not there just quite yet. It's been several years. I don't, I don't know that we will ever get there. I hope.

• 27:39Scott Tolinski?

  It's been too long is really what the answer is. It's been too long. Yeah. Bummer.

• 27:45Wes Bos?

  Yes. Last thing I want to say is, is React server components lock in. Cause you see, I see this a lot on the Next JS and React Reddit.

• 27:54Scott Tolinski?

  Yeah.

• 27:55Wes Bos?

  I don't think so, because most of my logic code moved from Catsby and moved to Next JS and moved to Waku because I try to keep everything as standard on server. And even things like the, the form actions API in React is built on thankfully a standard. And that's the, the form data API. So there is a little bit of like weird.

• 28:24Wes Bos?

  Code that needs to be written in some cases if you're moving some JavaScript from one to another, but it's no different than if you're moving Express Code to something standard as well. So I don't feel like it's a huge lock in. I feel like I could get out of this React Server Components in relatively quickly. I don't think I could get out of JSX very quickly. And people are going to be asking like, what about, why didn't you choose X, Y, and Z? Why don't you use Felt? I had no interest in rewriting all of my JSX into some other random templating language. I just wanted to move it over one to one, pass the data in that it needed, and those components stayed untouched.

• 29:04Scott Tolinski?

  Good. Yeah, well, I think that's a good update for people who are wondering what the status of this stuff is. It's really easy, like, to get into a time machine here, and now it's X amount of days from, you know, when they were first announced, and just wonder, hey, what is going on with that? I'm not using it, or I'm not using Next, what's the deal with that? So here's the status, that's where we're at today. And I gotta say, hopefully this list changes a little bit in six months, or else, I think, you know, I don't know, like, you could call React Server Components a failure at some point.

• 29:36Wes Bos?

  Yeah, I think if it's not picked up by React Writer and Tansack, or if it's like, if it doesn't have any more momentum in six months, a year from now, I think people will either, I don't know, maybe, maybe move to something else, or already, already starting to see that as well. Because like, it's not like React can like, oh, never mind, you know, like, they kind of, kind of bet the farm on this type of thing. So I still feel, feel good about it. But that's just me out of, out of one community. And I certainly would have not have expected the, it would take this long to implement, and we're still here five years in.

• 30:14Scott Tolinski?

  Yeah, I'm gonna disagree and say I don't feel good about it, not because I don't believe in the API, but I just think five years, and to have this be the result is not good. That's why I would say that.

• 30:27Wes Bos?

  All right. Thanks, everybody, so much for tuning in. We will catch you on Wednesday.

• 30:33Scott Tolinski?

  Peace.