all right all right all right all right well yeah
let's do it let's talk about Astro 410 our latest release of Astro it's not only our latest release
it's also one of the biggest releases we've ever done we have a lot of new features in Astro 4.10
I'm going to go over them here in a second but one of our main focuses on 4.10 is making it
possible to use Astro in ways you never could before and I'll explain what that is.So these
are the features you've already heard about actions I'm not going to go over that we also
have request rewriting we have number of build performance improvements we have type safe
environment variables and we have a new way to use Astro inside places that previously
couldn't go and we call that the Container API. But before I go over the features I want
to talk a little bit about some of the design principles we use when we build Astro. So one of
the first design principles that really we really try to think about try to make sure that we have
a cohesive framework is we try to make it easy to do the right thing. So you might be be familiar
with the term a pit of success and that's what we try to do we want to make it so that when you
build your site with Astro you kind of fall into winning strategies just by using it. A couple
examples here is of course Islands which is a way to add JavaScript just when it's needed. We
also have view transitions which is our take on client side routing so you can start with an MPA
and then you enhance it and make it client side routed. Another thing that we often think about is
making it it so that others can do the difficult thing for you and this really comes through
with our Integrations API. With integrations you have hooks into the entire process that
Astro runs and Starlight's a great example. Starlight gives you an entire documentation
framework as an integration. We think that's really powerful. So think about these principles
as I go through each of these features; think about how these um come through. First up we have
rewrites. So you might already be familiar with rewrites if you're familiar with older servers
such as Nginx, Apache those all had rewrites or you might be familiar with other JavaScript
Frameworks they also have rewrites but we did it in in a unique way whereas normally it's a
config it's you have inside your config here's an old route I wanted to go to this route instead we
try to make it dynamic and I'll kind of show what that is. But first let me tell you a use case here
so let's say you have a product page and the user goes to a product that doesn't exist you want to
show a 404 page. Well rewrites enables that sort of thing. The code looks like this you've probably
written this sort of code before yourself you have some type of function to call your API maybe you
call the database you get the slug from the URL, that product doesn't exist. You want to reroute
to the to the user to the 404 page now you can just call Astro.rewrite pass in the route that you
want to you want to render you pass in this case we're going to pass in the slug so you can get
a little bit extra contextual information to the user. But it goes more than this we can actually
use this inside of middleware so an integration could provide like higher level features for you
in this case we want to provide localized slugs we want to have the URL in the language of the
user right. But normally you don't have multiple languages in your file system right like you have
hello.astro and if you want the French user to see salut instead, I think I said that right, salut
um you could build an integration that does that right you you just parse out the URL you get that
slug here we have a little map and we're going to call rewrite to go to that instead so like I said
this is something you can imagine integrations providing you know a nice API to have these sort
of localized slugs so we're really hoping that Integrations start to build these types of things.
I'm going to take a little break from features for a second and talk about performance. Of course
performance is something that is challenging in a static site generator you know especially
when built like Astro that enables you to use JavaScript so it's something that we're constantly
having to monitor it's something we build benchmarks for and something we're constantly
trying to improve. So recently we've had a number of performance improvements that have had a pretty
dramatic effect on static build performance and I'm going to go over the numbers here in a second
but first I just want to tell you a little bit about how we actually did this and we did this
not necessarily just by improving Astro we did it by improving the entire ecosystem so through a
lot of upstream contributions. Now of course Astro is built on the shoulders of a huge JavaScript
ecosystem right so we have projects like Vite and so we we made some improvements there we also
have Shiki which is a syntax highlighter. We have tinycolor, expressive-code, we have Rollup which
is our bundler and we have the Remark ecosystem which if you're not familiar that is what gives
MDX, markdown support inside of Astro. So we made improvements to all these projects and that
had a dramatic effect on Astro itself. All right before I show you the actual numbers we kind of
use the docs site our Astro docs as kind of the test project for this right because docs is an
example of a great advanced static site. It's a static site with internationalization support,
it supports 14 different languages, there's 4,439 total pages that was like of a couple weeks ago
it's probably even higher now. And so our previous baseline when we started this project was 14
minutes. Which is doesn't sound that bad actually when you think about it but when you do start to
think about it and you think about the workflow for a doc site; the typical workflow is docs is on
a GitHub repo and so if someone wants to change a page like maybe they fix a typo or they document
a new feature they send a pull request to the doc site. So he has to wait for that to build to get a
preview URL so you're waiting 14 minutes and then perhaps the reviewer checks that and maybe they
ask for suggestions so you got to wait another 14 minutes so it's something that can accumulate
over time so after all these improvements all these ecosystem improvements we got the number
down to 5 minutes and 30 [Applause] seconds so that is a 60% Improvement which is pretty
dramatic and you know it not just Astro the benefited from this anybody that uses these
other projects get the benefit as well. But there's one more feature that we were able to
bring this down even more. So I don't know if you know this but in Astro 4.0 we released a new
experimental feature called content collections cache and what contents collections cach does it
it not it notices that most in something like docs or in a blog most of your content is in your
content collections in the contents folder and so what we did is we made it so that when you
do something like oh I'm just fixing the typo or I'm just adding documentation to this one
page instead of building the all the pages we just build those pages that have changed and used
cached versions for the rest of everything and so on the doc site when we do that the number goes
even lower. It goes to 1 minute and 9 seconds. So we started off 14 minutes just making
improvements down to 5 minutes 30 seconds and now we're down to just a little over a minute when
we add some caching on top. So content collection cache is a still an experimental feature, it
is great for a workflow like docs it's great for blogs it is experimental you can enable it I
recommend you check it out. All right let's jump back over to features and talk about astro:env So
astro:env is our answer for type safe environment variables this is something I'm actually very
passionate about I hope you can tell. So let's first let's define an environment variable
first off it's an operating system concept right. What happens when you have environment
variables is the operating system when you execute your program the operating system takes
all your environment variables things you define, define in your shell scripts and it makes a copy
of those attaches it to the process when you read the environment variables it gets it from that
list so this is something that's existed basically since the dawn of Unix. But more recently the
JavaScript ecosystem has added more ways to do environment variables; it became a bundler
features so if you're familiar with WebPack for example there's a Define plugin and that's
a way to define environment variables directly inside of your config of course. We also have dot
env files anybody here use a dot env file? It's a great way to do local development you can have
your environment variables inside of your project and you can point to your staging database or
your staging whatever and read from there so it's great for that use case. Of course we also have
environment variables inside of our CI, inside of our host and those all have different UIs and they
have even sometimes different ways to read the environment variables so environment variables are
just inherently a difficult thing they are hard I know like as a framework developer they're hard
on me and they're probably hard on you as well. But it goes further than that like we have some
environment variables that are just things we need in the client some are things we just need
in the server some of them are secrets; like you don't want your Stripe API key to be exposed in
your client bundle you're going to have a really bad day if that happens some of them are required
some of them are not some of them are optional. So our answer is astro:env, a new
built-in module inside of Astro so this gives you type safety
gives you nice auto-compete you define your variables with a schema which gets
validated with Zod and it works with any adapter runtime so there's no more worrying about oh
Cloudflare reads environment environment variables this way, Deno another way there's no process.env
shimming, none of that. So it looks like this you have a new env property inside your config you
can define your variables you can define what type they are; are they a string? are they a
boolean, number? And will get coerced for you. You define what context they run are they server
are they client. You define the access level are they public are they secret. You can define the
default or they required. Full configurability of your variables and when you go to use them
you import from astro:env/client or server you get nice autocomplete all that for you and in the
server version you have this get secret so if you want to read something dynamically at runtime you
can do that of course you can only do that on a server you can't do that in the client that'd
be impossible so we don't even let you try. All right last up we have component containers
so this is the Container API it this at the beginning of the talk is like one of the most
powerful features but it's also one of the most upvoted RFCs we've ever had this is something
people have been asking for in Astro since we started the project and I'll go over some of
the use cases and you can see why that is but first off what this is is it just a low level
rendering API it's a low-level API that you can render Astro components. So some use cases here;
anybody here a Rails or PHP developer. Python, no I guess not well whatever you're not going to
like the demo ha. Yeah so yeah you can use you can use Astro inside of Rails, PHP this is people
have asked for this because Astro is really nice to add JavaScript right you can just add your
client directives now you get JavaScript for free. You could also use it to do full text rendering
inside of RSS feeds just get your collection, loop over that collection, render that content
component, inject that inside of your RSS. You can also do testing we've always had support for
Vitest inside of Astro for quite a quite a long time now you can actually test those components
you import your card create a container render that to string do any assertions you need so
that is container API I'm going give you a demo that you're going to love, but first
4.10, you can upgrade existing projects: npx @astrojs/upgrade or for new projects
do npm create astro@latest like normal. So next I'm going to do a little demo. So we have
a PHP app and if you could guess I am not a PHP expert and I can tell none of you are either so
no one's going to know any the wiser that I did this a good way or not uh but what I do know
is that so this is just a nice little PHP app mostly HTML. I know that PHP has this function
called passthrough and with passthrough what you can do is you can execute an external command and
it will just kind of inject anything that command logs right here so basically what we want to do
is we run run our script that script is going to log some HTML and it's going to happen right
here. So PHP developers are laughing right now there's probably a much better way to do this
it's more efficient uh but this does work so this is what I'm going to demo. So I have
an Astro project inside of my PHP project this is a low-level API as I said here's the
container code I'll come back to this in a second first I want to show you kind of how I
designed decided to organize this I have this all.ts file which I export all the components
that I want to use, like for example have this React wrapper component and inside of that
we're rendering a counter component who would have thought you're pretty much required to do
counter components in demo so that's what I did. So I have this counter component which is just
a normal react counter component using Tailwind and I have this render.mjs script. I create my
container I'm passing some magic config stuff, I have this resolve function for example this is
allowing me to resolve like where client scripts are loaded from because I have them in a special
place in my project. Then I have this components which has my React wrapper component on it;
I can render that to string I console.log it; boom it is magically inside , which way do I go,
this way, it's magically inside of my PHP app. So this is a PHP app and I got myself a little
island and look at that a working counter, that's the most beautiful thing in the world. And if I
open up the inspector here we can see, hopefully that is large enough, let me just bump that up,
we have an Astro Island which I don't know if you ever inspected the HTML of Astro but you get
these little Astro Islands so there you go you got yourself PHP inside of Astro so let me just yeah
that is it let me let's go back to the slides. Now check out Astro 4.10,
thanks everybody [Applause]
