JS News: New React & Svelte APIs, RSC Updates, Redwood and Storybook

Welcome to Syntax. We are in the nine hundreds. 901.

Idea. Yes. I guess if we did zero based indexing and normal based counting, 900 was officially entering the nine hundreds, but we're past that barrier Node. 100.

And guess what? There's been a massive amount of JavaScript news just a little bit ago. There's been all kinds of new updates to both React, Svelte, and all kinds of stuff. So we're gonna be talking about what's been going on in the web dev world from, new React APIs to new Svelte APIs, React Vercel components, Redwood JS storybook, and more. So JS always, my name is Scott Tolinski, and with me, as always is Wes Bos. What's up, Wes? Yeah.

It's so funny because the React Vercel component stuff. So we did a show saying, like, where Wes at with React server components? And we recorded it and went off. And, like, before it dropped, there was two major updates to to React Vercel components, which which quite honestly shakes up the whole story of of not a ton of people supporting it.

And this is like, ah, that always happens to us. Same with the the payment Node, we were talking about Stripe.

And, like, two days before the payment episode dropped, they announced that now you they charge you when somebody Yeah. Regardless of if you win a chargeback or not, they're still charging you $15, which is ridiculous. So there's always something new that that pops up, which is we we try to record them, like, a week, weekend ahead of Vance. It's not too far, but there's always something new popping up. Yeah. It's it's down Scott. And

even man, I just heard about another, like, payment system that I I hadn't really heard about.

It functions along the lines of, like, lemon squeezy or whatever where you are. Like, lemon squeezy is the merchant of record. Yeah. Yeah. I can even find it. Polar? Have you heard of Polar?

P o l a r? Yeah. .Sh.polar.sh.

I believe yeah. I believe I did see this, which is a payment infrastructure for the twenty first century, the modern way to sell your SaaS and digital products.

Alright. What's the pricing? Immediately, 4% plus 40 per transaction.

Immediately, I am out. Yeah.

That's the problem with with a lot of these things is you're not gonna get any cheaper than Stripe unless somebody literally builds another

payment processor. I think the benefit here is strictly that the they are the merchant of record. Right? You know? Like, that is the sell there. It's like, yes. You're paying, and now you don't have to deal with all kinds of complications. Well, lemon squeezy went up to, like, 10% or something like that. So, yes, if if you're looking for that, then, yeah, man, this is that's a that's a good deal.

Woof. Also also, big woof if, your site is not functioning well because you have no excuses for that, especially with something like Century out here in the world. Century can make sure your app is functioning great, whether that's your cron jobs, collecting user feedback, getting alerts for all kinds of things, or even uptime monitoring or, heck, if your pages are slow or fast. You get user misery score if they're buggy. You get access to all of the errors that are existing on your your site. In fact, there's always gonna be errors because, let's say, you know, we're not perfect. And, if you're not perfect like me, you'll want a tool like Sanity to make sure you can fix your issues.

So head on over to century.il/syntax.

Sign up and get two months for free. Use the coupon code Sanity treat, all lowercase, all one word.

This podcast presented by Sentry.

Alright. Let's get into it with the first item on the docket today, which was React released in a blog post about experimental features in React. Now he had heard that there was some stuff brewing on the animation side in React.

It was presented JS, like, no other framework has animation features quite like this. I don't know about that, but this has given you a nice smooth way of using view transitions in React JS well as another new API called activity. So let's talk about these these both.

First and foremost, these are experimental. So to use them, you have to opt into React at experimental.

But it brings through two new APIs for view transitions and one for rendering.

So view transition is a element that will wrap, I guess, a component that will wrap your components to make view transitions easier within React.

And then add a transition type JS a function that lets you, specify the the reason for a transition, just give you a little bit more control.

But if you haven't been using view transitions, they're a really well supported browser API that allows for awesome animation features transitioning in your app. And a lot of people get this wrong where they think it's just for when you change pages. But in reality, anytime you're doing any state change on your application, you can wrap it in a view transition, and it can either interpolate that transition or you can write custom CSS to do that transition.

