Today we talk with Fred Schott, the co-creator of Astro. Being involved with open source web development for a decade, and working on several teams at Google, including Chrome and Polymer, he is now one of the biggest promoters of Astro. We talk about how Astro, as a static site generator, helps to solve the over-use of javascript on the client side.

Hello everybody and welcome to yet another exciting episode of Views on View. I am Steve Edwards, the host with the face for radio and the voice for being a mime, but I'm still your host. Today with me, I have a very special guest. His name is Fred Schott. How you doing, Fred?

 

You're doing well, thanks for having me on. Super excited to talk Astro

 

Luster

 

and VU and everything.

 

there we go

 

Oh no, did I lose

 

Yeah,

 

you?

 

yeah, for sure. Uh-oh, we had a little lag there. We'll have to edit this out. Hopefully it's okay. Had a delay between what I saw and what was coming out.

 

Oh no.

 

Edit this out. For those of you who have been regular listeners of Views on Vue, you've heard me talk multiple times about Astro, which is a static site generator, and how I'm using it and how it works with the old IELTS methodology, and I-L-I-N-T-S methodology, shall we say. And so I decided let's get the guy on who knows Astro just a little bit So Fred is here to talk to us all about Astro and how awesome it is and how it works and So on so before we get started Fred, why don't you just give us a little background who you are why you're famous What you do where you do it, etc

 

I don't know if I'm famous. I'm famous to a very small group of people, I guess you could say. Yeah, no, I've been doing web development for over a decade now, open source for almost a decade. I've been lucky enough to work on some great teams at Google, on Chrome, Polymer, and a couple product teams along the way. But definitely my interest has always been open source and specifically tooling for web developers. So ASTRO is very much a tool for web developers, a love letter to web development. And there's some really exciting things that we, I'm sure we'll get into about how the architecture works, how it's very different from all of the other site builders today. We just recently launched our V1.0 with support for Vue and also no longer just a static site builder. It now supports full SSR. So there's some really cool things that that's unlocked that you can do with Astro now coming into the post V1 era that I'm excited to, yeah, I'm sure we'll talk about all of it.

 

Yes, we will. So first of all, I'll give you my description of Astro, at least if I've understood it, and then you can correct me if I'm wrong. And we can go from there. So Astro is a, well, it was initially built apparently as a static site generator, right? So the idea is that you can build a static site, you make all your API calls, put in your markup, theme it, design it, however you want to, and then you build it, and you've got your static HTML. and accessory files, CSS, JavaScript, that you can send to wherever, an S3 bucket, I would assume, or Netlify, or wherever. But one of the, I think the bigger goals, if I've heard you say correctly, is that you're trying to get away from too much JavaScript because JavaScript has to be downloaded to the browser and it hinders performance because your browser is downloading and trying to run all that JavaScript, so you're trying to do the minimal amount of JavaScript while getting all of your site. deployed. Is that accurate?

 

Yeah, we really see JavaScript and you can kind of lump all the SBAs into that.

 

Mm-hmm.

 

The overuse of JavaScript on the client side has this problem to be solved. It doesn't make sense for every use case. If you're building a super dynamic dashboard and there's data flying around, like if you're building the next Facebook, Astro is not really designed for you in mind. But if you're designing a marketing site, a content site, a publishing site, even all the way up to e-commerce. that user or that site is much more concerned with performance. SEO, there's plenty of data that shows how bounce rates, SEO and everything are all impacted by performance, really directly, like hundreds of milliseconds equals full percents of conversions and ultimately sales and money for e-commerce sites. So we get

 

Is

 

to

 

that?

 

have this really interesting take on performance, which is optimized for that user. Instead of building a big application, we're helping you build a content site.

 

Now you mentioned this stat regarding how milliseconds delays can have a direct relationship to lost business. There's Amazon supposedly dead studies about a second can cost them so many million or billion dollars in terms of performance. I've always wondered, is that just because people are impatient and they figure out if the site doesn't load in less than one second, I'm gonna go somewhere else? Or

 

Oh, yeah.

 

how does that work? I've always wondered that.

 

So there's a lot behind that question. I mean, the biggest kind of thing you can't ignore is like Amazon's not using React. Like not because they don't like React, because it just doesn't, at the level that they're talking, like probably not even 100 milliseconds, like single milliseconds are probably contributing millions of dollars to their bottom line. That is a totally made up stat, but I can't imagine at their scale there isn't some truth to that. The way that that ends up, so it comes a couple of ways. One is, You know, we build sites on our big beefy developer laptops, on our wired ethernet, on our, you know, dev machines and everything about our local host environment is really like set up to not let us see the actual user performance. So we build these JavaScript applications and don't realize that that's being shipped down to mobile phones across low powered connections. So. Hundreds of milliseconds is kind of this way to like, it's the smallest unit of measurement that we can track real data to, but for a lot of sites, we're even talking about like tens of seconds on low powered devices to become interactive. So if you're an e-commerce site, I mean, I definitely know that feeling of like, I'm on a lower powered, like maybe I'm going through a tunnel or for some reason I'm outside of the city, my internet's not as good on my phone. Like the 10 second, just the drag of loading that site. I bounce off all the time when that happens. I'll say, oh, I'll do that when I get home and maybe I will, maybe I will. So it's really like, it's an experience that you really have to feel. And you kind of do feel it when you're off of your low, you know, high end developer machine. Um, but then most recently, Google has really started to get into this fight as well. Like they really have started only in the last year, ranking your SEO based on these core web vitals, the, you know, your lighthouse score. Um, they're, they're putting their hand on the scale to say, not only are we gonna, you know, for your own sake, you should be doing this, but we're actually going to rank all other things being equal, the fastest site's going to win this SEO ranking. So there's real kind of business implications even outside of performance and money being left on the table.

 

Yeah, recently we had Annie Sullivan from Google on JavaScript Jabber discussing that exact topic and I brought that question up regarding the Core Web Vitals and how much that impacts their rankings. And her response was basically, I believe that that's just a part of the overall, what shall we say? list of things that they used in their rankings. So it's not everything is in performance, but it is, you know, as they have made clear and as you just mentioned, that's a very big part is performance has to do with how you come up in the rankings. So.

 

Yeah, I've seen, I think the window is kind of 5% of like, people who have been tracking this, like it kind of opens up this window of 5% either direction where you can kind of raise or lower. Again, you know, Google keeps these metrics pretty close to the chest, but

 

Mm-hmm.

 

people are seeing that it's, you know, if you're, especially if you're competitive keywords, you know, 5% is a pretty significant bump and boost over some competitor who just isn't looking at performance or maybe their tech stack, their architecture isn't set up well for it.

 

Mm-hmm. Mm-hmm. For sure. Okay, so let's get into Astro itself. I'm always curious to hear what the origin story is. You know, what made you think you could be different versus all of the other static site generators out

 

Ha

 

there?

 

ha ha.

 

You know, my there's always the classic XKCD cartoon that I love so much that talks about standards, right? And there's 14, but this one's gonna be different. Great. Now we

 

Alright,

 

have 15,

 

this

 

right?

 

one's gonna unify it all, exactly.

 

Yeah, right. I just responded to somebody on Twitter with that the other day. It was pretty funny. Um,

 

Yeah.

 

so, you know, the first static site generator that I can recall being aware of, I think was Hugo or Jekyll, Jekyll when GitHub pages, you know, first started using that and allowing that. And so obviously there's

 

Oh yeah.

 

been quite a plethora of static site generators come along. You know, whether it's the Nuxt and Next from View and React. to there's some static site generiped as you can go and list and it's unreal the number that are out there.

 

Yep, yep.

 

You know and as you know we've talked about before on here the pendulum swung from you know the lamp stack to going the other way to glue everything together you know all the JavaScript SPAs now are swinging back to sort of where we were but without the lamp stack you know I can remember when I first started doing my very first website. This was in the late 90s, that'll date me a little bit, when broadband internet first came out. You first had dial-ups and AOL and all that. And then when broadband first came out, mine was on AT&T broadband at home, where I happen to live. And I can still remember getting HTML goodies, the book. and learning how to do HTML and building my own little HTML website on the space that the ISP gave us for hosting and,

 

