Hello everyone, so our next speaker is one of my very good friends, a BGS team member
and an Astro core team member as well. His name is Elian and he's going to talk about
guests. Astro.
Hey, who wasn't that a surprise?
Alright, let me check that I'm not in the screen. Okay, hello everyone. Hope you're
doing good. I'm doing good, I'm just a little bit tired. I just flew in from Poland over
Zurich because I had a conference yesterday as well. So if I sometimes struggle with words,
I'm sorry I'm tired. Also I'm in Astro core. Astro is this framework. I'll talk about that
in a minute. But also in the React Brussels and the BGS team, I don't know if you've ever been
to our conferences. That's here in Belgium. I was actually born here in Brussels and now
living in Ghent. But also those guys are the same ones that actually organized this dev room. So
maybe let's give them a quick round of applause as well. Yes. And they actually both left so
they have no idea. But that's good. I also do my own meetups in Ghent. So if you live in Ghent
or in Belgium overall, you're always welcome at our meetups. They're free. If you want to follow
me after this or want to ask some question that you didn't get time to, feel free to follow me
online. It's at Alien Coats on all platforms. So that should be easy. Okay, let's address the
elephants in the room. What is Astro? Who has heard of Astro? Oh, wow. That is a lot. I asked the
same question yesterday. We're like three hands. Who has actually used Astro? Okay, that's also a
lot. Who is on the latest release of Astro? Okay, still good, still good. And who is using Astro
professionally? Nice. Okay. No, that's what I was expecting. That's fine. That's fine. Cool. Okay,
so it's a personal experience probably. Okay, that's good. Okay, cool. So we call Astro the
framework for content-driven development. There are a couple of reasons that we say that. And
I hope that will be clear to you after the talk. See it as being a comparable framework to Next
or Next. It's a meta framework as we sometimes call them. There is a lot of discussion over
should we call them meta frameworks. But let's call it that for now. We can later discuss on Twitter
if it's, well, on X, if it's actually called a meta framework or not. This is what it looks like.
This is the Astro syntax. Basically, everything that you want to write in JavaScript or in
TypeScript, we support TypeScript, goes in between the front, the top, the dashes.
That's always server-side. I'll explain that a little bit later. But it's a very familiar
syntax. It's basically JavaScript at the top or TypeScript if you prefer. And below it's just,
JSX likes syntax. It's not really JSX. It looks like JSX. But you can use class. So it's an improved
JSX. Why is it ideal for content-driven? Well, it is because it's better for SEO and for meta tags
and all of that stuff. Because we ship zero kilobytes of JavaScript by default. There is a
few catches with that. We were one of the first frameworks to take this approach. But by now,
we're surely not the only one. And sometimes a better tool fits a better use case or there is
a different tool that's totally fine. If you want to discuss that, we can totally do that after
this talk. Think of your traditional framework application approach. You write something in,
let's say, next JS or in next. It typically looks like this. It doesn't always, we have now,
React Server components and stuff. But I'm not going to account for that. All of these components
require JavaScript or TypeScript and compile to JavaScript. And that is actually really weird
because there is a couple of stuff here that is completely static and doesn't need JavaScript.
For instance, the footer. It's just basic A tags, whatever. The header, maybe it's just an A tag
that refers to your home page or an image. Why do I need JavaScript to render an image? That
doesn't make sense. So what we do with Astro is basically we compile it all down to static HTML,
CSS and JavaScript if you want to. More on that later. Basically, you have to remember HTML first.
So what if you need JavaScript? You probably want some interactivity, right? You probably want to
add a button, a hamburger button, drop downs, all of that stuff. What if you need interactivity?
Well, of course, that is possible. We have a directive for that. It's called client. And that
gives you a few options on how to control interactivity and tell the compiler when and how to
hydrate components. I listed a couple. There are more. But I'm going to quickly just go over these.
Client only is very easy. It just skips our compiler completely and ships JavaScript,
as you would in React. And client media will only hydrate a component when a given media query is
met. Think of it like mobile only buttons, hamburger buttons, all of those don't require
JavaScript to render on our desktop side because you don't even see them. We have client idle,
which will only hydrate components when the main thread is idle, when it's doing nothing. So basically,
free for your CPU. Client load will just say, hey, I need JavaScript to send it to me. Then we also
have a couple others like client visible that will only hydrate when a component is actually in the
viewport. That makes sense. So what we actually can do in Astro, think of this as the basic HTML
page I was talking about earlier, we can ship JavaScript to just a couple of components. Maybe
an image slider, we need some things there. Maybe we need some header links, whatever, that are dynamic.
We can do that. Of course, we are an open source thing. So you can build your own stuff. You can
put that into Astro. And of course, you all know, as developers, if you let them free, they will
come up with weird shit. One of those is Astro client when it's raining in New York. This will
basically, like it says in the name, it will hydrate your component, but only when it's raining in
New York. Cool stuff. Ben built this. Ben of the Astro core team has an implementation to show
off how it works. But it's possible. It's fun. It's cool. There is a lot of creativity to be
explored here. We call that concept islands. Islands basically referring to a component that's
completely isolated from your other components. But we come with one twist. We have seen the
astro syntax. But the components that you want on your client side, you can actually build in other
frameworks. You say, add react to my Astro website. And then you can use react components inside of
your Astro website. Or you want to use view or you want to use felt or maybe both of them together.
That is possible. I won't say that it's a recommended thing to do. My thing disconnected here.
Okay. It's not a recommended thing to do, but it is possible. But by default, without the client
hydration, if you use a react component on Astro, it will still compile down to static HTML at build
time by default. That's basically what makes Astro fast. There is, of course, a lot more.
What I show you now is basically only the static generation side of things. That's the default.
But we have so much more. And just in 2023, that was a crazy year for us. We did a lot of stuff.
We shipped three major versions. And we have reasons for that. And I'll go over them like very
quickly. I'll show you what we did and how we improved the life of Astro developers. So in January,
I did my first real international Astro talk at JS world.
Amy, you were there, right? With Omar? Yes. We just shipped Astro too. Astro looked completely
different from the Astro that it is now. What we shipped, we shipped more than just the features
that I'm going to share. But basically, these are the important ones. We shipped the new CLI.
RCLI? I think it's crazy. It's crazy good. It's super clear. It's really easy. We just asked you
a couple of questions. And on those questions, we set up a template for you. A couple of questions
are, of course, do you plan to use TypeScript? Yes. What kind of TS config do you want? Do you want
strict, strictest, loose default? Whatever you call it. You can do all of that. But also,
since we are so open source minded, we also have released that as a client library. Well,
not a client library. CLI library on its own. That's called CLAC. That's built by Nate, one of our
core members, built in a weekend. And now it's used in different projects and it's actually amazing.
Cool to see that there is like a couple of different projects that came from Astro.
We shipped content collections. That was actually one of the biggest ones.
Content collections give you a type safe way of working with markdown, MDX and all of the other
markdown flavors. Even markdoc, for instance. This is probably very familiar to you. This is Zod.
And Zod is this client, well, not client. This is library that basically checks your types on
Eskimo. That's what you do here. And because that's type safe, we can also error check way better
that I'm going to show you in a minute. This is how it looks like. So you get all the
intelligence goodies. You get all the auto completion and all of that good stuff.
We added hybrid rendering. So I was speaking about, as super clear, you can instantly see what's wrong.
In your blog, the astrotutorial.mdx frontmetter does not match collection scheme. You instantly
know what's wrong. What file is it? Oh, its title is required in astrotutorial.mdx. You instantly
know what's wrong and where it's wrong. You fix it, done. Then we launched astrotutorial.mdx3.
I think that was in August, if I remember correctly. We shipped view transitions. View transitions are
a super, super cool thing. Who has ever used view transitions? A couple of people, not too much.
Who knows about view transitions? Okay, that's a couple more. What's the reason that you didn't use
them? Yell something. Time. Okay. Okay, yes, browser support. I was going to expect that one.
Yes, it's not supported by all browsers yet. But what we do with astrotutorial is we polyfill a little
and then it works. At least the basics work. And what view transitions are for the ones that didn't
put their hand up, it actually looks like this. So astrotutorial basically does this SSG MPA page.
But they actually, with view transitions, you can make an MPA with basically all static HTML files
feel like SPA with client-side navigation, even though you're not shipping that to the browser.
The browser will always do this by its own. Basically, really simply explain it takes a
screenshot and the screenshot of your next page and transitions in between both of them.
But you can do crazy shit with that and about the demo with me. It's not built by me,
but I have it with me. Can I do it like that? Okay, give me a second here.
You can all see this? Okay, okay, okay. Switch page. Yes. So as I was saying,
browser support is a hard thing, but you can do shit like this. So this is multi-page application.
Still, when I press North, look what happens.
Okay, let me fix that. I wasn't expecting that to happen actually.
Will it work? Yes. Okay, now it's there. So if I go back to South page, it's basically
South.html. Look what happens. All of that animation is coming from the browser. There's no client-side
hydration happening here. This is insane. I don't know if you're excited as I am.
Yes, some people. Okay, okay. Not too much. It's fine. It's fine. But still, it works also with
like the navigation API. So if at the top, I don't know how well you know ARC, but at the top I have
just the basic buttons forward, backwards. That also should work. Yes. That's amazing.
Okay, okay. Now let me go back to the presentation if I can get that back here.
Okay, okay. There we are.
And connecting. Yes. The craziest about all of that is actually from you as an end user. Well,
end users are typically the clients that use the website. I mean, as a developer that will use
that feature. It's only two lines of code. It's really easy to implement and we make it so easy
for you to ensure that you have the best developer experience possible. A couple of other things,
of course, if you think statically, you don't have middleware, you don't have all of this
edge stuff. We added that as well. And the good thing is you can always create faster responses
for your users anywhere in the world, wherever they are. But those are always like the catch words
with edge stuff, right? It's also a little bit of a smaller runtime. So it's a little bit more
difficult than that. But you get the point. Image optimizing. Images are hard. Can be hard.
Can be really hard like in the browser sometimes. What we did is actually we released a virtual
module, actually, which is astroassets. And you basically just import your image,
just like you would do with a component, then use it as a source and it will automatically output
a optimized WebP image. But of course, a lot of people came complaining and were like,
where is picture? We need picture. We brought picture. And then actually you can do formats
with it. So if you want to use Aviv, because that's even faster and actually not supported in all
browsers, but you have a fallback to WebP, which is supported in all browsers, then we'll take
care of that for you. So it's really easy for you to define and optimize the small bits of your
website that are lacking behind. That's at least how you get. Also, we did a major refactoring of
our internals, the JSX internals. And because of that, we also got another 75 performance
improvement, which is great. We also brought this. I don't know how many of you are familiar with
fast refresh. It's amazing. If you don't see what's happening here, that's good because then you're
living a good life. What actually happens is, does anyone ever like build a dialogue, for instance?
You click on it, you have the dialogue goes open, then you change some text and suddenly it's gone
again and you have to re go through the whole flow again. That's the problem with state. Actually,
what fast refresh does for all JSX in our, in our case, it will actually remind the state. So
while you're typing, the state will update and you won't like have to go through the flow all over
again. So it's basically quality of life upgrade for you as a developer. Page partials. It wasn't
intentionally built for it, but of course we have all the HTMLX hype. And actually, this is
possible now with Astro because of page partials. You just ship one thing, no HTML tag, no head tag,
no body tag, just what you wrote in HTML and that makes using HTMLX in Astro possible.
Then we'll have Starlight. Who has heard of Starlight?
Less people than Astro. Okay. But there were a lot of people about Astro. What is one thing that
you can name about Astro that is good? Documentation. I know you were going to say that. I just said
it for you. Starlight is actually a, I want to say theme slash library slash framework.
It's basically a great theme for Astro. But one important thing is that it actually ships
everything that we have learned from writing docs for Astro and brought that to a framework for other
people. And I was actually talking backstage a little bit earlier with Nicholas and he's using
Starlight at work a lot and says it's amazing. Like you have all these built-in features that
take care for you like the search. You can change that with Page Search or Algolia or
anything you want. Really it's very pluggable. It's really good. And of course you have all
the Astro goodies. You can use React, you can use felt, you can compile everything to native languages.
You can do anything you want. But then we launched Astro 4. Astro 4 is cool. Why? We have a DevTool
bar now and DevTool bars are something underrated sometimes. In our case, you can see your islands.
You can see where your JSX is located. You click on the file, it will open. You can see that in
this case it's not hydrated or it is hydrated. What's the text? How does it work? You can see
all of that just in the browser like without leaving the browser. But also we shipped accessibility
tools. Accessibility is getting more and more and more important and it is. And that's why we
integrated that. So basically you click on the audit tool and it will tell you oh an image alt tag
is missing. Oh these are misconfigured area roles. All of that will just show you. Really easy. But
also it's super pluggable. So open source first. You can just write your own DevTool bar plugin
and build it. For instance we have the Astro Tailwind Config Viewer which is basically you can see
your whole Tailwind configuration inside of your Astro website or inside the DevTool bar. So basically
if you do this well or there is a lot of more features you can actually just build everything
inside the browser and never leave it except for developing code. Then we have built incremental
content caching. A question I got yesterday for instance was what if I want to use Astro with
thousands of pages? Where are the paints? And there are some of course like if you want to use
SSG and you're constantly pushing new files then your build pipeline will just be very slow because
it's always building and it's always building all of those pages. Even though sometimes they never
change. If you change one file while building all the others basically that's why what incremental
content caching does. It sees one file has changed and will only change that file. That makes sense
right? But with doing that just for our own documentation it's still experimental but we
tested it of course. We had a performance gain just for our documentation which is like 3,000 pages
of 80% gain. That's a lot. The improvement is insanely good. And then we also redesigned our
documentation to Starlight. Now it looks like this. I don't know if you've ever seen the previous one.
It was also good. It was also like kind of built very hacky. We didn't have internationalization
support before and such. We all have that now in Starlight and such in Astro docs. It's really
great doc footing for both projects. Then we announced the ecosystem fund. It's a really cool
thing that I'm very proud of. Actually what we do is we have dedicated the funding that we get as in
GitHub sponsors and such things like that. We dedicated a hundred thousand dollars of that
to give to other open source projects that are empowering Astro users. For instance one of those
that got the grant was LuciaAuth. You know if you've ever done LuciaAuth it's basically an
authentication library. That's also framework agnostic. But also they enable a lot of Astro
users to build cool websites with authentication. And for that they deserve an award. Well they
deserve at least some money to keep working on it. For instance we also gave 10,000 dollars to
a team builder. They create themes for Astro and they output like one team per month or something.
But that means that a lot of users get drawn to Astro because there are so many themes. So that's
really makes it work. Of course that's not all of it. This was just like basically it was a ramble
of features and how it works. There is more and there is more to it. And the question I always get
is but what is next? What is the next thing that we are going to ship? Well I don't know. We have an
open roadmap. So basically you decide. Our users decide. We have an open GitHub repository which is
just a roadmap. And you can just make an issue there. We'll comment on it. We'll discuss about it.
And then we'll get into an RFC. It's accepted. And then we'll actually build a feature. And if you
can help in that, that's awesome. Cool. If you want to stay updated you can go to Astro.Build which
is the website. If you want to join our Discord where we are very active both in development but
also in support and questions you have if you can't pose them here today. Go there. There is
probably someone super eager to help you out there. And Astro.Build says chat. And we also built a
newsletter like actually was launched this week or last week. And that's Astro.Build slash newsletter.
Cool. Thank you. Questions or is that another thing? If there are none I did a good job.
Did you try creating... Is it hydrate only when it's raining in Brussels?
Yeah. Because it's always hydrates. That would just be client side. I didn't. But I should. You should.
It would be easy. It's just an equals truth.
Big round of applause for Elio. Thank you.