What's New in Astro

My name is Fred, I'm one of the co-creators of the Astro web framework. And this is a talk about the future of Astro, but really, it's a talk about the future of the web.

I have some exciting things to share, some announcements, some cool behind-the-scenes stuff. But no matter what tech stack you work on, there's gonna be something relevant to you and interesting. There's a lot of cool future stuff that's big impact outside of just Astro. So, I'm excited to jump into this.

You know, when we're working on Astro we have this idea of a couple of design primitives that we like to keep in mind as we design the framework. And one of the ones that matters a lot to me is this idea of pushing the web framework. Pushing the web forward with a web framework. We're not just building another web framework, we're trying to challenge the industry, different status quos, different ways of doing things that we think are outdated or deserve to be challenged. We want to give developers more choices on how they build things.

We want to give developers more choices on how they build things. For example, when we created Astro, one of the first things we were looking at was the state of performance on the web. And JavaScript frameworks specifically, they have this promise of a full JavaScript tech stack. Server, client, unified, one-language, Chef Kiss. And they all have their Hello Worlds, their blogs, their showcase sites that all look good and perform well.

But when you get down to the real world performance, it left a lot to be desired. These tools promised a lot, but at the end of the day, they shipped a lot of JavaScript. And it made it really hard for a developer to work in those frameworks and also ship a fast site. So, if you look up here, this is, you know, no one up here is batting above 50 per cent, right? The majority of sites are not fast. They're slow by this definition of Core Web Vitals. And this is across the entire net. This is 10 million sites measured by Google, HTTP Archive.

So, promise of power and all these great things that the web provides. But then the end user experience, slow page load, laggy interaction, really poor performance on the whole. So, this was something that we wanted to come in and challenge. This idea that you could have a unified tech stack, JavaScript everywhere, but it didn't mean shipping JavaScript, all of it, to the client. It didn't mean SBA. It didn't mean big apps. And this is what Astro was born to kind of solve and I think the data speaks for itself. It's our biggest kind of accomplishment so far is pushing this narrative, this idea that you don't need so much JavaScript. You can have a fast site and DevTools that you love. You can keep using React or Vue or Svelte. Keep it all, but have a web framework that optimizes your site at a much higher level.

So, this was island architecture. This is the big idea that we pushed forward, this idea of don't think of your site as an app. Think of it as a page of static HTML. And those interactive bits you need, those are the hydrated components on your page. We're going to isolate them, hydrate them in parallel, but they're little islands of interactivity across your site. It's not one big app. So, that header component, that layout component, those things that are static, you don't actually need to ship that JavaScript.

Just ship the HTML, let the browser handle the rest. So, this was super, super powerful. We followed that up with content collections. This was the idea of content built into the platform, built into the framework as a primitive. Static site builders have been doing this forever. Gatsby had done this. But we wanted to bring a modern take on this using TypeScript, front matter validation, schema, everything optimized for a modern dev experience where you're getting types out of the box. You're getting automated types. You don't have to define them all yourself.

And then lastly, Bruce mentioned this. This is one of my favorite features to come out of the web platform in the last ever possibly. This idea of Vue transitions. So, if you haven't seen this, it's going to look like magic. I'm going to get to it in a second. This idea of letting the browser handle an app-like experience of navigating from page to page. So, it feels like an app, it feels like magic, but at the end of the day, the browser is actually morphing, sliding, fading, as you navigate from page to page. It's really cool. And we actually partnered with the Chrome team to build this API into Astra. So, it's not just something like we support. It's actually an API that we expose to you, so you can control this in your site with a couple of lines of directives that you can just kind of sprinkle around. So, no JavaScript, app-like navigation on the web. Really, really cool. And that was a big feature we launched last year.

All right. So, future. New year. What are we going to work on? AI? Are we working on crypto? No, we're working on the metaverse. This is the most important... No, I'm just kidding. This is not what anyone is doing anymore.

