What’s New in Astro

All right. Thank you all. Thank you for having me. All right. Let's talk about the future, the future of JavaScript and React and a little bit of 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 we see that so tied into the web platform. React is one of the biggest frameworks that you can use with Astro, so we're a very generic kind of agnostic web framework. But Astro and React is chef's kiss, beautiful. I want to talk about the future of React. And I have some exciting things to share, some cool announcements. We've been tweeting all week about a couple of these things. I want to dive into some of them, share some new things that haven't been talked about yet. And no matter what tech stack you're on, this should feel super exciting. There's some really cool future of the web stuff that is happening right now in browsers, in frameworks all over the place. I'm excited to dig into them. So, sound good? Should we get started?

We have a couple of design principles on the Astro web framework. One of my favorite one of them is this idea of pushing the web forward. There are plenty of web frameworks out there. We don't want to just be another one of them, another way to use React or Celt or Vue. We want to be something that challenges best practices and ideas.

So to give an example of this, when we started Astro, we were looking around. And one of the things that was like super frustrating at the time, this is going back, you know, a while now, was this idea of performance. You know, every web framework, including Next.js, including, God, what was, you know, create React app especially, they had their great hello worlds, their great blogs, their great getting started all looked good under the kind of, you know, if you look at them quickly, the performance was there. But then real world, they all struggled to actually deliver on that promise. So real world performance and kind of theoretical performance, very different.

When you're shipping a lot of JavaScript to the client, it's really hard. Your baseline is already so high to then have so little room to wiggle around and actually build your own code when the framework is taking up so much of that. When you're building your UI as a JavaScript app versus a page of HTML that is static and fast and has interactive components, we're not talking about a static kind of dead web, but the idea of shipping an app versus a page, in practice, it becomes very hard to make an app performant at the same level that a page of HTML can be.

So we saw this problem where in real world applications, everyone was struggling to hit performance. No one up here is batting above 50%. Right? Some are even, you know, one out of five sites are performant, four out of five aren't. That's a really kind of scary place to be in. And so we saw this problem not as a problem of developers not taking performance seriously. You know, it's not really something that is up to everyone to be an expert in performance. If that's the baseline for the web, that's a pretty tough place to start. We saw this as a problem of tools. Tools can do a better job at, we use this term, the pit of success, pushing you into the pit of success. You should fall in to success, not have to struggle to climb it.

So we built Astro around this idea of performance. We shipped a new architecture called Islands, which is incredibly performant. It strips out unnecessary JavaScript, it makes your page faster. And now, after years of real world adoption, we are now way, way above baseline here against every other JavaScript framework. This idea that full stack JavaScript is like this super unified story, but it doesn't have to mean everything JavaScript, client JavaScript, server. Everything is getting shipped to the user. We can be much smarter about how we deliver that. And the results here speak for themselves. So we're not even like the smallest or the second smallest in this chart. There's so much real world data that shows that when you remove JavaScript and get super smart about how you deliver your site, even if you're using React, even if you're using a framework, whatever your favorite tools are, you can still bring those to the developer experience, but get something at the end of the day that's much, much faster, a much better developer and user experience. That's our goal with Astro, ultimately, especially for content sites. Content is so important to the web. That's our whole focus. If you're building a marketing site, a blog, an e-commerce site, if the main purpose of your site is to deliver content to the user, that's where Astro can really come in. So if you haven't checked it out, that island architecture, that's the original kind of genesis of Astro challenging the way that frameworks build sites. The next year, we looked at content as a primitive for Astro. So content has lived as a primitive in static site builders for forever. Gatsby had the GraphQL content. This is not a new idea, but we wanted to bring this to the modern age, right? TypeScript, not GraphQL, schema validation, front matter validation. We built content into the platform of the Astro framework last year, or a couple years ago. And then lastly, view transitions. If you haven't seen view transitions, they're gonna blow your mind. React, Astro, it doesn't matter. This is like one of my favorite technologies to come out of the web platform. So if you haven't had a chance to check this out, we're gonna dig into it because it's really, really cool. And there's some really exciting things happening, not just like this year, but like literally this week that we're gonna dive into. So view transitions, we started adopting last year.