It's just an incredible

API. I love this thing. Kind of like like a tween. You can tween between one state to a another. So if you can think of, yeah, there's a lot of things in CSS you can transition from, but if you literally wanted to transition from a dog to a Scott, you could. And and where that's really useful JS, like, you could do it with CSS grid if you're changing what the the grid looks like. You can do it for sliding panels back and forth when you're not necessarily changing the, the URL. There's there's a lot you can do within it. It's extremely powerful API.

All you really have to do is just say, like, start transition.

And then when the DOM is updated, the old DOM and the new DOM will just be tweened between each other and or the old element and the new element. Big fan. The best part about this API for me is that

by default, just by calling, you know, the start transition or in this case with React, by wrapping your, components in a view transition component.

Yeah. Just by doing that bit, you get a really basic fade animation, which honestly JS, like, such a great default functionality just to have a basic fade animation as being the default.

You don't even have to write anything other than, hey. Do this transition, and you get a fade. And then to get that tween, you do need to give your transition a name so that way it has, like, a name. Those are called shared element transitions because what you're doing is you're saying, hey. This one thing on the page is the same as this one thing on this other page, even if they're not the same. Yeah. But what they'll do is they'll tween between the two, and you, we're actually sharing our screen. So if you're watching on video, you can see exactly how that looks, within this animation and how you're able to do that.

In this React API, you're specifying a name with a unique identifier that's the same as a name with a unique identifier on the other, page or element. And in HTML CSS land, this is done with, CSS property. In this API, it's being done with a prop on the view transition.

Important to note as well that in order to trigger these, it doesn't just trigger on on any update.

You do have to fire off either a start transition, use deferred value, or a suspense that's resolving. So if you have a suspended component that's showing, like, a loader state and then it and then it resolves, it will transition between the two of those. So it's it's kinda nice. I I like that React seems to be putting a lot of these things in as first party implementations because that means that you don't have to bring in some some plug in for it. And then it but it also means that if you're using a third party component, those components can fire off transitions.

And then if you want to take advantage of those components that are are transitioning, then you can just wrap it in a, a view transition yourself. So I hope that this lands in stable,

but certainly go and try it for your application right now so we can get feedback on what the API looks like. Yeah. And it's neat too. There's also this add transition type function, which we mentioned, where you you can then basically say this this transition is a like, their example that they have here JS, like, let's say you navigate forward or navigate back. That way you can have, like, on Bos, when you click into something, it, like, moves over to the one side on in and then moves over to the other side on out. Right? Because you're then able to specify a specific animation for navigating forward or navigating backwards because you've now given that a name, and then you can write your custom CSS for each of those animations, which is is really great to have. That's a nice thing to have because it JS always kind of weird when you have just, like, the same animation on in and out, especially if that animation is like, let's zoom in. And now you're like, let's zoom in again on the way out. You know? So it's always, important to know, like, that that feels kind of natural in in the way you're doing it. Now the the one thing I wanna say is that the reason why this is necessary, if you're wondering why, it's mostly because of the virtual DOM. Right? Is that is that, like, why these are needed? Because in most of the DOM forward frameworks, you you just use the straight up JavaScript.

Is that accurate to say that, you think?

I don't think so. You think these are just helpers, really? You wanna be able to specify the the direction and name Wes what is happening. Because, like like, go to syntax.fm and show the, like, the number

that gets bigger and smaller as you click through. Well, that's a what's it called? That's a shared element transition,

which will those will always work forward and backwards no matter what. Oh, yeah. Yeah. I don't know if that if it's necessarily a I don't think it is something to do with the virtual DOM. Maybe it is. We'll have to we'll have to play with it. Yeah. I know. It's it's one of those things where,

my apologies, folks. My React my React is a little rusty. But I am stoked that these are in here specifically because this isn't gonna add a ton of JavaScript to your app to do these transitions. You're not having to add a library to do the interpolation between your elements. That's all being handled by the browser.

