Paul: Hi there, and welcome to PodRocket. I'm your host, Paul. And today we're joined with Ben Holmes. Ben was on the podcast last February in 2022. Ben, you're the creator of slinkity.dev. And we were going over Slinkity and the great power it can help developers tool in their front-end projects. Today we're going to be talking about something a little bit different, Astro, because you moved on to now you're a software developer over at Astro. A little bit of a change of pace. Excited to get into it. And welcome to the podcast, Ben. Ben Holmes: Yeah. Thanks for having me. It's crazy it's already been a year. It feels like a decade ago but also yesterday. So, good to catch up. Paul: And that podcast that we did together back then, at least on a personal front, really opened up a world for me of not using React anymore and looking over at the Slinkity thing that you made. And Astro was kind of like... For somebody getting into that world as a noob, stepping into Astro was a natural next step after understanding what Slinkity did. So it's really cool that you're here now. You're working at Astro. We're going to talk about the new updates. Astro 2.0 is out. We're, of course, going to get into Astro 2.0. Off the bat, if somebody's coming onto here and they don't know what Astro is, in 30 or 60 seconds, what can you tell them? Ben Holmes: Yeah. Astro is a site builder to build content-focused websites. Think marketing, blogs, newsletters, documentation, all the way up to e-commerce. Astro is a really great way to do that. And it's focused especially on making things performant, server-rendering as much as possible, and letting you bring all the tools that you want. The interesting thing about Astro is you can bring React, Vue, Svelte, Solid, LitElement, anything that you want. And we already have built-in tools to let you use your framework of choice in order to build those websites. Paul: Framework of choice. That's a big one that different generators and toolings might have or might not have. So cool. It really helps us build websites. It's a new framework. We've had episodes with Fred Schott, the creator of Astro. If anybody wants to go check those out, we have a few recordings of those. Yeah, so it's a framework. If I'm using React, I can step into using Astro or Next.js. It's similar. There's a page layout system that I can use and familiar stuff like that? Ben Holmes: Yeah. We're actually modeled on how Next.js routing back in Next 12. So if you're used to pages directory, you create little square brackets to have dynamic routes, use getStaticPaths to generate stuff and even turn them into server endpoints if you want to since we have an SSR feature. All of that is supported and should probably feel pretty familiar if you're coming from that side of things. Paul: So did you get reached out to by Astro or did you maybe think Slinkity was in a good spot, you wanted to move on to something different? How did that transition in your life come to be? Ben Holmes: Yeah. It was definitely interesting. I'll start by saying that Slinkity has reached its ceremonial 1.0 and also was kicked into maintenance mode soon after because I just wanted to deliver all the final features for that project and then devote all of my time to Astro here on out. Because Slinkity is... It was a great learning experience. It's where I was able to learn about Vite and all these amazing bundling tools and also about using your framework of choice to build things. It's a powerful idea. But now, it really feels like Astro is taking that idea to the next level, taking it to 11. So, sunsetting that, moving on to the next thing. Speaking to how I got started at Astro, it was actually a Twitter DM. Fred messaged me very early on in the project before it had been incorporated as The Astro Technology Company. Just sort of like, "See you're working on Slinkity in the community. Astro is trying to do something very similar. Would you like to do that but for money?" And I thought, "Yeah, that makes sense." There was, of course, more discussion and ceremony than that, but eventually decided to join the team full-time. And the rest is history. Been here since March through the 1.0 release and now the 2.0 release. Paul: What's one of the things you think Astro does to, so to speak, take it to 11 that piqued your interest coming from your Slinkity project? Ben Holmes: Yeah. Slinkity was definitely bolting two unnatural tools together, where you're trying to take Liquid syntax; which is a really old templating language, it's been around for a decade; and trying to stitch that into really modern tools like React or Vue or Svelte. And bridging that gap works, but there's no type safety, there's no auto-complete. You don't own the template, so you can't have nice editor tools that auto-complete for you, at least not easily. And Astro took that in a different direction and said, you know what? In order to make this work right, we're going to need a new template, a new server template, which is the Astro file. That way, we can own the language tools and give you that amazing auto-complete where you can just type a component name and it wires up the import for you. You start typing one of the client's directives, which is how you opt into shipping JavaScript, and we can give you documentation in-line while you're typing it so you can learn the tool while you're using the tool. And it's only gotten better from there. Developer experience is half the battle, and Astro is in the perfect place to make that work. So it just felt like the natural thing to go after. It's the full package. Paul: You said something interesting. You choose whether you ship JavaScript. And this is what these special new frameworks are delivering to us as developers. Are we shipping JavaScript or are we not? And I think where Astro shines, from my thousand-foot view of not having gotten into it but read it and booted up the Start project, is I can choose if JavaScript goes and when it goes. Could we start to look into that a little bit? What type of power do you have as an Astro developer about choosing where JavaScript goes that you were really enamored with when you stepped into the ecosystem? Ben Holmes: Yeah. That was, I guess, the claim to fame or what people were excited about, which was islands architecture. It's not as scary as it sounds. It's not this whole new architecture you have to learn. It's just the idea that, instead of building your entire app with JavaScript components top to bottom, you can pick and choose which parts of your app actually need to have a component with client-side JS. So when you build an app with React, you whip up a new Create React App. You're learning it for the first time. You create that div with an ID of "main." And then you just dump JavaScript in to render the rest of the app. That works if you know everything's going to be interactive. But when you're building marketing and blog sites, usually, it's half and half or less than that. And it would be nice to avoid loading JavaScript where you don't need it so the page can load really quickly, clients can see your e-commerce homepage super-fast. So in order to do that, we give you these nice little switches to start with the server-rendered template. You can use the JSX syntax you're familiar with to render out a page. And then when you need to reach for JavaScript to do something dynamic, say, an image carousel you want to put on the homepage, for that, you can write that image carousel with whatever framework you want. Say we're wanting to use React. We want to migrate into Astro. You can take that React component you wrote and you can import it onto the page and decide whether to load client JS with that. So we use directives in order to do this, where you can say, for this image carousel, I want to load that JavaScript when it scrolls into view. So you can use the visible directive to say, I'm not going to load any JavaScript when you go to the homepage so that it loads really fast. And then when you start scrolling down, I'm slowly going to load all the JavaScript you need so that when you click that carousel, it's working. You have that granularity to really choose exactly what needs to load and when. So you get really great performance while still using the stuff you already know. You're still using the same carousel that you wrote in that Create React App. Paul: Is there a directive... Down-scroll is an easy-to-understand one. Is there a directive or, rather, a strategy that you, Ben, have employed loading JavaScript onto a page that you found particularly exciting that you'd want to share? A directive, a strategy. Ben Holmes: Yeah. Once you use them, you're mostly using the visible one and just the load or idle directives. Those are two flavors of the same thing where you can decide I want to load JavaScript straight away for these components because I know they're above the fold, you need them immediately, so I'm going to make sure that's ready as soon as you go to this page. And idle is a way to delay that just a little bit. If you have some ad trackers and other things that need to load first, let those load ahead of time, and then let my component load in a more delayed fashion. So if you have more performant things, maybe you have a green sock animation and a crazy thing going on with the heading, maybe you want to use idle in order to let that green sock animation run, then load your components stuff. That's probably the most interesting thing I've done. Otherwise, we have the media directive where you can only load JavaScript when a CSS media query is satisfied. That's usually just used for nav bars. That's the big one. Where it's like, my mobile nav bar has a slide-out and I only want to load that slide-out when I'm on mobile. And then on desktop, I can just load some regular server-rendered HTML. Don't have to load any JavaScript at all. So when you use those tools, they're perfectly boring for the things that you want to do, which is usually a sign that it's a no-brainer. It should have been here the whole time. I don't need crazy use cases that are just useful. Paul: These directives, do you load JavaScript? Do you not load JavaScript? It almost puts the onus of responsibility of what do you need to interact with X, Y, and Z into the implementer? Do you use any crutches, tools, sticky notes as you're writing down this almost dag you're creating of how things get loaded and hydrated onto the client? Ben Holmes: Yeah. So you mean do I plan it out ahead of time, like what is going to load and when? Paul: Yeah. Or do you maybe not ship- Ben Holmes: Yeah. I usually just, in the moment, decide, yeah, this probably... I try to default for the one that's the most delayed. I actually did a little poll in the community like, "What is your default? What is the first thing you use in Astro?" And it was split between using visible first to only load that component when you see the component, and then slowly move it up to more and more urgency as you realize, "Oh, dang, delaying that actually made my website worse. Let me do something that's less delayed." That's really been my only approach is use the most delayed one, user-test it, bump it up if something isn't really performing how you want in production. But yeah, that's my approach. Paul: Are there any new directives in Astro 2.0 that have come out? Ben Holmes: Yeah. We kept the sauce how it was. We didn't do anything fancy for Astro 2.0 when it comes to the island story. We're really trying to build out everything around it. Now, 1.0 is just shipping the stable version of this islands architecture idea. Waiting for the community to use it and see how they apply it. And then when we saw people were really going after marketing blogs and docs, those are the big three, let's try to build things for those use cases specifically, which drove us to way better markdown and MDX type safety using content collections. That's the headline 2.0 feature. And also, pre-rendering, which lets people do a hybrid of static builds and server-rendered endpoints. So you can have both of them living in the same app, which you couldn't do before in 1.0. Paul: So if somebody's making a blog or just content, we're talking about content sites, markdown is awesome because it's auto-formatted and stuff, and people are familiar with it. And then there's MDX. How is that different from markdown? Is it different? Ben Holmes: It's very different. As someone who deals with the parser, it's like these aren't even the same thing. There's so much going on. But usually, the way we pitch it is markdown is the really performant way to get content on the page. It's a lightweight parse to just turn markdown into HTML. And then when you realize, you know what? I actually need to use Astro's image component, which, today, you would need to import as the image, the same way you would next/image or Gatsby Image if you're used to those. We have an equivalent. If you need to reach for that, you graduate to MDX and import that component. If you need something dynamic in your markdown, you want to have... Maybe you have a blog comparing React versus Svelte, that's something I've done, where you actually want to load a React component and a Svelte component on the same page and compare how both of them work. And then giving you maybe an interactive sandbox in order to play with all those ideas. At that point, if you were in the 11ty world, you'd stitch together shortcodes and hope they work. But in Astro, we wanted to say, actually, import them as components. Author them with Astro components, React, Svelte components, and import them like you would in any other file. And that's what we ship with MDX. It has the same client directives. It has the same support for any framework. It's just an Astro file with markdown syntax when you need to reach for it. So if you need to do anything fancy, you graduate to the MDX side, but it's got a bunch of extra features. Paul: An MDX file, would that look like a markdown file to me? Ben Holmes: It would. You can just change the dot-MD extension to MDX, and everything works fine. You just unlocked more features by adding that little X on the end. And we also support the same front matter, so like triple dash. You put in your layout. You can put in your title and description that you can load later. All of that stuff works the same between markdown and MDX. So you can organize them the same way too. Paul: So you mentioned components. You're saying I can use Svelte, I can use React, I can use whatever. But one you mentioned was Astro components. And some implementation demos that I've seen of people tooling with Astro components looked super appealing to somebody who just wants to spin up a content website. I just want to push stuff out there. The Astro components looked simple, very easy to integrate with MDX. Is that something that's new with Astro 2.0? I guess, what is the added benefit with the typed markdown that we get with the Astro components for these types of developers and implementers? Ben Holmes: Typed markdown is this separate thing that's more around organizing and importing it once you've authored your content. But the Astro side of things has, of course, been around since we shipped the MDX integration, which was 1.0. And I totally agree. Astro components are... They're probably the default we recommend for most people because it's just a templating language. It doesn't have any opinions on use state or client-side stuff. That's where you reach for the other ones. But by default, an Astro component is just some server-rendered HTML. It lets you use JSX expressions but without the weirdness. We have class instead of className. We have set:html instead of dangerouslySetInnerHTML__ scary stuff. So if you just want JSX but nicer, Astro is really what I reach for, and then graduate to the other stuff when you actually need it. Paul: If I'm using an Astro component, do I get the same... Even though it's simple, could I still choose to render it statically or dynamically or in whichever way I want with all my other components from what other frameworks I use? Ben Holmes: Yeah. Astro doesn't use client directives because we don't have any client-side state management. Astro's that baseline where you load other client-side components. We offloaded that problem to the frameworks that you already know. Paul: Gotcha. Because they've been doing it. So you're like, "Okay, we'll focus on this niche and make sure it's really good." Ben Holmes: Yeah. We'll make sure server templates are really good. We have seen people use Astro just to mount web components because we let you put in script tags in Astro because it's just a server template. So people put a little script tag and they can mount their web component. And we'll even bundle and hoist your scripts up to make sure that they load more efficiently. So that's definitely a use case if you're a web component nerd. I'm personally not, but I see it used a lot. Paul: Yeah. It's an up-and-coming conversation, so there's going to be people who are listening to this who that's going to pique their interest. So yeah, Astro components, there's not too much to think about it because they are just really like a templated component. There's a lot of availability you can do with that. If you're looking at something more of a heavy state-managed component like React or the Sveltes of the world, you still have power to have hybrid rendering now. So you can choose to statically render out the component. You can choose to do dynamically at runtime. What do you think is an interesting use case that you've seen of somebody do that? I like the carousel example that you gave at the beginning because that's the go-to JavaScript. Like, okay, I want to show images flopping around on the screen. What's maybe a React component or React functionality that somebody might have, okay, I want this static and I want this dynamic? Ben Holmes: That is something that I expected to use more but personally don't. I think I use it on my personal Whiteboard the Website, where I have a little video player that has a little colored border that appears whenever you click the play button. It's just a few lines of JavaScript to make it happen. I think I used SolidJS just for fun since we support it. But on the permalink page, there's no JavaScript. And then on the homepage, it does load the fancy JavaScript. So that way the dedicated page for that video loads really quickly. And then on the homepage, you get the fancy stuff because that's where most people are going to land anyways. So, same component, two different ways. You can also use slots and other things to dynamically add different content to that component without shipping JavaScript for the stuff you're slotting into it. I've used that. This is a more advanced case, I guess, but importing a markdown file and then making a thin little JavaScript wrapper in order to add that colored border when you hit play. But all the content inside of that colored border is just server-rendered stuff. There's no JavaScript involved. It's zero kilobytes. So you can get really fancy with what we call donut islands, where you server-render everything and just load a little JavaScript for the stuff on the edges. That's the most fun that I've had with it. At the end of the day, it's usually choosing different flavors of client directives depending on the context. That's the big thing that I see. This component uses visible for this page and uses onload for this page because it happens to be at the top or something like that. Paul: It's a totally valid use case, though, because you might want to not. It's really good for DRY: don't repeat yourself. You could write the same component and have different levels of detail depending on what area of the website you're in. That's something that when I was like, wow, you could render it static or dynamic, depending where the client... You could even maybe do it based on their network connection speed. Like, "Oh, this client has a gigabit connection. Sure, let's load everything right away." I thought it was a really interesting use case. And one thing we love about Next is errors. When something errors in the front end, you get that nice error box thing. And when I was scrolling through the Astro 2.0 updates, they had a screenshot of the new error box. And I was like, "Okay, this one wins now." It looks really good. Did you do any work on that new feature that came out yourself? Ben Holmes: Yeah. It's funny. When we talk about 2.0, it always ends just talking about the error overlay. It wasn't meant to be the headliner, but it is. It just is. Paul: It's the star of the show. It's a visual thing. And as humans, I feel like we're like, "Ooh, purty." Ben Holmes: Exactly. Yeah. That was actually co-built by Erica, who runs the VS Code extension for Astro. So if you see all the cool auto-complete we have, she's the one making it happen. And Mark, who is a new designer on our team that's been making all the Houston emotes that you see in our chat. And teamed up and said, let's actually get a designer to make the best error overlay we can. And then pair it with a programmer who can say, what's the best information to put on this error overlay? So we had a core discussion asynchronously over a few weeks, like what details should go in here. And that led to the hint, which is separate from the actual error message itself, where we describe what went wrong, tell you how to fix it, and then give you a little hint linking to documentation so that you can read up more about what actually happened. And I ended up using that for the content collections feature because that's all about type-checking your front matter before you ship. So when you do that, you want to check, oh, the title was missing on this blog post. Let's throw up a really nice-looking error, tell them that the title was required and they need to add it in. And then add a little hint telling them more about content collections. Like, oh, maybe you're surprised to see that the title was missing and you misconfigured something. Here's a documentation about setting that up so that you can debug this problem on your own. Because at the end of the day, some people want more details, some people want less, so why not just give both? So it landed on a really nice error overlay and new error codes. We have documentation for ourselves about how to write good error messages in the future. And it's just completely cleaned up from 1.0, which was just Wild-Westing, typing up error messages wherever we wanted to. All the wording was inconsistent. They were all in different places. And now it's all in one big error file. Paul: That's really encouraging to hear somebody who wants to learn Astro because I'm thinking, to learn in Rust, the thing that got me into it was the fact that the compiler was helpful. And it was a unified tone. I don't even care if the error message is accurate or not. It's like I'm talking to the same person behind the screen. Ben Holmes: Exactly. Paul: They don't go through mood swings. They're okay. It makes it easier to work with the compiler. That's great for people coming into the framework right now trying to learn. Ben Holmes: Yeah. Paul: So you provide links to the documentation too, which is neat. Half the battle, they say, as a programmer, is Googling stuff. When you learn you can put double quotes around a word in Google and it forces it into Google, I think you become a mid-level programmer. Ben Holmes: Yeah. Yeah. Paul: Because you're coming from the Slinkity project and spending so much time in there, you've spent a lot of time with Vite and tooling with Vite. And Vite 4.0 is the new kid on the block now. What benefit did Vite 4.0 really come and haul heavy right out the gate? Ben Holmes: It was a beautifully boring release, I hate to say. They actually bumped up an internal dependency of theirs called Rollup, which people have seen before stitching together bundlers over the years was a recommendation for Svelte. And it's a bundler that I used a lot. That finally got bumped to 3.0, and it was on 2.0 for years. And so Vite ceremoniously also became Vite 4.0. But there's other magical things that they're doing that I'm excited for us to experiment with. I think their headline feature was support for React SWC. So using Rust to compile React way faster than Babel. That's not something that Astro supports yet because we want to support multi-JSX like using React and Solid in the same project, which is a really big proposition. We're the only framework to do it as far as I know. So in order to go into the Rustiverse, we're going to need to take a step back and look at it. But it's really cool that Vite is pushing that forward because I know Next.js is also making Turbopack and all these fancy bundlers. So it's good to know the engine that we use is definitely going to keep up and also have a lot of community contribution from Svelte, Solid, and ourselves to push it further still. Vite 4.0, kind of boring. Hopefully, it didn't break anything on your end. It should mean less Vite config and overrides if you ran into server bugs in the past. So yeah, try it out. And I hope you don't notice. Paul: Yeah, hope you don't notice. That's a good thing. And the other thing is the new dev server, which is another backendy thing. Ben Holmes: Yeah. Paul: Hopefully, you just run in and it continues to work. Just a quick note on the dev server. I'm surprised about how many places I've worked or just gigged at for a little bit, and you see production groups running dev servers. It's quite shocking. Please don't do that. Ben Holmes: Running dev servers in production? Paul: Yeah. Ben Holmes: I've seen that use case for deploy previews if you use a CMS and you want to edit stuff in the CMS and have it live update on the other end. There's a lot of interesting ideas coming out of that. And we have a lot of CMS users that wanted to integrate with Astro better. So I think some of that conversation's going to come in. But I agree, don't run a server in production. We got server endpoints, we got SSR, that's what it's for. Paul: So, Ben, on your personal website, Whiteboard the Web, you're using Astro right now. What are the different frameworks that you're utilizing to present that website to people? You mentioned Solid already. Ben Holmes: Yeah. It's a pretty simple stack because... Well, I set it up with content collections, of course, where I just manage all of the videos posted as just markdown files, where it has the link to the Twitter and the YouTube in the front matter and then a description of that video below it to just give a little more info. If you happen to find this through Google, let me tell you what the video is. And then I used collections to validate that the Twitter and YouTube URLs are valid URLs. That's just a regex that's built into our validator now. We use Zod in order to validate all of this stuff if you know what that library is. Paul: We actually had a Zod episode just recently. Ben Holmes: Nice. Paul: Super powerful. Everybody should check it out. Ben Holmes: Yeah. And that's what Astro uses now to validate front matter. If you have a big blog, docs, etc., just folders of markdown, and you want to make sure all of them have consistent front matter end to end, you can write a Zod schema to make sure that the title, description, image, URL, etc., all look good. And you can do fancy stuff like parsing date strings to date objects so you can internationalize them. Zod comes with a lot of stuff. It's way more than TypeScript, which is why I'm really excited we ended up using it. Paul: Zod is, I would almost argue, a whole language hiding in a library. Ben Holmes: It kind of is, not in an intimidating way. It felt pretty natural to just say dot string. Okay, I checked that it's a string now. And then dot URL. Ooh, it's a string that is a URL. There we go. So you do learn it, and it is writing JavaScript instead of writing TypeScript types. But yeah. It felt natural but stupidly powerful. There's so many functions. The README is big. You can go deep if you want. Paul: And the crazy thing is I didn't even read the README to start using it because it's so well-designed. It's really powerful to use. Turning back to your blog or Whiteboard the Website, Ben, when you want to make a new piece of content, what does your workflow look like? Ben Holmes: Yeah. It's really short. Because I'm whipping out onto Twitter, YouTube, TikTok, and then the personal site with the links. And I have not automated anything. It's all manual. All I do is just make a new markdown file, add the Twitter and the YouTube in the front matter, put up a little description, and that's it. I just hit "publish" and it deploys in under a minute because I'm using server instead of a static build. I set up with Vercel Serverless just for fun because I wanted to learn what can it do. And that let me set up some magic things like permalinks or redirects where you can go to... Well, the domain is wtw.dev. Visit today. But you can do wtw.dev/57/Twitter. And that will take you straight to the tweet, instead of going through any of the other flow. And because it's one big endpoint, I can just check, oh, you went to slash Twitter, let me go grab the Twitter URL out of the front matter over here and I'll redirect you straight over. Just using Astro.redirect, you can just set up a redirect in one line. You don't have to worry about anything. And you can also set up cache headers to cache it as soon as that permalink hits. So I set up really aggressive caches across the whole thing that invalidate when I rebuild. But once I have a visitor, then it's just cache for everyone else. But it means that the build finishes in like zero seconds, and then it incrementally builds everything out with caches once it's ready to go, using CDM caches. I have a video on that. I at least understand how Vercel does it. That's my extent of the knowledge. But it's really good on there. Paul: Vercel has really good docs too on how they do it. Ben Holmes: They do. Yeah. Paul: They did something right, that company. They were like, "You know what? We're going to document the crap out of everything and nobody can get it wrong." And so everybody's like, "Oh, yeah. Okay. I'll go use your stuff." Ben Holmes: Their cache docs are so good. I was actually telling the Netlify team about it like, "Check this out." Their explanations not just of how to do cache headers in Vercel but what the best cache header is for what you're doing. It's better than the MDN docs, which I didn't fully understand. It actually directed me to, oh, use s-maxage to cache on the CDN. So then you don't have to bust caches or anything like that. It was so easy. It was so easy. Paul: How do you manage your markdown files in your head, Ben? So if I made a Next.js website and want to make a new page or a new piece of content, there's a few ways you could do it naively. Reach out to Firebase and get a whole honking JSON doc. You could get a static asset. But with 2.0, you have this whole collections thing. So how are you utilizing that and helping organize the content as you iterably put it out on your Whiteboard the Website? Ben Holmes: Yeah. It's a feature designed for managing your content with markdown and MDX via Git, so local files in your project. You're not making an account on Contentful and making an API call. You're just committing all of your markdown MDX here, and other data types in the future too. But managing it all that way. And then it's all based on folder structure. So I mentioned collections. Collections are just a directory of things with the same front-matter shape. So I just have a Whiteboard the Web episode collection. And that collection I can configure with Zod to have all the same schema all the way down. And then I can fetch that collection just by saying "get collection" and then "whiteboard episodes." And just by using that string, it actually has a little auto-complete because it knows the collections in your project. It does type generation to give you suggestions as you're typing. And then it's just pulling in that folder and letting you use it again with even more type-checking and auto-complete all the way down. So it's just type gen end-to-end and managing things with folders as you probably already are. Paul: So I can almost, in my brain, say this is going to be like pages on Next.js. It's just going to be MDX files. It's going to go in there. It's going to find them. It's going to be type-checked. There's going to be a particular form to the header, and I'll scope them based on their form. That's beautiful. And I love that it uses Git because, as programmers, if I'm writing a personal blog, I spend all day in Git. I'd rather just use Git. It's just easier. You don't have to think about it. It's free. Ben Holmes: It's easy and free. If you're making it open source, you can just tell people, "Yeah, go edit the file." I can literally put a permalink at the bottom of my blog post saying, "Go edit this blog post if you see a typo." I feel like Git and just local markdown is the default for a lot of devs getting things out. Even devs that work with copywriters and designers, they still use markdown and MDX. If that's your flow, it feels like we're building the perfect starting point for that sort of thing. Paul: Is there anybody building Docusaurus with Astro right now? Ben Holmes: It's definitely come up because we do have a doc starter that you can try on Astro.new, but it's pretty limited. It doesn't help with internationalization much. It shows you how you might structure your pages folder for that. We did update it with content collections, though, to show how, oh, yeah, you can put your docs in here, make sure all your documentation pages have a title description, categories, etc. But a full-built Docusaurus, they're shipping out features left and right. The Docusaurus I saw a year ago, not the same one. I got to go spin up a starter project with Docusaurus now. But of course, Astro is that static and performant default that people want to try out. So it feels natural to have a more powerful docs theme. Maybe internationalization opinions baked into the template, said you know how to do that straight away. And content collections are half that battle of at least we help you organize everything. And the end styling and rendering of your documentation is up to you. But it's come up a lot. It's something that we want to improve with our templates. And I think building towards that makes a lot of sense. Paul: Right on. Ben, for your project, Whiteboard the Web, I want to close out on this, are you going for something that's similar to what Jeff Delaney's doing with Fireship and education and putting out very niche content? Because you do more advanced niche content about- Ben Holmes: Too niche. Paul: Too niche. Oh, you're shaking your head. Too niche. Are you trying to broaden out a little bit right now? Ben Holmes: Yeah. I'm still feeling out the kind of content that people like because I've noticed that what does well on Twitter may not do well on YouTube and vice versa. The only things I've learned so far on YouTube are if you say "industry trend," people click. And if you say "React or Next.js," people definitely click. Even if the video is not about Next, it's like, "Should I switch to this from Next?" Still works. Still gets likes. So there you go. But yeah. Of course, I've followed Fireship for a long time. I think we both try to explain things in the shortest amount of time possible. I'm more aggressive about that. It's like 60 seconds for every video, which is the max length of a YouTube Short. So that's my lowest common denominator. So everyone is 60 seconds. And by doing that, even if the topic is kind of niche, you have to really understand something to explain it in 60 seconds. If anything, it's just a way to make sure you know about CSS and JS, that you know about Qwik versus React, all of these other things. So it's a good teaching tool for myself. And at least on Twitter, people appreciate the nicheness of like, "Oh yeah, I want to learn about Qwik versus Solid versus React. I want that video in 60 seconds." And it does really well. But from here, I want to look at longer-form content. I also have a Twitch stream. I want to somehow repurpose stuff I do over there into videos so that... Not double-dipping. I am way too busy and want to reuse things if I can. So we're still experimenting with longer-form stuff. But yeah, I definitely look to Fireship for the memes and the shortness. Paul: Because some of the titles, if you just pull them straight off, like, "Why is web dev getting harder in 2023?" That's interesting. Anybody who's doing web dev, that's interesting. Ben Holmes: Yeah. I use Twitter as a pulse check sometimes. I follow Theo and [inaudible 00:35:26] and other people that have definitely taken off in the past year. Whenever they're involved in hot drama, I take a little note like, "I could do a little response to that." But I always add the nuance even though I have no time. I still want to make sure all the nuance is covered. I want to be fair. I don't have super-spicy takes because there's both sides to all of the problems that programmers have, especially, "Is web development getting harder?" It's like, well, yes. Maybe it's not a bad thing. It's because of the industry. And breaking it down in a way that doesn't feel like you're repeating adages that you've heard forever. I guess it's been going pretty well. But yeah, using Twitter as a pulse check is helpful. Paul: Ben, thank you for your time coming on again and talking about the Astro 2.0 updates. Recapping really quick, the collections, the MDX typed markdowns, people are raving about that. Is there something that you feel like people didn't pay attention to in the 2.0 update that you want to throw out there as we're closing out? Ben Holmes: Everyone needs to use Astro SSR. Now that we have hybrid rendering, which is the second part of 2.0, it's so easy to build a hybrid of static pages and dynamic pages now. I built Whiteboard the Web entirely on serverless functions with caches because it just fit what I was building better. It was actually easier than doing things with static builds. So experiment with that SSR. Super easy. You can add adapters for Netlify, Vercel, and just Node and Deno buckets if you want to host it yourself. Look at hybrid rendering. It's very, very cool. I don't want that to get overlooked. But otherwise, yeah, content collections. Do it. Try it. Today. Paul: And Whiteboard the Web, of course, that's your treasure trove of information, knowledge, opinions, blogs, and content, Ben. You mentioned there's YouTube, there's Twitter. What is your Twitter handle if people wanted to follow you? Ben Holmes: Yeah. It's BHolmesDev. Like Sherlock Holmes. So, B H-O-L-M-E-S Dev. I have to spell it out. But I'm that literally everywhere, Twitter, YouTube, TikTok, all of the things. And wtw.dev is the website where I post all my stuff and link out to all those channels. So just go to that website and my stuff is there. Paul: Ben, thank you for coming on. Thank you for your time. It was a pleasure. Ben Holmes: Yeah, thanks. It was awesome.