Sir?

 

and just building it in there and manually resizing some images of my daughter and other things and, you know, putting it all up there and that was a static site. You know, you

 

Yeah?

 

uploaded and then for years after that, before I got into Drupal in like around 2006, many sites where there's an FTP connection, you got your, your, uh, PHP or or HTML files, you know, and you uploaded them directly to a server. And so it's like we're going, the circles come around except it's a lot easier to get there now, right?

 

It was my favorite comment from our Hacker News launch on V1. Like we were on the front page, got all these comments, you know, Hacker News, not the easiest bunch of people to impress, but there was plenty of comments where it's like, wow, it really feels like we're going full circle. Like this is like some return to an older way of doing things that was really nice. And, oh, it's just like so good. Like, and like they thought they were making this point that was like a dig at us. And it's like, no, that's like, that's totally what we're trying to do here. Like it was actually really cool to see. Even in being snarky, people were like totally repeating our thoughts back to us as like exactly why we thought that this project should exist in the first place. It is very much a return to bring some of the things back that we've lost over the last decade I'd say and do it in a way where you don't lose this great developer experience that you know Next.js deserves a ton of credit for really moving from a best in class to almost the status quo of having great dev server, great kind of JavaScript experience, but that's definitely made at the expense of, I have a similar story of how I learned. I learned on PHP, I learned on just playing around with HTML and CSS and script tags and style tags and built up my skillset over time, but I can't imagine learning web development today coming from zero to, okay, here's JSX, here's React, and it's Server React that's also gonna run the client and hooks and... It's all stuff that is super powerful, but oh my God, to a lot of developers, whether you're just learning out, learning and getting started, or maybe your use case just doesn't need to be the next Facebook, that's where Astra really has been designed to slot in. So that's kind of a roundabout origin story of like everything that you just said, I completely relate to, it's how I learned as well. that story has been weirdly lost over the last decade. And I don't think that was intentional. I don't think we lost ease of getting started, playing around and hacking together fun stuff because it was bad or wrong. I think the developer experience got so much better, but it was kind of in this direction that I don't think we fully grappled with the, you know, where that took us. It took us into a world of complexity, which pays off if you know what you're doing, if you're building a super complex app. But for a lot of other users, I think it's been at the expense of something that I miss in web development, which is just the creative kind of feedback loop. and that output that you can do when you're just playing around.

 

I can remember a few years ago there was a pretty famous post, I think it was on Medium, and I remember seeing it on Hacker News. And the idea of the post was to illustrate how difficult it had become to set up just a simple website now. And the way it was written was sort of a conversation between a new guy and a more experienced developer. He's like, hey, I just wanna, you know, I wanna spin up a website that pulls from database and displays this data on the page. Well, you need to do this and you need a build process and you need to do this.

 

Yeah,

 

And, you know,

 

yeah,

 

then

 

that's

 

you need,

 

a

 

you know,

 

hundred

 

a compiler

 

percent where

 

and

 

we're

 

you need

 

at.

 

Babel and... all this stuff and the whole it made the point pretty well. And there was some pushback on that where people said well yeah but build processes are good we need them for this and this and that. I wish I could find that post because it was awesome.

 

Another really, really influential post for us as the greeters of this was Chris Coyer's The Great Divide piece,

 

Yes, I remember that piece.

 

which is an incredible piece that really I think hits home this idea that web development has gotten complex to the point where we're literally fracturing our industry. It's almost like there's two different types of frontend developers. a design oriented CSS, HTML, semantic, like everything about the thing that gets kind of presented to the browser and then the JavaScript expert, like the person who understands how state is managed, how routing works, how client-side versus server-side versus SSR versus SSG. There's a whole skill set that's just being a JavaScript expert these days. And that is, again, very powerful for some sites, but what I love about that post is it speaks to what we've lost along the way. I don't think that was ever intentional. I think some could argue that it was inevitable that as our industry grows, as the web gets more advanced, you might have to split, but I don't think it's a necessary thing. I think what Astra shows is there's a way to have your cake and eat it too here for a certain type of user, a certain type of site. You can have something that feels really raw and fun to use and fun to learn. While at the same time being the great developer experience that we've come to get used to with Next.js and others.

 

Yeah, I first got into, you know, when I first started learning PHP MySQL, it was just straight PHP MySQL, CSS, no CMS, no nothing. And I was probably one of the few developers that didn't try to write my own CMS. Uh, but I can, you

 

Hahaha

 

know, but I got into the Drupal world and was there for a while. And I can remember when I first started playing with, with Drupal itself, you know, the end of 4.7.6 was last 4x version and then into Drupal 5. up a Drupal site, you know, it took a little work, you have your MySQL installed, you know, install everything, do a little config, and you were up and running with just a little local site, and that was how I started playing with it. I made my first blog using that, but now you look at where that's gone with Drupal 8, you know, now Drupal 9, and they're working on Drupal 10, and it's... you can't just spin it up real easily for a local site anymore. You know, it's, it seems to be more enterprise focused. You've got composer and guzzling, symphony, and all kinds of tools in it. I'm sure though, some people that'll push back on that, but like a lot of things, it, uh, uh, it just sort of grew. And, and now you've got this big gap, you know, back at the basics, you know, this is, I just want to spin up a little local brochure site, you know, help me with that.

 

Yeah.

 

So, so.

 

The funny meme of our community these days is that Astro is just like a secret, sneaky way to teach the new breed of jam stack JavaScript developers PHP. Like you can really with a couple of tweaks, like maybe change five characters and Astro syntax for how we do component, how we do HTML templating starts to look a lot like PHP where you have your server logic up at the top of the file and your actual templating logic at the bottom.

 

Oh, right.

 

And

 

Yeah,

 

it's

 

for

 

a

 

sure.

 

really interesting architecture because we don't have to worry about client-side reactivity hooks state, like all the things that react and view as well, we're all designed for was the complexity of the front end. And I think that's been the biggest thing about using view. all the way down your stack the way a Nux does. It comes at the cost of, well, now your language that you're using to express your site, you're always having to juggle the complexity of client state, client interactivity. Aster is this way to still get view when you need something interactive, when you need to take on that complexity. But at the end of the day, our kind of pitch is, you can write view if you want, but you can also write our really, really low level, just kind of bare bones HTML templating language with. server code up here, your template down there, it all runs on the server, 100% on the server, you're generating your HTML and then this island architecture comes in where you're actually just injecting islands of view, islands of interactivity on your page versus the Nux model of everything's JavaScript, your whole page is a JavaScript app. That's really, in a nutshell, what Islands architecture is, and that's what it unlocks, is this idea of not having to pay the complexity cost all the way down your stack that a Nuxt or a Next.js kind of forces you to take on.

 

Okay, so now I mentioned earlier that, you know, before Astro came along, there's been any number of static site generators if you wanna go back to Jekyll and so on. So I'm curious to see what it was that you saw was missing that you thought Astro could fill in that wasn't out there in other static site generators.

 