The amount of code here is simply just the the wrapping elements and the functions that you need here rather than anything to handle the animations themselves, which we gotta love. The next API that they introduced in this experimental, release here is the activity API. It's an it's another component.

And activity is kind of interesting because what it does is it basically allows you to prerender a component without having it be visible.

And it's interesting that there is a non boolean flag for this, which, David k Piano Scott be very stoked about this. He hates boolean APIs.

So it's basically an activity element with a mode prop, and that mode prop can either accept a visible or a hidden value Wes visible allows it to be just rendered as normally, where hidden is going to, keep the component unmounted, but, save its state and continue to render at a lower priority than anything visible on the screen. Basically, it's preheating your elements for you. So that way, if you have already loaded it, then it, like, kind of stays loaded. Or if you are going to load it, then that way, it's going to, like, make that transition for when it actually shows up to be, very fast. So, so it says that you could use the activity to save parts of the UI that the user isn't using or prerender parts that a user is likely to use next. Yeah. That for example, like like, maybe we should say, like, why would you possibly ever want this? So if if you have, like, tabs

and you wanna be able to hide and show content, you kinda have two options. First, you can just not render them.

Yeah. And then when somebody clicks a button, you can go ahead and and render those. And then the other option is you can simply just hide them with CSS, and that might also not be what you want.

You might want to because if you're hiding them with CSS, you may not be getting all all of the benefits, and you also are firing off things like effects, which you might not want because you you want your effect to run when the component is is mounted.

Right? But if you're prerendering it, should it should it also run the effect? Maybe, maybe not. Depends. Right? If you're, like, auto playing some some video, you probably don't want that.

Wes, this is it does not, by the way. The activity Yes. It does not. Yeah. It does not. Do that type of thing. So this this is

the ability to, like, I guess, a third way, to get in there. Mhmm. And it also is more performant, so I guess React will figure out, it'll deprioritize the the rendering.

So I Yeah. I don't know. Like, I I guess if you have something that is absolutely massive and and does take quite a bit of rendering, this could certainly speed you up. But, like, I don't know that

I have a ton of parts in my application that are are, like, sluggish enough that I would need to do something like this. But, certainly, there there can be Here's a very practical use case here. In the React blog post, they did a really good job of kind of saying, here's a really interesting use case for this, why you might want this. So they have a listing page. On that listing page is a search box, and then there's a detail page. Right? They're using the view transitions to show a detail page. These are completely separate components. So this is a different component, and this is a different component.

And what you do is let's say I type in in the search bar first, and then I transition to the last or to the detailed page. Now keep in mind, the listing page is now unmounted or it's not visible. Right? But it is wrapped in an activity, so the state is preserved. So when I go back, the state is preserved, and the search box that's there still has the value. Yeah. So it's like maintaining that state that the user had. In in my view, this is a great user experience, and, like, one of those things that will drive you absolutely nuts if you're using an app. Now that said, there's tons of other ways to get by this by, one, having the search box outside

of that, like, in the layout. When you have to, like, change it or you have to use, like, an external state management that, like, maintains it.

Yeah. You're right. Vercel state regardless.

But, hey, this is this is not bad. And and and I think this will make many React apps feel nicer if people actually use it. So Totally. Plus, like, there's that again, there's that benefit of

you can use a component that you can npm install it, and that component doesn't necessarily need to know about what your state management is, in order to maintain that type of thing. Because all of these updates are, like, really nice. We're just adding more features in. Same with React Vercel Components. It's standardizing these features so that, hopefully, one day Wes get to a point where the interop between all of these, third party components will be much nicer.

Yeah. Pretty sick. Big fan of this.

Shout out to the React team. I think these are some great little, updates here. Kind of on the same idea here, we have a proposal

in Svelte. Maybe not even a proposal. There's it's certainly a lot of it has been Node as well as the idea of asynchronous Svelte.

