Brian:
PodRocket is sponsored by LogRocket, a frontend monitoring and product analytics solution. Don't know what that is? Go to logrocket.com. Thanks.

Ben:
Hello and welcome to PodRocket. Today I am super excited to bring back Fred Schott, who was actually our first ever guest on the podcast some large number of months ago. Welcome Fred, how are you doing?

Fred Schott:
Doing well, thanks for having me back. I'm honored to be the first.

Ben:
Yeah. Well, your episode kicked us off in a great way and since then we've talked to a lot of really cool people on the show. And today I'm excited to have you back, because last time I think we spent most of the time talking about your projects Snowpack and Skypack. But today it sounds like you're here to talk about a new project which is called Astro, and so maybe you could give us a quick introduction to what you're working on.

Fred Schott:
Yeah, definitely. I'd be happy to. It's very much a evolution of those original projects, kind of fitting them together in a new way, so this is all kind of the same story we've been telling that really came out of that original Pika project back in 2018. Astro is a much more opinionated take on web development. So Snowpack was this build tool, Skypack is a CDN for JavaScript, and then Astro is this way to really just take a stance on what it means to build a website today in 2021. So a lot of the existing solutions are really about building JavaScript apps or these hybrid apps, but that requires essentially something running in the cloud somewhere. Maybe it's building on every response. You need this globally, like the machine that is hosting a website today, it's a JavaScript app in a lot of cases.

Fred Schott:
So what we set out to do was to build a static site generator that felt like one of those modern dev tools, but the end result was static HTML. So it feels just like Next.js or Gatsby or Svelte where you're using your favorite UI framework, but the end result is something much more like Eleventy or Hugo. It's this HTML-based framework way to build websites that lets you bring your favorite web tools, basically, to generate.

Ben:
Got it. And so is the idea that by building a website that ultimately is just HTML, it's the fastest possible website you could build? Is that kind of the general idea?

Fred Schott:
Yeah. HTML and CSS, no matter how bad you write code, you can try to make it slow and it'll still run pretty fast. And we're big fans of that. We love when it's simple to do the right thing and kind of easy. I know personally, at least I've built plenty of apps where I didn't realize what I was doing, the next thing I know I've actually slowed down my website quite a bit because it's this kind of black box of performance. So there's a lot of cool stuff going on inside of Astro, but one of our favorites is you can use these JavaScript frameworks, like React or Svelte that you love, that normally you'd be building this kind of big application, and instead the end result is always server-rendered HTML. So you're using a framework that you love but you're getting the guarantee of HTML and CSS that it's really hard to build a slow site in Astro.

Ben:
Got it. And so am I thinking about it right that it's kind of, I think you even mentioned some of these tools before, like Hugo or Jekyll, or even like Rails or Django where you can do templating but then it ultimately produces HTML that's served to the client. Am I thinking about it correctly that it's kind of like that, but you can use React, or I guess Vue if that's your preference, to do the actual templating and rendering of the HTML?

Fred Schott:
Yeah. Rails and Django are a bit more advanced than what we're doing today, where those will actually be running in the server, so that's back to that world of applications running. But yeah, Jekyll, Hugo, all these static site builders, the end result is HTML. It's essentially a static asset bundle that you just ship to the cloud and then it's really fast, it's cacheable, it's static, which is nice.

Ben:
Okay. Got it. So you build your site, you compile, you build it, and then you host ultimately just HTML files.

Fred Schott:
It is a total love letter to all of those ones that you mentioned, though, where in the last 10 years, a lot of JavaScript developers and frontend developers have moved into the world of JavaScript and then kind of left that behind. So this is kind of nostalgic feel to using, Eleventy is the one I've used most recently, where you're using these Nunjucks templates or Pug, I think it's called. It's a lot of curly brackets, a lot of shortcodes and partials and it's this very older way of thinking back when a lot of what the server was doing was actually generating the HTML. We now use React for that or Svelte. We use these frameworks for components and UI and that's all very good, but that has been a push towards more and more JavaScript on the client end as well. So this is kind of trying to give you that same environment but it's a total server side templating language at the end of the day, where you're writing HTML, you're writing React, but it's templating on the server before it ever gets to the user.