Yeah, I mean, I really like we started as a static site generator, because it was the kind of biggest missing piece and the kind of easiest way to get started, you know, building an SSR server architecture is much more complicated than just outputting some HTML and CSS. So we started there, but really, we now see it as much more just like a web framework like Knox or a full site builder, not just a static site builder, but What's interesting is our default is static. So I'd say that's the biggest difference where next and next have this like export kind of secondary flow. We see the static site as the best default. Like it's really simple. You deploy it anywhere. Everyone has a guide for how to deploy a static site. If you need the server rendering, then you can kind of opt into that complexity. The thing that I'd say it most brings is, and we can even go back to like the origin story, the Astro itself. a couple of us were working on this other project, Snowpack, which in the early days was very much head to head with Vite and Vite really kind of won out. But back when we were working on it, it was this new dev bundler ESM, like all the cool stuff of Vite was like what we were excited about with Snowpack. And what we were building was the doc site and we used 11.4, it's a classic static site builder. Might've even used Hugo at a time. So like that we were playing around with static site builder and what we loved about them was Oh wow, like just the way that this sets up my site is all HTML first. It still gives me the tools to reach into the JavaScript toolkit to bring. I think we used react or no, we probably use pre act cause it was just, we need a lightweight catalog. We had a catalog of plugins. So one page was pre act. The rest of it was all HTML generated, super static. And Alex Russell, if anyone here listening knows like performance grandpa, I would call him a Twitter just always just like, you know, shouting it, you know, the sites are too slow, the sites are too slow. He just kind of constantly making that message. He even reached out like via DM was just like, hey, what did you do to make that? Like, how did you do this? This is really cool. And like totally unprompted, which from him is high praise. And the weird takeaway was we didn't do anything. We just used a tool that made JavaScript an opt-in versus a default. And so Astro I'd say is very much trying to make what we did with that site, the default, which is that Client-side JavaScript is an opt-in. You can really easily bring Vue in, but by default, if you don't ask for JavaScript and Vue on the client, we're just gonna give you HTML. We're gonna take your Vue components and render them to HTML, fully server-side, and not force that cost until you're ready, and then we give really nice APIs to bring those Vue components into the front end with islands.

 

Okay, so what's the, what was, when did you start working on Astro, I guess, what would you sort of consider its start date?

 

I think, I mean, it kind of came very organically out of that project. I might say January of last year. It's been a while now. I think we said 16 months from like first commit to the repo, um, to our V1 launch. That was a timeframe we've, we kind of cataloged in history. Um, but it's been a while. We've definitely been thinking and researching on this for quite some time.

 

So I'm curious, have you ever seen a Vue project called IELTS, I-L-E-S?

 

Yes.

 

So

 

So,

 

we had, Maximo

 

now we get going.

 

Messini, we had him on November of last year to talk about IELTS and their whole approach to just having the little islands of JavaScript functionality in the midst of HTML. And so I've always curious to see if that was an inspiration for you at all, or if you were even aware of them, or if they're your main competitor, or how you

 

I believe it's

 

see

 

the other

 

them.

 

way. I think the thing that we're most proud of is the client directive. So this primitive to I'm building my HTML first site, but then I want to add a interactive component on the page. The way that you do that is with this client colon and then you kind of get to decide like load immediately or Load on idle so you kind of have a little bit more of a performance or so I should say less of a performance impact. There's this really cool one client colon visible Which is basically like if the user never sees this component, it's never even gonna load It's only when you scroll into view that's gonna actually trigger that That client colon directive is something that I think has probably been our biggest impact outside of astro where Isles, borrowed that from us, Capri I believe it's called is another one.

 

Sounds

 

Even

 

familiar.

 

is land which is an 11d project uses something very similar I wouldn't say it's the direct one to one but it's a very similar directive idea. Quick, which is this new framework is doing something

 

Yes.

 

similar to get like islands of react within their framework which is wild.

 

That's Misko

 

We

 

Hevery, we just talked to him last week

 

oh nice yeah

 

about

 

that's

 

that.

 

a really cool project very similar and it's kind of focus of like I think there's this whole movement that's kind of sprung up that we were very much in the early days. I think we definitely had an impact on all of these frameworks as they kind of set this up, which is there's a really cool primitive here, which is controlling the loading of the component when you use it. I think Misko would even say like there's this idea of just like, all you're doing at the end of the day as a web developer is like attaching client side JavaScript to some element on the page. And the way that react and view when you're doing the full SPA, the full next and next to yes is whole element, whole page, whole JavaScript app. It's all one big thing. And what quick and Astro and aisles are all exploring is what if you broke that down much more granularly, and you're just thinking this component and quick goes even further. They say you're just thinking this like event handler like on click. That's one granular chunk. So they go way deeper than we even than we even do with the with Vue.js because we think in components, we bundle by components, where our whole model is very much granular components. And so that's, I think, been our biggest impact on, at least the last year as we've developed this, we've seen plenty of projects borrow, build on. You could call ILS a competitor, but I would not consider them that. I think we're all exploring the same space here. I was being viewed first while we are taking a much more support every framework kind of, you know, Drupal WordPress. Like we don't want to pick one. We want to support all of them. That's, that's been our differentiator between aisles.

 

So you mentioned Drupal and WordPress. How do you work? How does that work? I don't understand.

 

Oh,

 

Are you saying

 

sorry.

 

that you just have a base Astro and then you could import a Drupal component in the Drupal twig templating? So, I'm gonna go ahead and do that.

 

Sorry,

 

I'm gonna go ahead

 

sorry.

 

and do that.

 

I meant them as we love that big tent story that they tell where like Drupal isn't saying like view is our framework. All other frameworks use something else. They're, you know,

 

Oh, gotcha. Okay.

 

so we're entering HTML and then they let you kind of bring your framework. That's the model that we really like about those older technologies that we're trying to bring into Astra. We don't take a stance. We support every framework, react, preact, views, felt. And because we're at this granular component level, we take on the routing. We take on the infrastructure of your framework. But... you still get to choose your favorite for the front end. So it's that model we really like.

 

Right, so, oh gosh, I just brain farted on where I was gonna go. Oh yes, so as a developer, one of the things that made Astro easy to work with for me is, as you mentioned, the whole component structure, where you have components and pages and layouts, and you can make a component that has just a nav bar, or just a header, or just a body, or something like that, and import and pass props to them. all that kind of stuff. So yeah, that's one thing that made it very easy, at least familiar for somebody coming from other frameworks that have that component structure. So that just certainly does make it easy to use. Anything about that that I missed you wanna talk about? So, I'm gonna go ahead and start with

 

Yeah,

 

the

 

we,

 

the

 

I mean, we started out talking about the new user experience, learning development, but even just learning Astro, if you're coming from something else, that is not an accident. We really tried to have one hook for every type of user coming to Astro for the first time. So if you're a view user, you're going to feel really familiar with a single file component structure, the idea of your script and your template, your style, all living in a single file. But we lean into JSX a bit more and it's not truly JSX because we are real HTML, like you use an image tag. So we are truly HTML compliant and kind of built on top of HTML, but we do that by sprinkling and it feels a little bit more like JSX. So if you're coming from React or Preact, that should feel really familiar versus, you know, view and spell take a more kind of templated syntax approach. All that's to say is that learning experience coming from view you should feel really at home with asterisk component syntax And then again the really fun thing is if you just want to use view a hundred percent down your stack You still can we'll do the HTML rendering for you automatically

 

Right, so now the way an astro site is built, speaking of the components, is your base file is a.astro file, right? So that's what you use. So I assume you have some sort of, gosh, what's the term I'm looking for? Something behind the scenes that interprets those, breaks them apart.

 

Yep. Yeah, we built a compiler

 

Compiler,

 

powered by Go actually,

 

thank

 

which

 

you.

 

is

 

So,

 

pretty interesting. As everyone's doing Rust, we're like, nah, Go is what we want to use.

 

Mm-hmm.

 

But at the end of the day, it gets compiled to Wasm and it's really fast. So

 

Yeah,

 

that

 

those

 

was

 

seem

 

a fun

 

to be

 

project

 

the real

 

to

 

heavy

 

kick

 

hitters

 

off.

 

from that server

 

Yeah.

 

side, Go and Rust, at least the ones

 

Yeah.

 

that I hear them out the most.

 

Well, especially with Hugo, I mean, just like there's so much inspiration there and how they do site building that, yeah, Go is alive and well, as far as our compiler is concerned.

 

So let's talk about Wasm for a minute. That's WebAssembly, I'm assuming. So how does that, let's talk about, I guess, what it is, you know, just high level, and then how you're using it in Astro.

 