And this is actually kind of exciting. We've talked about this quite a bit where I said my one gripe with Svelte is that you can't load your data at a component level. You always have to do it Yeah. Yeah. In you always have to do it at, like, a page level. Right? And this, I believe I'll I'll let Scott take it from here as he's a bit more of the Svelte guy, but this, I think, will solve that one of my main gripes with Svelte. Yeah. It will absolutely solve that because

this isn't saying anything about SvelteKit here. This is a Svelte API. So this is not tied to the meta framework. This is tied to the actual, like, front end framework. And it basically is just like, oh, yeah. If you use this new version of Svelte with async enabled, you can now use the await keyword inside of the script tag at the top of a Svelte component inside of a derived, which is just like a way to derive state from other states ESLint in your, markup in general. It it it's actually wait inside the template tag, which is wild. It's wild. So this is Svelte's answer to react suspense, to suspense in solid, to suspense in view. And, they're not they're not calling it suspense, which is which is fine by me because I don't like, we already have words for, like, for suspending like, it's a async await or async or whatever people on YouTube say we're saying it wrong. You know what? That's gotta be one of the most confusing comments we get often is async or us I don't even know what these people are saying. Like, which one is the right one and which is the wrong one? They're all fine. Async, async, it's the exact same. It's there's such no difference between those two words. That's such a, like, a regional pronunciation thing, but people are like, you're saying it wrong. Like, what? What are you talking about?

But, like, the idea here is that you can have a component that has some asynchronous work in it, whether that is something that fetches data, whether that's something that just takes a little bit of time to compute.

You'll be able to wrap a boundary around those components and show a, like, a, like, a loading or or pending state, right, or a suspended state as the rest of us would understand it. Yeah.

So I'm scrolling all over this blog post. But, yes, there is a I'm trying to find the boundary specifically. Yeah. There's a a new Svelte boundary because Svelte uses boundary for, like, errors and things like that, but you can now use pending inside of Svelte boundary to have it when it is loading. I do find this to be really wild where you can, yeah, you can just straight up await inside of your template tags, like await preload for an image, await on a function inside of a list item here in a template tag. It all looks nice. And I gotta say, the cool thing that I do love about this framework and one of the reasons why I am such a diehard fanboy of this framework is when you look at the requirements, section here, the very first one, minimal ceremony. We just wanna write code using the await keyword. Avoid framework specific APIs and idioms to the extent I gotta tell you, Wes, like, React introduced their suspense, they, had start transition, use transition, all this stuff. And I I get the functionality behind that. Yeah. But, like, there's all these names now. Like and and you have to know that transition in a start transition for suspense, not related to view transitions, which is another thing they just added. So it's like, alright. Now we have view transitions. Can be.

But they can be. But, inherently, they're they're they're not specifically. So start transition, use transition, suspense, like, all these words

are just there to replace words that we already had, which I don't know. It's fine. It's fine for me, but, like, I like that there is minimal Sounds like it's not fine for you, Scott. It sounds like it's not. But no. I agree. I agree as well. Like, there's a lot of the React stuff is like, oh, it's it's kinda like this, but there's there's some gotchas.

Yes. And you can't do x, y, and z. But, like, Svelte Wes like, no. We just we just wanna be able to put in a weight inside of a component. TypeScript tag and component. Yeah. All that stuff. Component has a a boundary around it at a higher level, then you can access that with a pending a new pending state, and you can show if it is pending. And then there's a whole bunch of work around doing stuff concurrently, which is really important because, like, whenever I talk about, like, I just wanna do my data fetching in the component, everybody comes out and says, well, that's how you get waterfalls. Right. Meaning that you have you have one component, that component loads. Oh, that component needs data. It goes off, fetches data, comes back. Oh, the data comes back. Now it needs to that needs to render another one, and then that component loads, and that needs to go do something. Right? And then you get these these crazy waterfalls where one thing triggers another, which is why a lot of these frameworks have, like, sort of hard armed us into, no. No. No. No. Do your do your data fetching and loaders at a page level So at least when you load a page, you can understand what's going on there. So they will do as much work as possible, with concurrency.

