Astro 5 with Matt Kane
===

Noel: [00:00:00] Hello and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket provides AI first session replay and analytics which surface the UX and technical issues impacting user experiences. Start understanding where your users are struggling by trying it free at logrocket. com.

I'm Noel, and today I'm joined by Matt Cain, a core maintainer for Astro, here to talk about Astro 5. How's it going Matt?

Matt: ~Hi! ~Hi, thanks for having me.

Noel: ~Yeah, yeah, I'm excited. ~I'm excited for this one. ~Um, let's uh, ~let's jump right in. ~What are, what's going on? ~What's coming out in Astro 5 that people ~should be, ~should be stoked about?

Matt: Well, Astro 5 has got some really interesting new features coming into it.~ We've, ~we've got a few headline things in there, and then ~there's also a, ~there's a few things in there too that ~are Like ~seem a bit niche at first, but ~when you, ~when you get to them, they're actually ~pretty, ~pretty exciting. ~So the, the most, uh, ~the most high profile thing on there is the new content layer, API, which is ~a, ~an all new way for ~handling, uh, ~handling content ~for, ~for your Astro site.

~Um, ~we've also got. The new,~ uh, ~server islands, which are a way of combining dynamic and [00:01:00] static content ~on a, ~on a page. ~Uh, it's like, ~it's a new kind of way of ~rendering, uh, ~rendering pages. And then we've got a few other smaller things, like one of ~the, uh, ~the things that I like the most, which is ~our, ~the new environment variables handling, which is.

One of those things that every web developer knows could be quite annoying to handle. This gives you fully typed, fully scoped environment variables. then there's just some new changes to the way that we handle our rendering modes to simplify them and make them easier to use. So this is about the difference between the static sites and the server rendered dynamic sites.

Noel: ~Nice, nice.~ I feel like that, ~that gives us, ~gives us a few jumping off points. Let's start with the content layer. I think that was the first one.~ Um, I'm, I'm like, ~I'm like curious. ~Kind of ~conceptually about content layers. Let's talk a little bit about what this does. And then I want to talk a little bit like philosophy once we've ~kind of ~established ~what this, ~what this content layer abstraction does for users of like a framework.

Matt: Absolutely. So I think it's probably best to start with a ~bit of ~bit of history on this one. ~Um, ~Astro has had [00:02:00] content collections since,~ uh,~ version two. So that's, ~I mean, ~the speed that we moved, that's actually only about 18 months ago. But,~ um,~ what that did was it gave you a way of organizing all of your local content.

So like folders full of Markdown and MDX files, Markdoc, and that kind of thing. And it just made a way of you having those with typed data and letting you. in your pages and components, query them, get collections of them and get individual entries. And it's just a, it gives you a really nice,~ um,~ typed way of getting them because in your editor, you will get all of things like the front matter and your markdown are all typed.

And ~it's, ~it's just a very nice, ~you know, ~easy experience for, ~you know, ~getting entries and individual collections. Now, almost immediately after we launched those,~ uh,~ people were saying, I want to use this for everything. ~You know, ~I don't just want to use this for my local markdown. I want to use this for all of my content.

I want, ~you know, ~I want to be able to get things from APIs or, ~you know, ~that people had lots of [00:03:00] ideas of ways that they wanted to load data. And of course being very,~ um,~ resourceful, a lot of users did. workarounds like generating files dynamically, which were then loaded and, ~you know, ~basically every possible way of trying to ~break, ~break it because people really wanted this, but we didn't want to do it straight away.

We wanted to work out what was going to be the best way of handling this. So it was a little over a year later ~that we, uh,~ that we were going to do this new content layer API, which is, ~it's ~really, ~it's ~just a new level of content collections. So it lets you have content collections that load ~it ~from anywhere.

~So ~it introduces the concept of a loader, which is ~just a, ~a function or ~a, um, ~an object that ~just, ~allows to define how the data is loaded. ~And ~it's got very simple API. And ~we come, ~we bundle a couple of ones that are built in. One of those is the glob one, which basically replaces ~the, ~the old content collections.

