(NEW) Astro 6: First Look

The next major version of Astro 6.0 just dropped and let's talk about it. [music] Hey, what's up? My name is Chris and welcome to Coding in Public. All right, for those of you who don't know, I'm a huge Astro fan. I've been using it since the early betas. I even have an Astro course. I'll include a special discount just for Astro 6 down below because I'll be updating the course to support all of these new features and you can grab it at a big discount since obviously I'm promising that and those things aren't quite there. But what I want to do is just kind of read through this blog post with you and talk about these individual features and why I may or may not be excited about one or the other. All right, let's jump in. All right, so we've got a a bunch of new capabilities. Fonts API, which I don't think I've done a video on somehow, although I use it all the time. Content security policy, which I also haven't done a video on and I've wanted to for some time. There's like some tricky stuff around this, especially if you're working with thirdparty services. So I need to do a video to kind of talk through that. Live content collections. So, I have done a full walkthrough of that, like an early version, although it's very similar to uh what it was when I went over all of that. Alongside this, there's like a bunch of new refactors done under the hood for the dev server. Um, this both is about speed, it seems, and also compatibility between dev and production mode, which is always really great when you have those environments super close together. Um, I should mention that's powered by their environment API uh vets that is. Um, so Astro can basically run the exact same environment uh right here. That's what I mentioned. Okay, so let's kind of walk through this. I don't know that I'm going to read every single thing. I figured you could probably do that, but um this I did not know about until today, and that is that there's a new experimental Rust compiler uh that's baked into Astro 6. It seems uh it's early, but the results are impressive, and I'm assuming this has much much more to do with speed uh than anything else. All right. Uh a couple notes about how to upgrade. I won't say a lot about the dev server because ideally, obviously, this shouldn't change anything for you. It should just work. And uh the improvements will be felt by all but you shouldn't have to actually change anything in your in your actual workflow. Um so you use Astro Dev like normal and it can run environment during development that's the same as what it would be in production. Uh Cloudflare users um especially kind of felt a painful gap in these two different ecosystems like the one for dev and the one for production. So obviously them being acquired by Cloudflare uh they're going to want to make sure that it runs uh nice on it but I think it's about much more than Cloudflare. Um, all right. Fonts API. This is super cool. You can pull in local fonts. You can pull in um Google fonts. There's other ones as well like font source that you can pull in and it has a really nice predictable API that works well across the ecosystem no matter which kind of font selector you're using. You simply use the font component declaration and then you can just declare it and once it's added you can even preload that font so it loads quickly. There was a plugin for this, an Astro plugin that somebody created. Um, but this or an integration, but this is obviously native and so should be a lot better. Um, although I was happy with the other one as well, but I've used this for the last several months in experimental mode. It's great. And now it's not experimental anymore. Live content collections, I've done this. The idea here is you can have content collections, but even if they're pulling from live data, it only does that at build time. So when you build it, even if you're in SSR mode, it creates a local store and that's where your live your content collections used to pull from. Now, um they could have just altered that one and like given you a live mode and a not live mode, but there's some complexity between those. So I think it's smart by the team to have the standard content collections. That's for static content at build time. Even if that content changes, it doesn't re-update in your site unless you rebuild, which you can do on a crown job or something like that. Alternatively, you have live content collections. This would be things like uh a store perhaps where you want to always check the current price. Now you could have done it with client side JavaScript or something like that but it's nice to have this live content collection as an option. So the API looks the same in a lot of different ways but there are a couple of other features like you build loaders differently. So um when you create them you're going to use this live.config.ts file and then when you use them uh or you have to also use define live content collection but when you use them you just use get live entry or get live collection. So, it feels very similar. A lot of the actual ending API is the same, but there are some differences. And again, I did a full video on this. And uh I think there may be one or two micro updates that I need to include if I do another video on that at some point, which I probably will. Um but that should give you get you 99% of the way there. So, live content collection's a huge benefit um to giving you just more flexibility. Like Astro has all these different layers now, right? You have um the SSR rendered mode, SSG, you have Astro uh islands that are client side. You have server islands where you can pull in data dynamically uh customized to the user and then stream that in using uh the server uh along with all the other options you have with Astro. This is another really nice one. All right, content security policy. This uh has some oddities around it just because if you're really going to be secure, you want to block off any routes. Um, if you don't know what this does, basically instead of it being experimental, now it's just like baked in by default. I think it's even true by default, uh, if I remember correctly. Um, but this is stable in Aster 6. It's one of, uh, the first JavaScript meta frameworks to offer a built-in CSP configuration for both static and dynamic pages in both server and serverless environments. It's hard to implement in frameworks like Astro because it requires knowing every script and style on a page so they can be hashed and included in the policy. So the idea here is you want to prevent people um from injecting like for instance like a post request that doesn't come from your own site. Um now this presents some complexities. I've run into this a few times already myself when I have this enabled where I'm like okay how do I allow for this one particular use case? So you kind of have to do a little bit of that manually yourself sometimes. Uh so for instance, if you have uh like an in like a web hook and you're trying to receive a post endpoint there, that's something that constant security policy would not allow you to do. So you have to kind of find your way around that. And uh so there's some complexity around this, but I think like for the default, it's a good default starting point. And I think they've even added quite a bit since I started using it. So as I've dipped into it here and again, it seems like they're trying to expand for some more opportunities like that to where you could get the benefit of the security without it kind of bogging you down. Um, so to get started with, you just enable it. It's a flag like I just mentioned. That's all you need for the most part. But here's where the control comes in. And this is what they've been adding in the last several weeks. There's a custom hashing algorithm, additional directives for external scripts or styles, and a full configuration API is available. So I haven't really dug all the way into this, which I need to do, but this allows you to essentially define your algorithm. For instance, you can define your hashes, your script directives, and which direct uh which directives you want to um implement. The idea is that it gives you control again while also getting the nice default. Again, I think there's some complexity around this and if you want to know more about it, you can check out the security configuration reference and full transparency. I haven't had a chance to really dig into that, but I'm excited about that as a good default starting point. Uh, a bunch of upgraded packages. Most of this won't massively affect you. There are a couple things to note like with Zod. Um, there's some schema differences, but you'll usually get that directly in your editor. So, for instance, instead of having like string and then email to like say that it's email type, it's just email directly off the ZOD object. Uh, so there's a couple things like that. And Zod has a really nice upgrade uh path, so it's not too difficult to get started with. Uh, you have new node 20 uh2 or later. Um, I'm like in this zone right now where I'm switching between node 25 and something else over and over again. But if you have questions about upgrading, they always have a really great upgrade guide here. Now, here's this experimental Rust compiler, which I didn't know about until this dropped, but this seems super interesting. And again, it seems like the main benefit here is speed. Um, but why not use Rust? Everyone else is as well. Um, and it's cool to see them experimenting uh with with Rust here in Astro. There's also cued rendering. So, Astro 6 uh introduces an experimental new rendering strategy. So, SSR, SSG, server rendered uh um like islands, all these things weren't enough. Now we have this cued rendering as well. Uh today Astro renders compu uh components recursively. Rendering function functions call themselves as they walk the component tree. Cute rendering replaces this with a two pass approach. The first passer versus the tree and emits an ordered que. The second pass then renders it. The result is both faster and more memory efficient. And we plan to make the default rendering strategy in Astro version 7. So you can enable this right now. Uh the docs are pretty good here if you want to understand kind of their reasoning and how how they've set this up. Um but it seems here again the idea is to give you more control over memory and this is kind of the next section uh where they're it seems like Astro is wanting to kind of move into is how do they do things like incremental static regeneration and a lot of these other more complex rendering strategies in a way that like doesn't mess up caching and gives you full control. And speaking of caching, route caching. So Astro 6 uh includes an experimental route caching API that gives you platform agnostic way to cache server side or server rendered responses using web standard cache semantics. Anyone who followed the drama with Nex.js the last several years, you know that you can really mess people up with caching um by being too aggressive one way or the other. So I like the fact that they're using web standards to start with. That seems so astro. Um but also I like the fact that they're moving slowly with this. Um, Matt Kane gave a great talk last summer where he outlines some of their thinking around this. Um, so make sure to check that out. I'll try to remember to link that down below. Um, but this is kind of the first step in that and I think will be one of the big features in Astro uh version 7. So you can enable route caching uh by configuration, a cache provider in your Astro config. A cache provider tells Astra where to store cache responses and it ships with a built-in memory cache provider to get you started. super excited about this and I think um especially for bigger sites like I have a site with I don't even know like five or six hundred blog posts not massive but enough to where I don't want to rerender all those since most of them haven't changed um and so every time I'm building statically which it's mostly a static site I'm having to rerender all these and I think my understanding is uh this route caching would allow me to opt out for certain routes there are of course ways to do that kind of right now uh with Netlefi or Verscell or a couple other adapters um but to have a native solution built in here kind of in the framework work I I think is super interesting. All right. Uh we'll skip past some of those. Uh core team members, please like remember a lot of these people. They're the ones who've made Astro special. Um not all them are on the core team. Uh I donate uh money uh to the Astro Collective. I encourage you to do the exact same thing. But the nice thing is it's not just these core uh maintainers. Look at all these people who contribute. And there's a bunch more beyond this. Um if you're interested in the Astro upgrade guide, uh you should check this out. There are a couple things that may mess with you. I'm trying to remember where this is even at. Uh let's see. Upgrade guide. Here we go. All right. For detailed steps, this will be really important for you. Um they always do a great job of walking through all the little things that have changed that may be interest of interest to you. So for instance, here's that uh email one I mentioned a moment ago. The way you do error message is a little bit different as well in Zod 4. There are a couple other things like for instance uh the Astro like namespace isn't in uh some routes now but you can still get access to those through importing meta.v like site for instance. Um there are a couple other things to look in here as well. So astrogit static path that's one I was thinking of uh that I saw the other day. You can just grab it right here if you want to. There are a couple other ones as well that have been out for quite a while. Uh so for instance they used to have this schema one. Now it's Astrozod. And that's nice because it kind of unifies that across the ecosystem. Usually you're just importing from Z and you don't or importing Z from whoever knows. It just tells you and you just hit enter. Uh so this isn't a huge deal and not a hard upgrade either. Um but there are a couple of things you want to to look at. Astro view transitions for instance. U for a long time now. They've had a lot of this kind of as the stable way to do it. But it may be that you've been using some of these um a long time ago and so now you want to make sure that you're using these updated ones. So, one of the things I really like about Astro is whenever they do like a a true upgrade, you never feel like you're getting thrown under the bus. It's usually a year plus where they're telling you, "Hey, this is going to go away. This is going to go away." They'll even tell you that in the CLI. And then when it finally does, you're like, "Okay, that's fine. I haven't been using that for a long time." Well, I hope this was interesting to kind of see what they're planning. I love that they're tipping their hat to like the next features coming out as well in Astro 7 around caching and uh some of the cool stuff with the REST compiler. Um, but let me know what you think below. Um, it's nice for me that like yes, there were some helpful additions to Cloudflare so that the dev and production environments work both on great on both, but it's not like dominated by Cloudflare now that they own uh Astro. And obviously, let's uh keep their feet to the fire, make sure that they're still communitydriven and all the rest of the stuff that we've grown uh to love about Astro. But I hope this was a helpful walkthrough. I hope to do videos in the future uh actually detailing these. Now, I mentioned I do have an Astro course and if you're interested in a special code, you'll find that down below because obviously it's not up to date yet for Astro 6. Most of it is still great. Um, I just need to add some things and that's the cool thing about Astro is a lot of these things, even if um they're new, it's not like they break backwards compatibility very frequently. And when they do it, you got a year plus to usually figure that out. Well, thanks so much for watching. I hope that was interesting to walk through and let me read this to you. Um, let me know what you think below and I'll catch you in the next one. Happy coding.