This I think in every framework, this can be a bit of a foot gun. You just have to be cognizant that you could possibly cause some performance issues with your your application.

Yeah. I I agree. I do I'm I'm just stoked to see this in here, and and I I think there is some discussion whether or not they will eventually need some API for orchestrating things like start transition. So, you know, maybe I'm speaking a little too soon on some of that stuff. But in the same regard, I think it's going to have better default so you don't have to use those things. It is it does say parallel by default, since expressions in a template can be safely assumed to be pure, sequential await expressions need not result in sequential async work. Similarly, asynchronous work in two sibling components should happen simultaneously.

So because they're a compiler, I think they can you know, you can just write your code as you would wanna write it and not have to worry too much about that. But, again, it seems like if you're deriving a value that's awaiting on a derived value that's awaiting on a derived value,

I think there's no way to avoid a a waterfall in that way. One thing I did not see in here is anything about, like, form actions, meaning being able to call server functions from the client.

Mhmm. I don't know. Is that going to be something that that is is worked in here? Because, again, right now, another thing you have to do is you have to put all of your actions at a page level, which makes makes no sense to me because your action is almost always tied to the component. Like, what does this thing do when it is clicked or submitted or whatever? I shouldn't have to, like, put that on the page where whatever page it's going to live in. I just wanna be able to pop a newsletter subscription function

on the component and for it to just work. I I I actually agree. And it does say very specifically that, like, they would like to use this API to replace things like all data loading within SvelteKit.

Mhmm. Basically, today, we cannot reuse much code between server and client portions of SvelteKit. We rely on a lot of virtual models and generated code, for historical reasons. But, basically, it's saying it's plausible. There's a lot of new interesting possibilities.

We find ourselves drifting away from primitives like load, which I would assume that would also entail things like actions considering that's the same concept of having to go to the server for Yeah. Data.

So that's under the improving SvelteKit part of things Wes, basically, you'd have to assume that this eventually would lead to better communication API. Yeah. The client and the server now that we don't have to yeah. Like, now that, yeah, you wouldn't be beholden necessarily to having it at a page level. So pretty dope. There's a little playground where you can go and test it out today. You can give feedback.

There is a branch you can try it on, but they Yarn, almost a lot of discussion around it whether or not you need things like start transition, etcetera, etcetera.

But, pretty dope. I'm, I'm stoked for this one. Can't wait. Next up, we have Parcel,

announced React Vercel component in beta. I knew that they were working on this, and I forgot to mention it in the React server components, but there was really nothing that you could could use. But now, it's in beta.

And this is kind of exciting because the thing about doing React server components is, like, your both your client and your server needs to know about your entire application, and you need something that can, like, transpile JSX and on the server.

So if your server is is written in in Deno or Express or or whatever, you need some sort of integration to that to sort of mate them together.

So Vercel released React Server component support. It's both a package you could just import on your server as well as part of the bundler.

And this is pretty exciting. It's just another good example of someone that can use React Vercel components. I think this is gonna be big for anybody that's on an existing stack that doesn't necessarily want you can't move to Next. Js. You can't move your entire application Next. Js, but you wanna use React Vercel components.

There's not a great option for that right Node. So I think that this is going to really improve things.

Yeah. Yeah. That we had a lot of people, mention Parcel with React Vercel Components when we dropped our React Server Components episode, which I I've always loved Parcel. So to hear that there's been, like, so many people being like, Parcel, that makes me feel good. I like that. Shout out to Vercel. Devin Totally. Knows everybody at Parcel. If there's is there anybody else at Parcel other than Devon? Just Devin. Devin holds up, like, 80% of the React ecosystem with, he's got Parcel and Lightning CSS?

Lightning CSS and React, Aria, and, man, all the way down. Yeah. I love it. What a guy. And then, like, a day or two later, Redwood. So Redwood is or was a kind of like a full stack framework for building applications in Node. Js and React with with GraphQL.