~So ~you point it at ~a, like ~a pattern of files on disk and it loads them and [00:04:00] types them and does all ~of that ~that you like before. But then you can also use them for loading from a CMS or loading from an API. ~And ~we've ~got ~already got,~ um, ~adapters that loaders that have been built that people have distributed.

~Um, ~Because ~that's ~one of the nice things about these loaders is that they ~are, they, they are, ~can just be modules that you ~can ~load from npm and then ~suddenly ~you can just plug ~it ~in ~and, you know, ~if you want to load ~it's from, ~from Notion or from Storyblock ~or, ~or whatever, or Stripe ~or, you know, ~you can install these loaders,~ um, ~and then just query them in exactly the same way.

Noel: ~Yeah. Yeah. Very cool. I feel like. I guess in your, ~do you anticipate that most devs will end up just ~kind of ~pulling in these pre, ~you know, um, ~developed like modules that somebody else have worked on a loader that somebody else has built to like, Oh, you know, ~whatever ~I use Stripe and ~you know, ~some ~like ~hiring platform and it's CMS and these are the three loaders I use.

~So like, I don't like, ~do you anticipate most Astro devs needing to write loaders or will they just be ~pulling, ~pulling in content loaders that somebody else has worked on?

Matt: I have to say, knowing Astro users, a lot of them will be doing their own loaders, but partly that's because they're so simple. ~You can,~ the [00:05:00] most basic loader is just an async function that returns an array. So that is literally all you need to do. So people could just hit an API, return the response, bam, and it works.

So I think a lot of people will be doing that. Realistically, most people. will just drop in their loader that they need, ~you know, ~most of them are zero config beyond, ~you know, ~some API credentials,~ um,~ or just like ~choosing a, ~choosing a type to load them from. And ~it's, ~it's really,~ uh,~ just a very simplified way of doing it.

~So, you know, these, ~these are ~kind of ~designed to be the easiest way to get on board with ~these, ~these individual data sources. Cause obviously you've still got. access to all of the APIs that you can do for them like you can now. ~You know, ~you can still load data in Frontmatter and do everything you want, but this is just a way of having a unified, simple way that's got a, ~you know, ~this, you can always query it in the same way, and it makes it just a lot easier.

And you can swap them out as well. That's one of the nice things. ~You can just sort of, you know, ~you can decide you're going to have some pages with markdown and swap them out [00:06:00] and load some ~from, ~from,~ uh,~ CMS or something as well.

Noel: ~Yeah. Nice. Is there, so I I, I alluded earlier a little bit that I'm, I'm curious kind of, ~I want to get into a bit of a philosophical discussion here ~briefly~ as briefly as we can, because I feel like~ there's kind of, ~there's kind of two schools of thought on ~like, ~should this layer be a part of the framework or ~like, ~should the framework be agnostic?

Like whatever. We'll just have a function that you can call and pass data and we won't even make this loader piece part of the framework and ~like, you know, ~the. Devs can write whatever they want and bring it in. And ~like, maybe like ~there's a more loose abstraction where it's ~like, you know, ~we'll have ~like ~a function that you can call, it'll return stuff, but then we're not going to have an opinion on like how that data loader promise works versus having something in the framework that's like, okay, this is the abstractions is how it's going to load.

Was there much of a debate there like on whether or not Astro should have this kind of content layer abstraction through which data would be loaded You know,~ like,~ eh, like it'll depend on the situation. So we'll let people ~kind of ~write it themselves.

Matt: Yes, absolutely. Yeah. And ~I think, ~I think one of the things here is that ~very much, this is just, ~this is an extra thing layered on top because ~there, ~there is no way that the [00:07:00] other approaches are going anywhere. ~You know, we, ~we are not. saying everyone has to go down this route. ~You know, this is, ~this is a mistake that has been made in the past of people trying to force everything down one route and, ~you know, that's not, you know, ~that's not the right approach.

~And, ~but I think ~that ~there is still real value ~about ~having an opinionated thing. ~Because, you know, ~as developers, we know when you sit down in front of ~that, ~that new page, it's good to have a well paved path ~for the,~ for the way of doing these things simply. ~And, and, ~Most people, like 80 percent of the way, ~is, um, is ~going to be covered by the very common case for these things, ~you know.~