Yeah, I mean, this is you stop me if this feels like a tangent, but I could go for hours about this because especially

 

I'll pull

 

in

 

you

 

the early

 

back

 

days,

 

if you get too far down the rabbit

 

at least

 

trail.

 

it so was almost created. No, I actually don't know. I am not the person

 

Ha

 

to come

 

ha

 

on

 

ha

 

to

 

ha

 

tell

 

ha!

 

you about wasm, but I will say it's been really interesting seeing the web ecosystem start to adapt wasm in a lot of different ways. And there seem to be these two camps, one which is rebuild everything in wasm. So that would be like the Rome approach or even the US build. could sort of fall in that, which is like our whole tool chip, our whole tool chain should be a compiled language like rest or go and web developers will love it because it's fast and truly it is incredibly fast compared to web back or some of these JavaScript based tooling, which the performance profile is completely different at the same time, if you look at yes build and I don't know if Rome could fall into this, but like yes, but I think it's that we'll use that as an example. That is a project with one contributor. There may be a couple of people making small changes, but like by using Go, your user is no longer really able to make contributions back. in the same way of like a webpacker, a babble, where those are open source projects with hundreds of contributors, maybe thousands at their scale. Um, because a lot of good reason of that, I believe is that it is a JavaScript tool. Their users are writing JavaScript and they need to make a change. They have everything they need to go and actually make that PR file the issue. They feel familiar with the tool itself. Um, that is a huge superpower that we get to benefit by being a JavaScript based tool, but Our take on this is that the future is these core pieces of infrastructure for a tool like Astro are individually being built in Wasm. So our compiler being this thing that like it's a pretty complicated piece of software. We don't really expect a lot of changes to that from the community. We don't mind the cost of reduced kind of contributors, but the efficiency that comes with it. At the same time, 90% of Astro is this runtime, this thing we built around the compiler. And that's where most of the bugs happen. It's where we're adding features. It's where we're, you know, the compiler is stable. The runtime is where we're developing Astro and really building Astro. So we end up kind of getting, again, best of both worlds here. It's a phrase we like to use and we like to leverage when we can. The idea that Astro is itself JavaScript based while the heaviest lift. which is a compiler ends up being WASM based is actually we get the performance of WASM and GO being compiled to it for the heavy lifting. But then... JavaScript is still really good at juggling a lot of things, especially IO. And that's where we can just shoot a lot of work into this compiler and get it when it comes back. And we're actually not really paying a performance cost. There's even a performance benefit to using node JS, um, or, you know, demo one day maybe, um, for using JavaScript for the, basically you could call it the orchestration of everything. So we see this hybrid WASM hybrid JS approach to tooling being really the best of both worlds. You don't lose your user base. You don't lose their ability to contribute. percent of the performance benefits of using WASM for the heavy lifting where it matters.

 

Yeah. Yeah, that makes sense. A good combination of the lower level stuff that you probably won't get many contributions from unless some really hardcore people, right. And then open up the higher level stuff for

 

Yeah, that being

 

where

 

said,

 

you'll.

 

it's early days for all this. Roam could just completely knock it out of the park. They're going full Rust, whole tool chain. Super curious to see what happens there. But for us, this is perfect for us. We're mostly JavaScript developers, but we have someone on the team has learned Go and now has built a pretty impressive compiler.

 

Nice. So let's talk about component structure for a little bit. It's basically using, I guess you call it a front matter type of approach. I think that's correct where you have your three dashes at the beginning and the end of your code section where you can run all your JavaScript and do whatever you need to do, create variables,

 

Yeah,

 

and then

 

think

 

below

 

of it

 

that.

 

like your view script component or again, PHP. It's your, it's your PHP tag. It's a server code of the component.

 

Right, yeah, what we put in script and then below that is what in a view template would be the template tags, right? So whatever you're going to render, use for rendering your HTML.

 

Yep, that's right. And the big difference from like a Nuxt or probably a lot of what Vue developers might be familiar with is that script, the front matter script, it only ever runs on the server. So the benefit of that is you can literally put like a database call, you can put a fetch call, you can do a top level of weight. The whole language is designed for real ease of use around because we're on the server, let's take advantage of it. Make whatever logic you need, whatever you need to make your site. Make direct database calls. You don't need to wrap everything in an indirect layer of loaders and API calls. It's all going to be server-rendered. It's all going to run on the server. So you have a little bit of a guarantee there, which then also lets us make a language, which, you know, top level await top level fetch is real nice.

 

Right. Now what's interesting about the template portion is that's as compared to view, that's a little more lower level JavaScript. You know, in view, right, you'll have your different directives, v4, vif, vbind, beyond, you know, that's sort of the syntactical sugar that view gives you that allows you to do things much easier than having to write a map or filter, you know, some of the other functions, but in an Astro component, you can just write plain JavaScript. I'm looking at one of the components that I have or a pattern that I have in this one particular side I'm working on. And I just have my open curly braces and I have my variable that was an array coming from the script portion. And then I just map over it. And then within my map, I return my child component and pass props to it. So very similar to how I do it in view with some differences. So just about any JavaScript can be used within the template portion of Astro component. Is that correct?

 

Yeah, we think of it as JSX like I'd say,

 

Mm-hmm.

 

the way we'd really describe is it's HTML with like JavaScript sprinkled in or JSX sprinkled in so Again, we're a little bit lazier and a little bit more lax than JSX, which has really strict rules about when you can close and open, you know, there's just HTML is not really one to one compliant with JSX. I'd say that's one of the biggest things we were trying to address with our language. If you copy and paste HTML and put it in a JSX file, good chance it's just going to break. You're going to get the red squigglies. You're going to have to go and edit it. If anyone's played around with JSX, they've probably run into that eventually. Our language is HTML first and then it's sprinkling in the logic to map over an array, iterate over different things. We don't have a lot of directives for templating logic. We really just, as soon as you need something advanced, fall into JavaScript. You can always come back out into templating the same way that you mix and match with JSX.

 

So another option that you have in addition to HTML is Markdown and MDX, right? So I guess you would want to use that for more of your text heavy type content that you would want to put like a blog, documentation, so on. I know for instance, I did a blog site in Nux 2, so this is a couple years ago, where I used Markdown files. I just had those and then imported it in and read through those and spit it out. Static generation,

 

Yeah,

 

faster.

 

Markdown's great.

 

So yeah, that's another option instead of just using HTML for sure.

 

Yeah, and you really see our kind of like content focused, you know, this type of site, like Markdown coming from a static site builder originally and working our way up the kind of complexity stack. Markdown is like a no brainer when you're building with Hugo or 11D. It's one of the biggest features that they're known for. So for us, it was also likewise a no brainer. If you're building a content site, you need a really easy way to author content. So that's where Markdown and later MDX came in for us.

 

Right. Now moving on routing. So this is very similar if you're familiar with Nuxt and the pages directory. It's almost identical here because you have a source pages directory and then as you create your files, those generate your routes for you. So reminds me of my first PHP days where I would have something.php and that was my route and then another.php for

 

Yep, yep.

 

that before Apache and your dynamic routing. capabilities that you could use. So yeah, that's about as pain-free as you can come. As the documents say here in the tip, there is no separate routing config to maintain in an Astro project.

 

Yep, it's funny, we think of file-based routing as this like modern next JS NUXT kind of, but yeah, that goes back all the way to the early days of just throwing PHP files on a server hosted somewhere and seeing what happens.

 

Yeah, exactly. But then at the same time, you can do your dynamic routing, similar to Next again, where if you have an ID value for a blog post, for instance, like that, you pass that out and it's one of your URLs, and then it becomes available within your

 

Yeah.

 

components.

 

And I find this part of it fascinating because I think it's just the part of things that I think about a lot. Hopefully everyone listening doesn't get bored out of their mind by this. But like the philosophy

 

Hmm

 