But I do love that image. No, I want to talk about our vision for the future. I want to talk about the three things we're working on this year that are going to push the web forward. And really, again, this isn't just our vision for Astro. It's our vision for all content-driven websites. So, if your site exists to get content to the user, you know, a blog, a marketing site for your company, an e-commerce site, if your main purpose is getting that to the user fast, letting them have a great experience, converting, not bouncing, all those things, then Astro is a web framework designed around that specific use case. If you need a big, heavy dashboard or a big, heavy app, there are other frameworks designed for those. We're really focused on that content-driven site, and we want to push ideas that we think all content-driven sites should be exploring.

So, three new features, all building on the exact same things that we've been exploring over the last four years. Islands, content, and view transitions. So, let's jump into it. We've got three cool things to share, three cool demos, three cool announcements. We've been doing a launch week on Twitter, so one of these things hasn't even been launched yet, totally new. You all have seen it for the first time, so very exciting stuff.

We'll start with view transitions. Again, this one feels like magic if you've never seen it. You're looking at Spotify here and you think, OK, big JavaScript app, heavy desktop app. This is really heavy stuff, right? But the reality is this is a clone of Spotify. We did not build Spotify, I promise. Built with Astro, leveraging view transitions. So, this is not a JavaScript library that's powering all this. This is actually no JavaScript written by the user or by the developer. The browser is doing the work of morphing and fading and transitioning from page to page. All the developer's doing is basically telling the browser what goes where, what's the before, what's the after, and the browser is going to morph from before to after for you. If you haven't seen this, this is one of the coolest things, because it takes this thing that was a JavaScript feature, a SPA feature, and now it's something that any website can use. It's totally HTML, totally CSS, no JavaScript needed. Takes work off of our plate as framework authors, takes work off of your plate as a developer. The browser's doing the heavy lifting here. It's really, really cool. So, native browser API.

You're sprinkling these directives to kind of name and fade transitions. And one of the cool things that we did was we basically built this for the future. But realizing specs, they take a while to get out there, right? You've got one browser supports it. The other doesn't. One browser shipped it incorrectly, and now you're going to have to support that forever. One of the cool things we did was basically build this in a way that we're going to abstract away all the browser-level implementation details. You're just going to have to worry about these transition directives, and that's going to give you both backwards compatibility. It actually works in browsers that don't even support this as a primitive yet. And it also gives you forward compatibility. Basically, as browsers start to adopt, you can make a one-line change or whatever you need to do, but we're going to handle that migration to the new thing so that your code stays exactly the same.

Maybe a config change, maybe one or two lines of change, but the majority of your site, these APIs that we've designed today, will work into the future. To do this, we had to get a little weird, a little funky. We had to inject a JavaScript router, basically. The way that browsers implemented this was incrementally. They're going to basically give a JavaScript API first, and then HTML, CSS API later. And so we had to hook into that JavaScript. We had to basically take over navigation for your website, which, if you know anything about Astro, it's like the one thing that we swore we would never do, and here we were shipping a router, shipping JavaScript app behaviour to power this thing. Its whole goal is to get rid of the JavaScript and let the browser do this work for you. But we made a bet. We basically said, all right, we'll take this as a shortcut. This will help us get through this backwards compatibility phase, and as browsers adopt this, developers will be able to remove this, we'll be able to remove this, and eventually it'll just all bleed away into the platform. One day, JavaScript won't be needed. We can remove this as a workaround.

Literally this week, we couldn't have planned this better, total coincidence. This week Chrome and Microsoft Edge both ship support for this final HTML API, giving you zero JavaScript view transitions, no JavaScript needed. You're clicking a link just like you've been doing for decades, and the browser is handling that transition for you. Zero JavaScript, all CSS. Really, really powerful and built into Astro. So Chrome, Edge, more browsers on the way, it's this really, really cool feature.

So Chrome, Edge, more browsers on the way, it's this really, really cool feature. That's all you need. You put that on your page, and it's telling Chrome that you've opted into this new feature. So this has to be on the beginning and the end, the start and the finish, wherever you're coming from, wherever you're going to. But the browser detects it on both ends. It says you've opted in, and it's going to power that with a default fade. You can, again, morph and transition however you want, but this is all you need to enable this feature in your site.