If you're loading one entry per page, and ~you're ~displaying a page with the data that you've loaded, ~you know, ~that will get you a lot of the way there. ~And ~you can mix and match. ~So, you know, ~you can use this for your core data, ~or, um, ~but you can also still inside your front matter hit an API directly and load data from somewhere else.

~And ~we are in no way trying to make these things,~ uh, ~replace one or the other. ~This is, ~this is an [00:08:00] addition ~to it that, ~that makes things easier to use.

Noel: ~Nice. Yeah. Has, has there been, I guess, ~is there any fear? ~I guess, like, ~cause I, I feel that ~the, the, ~the path that ends up being walked is ~if, ~if it becomes so clean and ~you know, ~like ~it's, ~it's super easy to use a loader, especially if there's one that's been defined for three of your four data sources, and then you hit one where maybe.

That,~ uh,~ like the content layer isn't the right abstraction that just becomes like the thing that everyone's thinking in. So people are like, ~you know, like, uh, ~especially new devs coming in just aren't even familiar with this, the like lower level, like the direct way of loading data in. Is there any of that concern or do you think it'll ~like ~stay more prevalent enough in the ecosystem where people will ~kind of ~always know what tools are at their disposal?

Matt: I think that The API that is now exposed for these content collections, and ~you know, ~HANA has been exposed the whole time, is familiar enough that it feels just the same as calling an API anyway. So calling getCollection doesn't feel massively different to get something from my API. the only difference is [00:09:00] that it feels the same because you can use the same API for everything.

So if you are calling getCollectionBlog,~ um,~ it doesn't matter if the next line down is,~ um,~ get from, ~you know, ~x, y API thing. ~They, ~they both return an array of objects ~or, ~or an object or, ~you know, ~something like that. ~They, this isn't, you know, We, ~we took a lot of inspiration and also a lot of counter inspiration from our old friend Gatsby.

~You know, ~this is, Gatsby is the kind of canonical example of a data layer in a framework. And,~ um,~ I know it very well because I worked at Gatsby a few years ago, many years ago. ~Um, ~and I think Gatsby got a lot of things right. ~Um, ~but they also got a lot of things wrong. And I think the biggest thing ~that was, ~that was wrong was forcing everything into this, ~you know, ~on a Gatsby page, you had to use the data coming through the data layer.

You had to write graph QL, even just for displaying an image. You had to write a graph QL query. We ~very, ~very clearly from day one just said we did not want anything like [00:10:00] that. We. deliberately wanted to make this the most,~ like,~ lightweight abstraction that you could get, really. ~You know, ~the idea here is that this should feel completely familiar to any developer that is working on an Astro page, and they don't need to learn anything new.

And in fact, the API is the same as the one that they will have been using for their markdown pages already. ~So, ~we're not forcing everything down there, because ~you can, ~this can sit next to all of your other APIs, and We also say that this is not the right thing to use for everything. ~You know, ~this is a build time API.

This is designed for the things that are going to be built ~when you are, you know, ~when you are generating your site. ~You can, you can, you know, ~you can query it during server side rendering, but it is querying the snapshot of the data that happened at build time. So this is not for your stock tickers or anything.

This is something like a CMS or a blog or something where when it changes, it triggers a build.~ You know, ~one of the great benefits of this is that it does, it caches all the data locally, and it means that you can do [00:11:00] very fast queries, you don't hit API rate limits, and,~ um, so ~this gives a lot of benefits, but obviously this also means that it's not going to be something that you're going to be updating constantly.

Now, builds can be incremental. ~you know, ~it works very quickly that you can, ~you know, ~you can do a very quick build. You're like, your second build is a lot quicker. So that's one of the other things that it's able to do. But at the same time, you're not hitting live data on this thing. So I like to think of it as something that if it's if you're happy with your data, taking, ~you know, ~a couple of minutes to update, ~then ~then that's the thing to choose.

~If you are, ~if you need the thing to be going right now, then You can still call it in, ~you know, ~call it from your front matter and it will work. ~And you can, ~and you can still mix them there as well. ~So, um, ~I think that's the best of both worlds really. And it fits in with a lot of the other stuff that we've been looking at as well.

