Supper Club × Astro 2.0 with Fred Schott

Welcome to Syntax. On today's separate club, we have what we think is possibly our 1st repeat guest ever on, and, we have Fred Schott joining us to talk about Astro.

We're gonna be talking about Astro two point o. We're gonna be talking about all the exciting things going down there, and it's gonna kinda continue this framework exploration that we've been doing. And I I do wanna say, This is kind of unintentional. It just so happened that all these guests lined up to be perfect. So we had, Fred Fred, you might not know. We we recently we just we just had Ryan from SolidOn. We just had Mishko from Quicken.

I mean, we've been we've been kinda just grinding through these different frameworks that people are using. So today, We have Fred Schott.

Fred, what's up? How are you doing?

Thank you for having me on.

Yeah. I'm honored to be on. Thank you, for for rehabbing me. You Yeah. We were chatting before the show start. I forgot I was on. That's how long ago that was. That was, like, Two projects before this one, so I'm honored to be on representing ASTRO, repping the brand. I think I got the hoodie on. Oh, right on. Yeah. We, we had you on many moons ago to Talk about, like, e s m being the next big thing, pick a package, snowpack.

If we have time, we'll we'll go back to that and talk to What what happened with that and where that's at right now, but we're we're here. A totally painless transition just like I anticipated.

Yeah. Right. Absolutely.

But we're not here to talk about that. We're talk here to talk about Astro. Specifically, you launched, Astro 2.0 last week.

When you're listening, this will be probably about a month ago. Do you wanna give us just a quick rundown of of what Astro is and what people might use it for? Yeah. Yeah. I mean, it's it's a lot to follow Ryan and, and Mishka, but, I'll do my best. Yeah. Astro is a web framework.

So similar to those, but we really take a very interesting stance in what we imagine a web framework to be. So where others are really heavily leaning into JavaScript, and you got your Next. Js, your stop kit, your solid start.

You know, the the status quo seems to be pick your favorite framework and then go all in on that.

We take a much more kinda agnostic and almost like JS lite or 0 JS so as a developer experience, you get all these niceties of working with components. You can bring React, bring Svelte, bring Solid, and you have to use it to build your site, But we'll default to server rendering. So we'll actually render everything out to HTML and 0 JavaScript by default, and you can kind of then opt in Little parts of your page to be interactive on the client when you need it. So we call this island architecture.

It's really exciting. It's kind of our claim to fame. And Astra two point o was, kind of big step forward for all the things we care about around authoring markdown, building websites,

static Prerendering and all those cool things. So, yeah, a lot of good stuff in the release. Yeah. Yeah. It's it's fun because, you know, my experience with Astro is you you're Opting into JS when you need it. And for the most part, Astro's kind of assuming you don't need it, which is honestly, I think the right approach Because of how often we're over shipping j s these days. So Astro doing sort of you know, you have To tell us when you want things to be interactive is was a big was a big boost to me in terms of, like, how I think about, You know, modern web dev flow.

In the past, Astro was only static generated sites. Was that Is that accurate to say?

Yes. Our up until, like, maybe a couple months before v one fully static site builder.

Now we Report SSR, hybrid rendering, all these cool features. But, yeah, that was our our history. Nice. When did that change? You said Yeah. So our v one was really when we Shipped out, it actually was always our goal to have that, but it was it's a lot to build, especially with our new architecture. It's a lot to kinda tackle so much at once. So We saw this real big need for doc sites, personal blogs, all these things that didn't really need it, the full SSR.

And it let us kind of explore what Astro Could be in a in a much smaller little playground.

So our ambitions were always to grow past that, but that was where we started. And, a static site. Yeah. So if anybody out there has had it in their brain that it's an a static site generator, it's absolutely not. It's a full stack platform. Yeah. We we do we're so good at marketing our open 1st project that we now need to go back and and undo the damage of, a static only. Yeah. We need to, like, update our homepage. Just Astro does SSR should be the news title.

Yeah. So What kind of stuff can you build with Astro? Because the way I've seen it as a as in the past has been, like, Astro is great for Content heavy website. Is is that true? It's not like an application framework. You're not building the Netflix UI with this, are you? Yeah. We're kind of unique in how much we lean into that. Like, it's good for it's really good for some things, and it's really not meant for other things. People have used Astro to build everything. So, like, It has the flexibility that every other project has, but I actually really think it's one of our strengths is we're really clear about that expectation of what we are optimizing for, where I think a lot of other projects could probably lean into that more.

So our focus is on content focused sites. So if you're building something that's about mainly getting something in front of your users to, like, Read or watch or consume in some way.

That's the main thing we're astro. So think publications, think, you know, news, blogs, portfolios, documentation sites.

