About this talk
In this talk, Matt from the Astro core team presents the recently launched Astro 6, a web framework designed for content-driven sites. He explains that Astro is built on Vite and is optimized for scenarios like blogs, portfolios, and e-commerce rather than applications like dashboards or chat apps. The speaker highlights the framework's ease of use and developer satisfaction, noting its rapid growth in popularity and downloads over the past year. He introduces key features of Astro 6, such as live collections that support real-time data handling and enhanced caching capabilities, which streamline data fetching from APIs. Additionally, Matt discusses the automatic content security policy support that aids in preventing security vulnerabilities, as well as improvements in font handling for better user experience. The talk emphasizes Astro's commitment to performance and ease of integration with existing tools and frameworks.
Full transcript
Hello. Um I'm Matt. Uh I'm on the Astro core team and I'm here to talk about Astro 6. Um it launched this week. Perfect timing. Came out on Tuesday. Um I didn't know that when I um for when I pitched this talk. So, the title that um you will see on your program is saying what's coming up in Astro 6, but now it's what has happened in
Astro 6. So, who am I? I'm Matt. This is my site. Um I have been building for the web for not quite since it looked like this. Um maintain quite a lot of open source projects. There's a few of them up there. I used to be on the Gatsby core team as well, but now I work at Cloudflare where my job is making frameworks all frameworks work
well. So, um how many people here have actually used Astro before? So, it's quite a few. Quite a few. You know, I mean I understand here that this is not an Astro conference and um Astro is not just about Vue, but there is uh quite a bit of Vue in there. Um but I'll give a short intro to um Astro for people who don't really know about
it too much. Astro is the web framework for content-driven sites. It's uh built on Vite. We don't try to be a framework for everybody. It's not you if you're building a dashboard or something like that or a chat app or something, you probably don't want to be building it with Astro. But if you are building a content-driven site, so blogs and um portfolios, docs, e-commerce, then we
think that Astro is the best choice. And devs love it. It's number one for satisfaction in the state of JS for 3 years running now. Um downloads have just gone through the roof. I mean been a lot, you know, people have clearly been doing a lot of vibing in since January, but we've basically trebled the downloads in the last year. Um and lots of sites are using
it for you know, massive global brands and weird little dev portfolio sites that supposed to look like 35-year-old Macs. what does an Astro page look like? this is an Astro page. This is a valid Astro site, an Astro page. It's just HTML. If you know HTML, you know how to write an Astro page. it can do more. If you add a frontmatter fence, that area at the
top is now TypeScript that runs at build time. Um and you can pull in components and do all kinds of stuff in there and that just works. But if you need some interactivity, you can pull in framework components. So, I've pulled in a Vue component here. I've told it to hydrate when it when the page loads. Um and then you can just pull that in there and
it also supports um React, Svelte, Solid, and so on, but you can even mix those in um the same page if you're being want to be crazy. and if you add that, then it turns it into a server-side rendering. So, it's rendered SSR um instead of being rendered at build time. And um what this all what this means is that Astro is really fast out of the
box. I mean you you have to try hard to make Astro slow in the browser. It's it's pure HTML and you know, HTML when it's just HTML is fast. So, but then when you do have the interactivity, you are doing it on your own terms. You're saying how much you need. Do you need that little bit of interactivity in there and you'll pull that in and that
will do it. So, Astro I've said is for content-driven sites. So, we have some extra tools in there for helping manage content. Um Here is how you define a content collection. So, we this is content collections are a way of managing all of your content that you have in a site from wherever it's coming from. Um a lot of people have big folders of markdown that they
use because, you know, Astro is awesome for doing docs sites. Um and this is how you would do that. You just basically say here's pointed at a folder. These are the um the markdown files and you can define a schema. So, if you do that, then it's parsed um at runtime and uh type checked and you get you know, you get get all the full TypeScript types
and everything in And then in your page, you just call get entry, load it. You render it and there it is on the page. And it's it's really as simple as that and I think, you know, it's a lot of people that keep asking me I mean they genuinely ask me why is why why do people why do I think that people like using Astro and I
think it's just really easy to get into it, you know, and it it makes it easy to get started and easy to do the right thing. But loaders aren't restricted to just the file system. So, here, you know, this is the one that we saw before. Um but you can also write a loader that pulls from any API, a CMS or database or whatever. Um and you
define it in the same way. So, here we've got a one that's loading from a store. You put the loader in there. Schema in the same way. And then you can just use it in the same same way. You get entry, pull a product, mix and match and it just just works in that's how content collections have worked up until Astro, you know, before Astro 6. The
problem there is that obviously this all of this data is loaded at build time. And even if you're running in SSR, it's still the the data that was um loaded at the point of the build. So, that's great if your pages don't change very often, but if you are using say you're doing something that like changes regularly or you're editing a CMS or something like that, you
can't use content collections, you know, you have to you lose the benefits of having a content collection. You have to hit the APIs and stuff manually, which, you know, I mean it's it's not as nice. So, in Astro 6, we've added live collections. these are basically exactly the same in terms of how you use them except for they run at runtime. So, you can live data that
updates. And the point is that it works you can use it in just the same way and you get all of the nice developer experience that you get from other content collections like all the type safety and the the way that it's all centralized and the way that you can reuse all the loaders and everything. Um And um you use it inside the um you define it
in a very similar way. You just create the loader and there it is and um it's just defining a live collection instead of um defining a uh a build time collection. obviously, the problem with live data is you are having to hit your API every time. So, you know, obviously that is not going to be as fast as having a fully cached um data that is already
there at runtime or pre-rendered. So, what you are going to um what you're going to run into is that, you know, you want to be caching this. Now, you can do caching with Astro now. You can set your response headers and cache it like that, but it's it's not very not very ergonomic. So, what we have done is um we are in Astro 6, we are adding
root caching as a may So, this is experimental in Astro 6. Um but let me just I'm going to try and show you how this um how this works. So, let's get this beautiful site here I'm going to um blame on Claude. I said build me a demo site and pointed at the docs. Um I didn't tell it to create a every possible Dutch stereotype that you
might have heard of. Um but it saw it was for Vue.js Amsterdam. So, obviously, that assumes that that's all that um Dutch people want to to learn about. So, anyway, here is this lovely site. Let's look at some more fools. Um it's you know, this got the it's got some Vue components in there for adding to cart. Um and yeah, so you just got that and you
can see that these Vue islands are hydrated, but the rest of it is all static. So, but what I'm going to do is I'm going to switch us over to the code, which I have got on the wrong screen. I was doing so well. It really doesn't want me to drag it up to the to the other monitor. Um There we go. There you go. So, let's
make this a a little bit bigger. this is how we are loading the um this is how we're defining the live collection. This looks like how we are how I showed it on the screen before. This is uh showing the where we're defining this product loader. Now, this loader here is um a fake one that I've created, but this just shows how simple it is to define.
So, So, just a load a live loader is just uh an object with two functions, load collection and load entry. load entry, it literally just grabs the data, returns ID, data. And then this is the secret. This here is a cache hint. And what we've got here is a um a last modified time coming from there and the tags. And what we're doing here is we're tagging
it with the ID of the project. Um we've also added um with the project and this we're also adding a category tag there as well. Now, this has to be this ID thing here has to be unique across your across your site. and then what we what we're going to um what we're going to do there is I'm going to show you how we use this in
the Now, I'm grabbing this entry here using get live entry. I'm pulling it from the products. And then this part here is I am calling Astro cache set on that entry that I've just grabbed. Now, what this does is this tells Astro this page uses this data. We may try and make it all run automatically, but at the moment it's something that you opt into. And this
is basically telling Astro this is a thing that you need to depend on. Keep an eye on this. We'll look at that look look at this one later. if we go back to our um our page here, we um we can see that this is actually cached. Um we can see this I'm going to make this a bit bigger so I can actually see. you can see
that this one was there load was rendered at 14:28 and as I reload it nothing is nothing is changing. So, here's our our waffles. there, 16:31. That was just now. And as I reload it it's not it's not updating. So, this means that this this has been cached. So, obviously waffles are amazingly delicious and there's been been a big run on them. So, you decided that we
need to bump the price. So, we hit on the thing to bump the price here. Price has gone up. Pretty shockingly expensive I have to say, but um people people still love them. So, we go back to here, we reload it. Oh, no. Obviously, it's cached, you know, not rocket science here. So, what I'm going to do here is I'm going to hit uh invalidate. I'm going
to go back there. I'm going to reload that. It's updated it. It's um invalidated the cache. Um and then if we go back to the index it's also invalidated this one as well. so this this here is running on a um uh just let me just switch back to my slides. Um This this that I've been showing you there is uh the node provider. This we launched
I mean this is running experimental that we launched last week or this week even. And this current one is just an in-memory cache. So, it's not doing anything anything special and it only works on node because you it doesn't make any sense to have a memory cache on there. So, this is this is not so interesting, but um we don't really want you to use our built-in
caching. That is only there for places where you can't run a proper cache. And what I mean by a proper cache is one from a CDN provider. So, I've got Cloudflare there. I work there. That's not, you know, that's that's just um it's just one example. But um this isn't ready yet. This will be shipping in the next few weeks, but basically the idea is that platforms
Cloudflare and Netlify and Vercel have got really um sophisticated programmable caches now. And these are just, you know, real HTTP caches. So, using the web platform. so instead of inventing our own caching, we are doing this thing that we always try to do with Astro, which is to use the web platform. So, we are just using headers. We are using the box standard cache headers. Now, that
doesn't neces- you know, that might not be particularly interesting. We're just sending a cache header. You could do that, you know, you can do that by hand. Um we are also wrapping their cache invalidation. Now, that is one way each platform is is different. They've all got their own ways of uh um uh purging their cache. We are wrapping around You just um call Astro cache set
or you call Astro cache invalidate and it does it all behind the behind the scenes. Um and they all support the same cache cache control headers there. So, you can do the the ISR type thing with stale while revalidate. You can do cache tagging. You can invalidate invalidate that really um anywhere and this works across different providers. What I would really love is that we would hope
that this API this cache API is um pluggable enough that people can implement uh uh cache providers for, you know, Fastly or for ones like for Redis or whatever and that is going to be um something that, you know, means that this can be used absolutely everywhere. I'm going to just switch back to my um And so, I'm going to show what this actually looks like because
what we saw just there was only the um only this in-memory thing, but we want to see the the real deal here with the with the cache header. So, what I'm going to do is I'm going to get rid of this memory cache and I'm going to change it over to this CDN cache provider. So, I've created a CDN of my own. Um don't tell my bosses.
Um so, we this is this is a very simple one, but it's just actually showing how simple it is to implement. Um it is basically just literally here. This is the API for creating a cache provider, set headers, invalidate. So, you know, anyone can make that. Um and this is what I'm doing for the headers. You know, it's a bit messy. I'll put we'll make some helpers
to make this easier. And then for invalidate, I'm just logging it. So, now I've changed this here, so I am going to have to to rebuild because this doesn't work in dev because you don't want your caching happening while you're in dev cuz that way lies madness. so, what I've now got is I've got this so, I've now got this new CDN cache provider that I've got
in there. So, um to open my um my cache tools here and I'm going to go to the network tab. let's go to so, I'm going to reload this and then what we're going to see here Nope. We've got all of these cache tags that have been associated with this page. So, this is the tags for every product that's on here. So, if I then um go
to another page and load this one here, you can see that um you've just got the um product and the category food. Then we've got these CDN cache control headers. I've set up stale while revalidate and that all that kind of thing for it. Um and then this isn't actually caching now because this is a fake CDN, but this would this what this would do if you
had a real CDN is it would see this cache control header. If you've not seen CDN cache control, it's a it's a web standard one, but it's designed just for CDN. So, your browser will ignore it. So, um it should be used by the CDN that that that then just handles it. but the point about this that I'm trying to get at is that because this abstracts
everything away, you can just if you're writing some code, you don't need to think, oh, am I on Vercel? Do I need to use um purge cache or do I need to use um Vercel cache tag or do I want to use Netlify cache tag or and and if you're writing a library, so say you are writing um a loader for a CMS, you don't want to
have to tell them that um oh, if you're on this platform, you use this way of doing it. That is all abstracted away. All you need to do is call Astro cache set or Astro cache invalidate. Um and it just makes makes everything uh a hell of a lot simpler. And I'm just going to finally just show the way that the invalidation works. So, when I was
hitting that invalidate endpoint, all it was doing here was hitting this API that I've got. This is just an API endpoint. And here it is, cache invalidate tags. And in realistically what you would do this for would be say you would have a webhook from a CMS, for example, would call out this and it would say, okay, I've you've edited a page. This is the page this
is the object that has changed. And we are going to invalidate everything that's on that that uses that object. And that doesn't necessarily mean to need to be one one page to one uh object. So, you know, if you are doing a complex page that uses like lots of images and um things like that from a CMS, you can pass those all to Astro and it will
merge them and create the unit um the union of all of the tags. And then when you edit one um icon of one um caption of one uh thing, it will invalidate every page that uses that image. um that is uh the way that live can collections are going to be working with root caching coming very soon. So, I'm going to move over next up, next feature
for Astro 6. Astro 6 includes automatic content security policy support. Now, if you have ever done this by hand, you will know what this is big deal this is. If you've never you done this by hand, you will be going, "What's a content security policy?" It is content security policy are a browser security feature and they are bar none the best weapon that you have got against
things like cross-site scripting vulnerabilities. Basically, what they are is an allow list of scripts and things like that that are allowed to run on your site and it can covers everything. So, whether you can load a font or whether a script or styles or anything like that. You can set it as a meta tag or an HTTP header and the browser will block any script or style
or image that doesn't match that. Now, if it's such a powerful thing, why do so many sites still get cross-site scripting vulnerabilities? Because CSPs are a massive pain to do. They are really, really annoying. You've basically got to do all of these things of getting hashes of every script that has to update every time you change any of the content or you have to set a nonce
value which has to change on every request and be applied into the HTML. It's just really annoying and um basically, we decided that we needed to do something better about this and it's it's been a massive amount of work to get this going but what we have done is we now can manage to keep track of every single inline script or whether it's a loaded if it's
a linked script or anything like that. We keep track of everything and then this is how you enable it in That's all you need. That sets everything up automatically. You can twiddle add add extra bits in there if you want. So, if you say want to do third-party embeds or something like that, you can add them in there but this, if you just drop that in here
there, your site will suddenly be blocking like 95% plus of any of vulnerabilities like that. so, I am going to show an extremely quick demo of this because I already have that demo there. It is the um this demo. Now, you may have spotted this already. This is the header that came from this. Really, do you want to be generating this by hand? Each of these here,
so if we say this is the script, this is fonts are saying you can load any fonts from this this origin. Scripts, these are ones that have you're only allowed to load ones that have got these hashes and it's the same with styles and everything or like that. And it just works. Just literally, I just added that line and it just did it. that's pretty cool, I
reckon, anyway. Next up, fonts. I'm going to take a sip. So, content sites. They are fonts are important. Content sites are about reading, so typography matters. this is another Claude special here. I did this on the Eurostar on the way over. I said, "Show me do something that uses Google Fonts." And wanted to demonstrate it. This is real recording. This is you what you can see here
is the way that it jumps around. Now, this is called the flash of unstyled text. Now, Google Fonts are brilliant. We like, you know, they're they're great. They've got all of these fonts that you can have but Google Fonts are free but they've got strings attached, you know. And you they are free only in as much as you are paying for them with your users' privacy. And
it's not your privacy to spend. the conclusion is you shouldn't use these third-party font font services. Whether or not these these legal things stand, I mean, just I think personally, ethically, you shouldn't be using them. you should self-host them. And that's annoying. So, what um what we can do is we can make that easy and we can make it so that we can do some extra little
tricks to stop that jumping around flash of And this is how you do it. This is live in Astro 6 now. You define the font provider. I look, I'm using Google again. You can still use the Google Fonts because it doesn't tell anything about the user. It just loads downloads them as you're as you're getting them built. And then you just set all the settings for them
and it's um downloads them at build time, so there's no GDPR stuff and then it generates size-adjusted fallbacks to make sure that the things don't jump around. So, what that basically means is it will say, you know, you are using a fancy serif font that you're loading from Google. We're going to do a placeholder where we use Georgia that we specially hint and adjust so that it
so that it fits. That is powered by Uniform and Capsize under the hood. Thank you, Daniel. it's the example here is Google but it also supports loads of others thanks to Uniform. So, it will handles like Bunny and Fontsource and even Adobe. Um and I'm going to show you the fonts. I'm not going to show you the fonts cuz I've only got 2 and 1/2 minutes. So,
I'm going to skip straight forward to this one. This is a little lesson for all open source maintainers. Um if you get the opportunity to nerd snipe somebody from EAT and E, jump right on it. Um I don't know how many people know EAT and E. I know was had some stuff yesterday. But this is James. This is what happened the next day after that. James opened
a PR 11 times faster. This is an example of the other thing that we've been focusing on. We have been doing all of these optimizations of the builds and rendering of Astro. Going through everything from the the compilation and the rendering pipelines because, you know, Astro originally was not really optimized for SSR or anything like that. It was, you know, it was, you know, it was good
enough but not good enough but but not, you know, not first class. It's getting better. It's getting a lot better. So, this is what we've got. But the big thing that we've done is this next new project. The the original Astro compiler was written in a weekend. Um Nate who wrote it, it was the first go code he'd ever written. Um this was pre-Vibe coding, obviously. You
know, this was 2021. Now, that considered, obviously, Nate is amazing. He's he's now does Clack which is used by absolutely everything. But he he wrote this and it did us really well for a long time. That go for putting a lot of lot of work. it was hard to maintain. So, we've done the traditional thing. Uh we've rewritten it in Rust and we've done the newly traditional
thing which is we've based it on top of Oxc. Um so, Erica who's built it, she's we're actually using a fork of Oxc at the moment but we should hopefully get that upstreamed. We forked Oxc to add support for dot Astro files. And obviously, the nice thing about that is because it's Oxc, this will give us support for Oxlink and Oxc format as So, I'm really excited
about this cuz I'm huge fans of those projects and we all are. And we decided to keep it in the tradition of before and this new one was also written in a weekend. This was written by Erica with a little help from someone called Claude. As part of the work though, this was the the first thing that she did was write a proper formal spec for the
Astro language which there hadn't been. The spec was whatever worked in in the old compiler and because of that because of because she put in the hours to make the spec, then the the compiler worked really well. Now, this is experimental in Astro 6. We're already seeing some great benefits. So, we recommend you give it a try. And then the final thing is the Vite environment API.
Now, this is pretty in the weeds. I know really, in terms of any audience, you probably more people here know what the environment API is than anywhere else but it is still pretty much in the weeds. The important thing is that this unlocks the biggest project that we've worked on in Astro 6. The previous version predated SSR of the the dev server. We've written an entirely new
dev server and the previous one predated SSR in Astro. And basically, we've done a full rewrite of the dev server that uses full SSR all the way through it, so you don't get so many of the works on my machine things. So, it's it removes a whole class of bugs. And it also unlocks some cool stuff like the fact that you can run because it's running the
same thing as in SSR, you can do stuff like you can run the real Cloudflare runtime in dev. Um so, it's not being emulated. It's the real thing. And then there's a slide I had to add. So, speaking of things built on Cloudflare Workers, most of you probably saw Evan announce Void this morning. these primitives here are the sort of thing that wouldn't have worked in dev
on Astro before but with this because of the environment API, they will be able to do this. And this applies to all the platforms. Now, this is my caveat. I haven't actually checked this with Evan. I I was going to ask him, but you know, your mileage may vary. this is And this applies to any platform. This isn't just Cloudflare. This applies to any platform that's got
custom APIs that run at um uh run at runtime only and not in not in So, that's Astro 6. Launched on Tuesday. We've had over a thousand contributors to Astro since it started. And every launch blog, we thank everyone who contributed to the latest release. And for Astro 6, that list was so long, I'm just going to show you their faces. Um we've had a hundred and
thirty over a hundred thirty. I think it's more like a hundred forty contributors to just Astro Um and that doesn't include everyone who did like why you do we ecosystem stuff. So, thank all of you. Um And so, yeah, that's me. Some come come by and say hey hi later. Um find me on Blue Sky. Um and I also find some of these limited edition Astro View
Mission Patch stickers. So, thanks a lot, everybody. Bye. >> [applause]
