510: Fred Schott on the Past, Present, and Future of Astro
Regular listeners will know Chris has been big on Astro for a while now, so it was a treat to have one of the co-creators of Astro, Fred Schott, on to answer all our questions about Astro.
Time Jump Links
- 00:42 Guest introduction
- 02:28 What happened to Snowpack?
- 05:28 Skypack though?
- 06:30 What was day one of Astro like?
- 12:37 Is Astro Jamstack?
- 20:40 HTML forward
- 24:50 Sponsor: Memberful
- 26:12 Adapters can stop static site generation
- 33:32 Content vs dynamic interactive side
- 35:03 What are the limitations of Astro?
- 38:24 How are people migrating to Astro?
- 45:24 HTML Imports
- 48:18 Is there a no bundle future?
- 53:17 What other issues are there after compression?
- 55:01 The importance of a version 1.0
- 58:22 Theming ideas for Astro
Transcript
[Banjo music]
MANTRA: Just Build Websites!
Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I'm Dave -- in the shed -- Rupert and with me is Chris -- in the booth -- Coyier. Hey, Chris. Where are we blasting off today?
Chris Coyier: [Laughter] To outer space, man!
Dave: Yeah.
Chris: The official theme of technology products. No, we have a guest on today. it's been a while since we've had a guest. The guest is Fred K. Schott. How ya doin', Fred?
Fred Schott: Wait. Is Astro not the first project to use the space theme?
Chris: I guess it's not. I think it was actually--
Fred: Oh, no!
Chris: Was it Gatsby, or no? I think it's Apollo was the first one.
Fred: Oh, yeah.
Dave: Yeah.
Chris: Just kidding... [Laughter] It's cool, though. You all do it with great taste, and it's a cool product.
If you are a superfan of ShopTalk Show and follow us on YouTube as well, we did a little video on Astro because I now have two production sites in it. They're quote, unquote production. They're little baby sites that I worked on myself that is mostly just content, and I could have used anything.
But I didn't use anything. I used Astro because I like the DX of Astro in a big way, and I think it's probably my personal favorite new site-building tool. It'll be hard to unseat Astro. It's so, so good. I wish I had bigger projects in it and worked in it all day because it's really a pleasure to use.
Fred, you are the captain of Astro, yeah?
[Laughter]
Chris: The CEO, as it were.
Fred: I'm one of many contributors, but I am the CEO of the company we formed a couple of months ago to help support the long-term sustainability of this project.
Chris: Right. Astro existed before this company did, right?
Fred: We go back a couple of years, actually - if you go all the way back. You've been, I think, following the story since early days when we were Pika and then Skypack. It's been a long story to get to this place.
Chris: Yes. I guess that's the first time I became aware of you - or whatever - was I think I knew about Snowpack, but probably was a little confused by it because it was weird. It's not so weird now, thinking back on it. You were just ahead of the curve a little bit. I guess kind of a Webpack competitor but slightly different and really approached things in a different way.
I don't know what the status of that is. Maybe you could give us a two-second thing. Is it all but done?
Fred: We were a very explicit competitor to Webpack. I think our launch post was, like, "You don't need Webpack anymore." In 2019 -- it's funny looking back -- that was very controversial. We might have ended the title with a question mark, so maybe not as explicit, but do you need Webpack anymore? That was what we were exploring. At the time, that was weirdly radical. We got so many hate comments, like, "Of course, you need Webpack. That's the only way Web development has ever worked. [Laughter]
Dave: You were maybe just two years and one pandemic too early.
[Laughter]
Chris: But it's proving that people are moving away from it now. I don't know what slice Snowpack stole from Webpack. My guess is probably not much. Not like what Vite is doing now.
Fred: Yeah. I was going to say, if you're not familiar with Snowpack, we were doing what Vite was doing, and Vite just did it way better.
Dave: Mm-hmm.
Chris: Mm-hmm.
Fred: I think, looking back, an analogy will probably be if anyone remembers Browserify versus Webpack.
Chris: Mm-hmm.
Fred: Two similar projects. Webpack just took off. Browserify never really went anywhere.
I'll humbly admit that we were the Browserify of the story. Vite has done an awesome job running that project.
Chris: Right, so probably don't pick up Snowpack today. Just go to Vite.
Fred: Yes. We have officially -- I mean all the core maintainers have moved over to Astro. It's not fully archived. We're kind of looking if someone will want to take it over long-term, but at this point, yeah, Vite just came superior at a faster and faster clip.
Dave: Part of that is the esbuild underpinnings, right? You were pre-esbuild, I feel like.
Fred: Yeah. the whole story goes back to, I was at Google. This must have been 2015, 2016, and lucky enough to be working on the Chrome team with the Polymer team, actually, the Web components team. That was right when ESM, that import/export syntax was coming into the mainstream. Chrome had just shipped the first version. No other browser supported it, but, like, "Oh, this is happening." Developers were already writing it and then relying on build tools to do it and process it.
That was probably actually the bigger shift. I think esbuild -- totally, our whole performance story was built on esbuild being 100x faster than Babel. But it was really the fact that you could -- and what Vite does today -- ship your code to the browser during development without bundling it.
Chris: Right.
Fred: Essentially, just removing a whole chunk of work. So, any time you waited for Webpack to start up, like your dev server, if that ever takes more than a second, it could be so much better.
Dave: Hey. Well, don't speak in past tense. Some of us are still in that world.
[laughter]
Chris: Yeah. Come on, man.
Fred: I know. I know. Dude, join us in space. It's great. [Laughter]
Dave: Oh, yeah.
Chris: Yeah.
Dave: In space, you don't wait on development servers? That's interesting.
Fred: Vite has come a long way. Their Create Vite app kind of story is getting a lot better. Really, our biggest problem was always the ecosystems behind. The big problem was packages in NPM were CommonJS, so we had to do the work to migrate those to ESM.
Dave: Mm-hmm.
Chris: ESM has followed you around as a story because then there was Snowpack, but there's Skypack as well, which-- [laughter]
Fred: Yeah.
Chris: --I very much hope doesn't go anywhere because that's a very useful product, particularly for CodePen, now and going forward, which is this kind of tool that's all of NPM, a little bit like -- what's Michael Jackson's one? It's not CDN JS.
Fred: Unpackage.
Chris: Unpackage. A little bit like that, but Unpackage had this experimental support for making packages ESM ready.
Dave: Modules. Yeah.
Chris: I think it's still in that state. They never really got -- or Skypack took that and ran with it. Skypack makes everything on NPM ESM ready. I mean aside from packages that don't build or whatever. But for the most part, even stuff like React, which famously doesn't ship with an ESM-ready version of itself. So, super, super cool and useful. That's part of the ESM story - or whatever.
Then Astro came out of nowhere for me. It must have been just like, [laughter] -- I don't know. We don't have to dwell on that because it'd be interesting. This is a big week for you all. You're doing launch week, Astro hit 1.0, and there's lots of exciting stuff that I want to get to.
But let's finish the past first. What was day one like of Astro?
Fred: I'll say we hit 1.0 beta, so the 1.0 is still coming in June.
Chris: Beta.
Fred: It's still a huge milestone for us, given where we've been from.
Yeah, so that goes all the way back to the Pika days, which Google had been like, "Oh, this ESM thing is going to change everything," and there's going to be a lot of work to do with every tool. Going all the way down your stack has some new change. The existing set, like Web packages, they've had a lot of trouble moving. They've built their entire methodology on CommonJS and single-file bundles.
Chris: Mm-hmm.
Fred: It was this idea of a leapfrog happening for the entire industry and there's going to be a lot of work to do. How can we best help with that, fit into that? Just as an open-source maintainer for almost a decade, I was like, "I want to be the guy who maintains... I want to be that... I want to be the Rich Harris of my decade." [Laughter] All eco-driven, all completely eco-driven.
Chris: [Laughter]
Fred: ESM was the story that kind of connected all of this, so Astro was really, I think, us realizing that, yeah, the Skypack CDN is still an idea we love. We still maintain it. It's still growing, but there was a performance story that we were trying to explore that I don't think panned out for production sites, which was, if every site that uses Skypack is sharing the same version of React, then the browser is smart enough to catch that across sites. Instead of having a thousand different versions of React in your browser cache as you travel across the Web, you have one that multiplies across the entire ecosystem and, all of a sudden, Skypack sites would load 90% faster. That's kind of what we were targeting.
Chris: Right.
Fred: It's been a tough story.
Chris: It died because, yeah, browsers said, "Oh, no. Sorry. We don't cache that way anymore"?
Fred: Yeah. They all started double keying the cache saying that the idea that a site could see what was in your cache was basically a fingerprinting vulnerability, which I think is a little bit of a naive take on it. There are things you can do, but I don't disagree. Apple has pushed everyone to think more about privacy, and I think that's an inevitable result is let's get the fast solution out first. No one is really using this that much anyway. That we missed. We were too late to, almost. I think, a couple of years earlier, we could have maybe told that story. But at that point, no one was using it. It was an easy thing for them to cut, and I don't fault anyone for it.
Chris: Wow. Funny. You're constantly -- you're either too late or too early on your things. You threw two darts: one too late, one too early.
Fred: [Laughter] Such is life. Such is life.
Chris: Got some investment - or whatever - and kind of formalized the Astro company. Is that what it's called? Now can do this. This one really has struck, struck a nerve.
Fred: Yes. That was the big -- so, the end of the story is just -- we kind of didn't know what to do with Skypack, and the flexibility and pluggability of it was both its superpower and also just the fact that it was really hard for us to tell a story that was compelling. We just didn't really own enough of your stack to do that.
Astro was a chance for, well, we actually do want to be more opinionated. Everywhere where we get stuck is when we're trying to be less opinionated or more pluggable, so we just went full, like, we're Web developers. We have thoughts about Web development. Let's take some opinions and build what we'd want to see kind of full, top to bottom, in a Web tool.
Chris: I kind of think of it as -- or at least maybe the term "meta-framework" has come out a little bit in the way of how React is the framework but Next is the meta-framework.
Fred: Yes.
Chris: Or Vue is the framework and Nuxt is the meta-framework. In the case of Astro, there's not really as clear of a connection of that, except for that Astro is more Next or Nuxt-like than it is like React, clearly, especially because the output of Astro is you've really tried to be clear with your messaging that it produces JavaScript-free sites. Clearly, you can write JavaScript as well. But by default, JavaScript gets stripped away.
But you're still kind of authoring in a JavaScript-like way. That's what's compelling to me. Sorry to jump around too much, but I think of Astro as slightly like a meta-framework and that you get the advantages of building a site in a JavaScript-like way, meaning that you get to build in components, and these components can fetch their own data. These components can call other components. That to me feels like the correct, modern way to build any kind of website. That's what Astro does, but I don't know how big of a deal this is to the world. It seems like a big deal to me. Although, let's see how it plays out in the future.
The fact that Astro -- you can bring your React components. You can bring your Svelte components. You can bring your Vue components to the Astro party. Right?
Fred: Yeah. My hot take on all of this is just that that's not that radical if you talk to anyone who doesn't live in the super modern JavaScript like Next.js world of, "I choose React and everything is React." Talking to WordPress developers, it's like, "Yeah. I add a framework to my front-end. How else would I do it?"
We actually borrow a lot more, I think, from the Hugo and Jekyll and 11ty where I think the reason we never use the term "meta-framework" is site builder is more what you would call those. It's like meta-framework came up because it sounded cooler and site builder sounds lame and boring.
Chris: Hmm.
Fred: But yeah, it's the thing that helps you build the foundation of your site that everything else kind of stems from.
Chris: Right, foundational. Meaning routes, even, like, "What are the URLs?"
Fred: Yeah. The very quick pitch of what we're trying to do conceptually is, can we bring--? SPAs have had a decade of maturity. Next.js is great software. But the static site story has really just been a lot of old technology hanging around and just hasn't seen the same investment.
It would be impossible for there not to have been a cool story for them to have taken over the last ten years. If the SPA story is in its later innings, I think the multipage app story is kind of just kicking off. There's a ton of investment to do here. I think we're just getting started to see what's possible.
I think React server components and a bunch of other new technologies are showing that betting on the server is not a bad idea. Maybe going full client was not the right path to have taken over the last decade. There are clearly limitations to that that we're seeing now.
Chris: Okay. Interesting. We should spend time there because that seems like a pretty big, meaty thing.
The Astro that I got to know over the last couple of years was like it makes a ball of static files and then that opens the door to shipping that thing on this whole new generation of Web hosts like - whatever - Netlify, Cloudflare pages, DigitalOcean's app platform - or whatever. Even though they all have differences and they all support different things, anywhere that you can host a ball of static files, you can host what Astro spits out, which is fantastic.
You get to be in the Netlify party and enjoy all the DX that they give you, too. I get all the DX from Astro and another pile of DX from Netlify.
Fred: [Laughter] Yeah.
Chris: And I'm living large.
Fred: It's the best. Yeah.
Chris: It really is great, but it also is like, okay. The sites that you can build that are entirely a ball of static files -- like the ones I have in production -- they are nothing fancy. It's just some content on a page, just a brochure site as it were.
That's some slice of the Web, but not super-duper big because it's now starting to mean -- this is just me talking here -- that that Jamstack word that Netlify invented that seemed to have a lot of traction, I feel like Astro is part of that because it just is. But Jamstack is starting to mean, to me, not just static. It means there's something dynamic going on also. I don't know what the word is for the ones that are absolutely just static only but, to me, Jamstack almost means, "Oh, there's at least a little bit of dynamic something going on." Author. It grabs the content from somewhere. It does something.
Their answer to that, generally, industry-wide, has been, "Well, Lambdas then, or little baby cloud functions to do something. Use those." That's been pretty neat, but maybe they don't all have to be Lambdas. Maybe the time has come to just rely on servers a little bit more.
I guess that was a part of your launch week. On Tuesday, the announcement was Astro can support SSR (server-side rendering) meaning that if there's a server available, those Astro components can take advantage of that server and generate from that. Right?
Fred: Yeah. I have so many thoughts on this. Probably more than we can get into here.
I actually gave a talk -- a very sleep-deprived, rambling talk, but a talk -- on what is Jamstack. I was asked to do the Jam.dev, I think it was, and close out. I was going to do this whole thing, and it was going to be a sales pitch on Astro.
As I was trying to -- like, okay, let me make sure I'm understanding Jamstack. I get the J, the A, and the M, but let me double-check that Astro is Jamstack. [Laughter]
You go to any definitive, like, "What is Jamstack?" website, I think there's jamstack.wtf, maybe?
Chris: [Laughter]
Fred: There's a bunch of them.
Chris: Uh-huh.
Fred: All over them, over the last couple of years, have been like, "So, we don't really know what Jamstack is anymore. A lot of people are claiming they're Jamstack, and I don't know." The definitive sites are just kind of like, "I don't know. You tell us."
I don't know if Jamstack is really in a definitive place. Yeah.
Chris: It's not, really. That's why I think -- yeah. Yeah. That's why it's nice for the people to take it and start having an opinion about what it is.
Fred: Viva la revolucion day of Jamstack.
Chris: Yeah.
[Laughter]
Fred: Brian Rindaldi said it a lot better than me. His blog post is actually -- like, save some time and just read that because he kind of concisely boiled it down to, like, "What is going on, and do we feel comfortable just saying that 'you know what. Jamstack is a cool idea, but it doesn't have to be a purist take,' because what you end up with is just pushing way more work than you should to the client in some key circumstance."
A marketing site, yeah, that can be totally static. An e-commerce site, now the client is checking before they can show anything, "Are these shoes in stock?" Or if we're requesting data fully on the client, that's not a great experience either.
Chris: Mm-hmm.
Fred: I think we're past the point where Jamstack purity makes sense for all use cases. I think the nuance is starting to have to come into the picture because otherwise, you're just pitching something that doesn't scale to large sites. If you can't scale, it's not a good methodology. You're just hurting your users when they get to that stage.
Chris: If we try to focus in on one thing, let's say all it does is need to--
There's no auth. Although, the auth thing is interesting, and I think we can get to that. But it's just like, you load a page and this particular website has 20,000 pages. So, there are very few static site generators that are putting up good numbers for 20,000 pages.
Fred: That's pretty brutal.
Chris: Yeah, it's a little brutal, and maybe that'll improve, but it's also weird. It just feels weird, like a waste of electricity or something to type an exclamation point and watch your whole site rebuild.
Fred: [Laughter]
Chris: I know there's incremental rebuilding and stuff that can help, but it's like, ew. You know? Then you push it and you break cache on 20,000 pages, too.
Fred: Yeah. No. No.
Chris: It's just one of these, "Meh, I don't like it." So, maybe WordPress had it right, you know. [Laughter] Not really, but whatever. That's a loaded statement to make.
Fred: [Laughter] Moving back. Just stepping away from the camera.
Dave: Yeah. Yeah.
Chris: Why can't a fricken' blog post yank its content or be dynamically generated from a server and just spit itself out, and that requires no fancy dancing, and wherever that data lives is irrelevant, in a way? It could come from Contentful or it could come from some key-value store sitting somewhere. Whatever. Who cares? Just request it quick. Slap it in a template and serve it like it's SSR.
That, to me, is a little obvious. It's so cool to see that Tuesday announcement be like, "Dude, an Astro page." You already are kind of doing that. You have these fences at the top of an Astro file, three little dashes. You write code up there that's JavaScript, but server-side JavaScript.
For now, I spent all these years thinking, "Oh, it's JavaScript that runs during the build." It was a very easy mental leap to understand that that's what Astro is doing. If you console.log something up there in an Astro file, you better go look in your terminal, not the browser, because it's a different place that you're going to see that output. That was a little bit of a mental shift, but I think people made it, they get it, and they actually kind of like it. I do.
But now you're saying it doesn't have to run during the build. It can run whenever. It can run on a server, and it requires no mental leap to get there. You're like, "Oh, yeah. I get it." [Laughter] Cool.
Fred: Yeah, it's very clearly been on our minds since the early days. We've been a static site generator for--
Chris: I didn't see it, though. You saw it. I was like, "Oh!"
Fred: We were hopeful, like, "Oh, wouldn't it be cool?" We just always had it in mind, and there was a bunch of refactor over the last three months when we knew we wanted to go this route. There were some pains along the way to get here, but now it just maps so nice.
Yeah. The most controversial thing that Astro does is pitch its own component syntax, which we understand that's controversial, or just a big lift, but we tried to make it familiar to anyone. So, if you've used Svelte or Vue, it feels a lot like that with a set of script being the code fence. If you've used React or Preact--
Chris: Yeah. You've got to do something.
Fred: --it's the code that runs before the JSX, and then the template is the JSX. But we really try and be much more HTML focused than JSX, which I know is a pretty small distinction, but I think it comes out in a lot of interesting ways when you start to actually use--
You can use an HTML comment in your template. It's HTML more than it is JavaScript.
Dave: Yeah, the HTML forwardness, I think, was the thing that lit up my eyes just because you're like, "Oh, that's just HTML. I just write that. Then I can sprinkle in some scripts at the top." I thought that was cool.
Back to the aging JavaScript frameworks or meta frameworks, all the SSG stuff, the server-side generating stuff, a lot of those frameworks, that was sort of bolted on. It was sort of like, "Oh, yeah, yeah. We can do that, totally. Yeah."
Chris: [Laughter]
Dave: Somebody who doesn't actually know how to do it but will just fake it until they make it. [Laughter] They're like, "Yeah. Yeah. We do. We totally do that."
I think your Astro, the way it came out, was just very much like, "Oh, we kind of are only server-side generation. But now this cool SSR--" and it's taking my brain--
Chris and I were talking about it before the show. It's taking my brain a bit to grasp the SSG and SSR, the differences there.
Chris: Yeah. Doesn't SSR--? If you're doing the Venn diagram thing, SSR encompasses SSG, to me. But it's almost like the industry has almost decided to split them instead and be like, "No, no, no, no. Let's just think of them as two different things."
Fred: The galaxy brain take is that they're exactly the same. It's just a question of when that build runs and what you consider caching. "Build ahead of time, and then deploy that," is not that different from "Build immediately after deployment and cache it." If you have a CDN, which Netlify, Vercel, and all the big players kind of give you now for free, that question becomes -- at least at a technical level -- way more muddled.
Dave: Before runtime, after runtime, or on-demand.
Fred: Yeah.
Dave: Pre-demand, on-demand.
Fred: But imagine a world where you deployed your site and then hit every route before any user ever got to it and warmed the cache. That's essentially the same exact user experience.
Dave: Yeah.
Fred: That's simplifying a very complicated topic, but it kind of shows how much it can be simplified now with the CDN prevalence.
Dave: We ended up doing that. We were building a Nuxt site for a client, and we thought -- they were like, "Oh, it's only 12 pages."
We were like, "Sure, this is great."
"Or 600."
"Oh, okay. That's fine. We have 600 posts."
Uh, no, no. It was in the order of like 20,000 because they had all these little quotes collected. We were just like, "Ah, that's--" and so we had 45-minute build times.
Fred: Oh, no.
Chris: Oh!
Dave: It was a Nuxt site, and it was just like, "Well, this isn't going to work because our S3 build is through the roof." And so, we ended up just using a server instead.
I did sort of the same thing on an app I'm working on now. I backed out of the full Jamstack serverless functions only, client-side only, and I've gone to the more, like, "Hey, having a server is kind of cool [laughter] because stuff happens on the server. Secrets don't leak. It's great."
Secrets stay secret, I think I heard Remix say the other day. That's just great. It has me longing for more of these flavors of using JavaScript, using modern tech in kind of a server side way.
Fred: Yeah, I'd say the big, our big take on that is if we're talking about Jamstack. I think we are probably the best case, like the best version of a non-purist on Jamstack where our default is still static site. So, you spin up your starter Astro. It's going to be a static site generator. When you're ready for it, add the adapter for your host of choice. It's like a one-line add. Then you now have a fully server-rendered site. It's only more features unlocked, so it's really not a breaking change for you to make the move.
Chris: Hmm.
Fred: It's harder to go backward; but to make the move forward, it only unlocks new features. It's a pretty undisruptive change based on what we've seen.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you in part by Memberful. Memberful is software to help you sell memberships to your audience.
What would your business be like? Do you need to build this? This is an awesome way to build a business.
But Memberful is for you, the developer, to build this. This is a whole package of tools to make building whatever kind of membership business you want to build possible. It handles all the hard stuff. It'll take payments with Stripe for secure payments. You don't want to write that from scratch. Use Memberful to help with it.
There's a full-on GraphQL API. Which user is it? What access level do they have? All that type of stuff, Web hooks, OAuth, single sign-on.
You're going to have to build a login process and account creation process. Why write all that from scratch? It's just built into Memberful, this complete package for dealing with membership stuff. It's so great.
Let's say the home base of your website is WordPress. There's a best-in-class WordPress plugin so that you can control who is able to see what and where the upsells are and all that stuff. Really tremendous. It handles all those transactional emails - so much of that.
It's just everything all bundled together. You can get started for free. There's no credit card required. Just think about it. If you're a smart developer, you're not writing all this stuff from scratch. You're leveraging other software that does what it does best so that you can build the integration of a membership website perfectly. Thanks for the support, Memberful.
[Banjo music stops]
Chris: I didn't realize that's how it works. If I have a totally static site and all I do is add an adapter, it will stop statically site generating?
Fred: Yeah, for now. I think we still want some idea of a per-page basis. But right now, it's all or nothing.
Chris: It's all or nothing. Okay. Interesting.
Dave: Well, and that's probably tricky because it changes per platform, right? Like the way AWS or whoever -- Amplify and Netlify do ISR different.
Fred: Yeah, exactly.
Chris: Yeah, these adapters can be no joke. They must be very complicated. Aren't they?
Fred: One thing that helps, though, I mean we support everything from a Node server running an instance all the way to an edge function, like an edge worker. We kind of run the gamut.
It's easier than you think to do all that because you just kind of target the most restrictive and then work backward.
Dave: Which is almost surely a Cloudflare worker, right?
Fred: Yeah. Oh, my God. There are size limits. There's every sort of limit imposed on that. But getting it all into one JS file with no dependencies is just something that we'll always run on Node as well.
Chris: Hmm.
Fred: That was probably the hardest thing, but that's our output now, so everything else can kind of flow from there. It's still a ton of work. Matthew Phillips (on our team) has been just working hard at this for months now, but it's really paying off.
Chris: Yeah, it's so cool because the paradigm is even different, too. On Netlify, all they give you is little Lambda things, right? Do you combine them into one?
Fred: Yeah. I think it becomes our router. It becomes the SPA in the cloud where it just takes your routes and responds to them using our server that's been built.
Chris: That's great. It's like one more step because when Lambdas first came out, it was kind of like, "Okay. I'm going to have a repo that's just my Lambdas, and I'm going to manage. I'm going to figure out how to deploy them and stuff."
Serverless.com came along and tried to help you deploy them and stuff. You thought of them as little, like, "I am going to take advantage of these infinitely scaling little bits of stuff."
Then Netlify comes around, and it's like, "Don't worry about it. We'll deploy them for you." They're still Lambdas, but you've still got to put them in a special folder, and you've got to give them a special name, and you've got to invoke them at this special route, so you're still thinking, like, "What code of mine will become a Lambda?"
With this, it's like you're not thinking about that. You just write the JavaScript at the top of the component and the framework figures out where and how it's going to run.
Fred: I can't take credit for this. SvelteKit, I think, was probably the first to do this and Remix, I think, followed. It's a really nice model. If we're moving to post Node.js dominant world, it's a really nice model to follow where you can move that complexity into a layer that we get to maintain. We can bring in these hosting partners to help us out maintaining them. It's a lot better than every user having to set this up themselves.
Chris: What do you mean by post-Node? Does it mean that the code that you write could be deployed to a deno thing or something? Yeah?
Fred: Yeah. Similar to Remix, I think we tell a similar story around, like, it's all Web standards. The nice thing about this moment -- again, early to some things, late to others, but the moment we find ourselves in is every framework is taking standards seriously exactly for this reason. We can now wrap Astro in, like, here's a standard request object, a standard response object, and actually, it's on you, the platform, to provide that to us.
And so, that lets us put a lot of that standardization work on them. Cloudflare has, I think, a whole team at this point to come closer to standards ... started with that idea, so that's an industry trend that we've been able to actually hook onto and kind of bet on. It means less work for us.
The world of Express.js having its own request and response object is kind of fading away.
Chris: Interesting.
Dave: Cool. Wow.
Fred: You all mentioned one thing that I would love to go back to because I think it's kind of the key to unlocking all this, or it has been in my head, which is, you talked about the component syntax being kind of hard to grasp. But when you get it, it makes sense.
The big thing that I think our big bet, our big take on this is that if you look at all of the frameworks in that space where it's Next.js took React, SvelteKit took Svelte, Nuxt took Vue -- am I missing any?
Chris: I don't know.
Fred: Everyone took React, if you look at Blitz and Gatsby. But that is retrofitting a client-side API that was designed for client-side UI and interaction and reactivity down to the server, which is an easier environment. It kind of maps easy enough. But now you're thinking in a UI and thinking in a language that was originally designed for the client.
You get a nice win with it's one language, but you're paying this cost of, like, if you've looked at how SvelteKit or Next.js work, everything is at a function. You're living in a JavaScript world. You have to think about rendering. You have to think about your get server-side props.
Chris: Mm-hmm.
Fred: With SvelteKit, you've got this -- what if I export something? You have this whole language that's designed for reactivity that you are now running in a server where there is no reactivity. It's just unnecessary overhead in the language.
That's the big mental shift that Astro introduces, which is, "If you could design a language from scratch for the server, it would be 90%, dramatically simpler than every other UI front-end framework exists today because you don't need to worry about reactivity. You're never re-rendering a second time. You're just running the code in the front matter.
You're making a database call directly in it. You don't have to fake this API that's only for your framework's requirement. You can make these database calls directly and just render the page. It's all linear. You throw a top-level.... You throw a fetch. It's all just happening in one really flat, linear way.
That's the model that just kind of clicked once we saw, "Oh, that's what's special here." I'm not even sure if we knew that that's what we were getting at, but "Oh, that is just 90% simpler."
Chris: You probably knew a little bit because there are Astro specific fetch calls. Don't you have, like, "That's what you're supposed to use is astro.fetch content," and stuff like that?
Fred: Yeah. Actually, that was one of the big breaking changes we made right before. It's like astro.glob. Now it's centrally styled perf for globbing files. Yeah, there's definitely some sugar worth throwing in there, like just throwing the weight on that. You're going to get back all the Markdown files in a folder and create a table of contents, create an index. You can do whatever you want.
Chris: I'm glad that exists because I've tried to -- this is not a dig. This is more a dig at my own intelligence, but I was going to build one of the sites I have on Astro. I tried to do it in SvelteKit first just because my point wasn't, "Let's get the site done." My point was, "Let's learn about technology. I have a technology show. I should probably have a little experience with different technologies."
There didn't seem to be a little helper like that because I think that's a type of site. There's a whole swath of sites in the world where my content is in Markdown files and I need to get my hands on it to build out the site, to template it out. It seems like there should be very direct helpers for that kind of thing in frameworks. In Astro, it was one of the first APIs documented. It was like, "Oh, thanks. That's just what I need."
Fred: I don't know why every other framework is so afraid to just be like, "Here is what we're good at and here's what we're not." That's our whole thing. If you're building--
I'm trying to find a way to get this idea out there without sounding like I'm--
I'm not trying to speak for other frameworks, but if you're building something that's on the content side versus the interactive dynamic side, like if you're building a dashboard or a Web portal that users sign into, it's all data flowing around, and really stateful and heady in JavaScript, like you need that JavaScript, don't use Astro. Just don't use it. [Laughter] You're probably going to have a bad time. Maybe one day, but not any time soon.
I wish more frameworks were just upfront about that. Maybe it's because they actually want to be everything to everyone, but it's one of our favorite parts about Astro is that by focusing on this, like, "Yeah, Markdown glob helper was a no-brainer. Integrated site map generator--"
Chris: Hmm. Content-based sites are a little more palatable for Astro land.
Fred: Yeah. Anything, I'd say, from really static marketing site to blog (even if it has a bunch of data). We're going to do really well. All the way up now with SSR to e-commerce. I'd say that's kind of where we draw the line. If you're going to start building a Facebook or Figma, probably don't use Astro.
Chris: Yeah.
Fred: But everything before that, the performance story is killer because you probably care about first page load. The ease of development is killer if you're an agency working in this. You can just crank out an Astro page super easily. You can bring in the complexity where you want it versus the complexity of a UI framework being the only language you can speak.
Chris: That makes a lot of sense.
Dave: That's actually one of the questions I had. What are the limitations? I feel like people try to bucket what Astro can do, and I was curious how you felt about the limitations. Like e-commerce is sort of like you're getting towards the end of it, yeah, on the spectrum.
Fred: I think where people fall down on what your limitations are is you could build Figma in Astro. It'd be really weird, but you could do it. And I think people see that, and they say, "Oh, cool."
Why would I tell people not to use Astro then? That's a user that I'm saying goodbye to. But it's that classic; if you try to make everyone happy, you're going to make no one happy.
Dave: Mm-hmm.
Fred: I'd say that, yeah, anything where you start to -- if you imagine that as a spectrum between content-focused versus interaction-focused, we can kind of get to the middle, if e-commerce in the middle. [Laughter] I'm making my mental model very clear right now. There's a spectrum and e-commerce in the middle because it's kind of that perfect balance of there's content, but it's really dynamic content, and the user is trying to interact with that content. You're kind of right in between the two.
Dave: Mm-hmm.
Fred: That's where I'd say we start. That's as far as we want to go. If that's as far from the content side of things to the interactive side of things that we get, we're happy.
Chris: It makes sense to start pushing the Astro component syntax hard now, I think, because it's like, "Yeah, sure. You can bring your React component, but why?" Then you don't have the fences at the top, so you can't do the server-side stuff unless you inject some weird API. I'm assuming you're not going down that road.
Then also, people use React because I can put an unclick handler on my button, which will not work in Astro unless I tell it to do the client load - or whatever - use the syntax that tells Astro, "Actually, I do want JavaScript on this particular page."
Fred: Yeah.
Chris: Then the second you're doing that, you're pretty much just building a React site then. I know it's an island and maybe if you just had one or two of them, it's still the efficient way to go. But if you find yourself using React components and telling it to load on the client-side for all your components, that's probably not the world's greatest framework for you. You should probably use Next.
[Laughter]
Fred: Yeah, I think that's where we're in a unique place because we've acknowledged that limitation. We could be like, "Yeah. We love Next. It's really good at that other side of the spectrum that we're not trying to tackle."
The Hello, World blog is just going to pay a huge performance cost.
Chris: It will. Yeah.
Fred: But the super dynamic application is going to have all these cool features that are about building applications. I think it's maybe the more nuance take on, "Oh, are we building websites or Web apps? They are two different things."
Maybe it's a spectrum, but I do think there's truth to the best thing for a blog or a huge content, e-commerce site is probably not going to be the best thing for a Figma. I think we all need to probably acknowledge that as users.
Dave: I don't know, man. I feel like the app shell of Figma could mostly just be statically rendered.
Chris: [Laughter]
Fred: Yeah, and maybe I'm giving ourselves not enough credit. That's the joke of Astro. Anything can be an island, including your entire page. Just throw Figma as a single React component and go from there.
[Laughter]
Dave: Figma, capital F.
Fred: Just Figma.
Dave: Figma.
Chris: Yeah.
[Laughter]
Chris: With a closing slash.
Dave: User object, yeah.
[Laughter]
Dave: That's good. Okay. I have another question. People who are using Astro -- customers, we'll call them -- do you see a lot of people importing their whole React design system and then spitting out a static site based on that, or is it kind of more people are doing greenfield, blue sky stuff? I guess, in theory, you can just use your components, and I could just spit out a new static site. Is that how people are using it, or is it kind of working out different?
Fred: It's a little bit of both. Again, in our borrowing from all the frameworks we love, we do file-based routing. We do -- God, what else?
If you're building a static site, there's this very similar get static path. We've taken a lot of inspiration, so if you're coming from certain meta frameworks, you'll feel at home.
Dave: Mm-hmm.
Fred: I think we see definitely greenfield projects. I think what we see the most is people recreating their site in Astro, but very quickly describing every UI component that they can from the old code base.
Migrating a page from Next to Astro is possible, but it's more of, like, okay, you're changing the way you think of data loading and getting props. But that button component, that's a one-to-one map.
Chris: Yeah.
Fred: If you're migrating, just bring that into Astro, and it will almost certainly run in Astro on its own. That's a huge migration story.
Chris: It's not a small market, I don't think, because it's like, "Show me a content-focused framework that you build components in," because there's the PHP CMSs of the world are huge and dominant. You add them all together, and it's a huge swath of the Web. And none of them are component-based DX. That has won. Sorry. It's just better. It's just a better way to craft websites and digital products of any kind.
As much as I like SSR, I like a good CMS, I like the management of that, there's just so much I like about the WordPress and friends of the world. They don't have a component authoring story unless you are piecing crap together. I get it. There's probably production (WordPress as a CMS, Astro as a front-end) sites out there. I don't love that story. I think it's trying to fix something that isn't great.
I just think now that's going to be a shift that that happens. There's going to be this, like, "We should be building our content sites out of components, too, and maybe Astro is the way to do it."
I don't even know...
Fred: No, it's all part of that story where you spend so much time arguing about these really JavaScript things and then the rest of the world is still like, "Short codes are the move, right? Short codes won?"
Chris: [Laughter]
Fred: It's like, "Oh, no." Chris, I feel like your "Great Divide" article is still something I think about every day or reference back to. If you imagine--
Yeah. I was trying to use this analogy. If there is a chasm, we're trying to be that bridge of, "Come see all this cool stuff. There's a way to bring that into a model that still fits how you think of a WordPress, a PHP site, or a Rails site."
The pessimist take on Astro, if you squint really hard and look at our syntax, "Oh, you just built PHP." There's my code. There's my template. It's all mixed together.
As long as you don't say that in a tone that's like, "Okay. Come on. Be kind." [Laughter]
Chris: Mm-hmm.
Fred: We're proud of that. It's a model. PHP was awesome. You just called email in PHP and send an email. That's super cool. PHP was the best.
Chris: Right. But Astro isn't that weird of it. It's almost like PHP, but just put your PHP at the top. [Laughter]
Fred: Yeah, exactly.
Chris: And then the template at the bottom.
Fred: The structure, yeah. I'd say that was maybe if the whole industry, which I think I say this like it's a definitive thing. I think we're still figuring it out. The whole industry, the pendulum is shifting back to server work is good, actually, and we should probably do more of it because not every user is on a device that can handle all this JS.
If that's where we're going, then I think the mistake has been that "Oh, that means Laravel, Rails, these server languages can't be JavaScript." I think maybe that's where we find ourselves. Like, "Well, why couldn't Rails just be written in JavaScript and be more familiar?"
One of the coolest things about the universe lap is I'm a developer who knows JavaScript and HTML and I can build anything. That's a superpower. I think that audience, if we're going to move back to the server, why wouldn't they want a server focused language that they felt familiar and comfortable with versus having to go learn PHP or Ruby or....
Chris: Yeah. It's not about avoiding learning something, but it kind of is, especially if that lingo is fully capable and if it turns out that Deno gets popular too, it's also real secure, safe, and stuff, and it runs fast. There's all this cloud infrastructure running that can run it too.
It's like, "Dude, rock and roll." JavaScript ain't that bad.
Fred: Oh, yeah. I hope that comes across as love for JavaScript and not like, "Oh, I'm lazy. I hate learning." [Laughter] The NPM ecosystem is available to you. You can't say that in any other language. Yeah, there's just so much that you can gain from that consistent, universal story without shipping all the work to the client. That's where we find ourselves in.
Dave: Well, and you end up doing double work. I think people don't understand.
I'm doing an app. It's in Nuxt. I like Nuxt. I'm not throwing it under the bus, but it's just a page that lists out posts. Right?
Okay. I've got to go get the post from the database, but I can't have the machine that talks to the database inside the view in the client-side JavaScript, so I'm going to go--
Chris: Yeah. Where did it go?
Dave: I'm going to make another machine, a whole other middleware, that goes and talks to the thing. Now my thing talks to the middleware.
I'm just like, "Oh, man. If this was in Astro, I'd have half the file."
Chris: Yeah....
Dave: It would probably be simpler just because it would be less abstractions, less whatever. It'd just be like, "Go get...."
Chris: It's a responsibility thing. You need -- that particular component's responsibility is to do some posts, so write the code to get the posts in that component. It doesn't mean--
But you could also do it on any parent on the way up, too, right?
Dave: Mm-hmm.
Chris: Which is kind of cool. You can move the responsibility. But that's what I like about the styling too. That component also has a responsibility to look a certain way on the page. Guess where you write those styles. Right there in that component. That's just a good idea.
Fred: Yeah. We love that single file component idea. Yeah, it's like all these things, all these frameworks have such great ideas, but they're wrapped up in this more complicated than needs to be templating language. On the other side of things, you just have handlebars and Nunjucks. It's like, oh, that's its own set of cool things you can do, but limitations also. Yeah, we're trying to bridge that gap.
Dave: I was going to say the single file template, it reminds me. Long-time listeners of ShopTalk Show will know of HTML imports. A little bundle of HTML, CSS, JavaScript, all living together cohesively to build a page. [Loud exhale]
Fred: I was on the Palmer team. I'm deeply, deeply scarred and aware of. Yeah, HTML imports were a thing.
Dave: You're living the dream, I guess is what I want to say. It's going to take a while for everyone to catch back up.
Chris: I love that CSS was the OG there. Of the three main Web languages, JavaScript only just got away to import other JavaScript, really. HTML still doesn't. But CSS, baby, we've had add import for a hot long time.
Fred: Having been on the team, the snarky, like -- it actually makes a ton of sense -- every other language can import itself. HTML, the thing that is used to reference other things, is the only thing that now can't import itself. Why? That's fair. [Laughter] That's just fair.
Dave: I don't get it.
Chris: [Laughter]
Dave: It's a crime.
Chris: It is a crime.
Dave: [Laughter] Yes, HTML links the entire Web of content.
Chris: Mm-hmm.
Dave: The wealth of human knowledge in existence, in its entity, but it can't link to another file of its own type.
Chris: I've got a CSS-Tricks blog post with 18 ways of doing HTML includes because I definitely came up during this time of even making little brochure sites where one of the jobs was, "Hey, it's a five-page site, but it's got to have the same header and footer. The navigation is repeated on all the pages." That will never change on the Web.
Fred: [Laughter]
Dave: Mm-hmm.
Chris: Astro has its own way of solving that. You make a nav component, and you import it and use it. But frickin' every site on the Internet needs this, needs a way to import.
What do people do? I don't know. They make crazy decisions. They'll run PHP just because the language PHP has an include statement in it. Or they'll run an SSG kind of thing because Nunjucks has an include thing. Pug has-- Those are old languages, but they have that one thing that people need to do.
On CodePen, we have a way to do it that we just invented because it was like people obviously need to import stuff. In HTML in CodePen, you can write three angle brackets - not angle, the square ones.
Dave: Square brackets.
Chris: Square, square, square, and then you put the URL of another Pen, and then go square, square, square at the end. It'll suck the HTML of that other Pen and put it in place where you do that. We have our own little processor to do that just because it's such an obvious need.
Fred: CodePen powered by Astro when?
Chris: [Laughter]
Dave: Hey. Hey.
Chris: We almost need to go the other way around and start supporting Astro. Don't worry.
Fred: Nice.
Chris: It's a whole thing. I play with the alpha every day.
Fred: Nice.
Dave: Hey!
Fred: I love that.
Dave: I have a question. Given your experience in ESM, that lifestyle, do you think there's a no bundle future where we don't do bundles? We just ESM our life.
Fred: If HTML imports are your baggage that you carry, like that story is definitely mine. I still love it. I don't know. I think it's always going to be harder to do. I think, unless you have a really cool caching story, like we were trying to do with Skypack, you're always going to be competing with the fact that your network story is just a lot harder. I think you have to tell the caching story for that to make sense.
If you're a super dynamic site and users are moving around it, the more you break it down, the more high fidelity your cache is. The story we try and tell is that we actually try to cache by component on the page. The cool thing about island architecture is that you're no longer thinking, "Okay, here's all the JS for your page, and let's bundle it all together."
You're thinking, "Here are the three islands on this page, the components that need interactivity. Then here are the five on this page and the ten on that page." By treating those components as the entry point, we're now one level deeper.
Instead of having to do one big page that then has to copy/paste to share anything, you're either bringing it into that main bundle or you're splitting it out. That's just a little bit of a--
At the end of the day, bundling is just about the amount of copy/paste versus the amount of efficiency over the wire. I should say, duplicate code instead of copy/paste.
Dave: Wow. Yeah, yeah.
Fred: I think you have to tell that story. You have to have a site where, no, we care about the user's second request and the fact that when they make that second request, they already have X% of the JavaScript cached away from the first request.
Dave: And evaluated. Mm-hmm. Yeah.
Fred: An easy way to gamify Lighthouse is to just throw it all into a single JavaScript file that then on your second page you're loading an entirely different JavaScript file that has 90% duplicate code. Your Lighthouse scores are going to be great. your user experience is going to be terrible. Maybe we're missing the right tooling to tell that story. I don't know, but we don't seem to be there yet.
Dave: No, well, and then I think you get so many gains still from bundling. Minification, obviously, like just less requests. Maybe tree shaking, I can just get one part of one thing.
Chris: Let's assume less request just doesn't matter, right? If we're thinking of the future, is there a future where requests absolutely stop mattering?
Fred: Yes. The network has come a long way. We have H3 now, which is really good at--
No one has ever told me I'm wrong on this. This is my understanding. If someone is, please correct me on this. [Laughter]
Chris: [Laughter]
Fred: H3 is really cool because it actually parallelizes requests. If you think of -- who was that old senator? "The Internet is a series of tubes."
Chris: Al Gore?
Fred: If you think of your connection to the domain as a tube, H3 lets you spin up as many tubes as you want to parallel pull these things down. If one blocks, it's not actually blocking the other ones. It's really cool technology.
What ends up now being the problem is, well, you're not actually getting the compression benefits. Each of those is an induvial, so you're compressing them individually. That's always going to be less efficient than compressing them all as one artifact.
Chris: Hmm.
Fred: You have to somehow agree on a compression key ahead of time that they can all share. It's just not there yet.
Dave: You know it's interesting because the common rebuttal to, like, "I just want to use a JavaScript framework and not care about performance," is like, "Well, the user is willing to wait," or "It's an app. They're on long sessions, so it's great."
My brain this week, I just was like, "Well, if you don't care how long the user waits, [laughter] just serve ESM. Don't even bundle."
Fred: Yeah.
Dave: Maybe that's your play. Why are you doing all that work if you don't care if they don't care?
Chris: That's a good point. Yeah.
Dave: If they really don't care, why are you doing all that work?
Fred: If you open up the Facebook dev tools, there's a lot of individual requests to JavaScript going on as you're moving around the page. I wonder how close they are to that already in their obfuscated Facebook.
Dave: Just kind of like, "Hey, you moused over this. We're just going to go fetch the marketplace," or whatever.
Chris: Hmm.
Fred: Again, it just comes down to what are you optimizing for. Yeah, I think there's a compelling--
If you really care about the long session use case, there's a really compelling story to the "don't bundle it all" today. I think you should make that case.
Dave: Yeah. Interesting. Right? Yeah. It hit me today. I just was like, "If you don't care, then don't do it." [Laughter] Don't chase--
Chris: Yeah. There are a heck of a lot of people that say they don't care but still have this complicated ass Webpack setup.
Dave: Yeah. We're doing quadruple backflips just to get a frickin' page on the Internet.
Chris: Hmm.
Dave: You're like, "Don't."
Fred: Let's draw the line back from that to that original, like, you don't need Webpack anymore post where flame war of the century for me. [Laughter]
Dave: Yeah.
Fred: Just to give that idea (with a question mark) out there.
Dave: Yeah.
Fred: Now, five years later, we're having a very serious discussion on this podcast, well, "Maybe you don't need it at all. Not even a better tool - like any tool."
Chris: What are the other things? Compression is one of them. But the problem there is that you're worried about what goes over the pipes. If we're really being futuristic, can we imagine an Internet that's just so frickin' smokin' fast that who cares about that?
Fred: Compression is a big one, and I don't think there is any proposed solution to it, which is why it's kind of the big one. After that, though, the whole thing--
The other thing that's helped a lot is frameworks are starting to taking preload header seriously, which is the idea of, in a world of unbundled, or even just more unbundling, like smaller bundles, the problem then becomes, "Well, your browser gets the first file. It sees the imports. It gets the second file that was imported. It sees those imports."
That's a pretty piecemeal process. It has to evaluate, load, evaluate, load, versus one bundle all comes in at once and all evaluates at once. No more loads. Good to go.
We don't actually do this as well as we should, as well as we will by the V1 launch. But I know Vite, I think, maybe by default. A lot of these new frameworks are taking this really seriously where preload headers tell the browser (on the first page load), like, "Hey, we've already analyzed the page. We know what's going to come down the pipe. We know what that fits, that import is down that chain. We're just going to give you headers to load them all from scratch."
Now when we go to resolve it, they'll all be in memory, so preload headers are cool. That's doing a lot of the work there.
Chris: You mentioned 1.0 again. That is beta right now. Astro 1.0 beta is available. You said probably June for the--
Fred: This Monday, this previous Monday, it was announced, and the official V1 release date is June 8th.
Chris: June 8th.
Fred: We did a lot of work to get all the breaking changes in. We're really just in polish mode at this point. We're feeling confident.
Chris: You're making the good call that 1.0 is meaningful. 11ty went through that recently. I think they took a little longer to get there but, God bless them, they got it. In a way, it's marketing, right? But if you're honest about it, it's really good marketing because what you're saying is you can count on stability now. Is that what it's saying?
Fred: Not just to our users who I think of, at least up to this point, have had a lot of--
They've been really willing to work with us as we make breaking changes. But more, I see it as, well, if you wanted to build a theme or an integration, why would you do that before V1?
Or learning materials. Of course, we've had several people reach out, like, "I want to do an Astro course." It's like, you're just going to regret it. [Laughter] Things are going to change in a month. You're going to have to go re-record everything.
Chris: Okay, so this is you saying it's time for themes. It's time for courses.
Fred: Yeah.
Chris: It's time for that.
Fred: Yeah.
Chris: We're not going to break any APIs on you. [Laughter] At least not for a hot minute.
Fred: We have a hack-a-thon that we're announcing (I think by the time this post will go out), so you can check that out for building themes and integrations. Prizes, the whole thing. A bunch of cool stuff, that's what this means to us is we could work on this for the rest of our lives and probably never call it V1. But we want to cut the line somewhere, commit to this.
There will be new fixes and new changes in V2 and V3 but, yeah, 11ty, SvelteKit, my own work, it's really hard to cut a V1. It's meaningful.
What did React do? They're like V 0.12, 0.13, 0.14. All right, version 14. They just threw it all out. They couldn't bring themselves to do a V1.
Chris: [Laughter]
Dave: Yeah. Yeah.
Chris: Yeah, that's what I mean. Who else is doing a good job of semantic versioning?
Dave: You mentioned themes, integrations. That's kind of the new feature. There are some really amazing ones, like the Party Town one was jaw-dropping. You just change script source or type=text-javascript to text-partytown and, all of a sudden, that big script is off the main thread. Beautiful.
But I guess what integrations do you want to see from this hack-a-thon and stuff? What does Astro need? What community needs are there?
Fred: Oh, God. There are a couple of ways to answer that. One is, I think SSR just kind of like opened the floodgates (in our own minds) of, like, "Oh, not only is this possible, but this unlocks a lot of stuff," probably even as the people build it. We only see a fraction of it, so one of the categories is just the coolest thing built with Astro SSR. We just kind of want to see what's possible because I think we are only realizing how big that question is.
Other than that, integrations and components and themes are kind of just all this bucket of more things that make it easier to get started with Astro. Integration can be anything from a CMS. It can be a hosting provider. It can be a cool feature like Party Town, which is such a cool project.
Themes: I really hope we have this awesome story around themes where it's not like, "Oh, cool. Clone this repo," and now you're stuck on the thing you just cloned, or "Copy these files into your folder."
I think because, again, we're using NPM, we have this really cool package story. I think we can treat themes as packages that you then can get version upgrades. If everything is a component, why isn't your layout just a component that you are the one placing on the page?
Chris: Hmm. Juicy.
Fred: You control the props.
Chris: You don't mess it up. You don't download the theme, then alter the theme, and then you're stuck forever because you--
Fred: Yeah.
Chris: Yeah.
Fred: Yeah, you can make little patch changes if you fix something with styling. But then you can also, like, "Hey, the new version of this is out. It's V2. You can actually upgrade it." Obviously, there'll probably be some work. It's a breaking change. But you're not stuck re-cloning and connecting the dots.
Chris: That's a great idea.
Fred: Yeah, it's wild that no one has done that yet.
Chris: I don't think I've ever heard of that. No, that's awesome. Then this theme, it would be documentation heavy, right? Because the theme would be like, "This theme has an Astro slider in it."
Fred: Yeah.
Chris: Nobody build the Astro slider. I'm going to make that one. It's going to cost $30, too. I'm selling it. It'll be the first paid Astro component.
Fred: [Laughter]
Chris: Yeah, I'm sure people will do that. Right? There'll be all kinds of little UI stuff, but just written in the Astro way, so that whole bucket is up there, but I really like that theme idea. It could be like, this theme provides these 15 components.
Dave: I don't know.
Fred: [Laughter] Yeah. Dave, take another side. Chris is being too nice.
Dave: I don't know.
Fred: Yeah.
Dave: I like that feeling, the feeling of downloading a zip file off the Internet.
Fred: Yeah. Yeah!
Dave: From some theme site that is only half in Korean. Then I like to just feel the file. I like to go through each file and rename every file because they're named bad. Then I like to--
[Laughter]
Dave: I feel like you're moving away from that, Fred, and I don't think it's good. I don't think people want to do that.
Chris: Remember the classic PHP one where you'd have the theme elsewhere and then you have your theme, and if you name the file exactly the same, then your one wins?
Fred: [Laughter]
Dave: Yes!
Chris: But if your theme is missing theirs, then it would go and pull theirs. Oh, man.
Dave: You can't do that with NPM. You can't do that.
Chris: [Laughter]
Dave: No.
Fred: But Dave, think about what we're saying. You can import a theme. It's almost like you're importing HTML.
Dave: Okay.
Fred: Onto the page.
Dave: Well, well, all right. I do like importing HTML, so I'll have to give this a look-see.
Fred: Yeah. Not to go super feedback into the conceptual rabbit hole, but I think that implicit data flow that you just mentioned is something we've seen a lot of in the static site generator world. One thing that I love, and maybe I'm more of a JavaScript nerd than I care to admit, but explicit imports are just so nice for tooling. You can follow them. You can command-click into them and see the types. It's something that I really like, so we really tried to make everything an explicit import whenever possible. There's no inheritance of this file is here and this file lives there, so, therefore, they're connected somehow. We're really proud of that. It's something I care a lot about hitting, and I'm glad we did.
Chris: That's awesome.
Dave: Very cool.
Chris: I just know somebody is going to make an Astro theme club.
Fred: [Laughter]
Chris: And they're just going to make a million dollars. I'm going to be so jealous.
Dave: You know what? You are so close. Y'all have it very close, but you just need a startup template.
[Laughter]
Dave: Just whatever has somebody holding an iPhone, and then you need -- oh, there are a couple of themes.
Chris: Yeah, like the photography one.
Fred: Yeah.
Dave: Yeah.
Fred: I will say this whole hack-a-thon is like, we're not owning these. These are your themes. As much as we can point, like, right now we have a themes catalog at astro.build/themes where you can browse the ones. We'd love to feature people there.
If you want to link to a Gumroad or a Patreon instead of a GitHub repo - I don't know - we're not going to stop you. Yeah, open-source shouldn't just be free labor. If you want to charge for your work and you think it deserves it and you think people will pay for it, we're excited to explore that a bit more because it's something that's always felt--
Chris: Just try and stop me.
Fred: [Laughter] Exactly. You can't put a link to anywhere, but if that's what you're trying to do, paid themes are just such a natural part of the Web (going back decades).
Chris: Yeah.
Dave: [Laughter] My only fans. Check it out.
Fred: [Laughter] Yeah, absolutely.
Dave: I talk about Web themes ... website themselves.
Fred: Dave, your only fans are not welcome on our site. I'm sorry.
Chris: [Laughter]
Dave: It is not popular, either, on their site, so it's just -- you know, so--
Well, cool. On that note, we should probably wrap it up. [Laughter] Oh, whoops. Hey, well, we got so far.
All right. Fred, congrats on the 1.0 beta and all the new features you're launching here. But for people who aren't following you and giving you money, how can they do that?
Fred: The best place is on Twitter. Astro.build is the project. @FredKSchott is my Twitter.
We also have some great core maintainers I'll shout out: Nate Moore, Matthew Phillips, Tony Sullivan, Caleb -- ooh, his name is @jasikpark on Twitter, I think -- and a bunch of other awesome, like, 20+ maintainers on the project. All of them deserve a follow. I don't have their handles on hand, but you can join us on Discord to chat with them directly. We have a great community there, astro.build/chat.
Go to astro.build for all of the launch week stuff. we've got a bunch of cool stuff. You can read our blog, our Twitter, and everywhere. It's been a really exciting week. I'm sad to see it winding down, but I also need some sleep, so fair is fair.
Chris: [Laughter]
Dave: Sounds good. Well, awesome. Well, thank you again for coming on the show. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for 16 tweets a month.
And we have a YouTube, youtube.com/shoptalkshow. Check out that vanity URL.
And join us over in our D-d-d-d-discord, patreon.com/shoptalkshow.
Chris, do you have anything else you'd like to say?
Chris: Oh, I suppose we should shout out Ben. He just started over there. He hangs out in our Discord too.
Dave: Oh, yeah.
Chris: I wonder what will come of all that 11ty Slinkity work, but I'm sure some of that--
Fred: Oh, Ben on our project. Of course, yeah. Ben has been awesome and has a ton of experience bringing that partial hydration to 11ty.
Dave: And he's also bringing a level of skill to the announcement videos, his unparalleled presence.
Fred: The number of Astro helmets on our Twitter account video selection has gone up dramatically. It's increased hundreds fold.
Dave: Props is his -- props and puns are his - whatever - specialty.
Fred: You had him on the show, right?
Dave: We did... no.
Fred: For Slinkity?
Dave: We haven't.
Fred: Oh, he's great. Yeah, he's a fun interview. Slinkity is not going away. It's been a fun thing watching him support that, so maybe one day.
Chris: All right, everybody. Thanks again. Thanks for listening.
ShopTalkShow.com.