Astro IRL with Eddy Vinck 
===

[00:00:00] Hi there, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. Try it for free at logrocket. com today. My name is Paul and joining us is Eddie Vink. Eddie is a software engineer with over six years of experience with a focus on front end development. And we're going to be digging into front end development indeed today. We're going to be talking about Astro, one of the coolest kids on the block these days. And we've had several episodes about Astro on PodRocket, but I'm extra excited for this one today because we're going to be digging in with Eddie specifically because he is an expert in front end development.

Thanks How you're using it as a developer. What is makes Astro great for the end user for us as developers. So I'm really excited to get in. Welcome to the show, Eddie.

Yeah, thank you. What makes Astro great? Personally, I've been using it for a while now, [00:01:00] so I first built my personal website with it. And that was really a straightforward experience for me. And that's why I ended up sticking with it. I have given a few conference talks about Astro at this point because I like it so much.

And I've also worked on a theme that I made for Astro, which is something I wanted to try. And that has been a very good experience so far. 

Do you feel like it's been a good experience because of the end product? Is it a good experience for you as a developer? Like I'm sure, all of these things you'd like because Astro is great in a lot of veins here, but which one of those bars on the bar chart in terms of good experience stands the highest for you.

I decided to check Astro out because. The end product was good, very fast websites, but then when I tried it, it also ended up being a very pleasant developer experience. So this, [00:02:00] so when I started looking into Astro, I just decided to go with an existing theme.

So they have this themes directory on their website and ~they~ they have a bunch of them on there. And I just picked one of the more popular ones for a blog and I just. Started working with that one,~ I decided to~ I completely customized it in the end, but all I really did was just look at the code in the theme that I picked.

And see how those things were working together. And that's all I really ended up needing. I didn't really need to look at the documentation very much because I also had prior experience with a bunch of other frameworks. So there are some similarities there, of course, because they all learn from each other.

So for my own website, most of the time was just spent on customizing things. And not necessarily learning the ins and outs of Astro. And that's so after a while, it just clicked like, Hey, I'm just. Like creating value instead of learning another tool.

[00:03:00] So it's very easy to pick up.

~That's it. ~That's interesting that take that you just presented where you felt like you didn't need to learn the tool necessarily. You didn't need to go to class by a course to use it.~ It was learned.~ It was one of those things you could learn naturally without being a super hardcore JavaScript person.

Oh yeah, for sure. There are some, things that they, have taken from, for example, Next. js, like a function that. It's called get static paths. And if you're JS, it's basically so you have like your website and then slash blog and then slash titles of blog posts or page numbers, if you're doing pagination.

So it creates those types of pages dynamically. That one might be tricky if you haven't seen that before. But then again, if you just go with an existing theme, then it's already going to be implemented. So you don't need to Really dive deep into it anyway. So that's also what I recommend for anyone looking into us.

[00:04:00] You could just start with a blank Astro project, but if you just go with a theme, then just pick one that has 90 percent of what you need. Take some inspiration for how that's working and then implement the rest or look at the documentation as well. ~I didn't need to do that very much, but the times that I did, it was, has been very good.~

The documentation is also very helpful.~ ~~So yeah, I think that if you go ahead with Astro, it should be a pretty smooth experience.~

Now, like I mentioned, we've had several episodes on pod rocket about Astro, like even some people who were part of the founding team of Astro. So if you want, if you're listening and you want to learn about. the core value prop of Astro or maybe some fundamentals about why is this different? You can definitely check out some of those episodes and any of a feel free, of course, to if you want to like, start to delve into any of those topics, I just want to remind listeners that we have those other pieces of content out there. Cause like I mentioned in this. Episode specifically, I would love to talk about using it. The some of the intricacies of using it cause you have so much experience at it. And one of those things that people are probably familiar with Astro is the [00:05:00] whole like fast by default, no JavaScript by default.

How do we do that? Islands architecture, Astro offers this new way to think about how we're putting JavaScript on the page. For somebody that's new to islands. And they're trying to wrap their heads around, or maybe they use and they want to level up their use case. Could you talk to me a little bit about some of the challenges of the first times you took an existing like Reactive model and tried to put into islands architecture and then ancillary to that are there like paradigms of development that people use in existing apps like global state? Redux things like this. How do you bridge the gap between? Those requirements and making them work in Astro.