So ~it's kind of, ~it's analog on the rendering side ~is, ~is this server islands thing, which we will come to in a bit. But [00:12:00] it's about working out, ~you know, where your data, when, ~when your data needs to be updated. And we don't want people to have to think about that too much. So we just ~sort of kind of ~make it that this is something similar to with their local markdown content.

You just query it, you get the data and ~You know, ~there it is. And you can just use it.

Noel: Yeah, ~I mean, I think, ~I think that those ~are, ~are both ~kind of ~interesting. Points in that it's ~like, ~yes, ~like ~not everything needs to be forced through this, but also the simplicity ~of, of, ~of just ~like, ~it's a function that returns data that you can then do things with. ~Like, ~I think ~that that is, ~is probably pretty potent, I feel for better or worse.

Like I think that there was a lot of ~reasons, ~good reasons that ~like ~everything in Gatsby was going through this GraphQL layer, but I think undeniably it did make it trickier for devs, especially ~like ~not people who are spending a lot of time in Gatsby to step into a Gatsby project and ~like, ~Figure out what was going on.

It was like, Oh yeah, this is this GraphQL query that gets built. Like we're using this external loader. This is the shape it comes back with. You ~kind of ~just have to know you can have ~like, you know, ~types and ~like ~auto complete and all this stuff. But it still is just this ~like ~very, ~you know, like ~kind of a Gatsby specific way of loading data in.

~Um, ~and I think. [00:13:00] Yeah. ~Like there's, ~there's reasons for that and ~like, ~it does give utility, but ~having, ~having it feel very close to the devs metal of just ~like, ~I know it just like types in looking through Astro, like ~the, ~the release here. It's ~like, ~I know this is like a simple function. It returns data. I can do stuff with it.

I think just is a lot more intuitive.

Matt: Yeah, absolutely. ~I mean, ~we're lucky because we don't have the same problems that Gatsby had with a lot of these things as well. ~You know, ~Gatsby had to force a lot of things into ~the ~the space of this SPA ~with, um, ~which meant that ~the ~all of the data, ~you know, every, ~every query that you're putting on Gatsby had to be loaded over the network, even if you didn't use any of it.

So that's why they were so keen for you to be using GraphQL, because Otherwise, people would just chuck the whole object, and then ~it would get, ~it would fill up ~the, the, ~the context, and, ~you know, ~you would be sending a JSON,~ um, ~file with all of it in, and it would be embedded in the HTML as well. ~I mean, ~Next.

js just ~decides, it ~seems to decide that they don't care about that, and that's what everyone does anyway,~ so, you know, ~because obviously Next. js went the other way, and you just chuck everything in there, ~you know, ~obviously. server components and so on ~change, ~change that somewhat. [00:14:00] But ~if you, ~if you view source on the next JS page, you may be horrified to find what's going on at the bottom.

~Um, ~but Azure doesn't have to deal with any of that because we don't have that same kind of dynamic data and everything in the way that things are being passed around there. So mostly it's being either statically rendered or server side rendered. ~Um, and. ~The only exception being with our, ~you know, the ~island architecture that Astro has.

So ~we, ~we keep everything static until you make the ~very, ~very explicit decision that you need something to be dynamic on the page, ~you know, ~so it's all HTML until you say you need that, ~you know, ~clicky button on there, or, ~you know, ~Login avatar or, ~you know, ~cart button or that kind of thing. And then that's sprinkled in there.

But that does mean that we don't just have to ship all of the data over the network that you might ever need for some, ~you know, ~dynamic reason on the page.

Noel: Totally. Do you find a lot of people reaching for Astro if they have,~ like,~ either a completely static site or something near it?

Matt: I think it's partly that, but I think one of the things that Astro helps is going the other [00:15:00] direction. And it's people who don't really realize at first quite how much of their site is static because, ~you know, ~coming from. ~Uh, ~background if you're using a site that is like entirely built ~with, ~with React or whatever, you are, ~you know, ~coming from the starting point that everything is dynamic, whereas with the Astro thing, you can just.