Ben:
Got it. And what if you have a website where, I feel like there's a lot of websites, where most of the content is static but there's a few parts of the site where you do need interactivity and so you want to ship JavaScript with the site. Does Astro have an opinion on how to do that, or is that something where you just bring in jQuery or you just run React on some pages?

Fred Schott:
This is the coolest part of Astro by far. This is what got us most excited, because it lets you opt in to JavaScript on client when you need it and it's really seamless how you do it. So this whole project started out of Alex Russell on Twitter, kind of a grumpy old man shakes fist at cloud Twitter personality. Hard person to please, very much a performance minded person. And then out of nowhere we launched a site and he actually gave me a compliment in the DM. It was like the highlight of my career that Alex Russell said I built something that was fast. And we looked at it like, why? Because we didn't think we'd done anything fast. And it was really, we followed this model, which is static site by default. And then the parts that need dynamic you hydrate.

Fred Schott:
So the end result is not like JavaScript app by default, it's really static by default, opt-in where you need it. It wasn't until later that I found that Jason Miller, who leads Preact, had written a post a little bit earlier basically coining this term "islands architecture," which is this idea of a static ocean and then these islands of dynamic content. So your whole page can be HTML, but then that search bar, you kind of hydrate that or an image carousel, you hydrate that without sinking down the full-page, sinking down that time to first render that if you were rendering it all with JavaScript, you would all kind of take on that cost.

Ben:
So how does that work? Let's imagine I have a fairly static site, but there's an image carousel that I want to be able to build with React. What is shipped to the client and how does React load in a way that doesn't slow down the rest of the page?

Fred Schott:
Yeah, so i kind of shifts how you think where today, if you're using something like Next or one of those site builders that builds an application, it's really about building pages. Instead you go back to more of a component-based way of thinking, so you're literally shipping an image carousel down to the client. The syntax is really easy because you're already able to use these components for service side rendering, so you basically just add a little like load on client flag, almost like a prop. And it basically just tells Astro when it builds a site, "Hey, this is going to render. It's going to do that SSR thing, but then also ship that JavaScript that it needs to run in the client." So you get the full page SSR and then it's shipping down these little islands of hydration.

Fred Schott:
One thing that's really nice about that is that because it's not all one page, it's these little islands, a image carousel that might be really heavy isn't going to slow down how long it takes for a search bar, which might be very light, to hydrate and actually become interactive. So you get this kind of decoupling, almost, of different parts of your site. They all are basically their own route, which means they can load, render and respond to events almost separately from each other without dragging everything down just because you wanted an emoji picker or an image carousel, trying to think of heavy things on the browser. But yeah, it totally decouples these islands.

Ben:
Let's say you have a static site with that kind of interactive content above the fold. How do you do that? Gradual loading in a way that doesn't look janky to the user where some of the page loads, but then it takes a little while to load and hydrate the interactive components of the page. Like if there's an image carousel at the top of the page, let's say, how would that work?

Fred Schott:
Yeah, so we get to lean on a lot of what SSR engines are doing today for the whole page, which is this idea of it can render server side, get sent to the client, and then the hydration is almost invisible. So that image carousel will actually, it'll basically internally call reacts like server renderer, same thing that a lot of other frameworks that are much more stable today are using, to render it and then hydrate it invisibly. But because we're separate components, we get to do a lot of cool stuff. So you can basically unload hydrate. You can wait for the page to stop loading, do all this other high priority stuff and then when it's idle, kick off that hydration.

Fred Schott:
And then my favorite, which is so cool, is defer hydration until it's visible on the page. So we'll actually use a little bit of JavaScript that we ship down, which is an intersection observer, basically. It can tell if it's on the page or not, and if it's not on the page, we just won't load it until it is on the page. So actually, even with JavaScript enabled on your page, you can get to a world where if it's below the fold, the page essentially loads as if there was no JavaScript because we don't need to see it yet so we're not going to pay that cost if we don't need to. It's really cool, especially on mobile devices, it's so cool to see.

Ben:
Got it. And so, it seems like overall Astro is entering a fairly competitive field with tools like Gatsby, Next.js. and I do think those platforms, whether that's Gatsby's Cloud or Next.js, I guess the Vercel platform or even Netlify, they do take a lot of the pain away from developers in terms of building a fairly static website, but being able to utilize React, being able to do service side rendering and ship a fairly fast website. So I guess, how do you see Astro fitting into that ecosystem? Who are the ideal users for Astro? Who really should be considering it instead of all the other competitors, and long-term how do you see product differentiation in this space going?