E commerce, I think, is about kind of as far as we really, like, want to go. And that it's about getting content, like, getting those new pair of shoes in front of you, but then still interactive bits. You still gotta click the buy button. You still gotta go through the checkout flow, manage a shopping cart. So there's interactivity in what we do, but, Yeah. If you're building the next Netflix, I would recommend a different framework. Yeah. You're just gonna have a bad time. It's possible, but but right now, that's not our focus. Yeah. But if you were so if you were building something like you have a doc site and you wanna have a search or maybe example or a set of tabs or something that does require JavaScript, That's where you get into this idea. We've been hearing it a lot as content islands. Right? Mhmm. Yeah. That's our magic. Can you explain what a what's an island? Yeah. So when you focus on content, you realize that, like, 90% of the page doesn't need to be shipped in JavaScript. If you think of, like, that layout component that you used to, like, layout your page or, You know, this div, like, divs are shipping JS just to render a div, and it's it makes no sense. Yeah. But that is you start to realize that is a actual, Like a need of the SPA. So Next. Js, and Falcon, and Solidstar, these are all building SPAs, which is, a single page application.

Like, you think of your website as an app. You build it, you bundle it, and you're shipping essentially an application down to the user.

You can still have all the cool, like, HTML rendering on the server, you know, all these like bells and whistles that have been built over the years. But at the end of the day, your whole site is 1 big app, and then you have to handle all this complexity to handle that. That's kind of where those apps live. It's just as as JavaScript everywhere because it's an app. And our approach is much more HTML everywhere, And then sprinkle in the JavaScript where you need it. We almost like pull apart your site into HTML first, and then instead of having to ship on down a whole application, you're shipping down these little bits, These little, like, micro apps that power your search and power your buy button and all those good things.

Islands.

Yeah. Exactly. Big islands. Little islands. Whatever islands you want.

Nice. Sounds like doctor Seuss.

The the authoring experience for people like, we had Caleb on a show a couple episodes ago, and that was like, oh, I have a PHP website or whatever, and I just wanna sprinkle in some JavaScript. This is a little bit different in that you would still write your entire layout in Astro and, Therefore, JavaScript.

But the actual client side JavaScript is is sort of opt in. Right? Like, only where you need it. Yeah. The joke like, our, like, meme if you imagine that, Scooby Doo meme where they, like, rip the mask off of Astro, and it's basically just like the PHP experience. Yeah. But for, like, this modern JS, developers, so everything that we give you by default is gonna be, like, it feels more like you're writing HTML than anything else. But then the ability to, like, step into React or step into Svelte for those dynamic bits. So we we knew we were never gonna build you know, it's and I actually believe it's impossible to build, and it's gonna be the best for server for front end. Like, those are 2 fundamentally different worlds. Like, On your server, you can talk to your database. On your front end, you can't. Like, in the front end, you need to manage state and, reactivity. And in the back end, you don't really need to because you're just rendering it once. Our big take is that those are fundamentally different environments, and you should build fundamentally different ways to express yourself on each. So Asperos is very much optimized for Expressing yourself on the server while still letting you kinda step into Reactor or Svelte or whatever you wanna use on the front end. I think more and more we're seeing that. And More and more, that's how I'm choosing to work as well in my own personal work because it just makes more sense than just shipping everything as JavaScript, Rendering it twice and doing all that dance that we're all doing. Well, what's fascinating is the React team has also realized that that's the way to do it. Like, the whole server command's Problem is them trying to back their way into the story of we need React that only runs on the server, not on the front end. And that's a fundamental change from the last, You know, 10 years or however long that project's been around. So, yeah, this is a trend that is now really picking up steam. And it also tracks in terms of, like,

the React team not being able to essentially just do that themselves because the meta framework being the lay of the land in React. So how is React going to dictate What everybody else is doing and, yeah, that that's a little bit of a tricky problem.

Well, so what's up with the, the the routes Inside of Astro, not in terms of, like, there's something weird there. But can you just give me, like, a a generalized all of these different Framework application site building frameworks we have now, they all use folder file based,

routing systems. Can you maybe just give a a quick rundown to the listener, Like, what to expect out of Astro's routing system? Oh, yeah. Totally. We definitely kinda learned from the best there. Took something that felt a lot like Eleventy meets Next. Js, The idea of a page's directory, which essentially defines your routes for you.

We're lucky that we don't have, like, a really advanced layout system at this point because that seems to be where the based routing is starting to hit some problems. Like, how do I define a layout for this folder, this subpath, but not the parent above it? Like, you're having to, like, Add so much configuration just to a file name. We're gonna have, like, dollar signs

and carrots and and percents in the file name. We're we're trying to avoid that. Yeah. Svelte did it by, like, adding, like, groups now where you have friends to say this is a group. And and, like, that that API to me is, like, one of the few choices in SvelteKit where I'm like, I don't know if The right one,