So view transitions, we started adopting last year. We built an API around it. And now, as browsers are adopting this standard, it's starting to enable some really cool things. So this is kind of a summary of like the big three bets we've been taking. It's a new year. What's our next big bet? Is it AI? Is it crypto? Are we building an NFT? No, we're going to the metaverse. The web is the metaverse. This is where we're going now. Every website floating around you. Now, that's not our vision for the future. But I think there is this really exciting future web that is kind of taking form here.

As we think about what this decade will look like, it's not just about Astro. It's just this idea of content-driven websites getting the experience that's optimized for them. These technologies I've been talking about, this idea of islands and content and view transitions, these aren't just Astro features. These are primitives for building on the web that we think deserve not just a place at the table, but like these will be driving the next decade of web development, especially for content-driven sites. So if you're building an app, you want to ship a giant JavaScript app, that's a great idea for certain use cases. Super stateful dashboards, that's great. But for most of the web, we actually think that this architecture, these primitives, these browser features are really, really exciting and going to totally change how we see the web. We've been working on a couple of different things in this regard. We're investing in three different primitives around islands, content, and view transitions. And that's going to basically define our roadmap for the next year. We have an open roadmap, you can check these things out, but these are the things that are getting us excited. We're going to be talking about how they relate to React and Astro and all these exciting things you can do with them.

So let's start with view transitions. I mentioned this feels like magic. It is magic. If you've seen this demo before, this is one of my favorite ones, because you think of Spotify, you think of heavy app, right? You think of JavaScript, Electron, you know, long load times. But in reality, this is HTML essentially only. HTML and CSS, obviously you've got to style it. But there is no JavaScript running here to power these animations. That might feel like magic. That's the browser actually taking over that responsibility from you. So these are full page navigations. If you click that, imagine you just click any other anchor tag, any other link on the page. Normally this would be a full clear and a full reset, a new page. But the browser now has the ability to not just make that seamless, but actually animate and transition between pages. So this is HTML, CSS. That's it. Powered by the browser. You can use this with any framework, React. You can use this with any lower level, Astro, Next.js. This is really cool technology. But what kind of sets us apart is for Astro, this is something that we didn't have before, right? With Next.js you could, you know, think of your site as a web application where you've shipped all this JavaScript. One of the benefits is now you can run those client-side transitions. Because Next.js takes over the router from the browser. So when you click a link in Next, you have a special link component. That's telling Next.js to run that animation, run that page transition. Super powerful. But, again, you had to ship a lot of JavaScript to get there. This is the thing that Astro didn't have.

By not shipping that JavaScript for the baseline, we never really had this ability. And we thought a little bit about, you know, should we build this in? Should we eat the cost of JavaScript to do it? There's Hotwire, there's all these really cool libraries. But they're all really complicated, right? They all end up kind of taking over responsibility for the browser of page navigation. That's what the browser does. That's like core browser technology. So this really tough kind of push pull. And the browsers have just totally saved our ass on this, to be honest. This is the coolest feature. And we didn't have to do anything. We built a simple API that plugs into this. So you don't have to write a lot of the CSS yourself. If you want to do a fade, a swipe, a cool, you know, whatever you want to program, you can program it or you can just identify it by name. We've given you these transition directors that basically wrap up all the accessibility concerns, the CSS styling. If you don't like working with keyframes and animations, you don't have to. We give you a lot of these primitives for free.

But at the end of the day, we're just telling the browser what to do. So there's some really cool stuff here about how we did this. But the big thing is that last point, to do this in a backwards compatible way, we had to get a little creative. We basically had to take over that router. That thing that we said that browsers are good at that we'll never do, we did it. And this was kind of like a huge betrayal of where Astor comes from. This idea of not doing that to do it for this feature felt a little icky. You know, it adds complexity. It adds JavaScript. But the big bet was that this would be a short-term fix. As browsers adopted this, as more and more people started to have this technology in their browser, we could start to see this polyfill, essentially this router, fade away, kind of melt away. You'd be able to remove it, and one day the browser would be able to run these zero JavaScript transitions for your React code, your HTML, whatever it is. You'd have that zero JavaScript thing. That was our bet. We were kind of betting on where the puck was going, skating there, and hoping that one day the browsers would catch up.