Again, today. It's available today in these browsers. If you used our backwards compatibility, we had this view transition component that was kind of injecting that router, taking over for the browser. Now that can just all bleed away. Again, remove that, add the style tag, and you're good to go. And again, looks like the same demo, because that's the point. It is the same demo, but it's actually a totally different recording made a year later using this actual in-browser power. So available in Chrome, available in Edge. It feels like magic. It's app-like. But again, all you're doing is sprinkling some CSS around your page. The browser is taking care of the rest. It feels like an app. It isn't. It's just HTML. Really, really cool. You can migrate whenever you're ready. It's available now. You can use the backwards compatibility now. Or just keep an eye on it. This is gonna be coming to more browsers. As browsers are getting upgraded and adopted, more users will have this functionality. It's a really, really cool feature that we built into Astro a year ago, and now the kind of fruits are being harvested.

It's there. It's available. It's one of the coolest things to be happening in the web right now. So check this out. They're called View Transitions. Just launched in Chrome. Safari, I think, just announced JavaScript API access. So again, that backwards compatibility, we can handle this for you. This is coming to the web, and it's really, really powerful.

All right, let's talk about content quickly. If you've used Astro before, you'll know that we have this content primitive, this idea of collections. So you put your markdown in your repo, put them in the right folder structure, and we're gonna do all this work for you to fetch them, load them, parse them, schema validate them, and give you this TypeScript API that knows your collection names. It knows the IDs and the slugs that you're trying to get. It knows the shape of your data, right? This isn't gonna be a runtime error. We're giving you the validation. We're doing all that for you at the framework level.

A couple limitations. We built this for local content, so our own Docs needs inspired a lot of this, but also Static Site Builders, they've been doing this for ages, they do blogs, personal dev blogs, content. Local content, super powerful, doesn't scale to remote content. It has to be markdown or some custom file type, but it has to be in your repo, most importantly. And it has to live in a certain rigid structure. So a lot of the power we take right now is that if you structure it this way, we can infer a bunch of things and give you a really cool experience. But as you scale up, you start to hit the limits of that as you grow.

Lastly, it's just as you start to hit the limits of that as you grow, you're also dealing with the fact that we basically store this all in memory. So you'd be surprised, this works pretty well for large sites, static sites, but when you go to serverless, the idea of loading all your content into memory just to serve some page, it's pretty brutal on serverless, SSR rendering times. So Netlify, Vercel, whoever you're deploying to, it can really hit some scaling problems. But content, this is not a new problem on the web, we have CMSs, we have remote data. We should be able to solve this at the astral level.

But content, this is not a new problem on the web, we have CMSs, we have remote data. We should be able to solve this at the astral level. So one of the things we're exploring this year, early RFC but still something we're actively working on, is the idea of a more powerful content layer. Basically, Gatsby the good parts. Can we get this idea of a unified content layer that isn't just about Markdown, but it's actually about wherever your data lives, remote, local, pull it all into a unified data layer that then you can build on top of reliably, consistently, and with well-documented APIs. So support the same stuff. Backwards compatibility matters a lot. This idea of, if you just want to use a folder of Markdown, great. Or MDX, fantastic. We'll give you helpers to work with that. If maybe you want local content, but you want to break out of this rigid folder structure, you want all your entries in one data file, like a big JSON array, great, you can do that too. You want to write something totally custom, so you want to provide just an inlined array of data, you want to go and make a fetch call to some remote API, that's awesome, you can do that as well. Whatever you want to do, custom loaders.

And what we're most excited about is this idea of making this pluggable. So, you can write your own custom loader, you can package that up, and you can ship that to NPM. Now, anything can be pluggable, anyone can consume that. You can have your CMS like Storyblok. You can have Instagram, Twitter, whatever you want to load content from, pulling this together in a composable way, into a single unified content layer. So there's plenty more on this API, this is just kind of a sneak peek at what I think is most exciting about it. It's pluggable, remote, local, whatever your data looks like, you can pull it into this content layer.