of what we've built is like if you take a look at the ecosystem like really zoom out, you've got Next, you've got Next, you've got SvelteKit, you've got oh god what else in this kind of framework-y

 

quick.

 

I guess this is the remix.

 

Yeah, right.

 

God, what else? Everyone is just doing some blitz in the earlier days. Like everyone is trying to solve the same problem. Oh, solid start quick, yeah. Everyone is like, at the end of the day, everyone's just building routing. It's all just different takes on routing. And there's a really interesting story here about how Astro, by being unopinionated about the framework, is trying to be this one platform that any one of these frameworks could hook into. So. There's a way to look at Astro as we're trying to do the routing logic so that you as a framework author, if you're, you know, if you're having you view, you can just be like, Oh, great, this is like routing. Great, like UI as a component syntax can sit on top of Astro. It doesn't have to be all the way down your stack. You can leverage what we built. And we really actually saw this very directly early on, Vsauj.js had kind of come onto the scene right around when we were maybe not v0.0.0, but you know, in our first six months. And... to build a new framework, right? Like Solid, there's a ton that you need to do to catch up with where Reactor view is. Like having your Next.js or your Nuxt or your full app development story is an essential part of building a framework today. And we got to be that for Solid. They essentially shipped a pretty simple integration to get Solid working on Astro. And all of a sudden they had this really cool story for how anyone could use Solid to build a full site with Astro. Like out of the box, they basically had their Nuxt story with a day's worth of work. Again, this is kind of like more of a philosophical take on what we're building here, but it's something I'm really excited about, which is everyone's duplicating the same work all over the whole over the world of tech of web development right now. And we have a chance here to actually really standardize like here's a routing system that anyone can hook into without having to adopt one framework and only one framework that you're always going to be left with. If you ever need to migrate, if you ever need to change your, the newest version of you comes out and you want to play around with it. You know, that's something that today involves throwing out your entire stack with one of these, you know, to move from react to solid, that's a huge change. But in Astor, we do have this idea of the frameworks being pluggable. So you could try out solid in a single component and not really mess with your current react app or an entire page or an entire section of your site. And you can kind of grow and crow as you go. Island architecture was designed, originally coined as a term at Etsy because they were moving their PHP architecture to start bringing in more modern components and they thought about it this way. It's a way to migrate to the new thing island by island, component by component. So yeah, this is a story that's been told plenty of times before and we just got to build a framework around these ideas.

 

Now moving through the docs here talking to the guides, you have items here on integrations and UI frameworks. Is there a difference between those two? Or is the integration basically just importing the view stuff so that you can turn around and use view within your site?

 

Yeah, it's most familiar to anyone in the Vue ecosystem who's used Nuxt modules. These different UI frameworks are essentially added as integrations, as modules in our world. So adding Vue is as simple as adding the Vue integration. But it's more flexible. It also lets you add the Tailwind integration for a really quick setup of Tailwind and, you know, Google Analytics, different CMSs. Like everyone has a story there similar to Nuxt modules.

 

Right, okay, so sort of like in view with the view CLI would do for you, if you say, okay, I want this and this and this, it's gonna go set it all up for you and

 

Yeah, exactly.

 

instead of making you do it manually. Okay, so let's talk about the islands themselves. We've talked about HTML and JavaScript and how that works. So again, the idea here is that you can have a whole page with a bunch of content. Maybe you want some interactivity in the middle of your page, maybe signing up for a newsletter or. I suppose there's any number of possible pieces of interactivity that you might want. What are some, I guess, of the more common types of interactivity that you've seen people add using these frameworks inside of an astro site?

 

I mean, it's whatever you're building. So again, where we get to kind of say the best type of site to build with Astro is one that's really focused on getting some content to your user as quickly and as simply as possible. So to use a blog or you can just go all the way to a CNN or a Washington post.com, you know, like full on publications all the way down to personal dev blogs. The idea is that at the end of the day, you're just trying to get like content in front of the user. They're going to read it. They're going to interact with it. But it's all about the experience of consuming that content. So for that type of site, it's not user data. There's not state that's really being managed. That's where these islands can really kind of thrive, where they already are. Yeah, you brought up the email sign up, right? That's an island that's an isolated component of interactivity. I'd say the biggest thing about this architecture is one, you're detaching them all. where next would bring it all into a single JavaScript application. It's really hard to piece apart. It's, it's why you have to ship the whole thing down to the client to hydrate a second time in the client in the browser. Um, and after it's much more component by component. So we get to basically reduce a lot of the complexity that comes with just shipping everything. It's all isolated. They're all rendering and loading and isolation. There's a complexity story there. The other big benefit is just the parallelization or the kind of isolation that lets you control loading, essentially prioritize different components over others. So, you know, that email sign up, if that's the most important thing on your page, you know, usually a team, especially at a company will have like a goal. Like what is our kind of top line metric that we're driving? If it's signups, like that should be the most important thing on your page. scrolls down is probably not going to do much for you. It's probably much lower priority. And so where a NUX is going to have to bundle it all into a single page, it's all going to load at the same time. That heavy image carousel is going to block the interactivity of the email signup. Instead Astro says no, we'll prioritize them differently. Like set that email signup to load. The page won't load until that's interactive. It's prioritized to load as quickly as possible. that heavy image carousel will delay that will delay that down to when the browser is idle and has some free time or even to when it is only visible so that the user never sees it. So there's this splitting apart that also just gives you so much more control over what you're building that you get to decide how important is this component to my site that I'm building. You have the kind of context of what you're building to know. If you don't care about it, just put them all as kind of load or maybe put them all as idle. You can basically control and have a nice default that you use. But for when you need it, you get to break it apart in that way. And behind the scenes, we're going to do the bundling and the kind of injection logic for you.

 

So one of the options, and this is probably one of the more commonly used examples that you mentioned is e-commerce. I can remember one of the first examples I saw of using a static site for e-commerce was back in, I want to say 2018, and it was Harry's Razors had used Gatsby to do e-commerce and it was for their women's... line of razors, Flamingo I think was what it was called. And they had a blog post, I think it was on Medium, about how we did it and why we did it. And so what they had done, if I remember correctly, was they had basically decided that when there are changes, you do have to rebuild the entire site, just because that's how the static site works. But in their particular case, it wasn't a particularly huge site with lots of products. It's not like Amazon or Walmart or something like that. It was fairly... low in terms of content size. Obviously, e-commerce is going to require a number of interactive pieces, whether it's a login, your shopping cart, and all of those things. If anybody hasn't done e-commerce, they must be living under a rock, I would say. So we're all probably pretty familiar with it. So can you explain how you would structure an Astro site to do something like that? from an e-commerce standpoint.

 

Yeah, it's definitely the most interactive we would recommend to use Astro. So like that's I think actually, I kind of flush this all out one day in a tweet thread that spread pretty far of just there seems to be the spectrum between content based and interactive based or maybe content and like stat and state like where you're interacting with things versus just consuming them. And e-commerce kind of sits in the middle. Like it's about getting that thing loaded as quickly as possible, but then the ultimate goal of e-commerce is to interact, to pay, to ship it to yourself. So it really sits at the kind of crux of both of those things. The thing that that means for Astro is that you need to build something and really think about this idea of islands are all individual components, they're individual islands, but. shopping cart you mentioned, that's a clear example of you click the buy button and now the shopping cart updates, it goes from zero to one or one to two. You still need a way to share state and kind of pass messages from island to island. And Ben on our team calls them boats, right? You're literally sending state and sharing state across your site, even though the actual islands themselves are all isolated and running in isolation. So this is all very possible. We use this thing called nano stores is our kind of general answer to this. But again, what's really nice about like just letting view do its thing is view has a whole ecosystem of managing state and all these components, they don't have to run in isolation. They can use the state management that a view app would recommend and push you to use. So I think it's, I'm gonna forget all the names of Pinnia, I wanna say, is that right?

 

Pinier is a new state library for View3, yes.

 