So there's multiple parts to that question. So I guess we can start with the basics. So if you want to have JavaScript in your Astro projects, you can do that with just dot Astro components. Those. Components basically allow you to just write vanilla JavaScript or type [00:06:00] script in like a script tag.

If you want something more complex, then you can also use JavaScript libraries like React Few Angular or frameworks, if you want to call 'em that. Let's not get to that. But ~so~ you can also use components from for example, solid. Yes. Which is what one of the first libraries that I tried using.

And Astro lets you import, for example, a Solid JS component into Astro components or pages. And that will basically, by default, it's just going to be a library that you can use to render some HTML. But if you. Add a client directive on the component tag, which is basically a prop that you can pass into it.

So it's similar to that. So it can be like client colon load, client idle, client visible. There's a bunch of them and those client directives basically. Let you [00:07:00] decide how you want to render when do you want to load the JavaScript and how do you want it to load? So for example, there's client load that will just load the JavaScript right away.

There's client idle that will wait until the browser's idle, which can be beneficial in some use cases. And there's another really cool one that is called client visible, and that will basically wait until a component is visible on the page. So if the user never sees the component, for example, if when they're scrolling on a page, then.

They don't have to load the JavaScript, which is pretty cool. ~ But~ so those are some of the ways that you can optimize loading it. ~But~~, ~so once the JavaScript is loaded, it basically becomes what they call an island. So Astra has this thing that they call the islands architecture. And that basically allows you to render a, for example, solid Jess or react or view component right there.

And that component could be an entire tree of components, of course. So it [00:08:00] could be like a small application. So you mentioned for example, Redux. So you could definitely use something like that within that subtree. But there's also some libraries that I'm not actively using it myself.

But there are I forget the name, but there's some documentation about how you can communicate with these different subtrees of components or different astro islands and how you can communicate between them with a global state.

So would you say that in general, if there's somebody in a different ecosystem who has a very specific use case, it could, in all intents and purposes be replicated in the Astro model,

Yes, I think so. Of course, as always. It depends. But it basically, if it can be a, for example, a just client side application there are people that have decided, for example, All right, I'm going to use Astro to start my [00:09:00] React projects from now on. So it's basically replacing create React app for them.

So 

Gotcha. Okay. 

application, one giant React JS Astro island, and that's it, right? So you can do that, but yeah, you can also have multiple different islands. There's multiple ways of going about it. So what what you will typically see is for example content focused websites with a little bit of dynamic components sprinkled in between like mostly static stuff.

So for example, a search bar. That, that could be something that's more dynamic.

So Eddie, in general, would you say that the Astro is a, would you call it a server? first framework.

That's a good question. So they started out as mostly a static site generator. Eventually they added support for basically server side rendering. Frameworks in that [00:10:00] regard. So you can have both. You can have geostatic rendering, you can have server rendering, and you can even combine them in the same project, which is called hybrid rendering, and you can basically decide that in your astro config, so you can select an output method.

And if you decide to go with hybrid, then you can have this in your astro components, for example, you can export a variable called pre render. And if you set that to false, then it will not pre render a page, for example.

So if it is true, then it's just going to be a static page. Or a static endpoint, but if it's false, then it will just run every time. Maybe if you're connected to a database and then doing some database calls or doing some other dynamic things, then it will just do that on every request.

And if it's a static page, then it will just do that at build time. So I guess you could say Astro it's [00:11:00] very content focused and it's very focused on building these mostly, content heavy websites. So blogs, marketing websites, e commerce. So with that in mind, it's definitely, I would definitely call it more server first, but also I guess static websites, build system is still server.

So yeah, server first and you can add additional client side functionality to add some more dynamic parts, but I would say that, so if you're comparing it to something like Next. js or Nuxt. Those definitely see more geared towards building these web applications, right? So Astro is definitely more focused on just doing these content focused websites, not necessarily applications.

So They have been moving towards more dynamic features. Ever since I did my first conference talk, they have been adding more [00:12:00] stuff. For example, the API routes, which they call server endpoints.

And also a client side router. So they can have these animations when you navigate between pages, for example. So ~it's becoming more geared, ~they have been adding these features that allow you to make more dynamic applications, like you could, have a multi page application or a giant Astro Island that just communicates with your Astro endpoints.

But at the core, I would say it's still very much a server first kind of framework.

