Transcript

Fred Schott: You know what? Screw srcset.

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave--powered by Zig--Rupert, and with me is Chris--compiled on the client-side--Coyier. How do you do that?

Chris Coyier: Yeah.

Dave: Hi.

Chris: Chris--two buns--Coyier.

Dave: Two buns Coyier.

Fred: [Laughter] Two buns.

Chris: Damn right. Uh... uh... We got Fred on. Fred's a friend of the show. Probably you've been on a number of times before.

We tend to get you on these release days, but it's not intentional. We'd have you any time, Fred.

Fred: We chat. We chat.

Chris: Yeah.

Fred: It's not about the release. It's about the friends we make along the way, Chris.

Chris: Yeah. It just makes good... It makes for good news. And somehow, some way... This is almost a good intro question is, like, you did a good job with capturing the hearts and minds of people with Astro. But why?!

[Laughter]

Fred: Existential crisis on the podcast.

Chris: Yeah. Let's do it.

Dave: Yeah, let's get real existential here.

00:01:23

Chris: For whatever reason, the technology that is the thing that powers your website is just so personal. You know? You just care so much about that. There's all this other tech we use that we're just like, "Yeah. Yeah. Whatever." But somehow that core website builder tech, man, you just can't. You have to.

Fred: I mean that goes back to the days on Snowpack. So, before we were building the Astro Web framework, we were building Snowpack, which I'm sure... I probably came on their podcast to talk about it back when we were working on it.

Chris: Maybe. Yeah.

Dave: Mm-hmm. Mm-hmm.

Fred: It's basically what Vite did; Snowpack was trying to do. Vite just did it better and with Evan, yeah. That was us feeling out the space. Yeah, that was basically kind of the big insight is, like, Snowpack was so low-level, people didn't really know they were using Snowpack, or they set it up once and then they kind of forgot about it.

Very different where we're at now with Astro where it's like, "Yeah, you're an Astro developer." It's a part of your stack. Everything you use is a part of the Astro experience. It's a very odd spot in the stack to be in.

Chris: I suppose, yeah, because you really have to care. You're like, "Oh, how do I do images again?" Then you Google "Astro images" or whatever. And hopefully, you land on the docs. Then you're staring at the little rocket ship in the corner and whatever.

Fred: [Laughter]

Chris: Yeah. I guess it becomes more a part of your day.

Fred: Yeah. it's like the context that you live in if you're building a website. I mean that's our goal. If we're doing the job right, it's this context where Astro does things for you. It makes your life easier. Yeah, I think it's both the goal and also kind of the weird relationship we have with our developers, which we definitely don't take lightly.

Chris: No, and so that's a part of it, too, is the whole community angle of it is pretty strong, which was intentionally cultivated by you. You didn't have to go that route if you don't want to, right? You can just be like, "I don't know. We just make this tech and you can use it." But there'd be little precedent for that. You probably wouldn't be as successful, and not just because community automatically equals success, but because the foundations for that are set.

Fred: Yeah.

Chris: There are word camps all around the word.

Fred: [Laughter]

Chris: People just care about the thing that makes their websites. I don't think you can be the outlier that's like, "Yeah, we also make a website builder too, but we don't care about our users." [Laughter]

00:03:30

Fred: Yeah. No, it's very intentional. I think just part of our early team was just super nerdy about this stuff. But I think it's been--

This is not me dunking on any other projects. It's more work, and I think the road is way less clear to be so open-source-focused. But all the way to our governance, when we have team meetings, it's like Astro core team meetings. If you are a part of our open-source community and you contribute, becoming a teammate, become a core maintainer, you're actually at a higher level of our governance structure than even that employee of the Astro technology company, which we formed to support the project. It's a total flip of the model than most projects with a company or with funding and support tend to use.

Dave: Where's Ben's whiteboard on the org chart?

[Laughter]

Fred: Ben crossed me in Twitter followers and the meme became that he's actually now the CEO. That's actually how open-source projects work. Whoever has the most followers wins.

Chris: Gees.

Dave: Oh, wow.

Chris: Wow!

Fred: Yeah. Yeah. I take my orders from Ben now.

Dave: Great.

Chris: Gees.

Dave: Yeah, that's wonderful. I do like that. That is interesting. Some people who are not paid by the entity, the business entity that works on Astro, are kind of having a larger impact, more outsized impact.

I think React has recently sort of switched in that regard. It was all Facebook. But then, recently, some maintainers have kind of pealed off. But I don't know if their direction... they get to control the direction like they maybe hope from the outside. But I don't know.

Fred: Yeah. I can't overstate the impact of having just full-time resources, which would be... I mean we're lucky now. We have $175,000 a year in open-source sponsorship, so that's totally outside the company that is run by Open Collective, which is a great funding platform for open-source.

Chris: Really?!

Fred: We had a stipend for non-employees. Anyone who is in our community can work... Yeah. We are doing pretty well on the open-source side of things, which again I don't think we'd be focused on without that aspect. We'd probably just be like, "Who cares about sponsorship?" But--

Chris: That's a pretty big number because there's all that Vercel news. I'm sure people are curious about that. But that ended. You were public about the number. It's $5,000, so that was a tiny, little grain of sand for... compared--

Fred: I mean $5,000 every month, that adds up, so that's $60,000 per year.

Chris: Oh, I see. So, it's $60,000.

Fred: [Indiscernible]

Chris: It's like a third of it.

Dave: That's what I'd charge you for my whiteboard.

Fred: [Laughter]

Dave: To be honest.

Fred: Yeah.

Dave: I mean that's... [Laughter]

Fred: The whiteboards get all. It's all going into whiteboards.

Dave: It goes straight... It goes straight to whiteboards.

Fred: It's a whiteboard budget. [Laughter] The whiteboard budget is huge. I'm not good with money. [Laughter]

Dave: Yeah.

Fred: No, that Chrome, we got a great sponsorship in Chrome. Netlify is still giving us money. Storyblock. Yeah, we just have a really great set of sponsors who, again, I think it's mutually beneficial. They help us dog food. They help us build stuff for their platform. Then at the same time, we kind of help get them in front of users. It's a good relationship.

00:06:20

Chris: A harder biting question then is... So, sure. Outside people have more influence or whatever. It feels like that's great and the way it should be. Hopefully, it will go that way forever. It's kind of like that's maybe true when things are going well, and they're going well now. But if things weren't going so well and you needed to make some choices, you might just make some choices. You know what I'm saying?

Fred: [Laughter] That sounds threatening.

Chris: You drive the friendship.

Fred: Wait. Am I walking into Vercel with a bat and just breaking glass?

Chris: No. No, no, no. I just mean, like--

Dave: Where's Guillermo?

Fred: Where's Guillermo?

[Laughter]

Chris: There are some business choices that need to be implemented, and we're going to do those because we're the Astro company.

Fred: Yeah, I mean that's what the governance model... It's tough. I'm the steward of the project, so yeah, there is a lot of control I have by being the steward. It's a responsibility.

At the same time, there was this moment we were stuck in. The company got sucked into the SVB thing. We were with SVB. Our bank collapsed. There was a weekend where I thought that the company was just not existing anymore.

Dave: Yowzers!

Chris: Wow!

