Astro 3.0 === [00:00:00] PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. Try it free at logrocket. com. I'm Chris, and today we're excited to have Matthew Phillips, co creator of Astro, and Ben Holmes, Astro team. Here today, we're going to talk about Astro 3. 0. So welcome to the podcast. Hello, thanks for having us. So before we get into the newest features of Astro 3. 0, Can you tell us each a little bit about yourself, I'm Ben, I am a core maintainer at Astro, also a full time staffed person. Have to say that because no one really knows that open source can be this full time job. I'm also terminally on X slash Twitter. Whatever you call it. I do whiteboarding content to explain popular web development concepts including Astro and React server components So if you see a guy with a whiteboard, it might be me. Wow, Ben, I like how you just claimed whiteboards for yourself. Actually, I'm not surprised by that at all. A vertical[00:01:00] But you should have said, I'm Ben and I am too online because that's the way I think of you sometimes. all right. yeah. Hi I, am Matthew Phillips. I am also a core member of the Astro team. I also am a staff at staff. There as well. I am the manager of the platform team where the team is primarily responsible for the open source Astro product. And yes, that is me. Awesome. So we've said the word Astro, but can you, either one of you give us a brief history of what exactly Astro is? Sure, I can jump in here. Um, Astro. It is a web app. I almost said it's a static site generator. I just instinct instinctively say that Astro started out as a static site generator so a way to You know, build a website using, markdown HTML pieces and building static HTML, CSS, JavaScript from that to what your site, that's what it started out with, but we've evolved over time and now [00:02:00] we're a full stack framework back end oriented, but a full stack framework. Interesting. So let's kind of dive into like 3. 0. So I know, I feel like not too long ago, we just had a 2. 0 release from you. At least for me, it just felt like it wasn't like too long ago. So I'm super excited for 3. 0. But like, let's talk about some of the top features, like you're really excited about. Yeah, for me, it's easily the view transitions feature I'm not gonna claim it because Matthew's actually the one who got to build it but I've been demoing it every chance that I have because it answers some pretty fundamental questions with Astro Up until now, it's been focused on generating each page separately. So if you've heard multi page app or just how the web was, that's pretty much what Astro does. It outputs a bunch of separate HTML pages or separate endpoints with SSR. But if you wanted to share state between pages, maybe have a media component that stays on the screen while you route around, or you want to, have a snappy transition without a page refresh, That wasn't possible. And now both those things I described [00:03:00] are baked into Astro 3. 0 should be stable from 1. 0. And it's all possible. Thanks to a cool API from Chrome called view transitions as well. We have some polyfill, so it works in any browser, but that was the inspiration for it. And it's the one, a lot of people are really excited about. So like, in my opinion like, or like my perspective was the major. Like backlash against MPA versus like SPA was like the refresh between like page navigations is, does it like, so I haven't personally used the view transitions API. Is it now that it gives you that seamless, like client side navigation. So you persist that state across routes. Yeah. We might want to start, I don't know if your audience is probably very technical. They probably know about these things, but. It might be good just to define what a view transition actually is at like its core. So a way I would, I've been thinking about it. I didn't actually know this at first when I first started working on all this stuff. I was like, Oh yeah, view transitions. It's a way to animate between pages. That's the primary use case, but really what a view transition [00:04:00] is that kind of at the core of it is it's a way it's a browser API. To say to tell the browser, Hey, I'm going to make some changes to the Dom. I want you to take a screenshot of the current state. I'll make some changes. And then when I'm done, I want you to animate between those two states. So if you think about it like that, it's not actually about page navigations. Like you could use it for anything. And there's actually some people doing some really cool demos out there. I don't know if you've seen that they really have nothing to do with. With page navigation, literally, like I've seen demos where, you know, you reorder a list, you sort a list, and then inside the view transition, you get this really cool animation just automatically, without you writing, having to write any CSS code yourself. So, yeah, that is actually what a view transition is. Now, obviously the, the biggest use case, and the one that we're, Focused on right now is page navigations. So yeah, answer your question Yeah, what is the whole spa versus mpa debate? Like we can go into this it'd be fun to talk [00:05:00] about but I don't know if really animations was really the thing but That is what we've taken from it. Ben. What are your thoughts? Yeah, I actually did join a Twitter space called rspasdead, just as a very flashy title. But when you get into it, they are doing two different things. So, if you think about why do you use a spa? Why did they ever get in fashion back with, React in 2015, other frameworks before that? It was really because you wanted to have state. On the client side, not on the server side, not involving user sessions, maybe. And you want that to remain while you route around the website. Maybe you have a config based router, like react router in order to hot swap components without hot swapping the entire page or reloading entire style sheets. All of that is doable when you use JavaScript to drive all of the route changes. But when you bring in view transitions, it. On [00:06:00] its own, doesn't address sharing state. It's just animating, as Matthew said, a snapshot of the old to the new. So it's really like a frame or motion replacement, when you look at it that way, and it makes animations that were previously really hard, suddenly stupidly easy. So I'm hoping it just makes the web feel more interactive on its own. Like mobile apps that grow and shrink navigation bars when you click into, like an album title, for example, the album grows really big. All of those native transitions that even spas didn't help with are pretty possible with Vue Transitions now. There's that other part about state that we're solving separately, but Vue Transitions help us. I honestly don't know how it works under the hood, but we do have a separate directive called persist that can trace that navigation from one page to another, but also lets you keep a component on the page when it hot swaps. So that's a bit of added JavaScript, but it's a new way of thinking about, okay, I have this component. I want it to be the same component when I go from the home page to the album viewer. It's the media [00:07:00] player, it's the whatever that has client state. And I want to preserve that component between that previous page and the new page, and also animate in the contents. So now it's tackling both animations and client side state, which are two really big things that usually use JavaScript, or heavy JavaScript before. Now it's very lightweight JavaScript. So it helps. Each of those features helps each other out and it means you can build websites in a kind of new way that isn't driven by spa routing at all. It's just this new JavaScript driven thing, like turbo links if you've ever heard of those, but it's really its own beast. It's thinking about it in a different way. I think that it's interesting subject because Client side routing there's several different reasons why you might want to do client side routing. And, Ben brought up a really great one, which is, I want to keep some state around. There's no way to do that when there's a full page navigation. There's also this UX thing that [00:08:00] people have always had an issue with full page transitions. It's actually changed over time, which is interesting. It used to be when you clicked on a link, just a regular link, no cloud side routing, like the screen would go white. Like it really stopped displaying the current screen. You'd see a flash of white when the new one would show up. And the browsers have actually improved the UX of navigation on their own without any APIs necessary. So today, if you just look at like an astro site that's an MPA, you click on a link in Chrome, for example, there is no flash of white. Like they've already gotten rid of that. It's already a nice transition, if you will. Between the pages. So what we're really, what we're really focused on view transitions is, yeah, what are those things that you can't do just with regular NPAs? Well, you can't animate between them currently, you can't persist state. So those types of things are where we see ourselves fitting in. Awesome. Yeah, I saw a bunch of demos online about the view transitions and I was really. Surprise on how easy it looked to implement these [00:09:00] things into the framework. I'm not sure if it was you, Ben, but I saw someone do some demo and it was like. literally only a couple of lines of code, maybe just like tagging certain elements to transition during like navigation and then just did its thing. So, I'm excited to try to play with that stuff. But yeah, so next let's talk about the react direct fast refresh support. This one's this is something I'm really excited about for Astra. Yeah, Ben you probably know more. I can explain how it works, but you probably know more about what fast refresh is and like what the benefits are. Yeah. First off, we have it and we didn't before. So of course it's better. And if you don't know what fast refresh is, well, when you hear fast, you think, okay, it must be an improvement, but it's something that all of the frameworks have their own implementation of, if you have. built an interactive app, maybe with Next. js or Vite with React. You are editing other parts of the page, like you're editing the navigation bar. But you have some state inside of those [00:10:00] components that you want to stick around. Again, we're talking about state here. But this is like the development experience of it, where, you have a request from the server and that is persisting a live video feed if you're building like a video chat app. And every time you edit little parts of the UI, you don't want the whole video chat and socket to reload just so you can see your Tailwind styles. Like, all of that stuff should happen around it, but the state that's persisting or whatever connections you have should stick around and not change. So that's what was actually in Astro Pre 1. 0. Caused a really turbulent beta period where a lot of things didn't work how you expected, like we fix one bug, two more appear. So we said, alright, MVP, we're going to strip out fast refresh and just do it for styles in a couple isolated cases. And now we've finally revisited the problem, because people are building more and more interactive things with Astro than they used to. So we thought, alright, now's the time to go back to fast refresh. And we're built on top of the VEET bundle, or if you've ever heard of it. So we wanted to dig [00:11:00] into, what are the defaults for React and VEET? Can we just bring those into Astral wholesale and restructure some things? I'll let Matthew get into details. I'm just going off of what I know. But, what those added, now you get the same refresh experience you might expect from VEET with React. And honestly a faster experience than like the app directory on Webpack, which has been in an interesting phase right now. I love Vite and the fact that we can leverage that, so you can build apps a little bit faster than you might be used to. Oh, that's spicy. I I didn't know about that. Okay. Yeah. So the backstory here is interesting. When we first started Astro, we were, I don't want to say the first, but we were one of the very few frameworks that allowed backend frameworks that allowed you to use multiple different types of component frameworks in the same app. What that means is that in Astro, you can use react, you can use felt, you can use view all in the same app, whether you should or not. That is an open. Debate, but you can do that. And we actually went a step further, which is, you can actually use multiple [00:12:00] JSX frameworks within an Astro app. You can use Preact solid and react all at the same time. And that, when we built this, that was a very unusual thing to do. The plugins around those things were not really designed with that in mind and so they clash with each other. And so we had to write a bunch of custom code to make it possible essentially. And yeah like Ben said, we, at one point we did have it in there, but because of this problem, we had to refactor everything to make everything compatible. But over time, these the base plugins have gotten much, much better. And now they have a way where you can say like in each of them, only build these certain files, you can give it a glob of all your React components, or a glob of all your Solid components, etc. And they don't clash with each other anymore, and that allowed us to just use the base uh, Vt plug in. So now we use Vt plug in React, Vt plug in Solid, etc. There's very little of our custom stuff on top of it at all. And yeah, so we get great stuff like [00:13:00] React, Fast Refresh Preact has their own version of this called Prefresh, I think. And yeah, other, I'm not sure if Solid has this or not, but yeah, Awesome. So, so we talked about the react fast refresh support. We talked about view transitions. Is there any other features that you'd like to highlight? I think I saw something about the image component becoming stable in this. Is that something you wanted to touch on or yeah, we can, absolutely. Yeah, Image Component, it's funny because the way that we kind of design things in Astro, is we very much believe in like release early and often. So we'll release things. We mark them as experimental, which basically means, Hey, we're just throwing this idea out there. This is vaguely what we think is going to happen, but we're going to keep iterating on it. So because we do that, it feels like image component is old news, but it's just now stable. So we originally released this, I think in 2. 1. And it's a, it's an image component. We had an integration before that, but now it's built in. So it [00:14:00] has support for things like mark and markdown. Those images are automatically optimized. we have good integration with content collections. Content collections is the way in Astro, how you organize your content. So what you can do, you do cool things. Like you can say. You can define a front matter property as being an image and that will not only be optimized, but also you can specify what dimensions it should be. So, if you upload an image that has the wrong dimensions, you get a nice little error message in your editor. Yeah, the image component is wonderful. Ben, feel free to chime Yeah. The image component has a funny history too, because when you build an experimental feature, and it's really good, People use it in production, and treat it like a production tool, and honestly forget that it's experimental. That's what happened at first. We had an integration that was pre 1. 0, but it hit some more fundamental problems with how it was designed, and led to a lot of bugs, of course. So we overhauled it, did it a much different way. That's also familiar [00:15:00] to you if you've used Next. js image. Definitely an inspiration for the properties that we support on our image component, though we do add a couple more goodies to it. And, yeah, it's really nice that it's built into content formats, because Astro's mostly built for those kinds of content sites. And if you're using MDX, MarkDoc, which is close to my heart, but no one knows what it is, and Markdown, all of those will support image optimization without having to use the image component. But also if you're using MDX, you can import the image component and have really fine grained control over, the width and height and loading strategies if you want to tweak those. So you have the option to both use like the markdown syntax and also the big boy component if you need to do something really specific. So it's nice that all of those work and you don't have to set up a million MDX plugins to hotwire the image into it. It's just built into all the formats, and now you don't even need a flag to use it. So, it's pretty, it's a no brainer to reach for image just to [00:16:00] optimize everything you have. In fact, I think we do it automatically for Markdown specifically, if you're using like relative image paths that are next to the Markdown file. Oh, Yeah, another thing we have is it's a low level API. You can define your own image service. And we actually have a, in our Vercel adapter, there's a way to just enable Vercel. Vercel has their own image service, and there's a thousand ways you can customize things there. So if you want to, in production, deploy your Astro site and use Vercel's image service, you can very easily do that sort of thing. that's awesome, we added that. I didn't know we had. Because they have their own specific image optimizer, right? just out of the --- box. Yeah. Another, Another thing worth 3. 0, the new default is to use sharp. But sharp is the best in class image optimization library. Previously we were using Squoosh, but Squoosh is I think they've deprecated their JavaScript API and sharp is really well supported now. I just saw that stack blitz support sharp natively as well. Which is really [00:17:00] cool. So, yeah, that's a really nice change. Awesome. So as far as all the features that go into Astro 3. 0, like, how do you as a whole, decide which features to focus on for this release? Like how's that decision process happen? Well, we have a roadmap process, which we follow. So. We have, it's an RFC process. This is maybe a little boring for some people, but people from the community go to that, add their ideas, we refine them. Eventually we do like a, we do some planning sessions around Hey, well, what do we want to launch for like the next release? And we grabbed stuff from the roadmap and decided to really focus on that. Our process tends to be. Especially on, I would say bigger projects, things like images, things like view transitions. I know when we started on view transitions, we were like, this feels like the right way to go, but I don't know, like it could be wrong. I really just want to get something [00:18:00] out there and let the user try it out. So like the initial version of view transitions, like the router had all kinds of crazy bugs. It was and I think actually Ben on his stream encountered some of these things. So. We release very early and often, so we'll flag things as experimental and keep iterating on them and getting feedback. But yeah, as far as how we plan things we really go to that roadmap. Do you all ever like pivot based on like community feedback from like an RFC or anything, or like completely switch, like which feature you want to release and go to some other feature? Is that like a common scenario? Not really. Well, Ben, what are a few thoughts here? I think that we have definitely have done it in the past. Vue Transition is a great example, actually. I know that, we've been thinking about a few transitions probably, I don't know, going back a year, like we saw early demos. We're like, Oh, this is really cool. This seems like a great fit for an MPA thing. But we were like, okay, well, it's going to take a while for this to really be ready. So we'll let's do our own client [00:19:00] side running thing. And so we started with some very different APIs. That we were thinking about, there was some crazy ideas out there for that. And we didn't really feel great about it. And we saw that, people in the community were using view transitions doing these crazy demos. And they weren't like, they didn't use us. We didn't, we weren't helping them at all on that. They were just doing really cool stuff. And we're like, Oh, actually we need to pivot and make our API be focused around this. So that's one example where this, where that's definitely happened. Yeah, and it's nice because of the RFC process being multi, multistage. It starts with a casual GitHub discussion about here's the problem I want to solve. No code at all, just this is a thing and here's the user need. And then we start doing examples later on. So that way. We've never had a roadmap item that was high priority and then get kicked back because usually from the discussions we know, okay, these are the most important things based on upvotes, based on need [00:20:00] from, other partners or headless CMSs. Based on that, we can figure out the problem and the only part to pivot is the solution that we're working on. And Vue Transitions is probably the most turbulent one there, where Nate Moore back in last year, like March of last year, had a proposal for SPAs that didn't quite gel with what we wanted. Then we talked about weird layout conventions and nested layouts. Then we realized, God, those are complicated. I love that Astro doesn't have them, so let's not. And then we walked to Vue Transitions after a certain amount of time. So, yeah, I think it is really approachable in that way, where if you don't want to work on a solution, you have a problem that you could, defend and have strong use cases, any community person could just walk in and make a proposal. That happened for middleware, actually. There were a few champions for that. One of them was Pilkrow recently, where he thought of a new middleware idea, reignited an old discussion, then we brought in Emma, a new team member at the time, and he [00:21:00] was able to bring it to the finish line. So if you have a, thought about Astro features, just start a discussion and you can pick it up yourself and drive it, or just let it be voted on by the community and get legs if you don't want. Content collection is a little bit like that too, right? I remember the early stuff you were working on. Did you have data collections as an idea in there somewhere? It's a pretty common thing that we do is that we start off we start off with one idea and we're like, we do like, all right, let's punt on this. So data collections is something that has come to Astro, just with the last few months. Yeah. 0 thing. That was just casually thrown in a minor release as stable at one point. But that was like a, that was a scope creep moment. Where we release content collections, way to organize your markdown. And there's so many other things we want to add. People are going full blown. Can this be a SQL query editor that just lets you query for content with SQL queries? And we're like, slow down. We'll let you just map [00:22:00] and filter. And that's I still want that. We still want it. And we're still thinking about it, but there were other things like being able to reference one collection from another not full blown sequel But just a way to say this is the name of the file I want to pull in all the author information from this file into this other Markdown file so I don't have to copy paste front matter everywhere for the author profile picture or something So I was like, alright sequel inspired scoped down version of it. We could do with today's tech So let's make that its own minor release later on and it's been going really well I'm not tagged in any bug reports, so I think I did it right. But yeah it's nice going through the review process so you can figure out what to cut out and just do it separately. Awesome. So I have a scenario for you both. I'm an Astro 2. 0, I'm an Astro 2. 0 user, and everyone knows that bumping like major versions is, could be a pain, right? So one, so first part is, I want you to tell me what are the benefits [00:23:00] of me upgrading 3. 0? And then further, are there breaking changes? And how do I migrate to this new version? Yeah. Well, you should do it. Please upgrade. Is That's it. We're done. Yeah --- Um, no, I mean, think more than anything, the benefits of the, of all of the things we've updated is really the selling point. Using view transitions is great, but you don't have to use it. Like it's not on by default for reason. But just upgrading all the plugin, the better experience you get as a React user, that sort of thing. That, that is the thing that I think is the most, the biggest reason why you want to do it right away. Also we do try to make it as easy as possible to upgrade. Like our process for breaking changes is we deprecate something in one major and then the next major we actually remove it. And actually we actually, sometimes we forget that we deprecated something and we're just now removing things that existed like pre 1. 0. So yeah, there, and the [00:24:00] other benefit I would say is that we have one of the best docs teams of any framework out there. They have a very extensive guide that's already available within there's an RC release of Astro 3. 0 and. It goes through all the different steps. So probably the biggest breaking change is dropping support for node 16. Node 16 is end of life at the end of September. We were like, do we want to keep this around for another major, even though it's going to be deprecated? So, we decided to get rid of it. But for most people, there's not going to be. Much notice of changes of just using Node 18 or Node 20. I mean, He and the docs both hit it out of the park. And if you need convincing, it makes React better to work with and Images better to work with, which covers like 100% of websites. So I assume you're in the group that would benefit from it and you can drop some experimental flags along the way, which is always nice I'll add one more thing. We also had some rendering performance improvements that are in this. [00:25:00] Long story, we used to use JavaScript generators like a lot in our code because it makes it, yeah, it's my fault. I really like them. It makes it very easy to write like sequential code and kind of a very readable way. But in parts of your code that is very performance Where performance matters the most, which obviously like rendering HTML, that it matters not the best thing to do. So, so we ripped those out we got rid of as much asynchronous promises and stuff as we could. And so we actually have like up to 30% faster rendering. So yeah definitely a good reason to do it. I think, 3% is a big number. Yeah, 30% is uh, that'll definitely convince me for sure. So let's switch gears real quick. We noticed that you redesigned your homepage. Can you tell us a little bit about that? Yes, we did. Uh, Doing it I know, I know. Yeah, we had a stepping stone where we wanted to Reintroduce ourselves, but we had a one week [00:26:00] deadline. So we just rebuilt it with Tailwind UI, made it look nice enough, but it wasn't the true space age refresh, make it look like Astro. So then we spent a longer period of getting proper design mock ups and really getting that done. I think that's been up for a few months now. But I know we want to reintroduce ourselves again. I don't know if it'll coincide with 3. 0, but it should, to showcase all the use cases people have now. Before we talked about content a lot, now we talk more about, well, it's a server first framework. If you're trying to build backends, you're trying to build endpoints, Astro is really good for that. And we have a growing node server community serverless community as well. So we want to make sure on the homepage, that's also front and center, that Astro is going to be, especially with a 30% import. Performance improvements is the quickest way to render HTML adapted to any server of your choosing. So static or server are both really addressed. And with React Refresh, also really good for dynamic apps. So growing the pie a bit [00:27:00] from just building blogs and marketing sites, which you might be used to hearing about Astro. Yeah, not only have, not only are we going to update the site for 3. 0, we have remember Ben, today is August 30th, it is release day, yeah, it's done. We and we have, yeah, we've updated the content, yeah, like Ben said, we wanted to change the focus a little bit a lot of our focus And historically has been about, Oh, it's a great way to make performance content site. And while we don't want to get rid of that, there's always been this thing and be like, Oh, well, I guess I shouldn't use Astro if I'm building a spa. That's not really true. You can use Astro. We like to think about Astro as like a meta framework of meta frameworks where like I'm building a spa. And that can be part of my Astro site. But then I also have content pages. I might have a blog and like, Why would you, use , two different systems for that? Why would you have to use one thing? So, I really wanted to focus on the ability to, build anything you need with Astro. So one last thing is I personally and a lot of my peers, [00:28:00] we've noticed that Astro has just been gaining lots of traction. In your own words, why do you think Astro is a? Why do you think it's starting to, quote unquote, blast off? Hey, Hey, I got that from Ben. really? I've probably said that. But yeah, there's a lot of reasons. The community was really strong from day one. So it means there's just been organic growth and word of mouth that hasn't stopped. It never really slowed down. And since it's unopinionated and pretty friendly to whatever you're trying to do, it doesn't end up being this very dogmatic, if you use Astro, this is how you think about web development. Which can happen sometimes. In HTMX, it happens. But, because of that, and everyone is coming in and trying it, There's actually a even spread of users across React, Vue, Svelte, and Solid. There are subtle differences, but there's a surprising amount that are from all of the different frameworks. Which means everyone is, spreading the love a bit, bringing the component systems they already have. And trying Astro for [00:29:00] more stable features like server rendering and images. So because the use cases are growing and it's familiar enough to whatever you're trying to do, it's easy to try it in a weekend hack and it's easy to, pitch it to build your next company blog or your next documentation site. Also with Starlight, which is our documentation theme that came out in the past year. And that introduced a whole new documentation community that now has a really nice framework for it. So I think we're, building a community that talks about it for us and memeing on the side for all the gaps that might be there, yeah, Ben said it perfectly. I don't really have a lot to add. I think over overall, it's been our ability to be a big tent framework and not to, we have some opinions, but we don't, we're not the type to say Oh, well, if you think about, if you think about web pages as CSS first. You fit within Astro, or if you think about, you think about it more from JavaScript perspective, you fit within Astro as well. So our ability to, to appeal [00:30:00] to a large array of different perspectives. Yeah, the one thing I really loved about Astro when I first tried it out, which Ben hinted on, was just the ability to use any framework I want. I think that's usually like the biggest, at least for me personally, that's usually my biggest pain point is having to learn Like some new syntax or whatever, but the fact that I can just bring my own ecosystem to this, and then basically plug in the pieces and have it work is like probably one of the best onboarding experiences I've ever had. So kudos for that. But I feel like you all have accomplished so much and everything's just, everything's falling together at this point. Like where does Astro go from here? What's the future of Astro? Oh, interesting. I think that Astro, I think what's interesting is the way that frameworks have been for a long time is that they really have a way to help you build websites with basic functionality and features. But when it comes to, everything else you need to do to build a website to connect to a database [00:31:00] to, do billing or do authentication and stuff like that. Mostly hands off or be like, Oh, well, you can use this package and you wind up having to make a lot of decisions by yourself. So I see Astro, I don't really know exactly where we're going to go next. We'll talk about that soon, but I see Astro growing in that way where we can extend past just, the build process, extend past into production. It's very vague on purpose. Yes, there's a one more thing that will be coming soon, talking about some of that. But there's also, yeah, I know that we have, a themes page that we've always bolstered, but it feels like there is more of that energy. of people building stuff just for Astro, like documentation being the first one, and building our own docs theme that has a ton of opinions around internationalization and built in components that you don't have to build them yourselves. Because Astro's content first, people usually want a very hands off experience where you're just editing markdown most of the time. You don't even have to author the [00:32:00] components or install them. It's very hands off, but you still own your content and you can, deploy preview it with Git because that's, the developer's favorite workflow. So the future is really like just making it more and more hands off with the stuff you have to add to the project manually. Manually install component libraries from here and just have it all be bundled in with best practices. There's been some fun developments with bringing authentication to Astro. Something that's not totally solved, but solved vaguely in the community. I know Clerk is cooking up something there that should be exciting. When that comes out, I don't know. I really don't. I just know that we're working on it, and they're very excited about it. So, it's like the primitives are there, but the best practices are growing. And that's the part that I really want to see hit home. So that people don't have to wonder, What blog post do I follow to build an Astro site? No. These are some really ready made options from the community and from Astroverse. Cool. Well, I'm definitely looking forward to all those top secret things that you guys will reveal later [00:33:00] on. But Hey, that about ends it for me. I was dude, it was a pleasure talking to you, Matt and Ben. Thank you for coming on to the podcast. I appreciate it. Thank you. Yeah, appreciate it.