~You know, ~take it step by step and island by island and think actually Most sites if you're not building a dashboard, most of the site is normally static. ~So, you know ~Astro Can be used for building those complex dashboards and so on But really where it shines is the sites where there is this mixture of either being mostly content mostly static Or ~you know ~content ~with ~with bits of dynamics sprinkled around in it And whether that's the client You islands that, ~you know, ~allow people to have embed your React or Svelte or Vue or, ~you know, ~solid or whatever,

Noel: Yeah,~ right,~

Matt: components inside your page.

Or if you've got the server islands now, which is, ~you know, ~where you've got server side [00:16:00] rendered islands in there, which means you still have got the kind of almost zero JavaScript without needing to do,~ um,~ client side rendering, but still managing to have dynamic data mixed in.

Noel: ~hmm. Okay, nice.~ Let's talk about surrounds a little bit. ~Where is the, ~what is the distinction here? Like, how does that abstraction Mm

Matt: ~Well, ~server islands,~ um,~ are, ~I mean, if, ~if our inspiration for the,~ uh,~ content,~ uh,~ layer is Gatsby, our inspiration for server islands is Next. js partial pre rendering. ~Um, ~when I saw that when they first demoed that last year, I thought, this is seriously cool. This is really good. And I tried it out earlier this year, like before I worked at Astro, I thought this is really good, but I ~really, ~really dislike the implementation of it.

I think they've made some fundamental mistakes in the way that they've done it. ~I mean, you know, ~I say mistakes, decisions that I would not have made. And Astro is The decisions that I would have made and it's what we made, ~you know, ~when [00:17:00] we, and this is, ~you know, ~this was ~built, ~built by Matthew mostly, but,~ um,~ I, ~you know, ~the,~ uh,~ CTO,~ um,~ but it's.

~It's ~basically a ~much, ~much simplified kind of example of the Next. js partial prerendering. And for people who are not aware of what the PPR is, it's what the Next. js one is, that it ships the most, keeps most of the page static, and then ships the,~ like,~ dynamic islands in a stream along with the rest of the page.

So it pre renders ~the, ~the kind of the shell and then in the same stream dynamically inserts the individual components into the page. Now there's a lot of magic involved in there. You need logic and the CDN level for caching and so on. And you can't cache, ~you know, ~you can't cache the shell because it's all in one stream.

So you can't cache it in your browser and you can't cache it in the CDN. ~So, and you know, and that's. ~That's the Next. js way, ~you know, ~Vercel is, ~you know, ~I think if anybody has followed Guillermo's tweets, he's now not a fan of CDNs. ~Um, ~[00:18:00] We are fans of CDNs and ~um ~We love static html, ~you know, that's ~that's where we come from.

~So ~Static html, you know,~ it's ~it's been around for a while. ~Um, ~and it works pretty great So what server islands ~are ~are basically static html with a little bit of magic in there and it's a bit old school magic It's effectively ~It's, ~it's almost like it's ~kind of ~if you're around for the early days of Ajax and things like that, this is very much ~what, like ~what it is.

So effectively, what happens is ~you, ~if you've got any components on a page, whether that's an astro component or ~a, um, say ~a react component or whatever, if you've got your page,~ um, ~either statically rendered or ~server, ~server side rendered, but with ~like ~a long cache time, for example, you can mark individual components on that page with the directive server defer.

That's all you need to do. You just literally just add that single directive on there. And what that does is that means that when the page renders,~ um, like ~either at build time ~or, ~or whatever, it's rendered. skips the rendering of those individual components [00:19:00] and replaces them with a placeholder. It's like either an empty placeholder or you can specify something to sit in its place.

Noel: ~Hmm.~

Matt: Then it attaches a tiny little runtime on there, like a single little script tag, and that script tag does a fetch. So it's all it's got in it is a little thing that makes a fetch to an endpoint,~ um,~ which is a tiny little server side rendered bit of just that individual component. And then that is loaded, and then it's just ~like ~swapped into the HTML, ~you know, ~it creates an HTML fragment,~ um,~ and then just swaps it in place.