Fred: Literally, I had my big, short moment where I was driving to the bank to try and get a cashier's check, something out.

Chris: Right.

Fred: Then I get there, and they never opened. It was the day. I was on my way to Sunnyvale because that's where the branch... It was chaos.

Dave: Yeah.

Fred: Not a good weekend.

Chris: Hmm...

Fred: Yeah, that moment, kind of a moment of clarity on the way back of just being like, "Okay, well, how bad is this? The company dies. We obviously... I lose my job. But also, we have the open-source project, which is... There's this open-source governance structure. It actually doesn't change that much. We'd lose resources, but there's enough if in the sponsorship to support more than one full-time developer. The project would survive."

Yeah, it's just... I don't mean to overstate the impact of it. But it also is definitely a different model, which I think, as much as it can, protect the project from the company. It definitely does exist to do that.

We vote on things like any other open-source project. We're trying to walk that line as much as we can.

00:08:12

Dave: Astro 3.0 just came out, a big release. I did notice, though, in conjunction with this Vercel partner deal, which is cool. I mean that one makes sense because it's kind of like people are deploying to Vercel. We're just going to make it good.

But I did notice some pet Vercel features kind of in the release. Was that just to make people's lives easier. Was it like, "Guillermo is like, "Hey, it'd be really nice if you implemented this feature that we do"?

Fred: Guillermo!

[laughter]

Fred: Guillermo!!

Dave: Yeah.

Fred: No. Yeah, part of that is getting the messaging right. Everything we launched was basically open to any platform to implement. We actually shipped it all so that Astro is agnostic. It's up to the adapter, which you use for your host, to hook into it.

Day two... Day one, we launched with Vercel. But day two, Netlify, Cloudflare. Anyone could go and build these features in. It's all agnostic and documented and API-based. Part of it was just that we'd been talking with Vercel for a while.

There've actually been a couple of bugs that were a little high profile that had happened on Vercel. Someone had a runaway build because of the way that Astro (back in the 2.0 days) had built your site caused one route to call another route to call another route. And it became this loop where someone woke up and their build skyrocketed overnight because they went to bed, which isn't a crime.

Part of it came out of just those conversations of, like, "Hey, how can we fix this?" Vercel, to their credit, pretty quickly shipped... I think that can only happen a couple of times before it just errors versus a recursive forever.

Then we were able to ship a new bundling strategy, which basically each route is now individual, so there wasn't this accidental (because of how your code bundling) a route that you don't mean to hit gets hit, which is what had caused that bug. It all kind of came out of just conversations with them. How can we make Astro better? How can Vercel make their platform better? Then realizing these were features that we all needed and cared about, and the sponsorship just kind of became a natural fit.

Their build API is really powerful for a framework like ours where, yeah, the stuff that we announced -- that bundling strategy, edge middleware, image optimization -- all three of those are APIs that already existed in Vercel that we could just hook into. It was a bit of us just doing the work to hook that in.

Dave: Mm-hmm.

Fred: But it's all stuff that we also then were able to refactor our own codebase to support others to do the same. We made less of a big deal about it because it was such a Vercel announcement, but the Netlify adapter also has that bundle splitting built in now, so yeah. It's not as much of a Vercel-only as it was Vercel-inspired and obviously supported with funding.

Dave: I can imagine there's just enough difference between Vercel ODB (on-demand builders). No, incremental renderers - or whatever. What do they call it? I don't know.

Fred: [Laughter]

Dave: One of them called it on-demand builders.

Fred: There's a three-letter acronym for everything now.

Dave: One of them calls them incremental renderers - or whatever.

Chris: Yeah, it's like it doesn't even build the page at all until it hits once. Then it's cached, which is a nice strategy. It feels like that'll probably last.

Fred: Yeah, and our SSR does something effectively similar where you're shipping an app to Vercel servers or Netlify servers or wherever versus shipping static build. We have that SSG by default, SSR if you need it, model.

00:11:28

Chris: Yeah. I'm curious about that. We didn't even open the show talking about what it even is, but you build websites with it, right?

Fred: [Laughter]

Chris: It's a website builder. Cool. Got it. In my estimation, part of the reason of its popularity is that (you've always said) it's for content sites or at least it excels at content sites, which I believe is highly true. And that the other players in this market were just behind. There are lots of static site generators. But none of them are like, "Well, yeah, but use modern componentry." They're like, "Use whatever."

Dave: My bespoke Nunjux.

Fred: [Laughter]

Chris: Yeah.

Dave: Yeah.

Chris: I actually kind of like Nunjux, but we need to move on. You know? The modern componentry is the way to go. Then to be able to use that and know that the JavaScript is getting stripped away because I don't really need it, but I still want to build with that model. My God, that's just a wonderful way to build websites. A lot of people are comfortable with that. The output is great. Yeah, okay. Great. But that's kind of mostly SSG.

Fred: Yeah.

Chris: Then even in Astro 2, I think you launched SSR, right? Wasn't that the big announcement for 2 and now it's better in 3?

Fred: Yeah. It all blurs together. I think that's right.

Chris: Right. The point is that when you hit an Astro site, it doesn't have to be just an absolutely complete HTML file sitting on a CDN - or whatever.

Fred: Yeah.

Chris: It can now... a Node server. I think it's probably only Node, right?

Fred: Yeah, Node server, serverless with the Lambda. Yeah. The SST, AWS.

Chris: Astro will spin up and go, "I know what to do. I'm going to build that page on demand because I need to hit an API to suck up some content," or something. Then return that page instead.

The reason you would do that, maybe, is because you're selling 20,000 widgets and you don't want to have a build that builds 20,000 pages every time, or it's just a dynamic choice or something. It's cool that it can do that. It does seem like something that a website builder should be able to do. But I wonder if you have a sense of, like, was that a super bid deal? Is it like 50/50, people doing SSG and SSR or something? Did it unlock tons of usage?

00:13:56

Fred: I'd say unlocking new usage is probably the way I'd... So, what make our, not even our architecture unique -- any site could do this, any framework could do this; we just are one of the few ones that actually chooses to -- is, by default, it's a static site build. Then you can opt into SSR. Basically, every other Web framework--

Chris: It's the other way around.

Fred: Is the other way around, exactly.

Chris: Yeah.

Fred: Static is seen as this secondary, like, "Oh, you want a static site? Ugh. Yeah. Here you go."

It's low power. It doesn't support this and that.

Chris: Yeah.

Fred: We really tried to flip that model because that's a model that we were familiar with as developers. I start with a static site. As soon as I need that API endpoint or I want to make a database call.

The big thing that we saw from our own users was just scale. Once you have a certain number of pages, that static build, which you can improve with incremental building. But I think a lot of what Gatsby hit in their days was, like, "Oh, my build takes an hour. Is that okay?" It's like, no, no, no.

Chris: No. Yeah.

Fred: You've passed the threshold. You need... It's just an architectural problem at that point. So, it was really important that we did that early. It was really important that that was available. But it's like any other feature or tool. It's actually complexity, and you should only bring that in if you need it.

Chris: I'm constantly eyeing up, like, what does it really take to do WordPress plus Astro? I have this. I just don't want to write blog posts in Markdown. I don't know. I'm just set in my ways.