So it had, like, like, an ORM. And, basically, every all the time we're asking, like, where's the Laravel for for JavaScript? And and everybody says, Redwood is that? Redwood is that. Right? And then it looks like they're taking a bit of a pivot away from that. I think that it's over the years, it never really got much uptake, unfortunately.

And they've announced that Redwood is now Redwood GraphQL.

So they've sort of moved the existing you built your app on it to Redwood GraphQL with all the ORM.

And now Redwood SDK

Mhmm.

Is being branded as a React framework for CloudFlare, which is absolutely a wild pivot and something I'm I'm honestly quite excited about. So what it is is a Vite plug in that allows you to use React Vercel components and form actions and and all of the stuff that we know about React server components. It allows you to use it with Vite, and it's sort of, like, tuned for deploying to to Cloudflare. So you get tight integration with, d one, which is their database. You don't have to use these things, by the way.

This is just a it's sort of like I I think maybe that was the problem with the original Redwood is that they're very prescriptive.

And as much as we say we want to we want things to be prescriptive, we want it to be the way that we want it. Yeah. So this is just like can't. Yes. So by default, you can get d one and r two, which is things for, like, hosting, like, like, files, images, stuff like that, durable objects, queues, has middleware, has some auth stuff built in, but it is just a Vercel plug in with Wrangler installed by default. And and then the v the vite plug in is is probably the most impressive part because doing React Vercel components with Vite is not not easy. I think I think Waco JS the only other one at the time that that does this. Waku. So this is kind of exciting. Waku. I can't say it wrong every single time.

Async. Async.

Waku. Waku. Yeah. So this is cool. I think, I don't know.

I think it was it's a interesting pivot, and it's also just, like, another huge win for

Vite as well. How many wins can they stack up for real? Publishing React to

Cloudflare JS, is getting easier and easier. Because, like, I've I've gone through the whole gamut of it. Right? I I did Next. Js on pages, then they moved it to open Next. Js for CloudFlare, which is using Next. Js on CloudFlare workers. It's pretty good, but still a little bit of a pain. They're literally just monkey patching the Next. Js Webpack output, which is that's that's a whole thing. And then I moved to Wacko, which is a multiple Vite builds.

And now we have this this Redwood, which is I'm assuming it's using the environment API in Vite, which is new, to do both server and client Vite. Cool. Pretty sweet. Yes. Yeah.

The last one that we're gonna be talking about today is that storybook nine entered beta in April 24.

And we started using Storybook on the new Syntax site, which there's you know, Storybook is interesting

because it does everything in an iframe, you know, if your components were lying. So can you explain what Storybook is for, real quick, for anyone who hasn't heard it?

Storybook is a place to, develop your components in isolation, which allows you to essentially render an individual or even, like, chain of components and then pass in mocked data.

And, therefore, you can build your component in a little sandbox where you can make sure that this thing will fit all the specifications, and then you can change it with different data, see how it reacts, longer titles, longer this, change the image, all that stuff.

And you can build out your entire component library outside of the bigger application.

So that way, when you dump your stuff in the bigger application, it you're playing with Legos. Right? Which is a great way. Because sometimes when we're working in a bigger project or project in general, we can build things that are really, like, tightly coupled. One, but two, like tightly coupled? Yeah. Possibly re be relying on stuff outside of here or stuff outside of here, and you might not recognize it until you're trying to use these things more flexibly.

So, flexibly, flex I don't even know if that's a word.

With flex. Yeah. So storybook nine has a number of really enticing updates. So I'll be updating to this because I'm a beta user all the time.

But what does this add? It adds component Wes.

Well, what JS component Wes, which I don't even know what that is. It adds interaction testing, accessibility testing, visual testing, test coverage in general. It's a 48% lighter bundle, tag based organization, and React native, support.

So oh, the testing widget is basically one that lets you run your test. It's a widget for running tests. But the thing I like most about this testing feature so you can have your integration tests inside of Storybook now in a visual manner a la Cypress or