And it works really well, ~you know, ~it's dead simple, you can view the source and you can look at it and go, I know how that works. Now, I spent a lot of time looking at the ~You know, ~Next. js PPR thing. I think I know how it works, ~kind of ~now, but still not totally sure. But,~ um,~ this, ~I mean, ~this, I have to say, this was before I worked at Astro.

This is when I worked at Netlify trying to make Next. js work. ~Um, ~but this is a, ~you know, ~this is very much within our,~ um, the, ~the kind of Astro philosophy of being cross [00:20:00] platform. ~You know, ~this works anywhere that you can do server side rendering for Astro, which, ~you know, ~Whether that's your own node server ~or, ~or Vercel or Cloudflare or Netlify or whoever, it just works.

And it's mostly just HTML. So it's just genuine HTML files on disk being served from the CDN with a little bit of magic in there. And this is really cool because I think, ~you know, ~people, the first thing that people say who are pretty familiar with Astro when they see this is, why is this different from client islands?

~You know,~

Noel: I was about to ask. Yeah. ~Like, ~wait, like ~how, ~how does that interaction work? ~Yeah.~

Matt: Yeah,~ because, because with, you know, ~with client islands, they have a way to have a static page with some things that are interactive. So you could have your, ~you know, ~the example that I gave before of ~a, a, ~a page with, ~you know, a, say, like ~a user's avatar or something on it that you can, ~you know, you could ~have a dynamic thing in there, ~a bit of, you know, ~like a React component, hits an API, loads something and sticks it in there.

~Oh. ~All pretty simple and you can do that ~with, with, um, ~with Client Islands today.

Noel: ~Hmm.~

Matt: Now, what Server Islands does is it server side renders that, so you can still have no JavaScript. ~So, ~it can still be [00:21:00] super duper fast, but it can have that individual thing rendered personally with that user's cookie. And shipped into the browser.

So you will have the like overwhelming amount of the page is just the static thing that everybody sees and then the little island is the bit that's either personalized or Dynamic or ~you know, ~I think a great example is It's it's the one that we used for our for the demo. It's also the one that next.

js uses for its ppr demo ~um, ~which is ~uh ~an e commerce site, ~you know, you've got a You ~For an e commerce store, you Most products are changing, ~you know, ~not very often, ~you know, ~they're not changing hundreds of times a day, ~you know, ~on a massive site, they will probably change a few times a day. But generally, they can be pretty static.

But your page will have dynamic stuff on it, like stock levels, or ~Um, ~comments or ratings or personalized stuff for that individual [00:22:00] user and what you can do with this is pre render all of the kind of bits that don't change so often, or, ~you know, ~server side render them with a, ~you know, ~10 minute expiry time, for example, and then you're done.

Have the islands that are marked in there that load as the user views them Now if you want to get super advanced you can set individual cache rules for every single one ~I mean ~most people don't want to do that if you're the sort of person who likes tweaking cdn cache rules ~Um, ~I think I might be one of the few who does that but it's something ~that you ~that you can do ~Um, ~but the important thing is that it lets you do it per island.

~So, ~because it's literally just a fetch request. That's all it's doing. It's just ~hitting, ~hitting an API endpoint, doing a get. And it's like there's a teeny little page with a single component in it. Because it is a teeny page with a single component in it. That's literally what it is. ~So, um,~ that's what is then just gets pushed ~into, into the, um,~ into the individual island.

~So, ~I think it's really cool. I really love the architecture. I think the, what we've built there [00:23:00] is. a brilliant combination of the best of things that Astro can do. And, ~you know, ~for uses like e commerce, where, ~you know, ~every millisecond counts, you cannot get faster than a static HTML page. ~And that's, ~and that's the thing, ~you know, even, ~even if you're doing like magic at the edge with, ~you know, Like ~PPR or something like that.

You still got to, you're still doing some like extra special stuff of pulling things from caches and data stores and all that kind of stuff and doing with the streams with this, you've literally got an HTML file that's being served from an edge CDN, which is about the fastest thing you can do, ~you know, ~when it comes to the web, you've got an HTML file and you ship it.

And ~that, ~that means that you've got that thing visible immediately. And so you've got this time to first bite that is. impossible to beat. And, but you can put placeholders in there as well. So you don't get your big layout shifts and things like that. And you just get it, ~you know, ~bringing in the dynamic content ~as it's ~as it's needed.