Fred: You were one of the OG WordPress in Astro. I think the earliest, using headless WordPress with Atro, was one of your repos, if I'm not mistaken.

Chris: No, I don't think it was because I want it. I'm the earliest to be whining about it.

Fred: [Laughter]

Dave: [Laughter]

Chris: Because I'm like--

Dave: First to whine. Got it.

Chris: Yeah. [Laughter] And I could do it right now. I could spend the afternoon wiring up the two things together. It's not that it's difficult. It's just that I want it to be better. [Laughter] You know? I want to manage my website as if it's just made of WordPress. Then I hit the publish button, and the publish button I have now wired up to hit some cloud function, and the cloud function triggers a build. It changes my homepage and all that stuff. That's not... None of that stuff is out of the box anywhere, as far as I know.

Fred: It's tough because CMSs are solving problems for giant marketing orgs. You've got your big marketing side, and it's like, "All right. My content team needs a CMS," is usually the way it's introduced, not like, "What's the best thing for the developer?"

Chris: Mm-hmm.

Fred: It's a bit of a messy world. Although, I like all the visual stuff, like Builder IO and Storyblock. There's some really cool stuff happening, but it's a bit of a messy part of the stack right now for that seamless experience based on how the developer experience has evolved.

Chris: Right. I feel like I could build it, but then it would be house of cards and only for myself. I'm just going to sit back and wait for things to get better.

Fred: [Laughter] I mean that's a classic thing. Yeah, you realize, when you try and build it, like, "Oh, yeah. That's why it works that way. That's why this is hard."

Chris: Mm-hmm.

Fred: Yeah. "If it was easy, someone would do it," is usually the truth I find.

Chris: I think there's a way with SSR to do it that's like, "Okay, somebody hit the homepage. Well, then go make a request against a WordPress API think. See what the latest posts are and build the post on demand to do that."

But something about that gives me the skeevies. You know? Like, "Really? It's going to do that on every load?" I don't love it.

Fred: I think that's... If I had to guess why most frameworks treat static as second class, it's because there is power in the SSR thing. But as a framework author, doing static images is just like, "Oh, okay. It means you have to have your image optimization happen at build time versus in SSR it's on demand," right?

Chris: Hmm...

Fred: There are certain features like, "Oh, when you're in SSR, you can image. You can user agent sniff to find the perfect image format for that image based on the exact browser that's hitting you." In static sites, you're getting the same one for everyone, so what's your lowest common denominator?

There's good reason behind both of those. But as a framework, how many times is it like, "Oh, that would work in SSR, but we need a good default as well"? You can't. Yeah. There's power and complexity that you kind of have to trade-off between.

00:17:47

Chris: Well, speaking of images, I know there was... not third-party but kind of a separate plugin for a minute, and now Astro Image. Was that a 3.0 deal?

Fred: Yeah, built into Astro after like two years of working on it.

Chris: Nice.

Fred: It turns out images are complicated. Yeah. Who knew?

Chris: Ooh... Tell you what. Now there's a capital I image component. You just import it from astro:assets, it looks like. Nice. I played with it the other day. Pretty cool.

Fred: Oh, nice.

Chris: Yeah, and then you get some stuff, right? What I think is nice about this is I think people are used to... I know images are hard, so can somebody else do it? You know? It seems like the thing that computers should be able to do - or whatever. For the most part, they can, so the checklist is long there.

They're like, "Oh, there's some weird decoding attribute that's supposed to be on there? I don't care. Put it there then."

Fred: Yeah, fetch priority, lazy loading, srcsets. Yeah.

Chris: Yeah, and not to mention just optimizing and serving in the right format itself. So, it looks like the checklist for the image component is some or most of those.

Fred: Yep.

Chris: I played. It looks like it made a WebP for me, which is pretty cool. but it didn't make an AVIF, so it did some stuff but not the other. It doesn't do srcset, I don't think, but it does a lot of other stuff, so it was very pleasant to be able to use.

Fred: I'd be curious to get your take on that because WebP, by default, was an intentional choice based on browser support for AVIF and also a little bit of concern of, like, "Oh, well, some users will get AVIF but some users will get WebP. The developer might see a different image than the user gets." Is that a big concern in your world? It was definitely something we kind of juggled not wanting to ship production assets that didn't match dev.

Chris: I'd want to be in a longer conversation about it looking at all the tradeoffs. You know?

Fred: Yeah.

Chris: Just because I know, also as a software developer, that it's not... I can't just be like, "You screwed the pooch on that one! Where's AVIF?" You know?

Fred: [Laughter]

Chris: I know that they take forever to generate. That could be annoying for people. They're definitely not as fast to crank out, whereas the WebP conversion is much faster. And sometimes it's worse, so you'd need to write code that probably generates both and then picks which one is better. There are certain types of images where even the WebP is better.

Then you're like, "Wow. We did a bunch of work for a worse result sometimes. That sucks."

Fred: [Laughter] I mean this is such a dumb take, but I wish there was just the best image format in all cases that worked for everything.

Chris: Yeah.

Fred: There never will be.

Chris: There never will be, so get that out of your head. It's not happening.

Dave: It's not good. It's funny. The only thing I care about is when I drag it to my desktop. Is it a PNG or a JPEG?

Chris: Can you see it or not?

Dave: Yeah.

Fred: Right.

Chris: Mm-hmm.

Dave: If it's jpeg, that's a failure, critical failure.

Fred: [Laughter]

Chris: I know, but you should blame Apple or Windows or whatever for that, I think.

Dave: Yeah. Yeah.

Chris: Because you're right. I think WebP got a little further. But yeah, I think if an AVIF lands on your desktop, that is a white rectangle of nothingness.

Dave: Just a ghost of an image.

[Laughter]

Dave: A little ghost.

00:20:54

Chris: Anyway, the image component is built in. That's nice. You'd almost expect... You know it took a little time to grow up. You need a good image component in a site builder and now you've got one.

Dave: Just before the image thing -- my ignorance -- if I'm hooked up to Contentful, Storyblock, or something and I'm getting my image from there, and I put that image into my image tag, does anything happen to it? No because it's--

Chris: It's a remote image. I think it does.

Fred: Yeah, we do some optimization. There's also the idea of us just hooking up Astro to optimize from Cloudinary, so you can have it be a local image, but we'll actually pipe it through a URL. Cloudinary basically acts as your proxy, so you don't have to ship Sharp or one of the image optimization services with your site. There's some cool stuff we can do there.

Dave: Is that on my Cloudinary bucks? However they bill you. With florps?

Fred: Yep. [Laughter] Three cloud bucks per image is, I think, the going rate.

Dave: Three cloud bucks per image. Yeah. Cool. That's like Bitcoins.

Fred: Yeah. It's just trying to improve (at that point) just on the image experience. You'll get... I think we force a height and width if you don't get one automatically inferred from the image so that you're going to basically reduce CLS.

Chris: That's so nice.

Fred: Yeah. Just on that reason alone.

Chris: Yeah, exactly. Otherwise, I'd go to the finder or I find some way to measure the image and then go and hand-type my little width and heights. The fact that those just are automatically in there is nice.

Fred: I'm requiring an alt tag even if it's just an empty string. Stuff like that, it's all making sure you're set up for the best.