because it it feels a little weird. It's it's again, it's a limitation. They they have to. Yeah. It's it's once you start to define configuration, the file name, You're gonna have to there's advanced configuration needed. Yeah. Totally.

Solid start, actually. Ryan gets a lot of credit for, I think they have a fallback To file to config based routing for the really advanced stuff. That'd be nice. Remix might be exploring that as well. Yeah. I wouldn't I wouldn't mind a config file in general for when things get tight.

So inside of your route directory, you do what type of files to determine,

like, a page? For the asterisk component, when we talk about that, it's really a file that ends with Astra, you can think of it as, you know, dot svelte and dot view as, you know, that's a single file component.

If you define one of those in your pages directory, it's gonna return HTML. That's essentially a page that you've created whether that's statically, a build time, or, you know, in an SSR server when you actually respond to a request.

You can also create a dot j s or a dot t s file that will create like an endpoint. So if you wanna build an API within Astro, that's supported. Those are the 2 main ways to kind of express, It's, what you wanna return in an astrocyte when you hit a route. Cool. But you can also do, like, an MD file, right, in there? Will that will that do a page as well? Oh my god. I how did I forget? The reason I forgot is that that's actually something that we, the newest feature of Aster 2.0 is this idea of giving you ways to manage your markdown, which actually ends up moving it out of the page directory. So it's still there if you want, like, you know, create an about page, Write some markdown and just save it.

That's still a supported, feature. But this whole, like, markdown authoring experience is something that we really care about.

And that was a big part of the 2.0 release. It was more tools for managing your content, outside of just basic routes. Cool.

Let's talk about the MDX stuff. So this sign, as soon as I saw it, it caught my eye. I have a blog full of Literally, probably 700 markdown files, and I converted it to MDX 2.

And it was such a painful experience just because, like, the the API changed a little bit and, like, if you had a curly bracket anywhere in those 700 files that it would It would the whole thing would fall over, and, I saw like, it's it's all just in JavaScript, and I was like, oh, it'd be nice to have this sort of stuff in TypeScript. So, Like, what have you rolled out in Astro 2 that is this new type safe markdown?

Yeah. MDX is super powerful. So, for anyone Anyone at home has followed along. We actually tried to build our own version of MDX in the earliest days when what is after? I don't know. Let's build our own disaster. It's so hard to do.

Really Really hard to do it turns out. The MDX team has actually tackled something super super complicated, and, we ended up scrapping that just leaning into MDX for the people who need, Components in their markdown. That's that's the tagline. That's what it is.

So we support markdown. We support MDX. And, the big thing around type safety was actually, it actually perfectly aligns with what the MDX team is doing because they're actually right now working on their editor tools. Like, they seem to be really investing in the language The thing that power is, like, Versus code when you open up an MDX file.

We kinda tackle the other side of it, which is how do you manage type safety in your front matter? So if you have an MD or an MDX file? You have 10 properties. Right? And you mentioned, like, 700 posts. Right? So 700 individual files.

The problem we're trying to solve is what happens when one of those Properties doesn't match the other 699 posts. Yeah. Yeah. Typo. You, you did a date string instead of a date object They're an array instead of a a single string.

All that is like the wild west of of markdown. We don't really talk about it as much as as the rendering part, but it's a really It's, you know, it's the content is the how you're presenting the metadata of the post.

So that's what we focused on in our type safety is bringing in type safety to that part of the problem. I like it. I like it. Well, let's talk about the edge compute stuff. We're jumping around. If you if you feel like we should we should hit a a topic here, but I'm just kinda looking at what's interesting to me. So, the docs say that Astro is, like, edge ready, which means that you can put that obviously, it runs on node, but you can also run it on Deno and Cloudflare workers and probably bun at some point and all these types of things.

What's it like Writing something that has to be edge ready has to work everywhere. Yeah. I mean, what's it like? It's it's it's pretty difficult.

It's definitely a lot to bite off. Yeah. I this is another kind of credit where it's due moment. The remix team and the Svelte team, I'm I'm not sure which of them kinda did it first, but those are 2 kinda inspirations we're lucky enough to learn from.

You know, if you've released a web framework 3 or 4 years ago, you're just building for node and you don't really care what else. You just hope that, like, whatever your run time is, you know, Lambda Respects node. Yeah. But with Deno Cloud for workers, that's no longer really the case, and we were lucky enough to build our build system knowing that that's the reality we're moving towards is You can't really really bet on money 1 run time. So what do you do? And this idea of having an adapter is what, So we follow them very much into this. The idea of we're gonna build a JS app. So we're not gonna assume that, you know, node modules are built in or that NPM works. Like, we're just gonna build you JavaScript.

And then it's on the adapter to basically plug that into what Vercel expects or Netlify or Dena or Cloudflare.

Take that app and and adapt it to that runtime. Mhmm. So there's a couple of things you gotta, you know, you can't be using the dental object in your note app. It's it's not that powerful, but, it gives you a lot of flexibility. If you know what you're building for, you can kind of,