And that's a super [00:24:00] powerful combination. And, ~you know, ~I think It's going to take a little while before people really get the power of it, but I think ~I'm, ~I'm super excited for what people are going to build with this because I think this is just like one of the,~ you know, the most, ~most exciting new primitives in there.

And ~I think, ~I think it's a model that other frameworks. will probably be taking on as well, ~you know, I'm, I'm under, you know, ~I'm not pretending that I did anything other than copy the concept from Next. js. And I think it's brilliant one. ~I mean, ~the execution was completely different. But I think this concept of having these static shell with server rendered things ~is a ~is a, ~you know, ~the best new island architecture thing that's come along for a while.

~So, you know, I, ~I hope that ~other, ~other frameworks,~ um, ~copy it too.

Noel: Yeah. ~Is there, ~is there any ~kind of like ~kind of hierarchy ~that, ~that comes to be here? ~Like, say, ~say I have something declared as a server Island, ~can I, ~can I then have components within that component that are declared as client Islands? Or is it like ~once, ~once you ~kind of ~have pulled the eject switch into server Island mode, that's what's going on

Matt: Nope. You can do that. You can [00:25:00] mix them. You can nest them. ~You can. ~I don't think ~you can't put a, ~you can't put a server islands inside a client

Noel: client Island. ~Yeah.~

Matt: other stuff inside client islands. Cause they're, ~you know, they're, ~they're,~ uh,~ client rendered things. So you can't do it that way round, but yes, you could absolutely put client islands inside server islands.

And that's, ~you know, ~that's quite a common thing, ~you know, ~so you would use that for say your shopping cart or something like that, ~you know, ~you would stick some buttons in there and things like that in, in there. ~So, you know, ~you can. Definitely mix and match these and you can literally make an island that is a fully dynamic, ~you know, ~React island that is a client island and server island at the same time, ~you know, ~so ~it's, ~it's both client side dynamic and server side dynamic.

And, ~you know, ~I think that's a very powerful pattern too. 

Noel: ~Uh, yeah.~ So like ~kind of ~depending on the context of where something is loaded, you can have it be, yeah,

Matt: So it's, it's effectively something where it will be loaded, but as soon as it's loaded in, it is interactive on the client as well. So it's, it ~kind of ~gives you both, but I think, ~you know, ~my favorite is ~having it a non, you know, ~just having it ~as a. ~as a standard Astro component. So it's [00:26:00] super fast and HTML only, but server rendered.

So it can ~be ~be fully dynamic. And ~it feels, ~it feels just like writing HTML with components. ~You know, it's, ~it's like writing any other Astro thing. I think it's amazing that what they, ~you know, ~we've, ~there's ~been managed to do with making it literally just a single directive that you add ~on ~onto the component.

There's no extra stuff in there, and there's no magic, so it's not happening unexpectedly, which is, I think, one of the other things. This is something that you opt into, and then once you've opted into it, it's like the simplest ~way ~thing you need to do. You just literally just ~drop a, ~drop a directive on, and it just does it, and it sets up all the endpoints and does ~all of the, ~all of that stuff for you.

Noel: ~Nice is I'm, ~I'm curious, I know ~we're, we've, ~we've covered quite a bit here, but we should work towards wrapping up. I'm curious, what's the,~ like, ~migration path here? You're saying ~how, ~how easy it is to do this. ~Like ~say you're on Astro four right now. Is there anything to watch out for, ~to ~when upgrading, or ~is it, ~is it pretty easy to ~kind of ~flip it and start trying to instrument some of your components?

Matt: ~It's, ~it's, in most cases, it is simply a case of [00:27:00] just adding server defer onto it, and it should just work. ~Um, ~I'm sure there are edge cases, and,~ um,~ please report them, ~you know, ~open issues or jump into Discord,~ um,~ astro. build slash chat, and ~it's, it ~give us, ~you know, ~give us some feedback on it, but I've found it to be really robust, ~you know, There were, ~there were limitations, but the limitations are mostly pretty similar to the client island limitations as well about the way that you can pass props to them and so on.