Dave: Yeah.

Chris: And you get squiggles, right? That's how it enforces it. It doesn't break the build, but you get little squiggles. I love that.

Dave: Is this the point of the show where you want to announce you've ditched TypeScript so that you can get some marketing going?

[Laughter]

Fred: Exactly. It's all about the marketing. What's the hot take I can throw out for Astro 4.0?

Dave: Yeah. We unilaterally ditched TypeScript. Yeah.

00:22:52

Chris: Yeah, well, there's even a combo to images. I noted that image doesn't do srcset yet. I don't think so, right? That's another step now. It'll probably be a future, Astro 4.

Fred: I think we're actually going the picture route for the next improvement we make. There have been a lot of people asking for a picture component and using that as the multiple image srcset solution, basically. But I'd be curious to hear your thoughts.

Chris: I have some, but--

Fred: I keep asking you. [Laughter] I keep asking for your hot takes. You're like, "No, no, no. This is you in the hot seat, friend."

Chris: Yeah.

[Laughter]

Chris: Well, the problem is, if you're going to handcraft some Markup and the only thing you're going to do is change the resolution of it and have multiple versions of the resolutions, that's not what picture is for. That's for srcset. But that's just theoretical. When you're in the seat that you're sitting in, and you're trying to build this for thousands, millions of people - or whatever - that's... You need to approach it from a different angle.

Fred: We have an open roadmap, so we just get a lot of people asking for the picture component and not as many people asking for srcset. We'll probably do both at some point, but that's, I think--

Chris: Yeah, and is it because they don't know?

Fred: Yeah. It's always what we have to juggle.

Chris: They just think of picture as that's what responsive images is? Because it probably is.

Fred: Yeah. Even within our team, there are a lot of thoughts about this.

Chris: But here's how it relates to view transitions is that if you are on one page and your image is real small, like a card because that's the classic example of view transitions is you click a card, the card expands to a larger, full-page thing. If that image is in both places but is in different sizes on both images, that's a known sucky situation for view transitions.

Fred: Mm-hmm.

Chris: Because then you land on the other page and the image isn't there because it's like, "Oh, crap. I'm going to download a different version of that image now." Well, not a problem in Astro because there's no srcset anyway.

Fred: [Laughter]

Chris: It will be the same. It will be the same image. It will look great.

Fred: Yeah. There was some capital D (discourse) about that. Was that over the weekend? Yeah, I don't know if there's a best... Everyone is still figuring it out.

That's kind of the weird thing about new tech. It's like, "Yeah, what should that do? What is the best practice?"

Chris: Yeah. I heard Addie chime in, and he credited Jake, but really this is Dave's thing. Remember? Remember, Dave, you wrote a post ages ago. It was like the 1.5x theorem - or something.

Dave: Yeah, 1.5x hack, man.

Chris: Just split the middle, baby.

Dave: Hey.

Chris: You know?

[Laughter]

Dave: You know what? You know what looks good on everything? 1.5x.

Chris: 1.5, yeah.

Dave: Sure, you got--

Chris: Screw srcset.

Dave: You made lighthouse.

Fred: Screw srcset. [Laughter]

Dave: You made Lighthouse just the smidgest bit mad, but your life got 1000% easier.

[Laughter]

Fred: Could you recut? Chris, could you recut this interview so that that was my answer when you asked, "What about srcset?" Like, "You know what? Screw srcset. 1.5"

Dave: Ooh, yeah. That's good. A little hot.

[Laughter]

Dave: A little hot for the drama. That's good.

Chris: Yeah.

Dave: We'll open that. Chris, open the show with Fred saying, "Screw srcset."