So if you were taking an example of a next JS project, what you get in that bundle is you have server to client rendering and hydration, and you have the end points built in. And at the end of the day, all of that, you could still equally with the same level of maintainability do in Astro, but what you just described, Eddie, we would have an island. Could be your whole react app if you wanted. And the endpoints could be those endpoints, but what did they call [00:13:00] them? Roots? I forget what the Astro team likes to call them

The endpoints, they are called server endpoints.

endpoints. One thing that I noticed in one of your presentations that he is, you said Astro, could be better than create rack react app. for bootstrapping your project. Do you foresee people like using Astro as their react boilerplate? They're saying, listen, that Astro is great.

Maybe I will use a content collection someday, but I'm just making a react app and I'll start it with Astro. Do you see that becoming a reality? Is it a reality in what you see right now in the field?

Professionally, I am not using Astro at work, so I cannot talk about that. But, I have definitely spoken to people that have said, That they are just using Astro to bootstrap React or SolidJS application, for example, and just one giant Astro Island. So there's definitely people doing that.

So in my talk, I said you [00:14:00] can definitely do that. But you need to think about ~if it works,~ if it will work for you. So Astro is, like I mentioned, ~becoming,~ they are adding more features to make dynamic projects more but I would say if you're going to make a very complex project, you need to think about if just having a giant.

Client side component, for example, or a component tree would be suitable for your needs ~if you need to do, some,~ so with for example reacts, you have the server components right now. And so if you need something like that, I guess it would be a more streamlined experience with something like Next.

With the server components right now, it might even be impossible with Astro. I don't know. I haven't tried. But yeah, if you just need to have some server rendered react component that is dynamic and like maybe. So it has some client components. It might be better to go with something else, but for Astro projects, it can definitely be a [00:15:00] good choice to start for with a application where you would know that a client side application will.

Be all you need, like a back office application that doesn't need any SEO, for example. So you can just render everything on the client if you want to. That's totally fine.

You drew a line in the sand. Eddie is saying like a web application, they're notably different and they are, but there's a lot of things that we would call a web application that indeed are very finely served by one giant client side component tree.

It works just fine. And we're not loading crazy data. Love to talk a little bit about where you see the Astro framework heading. you know, It's new people are wondering, Hey, what I do now will it be maintainable in a couple of years down the line before we do that? I want to remind our listeners that if you're building a web application or you're working on one that's been going for a while, you know, you can use Astro, put it in ~ ~~your client uh, ~one big client island. Separating to islands doesn't matter what you do. If you want to get more Intel on how people are using it, [00:16:00] errors in your application, no matter what framework you should check out log rocket because log rocket lets you look at what your user doing full session replay, things like heat maps and data driven insights that you might've missed.

So you can spend more time developing, exploring your frameworks, exploring your core product and value proposition and less time in our least favorite place, the debug console. So head over to log rocket. com today and check it out for free. So Eddie, moving on towards the future, if people are looking at Astro eyeing it for their new projects and they're saying, all right, they're working on these new dynamic features, these new progressive features. What's something that you feel the community has been voicing that's still missing that is being worked on might get people excited.

So personally, I haven't had that many, requests of, Hey, I need this, otherwise I cannot build my project. But I was looking at the roadmap earlier. So they have a public roadmap on GitHub and you [00:17:00] can see which discussions have been accepted. They have~ this approved~~,~ these approval stages, and you can see which ones are accepted.

So, Some of the accepted proposals are one that is called about basically rendering dot Astro components to a string. They want to make it easier to do that because sometimes you might want to, for example, test and with react, you could have a component that you render to a string so you can do ~snapshots,~ testing for example, with all these testing frameworks, that's something that I think is still hard to do with Astro.

And there are some other some other things that oh yeah, one of them was rendering SVG files as a component in your Astro component. So that's, you know, You can do that in some other frameworks, just import the SVG and use it as a component. That's just one of those quality of life improvements that people want to have in their projects.

So that's of course, very [00:18:00] convenient. And so there's a lot that they are working on. Some of the things that I wish they had so I gave , my first conference talk about Astro in May, 2023. So it's now February, 2024. So in the, in that time, they have added so many new things that I wish they had at first.

So I was able to incorporate those, things like, ~like~ the view transitions, for example into my talk at a later date. So things move fast with Astro and seeing as they have been working on adding these more dynamic features, I think, I'm not like, an Astro core member, right?

So I'm not officially associated with them. I'm just a fan really. So I, I dunno if they have internal discussions or not, but I could see them moving towards more dynamic stuff in the feed and if in the futures to enable you to create even more [00:19:00] dynamic applications with these.