was it Playwright is the other one? Yeah. Yeah. Play Playwright so Playwright is, like, both like a headless browser, like puppeteer, but then it also has some utilities for running your tests, either headful or headless.

Yes. Okay.

So we have that. We have accessibility testing, which is a perfect fit for something like this. It now will complain, about accessibility issues within your components, which Scott love that. Anything we can especially when you're there building. Right? It's always great to, one thing I really like about the Polypane browser is it's just there when you're building. So to have this here Wes you're building, if you're building in Storybook, really nice.

Visual ESLint. You can now visual visual regression test to make sure that your components, don't get like, let's say I changed some global CSS here, and it now affects a component here in a negative way, you're gonna be alerted to that with a visual regression test. I gotta say, visual regression testing is one of those things that I've always looked at as being way more pain than it's worth. But if you can have it within isolation, to me, that makes so much more sense because you have a page, you have an individual component, whatever, on a page.

All of those things change all the time. Right? But when you have these things in micro isolation with sandbox data or or with mocked data, it shouldn't change unless you know it's gonna change. So the fact that you have so much control over all the information coming in and all that stuff means that, like, I now could be confident if this is visual visually saying, hey. Something goofed up here, that it's actually worth my time. So visual regression testing, I've never been a fan. I'm gonna use it. I'm gonna I'm gonna straight up use it. Yeah. That's nicer to do, I think, at a component level

than like, in the past, I've used it on, like, an entire page.

And there's just so many things that could possibly nudge it left or right. You Node little browser quirks or a little piece of text that is longer than the other, and it is just like a too much of a pain. Too many, like, false positives. Right? But I could imagine as part of your, like, component Wes. Right? Your components should not change anything about how they look unless you explicitly approve that. So I think that's great.

Yeah. I'm gonna use it. I never thought I would say I would use visual regression testing, but we will add it. There's also a test coverage screen now so you can see which components are tested and how much of these components have test coverage. Test coverage to me is one of those things that it's nice to have, but, like, I don't know if I need it, but it's nice to have. I think one of the coolest things about this update for me is this 48% lighter, but it's not just that it's a little smaller in size. They have an image, and we're sharing our screen here, of the dependency graph before and after.

And some of this has just been, like, a result of the ecosystem building packages that reference packages that reference packages, etcetera, until, you you know, you're using an is even package somewhere.

And there's been a bit of a, a resurgence in, like, using packages that have no dependencies or small dependency graphs.

And I gotta say, if you're comparing these two dependency graphs that I'm showing on the screen right now, nothing makes me happier than this. I am a spring cleaning kinda guy. I love picking up the stuff and putting it in where it should go. And,

look at this and look at that. Yeah. I wanna know what they actually did, though. Like, what

a bit of a threat on on Twitter. I think I think some of it is is replacing common packages that had many dependencies with packages that, again, are are primarily built to be a single

dependency package. Did they just bundle it into a a single package?

There there's been a huge push for that in the the Svelte ecosystem as Wes, where they've been, like, rewriting common packages to use no dependencies.

Yeah. So there has been a bit of a a push in in my ecosystem.

As well. Yeah.

Lastly here well, not lastly. There's two more things. The tag based organization, you can now tag your stuff and filter by those tags. Just a quality of life thing. And then React Native support.

Cool. I'm not using React Native, but happy these folks have, React Native support inside of, Storybook.

So shout out to all the teams releasing cool stuff. This is all great. I don't nothing to complain about here. I think Yeah. If the thing I complain about the most is naming of React APIs, then that's pretty good.

I'm gonna do that anyway. So Yeah. Yeah. That's great. Awesome. Yeah. Tons of stuff. Tons of new updates. We haven't really done, like, a news show very often, but it feels like just the the updates just keep on coming. And it's it's fun to be able to talk about what's been going on. Let us know down below in the comments if you have any thoughts on any of this stuff, if you're gonna be using any of it, especially the React Vercel components. I'd love to hear your thoughts on that.

Yeah.

We'll catch you next