which uses the idea of like, I believe it is like, you actually import this like atom or the signal that you're gonna manage. And that's where like Svelte has a really great built-in state management that works really well with Astro, because you're essentially importing your store. And it's this thing that lives at a file, two different components will import the same store. So there's that connection there. React and Redux like that's a real example of saying that doesn't work as well with Astro because if you think of what Redux is, it's like everyone's sharing the same component provider. Like when you break everyone apart, all of a sudden they'll have their own state tree. So it's not a you know, it's not a zero. We want to get to a kind of one click way of thinking. But as of right now, you still need to manage this idea of how are my components sharing state. We get plenty of guidance there, but it's really still up to you to choose the right tool for the job.

 

So yes, you have the NanoStores library, which you mentioned in your documentation on sharing state. And my guess is that's supposed to be framework agnostic, right? You can plug it in with whatever framework

 

Yeah, which

 

you're

 

is

 

using.

 

really cool because then a view component and a svelte component can share a state on the same page. Like one update happens in view and it's going to trigger this svelte component to update as well. So that framework agnosticism, if you need it, is obviously very cool in Astro.

 

But you could use Vuex for instance, or Pinio if you're using Vue, you can plug that in as well. So let's, I'm always into the details and the nitty gritty. So one thing I'm still trying to comprehend is how, what in an e-commerce site, for instance, what is static, what is dynamic? For instance, I'm gonna guess your product pages are static for the most part, because you're not really changing your products on a regular basis, at least most people. You know, the classic Wolf Moon t-shirt is probably not going to change much

 

Sure, sure.

 

over time.

 

Yeah, it's really up to you. I mean, so thinking about, yeah, let's just picture like a product. It's got the photo of the thing you're buying, the information about it. If it's a t-shirt, let's have like a little size picker, and then obviously the buy button. you think of it less about like, is this information changing often and much more like is the user meant to interact with it? So the photo is a really good example. It's just a single photo, like put an image tag on there and move on. Like that'll just be all you need. But if you want that, okay, when I click it, I want it to zoom or if I click it, I want them to flip to the next photo in a set of three, that would be all of a sudden interactive. So it's less about the data changing and much more about the interactivity needs on the browser. As soon as I click and something happens. That's a really good signal that you want to use one of these islands. It's when you would want to bring view into the picture. But if it's just a single image, use the image tag or the title, the description, that's just text, right? You don't need to ship a JavaScript component to render text, which was already rendered on the server. finishing it up, you know, the size picker that's obviously going to be interactive. I switch which size I want. That would be an interactive component and the buy button is usually going to trigger something to happen. So even that's a little interactivity, right? When I click this button, I want to update my shopping cart. Um, that would be a good, a good, good use case for a view component. So it really depends more on what is the user expected to do with this part of the page. And if it's interact, then you should be using view. If it's just read it or consume it, or maybe it's a layout kind of component. It's the thing that's giving you your kind of two column layout. That's just presentation. There's no interactivity there. So you don't need to worry about that.

 

Cool, cool for sure. Now you mentioned images and I thought I'd share a little interesting story here. So there's an images component. Is it still beta? I can't remember the status of it.

 

It's, yeah, we were still kind of experimental, although we're pretty much working full time on that. I'm getting it up to kind of V1 level to match the rest of the project. I'd say use it at your own risk for at least the next week or two, but really the final bugs are being squashed this week.

 

So yeah, I had not too long ago, about a month ago actually, I had an issue with the images where I was trying to do it and it was throwing some node errors when I was trying to import it. And actually you answered this. You were the one responding to me. You

 

Nice.

 

and

 

Nice.

 

Nate Moore. And

 

Yeah,

 

short

 

made on

 

version,

 

the team.

 

I filed the issue and like two days later, there was a new version of Astral Roll that had a fix.

 

Yeah,

 

Astro

 

that's that's

 

One Point.

 

V1 release energy. That's just as issues come in, you're squashing them left and right. The funny story with the image component is that Tony on our team, Tony Sullivan, built the image component and was out the week that we did our V1 launch. Just vacation totally. So we didn't realize he was like, yeah, like, you know, it's still experimental, really. All right, cool. Like we're writing the blog post. We're putting it in like use the image component. Completely misunderstood that like, no, no, this is experimental. And so we ended up launching, I'd say maybe a bit more confidently than we should have with that. Tony's just been working pretty much nonstop to get that up to speed, but that was more us getting a little bit ahead of the ball there with that component.

 

I don't know, I was impressed with how quick the turnaround was.

 

Yeah, well, it's an important image. It's one of those things where JavaScript is this really expensive resource to send to the user. Per byte, it not only does it have to be downloaded, it has to be parsed, understood, executed. But after that, I'd say images obviously are a huge place for performance improvements. And that's the end of the day kind of why we exist as a framework is to make these sites faster by default. So we were super excited to get that image component out with our V1, even if we're still cleaning it up a bit for the next week or two.

 

Right. So now I can assume going forward that anytime people file an issue will be resolved in the next day with a new release. Is that?

 

Yes, that's

 

Yes.

 

super healthy for us as maintainers to set that expectation.

 

for sure.

 

Um, it's, I mean, there's this V1 kind of expectation that users have, which is very, very much what we're trying to honor. It's, it's why we did a V1, you know, react famously, we did like zero dot 14, then V15, they're just like, you know what versions don't matter. Um, we very intentionally wanted to say, this is our V1. It's us. Stability, bugs, these are things that we're going to value and prioritize. Now we, now that we're past our VZero infancy, we know what Astro is. We want to kind of, we want it to be stable. And that's our biggest thing we're working, looking at post V1.

 

So now there are many of you that are unlike me that are very big TypeScript aficionados. I still haven't dipped my toe into that well yet. I probably should at some point. But you will be happy to know that according to the docs, Astro ships with built-in support for TypeScript. You can import TS and TSX files in your Astro project, write it directly within your Astro component and even use an Astro config TS file if you like. So it's all there for you out of the box.

 

Yeah, I mean that we should maybe even be a bit more explicit. Like we Astro has TypeScript built in for every user. It's, it's essentially built into Astro in that server language up at the top. So if you've never used TypeScript before and you've built Astro, surprise you've used TypeScript before. Um,

 

Hehehe

 

it's kind of just built in and bundled with Astro. The way that we presented is basically saying, listen, if you don't care about TypeScript, our default TypeScript config is going to be really relaxed. Like you really should never see an error. unless you're doing something really wrong, in which case we're trying to help you, but you never have to write a line of TS config, like a line of TypeScript actual types or interfaces or anything, unless you want to. But it's there if you need it. So we're going to still give you all the great kind of benefits of TypeScript, code hints in your editor, you know, errors when you do something really wrong. But ultimately, it's kind of meant to be this like kind of hidden like Trojan horse, like you're using TypeScript, if you don't want to, that's okay. You never really have to think about it. It's just there to help you out. you never actually have to author it yourself.

 

Okay, now let's come back to something you mentioned at the very beginning, how we mentioned that it was initially a static site generator, but now we have SSR, server-side rendering capability. So that's, I mean, basically you're now up to what a Nux, Next, whatever can do, right? Instead of, it doesn't have to be static, you can also be dynamic. So explain how that works, first of all, what it is and how that works, and then I got some follow-up questions.

 