I guess you mentioned you're not on the core team, but would you want any Astro to get to the same level of dynamic activity as something like a react framework? Would that be good for the framework, bad for the framework? Is there a limit to how much you want to see in terms of the dynamic vector in which it's being built?

That's a very good question. So I think that one of the strengths of Astro is actually that it's very focused on the things that it is good at now. So making these content focus websites. So maybe they want to add some more dynamic things in the future, but it shouldn't be. So I believe that this focus on that type of application, website is actually what separates Astro from the other ones.

The other frameworks, for example some of them are trying to be the go to for everything, right? So you can do web applications, websites you name it [00:20:00] even~ ~~using them as just some~ just using them as like you would use express JS to create an API, you can do that, but I think that.

Astro should definitely stick to being very great at building these content focused websites because That's also what separates them from the rest. if it's just going to be another framework that wants to do everything, then it might not be as great anymore. And if, I dunno, I'm just speculating here, but 

if they are allowed to have that focus, then they can make, I think they would be able to make better decisions on what they should and shouldn't do, and also provide a better, more streamlined developer experience because. Hey, we are Astro. We know you want, you probably want a content focused website so they can gear all their documentation towards building those types of experience.

For example, otherwise you're going to have this kind of split, right? So you need to support both use [00:21:00] cases. And ~I think that would, it's still~~ ~there is a, technically a company behind Astro. I don't know if they make money yet. I don't know anything about that.

~They probably, ~they have sponsors, but besides that, I don't know.

Yeah, tough question, but in summary, it's great that Astro is very good at what it does

and. We're welcoming dynamic features, but with caution because we want to make sure to keep a good developer experience, on that same topic of, dynamic should it be, maybe people listening to say, I do a server side load right here Eddie just said, forget it. If you want to do server side, Astro may not be for you. I'm overstating here, not a direct quote. It might be difficult to replicate that in Astro, but. Do you really need that server side endpoint? And I wonder if you feel like other frameworks, and we don't have to name drop here because there's like a lot that do the same sort of thing, do you feel like other frameworks are overcomplicating what developers think they need?

And maybe you could [00:22:00] build the same exact thing at the same level of fidelity and something that's way more boiled down and simpler, like Astro.

So with Astro, like I mentioned that I believe it's good that it's very focused and that allows you to have a better, more streamlined developer experience to create those specific types of experiences on the web. So I guess I think that having a focus for a framework like that is definitely very beneficial.

~That's a tough question. Sorry. ~

well, do

You feel like developers, the developer body in general and web today are overshooting? The feature set that they need to accomplish the UX that they want to deliver. Like if I'm a beginner web developer and I say, hey, I need this and I need that, the first thing you'll find a lot of times is, hey, here's how you do this with. top tier JavaScript framework in this framework in this top ecosystem, right? That's probably where I'm going to end up. I'm going to do it that way. I'm [00:23:00] going to go pull a component from MPM or something. Do you feel like there is an oversaturation of that sort of development and things can, in essence, be boiled down to do that, which they actually need, which would fit holistically in an astro model?

Do you think that there's a difference in that developer body of how we're structuring things out there?

~right.~ I would say so. Of course with React, there has been some discourse of people that Don't like the initial response to, for example, server components was a bit mixed. Uh, I guess you could say people seemed to be a little worried about. React changing focus. So not necessarily that it would be a problem to have, both the client and the server stuff at the same time, but people seem to be a bit worried about the direction where things are going,

so~ I guess~~.~

I guess you could say that, there is some things to be said about having a great focus because it's also this perception of people that want to use your tool, right? So if you just do [00:24:00] everything, then which parts do you do a little bit better than the other parts that you support?

So yeah, with Astro, it's just great. I think it's just great that they have this narrow focus. They're very. Explicit about that. And of course, other frameworks also have focus, but they also seem to just do everything, some of them at least. And that, that can be confusing because then you have this giant hammer, right?

And everything's just starts to look like a nail as they say. So maybe, that's how I. Ended up at Astro because I was trying to create a website with a JavaScript framework. And it just seemed a bit overkill. , so I heard great things about Astro and I forget which conference it was, but I believe I saw a talk there about Astros slightly after I had heard some things about it online and it just looked very great to me.