One thing that I don't have time to mention, but also very cool, I mentioned scale. Using a real database this time, not just a giant in-memory blob, but actually embedding SQLite into Astro itself to power this will help us scale to tens of thousands, hundreds of thousands, however much content you have. SQLite's a really, really dependable database, and it runs embedded inside of Astro, so no Docker containers to spin up. Really cool technology that we're exploring here. It's still Stage 1, it's an early RFC, but this is what we're actively working on this year.

Alright, last. This is one we haven't talked much about at all yet, so you all are kind of seeing this for the first time. What are we doing about island architecture? What's the next play there? Again, I mentioned this idea of islands of interactivity. This is a really helpful illustration from the Deno team, this idea of static HTML, islands of interactivity. This was our original front-end architecture, it's optimized for content sites, when most of that content is just, you know, not about user apps and big, complex state.

It's just about getting content to the user. This can be really, really impactful to performance, still using all your same favorite web frameworks. You only hydrate what you need, you get static HTML, it's fast. That's the big thing about island architecture.

But front-end performance, JavaScript versus HTML. That's only one part of the problem. There's also the how. So if that's the what you're sending to the user, how are you sending that to the user, is also a huge question of performance. Developers today, you're kind of stuck with this trade-off. You have static HTML, put it behind a CDN, get static global caching, tens of milliseconds to deliver a page to the user. This was like the original promise of JAMstack, right? The simplicity, the speed, static, is really fast and really simple.

If you've ever deployed a static site versus deploying a big, heavy server, you know the difference. But you lose out on a lot of things. One of those is personalization. Anything dynamic, anything personalized to the user, the second you start to embed that in your page, all of a sudden you actually don't have that static page anymore. If your face is showing up, your little user avatar on the top right, that's not really something you can cache for everybody. All of a sudden, everyone's going to see your face when they hit that page, because you accidentally cached personalized content globally. And so you get that problem of having to choose between these two options, which aren't really, you know, neither side is really correct, right? You have performant, fast but simple. You have super personalized but heavy and slower, right? You have to hit a data center now to render that content because you've skipped the cache.

This is something we're really excited to be exploring because we think that islands holds the answer for this as well. We think that server islands is a new concept that we can bring to island architecture, the first change we've made to this since the creation of Astro that doesn't just tackle JavaScript versus HTML, but tackles the idea of personalized content inside of a static shell.

The API that we want to ship is super simple. It's just the idea of, like you would hydrate a client component with a client directive, we want to give you a server directive. This is going to give you something that you can attach to any sort of personalized content on your page and tell Astro, this is personalized content, this comes later, this is not a part of that static shell that you're going to be rendering. Defer the rendering to later. We basically render a fallback in your page, so some skeleton that can go with a full page that's not personalized, it's super static. We're going to inject a small script that's going to go fetch this rendered content later.

So we're going to go fetch it from a separate endpoint, render it back onto the page, and then stitch it back in to replace that fallback on the page. So, really simple. This is a very simple demo.

It's going to be looping so you can see it a couple times. You see that first response? 20 milliseconds, globally cached. No matter where you are in the world, that's coming from a data center that is close to you, not the one that it's running in Virginia. Global caching on that HTML.

But then the personalized content, that's being fetched separately. So as soon as that page comes, the script runs and it goes and fetches that personalized content. I've added a pretty absurd, I think, a little over a second of delayed time just to see what that looks like. The browser's waiting. It fetches it. It does interrupt the majority of the content on your page, and it still comes back, hydrates that dynamic personalized content. So this is our answer.

We've been watching the React team for almost a decade now work with suspense, and then server components, and then streaming, and now partial pre-rendering. And we've learned a lot from them, and we've also been getting asked about this feature for pretty much since the dawn of Astro. What is our answer? Our goal is to leapfrog to that kind of end state, which is what you're trying to do is solve a problem for the user. Personalized content, static performance, that's the kind of holy grail here that we're trying to deliver. And we think that islands are the right primitive for that.

