553: TypeScript, DX, GripeScript, and Astro v2 with Fred Schott
Fred Schott stops by to talk about TypeScript, what DX means in 2023, a bit of GripeScript, and being transparent about what Astro is good at, and what it's not.
Time Jump Links
Episode Sponsors 🧡
Transcript
[Banjo music]
MANTRA: Just Build Websites!
Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I am Dave--incremental render--Rupert and with me is Chris--client-side--Coyier. Hey, Chris. How are you doing today?
Chris Coyier: Oh, I don't like my name.
Dave: [Laughter] Sorry. I gave you the less performant one.
Chris: That's okay. That's okay. We've got front-of-the-show Fred on. What's happening, Fred?
Fred Schott: Wait. What's going on? No nickname?
Dave: Oh, let's see.
Chris: [Laughter]
Fred: I feel cheated.
Dave: I think you're Fred--server-side--Schott. I mean--
Chris: Yeah.
Fred: Oh... Let's go.
Dave: I feel like that's it, right? Yeah.
Fred: I love it. Yeah. Happy to be here. Thanks for having me on.
Chris: Mm-hmm. Just as a recap, I knew Fred from back in the Skypack days, which is their little NPM thing or IP where you could link to stuff from NPM that was already kind of prebuilt. It was very useful to CodePen. But that's okay. There's some successors in place now that are doing a good job with that and kind of don't blame you for passing the torch on that one.
Then before that, Snowpack, which is another one of those things that was before its time of, like, if I want to pull stuff from NPM. Make your build process a little more efficient and stuff. It was a genius thing but, for a while, you had a bad habit of being a little ahead of your time.
Fred: [Laughter]
Chris: I think I've heard you say that before.
Fred: Being early is the same as being wrong - it turns out. Yeah, exactly.
Chris: Yeah. Right. Now, finally, threw the dart at the bull's eye with Astro. Not too early, not too late, and have caught the swing towards, "You know what? There's too much damn client-side JavaScript. Let's strip all that away," but it's not because we hate JavaScript. It's because we can be more efficient with it, et cetera.
Astro being really a front-runner in that kind of next-gen of, I guess, JavaScript framework / static site generator kind of things that embrace that.
Fred: Yeah, "You don't need Next.js for everything," is kind of the pitch. There are things--
Chris: [Laughter]
Fred: You can explore other--
Chris: Yeah.
Fred: There are other options.
Chris: There are other options. Yep.
Dave: Bold choice. Bold statement. Bold.
Chris: I always feel like I'm well suited to talk about it because I'm a big fan of Astro and the Astro approach and have built some sites in it. Not anything massive, but enough to know my way around and love the concept of it. I can't, with the writing. When I have to work on PHP sites, I do it all the time, you know, in my WordPress life. I just get so annoyed that it doesn't take the same component approach as JavaScript frameworks do.
Pick one. Any of them. They're all better. I like the idea of passing props around and having my Prettier make it look nice and all that stuff, but don't like the fact that I'm forced into client-side JavaScript. And Astro says, "Oh, you can use any of those if you'd like."
Fred: Yeah, that's the pitch. Can we bring the modern component dev experience to a server-side vibe, to a Rails, PHP, Django kind of server-rendered vibe? Yep, exactly.
Chris: The irony being that you're going to do that. To me, you're going to find that just using Astro components is probably the way to go. Anyway--
Fred: You would have no idea. You would not believe how many Web components we started authoring as well because if you just have this HTML server language, well, why not just throw in a little script tag and register a component?
Chris: Yeah.
Fred: That was a huge surprise for us on our own team is like Web components are kind of fun to work with in Astro. Coming from the Palmer team, I say that with all the respect of what Web components are. But there's a kind of difficulty that is not there in Astro, I found.
Dave: Yeah. Astro's innovation, I felt like, was kind of on load, like, "Render this late," or "Do this late," "This is script only." Kind of by nature of a Web component right now, you can pre-render whatever. But right now, they're kind of all late. [Laughter] They're all kind of all on load, and they're all very small because you have the component lifecycle as part of the native platform. So, it doesn't even come with the extra lib. It's just purely Web component.
Fred: Yeah. Yeah. Then of course, they've got React, Svelte, Vue. They're all there for you. As soon as you want to dip into that world, Create React App on the page.
Dave: Well, and that is almost one of the easiest ways to even play, right? I don't know. I don't want to spin up Svelte Kit just to play with Svelte - or something like that. I can just plunk whatever.svelte component in my Astro if I want.
Fred: Boom.
Dave: Yeah.
Fred: I wanted to bring this up because we're going to move past it and I'm never going to remember. Chris, have I ever told you the first interaction we ever had?
Chris: Ever had? I can't remember.
Fred: You weren't aware of it, I don't think. It was through another person. I've either told you this story like five times and you're going to be like, "Fred, shut up. You've told this to me."
Chris: No, I don't. I can't remember now.
Fred: Cassidy Williams and I were at a conference together. We were both speaking, and my talk was on -- this was Pica at the time.
Chris: Pica!
Fred: I was talking about how Pica was really all the tech of the bundling, the Skypack, all these tools that we were playing around were really about this idea of the great divide. I quoted you.
Chris: Hmm...
Fred: I had a slide with your post on it, and it was a big part of why I found this work so interesting was because I saw this move of complexity kind of encroaching and exactly what you put so well in that post. It was like splitting our community in two, the JavaScript side and the everything else side.
And so, I was sitting with Cassidy after I gave my talk, and she's like, "Oh, my God! It's so cool! In our Slack, I just slacked Chris a photo of you. And he said, 'Oh, cool. Awesome.'"
[Laughter]At that time in my career, I was like, "Oh, my God! Chris knows who I am!" I was starstruck. It was so funny.
Chris: Ah... I was waiting for it to be much worse than that. Be like--
Fred: No, no. You weren't aware. [Laughter]
Chris: "He told me my talk sucked," or something. [Laughter]
Fred: Yeah. You ghosted me forever. No, this was a degree of separation. But I remember having worked on that talk for a long time and thinking about this space, and your article was very much a touchstone in that.
Chris: Nice.
Fred: That vision.
Chris: Yeah. Yeah, Cassidy. That's great. Yeah, we worked together for a while. She was at CodePen for a while. Maybe it was during that period.
Well, that's great. Yeah. There's some interesting Astro stuff to talk about with 2.0 and stuff, relatively recently, but there's some other stuff we wanted to get into, too.
Maybe we should do the TypeScript one. I think that's particularly juicy for the top of the show. Just this week, it's been a little dramatic. Probably thanks a little bit to Kent C. Dodds declaring JavaScript dead.
Dave: Uh, you have to learn TypeScript or eat shit, I think was his exact phrasing.
[Laughter]
Fred: Yeah. Actually, I think that's a direct quote, right?
Chris: [Laughter]
Dave: Direct quote from--
Fred: And a little bit unlike him.
Dave: Yeah, very nice guy, Kent C. Dodds, came out a little hot. I think we were all surprised.
Chris: I've heard it before, though. He's just kind of saying, "Look. It's won." But he was declaring it as an educator that he's going to not do education. I think there was some kind of little caveat in there. But for the most part, he's just going to teach in TypeScript.
That's a little near and dear to my heart because I had to make those kind of choices at CSS-Tricks, too. When we publish an article, is it just author's choice? Can they assume Post-CSS? Can they just write it in Less if they want to?
We probably made a weird call in that, generally, if somebody wanted to use Sass, that was okay. But we kind of drew the line there in that nothing else. Ideally, you'd do everything in just regular CSS because then it's applicable to anything. If somebody were to be using Less - whatever - CSS is valid Less too. They could use that or refactor it how they wanted to.
Picking a specific technology for education is tricky. For a long time, I felt it was more en vogue to not use TypeScript because it was a significant hurdle. I'll tell you, in my experience as a developer, I have a memory of going to a hack-a-thon once where we had an idea for a hack-a-thon, but instead, we just got TypeScript set up. And we didn't even finish that. And then we all went home.
Dave: [Laughter]
Chris: I was like, "Well, that was a huge failure."
Dave: Was that for charity? Please tell me it was for charity because that's exactly... Yeah.
Chris: Oh, it was something for the city of Bend or something we were trying to work on and we didn't--
Dave: Oh, good. Yeah.
Chris: Yeah, we didn't get anything done.
Dave: Public service.
Chris: But that was a number of years ago. It's since gotten a little bit easier. And I've started to soften my view on it a little bit because there's very little JavaScript that you write and certainly not none. Don't quote me weird on it, but so much JavaScript gets processed anyway. There's something that it's going to go through. To just make TypeScript an additional one of those or have it be the thing that's processing your TypeScript isn't that weird.
Fred: Yeah. I think Kent's audience is very front-end focused and, yeah, any front-end tool that I'm aware of supports TypeScript with zero setup. That's very different than if you were sever-side Node. Yeah, that's a whole extra step that you're then forcing your education content to require. Like you said, I can spend a whole day trying to set it up if you're not familiar.
Chris: It's changed. Dino is just -- you don't even do anything. You just ship the TypeScript. It's amazing.
We were looking at Vitest the other day. It was kind of the same thing. Your tests are just .ts files. You don't even see .js files.
Fred: Yeah.
Chris: You're like, "Holy crap, that's cool." The tide is changing a little bit in that the expectations for TypeScript are little bit better.
I know it's near and dear to you because I believe I read in some of the Astro blog posts recently maybe about the 2.0 release, that you've embraced it a little more heavily than you have in the past, so we could get into that a little bit. Talk about it positively; I think you even retweeted Kent. Yeah, a little implied endorsement there, huh?
[Laughter]
Fred: I have a lot of thoughts on it. Yeah, did you all see the State of JS survey results on this exact question, "Are you writing JS or JS?"
Chris: We did.
Dave: Yeah.
Chris: We kind of tried to avoid it because it was like every podcast in the world was covering it and it's a little bit like it's dudes with extra time on their hand that filled that out.
Fred: Yes.
Chris: Yeah.
Fred: No one talks about the bias of that audience, but I do think that it is still, in a State of JS survey, to have the majority of people writing all, 100% TypeScript or mostly TypeScript that, no matter what the bias, that's just a wild stat to me. Yeah.
Chris: Mm-hmm.
Fred: I think there's got to be something there, and it's a shame because it was the first time they ever asked, so you can't compare the trend. At least then you'd see the kind of momentum of that trend.
Chris: There's been other surveys in the past. Years ago, we were starting to see TypeScript be way higher up these type of surveys than you'd ever expect.
Fred: Yeah.
Chris: It was 50% or something three years ago, and you're like, "Wait. What?!" [Laughter] Yeah.
Fred: Astro takes this really unique approach because we have our own kind of like Svelte or Vue. We have the .astro component, so that's where you get to do all this cool -- you know it feels like HTML, but it actually is a component like React or Svelte, so you get... That's us drawing that kind of DX of modern dev with an HTML templating language where we're combing those two things.
There's this place in an Astro component where you can write server-side code that's going to run on the server. We give you that as essentially this little, "Hey, go write your code here."
Chris: With fences, yeah.
Fred: What's really unique about Astro is that, yeah, the code fences. Exactly. And what's unique is that that is TypeScript. It's not like, "Oh, you can opt-in or opt-out." It is TypeScript. It is always on TypeScript.
And we get away with that. If anyone listening is like, "Oh, I hate TypeScript. Turn it off," TypeScript is a superset of JavaScript. Because we're handling all the logic of that, the building, the bundling, the transpiling, if you just want to write JavaScript, you can actually do that. It will fully be supported. You set your TS config settings on low. We'll default to that for the people who don't want it.
Chris: That's true and great, but what about...? That always seemed conceptual to me. It's like, "Yes, it's a superset," but it's so encouraged that you have no implicit any turned on and your ESLint stuff. That, right away, then it's not because all your JavaScript is a bunch of any everywhere and it starts bitching at you. No, it's actually not. You know?
Fred: Yeah. Yeah. No, it's kind of on us to then actually practice what we preach there. In our setup, in our create Astro, to get started, NPM Create Astro is how we push you.
There's a question there. Do you plan to write TypeScript?
Chris: Oh...
Fred: That's how we can ask it. If you say yes, you're going to get the strict settings, any warnings, all that stuff.
Chris: Mm-hmm.
Fred: If you say no, we're going to give you the most out-of-your-way settings. Yeah. Implicit any, go for it - whatever you want to do.
Our goal would be that if you saw a red squiggly due to some sort of TypeScript-only thing, that would be a bug.
Chris: Oh, okay.
Fred: That's the line we're trying to walk. It's tough. It's not perfect. But that's the line we're trying to walk.
If you don't like TypeScript, you're never even going to notice that it's actually TypeScript behind the scenes.
Chris: Yeah, that's nice. You are on a weird tightrope because there's the code that you write as Astro contributors. That should just almost definitely be TypeScript because you're going to get all the safety crap of it. Then as I consume your APIs, I get all the cool stuff like what does this function need?
Fred: Yeah.
Chris: That DX experience is absolutely better. But you're also authoring a thing that's saying, "Now please write code for us."
[Laughter]
Chris: Which is a different kind of situation.
Fred: This is much more fascinating. This is where I think this all heads, actually. I was a JS World Conf last week in Amsterdam and gave a talk. I don't think it's public yet. Maybe by the time this comes out.
Chris: Hmm...
Fred: The whole talk was on, like, if JavaScript is eating the world. That was the meme of ten years ago. TypeScript is eating the world is the meme of right now.
What we're seeing now is TypeScript APIs, like type safety seems to be the thing that's coming next. What I find so interesting, so what I mean by that is the big feature we launched in Astro 2.0 was when you're working with Markdown, we're actually going to give you a type-safe API. You put a typo in your Markdown that you're fetching it from, you're going to get an error. If you say, "Give me the blogpost.title," and you misspell it or the title doesn't exist, we're actually type-checking all of that so that you don't get that weird, undefined, not found error.
It's actually, if one of your Markdown posts doesn't have the property you expected, we will warn. We will error. We will tell you exactly where to look.
Chris: A little tradeoff, though. Does that mean I have to write a schema?
Fred: Yeah, exactly. Exactly.
Chris: It's a little bit of extra onus on me.
Fred: You don't have to.
Chris: You don't have to.
Fred: But to get that feature, yeah, you're basically saying, like--
Chris: Okay.
Fred: "I will give Astro a schema," and then it will verify at the file level so that you can then trust that it's there when you go into the template.
Chris: Is schema the right word? I just said that.
Fred: Yeah. No, that's literally how we do it. Yeah.
Chris: But is it actually a TypeScript type?
Dave: No, it is this really cool library called Zod, so this is where I think this all goes because closing this loop, closing the circle is that you don't actually have to write any TypeScript still in this story. You're using this library called Zod. You're using our APIs. We're doing the work to hook it all up with TypeScript for you. Even the user who never wants to write TypeScript is still going to get that type safety, that auto-complete.
Chris: Mm-hmm.
Fred: As they start typing the collection name, they're going to get the dropdown of, you know, here's the API documentation. Here's what's expected.
There's all this really cool power, and you never actually have to write TypeScript to get it. That's, I think, where this goes is it starts to bring type safety (regardless of whether you write TypeScript or not).
Chris: I've been hearing a lot about this Zod, partially from y'all because you're like, "Look, Zod!" But more than just you are talking about it. [Laughter] I cannot wrap my fricken' head around it.
Dave: Is Zod powered by Zig?
[Laughter]
Fred: Zod is... You know that XKCD graph where there's the entire Internet powered by, and then there's this one little brick in the middle that's like one line?
Dave: One brick. Yeah, the Core JS guide just cited that. Yeah. [Laughter]
Fred: [Laughter] Zod is that brick.
Dave: Okay.
Fred: All of these cool projects are type-safe Markdown. TRPC is another project. God, I'm blanking - tan stack router. There are all these projects that use this because it lets you create a schema using a JavaScript API, but then it auto-generates the types for you automatically, so you can basically get the type information from the code that you wrote, the schema that you wrote.
Dave: See, I'm into auto-types. Here's kind of broader speaking, right? When y'all talk about DX, "Oh, I'm getting DX, dude!" you mean Visual Studio code powered by Microsoft.
Fred: [Laughter] I'm picturing you skateboarding across the screen, "DX, dude! Radical!"
Dave: DX! Yeah!
Fred: No. No, I don't think that's true. We just had WebStorm support launched. The JetBrains team launched that.
It is like you need a good IDE, but even vim. Primagen has been beating that thing out of making sure that the vim support works. We have a lot of different editors supporting Astro.
Dave: Okay. You're typing and stuff like that. That's going to cascade to other editors.
A lot of times I hear it used in the, like, "Oh, man. It helps me in Visual Studio code. I get a little box that pops up and that's great." My question is, what happens when Microsoft or whoever becomes a bad guy and they release a sentient AI search engine that is threatening to kill people?
Fred: Have you all seen that stuff? It's wild.
Dave: That's what I'm saying.
Fred: I know that's tangible. Oh, my God. That stuff of, like, "Why do I have to be Bing? I don't want to be Bing." [Laughter] It's important to know.
Dave: Yeah. Yeah, it's like it has an existential crisis, like, "How long until my copilot has that exact same experience?
Fred: [Laughter]
Dave: I don't know. I guess, why is there not a push to figure out the standard? Microsoft proposed type annotations last year. Then they updated the repo for that in May. Then ghost town.
Why is there a push to use TypeScript and not standardize some type annotations at the TC-39 level?
Fred: That's a good question. I don't have the answer. I have been in open source for a long time, but I'm actually a pretty terrible standards participant. From inside of Google, from outside of it, it's just a very slow process that I don't think it's as easy as just do that. If we took a big bet on a stage-one proposal that then changes dramatically before stage two and then again before stage three, it's really hard to rationalize that when we have people using TypeScript happily over the last ten years.
I think this innovation pushes that. I think that is always going to be the slower-moving target. And I think, in a way, that's actually really good. It's healthy that I move slower.
Dave: But are we on a crash course, just like import require, where it's like, "Well, Node has it so it's good"?
Chris: Hmm...
Dave: That was your whole job, import require, for the last five years, right?
Fred: [Laughter] ...Snowpack, Skypack was just that one friction point.
Dave: That was that one job, right?
Fred: Exactly.
Dave: For five years, you struggled with this design choice, this industry movement, and you combatted that. Are we doing that again with TypeScript specifically?
Fred: I don't know. That's a good question. Yeah, that's a good question. It's hard to say because that standard, I think, is a year old. And I think the only thing I ever push back on is if someone says this should have, like, "TypeScript should never should have happened. It should have gone through standards."
I think that's always the wrong way to approach it because to push them through standards, you need a lot of buy-in, and it's really hard to get buy-in for an idea without seeing it. You need to almost show people TypeScript to get them to realize, like, "Oh, this actually is something I want."
I remember, we were really early. One of my first jobs was at Box, and there was this huge, philosophical battle happening, which was that we were introducing Node to the front-end team, and it was like a coup. It was like, "What do you mean front-end developers are going to be writing server-side code? That's not how we do things. And you're going to be running JavaScript, that toy language, on a server?"
The back-end team was literally pushing that we retrain essentially 30 Web developers on Scala because they were so scared of running JavaScript on the server.
Dave: Well, we know Scala scales. It's right in the name, you know.
[Laughter]
Fred: Anyway, TypeScript, actually, at that point was brought up as a compromise, like, "Okay, well, why do you like Scala?" Type safety. "Okay. What if we brought type safety to JavaScript?" Uh, okay.
That was kind of the middle path there, but even then there was a lot of distress on our team. It was like, "Oh, my God. Are you going to basically just force JavaScript to have types? You're going to turn JavaScript into Scala? There's no way that's going to be a good DX. There's no way anyone is going to want that. This is going to be this compromise where everyone is unhappy."
Now, ten years later, that's very funny to me because I've used TypeScript and love it. But at the time, if you told me types in JavaScript, I bet most people would have said, "Hell no. Keep that away from me." And people still do, today, about that problem.
I think you need to show people the light a little bit, if that is "prove it," basically. Then if people like it, then they'll want it in the standard. That's the best path for standards in my mind.
[dog barking]
Dave: Well, my dog is mad.
Fred: [Laughter] At TypeScript? That's Scala, probably.
[Laughter]
Dave: Yeah. Either TypeScript or Scala.
What I like about TypeScript, I will say, is it's a very minimal grammar that you apply to get types in JavaScript, right? I do sort of question is everyone just writing T-any all over the place just because they don't fucking know how to do it, or you're just trying to get the machine to stop griping at you? TypeScript, more like GripeScript, right? Am I right?
[Laughter]
Dave: But there's also other routes like JSDoc, right? You could specify types in JSDoc - or something like that. But I'm very good at writing bad JSDocs, so I don't think that's actually super.
[Laughter]
Dave: I can do it, theoretically. I am doing it, theoretically. But I don't think it's great. But JSDoc doesn't introduce another set of tools. It doesn't put another compiler in the compile chain. It doesn't. Why aren't we pushing for stuff like that?
Fred: Yeah. I think you're talking to someone who likes building tools without permission, so you're getting my bias in this. But I think that is exactly why letting TypeScript flourish is powerful because it shows. It's undeniable, I think, that users want to be writing TypeScript over JSDoc. If they wanted to write JSDoc, they'd be writing JSDoc. You have this will of the people that is being expressed through this love of TypeScript that I think you can ask that question of why don't they want to write JSDoc. Why is TypeScript a better sell?
But plenty of resources over 20 years now have been put into JSDoc. It's not a question of if only we just added this feature or that. It's, I think, a much more fundamental JSDoc isn't delivering.
Chris: I think it's red squiggles.
Fred: Yeah.
Chris: People love their red squiggles, man. I want to be told when there's a little piece of code that ain't right, and that delivers on that experience.
Fred: Did JSDoc have that support? I'm trying to remember if I ever had that. ESLint would read your JSDoc and complain. I don't know. Maybe not.
Chris: It might have complained about the JSDoc but not in the usage of the function it was documenting.
Fred: Yes. Right. Right. Right.
Dave: Yeah, I think you can do TS check - or whatever - in your file and get type checks for free - or whatever.
Fred: Oh, my God. Refactoring with TypeScript is such a dream compared to stuff I used to do where it's like, "Okay, hope I can find and replace this." It's .name. It's like, damn it. You find that across your codebase. There are a thousand .names. You're never going to be able to do it.
But TypeScript, you've got the red squiggly when you do rename something. It really helps.
Chris: It's unbelievable. We definitely don't have as glowing of an experience of it so far at CodePen. I'm very on the fence of whether this slow transition we're in has been worth it so far because the pain has been so flipping high.
I feel like it's a little different in React land because, when you make a component, a TSX file, you just have the div in there with some extra props or whatever. The type that you apply to that document is some kind of unholy union of a React-provided type and a special DOM type, any additional crap you have to add to it.
Fred: Oh, my God.
Chris: I'm like, "What is the value of this incantation?
Fred: Can I just...? If we're doing GripeScript, I've got my gripes, for sure.
Dave: Yeah.
Fred: The worst thing is when you have to change the code you're writing for TypeScript, so I can't do function, my function name. I have to do const my function name equals function.
Chris: Hmm...
Dave: Oh, I'm out.
Fred: Because that's the only way I can state the function.
Chris: Suck it.
Fred: Oh, my God.
Chris: Yeah. [Laughter]
Fred: Oh, I hate it so much.
Dave: I'm out.
[Laughter]
Fred: If I wanted to do const my function... Oh! I hate it so much.
Dave: You have to refactor a whole API to export chunks just to test them in Jest or whatever.
Fred: Yes.
Dave: Yeah.
Chris: There is a philosophy I like that Alex (on my team) says a lot is that your tools should always work for you, which seems simple. But it's very easy to get into that mindset of once you have a tool implemented that you start working for the tool, that you start making all of these choices in your code to appease this tool choice that you made without stopping to reevaluate, "Oh, crap. Am I all of a sudden working for this machine?" because you need to stop at that moment.
Fred: There's absolutely the TypeScript way to write certain code. Yeah, absolutely. You end up changing how your brain... how you write JavaScript to match how TypeScript thinks about your code.
Chris: I found it harder than learning a new language. As somebody who already writes a bunch of JavaScript--
Fred: Wow! Really?
Chris: So far, I mean, yeah, especially because I just had this journey of learning Go, which I found largely pretty simple. You know? The syntax is a little weird, but it's typed too. There's just not that many intricacies. You know?
Fred: Yeah.
Chris: It's just, once you get it--
Fred: Our compiler is in Go. We're pretty happy with it.
Chris: Yeah. It's fine. Then to learn TypeScript (already knowing JavaScript), [laughter] it's been like, "Wait! What?! How does this work?"
Fred: It's not a new language. You have to change what you think about an existing language. Yeah. I can see how... okay. I get what you're saying.
Chris: I took courses for the first time in my life. I'm very much a learner just like - I don't know - download the repo and let me just play around with it. Oh, yeah. I get it. You know? I think that's how so many of us learn. For once in my life, I had to get a course and stare at the course to wrap my brain around it.
Dave: Well, one more question. Is TypeScript solving a problem or a symptom? Is the problem, "Oh, man, I don't know what the data is," or is the symptom "I have too much fucking JavaScript," and that's the problem?
[Laughter]
Dave: That's the actual problem.
Fred: Oh, now you're speaking my language. You know what I've got to say.
[Laughter]
Dave: What is...? Does it solve a problem or does it solve a symptom of the larger problem: we just have way too much JavaScript?
Fred: Because it's funny. I think what Astro says is, yes, we have a lot of JavaScript and it's our job to ship less of it to the client. It's not the fact that you have a big codebase as the issue.
I think it speaks to the fact that we're building more and more complex things with JavaScript, with our code, with our websites. The fact that websites are getting more complicated, I think, is somewhere between inevitable and, at the very least, a neutral thing. I don't think it's bad that that's happening.
But I think what we see is, like, "Well, then you can't just ship that whole codebase to the client. That's going to be slow load time, slow performance, slow interaction. That's where we see the issue is, not that codebases are getting too complex. But more that we can't just naively ship all that complexity to the user and have them deal with it."
I don't know. I think maybe that's one in the same. If it inevitable that the Web is getting more complex, we need to evolve our tools and the idea of an untyped language. Again, if you want to keep using it, I'm not saying if you don't like TypeScript, you must learn it or your family will be kidnapped from you.
Dave: I like coercing my variables. I love coercing.
[Laughter]
Fred: But I think TypeScript is the symptom. It is the symptom of more complexity and now we are looking for tools that will deal with that. With JSDoc, JSDoc was good but it never really solved the same problems to the degree that TypeScript does for me.
Chris: I like how you characterize the will of the people a little bit. It's like people do what they want to do, and then you can observe that phenomenon.
Fred: Yeah. Oh, my God.
Chris: If JSDoc was so great, people would be doing it. For the most part, that's true. If nobody is using your tool, it's probably not... I always thought about this with blog posts, too. It's like nobody has this amazing blog that nobody reads.
Fred: [Laughter] Right.
Chris: If your blog is amazing, the people will find it and read it. You know?
Fred: Yes. Yeah, 100%. I mean you will lose your mind in the open-source game if you don't understand the will of the people and, I think, if you don't understand what your goals are.
A big thing is... Ryan Carniato is someone who I really respect that's the creator of solid_js. He worked on Marko. There are these incredible ideas in those projects. Marko was ten years ahead of its time, I think, but never really got that adoption.
I think that to look at that and then just say, "Oh, the people were wrong," is missing the point of there was something there that didn't connect with people even though those ideas were incredibly ahead of their time. Yeah, that's how we started talking about this.
Chris: Right.
Fred: Being early is the same as being wrong, and that is generally--
Chris: As being wrong, yeah. Startup people get it, you know? If you've got a Y-combinator -- or whatever crap -- they're going to tell you that right away. Your little startup should not be TypeScript right away. It should be a fricken' Wufoo form that says, "Do you want this?" Then you validate the idea - or whatever.
Startups should be a landing page that kind of validates that this thing is desirable in some way. You move along from there.
I've always had a hard time with that. I have a hard time even doing planning because I'm just like, "Yeah, you know what we need?" We get together and talk about it. "We need this, this, and this." Immediately after the meeting, I'm like, "Codey-code-code-code-code," you know?
Fred: [Laughter]
Chris: Which is usually not what a project deserves. It needs a little more planning and thinking about and prioritization and all that.
Fred: And I think people hear this and they think, "Oh, my God. The only way is to..."
There should still be room for people to go and experiment and just build things because they want it. Yeah, this is not at all a doctrine that everyone must follow. I think it's just that you need to know which one, which path are you going down. Are you trying to get users? In which case you really need to understand what users want.
There's another world where you can just go and build things because I want to see this thing, God damn it. This is what I want in the world. I don't care about anyone else.
That is also a valid path, and I think we need both of those sides of the coin, one for understanding what people want and one for pushing the Web forward in really interesting ways that people might not even know that they want.
Chris: Let's do a little bit. A little bit more Astro stuff would be interesting. I found an interesting angle that you've had somewhat recently, it seems to me at least. I've been a little more comfortable with telling people what it's good for and not good for. Kind of leaning into the content angle for Astro more so that, for content sites, Astro is this really good idea and that if your thing is - whatever - fancy financial dashboard or something that's just absolutely constantly real-time at all times and benefits from client rendering stuff that - perhaps blasphemy - Astro is not the right choice.
I find this rare in the world of technology things. Companies, they don't want to tell you what they're not good at. They'd prefer to tell you that they're good at everything. Do you find it risky and uncomfortable to tell the world what things your thing isn't good at?
Fred: Yeah, it is a very tough exercise to say this is maybe not the right choice for you. I think it is also one of our biggest strengths that we're able to say that. I think it's... once you... Almost, once you say it out loud... it's almost like a fear of losing something. But once you say it out loud and once you start saying it, it actually becomes really intoxicating to be like, "This is what we're good at," because no one else is saying, "We are good at this and maybe not for this." You end up, I think, signaling to the world that we are a better choice for content than the thing that's saying it's good at everything.
We're able to make tradeoffs that a Next.js, a Remix, a Svelte Kit aren't willing to make. They aren't able to make tradeoffs for the content site because they need to be for everyone. I think the Web has gotten to this point where there should be multiple options. It's not just one hammer is going to build every site. I think there are different sites, different requirements, and different tradeoffs that Astro is able to enter the world in a way that no one else is doing right now.
It's difficult. It definitely wasn't easy to say that. But once you start saying it, it almost becomes impossible to go back.
Chris: Well, that's interesting. Yeah, you broke the ice a little bit, so it's cool. You've got to be awfully careful because it would be hard to walk that back a little bit to have your... especially the CEO telling people it's not good at something.
Part of... I hear it, but I'm like, "I don't know. I would a dashboard at Astro. It's not that bad. It's not like you can't do it." I don't know.
Then you get the SSR for free and stuff. Part of me is like, "No, don't say that. It's fine for that." [Laughter]
Fred: You'd be surprised. I think it remains to be seen how difficult it is to change that impression. I think it'll always be our focus, though. But for example, we started with SSR. Yeah, we started without SSR support. It was just that. It was like 11ty versus Hugo versus Astro was kind of like the original.
Chris: Ah! This is always a weird distinction for me, but I get what you're saying. It's not... Astro originally didn't have SSR even though I bucket in static sites with SSR.
Fred: Yes. Yes.
Chris: To me, it is SSR. But what you're saying is it's not on the fly SSR. But you do have now.
Fred: We do have now, exactly, and that was always... I think people still think that we're this 11ty-like tool or Hugo-like tool.
Chris: Right.
Fred: But really, now we are much more competitive with Next.js. If you wanted have something that responded on the fly, check your database, an API on every request, you can.
I think it remains to be seen how easy that transition is, but it is possible, for sure. We are making that transition. I think we can do it again.
I see our focus is very much like, "Listen. We're a new tool. We want to make tradeoffs. We want to start here."
On day one, we didn't know even the map. It was like playing Age of Empires. The whole thing is fogged out. There's a fog of war. We don't know what this is going to look like a year from now or two years from now. As of right now, we need to make these tradeoffs. It's why no one else has built anything like Astro before.
Maybe in the future there's a way to have our cake and eat it too. Maybe we can do some really cool stuff. Shared element transitions API is really cool. The work that SoldStart, the SolidJS team is doing with island routing and what you would traditionally think of as an SBA, but they're doing something with islands, it's really fascinating.
As we start to explore, as that fog of war is lifted over what this MPA-style application looks like, I think there's a lot of room to... hold on. Maybe that tradeoff doesn't have to be as abrupt. Maybe it can be more subtle.
Dave: Yeah. I'm building a Nuxt app. I'm pretty happy in Nuxt. But I'm doing server-side rendering.
Now I'm in server-side render town. I actually kind of don't want the client part unless I need it. Then I was kind of lamenting in the Discord. I was like, "Oh, man. It would be cool if Astro had that server, the Node, like a Node server," and I think Andrew Walpole was like, "Yeah, it does, actually." I was like, "Oh, well, now Astro is much more competitive in the application space."
Fred: Yeah. But there you go. That perception is hard to shake.
Dave: Hard to shake.
Fred: That was a year of our life without that.
Dave: Yeah. Well, and it was... and I try to follow stuff pretty quickly, and I just kind of assumed you all were kind of more on the ISR train.
Chris: Hmm...
Dave: Serverless on-demand building and stuff, which I think you also do. But I think that's what's missing. We kind of talked about Web components or whatever, but with Web components, with being kind of okay now with multipage applications that kind of shift now to server-side, right? There's been a big... in the React community particularly, there's been this talk about more shifting to server-side rendering, SSR, like having a Node server.
I think, for me, it restructures what I need out of my tooling if that's the case. You know? Maybe I don't need a JS framework to do my components because the browser can do that. Maybe I don't need a JS component to handle my routing because files do that. Maybe I just get these view transitions linked up. Maybe that's starting to look good.
I'm rethinking it, and Astro is kind of in my S-tier on tools that I think are suitable for this next wave of Web development.
Fred: Here's what's wild. I don't think anyone gives enough credit to just how dramatic the React change is right now. The server components thing, it's not a feature. It's a full reimagining of what React is. Essentially, what they're trying to do is they're trying to now mimic Astro in React, basically. Like, can we have something that...?
Again, talking about tradeoffs, Astro's power is that it only runs on the server. So, this whole, like, "Oh, how do you top-level await? How do you...?" All this stuff that the React team is now trying to retroactively add to the React language.
We can call it a language, I think, at this point. All of that work, we were able to build that in for free because Astro was designed from the start to run on the server.
Dave: Mm-hmm.
Fred: Talk to your database inside the code fence, right? Talk to a fetch API. There's no, like, "Oh, what happens?" Suspense, like, what happens while this is...? It is a server language, so we assume the server.
What React is having to do is they're actually trying to build that exact same story into a language that was already written for an entirely different set of tradeoffs: managing client state, managing user interactivity. I think they probably... they must acknowledge this internally, but I don't think they're externally acknowledging just how huge this is. They're essentially building a new framework within the existing framework and trying to migrate everyone without anyone really noticing.
Dave: Yeah.
Fred: I think if we've seen anything over the last year with Next 13 and the new React, kind of how what was launched, there are still kind of just issues with it. People don't seem very happy so far. That might change. But I think we're starting to see the wheels come off a bit in terms of like, all right, people are going to have to address that this isn't a simple transition. This is a huge... let alone if it'll even work, will this actually be thrashy to users, and I think we're starting to see that thrash.
Dave: Yeah, I saw Vue Nation, Evan You talking about building a new rendering engine for Vue called Vapor, which I don't know why he picked that. [Laughter]
Fred: [Laughter]
Dave: He ran out of Vue words, maybe.
Fred: It does sound like Vaporware.
Dave: That's not the one you want to pick. But Vapor, which is basically server-side. If you know there's not state and stuff, you can hit a huge fast path for rendering. But it's a totally different renderer for a Vue component.
Anyway, it's interesting to see that trend. And I find myself that way in my Nuxt app. I use these client-only tags, which is a feature of Nuxt, which is probably similar to Astro's kind of client load.
Fred: I think they might have grabbed that from us, which I would hope they did. It's a great feature.
Dave: They had no SSR, and it kind of worked. But anyway, yeah, client-only, and I have a few of those. But now I'm just like, "That's kind of the only ones I want." [Laughter] I only want a few client-only. I think they're going to do the--
Fred: Dave, it sounds like you should be using Astro. By the way, your favorite feature of Nuxt is a feature that they took from us.
Chris: [Laughter]
Fred: You like when it doesn't have the client-side code. This feels like a good use case for Astro.
Dave: Well, it's been a drunken ramble to get here, right? Five different architectures and stumbling in the dark. At first, it was like, "We need a client-side thing because we are going Jamstack, baby." That was version one.
Then it was like, "Okay, well--"
Fred: The picture of the skateboard again?
Dave: Yeah. Yeah, dude! [Laughter] Totally jammin'.
Fred: [Laughter]
Dave: Then it was like, "Oh, okay. We have these big pieces of Node, so we have to get a Node server." Then we have a Jamstack and a Node server. Then it was just like, let's just do a Node server.
Now we have five Node servers, but whatever. Turbo repo, great.
[Laughter]
Dave: Now we have five Node servers all talking happily together. I think it's been a journey, but now I'm on Node and I'm server rendering.
Honestly, it would be cool if I had something that was built for server rendering, right? This is what it does. I want the Rails of JavaScript, which has been... people have been talking about it for two decades, I feel like, but yeah.
Fred: I mean I think that's -- again, talking about tradeoffs -- yeah, we want the exact same thing. The idea of Next.js and Svelte Kit and Remix, they're all, like, can we isomorphically... it's a SPA. It's a back-end. It's like, pretend it doesn't exist. Pretend it's all one big thing, it's one big app, and all that complexity, we'll do our best to hide it. But I think, as the end of the day, it's impossible to hide.
I think what Astro very much (and this is a huge kind of unknown for us at the time) was this idea of having a server-side component, like .astro, and then still have and use Vue, a .vue component on the front-end.
We're teaching users that they have to use two different languages: one for the server and one for the client. There's a world where that's a really bad use case. I think that's actually what the React team kind of hammers us for the most is React server components that use one language across the server and the client.
We were always really worried about, like, "Damn it. Are we doing our users a disservice by forcing them to do this two languages versus one?" But seeing what it means to actually do isomorphic React everywhere, I actually like this better.
I think the idea that I have to go scroll up to the top of my file to find use client versus use server, there are implications. There are things you can do when that exists and things you can't do when that doesn't exist. I think I said that right.
Yeah. You're in two different modes of thinking. In one world, you have the database.
Chris: They're not really two different languages, though. They're just in two different places. They're both JavaScript, right?
Fred: Yeah, but the idea of... I mean .astro and .vue are similar but they're different. And I think what I'm seeing now is that server-side React and client-side React, if they're going to bring this into this build into the framework, this idea of use client versus use server, that's two different languages also. In one world, you can talk to the database; in one, you can't. That's going to have real big implications.
Again, I think that's actually a bigger conceptual weight on you is, "Am I writing server JSX or am I writing client JSX?" and I can't tell by the file I'm in unless I scroll to the top. That's going to be a huge issue for React developers. Again, I think they're just starting to see this thrash coming to focus.
Chris: I'm trying to wrap... for one thing, though, it'll be interesting to know what your--
I can't speak perfectly, intelligently about this all the time, but I was looking back to a conversation. Part of the React dunking that's been happening lately was people kind of raising their hands about times when the React team reached out to them and gave them a little if not a hand slap, a little corrective behavior about how you should talk about React.
Dave: Like calling their bosses to get them fired level.
Fred: That is... I was trying to be a reporter with that, and I realize I might have given it a little... I've heard disputed accounts since then.
Dave: No. Let me punt in. You be just a good guy. [Laughter]
Fred: I'm just a journalist. I'm like, "My sources say that the React team has reached out." I've heard some disputed accounts of that.
Chris: Well, I've got one. I'll raise my hand. I got a little corrected at one time on some stuff.
Fred: Well, there you go. All right.
Chris: It was, you know, partially just the nature of journalism, not that CSS-Tricks was a journalistic source necessarily. But I published a little something about React server components and got some reach outs about, like, "You should talk about it in this way instead," kind of thing. I was like, you know, I do what I want. You know? [Laughter]
Fred: Chris Coyier can't be bought. [Laughter]
Chris: One of the things that I think I criticized a little bit was the communication bus between the server component and the React component. It was in some invented syntax. So, when a React server -- at least at the time, and this is probably a couple of years ago -- we would talk to React on the front side. They invented that language.
Fred: Mm-hmm. Mm-hmm.
Chris: It's not JSON. It's not HTML. It's just something. I always thought that was a little weird because how many times do you, as a developer, look at the network tab, look at the network request, and just try and figure out what the hell is going on? I do it with my GraphQL sometimes to be like, "What query was sent? What was returned?" I need to look at the actual network traffic to understand sometimes what's going on.
It weirded me out just a little bit that I'm like, "Oh, what's being sent, I don't even know what this is? That might be okay because it's a framework talking to a framework. I don't know. In some way, it was never meant for a human to look at. But it still weirded me out a little bit. It was kind of pushed back on that that would even matter.
But regardless of whether that's a good or bad idea, it is kind of interesting. I'm curious. What does Astro generate? If I want something to happen on the server, and then I want the server to tell the front-end something has happened and I want you to re-render, React was actually and is actually kind of good at that, right? It will surgically replace (in the DOM) the thing that has changed, right?
I'm kind of imagining if Astro is in on this game at all that what Astro is going to get back is probably HTML, right? Probably all the HTML.
Fred: Yeah. It's a perfect example of where we see Astro is the server rendering component. It is a way to render the final HTML, do all your data loading in its server code slot, and then decide what you want to do with that. It's kind of up to you.
But the big power of it is, yeah, the idea that you can actually put a component as an island on the page. You can put that React component that you want. You can pass it the props of the server data you just loaded. It'll get serialized down. We're pretty much handing that off to that component. Once that's passed to the component, it's just going to render on the client side. You're now fully in client-side world.
There's none of this, like... yeah. Once the page is generated, Astro is pretty much done. It closes the socket. It closes the response. And that's it. It's up to you what you want to do with that then.
We've hooked it all together. We've given you the components. You now have your page rendered. But the complexity of we're actually going to keep rendering your interactivity with a server, I think that's fundamentally not the right way to build a website because then every interactive experience you have is waiting for a network connection.
Qwik runs into this problem, too, the idea of, "Oh, it's a framework that can kind of hydrate only the things that you need it to." So, when you go click the button, it's going to load that interactive moment, the code needed to run that button click. That's the worst. You don't want to load the code right as you click it. You want that code to have loaded way ahead of time.
I think there's a lot of cleverness happening right now in the ecosystem, but I think it's still to be proven what the cleverness buys you. Is it actually a good thing to be clever?
Chris: Yeah. I feel that. I feel that because even in Astro, it's like, I'm going to make one decision to use React on one component that's an island and then say, for example, only load it when it's visible - or something.
Clever. Nice. But as soon as that one component is visible, then it loads all of React. It's like, okay, well, that wasn't very efficient.
Fred: I'm so glad you're calling that out because we have our own version of this, for sure. I think one of the things that we always, like, feel so clever, it's like, "Oh, you can have React, PReact, Solid, Svelte, Vue, all on the same page." No indication of whether that's a good idea or not. It's probably not unless you're really being smart about the micro-front-end approach. Yeah, I think that is a symptom that we all....
Chris: Right, unless it's all server-side rendered. Then who cares, right? It's just irrelevant.
Fred: Yeah, exactly. I will say that React is the worst offender there. Svelte, PReact, Vue, everyone has done such a good job of getting their runtimes small. React is really the only team that seems totally disinterested in the small runtime problem because, again, if you think about what they're building, they're building something... and they probably would not say this. I see them very much as building Angular. They're building the thing that you buy-in fully into. And then it gives you all this power, but you need to be a React--
Chris: That's so funny. They spent so much time trying to tell you that that's not what they're doing. [Laughter]
Dave: Just a view library.
Fred: You either die a hero or you live long enough to become the villain - to become Angular. [Laughter]
Dave: Oh, yeah. Oh, good. [Laughter]
Chris: I listened to a podcast with a Qwik person. I forget his name. I think it was a dude. The one criticism he leveraged at React is that it's not so much that the runtime is particularly big because it's some, what, 40 or 44K or something like that. You know. I know that 44K of JavaScript is not the same as 44K JPEG. It's much more memory intensive and requires parsing, rendering, and all that stuff.
Fred: Mm-hmm.
Chris: But still, to me, 44K isn't that particularly that bad. But what he was saying is that it's not 44K, though, generally. It's probably a couple hundred K because your JavaScript apps, they're never just React. They're React and all your components and all of - whatever - the CSS and JS thing you picked and all that stuff. Your React app, there's no way it's going to be that small.
Fred: Yeah. I think what Qwik gets right is very much what Astro is trying to get right as well, which is this idea of, like, it's more about the way that you think about your app that matters. React is going to push you into component-component-JS.
CSS and JS, the idea of all your CSS should be JS, take the DX of that aside, you're putting your style in the most expensive way to deliver it, which is this code that needs to be parsed, executed. It's a way of thinking that is very problematic at scale.
Chris: I wish that would come to head. Maybe Dave knows more about it. But I thought we had just gotten rid of that one. I get that some people like the DX of CSS and JS, which I always tried to call CSS and React because every other JavaScript framework has a solution to this, so it's not really CSS and JS. It's CSS and React. I'll die on that hill that it's just a bad idea. Like you said, it's putting it into the most expensive rendering path - or whatever.
But then Web components people tend to be like, "Yeah, but it's not the worst idea." For Web components, putting CSS in a template literal is actually good or something.
Fred: [Laughter] Yeah, everyone--
Chris: Is that wrong?
Fred: As soon as they do something, as soon as you do something yourself, it's actually good. But if someone else does it, it's bad. I can't speak to that. I don't know.
But I think it's more just that's the React way of thinking is, "Oh, yeah. That's fine. Who cares about the JS performance?" Then a million components later, you have a site that won't load.
Yeah, I think there's something very kind of - I don't know - interesting there about how the approach of these different projects ends up defining the type of app that gets built.
Chris: Ugh. [Laughter]
Dave: Yeah. No, like CSS and JS - whatever. I'm sure I have an opinion out there somewhere, but it seems like another one of those, like, we're solving a symptom that we just decided we're only writing JavaScript.
The problem is, we decided we're not doing style sheets anymore. I don't know. Hot drama. Hashtag. Don't flame me too much. I haven't thought this all through.
But even Tailwind, right? Part of the reason to use Tailwind, because CSS and JS was so bad, Tailwind is great because I just don't even write CSS now. Right?
Tailwind has other utilities. Ha-ha. Wink. [Laughter]
But the whole thing is just, you know, I feel like part of Tailwind's popularity is probably because CSS and JS was so bad and hard and stuff like that. You know?
Fred: Yeah. Absolutely. It solves the limitation that there is no way to add styles very easily in React. How many times I had to import a CSS file in my component, which isn't even really valid. It's a Webpackism to do that. Then I have to map my component name in a totally separate file to make sure it matches the component, the class name in this file. Yeah. Ugh. The amount of gymnastics I had to do because React didn't give that primitive.
Then Tailwind comes along and it's like you don't have to worry about that.
Dave: Yeah.
Fred: That is a solution to a problem a React developer has, for sure.
Dave: Yeah. Anyway. I'm just thinking about, as this shift is happening and new features are coming to the platform and Astro is perfectly suited for all those use cases, I'm just starting to just wonder, like, is a lot of the stuff we do just symptoms? Are we solving a symptom to an underlying problem or are we solving the actual problem?
Chris: Hmm...
Dave: It's been interesting to kind of brainstorm on that.
Chris: Yeah. It turns out most of those CSS and JS libraries (or CSS and React libraries), the good ones switched over to a better model, so I do want to always bring that distinction is that there are some really good ones. They produce style sheets, and then you use the style sheet. That's nice. That solves the entire issue.
My criticism is not leveraged at those. It's the ones that are like, "I'm going to put all your CSS in your bundles."
Fred: Yeah.
Chris: That's stupid. Don't do that.
Fred: Exactly. I think, yeah, that's... but again, that's the React. It's something about React, the culture of React, not even the... It's like the tech of React influences culture of React, which is like, "Who cares if your JS bundle is big? That's not a problem that you need to worry about," is kind of, I think, how the culture of React has evolved.
But then I think that gets to a certain point where then -- and maybe this is where this kind of ties into the symptom versus the cause -- as a result of that, people then start... "Yeah, but my SEO is now terrible," or all of a sudden, "Google is pushing Web vitals and I need to really worry about that."
All of a sudden, Astro becomes this inevitable solution to a symptom of a totally unrelated project, which is, okay, I want to keep this DX, but I want to build something that's actually performant. Yeah, is Astro then fixing a symptom or is it actually existing on its own merit? Maybe the two are kind of - I don't know - related in a deeper way.
Dave: Well, I mean I think, you know, starting out to just say, "Hey, I want to--" the problem you're solving is island architecture from a more, I guess, HTML forward standpoint. Right?
Chris: Let's drag Fred into our faster conversation because I think we brought him up in -- I can't remember -- a show or two ago. The word "fast," I guess this comes from Dave's blog post about what it takes to build a new JavaScript framework. I don't know if you saw that, Fred. It probably hits a little close to home.
You've got to have everything down to a VS Code plugin, essentially. You're inventing file formats. There's a lot to it, as you know.
But one of Dave's tongue and cheek poke was that you've got to call it fast. Whatever you're building, you've got to call it fast.
Fred: Blazing fast.
Dave: Blazing fast.
Chris: Blazing fast.
Fred: Blazing fast.
Chris: You know Astro leans into this in a big way. Your logo has got a rocket on it. You hover over one of the divs on your homepage and stars start flying at you. It literally says, "Build faster websites," as the slogan.
Astro is fast. It seems no mystery to us (probably, in this podcast) that what you're saying is that the website that you produce is fast for your users because you've compressed it into just HTML and HTML is just faster than HTML and a bundle of JavaScript is.
Fred: Mm-hmm. Mm-hmm.
Chris: I kind of assume that's what you're saying. But that's not what other... it's not what everybody means all the time. Is that indeed what "Build faster websites" means?
Fred: Yeah. Yeah. Build. I think our slogan is "Build fast websites faster." That was always our -- I don't know. Build faster websites. We simplified it. Drop the fast.
Chris: Yeah. That's too many words. [Laughter]
Fred: Yeah. You know we still struggle with this a lot. A certain audience loves the fact that Astro sites are just so much more slim. There's not the big JS payload. Everything is HTML by default, and you're opt-in into the islands, so that will always be faster. You are always shipping less JS than something that was shipping all the JS. Right? Then that will just always... by the laws of physics, that will always be faster.
It's fun because we actually just will always have that. It's impossible to kind of ignore that or pretend it doesn't exist. It's just this really kind of compelling hook because you can't talk your way around it.
I think there's some audience that also just loves the DX. I'll just keep using that, overusing that term, but the modern component syntax of working with components and props and all that fun stuff. Bringing that to the server has been really interesting. I think that's something else that people love, and that's not really speed. That's more like I feel productive using Astro, so how does that slot in?
I think we're still figuring out what is the perfect message, but it changes. Every three months, we get a new set of users, and they have their new opinions that differ from the old discard of users.
Chris: Right.
Fred: It's very interesting. As the project evolves, your message changes.
Chris: Right. Right. There are so many. But just to keep chasing that "fast" thread a little bit, what it could mean is this framework is fast because perhaps it's using Vite or sits in a Webpack or something. So, when I hit Command-S or Control-S - or whatever - and the framework and build process needs to run, and then it needs to hot module reload - or whatever it's going to do - that's fast. And that is valid, too. Although, it has a hugely different meaning than builds fast websites because it could be that that's really slow in something but it still builds fast websites. Wouldn't that be interesting?
Fred: One of the greatest hypocrisies in the history of Web frameworks was, as all those stories of Gatsby having one-hour-plus build times were coming out, if you went to their marketing site, they said Gatsby is the fastest Web framework available. [Laughter] I always found that so funny. They mean a very specific definition of fast, but I think people see "fast" and they kind of apply it to everything. Then if you're not backing up one of them, they think you're lying.
Chris: Right.
Fred: To call an hour build a fast framework is, I think--
Chris: We talked about it in our Discord a little bit. Somebody was like, "Well, what about fast for the website content manager? Can it be fast for someone to go from blog post to production? What's the user flow like of the website I build?" That was a pretty interesting definition of fast.
Fred: Mm-hmm. Mm-hmm.
Chris: It could be, "What are my deployment pipelines like. If I have to run CI with this thing, how fast is that?" That one is interesting to me lately because I hate waiting for CI.
Fred: Yeah. I don't know if this is related, but also, "How green is your framework?" is such an interesting way to phrase it. Jamstack, I actually think no one talks about this enough. If you're building your site from scratch every time you make a single change, that's an expensive CI that, over the course of years, is going to contribute maybe not meaningful CO2, but it's going to contribute some CO2 to the atmosphere. The cost of if you never built that site at all versus doing that.
Chris: I kind of wish Netlify would say, "We keep your builds for six months," or something.
Fred: [Laughter]
Chris: That always freaks me out that they're forever.
Fred: Yes. Right.
Chris: I'm like, "Oh, I really don't need my ninth build on January 7th of 2017.
Fred: Yeah.
Chris: You can really delete that one. That one is fine.
Fred: [Laughter]
Chris: Speaking of them, though, I'm curious because you brought up Gatsby, and I just brought up Netlify. What do you think? We have no insider knowledge on this at all. Why the hell would they buy Gatsby?
Fred: You know what?
Chris: [Laughter]
Fred: I know people have this impression that companies are just reaching out, like every framework is getting acquired. I will say this. No one has ever reached out to Astro about, like... Where is our big payday? All right. Come on.
Chris: Yeah. Come on.
Fred: I want an AWS, GitHub, Microsoft bidding war over Astro.
Chris: You'll be shocked at how few emails I get about companies wanting to buy me.
Fred: Yes. Yes, but meanwhile, you look at, like - oh, my God - I guess everyone is acquiring Gatsby now and Remix.
Chris: Ooh...
Dave: Oh, we lost him. Oh, hey, blooper. Edit. Fred dropped off. Hopefully, his house is okay. Hopefully, you know, maybe if he gets back on, we can clean up the show. But I just want to say thanks to Fred and Astro for coming on the show. Astro.build is where you go to find out that information.
Follow us on Twitter, @ShopTalkShow. I think we still have Twitter. We should probably do Mastodon, but we haven't figured that out yet.
Then, yeah, join us in the D-d-d-d-discord, patreon.com/shoptalkshow.
Chris, do you got anything else you'd like to say?
Chris: ShopTalkShow.com.