And so that's what's changed this week. If I was giving this any other time, it would be a weird kind of caveat. But this week, Chrome and Edge both ship support for this zero JavaScript transition in the browser. So you can use this today. No canary builds, no beta. This is available in users' browsers at an accelerating pace as this rolls out. More browsers are on the way. Safari just shipped a more limited support for this. But this is here. It's not just coming. It's not just future stuff. Of all the three things I'm going to talk about, this one is here today. And that's all you need to do. It's a couple lines of CSS. It's this new view transition rule, navigation auto. This tells the browser that you've opted into this feature. So if you never wanted to use this, you never want to think about view transitions ever again, that's fine. If you want to opt in, this is the CSS you need. It has to exist on the start and on the finish of that transition. If you do that, it basically tells, you know, here's where I'm coming from, here's where I'm going.

Both have opted in. Let's do the cool thing. Let's do the cool animation. If you've used Astro before, this was our backwards compatibility layer. You just remove that. You're now on the native thing. No more Astro code, no more spa router. This is all powered by the browser. And again, zero JavaScript. If you looked at the dev tools, zero JavaScript. If you looked at the actual network tab, this is a full page navigation each time. You're going from page to page and the browser's doing the hard work. So this is available now. It's coming in more browsers.

This is here. This is probably one of the most exciting browser primitives to come out. If you think about how the web existed for decades now. Clicking a link, navigating from page to page. This is fundamental stuff that hasn't changed in decades and all of a sudden this huge new technology is coming out. We think this is going to totally change how you architect for the web. And it's in a way that really supports Astro's island-based architecture. So give that a check out.

I'll go through content collections quickly. Because I think this is really cool. It's one of the things we've been built around, this idea of being able to manage content. We started with local markdown. Because we work on doc sites. We work on dev blogs. Markdown's great. Developers love it. MDX. All that good stuff. But by shipping this primitive in Astro, we had a couple of limitations. It only works for local content. So if you have a CMS or a remote API, out of luck. We enforce a rigid folder structure. So this is great for kind of if you follow the rules, you get all these nice features. Type script enabled. Front matter validation. If you don't follow the rules, you don't get the feature. It's pretty rigid. And as we started to scale this, we realized by keeping all this in memory, it starts to become a real problem when you actually deploy this to an SSR site. So if you have a static build, you'd be surprised by how well this scales. If you're in serverless, every time you have a cold start, it's loading a bunch of content into memory. Not a great place to be in. So we had these limitations. We tried to build around them and eventually realized that it was a great first start. But what we really wanted was this idea of a deeper content layer. Something that could manage remote, local content all in one place. We've been kind of lovingly referring to this as Gatsby, the good parts, because Gatsby had a lot of great ideas here.

And can we explore this without taking on the GraphQL layer? Can we use a more type script-based approach, auto-generate types, all these exciting things that let you work with your content, your React components, your front-end, all powered by a unified content layer? So if you've ever worked with MDX in a web framework, this is something we support today, but this is a much more pluggable API. This is the idea of actually globbing a folder. If that's where your content lives, great, point it anywhere you want. Maybe you have a single file, a big JavaScript or JSON array, thousands of entries. You don't have to break those up in individual files. Point us to the file, we'll do the rest. And maybe you just want to load your content from somewhere totally custom, right? You want to code it up yourself, generate it automatically. You want to fetch from some external API. Whatever you want to do, it's a low-level data API for pulling data into the content layer so that you can have access to it. And lastly, super pluggable. So anything you can imagine, Storyblok, your favorite CMS, your favorite API, Instagram, Facebook. You can pull this content from anywhere. We imagine a totally pluggable ecosystem of these components. Excuse me, these loaders that are existing on NPM. You pull them into your site and you're good to go. So this is really exciting. I haven't even like kind of scratched the surface of what's possible here. But if you're working with content on the web, you know it can be a total pain. All these different data sources, all these different CMSs. How do you bring them all together in a unified data layer, unified content layer? That's what we see as coming in the content layer for Astro. Really exciting stuff. It's still early. We're still exploring it. But if you have problems around managing your content, this is a really cool feature to check out in our roadmap and currently being developed on the team today.