Yeah, I mean, it works a lot like how it does in any other framework. So we, again, we're trying to be really kind of matching your expectations coming in to Astro coming from a Nuxt. Um, but the biggest thing that I'd say is that our language is designed, the Astro component, it all renders, you know, in an SSD, in a static site world, it's, it's running at build time. So when you build your site, it's going to go and make that fetch call or make that database call. In SSR, it just kind of moves that logic into the server, wherever you're deploying your site, that database call is now gonna happen on request. So there were some interesting challenges as we built that, which were really about, you know, you can't assume you know the output of the page when you're building the site. It could get rendered totally differently in the server based on what comes out of that database call, you know. success versus error, we need to be able to build to make sure that everything is bundled appropriately, even not knowing what the actual page output looks like yet. So that was a big technical challenge coming from a static site builder. But the thing I love about Astro the most is that we don't, we flip the script a little bit instead of defaulting to the complexity of SSR and having that a static site as this kind of like secondary flow, um, defaulting the static, like our Astro.build website is still a static site by default. It's, um, we haven't hit the scale where we need to take on the responsibility of a server. We haven't hit the use case yet where we need that server data to be rendered. So. for even a project as big as ours, we still don't have the need yet for SSR. So we don't take that on, um, totally opt in versus being opt out.

 

Okay, so as I'm reading your docs, it sounds like it's all or nothing. So Astral will, according to the features heading on your SSR page, Astral will remain a static site generator by default. But once you enable a server-side rendering adapter, every route in your pages directory becomes a server-side rendered route. That was all in bold. And a

 

Ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah ah

 

few new features become available to you. So my question is this. What if you want some of your pages to be static and others only server rendered? Is there a way to do that or is it sorry, one extreme or the other?

 

Yeah, the bold text gives away that we get asked this question a lot. It's probably been actually one of our more requested features coming out of V1. Right now, the answer is all or nothing. You're going from static to server rendered and it's a big change. We see a ton of users wanting that idea of... being server rendered on some pages and static on others, and there's nothing stopping us from doing that. It was just a feature we didn't prioritize for V1. We're engineers, we're building this thing, we kind of see the benefits of SSR, and for us, you're shipping a server either way, right? The second you opt into one page as SSR, you need to think like a server. But that's not a feature that we can't support, it's just one that we didn't prioritize. So I think, I would expect to see more information about that, it's probably the most requested feature we've seen coming out of our V1 launch.

 

So then it automatically, anything in the front matter, or excuse me, that's not, what do you call that top section? Do you have a name

 

Yeah,

 

for

 

Front

 

it?

 

Matters script is what we call it.

 

Front matter script, okay. So anything in front matter is not run until that particular route is called.

 

Yep, exactly. In SSR world, that's going to basically run. So you mentioned reading that like some new features are unlocked, you get access to the response object in that front matter, that's going to change based on what the user is actually doing. Query params, you know, the question mark Q equals anything in the URL that wouldn't be available to a static site, but it would be available to something running in the server that's gonna hit all the different routes a user might send it. So that's where we see that kind of the new features that are unlocked. And again, why we think it, well, we all love the idea of having some sites be statically rendered. you can still achieve that pretty one-to-one by just having really good content headers and using a CDN, which we recommend everyone do anyway. So if you're in a world where you're shipping a site from SSR, or you're making the switch from a static site to an SSR server rendered site, by just returning the right content headers saying this thing I've rendered and it's never gonna change will basically tell your CDN, whatever's sitting in front of your site, hey, like I just responded once with this, you just go do the work of responding to every request with this thing I've just given you. So in a perfect world that SSR site even if we don't give you the tool to statically render it build time You're still going to be able to tell your CDN. Hey, I'm building this once and you take care of it I'm never going to build this again ship it to the user as quickly as possible next time from the CDN

 

Okay, so now you have adapters built in for probably your more commonly used hosts, right? Cloudflare, Deno, Netlify, Node.js, Purcell. So this is a Node.js runtime, I'm assuming it's running behind the scenes, is that correct? Okay.

 

Yep, that's correct.

 

So I'm thinking through the possibilities for this site. So this, I guess you would want a site like this. Could be a combination of things, right? Maybe an e-commerce site where your product data does change on a regular basis and still have that interactivity that we talked about with the islands. Or maybe even just a brochure site that is gonna have somewhat frequent changes, right? You don't wanna have to rebuild the entire site every time you change something.

 

Yeah, we see it as an answer to scale ultimately, or if there's a use case that needs live access to data a week after you've deployed the site. If you're building an e-commerce site with thousands of products, rebuilding site every time your stock changes is going to be a real pain.

 

Mm-hmm.

 

And so that's where we see SSR really coming in. We want it to feel that it is it's drop in. Your site doesn't really have to change your code doesn't have to change. But that is you can flip on that switch to SSR as soon as you need it. That's what I'd say is the most kind of That's what we look for when we look for users who are looking to make the switch to SSRs, are they hitting that scale problem or that stale data problem? If either one of those is true, yeah, rebuilding your whole site as a e-commerce site with thousands of products, that's a real tough, a real tough sell to anyone.

 

Well, that brings up another slight rabbit trail, and that is the holy grail of JAMstack sites, which is incremental rebuild, right?

 

See you later.

 

What that means is, as you mentioned, let's say your site has 100 pages, 100 routes or however you define it, and you change content for one page, well, that's the way it stands. Now you'd have to rebuild all 100. And where incremental rebuild is the idea that you could just rebuild that one, and that... Jen that, excuse me, send that newly generated HTML to wherever you're hosting it to your server. Now I know if I remember correctly, Gatsby can do this in Gatsby cloud. I don't know if it's anywhere else. And I know that's, you know, this has been a holy grail for a long time. Is that something you guys even looked at it considered? Is that way down the road or is that just out of the ballpark for what Astro would want to be able to do?

 

Um, for right now, our answer to that user would be use SSR, have a server actually running, generating those pages on request and just have good cache headers to invalidate that request every so often so that the data doesn't get stale. Um, I love that idea of a feature of just like essentially your site is always. up to date in like this cash that's been generated incrementally every time your stock changes to use the ecommerce example some more. But right now we just don't support that. We've gotten some inbound interest from ecommerce, like some pretty big ecommerce companies. So there might be something there that they either push us to build or even build for us. We would definitely be open to that. But as of right now, that's yeah, there's a reason only Gatsby has really done that. And they've only done it with their paid proprietary cloud system. It's a really tough thing to do. SSR does get you a lot of the way there.

 

Right, right. All right, I can't think of anything other questions I have. Is there anything about Astro you want to share with us before we move on to pics?

 

just that we love you and using Vue with Astro is a great way to build a content site. So I don't know if you'll give me a chance to plug. I got all the links to send people to if they want to learn more.

 

Yeah, we can put all those in the show notes for...

 

Cool. Astro.build is a website then, I'll just say that. Astro.build. And Astro.build slash chat is our Discord server. It's a big one. It's one we really care about a lot, so come say hi. Yeah,

 

Yep, I'm in there quite

 

those

 

a

 

are

 

bit

 

my...

 

myself.

 

Yeah, it's a fun time. We play mini golf. We have a great time with it.

 

Oh really? I missed mini golf.

 

Um, yeah, we don't do it very frequently, but, um, every once in a while we'll just be like, hey, if you can join in an hour, we're all going to play some mini golf. Um,

 

How

 

try

 

do you

 

to have

 

play

 

some

 

mini

 

fun with

 

golf

 

it.

 

on Discord?

 

So a week ago, I would have told you, you have to go download a game on steam.

 

Uh-huh.

 

Apparently some discord servers now have a built in mini golf that discord has shipped.

 

Really?

 

I, I have the lit HTML. If anyone knows that project,

 

Yes.

 

um, They have a cool new Discord server and they seem to have gotten invited to all the cool stuff that we don't get. So I guess I'm plugging into other projects' Discord server, but if you go there, there's like a button to start mini-golf, which seems to be built into Discord.

 

Excellent. I like that. I like

 

I know, I'm

 

that.

 

very jealous.

 