Fred Schott:
Yeah. It's a great time to be a web developer because there are so many options. Next.js and Gatsby both are doing a great job in their space. They're definitely targeting a more dynamic site, so I mentioned there's a server running. You have to host that, you have to keep that running, you have to scale it around the globe. We're trying to be an option for people who don't necessarily want that. Right now, a lot of users you don't need that or don't want that are still finding their way over to that sort of solution, because it's really the only modern-feeling solution out there. So Eleventy is really, really powerful, but you still have to go back to this kind of templating on the server, HTML, Nunjucks, Liquid, all these kind of older things that at least I, as a developer, hadn't used in a while. But I love Eleventy, I would use Eleventy for it.

Fred Schott:
And so we're kind of trying to fill that gap of someone who loves the development experience of a Next.js, but wants a static site that's just kind of guaranteed fast. So like what Next.js is doing with their image component for image optimization built in, that's a great example. Anyone can do that. We could build that for static sites and there isn't that option available. So we want to kind of be that good of a developer experience, but for a different kind of site. A content site, a blog, versus an app is great for applications that have a lot of state and users or dashboards. There's a whole part of the web that's just really content-focused that's being underserved right now.

Ben:
Yeah. And it's interesting. I talked to last week, we had Kyle Matthews from Gatsby on the podcast. And one of the interesting things they're doing is a lot of work with CMS platforms like WordPress and Druple, kind of serving as the front end to those CMS back ends. And it sounds like Astro could be an interesting fit, basically used in a similar way in terms of give developers an easier, faster way to build static front ends on top of that. So I'm curious, do you see a future where you build more out of the box integrations with CMS back ends or other kinds of static site tools?

Fred Schott:
Yeah. Yeah, we get a lot of requests for headless WordPress, other CMSs. We just launched, I think two weeks ago from the time we recorded this, so the community is just getting involved now. We're seeing a lot of new projects spinning up. The support's there, we just need either documentation guides, or yeah, really, that's it. It's all supported out of the box. It's really just a chance of the people doing it now are the first people. So any sort of production site at a certain point, it moves out of the repo. We're really specialized in markdown files, having this really nice layout of your repo because we get to target that developer today, but a company is going to have a CMS and we want to support that as well. That's definitely on our very near term roadmap.

Ben:
So one of the things I thought was interesting, I read your introductory blog posts to Astro and you talk about this, one of your sections says Embracing the Pit of Success which I thought was an interesting metaphor or analogy or whatnot. So could you explain what you meant by that?

Fred Schott:
Yeah. I love that analogy. I definitely didn't coin it. I think it's, oh God, who?

Ben:
I think you have Jeff Atwood here.

Fred Schott:
Yes. Classic Jeff Atwood quote. Yeah, and really talking about like a good tool, a good experience, really its goal should be to, he uses the term, "Throw you into the pit of success." And we looked around the existing set of tools and we didn't see a lot of that going on. A lot of performance problems were more the result of the tool making it very easy to do something that wasn't performing. And that's no fault of the development. The developer is trying to build a good site. I have done plenty of dumb things because it was either fast or it got me what I needed. That's just a part of doing your job as a developer, is building things.

Fred Schott:
And performance has always been kind of framed in this almost really shame-y way where it's like, "Oh, you built a slow site? You're not a good developer at all." It's like, oh God, you could be 20 years into your career and someone can get mad at you on Twitter. That's not the way we should be thinking about performance. It doesn't need to be this like nerd cred, you know, are you an elite hacker or not? That's all completely backwards. So again, Astro is really just a return to trying to build a fast website. And the shortcut that we get to take, which is awesome, is JavaScript is where a lot of those problems lie. So if we can move that to a server side first, especially, pre-build before the user even sees it first mentality, then the user is never even seeing it. No matter how slow that is, you might slow down your own build, but that's about as bad as you can do. At the end result, you're still shipping HTML. It's really hard to go slow there. So we're trying to do the right thing as tools authors.