All right, lastly, there's one really cool feature here to share. It's a round island architecture. If you're not familiar, I went over this briefly at the top. It's basically this idea of static HTML. Instead of shipping a JavaScript app, ship a page. And what Astro does is it strips away all that unused JavaScript. So if you use React to build your whole site, that's awesome. But really, so many sites fall into this hole. Only a couple of those components actually need to be interactive, right? So a buy button, a cart, a carousel of images. These are things that are interactive. The rest of the page, static, right? It doesn't need to change. So this is island architecture. It's just this at its core this idea of breaking your page into these islands of conceptual complexity. So static, simple. Client-interactive, a little more complex. We're going to ship React just for those client components. Totally optimizes your performance. Keeps things static, which means fast. It's really, really powerful, especially for content sites.

Now, when we think about what we send to the user, that's a big part of it. If you remember that kind of graph, our performance story is really about optimizing what you send, but there's this other part of the equation, which is how you send it, right? If you ship a static HTML page, you're going to get this great performance, but it's static, right? It's not going to change a lot. You can't put it in the CDN if it has your face kind of shown in the corner. Personalized content can't be cached in the same way static content can. But when you go personal, when you go dynamic content, you're eating this performance cost. We have to go to a data center. You have to go and hit that. We have to load that from somewhere, and you end up with this really tough kind of trade-off. Performant, static content, but doesn't have that personalization, doesn't have that dynamic data, or personalized, but now it's a little bit slower. You're having to fetch that data from somewhere that isn't a globally distributed CDN. So there's all these different trade-offs here. This has always been a really tough problem. If you've heard other frameworks, Next.js has been doing suspense and partial pre-rendering. This is our take on it, which is actually built on server islands. This idea of an island that isn't just a client component, but it's actually a server component. Every Astro component can kind of be thought of as a server component. We do this rendering. We render HTML, but what this unlocks is the idea to actually defer that rendering. So just like with client islands today, we're going to add a directive. In this case, it's the server defer directive, and what this tells Astro is to basically don't render this as a part of the initial page. Render it in a deferred way. So ship the static fallback, ship the page content. Whatever that React component is going to look like in its kind of skeleton loading state, ship that immediately. And what that really means is cache it, right? This can be cached on the entire page on a global CDN. Page loads, we're going to go fetch that dynamic content now after page load, and once that comes back from whatever that more expensive API endpoint is, we're going to stitch that back onto the page. All of this is done entirely behind the scenes for you, so all you need to think about is what's the fallback, what's the real content? Astro takes care of the rest and stitches it back together automatically.

So quick example of what this looks like. You can see the initial page load, 20 milliseconds, right? That's a global CDN. Super, super fast, no matter where you are in the world. This is powered by a Vercel, but any hosting platform is going to have this CDN functionality. That's because this page is static.

Even though there's my face or my little avatar in the top right, the page skeleton is static. What Astro has done is taken that deferred component and shipped that into a separate endpoint. So we've actually done the work to defer that, ship it as a separate endpoint. I've added some fake delay here just to kind of illustrate what this would look like on a slower connection, on a more expensive content generation. And that's all going to load in separately. So for content sites that Astro is so focused on, this kind of story is great because the majority of your content should load fast. But every once in a while, you have that personalized experience. Reviews on an e-commerce site or your avatar on a toolbar like this. This is perfect for this use case. This is our answer I mentioned to all these really cool things. We've been watching the React ecosystem. We've been working with the React ecosystem and on our own support. They've been doing a ton of exploring over the last decade on suspense, streaming, partial rerendering. For us, this is our answer built in a much more generic way. So this isn't built in any one framework. It's available for everybody. It's not just built for one hosting provider. It's built for everybody. This is really, really powerful and it works with any CDN. Oh, excuse me. So this is really cool. It's early. We're still checking this out. We have prototypes and demos. We'll be tweeting about this a lot more over the coming weeks. This is a really cool performance story. Not just about what you ship to the user but how you ship it. Combine this with the client island story we already have. You get a super optimized site with again very few limits on what you can do as a developer.

All right. View transitions, content layer, server islands. These are the three big things we're working on this year. View transitions already here. So check that one off. Content layer and server islands coming this year. So check these out. We have an open roadmap. Go jump into the road map. These are the three things that we see as foundational to the future of Astro and technologies that everyone should be playing around with no matter what your tech stack is. So if you haven't tried out Astro, give it a look. Give it a follow. And thanks again for having me. Thank you.