You're already thinking of your page mostly static. You're adding on these islands of interactive content, and now you're adding on islands of personalized content. So it doesn't have to be JavaScript. It could still be static HTML, but it's dynamic. The content itself can change hourly, by second, by minute, however much you need. But it doesn't impact performance. That's the big thing. Your page becomes a shell, static, globally cached. This isn't proprietary. It works on any CDN, so it works anywhere you want to host this. It's something we're really excited about. It's really going to, I think, change the formula when we think about these two things, personalization or performance. We think you can have both. So again, early, early, early stuff here.

This is something we're working on this year, so it's not eight years away, I promise. It's coming. We're exploring it, but really, really excited to be shipping more of this stuff and more experiments later this year.

So this is what we think the future of Astro is. It's about investing and pushing these same primitives forward. Zero JavaScript view transitions are here now. This one was a trick. It's already here. You can use it today.

A more powerful content layer and a more powerful personalized server island, both in early RFCs, but still on their way coming early this year as we develop and explore this more.

So this is our vision for the future. These are technologies and practices that we think any content site should be taking advantage of. Just because we're building them in our framework doesn't mean you can't explore these on whatever tech stack you use. So if you're using Vite, SvelteKit, Remix, Next, Nuxt, whatever it is that you use, these are features that you should be exploring no matter what. They're pushing the web forward, and at the end of the day, that's why we're here at Astro.

So I'm excited to be exploring these things, excited to share them here with you all. Hopefully you took something away from this. Thank you so much for having me.

How would you compare Astro components to the React server components? They're very similar. Both projects came into the web around the same time. This idea of the client-side JavaScript, we gotta do something about it. React took the approach of, let's build it into React, and we took the approach of, let's build it into a lower-level framework. But an Astro component is essentially a server component. We basically don't have the concept of client components. Instead we say, go use React or Svelte or Vue for that, but we're OG, only server components. We've been doing it for a while.

So the essential difference is that the Astro ones are just better. It's more limited, but on purpose. It's server-only, and the idea is that that pushes you to think more as a server app. Think more like a Laravel or a Rails. You're building an HTML at the end of the day, and then those islands of interactivity are doing the work that React is currently doing for everyone.

Gotcha. I think I know the answer to this, but I'm not sure, so I'm going to ask it because somebody asked it, and I want to reassure myself. Why do we need an API in Astro for Vue transitions if one could use the browser API directly? That's a great question. There's a couple of things we did with that. One was we wanted it to be backwards-compatible, so you don't need to wait for the browsers. You'll use this backwards-compatibility layer. Our API ties into that. The second is accessibility. The browsers made very good choices, but one of the choices that we disagree with is this idea that by default, these animations are going to, whatever you tell it, it's going to run for everyone, and our take was that for page animations, if you have a sensitivity to movement, you're in a browser that says, I prefer reduced motion, we should be honouring that. There's a couple of things around accessibility and how they work at the lower level, which anyone could be doing themselves, but we think we can offer a more opinionated take for the use case which is navigating from page to page. We don't want every user to have to worry about things like a lower-level accessibility API if we can handle it for them. The third is just making it easier to use, so there's a couple of things like fade and wipes and slides where we can actually just give you a named transition and you don't have to go and figure out what are the keynotes, keyframes, what are the animations. You can basically just get automated for you wrapped up in a name, and then you can distribute those yourself, you can make them pluggable. There's some really cool things we can build on top of it there in that way.