adapt it to that runtime and still get all the, power of your runtime as you build. Okay. And And, like, the the API for that, I'm curious, like, just what that looks like. Do you just, like, have to

emit or run a function that says Save file, and then the adapter figures out, okay. Well, if it's no, then we use f s dot write file. And if it's dino, we use dino dot Save file or whatever the API. Is that is that how it works? I mean, we it means we need to do a lot of upfront work to basically if there is something like that, do whatever we can before it's Shipped to your run time to address it. So Okay. We have a couple of tools at our advantage. One is, like, the way that files work on a web server is rarely like FS read, you're much more like pointing to a static or, asset.

You are calling something. You're importing something with the SM. So we have a couple of tools we can kinda play around with. Like, the import keyword Saves our saves our butts. The nice thing is we take on that complexity. Like, we're the framework authors. We can handle that complexity. Yeah. It sucks, but we can do it. And that saves you from having to worry about it too much as a developer. Yeah. I I do like this this new approach of,

the output format being not directly hard hard coded into the framework as being a choice that you have to make once or whatever that you you can You can make these choices and and potentially experiment with the output of your application to to you know, who knows what we're gonna be Outputting on in the next 5 years. Right? It could be something that we don't even know about. Yeah.

Right? Yeah. What's what's actually super interesting is that now people are trying to bring the same idea To other like, so Next. Js, right, being an older framework, it really only builds for Node or Lambda or, you know, Vercel's Mhmm. Platform.

And there's this project called I think it's open next,

Which is, like, let's take that output and try and make it work, like, anywhere. So AWS, other for other run times that aren't for sale specific. Yeah. I I haven't really dove too much into, like, like, how I really wanna get into the there's a adapter, first felt kit, or a a bun adapter just to, like, experiment with them and see what their limits are. But I I do like the adapter flow of things. What about let's talk about, like, data fetching inside of Astro 2 specifically.

You know, data fetching has been one of those things that we've noticed specifically a lot of trends and directions in terms of how people are doing things, You know, some of which stem from, I think, how even Astro, has been doing it for a while, but also remix and others. Do Do you wanna talk a little bit about just the general flow of loading a data from

an API database or anything into your component displaying that Information, and what what's kind of cool about how Astro does it? Yeah. So that's, I think, a perfect illustration of one of those concepts we were touching on earlier. Like, Astro being written for the server Means we can do things that other front end frameworks like React and and Svelte can't.

One of those is top level await. So in your Astra component, Whatever you gotta do to fetch data, whatever the source, whatever you gotta do, do it. So you can await a fetch call, you can await a database call.

You don't have to do a special library that kinda helps manage the flow. Okay. Well, while it's fetching, what is my state, and how do I manage the air? Like, It's all just kind of there in the in the component itself because we're gonna wait for it to render to HTML no matter what. It's all part of that kinda like streaming response that you're gonna get. So by being a server focused framework like Astro, we can actually really build for that reality.

So yeah. You're basically you're right in your component. You can go and fetch something For remote source, from the database, you just have the fetch keyword, you have your database, you know, SDK if you're using an MPM package, Prisma, tRPC, whatever you're fetching your data from, you get to call it kind of using maximum power, using whatever the tool that you'd like to use. It's asynchronous by default, TypeScript by default. It's got all that cool stuff built in.

So you can just kinda do whatever the docs for that project that you need. And in in dot Astro files,

specifically, you can do this directly in, like, the front matter area. Do you do you actually call that a front matter Area of a file even if it's not marked down in ASTRO?

Yeah. Just for familiarity, we used to call it the component script, but I feel like people just called it the component front matter. So you can think of it as, like, this is where the server logic goes and runs, and then everything below that is, like, the template of the, you know, the render function, basically. Single component files,

really, really open up a lot of, like, cool stuff you can do. And and you don't see a lot of people doing what you guys are doing here with that differentiation between The like, you said the the front matter, the components front matter, anything like that, being able to run Straight up function calls to grab data or whatever directly in the top of that component. Does it remind you of something? Does it maybe remind you of PHP a little bit? And it does. And it it's So wonderful.

Like, I wish more people would do this instead of just saying, alright. Now here we have, you're just gonna use it the way that reacted because Reacted it that way. So, definitely, kudos on taking an approach that's like, how can we make this easier on people? This is the stuff people have to do all the time. Who who cares about a function that calls a function or whatever? We give you top level await. We give you TypeScript. Just toss it all at the top of a component. Bingo, bango, your data's there. So that's one of my favorite components. Thank you. Well, that that means yeah. Sorry. That means No. No. It's just one of my favorite aspects of ASTRO in general, and I think that's a trend we're seeing more. What about, like, data mutations? Like, how do you handle,