Ben:
Yeah. I mean, it's still shockingly hard to build an even relatively simple website that's fast. So I certainly am happy to hear more and more folks are working on that problem, and just making it by default fast seems like a good plan. So I like that. So you launched on Hacker News, I think a couple of weeks ago. And I thought there was an interesting comment I'm going to read, and then you can see what you think of it. It is of course a top one, and you you mentioned something earlier about a grumpy old man comment. And I felt like this is kind of that, but also it's a very common sentiment.

Ben:
So the comment is, "I get it. I'm glad it exists. It's neat, and congrats, but it's also amazing to see that we've reached the point of JS tooling where we're making frameworks to deal with frameworks, build tool frameworks a few levels deep, et cetera. Just seems like so much stuff, and now we have stuff to help us use even have less stuff, but it's still stuff in itself. Nothing stopping anyone from opening Notepad and writing HTML with inline style, then using FileZilla to FTP SEP to a server, probably a VPS these days somewhere, publish it on GitHub or GitLab," and then it goes on a bit, but that's the comment. And I'm curious how you'd respond to that?

Fred Schott:
I love that for a couple of reasons. And not at all, this is not like sarcastic. I genuinely like comment because it reminds me so much of this Dropbox launch comment.

Ben:
Yeah, the famous Brandon M. comment.

Fred Schott:
Yeah, right. There's this comment where it was like day one of Dropbox, they had just launched. And the top comment I think for them was, "This is great. I love it, congrats. But this is something I could do myself. I would set up an STP thing, I'd set up my own data warehouse." Maybe the cloud, I think that almost predated cloud storage. So it like really like someone outlining how you could build it yourself, "And that is why I think this is a bad idea." I mean, the takeaway from that was no the fact that you wanted to do it yourself, that you were like one of a small number of developers who either knows how to do that or takes the time, it would be worth their investment.

Fred Schott:
I love that comment because that's like a great sign, "Oh, we're onto something." Someone likes doing this and this is what it takes to do it now, but we're trying to be, again, a love letter to that type of development. Yeah, a static site is one of the easiest things on the block. We're just lucky because performance is, at the end of the day, you will always beat out someone doing more than you. And the real performance story on the web is how can you do as much as possible, shipping as less code slowing the user down as possible. So Astro is really an attempt to do as much as possible while still shipping the least amount of code, and with a modern dev experience to wrap it all together.

Ben:
Yeah. And I think that dev experience piece is just so important, because developers are smart, they can build anything and figure anything out given enough time. But if you can give a developer something out of the box that does most of what they need, and it's easy to make it fast and it lets them focus on building what's actually incrementally new about their project versus building infrastructure and tooling, it seems like it's always a win. And the amount of developers in the world is growing, the amount of projects developers are doing is growing. And so the more developers that can focus on just creating value and not struggling with their tooling is just always going to be net positive, I believe.

Fred Schott:
It's a tough spot about where the web is right now. Where open source is, really. I think Zach, the maintainer of Eleventy, just posted something on Twitter essentially like, "Listen, we're never going to be first to market because this is a side project. This is an open source at its core side project. So we think it's good to be small." He was basically making the case that it lets you not prioritize features for the sake of a business story, it was he gets to prioritize features because they make sense to him as a maintainer. The open source ecosystem today is just really full of a lot of companies that are trying to make a business case, and the open source is almost in service of that versus being the other way around. So simple as it's a rare commodity, we're trying to at least be true to that. Yeah.

Ben:
So that's a good segue, because I was going to ask, thinking longer term is there a business to be built around Astro in the way that Vercel is being built around Next, and Gatsby Cloud is being built around Gatsby? Is that at all thoughts in the longterm of Astro, or is the goal just to build a great open source tool and let people host wherever they want and not try to monetize hosting or other services?

Fred Schott:
Yeah, we're trying to walk the line between those two. So Zach from Eleventy on one side and then Vercel or Gatsby on the other. We are certainly trying to build a business. We have full-time people working on this tool because we want it to be great. But at the same time, I think the hardest dance here is building features that are authentic to the tool itself. So building features that support someone, even a free user, versus someone who is paying or building their company on top of some paid service. I think the line that both of those companies walk where it's like, here's the open source and here's the hosting company, I think is a pretty decent attempt at it.