There has been a bit of interest on view transitions. Very exciting. Very cool demo. The people want to know. They're not supported yet in Firefox. I want to support more browsers. Do I still need to import a package? Do I need to polyfill it? What's our production plan here? Really good question. So for the last year, we've had this view transition story when none of the browsers had that full support. Every browser is incrementally getting there. Safari, for example, just recently announced support for this you can consider a level one API. JavaScript. So it doesn't do the full we take over the page transition for you, but it gives a JavaScript API to us, the framework author, to basically control this. That was that router that I mentioned. So the browsers are incrementally doing this. They've been incrementally doing this for the last year. That's where our view transition component comes in. No matter what browser your user has, they can basically put that on the page and we'll do all the work to polyfill that backwards compatible. We basically take on that work for you as a framework user. And then as browsers adopt that switch to the native CSS, that's where you opt into like the full browser. So if you're not ready for the future, if you want to wait a little bit, that's totally fine. The backwards compatible story is owned by us. The native kind of jump to where the browser is in the future story, that's the native CSS thing I just showed earlier. We all do all the work for you is a great answer to that question. That's my favorite answer. I like that a lot. Don't worry about it. We got you.

That's really great. There's a couple of backwards compatible. Yep, yep, yep, yep. Fred from Anonymous. Is island hydration streamed or a separate HTTP request? And can you cache the initial HTML on a CDN and have the island hit your server, which I think maybe you touched upon a little bit. Yeah, a little bit. I think that's the big thing, especially when we compare it to where the React ecosystem is now. Lots of focus on streaming. Lots of focus on basically the same kind of personalization we showed.

Next.js is tackling this from the perspective of one request stream down. So you're getting that personalization coming in the same request. Super powerful. It's really hard for the actual hosting provider to support that. So a lot of the CDNs, right, they're global and static, but they don't have that functionality built in. So we're building for that CDN in a way that we've seen in performance testing isn't a huge difference. You get that kind of more agnostic support, and then you get essentially that second request follows up after the page is loaded. So it's just a different approach of the same problem. We found it really, really compelling, especially for content sites and what they're optimizing for, which is a faster first page load. They need really good core web vitals. We see this as pretty competitive and comparable there. Is this something that you would like to see support from, like hosting providers?

Well, that's the thing. For us, they all basically support it. This is just how the web works. There's no extra kind of streaming functionality needed. I think streaming is super powerful. We support streaming. We have really cool APIs around suspense already. So this is something we care a lot about. But for this feature, we find the simpler the better. Again, let us do more for you. Let us kind of put less roadblocks in the way. So simple is nice. Simple is nice. We do love that. We're coming up with like cliches and little kitsch. Simple is nice. We should make t-shirts. Thanks.

Fred, when... Oh, this is interesting. A little more education on when using React in Astro, when does the React bundle itself get loaded and how does that work? So if you haven't seen our island architecture and you're curious to learn more, our docs have a lot of stuff on this. It's a really cool model where basically because you've broken your site into components, we can essentially optimize your site per component. So imagine you have a really heavy carousel down your page. You can basically tell Astro, hey, this is not the most important thing. It's a carousel. It's heavy. I don't want this to really impact my page. Defer this to hydrate. Load that whole bundle only once it becomes visible on the page. So the result is that basically you have total control over when that bundle loads. It can be immediately because you need that first component to be super interactive as fast as possible. Or you can say, I use React for really unimportant stuff. It's more like sugar. Defer it to when the browser is idle. Defer it to when it becomes visible. Way more control over the entire page on a component by component basis. So there's some really cool stuff that all ties together. It blows my mind. That's a big one.