You need to have a, you need to think about the fact that it's passing ~these, uh, ~your props over the network as well. So you need to think about that and remember that, ~you know, ~don't have a flag that ~is ~is admin on there. ~Um, you know, check, ~check your authentication inside the component and things like that.

~Um, I mean, ~the props are encrypted, but this is, ~you know, ~just sensible,~ um, to, ~to not trust the props coming ~into the, ~into the component. ~But, ~but generally, it is literally just a case of adding the directive and it just works. And then you suddenly have ~the, ~that great mixture. ~I mean, ~you will then want to [00:28:00] start thinking about how to best make use of that.

So you will probably want to make sure ~that say that the ~that the shell of it ~is now server ~is now statically rendered, for example, or, ~you know, ~set a long cache time or something like that, because otherwise, ~you know, ~what's the point ~if you're, ~if you're just doing SSR ~the same, you know, ~in the same way.

~Um, ~but ~it's, it's really, it is ~really just clicking it on ~for, ~for an individual component, and it will just work.

Noel: that's very cool. ~What's, what's kind of, ~what's coming down the pike? What's next for Astro in the coming months? I'm sure this is all got to get finalized and there'll be some bug ironing out, but is there anything else that's,~ uh,~ has you excited?

Matt: ~Well, ~we've got, ~I mean, as, ~as you said,~ the, the, ~the next thing is stabilizing all of this and making it. ~You know ~ready for the release ~in the next ~in the next few months and getting it out there ~Um, ~but there are a couple of extra goodies that are coming that i'm super excited for and I think people are going to love ~um ~And ~they're really ~they're really simple and i'm not going to talk too much about them at the moment because they're still not certain though People may want to go and have a peek at our rfcs to see some of the ideas in there, but they are [00:29:00] solving some things that everybody has problems with ~on, ~on the web at the moment, like some of the most annoying problems on the web, and ~they are just ~the developer experience on this is going to be so good.

And it's going to be so easy. And I think people are going to love it.~ You know, ~we're not 100 percent whether or not these will make it into 5. 0. ~When it's ~when it's stable. Should do, hope so. But, ~you know, that's, ~that's ~kind of ~looking like that'll be the way that ~we're, ~we're going. So we'll have these big new things that we've got coming here, and then some juicy treats that ~we're gonna, ~we're gonna throw out as well,~ um, ~which I think, ~you know, ~people are gonna love.

Noel: Nice cool. ~Um, ~that sounds awesome Is there any way that you'd recommend ~kind of ~people keep their ear to the ground? ~How should they ~how should they stay aware of what's going on

Matt: ~Well, I mean, ~if you want to be minute by minute, ~jump and ~jump into our Discord and say hi, we're all in there all the time. ~Um, ~Follow us ~on the, ~on the socials,~ um, on the, um, ~we are astro. build on, on the Twitter. ~Um, ~and,~ um, but ~just come along and see us on GitHub as well. ~You know, that's, that's where, that's where the stuff is.~

~You can, you know, ~you can,~ um, ~see what's coming along. ~We, ~[00:30:00] we ship. A lot, very quickly, ~you know, ~we have miners out every two weeks and miners all have new cool stuff in every time. So we are not one of those that sits on a release for two years and, Doesn't let anybody get stuff, ~you know, we, ~we will ship the cool stuff as soon as it's ready.

And,~ um, so, you know, ~keep up to date, come along, follow our blog. We do very detailed blog posts about every one of our minor releases. ~Um, ~and just give these things a try and, ~you know, ~particularly content layer is the thing that I've built. ~So, you know, ~talk to me directly. If you've got some comments and feedback on that.

~Um, if you're. ~If you're talking about server islands or any of these things,~ um, ~then, ~you know, ~just give us some feedback. ~We really, ~we really need to hear about these things, particularly for the, ~for these, um, ~5. 0 things that are particularly new and likely to need a bit of feedback.

Noel: Nice. Cool. ~That sounds ~that sounds exciting Thank you for ~uh ~coming online and chatting with me matt. It's been a pleasure.

Matt: ~Well, ~thanks for having me. It's been [00:31:00] great to talk.

Noel: ~of course, ~of course. Have a good one