Fred Schott:
But I don't know, we see ourselves more as we're trying to follow a WordPress model where if we can build this new platform for development where there's this whole ecosystem of plugins, of add-ons, of people building on top of it, themes components. If we can do that, then I think there's something really valuable there that doesn't force us into an open source tool with any sort of... The worst thing you can do is just jam hosting into the story. I think that there's a path there that we are at least excited to explore around being the platform versus the hosting add-on.

Ben:
Got it. And earlier on, you kind of mentioned how Astro does build on some of the work you've done with Skypack and Snowpack, so curious, could you talk a bit more maybe for viewers who didn't hear the very first episode so long ago, quick introduction to Snowpack and Skypack, and then maybe you could speak a bit to how Astro builds on the work you did there.

Fred Schott:
Yeah, it builds very technically on top of Snowpack and then very conceptually on top of Skypack. So I think of the two Snowpack would probably be the most interesting to talk to. Skypack, you can go check it out at skypack.dev. It's basically a way to import any JavaScript package from npm as ESM. So it literally will work in the browser natively. It's really cool. We're conceptually aligned with that idea of just being more BSM first, but Snowpack is actually what's powering Astro behind the scenes. And it's probably technically possible to build Astro without Snowpack, but it's really a lot of the mental shift that we're able to make from JavaScript application to HTML website. That idea of like what you're building is an HTML website, not a big app, is because Snowpack is not a JavaScript bundler the way webpack or Rollup is. It's a build tool for the web, but it treats every asset as essentially a first-class CSS, HTML, JavaScript, they're all part of the site you're building with Snowpack.

Fred Schott:
So Snowpack was a site builder. It was really about taking away the bundler from your build tool and treating these assets that way, giving you a really fast dev environment. ESM was very new at the time, so it was this kind of contrarian way to think about building your site where you're actually leaning on a new tech in the browser, which is like the total opposite of webpack and Rollup are all about, compiling out the cool stuff so that it runs anywhere. But we thought dev could be one thing, production could be still the same stable, old code.

Fred Schott:
But that was a tool that was kind of designed, pushed, and we care a lot about, but the world caught up to us. So Vite is kind of the new kid on the block there, that's a great other ESM-based tool. There's a couple of, I think more Rust and go-based tools that are starting to explore more of the space. So if you're building a tool now from scratch, you would definitely follow an approach more like this. So that's given us a chance now to take Astro a little bit further and say, "Okay, but what does it actually mean? What am I building?" Not just the how, but the why and the what.

Ben:
Cool. And so looking at Astro, tell me a bit about roadmap. What are you most excited about, next year or so of roadmap?

Fred Schott:
Yeah, so our main focus right now is we just launched a beta. It's beta, it's not as stable as you want to get [inaudible 00:23:25]. The people who tried it out day one, my heart goes out to them because it was exciting and Wild West and we were kind of fixing bugs as we launched. It was exhilarating, but now we're kind of two weeks in, we're kind of taking a breath. It's really the last week of tackling these kind of launch bugs. So yeah, we're trying to figure that out now. Our Discord community has been amazing. There's a ton of great feedback and ideas going around there. So that's astro.build/chat if you want to get involved. It's an open source project. We're really trying to lean on the community for guidance here in terms of our roadmap. I know that the obvious directions to go is more towards Next.js, that idea of running in a server, but I'm trying to stay away from that.

Fred Schott:
It's cool and powerful, but then all of a sudden we're playing catch-up to a game that for all other purposes, Next.js is doing very well. So we're trying to kind of find our niche here, what isn't being served today. I'd say what will keep us busy for the next couple of months, at least, is definitely taking more from that developer experience and bringing it to this world. Like the image optimization built in, font optimization built in, I'll do some cool stuff around having an icon font essentially managed by Astro so you don't need to take all of Font Awesome or all of these giant STKs. There's a lot of cool stuff we can kind of play around with that we're really excited about as developers.

Ben:
Right, yeah. It seems like really drilling down on that static site use case and making it fast. And it sounds like you're kind of doing this, like looking at what are the commonalities between most static sites and how do you make it easy to do that in a very fast site.