Cool. Yeah, we will put Astro links in the show notes so that you can click to them to your heart's content and we don't have to read them to you on the air So to speak in a podcast but excellent. Well, thank you for coming on. This has been a long conversation, but very good Something I appreciate as an Astro user myself. So Thank you for that. So with that, we'll move on to picks. Picks are the part of the show where we can talk about other things, other than Astro and Vue and tech and programming and so on. So I will start out. I do have a legit pick before I get, well, not that dad jokes aren't legitimate, but a non-dad joke pick, let's put it that way, before I get to those. So. I have switched microphones. I'm hoping the audio sounds better than what I've had before. For a couple years I've been using the Blue Yeti and I've had issues with that with lack of configurability and it doesn't sound very good in my big, huge, bright office with 12-foot ceilings and without a ton of soundproofing. So I had been looking at the Shure SM7B microphone, which is sort of the top of the line. well-known audio microphone professionally used. The issue with that is that it uses an XLR config which requires some other hardware and inputs and so on that I really didn't want cluttering up my desk considering I have no more space on my desk to clutter up, really. And so while listening to somebody else on another podcast, I looked at the Shure MV7, which is awesome. It costs about a couple hundred dollars less than the SM7B. but it has both USB and XLR connection types. And, but what some of the things that are really nice about it are the configuration options. It has an app, I'm on a Mac, so there's a Mac app that allows you to make all kinds of settings as to how far away and close up you can be from the mic, the tone, you can have natural or dark or bright, you can... Determine how much feedback you get in your headphones, you know versus something you're playing back as if in your as if you're overdubbing something for instance and then That does it a lot of auto and then you can even get really nitty-gritty with the manual settings like your mic gain your monitor Mix your EQ settings compressor and so on and then also It has a little plug-in where I can plug in my headphones into it and hear what I sound like through the mic With the Yeti that didn't work and I would have to do stuff like open up garage band and make a recording in there And play with the settings to see how I sounded to hear I can get direct feedback. So Hopefully I sound a little better now going forward but This really was a for me It was a real happy medium between the sure the more spendy SM7b and all the other $200 of equipment you would need with it versus the lower end blue Yeti and with that we'll move on to the dad jokes my dad jokes uh that i share every day with my world on various uh social media and people love it i just my fame has just increased worldwide it's amazing just from sharing dad jokes to be honest no but seriously so anyway um uh i am a big uh blood donor you know with the red cross the the vampires of the red cross hound me mercilessly because i That's rare blood that is very in demand. But anyway, the other day I went to donate blood, but I got in trouble because apparently it's supposed to be your blood. So, I'm gonna go ahead and donate blood. I'm gonna go ahead and donate blood. You're

 

There's

 

nuts.

 

a sound effect? You didn't tell me there'd be a sound effect.

 

I got all kinds of sound effects.

 

Well done.

 

Well you know unfortunately I meant to do this ahead of time and sometimes I do it I forgot but I also forgot to introduce the studio audience that's been there you know so say hi sorry I didn't mean to ignore you I really didn't mean to ignore the studio audience but they've been there all along and sometimes they'll laugh when they like my jokes you know so But I say that probably the really good ones.

 

They're really good ones.

 

Which is all of them, although my,

 

Oh yeah, of course.

 

uh, I still have friends ask me when I'm going to start telling good ones. Um, so, you know, my dad was a big financial planner and advisor for a long time and, and, you know, he had talked in one of the books I've heard talked about frequently by people in that, uh, area is called like the millionaire mind. I think there's a guy that wrote the millionaire mind and there's another followup to that talks to just about. how people who are successful, how they think. And so, you know, after reading that book, I went and I talked to seven different billionaires and I said, what's the secret to your success? And they all said the same thing to me. How did you get into my mansion?

 

So the audience didn't laugh, does that mean that wasn't a good one?

 

Oh, sorry. Sorry, sorry.

 

Okay, there it is.

 

Sometimes I have them muted and I have to remember to unmute

 

Of

 

them.

 

course, they're laughing consistently the entire show.

 

They're laughing with me, not at me. And then, um, finally the other day on a more personal note, I bought some, uh, I was at the store and I thought, uh, actually you take that back. Not the other day, considering I haven't had hair for many years. Uh, one time I bought some, I was looking for some shampoo and I bought some coconut shampoo. But then when I got home, I realized I don't even have a coconut. So. Thank you, thank you. Those are my dad jokes of the week. Oh, before I forget, you know, I really truly write all my own jokes really. But there's this great Instagram page and it's another dad joker and it's called 789dadjokes. But it's a guy, it's a dad and he's so funny. He's always taking video selfies of himself as he tells the jokes and a lot of times his kids are there groaning, you know. Within the past couple days, he started adding rim shots to his jokes afterwards, and I was like, yes, that's so good, and I even commented and said, hey, I love the rim shots. So 789dadjokes on Instagram, it's really great. So with that, Fred, it's your turn. What do you have for us for picks?

 

Um, we were talking about before the show started. I don't really have any like hobbies. I am a new parent and Build an astro. Those are my two things. So my picks are very much fallen in one of those camps, but um Just a plug for Svelte Summit is coming up tomorrow, I believe. I don't know when this is going out, but September 8th and 9th is this great Svelte Summit conference happening in Stockholm this year. And I believe, I have no insider information back this up, but I believe they're getting ready to announce Svelte Kit 1.0 release candidate. And if anyone's been following Rich Harris and the Svelte team, they've been... Literally every day is another change, another change, another change. Some of them breaking, some of them are just really cool to see. So they're clearly moving quick to get to that date. I'm super excited to see what they launch. Looks very great. And yeah, always a team that we like to support. Some of the Vue team. Everything that the cool that they launch, we get to take advantage of. So it's a win-win for us. I'm very excited to see what they announce tomorrow, September 8th.

 

Speaking of that, that reminds me of another pic. There's also, from a view standpoint, it's not necessarily a view. There's VITCOMP coming up. And I'm scrolling

 

I'm gonna be there.

 

through the list, and look, there's Fred K. Schott from the Astro

 

I'm going to

 

Technology

 

be there,

 

Company.

 

Nate's going to be there, so

 

Yep.

 

we're going to have a summit to go over your issue together when we're there, your image

 

Oh,

 

GitHub issue.

 

yeah, there's a number of people there at VeeComp that we have had here on the podcast and that I know, Eric Simons from StackBlitz. We got Debbie O'Brien will be there. There's a ton of speakers. Mishko Hevery that we've had on JavaScript, Javver, Daniel Rowe from the next core team. And yeah, just a whole ton of Guillaume Chow is going to be there speaking. So yeah, I watched a video with Nate. There's a... Are you aware of the YouTube video that, and I forget the name of the podcast, that he's on there building an Astor site with Prismic?

 

Yes, it might have been Ben, I can't remember if it was Ben or Nate, but yeah, Prismac is a very cool project.

 

Oh

 

Okay.

 

no, it's definitely with Nate. I recognize Nate from the... He's got a great haircut like me with a big red beard and glasses too, things I don't have. But yeah, that's how I learned a lot about... That's where I used as my template for building my view site, my Astro site, excuse me, with Prismic. So I'll find

 

I got

 

that video

 

it.

 

and put it in the show notes. It's really, it's like a two-hour thing where they just go along and build it as they go. But V comp, now when is V comp? I cannot remember the dates.

 

feedconf as I stall while I look it up because I should know this off the top of my head October 11th and 12th.

 

Right, meetconf.org is the website for that.

 

Yeah, I'm going to be there. A bunch of Astro maintainers are going to be there. So very excited. That's going to, that's like, that is a brain trust of cool projects that are going to thank God, I think it's all remote. So no one, there's no bus factor to worry about in case anything happens.

 

the

 

Um, it's a really cool speaker lineup. I'm super excited about it.

 

Yeah, that looks, I mean, the, looking at that list of speakers, it's pretty amazing. A lot of the heavy hitters, uh, in various communities for sure. Alrighty. So with that, we will wrap it all up. Uh, thank you so much for coming on Fred. I've heard you on other podcasts and said, I got to talk to that guy. So,

 

Oh, thank

 

uh,

 

you for having me. It's been a lot of fun.

 

yes, it's been a lot of fun to get into the nitty gritty as we say. So without, we will wrap it up. Thank you all for listening to views on view, and we will talk at you next time.