I just started using it and that's how I I [00:25:00] ended up liking it very much. And then when I started working with it I noticed that they had this great focus on these content focused websites. And personally, that was just very nice to me. Like I mentioned, the documentation, it was all geared towards this one end goal.

You come there with a goal and everything is geared towards that goal and it's, that just makes the entire experience from going from no astro experience, but a need to have a portfolio website or a blog from going from that point to the end result of a live website on the internet.

That, that was very smooth and a very nice experience because of that focus. Yeah I totally could see that,

What sort of things are advertised in the public facing stuff on GitHub of the released notes, um, that's coming up that you personally are excited about, Eddie? Is there anything [00:26:00] that you're going to use? New APIs or anything like that. Sitting here in February of 2024.

right. So when I gave my~ ~~lat~ latest Astro talk, the latest version of it, it was still version 4. 2 so that was last week. Now they're on 4. 3 

for example, they are working on better support for multilingual websites. So that's something that's. Really cool. I don't know if I need it right now, but if I'm building a content focused website and I know that it might need to be translated to a different language. So I'm Dutch. So if I am, but my website's in English, so maybe I want to easily add a Dutch version of my site at some point.

So that's something I could start thinking about right now. So yeah they're constantly working on these new cool features that again, are very focused on content focused websites. And I think that's awesome.

If people wanted to learn about [00:27:00] Astro, would you recommend a tutorial? I'm gonna guess no, because you say jump into it and just build. Would you recommend they just start building? What's the best path forward?

All right. All right. I guess there's multiple paths. So I was jumping into Astro as a somewhat experienced developer. So if~ ~~if you're,~~ ~you've worked with any front end framework before, maybe a static site generator, I would say just go ahead. You've already deployed something to the internet before you but even then just take a template and try to make that 

Templates, right?

Yeah. ~And~ but otherwise their documentation is phenomenal. They have A lot of pages in there but you don't need to read all of them at all. They also have some tutorials in the documentation to create some websites with Astro. And if you like more visual stuff, then of course there's a lot of online content available as well on YouTube.

Uh, if You've been to a conference. Before or [00:28:00] attending one in the future, the Astro core team, they have members doing conference talks all the time. So if you're going to a conference anytime soon, maybe check if there's an Astro talk on the schedule and you'll learn. A lot about it and probably more than you need to know to start with Astro right away.

So yeah, multiple ways to go about it, but I would say just get started, check out the website and, see how it goes.

Yep. Alright, Eddie. It has been great hearing about your experience in Astro. I feel like Talking to people who create a framework or their core contributor, it's very much like you have to take everything with a grain of salt, right? Because it's their bread and butter. It's their pride and joy. Coming from somebody who has spent so many years specifically doing web development and speaking to the strengths and what make you appreciate this. The new kid on the block, is cool to hear. And it makes Astro feel like something that can work for everybody. It's not just an [00:29:00] evangelist sort of thing that's happening right now. And also appreciate the resources, like pointing out the documentation and telling people they can just hop in it's a cool kind of like refreshing. Brain space to be in where it's I can just go to one spot. They know what I'm going to try to do and I can get it done. So like Eddie said, go check out the documentation and you'll have your idea up there in no time, as it seems,

Absolutely. Absolutely. So in my conference talk, for example, it's a prepared demo, right? But~ ~~I just~~. ~In my conference talk, there's like a live demo part where I basically take my own theme, customize it, and then we deploy it to the internet. And then I like within the span of five minutes, it's live.

And I've also been able to cover all the features in the theme. So if there's a theme that you'd like, and it has some, they all have documentation on how you can customize them, for example. So you can do that, take a theme, customize it a little bit, and you could have a [00:30:00] website up in five minutes for it.

So ~if you,~ if the goal is to just have something online, it could be pretty quick experience for sure.

what's the name of your theme? Eddie,

It's Astro engineering blog which is a very creative name. I know. So it's a theme that's geared towards building engineering blogs, of course, but also with the aim of supporting multiple authors, co authoring, all that stuff, but all based in Markdown.

Just wanted to throw at least one theme out there so that engineers, who are listening to

Can have somebody Google right away. They want to check out a theme in particular. It was engineering blog theme, right?

yeah. If you just go to the theme section on the Astro website and search for engineering, you'll find it. I believe it's only one of two that have that in the name. 

Well,

Eddie, thank you so much for your time. It's been a pleasure talking to you and learning about Astro in the wild.

yeah. Thanks, Paul. It was very fun.