Fred Schott:
Yeah, and it's already conceptually what we're talking about, this idea of every asset should be treated as a first-class citizen. So we're not a JavaScript bundler where everything else is just off to the side, we're actually thinking about images, videos. We have a really cool built in CSS bundling mechanism that basically is like scope CSS, but by default bundled for you automatically. the problem with launching something, I get excited about everything, so even as we were writing the blog post to introduce it, we left like five different things on the cutting room table. There's markdown component support, so MDX-like. There's all these cool features that we've been building into it for the last couple of months now, so we're really excited to see where everyone takes that.

Ben:
Okay, so that covers the Astro roadmap. Curious to hear since we spoke way back when, maybe what has changed specifically in Snowpack and what are you excited about in the future of Snowpack?

Fred Schott:
Yeah, I mean, this is built on Snowpack kind of to its core so we're learning a lot as users of Snowpack now. Not just building sites, but we're basically using it as, as our SSR runtime. So that was a fairly new API that we actually launched basically in collaboration with Rich Harris of Svelte back when we were testing out Svelte being powered by Snowpack. He had integrated a SSR runtime, and now we're like power users of that. So that's been cool to kind of kick the tires on that. We love it. We're seeing all these kinds of ways we can make it better now, so I think Snowpack v4 is really going to be about being a better runtime for build tools. The way that webpack is powering Next.js, Blitz, all these other platforms, Astro kind of has that in Snowpack, but we're definitely kind of hacking around some edges there.

Fred Schott:
It's not as easy as possible. So there have been a couple of people before us, like Microsite, Slinky, I think is the newest one, which is like a Snowpack plus Eleventy plugin. There's kind of like these experimenters who are kind of testing the edges of what it means to build on top of Snowpack that we want to support now that also building on top of Snowpack. So that'll definitely be a priority.

Fred Schott:
Vite also has done a great job seeing how far esbuild can go. esbuild is this really cool new tool where it basically like is I think it's Go or Rust-powered build tooling. We use it for a small part of our bundling and building, but there's way more that we can apply it to, and especially now it's getting more mature. I think we're going to go all in on esbuild for the next version. So essentially a dev environment on top of esbuild would be a really cool way to take Snowpack. That'll just mean it gets lightning fast.

Fred Schott:
So yeah, we're really excited. Drew Powers has been a contributor to Snowpack for forever and is working on Astro now, but is going to be taking some time to really get Snowpack v4 focused on and what we can do for that.

Ben:
Awesome. And speaking of contributing, if anyone out there wants to get involved with Astro, what's the best way to do so? Just go to your GitHub, or any kind of community that people can join?

Fred Schott:
Yeah. There there's links everywhere. We scattered them all across the internet. astro.build is the website, and then /chat if you want to join our discord. We've got a lot of cool projects going on there. We're trying to build this really cool GitHub Discord integration bot, which we haven't seen anyone do, so trying to kind of connect these two communities together a little bit more. And Documentation, dynamic routing, there's just all these cool projects being spun out of there, so a lot of people. We're also perf testing Astro sites, which is always fun. So there's people posting actual like webpage test timelines and screenshots and seeing how much faster we can get it compared to some other stuff. So, yeah, it's just a really energetic community. That's probably the thing I'm most proud of from the launch, has definitely been that.

Ben:
Is that community that's developed kind of organically, or have you done a lot of promotion and made efforts to build the community?

Fred Schott:
Nate Moore did a great job. Nate Moore is one of the other people working on Astro, and I went out for paternity leave. So I was out, and he did this really clever little secret site, basically, before we launched where there was like open your console log, there was a link to discord. And we had this really organic community grow out of that, of people are just kind of found us and then were excited about what we were building. So we were lucky to kind of launch on the back of a private beta of about 300 developers. That definitely helped us kick the tires a bit, but that's only grown since then.

Ben:
Awesome. Well, Fred, it's been once again great having you on the podcast and I hope we can have you back in another six or 12 months to hear about what you're working on, but yeah, it's been great. Thank you so much.

Fred Schott:
No, yeah. I'm so glad the podcast is still going strong. I didn't tank it on the first episode. That's always a good sign. So thanks for having me back on.

Brian:
Hi. Thanks for listening. Please remember to like, subscribe, email me if you want, even though none of you do. Go to logrocket.com and try it out. It's free to try, then it costs money, but yeah. We'll see you next time. Thanks.