We're getting into a little bit more of philosophical territory here. And I'm actually going to blend some of the questions. One person asked, all the frameworks are looking more and more similar as time goes on. Do you think we'll ever hit the framework singularity? And a similar question, which is sort of which projects is Astro good for and which ones is not? And has it sort of changed enough recently that it starts becoming a bit of a competitor to Next or Remix? Well, there's a panel later today. I'll plug my own panel. I think there's a future frontend panel about that question. Check it out. Yeah, that's later today. Framework singularity. I think a couple things. I think everyone is kind of exploring the same things around techno. Like the streaming is really big right now. Signals. There's these kind of trends that flow through our industry and then all the frameworks kind of throw out their answer to them. I think a thing that sets Astro apart is that, you know, you can look at it in our tagline. The web framework for content driven sites. That's a focus that no one else really shares. If you look at others, it's a lot of, I don't mean this at all in a disrespectful way. It's a lot of like, you know, the modern web framework or the framework for cool developers. It's a lot of like very generically cool and modern. But like we have this real focus on if you're building a content site, we want to be the best. So content is king. Another great cliche. Exactly. So I don't know. I think that's where it's like, I think what sets us apart is that we are doing things that are optimized for that story where others won't. I think that sets us apart. I think that gives us something unique. And do you think that's sort of like, you'll sort of stick to that track and really optimize it rather than trying more depth first? Yeah. I think we really want to kind of crack that, because I think that's where, especially you look back at the last decade, apps and JavaScript and SPAs, it was really, really great for apps. And the content site was kind of left behind. It was way more like, oh, that's something we don't care about. Or like, oh, you have these static site generators like Hugo. You're fine. You don't need anything. And for us, that wasn't really suitable. We wanted to use modern JavaScript. We want to use React. And wanted to find a tool that could kind of marry those two things together. That's very cool. It's interesting how many questions were like, what's the use case? What is it best for? And it's content, baby! T-shirt. This is interesting, a little bit sort of off of the specific things that you talked about. Somebody asked what the roadmap is for Astro Studio. Oh, good question. Is there anything you can share? So Astro Studio is us trying to play around with some higher level primitives. So a database, like an image host. Can we build these things into Astro in a way that basically any Astro developer as soon as you want it has a database? Like it's in the API. It's connected to a backend. That's what we're exploring there. It's really early.

These are really cool things. But building a backend and hosting infrastructure is really difficult. So it's early. We're playing around with it. But yeah, it's super exciting. I think every framework, Laravel has shown so much cool stuff there. Like frameworks, as they move to the backend, I think the natural next step is to move into some of these high-level primitives that are hard to get right. But when you get them right, it's a database. It's the thing that powers your apps. There's some really cool, exciting stuff there.

Do you know, I think that might be the first Laravel shout out I've heard at a React conference in a long time. That is a sign of something. I don't know what, but that is definitely a sign. I mean, it's interesting because it's sort of like the direction we're taking starts bringing it in more into the conversation. Your earlier question about where frameworks headed. I think that's a big part of this. I think everyone is exploring that same question of like, wow, we're all doing server backend stuff now. What's the database story? And that's where Laravel has been for decades now. A decade.

This is a bit of a also sort of future focus. Is there any specific focus on SEO and any new ideas from Astro in that respect? It's content, baby. Yeah, SEO is something we really, really care about. I try to think if we have anything new related to that. So much of our focus is on the content layer. So managing your content. A lot of what SEO, you know, we see SEO as a performance story. So Google rewards fast sites and punishes slow sites. And giving you the tools to kind of improve your SEO, make sure your meta tags, accessibility audits, all those things really help. But yeah, that's something we definitely care about.

One more sort of envision the future question here. What imaginary HTTP 4 feature would you like to see in the future, ideally helping Astro's vision, if you could pick? That's a very good question. I don't know. HTTP 25. If more stuff like view transitions keeps coming up, I am happy. Like that is so cool. I love seeing the browser starting to think of itself more as a native platform for really cool user experiences and not just like, we serve HTML. Here you go. I love that as a trend. So more stuff like that, I guess. I don't know. I don't have any strong ideas. I'm open to anything. Fair enough.

One more from me, because it's always usually helpful, is where can people learn more about Astro, learn about all the nuances, the pros, the cons, that kind of stuff? Astro.build is our website. It's also our Twitter handle spelled out. With the dot spelled out. It's been a while since I've actually typed it in. We've been doing a lot of talking about a lot of these concepts this week. So you can go and check it out. There's links to more demos and all these things. Yeah, we're active on Twitter. Astro.build is our website. Yeah, that's our kind of main memes and good content. Great. Well, Astro.build, check it out. Round of applause for Fred. Thank you for joining us. Thank you for answering all of our questions and for telling us more about Astro. Thanks, everybody.