Okay, I'm going to drill down a little bit on that because, as I mentioned, I really like view transitions and I started life as an accessibility consultant, so you've pressed one of my buttons. So, if a developer used the browser primitives, they could indeed wrap it all in a media query to not show the animations if the user prefers reduced motion. But they have to remember to, whereas if they use the Astro Layer APIs, you will do that remembering for them. Yes. We try to basically use our leverage as the framework to ship an opinionated set of, okay, these are page navigations. A lot of what the browser wanted to do is not take an opinion stance, every animation can't work for accessibility, every prefers reduced motion, every animation disabled, because that's not really the intention, and you're the expert here, but the intention is that prefers reduced motion doesn't mean no motion, so the browser didn't really want to go that far to say no motion with these page view transitions. But we know that you're doing a larger page navigation, we know that, as a default, it makes a little bit more sense to have that opinion.

As an accessibility person, I very much approve of tools helping developers to remember this stuff. And again, if you don't like our defaults, you just implement it yourself. There's nothing about us that's preventing you from using the native API. We're like the helper wrapper on top of that. There was another question, I can't see it now, but somebody was asking that Chromium has two different levels of view transitions. There's the one that works in a single document, and then there's the cross-document one. Safari has so far only implemented the first, which is view transitions within the same document. Will Astro polyfill the level 2 for Safari until such time as Safari implements it? Yeah.

Will Astro polyfill the level 2 for Safari until such time as Safari implements it? Yeah. So up until last week, no one had implemented that level 2, and for the last year, we've been shipping that polyfill as the best you can do, unless you're working with Canary or beta browsers. If you're working with a mainstream browser, that level 1 JavaScript SPA API was what we tapped into to leverage this. So we would do that work of basically shipping a router so that you could use that JavaScript API, and what's new as of this week is the idea of actually being able to, for the first time, remove that router and leverage the full level 2 in Chrome, Edge, and any Chromium browsers that want to update to that latest.

Brilliant. How much longer have we got? I think we have hours. So a few quick-fire questions of people asking, can I use X with Astro, or can I use this thing with Astro? First, Fred, what CMS would you recommend for using with Astro? We work with a lot of CMSs, Storyblok. They're a sponsor here. They're one of our sponsors. Old sponsor. This sounds like a plant question, but it is actually a great CMS. So they've worked with us on making sure that Storyblok's support in Astro is great. They've been providing a ton of resources. They really care about Astro's support for Storyblok. It's been a joy working with them, so yeah, they're definitely my pick.

Gotcha. Fred, would you recommend using Astro for something like a video sharing website like YouTube? So, the content-versus-app dynamic I find fascinating. Like, I think you can think of any site on a spectrum from that left to right, and it gets really wonky when you're trying to think, okay, is a video-sharing site a content site, or is that like an app-like dynamic experience? I'd argue that it's mostly a content site. It's about getting a video. It's getting content, even if that content is video, not HTML, to the user as quickly as possible. But as you start to think about what a video site looks like, there's recommendations, there's comments, the more and more YouTube, or Twitch, I think is another good example, starts to feel like an app, the more and more that's not really what Astro's designed for. If everything on your page is a client component, sometimes a framework that's basically shipping an app might actually be a better fit for that. So, the performance story for Astro is great, but at a certain point, if you have a lot of client-side state, that's where we start to say consider your options. There are a ton of great web frameworks. That's kind of the balance that we like to think of is how many components you actually have on the page. If it's everything, you might need a SPA. You might need a web framework that's designed for apps, not for content sites. I think it's interesting that you said that there's a spectrum between website and web app rather than they are inherently different things. Personally, I think that view transitions blurs that distinction even more because now you can have what feels like a single-page app, but it's actually multiple HTML documents, or what in the old days we called a website. Yeah, I love that Spotify example because I think of Spotify as such an app, but actually, how much client interactivity is there? There's clicking the songs. There's playing the music, but it's actually not… You can get really far I think with just HTML as you can see in that example. So, I think there's a ton of things that we think of as apps that aren't as interactive as you'd think, and that's where I think view transitions is going to push that considerably. You don't have to ship something that's going to take seconds to load up in your browser if you can just ship the HTML and hydrate it after.

Brilliant. I could talk for hours about this, but the red light of terror is flashing. So, folks of JS Nation, please give it up for Fred Coolshot. Thank you. Thank you.