[[Laughter]

Chris: Screw it. Yeah, it's a lot easier if you just stop caring.

Fred: [Laughter]

00:25:57

Chris: View transitions is a native Web technology, which I just find hilarious for you because, after so many times in your life where you're trying to strike something while the iron is hot, didn't (once or twice even). Then all of a sudden, Astro is perfect. Then I feel like view transition is almost... It's not, of course, as big of a deal as Astro itself. But it's like, talk about striking while the iron is hot.

Fred: Oh, yeah.

Chris: You were in a perfect spot at the perfect time for this piece of technology to land, and it has. It's always two-prong. I always make a point to mention this is that there's... And I think it's relevant to what we're about to say.

There's a JavaScript version of it where you call an API, and you say, "I'm about to change the DOM. Okay, I changed it. Now tween between the two things." There's no page transition, which is very cool. But then there's the maybe even cooler one where you need no JavaScript at all.

Fred: Yeah.

Chris: You just use HTML attributes and say this thing is going to... There's a little CSS involved. This thing is going to morph to this thing on this other page. It doesn't even have to be the same component. Unbelievable.

Fred: Yeah. So, for us, this definitely feels like an overnight thing. But we'd been tracking this API since, I think, the earliest days of Astro because for us, for two years now since the project was built, we've been getting this MPA thing. "This Astro, it's a toy, right? You don't have--"

The number one thing that we don't have is always like seamless page transitions. It was always like, "Do we just suck it up and build this? What do we do?"

That's where we're really, really curious because, with browser specs, it's always like, "Is this actually going to happen? Is this going to be a one-browser toy that then never goes anywhere?"

Once this started gaining steam, it was like, "Oh, yeah. Not only is this cool tech. It's also exactly what we need." It turns out biggest weakness into a strength, basically, where this is actually really, really cool that now other frameworks are like, "How do we add our view transition story?"

But it wasn't as big a priority for them because they had all the JavaScript on the client anyway. You can see in all their APIs, they already had seamless page transitions because there was just a JavaScript app anyway. For us, it's a totally new world that this opens up for us.

Dave: That's pretty serendipitous because you probably had an issue a day, like, "Give me a router. Bro, where's my router? Router, bro. Bro, router? Router?"

Fred: Yeah, number one, I think, requested feature for a while.

Dave: I know y'all had started that. I would love to walk through that story, but you started it, what, like five years ago?

[Laughter]

Dave: No. Probably a year ago, I started hearing, like, "Oh, Rasters might get a router."

00:28:34

Fred: Yeah, so that's where it's... Yeah. I shouldn't put too much credit on us. Serendipitous, like, we actually did start work on a client-side router. No APIs powered by the browser. All on our end. And that was really tough.

Again, it's our architecture that just makes that really difficult. At the end of the day, we're just shipping an SPA or we're shipping turbo links, and we're going to do it worse than Rails. There was just no really good answer. That, I think, is where the serendipity kind of came in.

It was like, "Oh, this API is picking up steam. We need it. We realize that no other path is going to come close to what the browser could give us." Yeah. It all fell into place.

Chris: Shipping a router by not shipping a router.

Fred: Being lazy as a developer continues to pay dividends.

Dave: Yeah.

Chris: Super cool. In a way, you don't need to do any. You did do a bunch of work, but you, in a way, didn't have to. But you wanted to have people benefit from this before. Because even in Chrome, the multipage view transition API is flagged.

Fred: Yeah. Yeah, this is where it's getting lost in the noise. Astro is one of the few or the only framework that ships backwards compatibility. So, this is going to work on every browser. I think there might have been a launch day bug where Firefox still wasn't working. But I believe that's been fixed.

The goal is every browser, regardless of actual support, can be supported through this API. Even with Svelte, they've been doing a lot of noise now about view transitions, which is awesome. it's really cool tech. I'm glad they're doing that. but they're shipping just the browser API, so you're only in the browsers that support it. Nothing is going to happen in the browsers that don't. You have to handle accessibility, so if you have a user with prefers no motion, what do you do? That's all being left to the user.

Astro, it's kind of a similar idea to images. We built an API into Astro that is essentially just the browser primitive view transitions. But we're getting rapid NADX that's a little bit... It's going to protect you from the rough edges. It's going to protect you from doing stuff that's accessibility bad. And it's going to have those backwards compatible support.

00:30:27

Chris: Yep. Right. So, it mostly leans on the browser thing and adds some DX around it. Then there's some... I don't think the word exists for it yet because it's tempting to say polyfill, but it kind of isn't really. I don't know that it's a polyfillable feature completely. Tell me if I got this right.

I think, in Chrome, I mentioned there are two kinds of view transitions. There's a JavaScript one and the multipage one. It kind of looks to me that the way it works in Chrome then is rather than needing to have the flag on, it uses the JavaScript one to do the cool transition, which means that it's going to morph and do all the cool stuff.

Fred: [Laughter]

Chris: But it's like polyfilled with itself. You know?

Fred: Yeah. Yeah.

Chris: Like it uses the view transitions API to polyfill the view transitions API.

Fred: Yeah, it's like an onion. Every layer. We're trying to ship one that feels like the eventual zero JavaScript, all HTML and CSS experience.

Chris: Mm-hmm.

Fred: The Astro API feels like that today. Behind the scenes, because so few browsers support that, we're basically using the view transitions JavaScript API, which most modern browsers now support. Then for the browsers that don't even support that, I think Firefox is the only one at this point. Maybe Safari as well, but they signaled support coming soon.

Dave: I think Firefox (at TPAC this last week) signaled they'll do view transitions, I think.

Chris: They'll do it?

Dave: I think they--

Chris: Ooh...

Fred: I completely missed that.

Chris: That's good news.

Dave: I think I saw that.

Fred: Yeah, so for the browsers that aren't even there, then that's where we do our best with JavaScript. We have these built-in slide animations and morphing animations.

We do our best. It's never going to match the browser-optimized, GPU-enabled.

Chris: Yeah. When I played with it, it looked like it just aborted on the morph and went for the fade. So, it's still kind of there, but it's not the same as Chrome.

Fred: Yeah. We do our best, but yeah. That's the beauty of the feature is that we don't have to build a perfect morphing JavaScript library. We can basically let the browser do it and then fall back as best we can.

Dave: Then if some neck beard on a Tor browser is like, "I disabled JavaScript." [Laughter] I have a friend like that. Great guy.

Fred: [Laughter] Nice save. Nice save.

Dave: But they still get a page load.

Chris: Oh, yeah.

Dave: No one was injured. No one was... You know it's beautiful we're getting it on the client or native to the browser and not heaps of JavaScript to make it all work.

Chris: Tremendously little code that you need to do it.

Fred: It's like three kilobytes, basically like a router but powered by the view transition API. I think that's what we ended up shipping.

Chris: Right. But I mean for the author, you write very little code as well. You just write view transition name - or whatever it is - and just plop it on the component.

Fred: It's been so fun. I jumped on a couple of live streams for the 3.0 announcement, and just seeing someone be like, "All right, what is this flashy feature we're going to spend all day on?" Literally, yeah, it's one line.

Chris: Yeah.

Fred: Then it's like, "Oh, my God!" Yeah, it demos so well, which is why I think it's doing so well on Twitter, YouTube, and all these places.

Chris: Yeah.

Fred: It's just so not just beautiful but the experience of adding one line and then that power is so nice.

Chris: And then you're not just learning this API. If you want to write CSS to control it, you do, and you do it in the same way that you will when the actual feature drops.

Fred: We have fade, slide, and morph are kind of the three that we have built in. But then, yeah, you go and style it with your own CSS. Obviously, we can't polyfill that as reliably. I think we just don't at that point.

Chris: Right.

Fred: But in all the browsers that support it, that's going to be totally custom, totally controlled by you.

Chris: Right.

00:34:03

Fred: It's almost like presets. We're basically shipping presets. Do you want a nice fade? You don't want to write--

That is the one thing I'd say about the API that I don't love, and I don't know if there's a better way to do it, but it's a pretty verbose styling API. You needed to find the fade. Are you using 100 milliseconds, 300 milliseconds? Ease in, out. Bezier curves. I really love that we're actually doing a lot of this for you, so you don't have to think about the perfect fade. You just write the word fade.

Again, that's where I think, even if this had full browser support, we're presets. We're styling stuff. We're helping you still with the DX of it all.

Chris: Yeah. Yeah. There's just a lot more. I'm glad to see some writing starting to drop about this because it's pretty complicated.

I saw a really interesting one just yesterday. Imagine a 200-pixel box by 200-pixel box. Then all it did on the next page was stretch to be a full page box.

Fred: [Laughter]

Chris: But the same height. It's still 200 pixels tall. View transitions kind of sucks at that because what it tries to do is, like, "Oh, the next one is bigger."

Fred: [Laughter]

Chris: "I'm going to screenshot it."

Dave: Scale, yeah.

Chris: "And I'm going to scale it bigger." But it scales it vertically too. You're like, "No, no. All I wanted you to do was stretch the width, not the height too." It just has no way to know that.

Dave: I ran into that on my site. I made a container go wider, and it was very mad at me.

Chris: Yeah, right. It scales vertically too. But you can pop in there with CSS and be like, "Oh, don't do that. Height = 100%.

Dave: I had to do... I'm trying to figure it out. I had to do something like min inline size ignore, or something like that. [Laughter] Don't do that. Fit content. Width fit content rather than--

Chris: Sure.

Dave: --just use the image size.

Fred: The big, snarky response to view transitions, which is correct even if I think it's kind of just being snarky and a jerk, is like, "Oh, man. This view transition. The whole Web is going to become chaotic animations everywhere." I'm like, "That's fair, but I think that's also just any feature like this is going to have people trying it out." There's stuff you shouldn't use. If it doesn't look good, you shouldn't ship it. That's always going to be the role above any feature. You can overuse anything.

Chris: It reminds me of, like, "If everybody bought an EV, the power grid would fail."

Fred: [Laughter]

Chris: You're like, "You're right. You're right. If every single person in America bought an EV tomorrow, that's what would happen. But that's such a strawman--" It's literally not going to happen.

Fred: Nate on our team went back and saw all the fud around keyframes when those were shipped in the browser. "Animations are going to be everywhere! This is going to ruin the Web!" [Laughter]

Dave: Oh, yeah.

Chris: Yeah.

Fred: It's like, "Okay... Okay."

Dave: You just ruined it. I mean it kind of did with scroll.

[Laughter]

Dave: Paralax kind of ruined the Web for a bit.

Fred: Dave, I'm trying to make a point. Get out of here with your logic and reason. [Laughter]

Dave: Remember when the paragraph just goes, froow... right into--?

[Laughter]

Dave: Yeah. It activates your lizard brain that's like, "Danger is here!"

Chris: [Laughter]

Fred: Oh, God. Yeah. Every scroll jacking website. Damn it. What have we done?

Dave: Yeah. But no, I'm with you. This is my newest worst opinion is whenever somebody is like, "Oh, that's a cool, new tech. But what if somebody uses it bad?" I'm like, "Yeah, that's like everyone is going to use technology bad."

Fred: [Laughter]

Dave: We do need safeguards. But man, yeah. People do terrible stuff with technology.

Chris: I'll tell you; we need to get rid of background color then because people pick some shitty background colors.

Dave: Leave my tomato alone.

[Laughter]

00:37:40

Chris: Uh, well, there's a Discord, too. I think I've mentioned this before on the show. I do think it's interesting. It's a lot, like Cloudflare does it, too. If you've got a question about something going on with Cloudflare, your best bet is their Discord because it's just full of people and support stuff. But they don't do it nearly as good as you. I feel like it's the prototypical really good Discord. A lot of it is really automated. The help forum, it's like you're encouraged to start a thread and each thread then has a support title. That ends up being searchable.

I'm sure I'm just scratching the surface of just how automated and everything going on in the Discord, but it seems like that's really home base for what's going on with Astro.

Fred: Yeah, 100%. We have an incredible support team, volunteers, DX team. Yeah, there's some really cool stuff going on in our Discord.

Actually, not most people know this. There was an early threading. Before Discord had support for forums, there was a thread bot that a lot of open-source projects adopted overnight. That actually came out of our community.

We needed it. Someone built it. They open-sourced it, and then everyone else adopted it. So, we've been doing this game for a long time. Yeah, I think our Discord is definitely best in class.

Chris: I think so, yeah. Then if there's too much noise elsewhere, you could just tune in for the announcements if you want to. It looks like you use its feature to actually talk to each other and stuff, too, to the community.

Fred: Astro.build/chat is the URL to get there.

Chris: Yeah, pretty cool, and if you really do need help. I'm curious about it. There's so much good content in here that I feel like the temptation for many years in the tech world was like, "You know what we should do then? Forums because forums have URLs, and URLs is what Google likes. That means SEO, and that's good for us. That was the math that people did. You know?

Fred: I think that's right. I still feel like we lose out. It's not even that SEO good. It's more like Discord search bad. The muscle memory of, like, "I should search Discord first for this issue," is just not there for most people. And Discord search kind of sucks, so you're kind of getting the worst of both words.

Chris: Hmm...

00:39:45

Dave: There is a problem, and I'm pro URL. Don't get me wrong. Jeremy Keith, don't get mad at me. [Laughter]

How many times have you been to a wiki and it's just the most out-of-date thing, or a forum, like Stack Overflow or anything? It's just the most out-of-date crud in your whole entire life, and it was intended to be ephemeral, like, "How do I move this ten pixels left?" Somebody is like, "Use jQuery," because that was hot then.

Fred: For every... yeah, yeah, 100%.

Dave: I feel like Discord serves this on-demand need for knowledge that does not necessarily need to be permanent archive, but permanent archives are good. I'm saying I'm criticizing Stack Overflow, but how many times has it saved my bacon? Just some weirdo in 2010--

Fred: [Laughter] Yeah, there are some really cool projects. There are some really cool projects that are turning Discord forums into URLs, so trying to give you the best of both worlds.

Chris: Hmm...

Fred: Essentially, just the SEO juice for a Discord thread that was helpful to someone.

Chris: Well, I could see that being nice. There are just no cool forums anymore. I think you just lose a lot of, like - I don't know. I'm hesitant to say younger, but fresher, hipper devs that are just not going to participate in your stodgy ass old forums. They're here in your Discord because that's what the people use now.

Fred: Live chat is absolutely the future and, I think, even the present. But there's still something about, like, "Well, why do I have to go to your Discord and search there?" Where like, yeah, Stack Overflow will never be... I Google the problem and it's the top result. That's the best.

Yeah, the forum idea, I miss forums, nostalgically, but I do think live chat is where it's at. It's still such a walled garden, which I think Discord is kind of incentivized to do. I don't know. It feels like there's something missing there.

Chris: It prevents you from bad, old content too, though. You know?

Fred: Yeah, that's true.

Chris: If you look, "How to get the last item in an array," not going to get super good info from Google anymore. Not that that's this big problem because you'll probably find what you need, ultimately. But I don't know. Astro is young and changing, so having not old threads.

00:42:00

Fred: I'll shout out a really cool project called Kapa, which we were actually one of the first adopters of. We didn't create it, but it's this AI for your Discord threads, basically. I'm usually pretty skeptical of AI stuff, but this one is really helpful. It's basically--

Chris: Hmm...

Fred: How you present it to users is really interesting. An AI bot trained on our docs, trained on a lot of old support threads that were successful. You post to the forum, and it'll be the first response, "Hey, here's the answer that I think is right."

We've been pretty skeptical about just throwing AI in your docs and everywhere, but in this use case it's like the user is already stuck. They're already in trouble. It's this answer or they wait for an hour for someone to get to them. Why not give them something to try? If it doesn't work, they're still in the exact same spot. If it does work, great, they've unblocked themselves.

This is one of the few uses of AI that we have enabled that has been really, really productive. A first line of defense. If someone can opt into this, they are able to get an answer from our doc site, basically, instead of from a person.

Dave: Wow. Yeah, I mean--

Chris: It's called Kapa?

Fred: Kapa.ai, I think is the domain. Yeah, a really cool team. They're doing some awesome stuff. They're in a lot of other... I think they're in the Next.js Discord. They're in Theo's Discord. They're in a bunch of other places.

Dave: No, that's nice.

Chris: I just watched this movie Gran Turismo last night where the video game players of the game become real racecar drivers. The bad guy is named Capa.

Fred: Oh, no.

Chris: So ... on that one, Kapa.

Fred: A brand disaster.

Chris: Yeah.

Fred: Or a marketing opportunity.

Chris: Yeah. [Laughter] Perhaps.

Dave: I can only think of the mythical Japanese water beast, the kappa. [Laughter] Anyway, that's--

Chris: Oh, gees.

Dave: Yeah.

Fred: ...Dave. All right.

Dave: It's like a yokai, a mythical beast kind of thing. But anyway--

00:43:45

Dave: Well, Fred, do you have any leaks for us?

[Laughter]

Fred: Oh, you tricked me. I have to answer it truthfully.

Dave: Yep. That was on the contract.

[Laughter]

Fred: Damn it!

Chris: Well, it's not too big of a leak because you announced it yourselves that there's some secret data something cloud storage. What did you call it, Astro Studio? Do I have that right?

Fred: Yeah! Yeah, we have our first hosted service coming out, which is really exciting.

Chris: Yeah, I notice you intentionally said it's not a hosting company. I don't know. It's literally the first sentence of your thing.

Fred: [Laughter]

Chris: Well, because I wonder. In the past with things like Gatsby and stuff, it almost became a joke, right? They're like, "There's only one way to make money, and it's to be your own host," or whatever.

Fred: Yeah.

Chris: I'm sure you were cutting that off at the legs.

Fred: That was kind of it. We wanted to tease it, but we weren't really feeling ready to show it off entirely. It's still a little ways away, but we wanted people to be aware that we were doing this. We're starting to see a lot of, like, "Oh, these companies. You've got to watch out. They're going to try and sell your data or install a Bitcoin miner in Astro." We were trying to just... It had been a while since we'd given people an update, and we're just trying to fill the void a little bit.

Chris: Yeah. there are inevitable questions about how does the Astro company make money.

Fred: Yeah, exactly, which is like anyone, I would have. Yeah, doing a Gatsby is kind of the big criticism of what everyone thought we were going to do. It was like, "They're just going to do a Gatsby and it's not going to work. And Astro is going to die as a result." That was, I think, everyone's fear.

Chris: Well, yeah, sure. Or you could do a Vercel and turn out pretty good. [Laughter]

Fred: Yeah, but even in Vercel... Okay, now you're--

Chris: I know. That's a different company.

Fred: I would argue that Gatsby was trying to a Vercel and that was the big mistake.

Chris: Oh...

Fred: You're just trying to beat Vercel at Vercel. Vercel is really good at being Vercel. They're not some stodgy enterprise. They're doing a good job.

Yeah. Basically, we were just trying to fill the void with some excitement and hype, but basically making sure people felt like we were going to be good stewards of this project. That was really in the vacuum of what this actually is going to be, making sure people felt like we weren't going to exploit our current users. We weren't going to build something that goes against their interests, and really trying to hit, like, this is a tool for Astro developers. It's not going to exploit you. It's going to be something that helps you. And if you don't want to use it, you don't have to.

Chris: Yeah.

Fred: It's the Laravel model. It's the Tailwind model. We're just trying to go that route versus the Gatsby model.

00:46:10

Chris: Okay. Well, since you can't say anything else about it, we'll just do a dramatic reading of what you already have said about it.

"Astro is launching a hosted service in 2024. It's not a Web hosting company. It's not a CMS. It's something entirely new for the Web ecosystem and it will be available exclusively for Astro. We're calling it Astro Studio." Yeah.

Fred: Chris, can I get your Inner Worlds movie trailer voice?

Chris: [Laughter]

[Inner Worlds, Outer Worlds trailer music plays]

Chris: Astro Studio is a globally distributed edge data platform built for Astro. Connect any new or existing...."

Fred: [Laughter]

Chris: It loses it when it gets into the technical details.

Fred: [Laughter] Sorry.

[trailer music stops]

Fred: Oh, it's perfect.

Chris: So, you connect an Astro project to a hosted database in seconds. So, you are saying what it is. It's fricken' data storage. It's fast everywhere.

Fred: Yeah. Yeah.

Chris: Yeah?

Fred: I thought it was pretty explicit, but we got a lot of people being like, "What is this?" I think... I don't know. Yeah, that's what it is.

Chris: Okay. It's a database. But that remains to be seen. A KV store and a PostgreSQL are pretty different things.

Fred: Yeah, exactly. Exactly.

Chris: So, what is it?

Fred: I think that's what people are looking for. Yeah, early 2024 is definitely the target. I think we say that at the end of it, so this is coming sooner than people think. Yeah, we'll have some teasers.

Chris: Yeah. It's interesting, though, because then there's a database. Then it begs for stuff like ORMs and CMSs. So, if it's not a CMS, which that's the second sentence of this thing, then you're saying somebody else write the CMS, kind of. That'll be an interesting place to be because you're like, "Maybe that's cool. Maybe multiple people will make CMSs. Then you'll buy the better one."

[Laughter]

Fred: It's the same thing with Vercel where it's like, "We're not going to be--" We're trying to build something very new here. I think that's the TLDR. We're not going to compete with Vercel. We're not going to compete with Contentful or Storyblock or anyone. They are really good at what they do, which is building the CMS.

Chris: Yeah.

Fred: I think what we're trying to basically do is get everyone's expectations a little lower--

Chris: Oh, there you go.

Fred: --in terms of, like, this is going to be a primitive. This is going to be a low-level thing that you can choose how you want to use that and how you want to build on that.

Chris: Oh, right, because... Yeah. You can't just be like, "We're building a CMS," and be like, "Really?! That's a hell of a pivot then."

Fred: Yeah. Enjoy the next two years of just trying to basic features. Yeah. What Storyblock has done is super impressive.

Chris: Well, I can tell you a little something about rewriting everything that you've done so far.

[Laughter]

Chris: It really doesn't go fast.

Dave: Hopefully, you like internationalization, would be my--

[Laughter]

Fred: Yeah. Oh, my God. There's so much.

Dave: I hope you love it.

Fred: Yeah. I think that's, again, where we're trying to ... doing a Gatsby. I don't mean to be so mean with that, but it's just like I think it's almost representing naively thinking you can do something better than someone else. These are complicated tools with a lot of reasoning behind why they're built.

WordPress is just... WordPress is WordPress. It's 50% of the Web or whatever. They're no way we're going to beat WordPress at that game.

Dave: It's sort of operating in your competency, like build versus buy - or whatever. Not that there was incompetency on the Gatsby side of things, but just like if you're a React site building company and you're like, "No, we do servers," that is different.

That's like, we even call them different things. We call them front-end and back-end. They are different jobs.

Fred: Yeah.

Dave: You need different staff. You need different everything. You don't even need back-end developers. You need systems engineers and Linux dorks. It's so different.

00:49:54

Chris: Let's just speculate then without Fred. You have to be quiet.

Fred: Yeah, I've said too much. I'm zippering up.

Chris: Dave and I will speculate what could be built with this. CMS is one thing, but they're not going to do it. Somebody else. You could do it. You're not going to out WordPress at WordPress, but somebody could build a CMS that's right for their company that's smaller in scope and scale.

Oh, my God. Fred is really not going to say anything.

Dave: He doesn't like it. Yeah.

Chris: You could... I would say comments is a big one. You could build your own comment thread thing on an Astro site because obviously anything that's user-generated content is a fit.

Nothing? Fred is still stonewalling us.

Dave: Yeah. You want to get into the products realm. You want to get into... You have some kind of--

Chris: Products? Yeah.

Dave: Hmm... But my wonder--

Chris: [Laughter]

Dave: They're good at adapters, right?

Chris: Adapters. Right.

Dave: What if it's kind of like an adapter, you know, layer to, like, for CMS-y kind of thing? You know that might--

Chris: Yeah.

Dave: So, like, they have a good API for it, and they kind of--

Chris: [Laughter] Fred is now juggling for the audience.

Dave: Juggling and solving a Rubik's Cube out of nervous energy. This is great.

Chris: [Laughter] Yeah. Okay. All right, well, that's Astro Studio. We're going to find out in a couple of months, I assume, what that is. Early... At some point in 2024. It's still 2023, remember.

Fred: I would say there'll be more info coming out this year.

Chris: Yeah.

Fred: Definitely got some stuff planned for the end of this year to unveil the curtain a bit.

Chris: With all the details.

Dave: What if it's just like a photobooth in San Francisco that you could go to?

[Laughter]

Chris: That's what it is? They're getting into the--

Dave: It's like Fred with a camera taking wedding photos... Yeah.

Fred: Any of y'all want some databases?

Chris: Yeah.

[Laughter]

Dave: It goes to a database.

Fred: [Laughter] Give me your photos. I'll take good care of them. I promise.

Dave: Yeah. I have an index DB on my iPhone.

Fred: Yeah.

[Laughter]

Dave: It goes right there.

Fred: Just a bucket with S3 written on it.

Dave: Yeah. [Laughter] Polaroids out, and you just drop it in the big ol' trash can. That's good.

00:51:51

Chris: Well, what I like about it is it literally says database. We can move on from this in a moment, but if you were to just ask me, "What's a way?" If you had one year, you're trying to get... You have a startup and just definitely make some money, the answer is, "Have people's data." One way or another, get your hands on some users' data.

I'm not saying being nefarious about it or be a jerk or something. But when you have data, that is a good startup business to be in. I'm going to applaud that choice because I think that's a good one, a good place to be.

All right, so we talked about Astro a bunch. I mean we're coming up at the end anyway. Was there any other... anything juicy happen this week outside of that world?

Dave: No, I see tweets that Astro is running on Bun. That seems incredible.

[laughter]

Chris: Could it?! Why not? It's almost Node-compatible, right? Have you even tried?

Fred: It's a funny thing about that. But yeah, I think we were featured in the blog post as one of the launch day supporters.

Chris: Oh, really?

Fred: Yeah, it's very much a part of--

Chris: Oh, it already works. Oh, that's good.

Fred: I think therein lies the Bun's real focus right now. I get the sense, like, if there is a bug, report it to Bun, and they're going to fix it. It's, I think, where they're at right now.

Dave: Yeah.

Fred: Which is, yeah, I think they're 1.0 just came with a ton of traffic and people trying it in new ways. So, I think that's where they're at right now. But simple sites, even, I think some pretty complex ones do seem to run pretty well on it, so yeah, kudos to them for essentially Node compatibility, which is not easy.

Chris: Yeah. I kind of like don't get how it would matter for Astro. You use Vite to build and Vite uses its own stuff. How does Bun even fit into that story? It doesn't really.

Fred: There's an invisible drop-in, kind of. I mean there's some stuff we could do if we really went only Bun, but that's not anything that's on our plan.

Dave: They have a different read-write architecture, right?

Fred: Yeah.

Dave: Instead of fs.read-sync-file, it's like bun.file or get or something.

Chris: I heard that, yeah, which seems good. Right? I heard it in the context of being applauded as, like, "Oh, well, at least there's not eight ways to write a file now. There's one."

00:54:06

Fred: It's so funny. The more mature Bun and Deno get, the more I realize they're basically doing the same thing, which is backwards compatibility for all the Node APIs. Then ship the new thing that you think is actually how it should work. For Deno, that's TypeScript. For Bun, that's JavaScript. But it's still a new API for, yeah, everything read, write, security.

Chris: Right, dude.

Fred: They have a bundler built in that's basically an esbuild competitor. Yeah, there's just a ton of new stuff to play with.

Chris: It is vendor lock-in, but you can't blame them. The second you write one API that doesn't work on any of the others, that's what vendor lock-in is.

Fred: Yeah. I'd be really curious to see how they... Yeah, what does this world look like where it's not just Node? So much has been Node vendor lock-in, but everyone is like, "Yeah, but it's Node."

Chris: Right.

Fred: It's basically the platform, and now it's like, "Well known."

Dave: It's the environment we all work in. Now that truth is unraveling.

Chris: Yeah.

Dave: A bit.

Chris: It used to seem so big, like NPM seemed so big. You're like, "They're the unstoppable beast." Now they're like, "Oh, we're just... There are two people at NPM anymore." Now that happened to Node, too. They have one person on Node.

Fred: And only on security. Oh, my God. That was so mind-blowing to me. There are one or two people working on security only full-time, and then zero other full-time resources.

Chris: Yeah, it is a little surprising. Is it because they chose not to monetize it in any meaningful way?

Fred: It's also... I feel like the open terraform stuff has been almost a stark contrast to that where, like, "All right. Terraform is going away. Crap. What are we going to do?" Overnight, there are 20 dedicated full-time resources over 5 years committed by different companies.

Then you look at Node has a foundation already and zero full-time other than one company gave one very specific sponsorship for that one security.

Chris: Right, and that one person seems tenuous and not into it.

Fred: Well, yeah. The biggest steelman you can say I that they have someone full-time on security through NearForm, I think, is the company. They are covered, like, I'm not worried about the security of the platform. But the growth of it and keeping up with Bun, Deno, and all these, I'm much more skeptical than I was 24 hours ago about Node's future if there's no one full-time working on it. That's just so shocking to me.

Chris: Yeah. Isn't it? Does Amazon--? They're like, "Oh, we have this product that makes tons of money by helping you run Node stuff in various ways, and we make a billion dollars a second."

Fred: Yeah, even just from a self-preservation. Yeah. Amazon doesn't want to move to Deno or Bun. I would assume they're lazy. They just want to keep the Node hierarchy strong.

Chris: Yeah.

Fred: How are they not giving one resource to play catchup is very surprising.

Chris: Wow! Indeed. Maybe there's more to this story, but--

Fred: It does feel a bit like that, I will say. I don't want to...

Dave: Hmm...

Fred: I have specifically not tweeted about this.

Dave: Maybe we pivot this to a murder podcast.

[Laughter]

Dave: It was then that I knew there was more to the story.

[Laughter]

Dave: Dun-dun-dun-ta-dun-dun-dun....

Chris: Hell yeah.

Fred: Yeah, there could be. I'm specifically not tweeting or making a big deal about this, but it is shocking. Yeah, maybe there's more to it. Yeah, kind of wild.

[Meditation sounds playing]

Dave: One person maintaining Node... in a world where everyone depends on this.

[Meditation sounds end]

Chris: [Laughter] All right. Well, we did it. We'll have you again. Hopefully, it's before Astro 4, unless that's in two months. But it seems unlikely.

Fred: The early existential crisis we started on is, you know, "Maybe I don't think I have anything worth talking about unless it's Astro. Maybe Astro is the mask I hide behind."

Chris: Hmm... [Laughter]

Dave: [Laughter] That's good.

Chris: That's a pretty cool mask. You're good, I think.

Fred: [Laughter]

Dave: That's a good clip for the older murder mystery, too. That's good.

Fred: He took off the mask.

Dave: He took off the mask.

Fred: And he's covered in blood.

Chris: Yeah.

Dave: Yeah. All right, well, hey, Fred, thank you so much for coming on the show. For people who aren't following you and giving you money, how can they do that?

Fred: I am @fredkschott on Twitter. Yeah, @astrodotuild is also on Twitter, all spelled out, dotbuild.

Yeah, a shout-out to the amazing people on our team. Matthew Phillips worked on the view transitions. Erika worked on the images. And, yeah, our awesome community of support, DX, docs, everything, all on our Discord, which you can go to astro.build/chat to find.

Dave: Awesome. Well, thank you, and 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 or Mastodon right now and over and then... But where the party is at is in the Discord. So, join us on the D-d-d-d-discord, patreon.com/shoptalkshow.

Chris, do you got anything else to say?

Chris: Oh... ShopTalkShow.com.