EPISODE 1588

[EPISODE]

[0:00:00] ANNOUNCER: Front-end web frameworks are software toolkits that handle many of the low-level and repetitive aspects of building a website. These frameworks have made it easier than ever to build a modern website. The open-source Astro framework was created in 2021 for the purpose of creating simple static sites that load quickly. A key factor to its high performance is that by default, web pages don't include any JavaScript. However, Astro gives users the ability to opt into using JavaScript wherever it makes sense in their projects. Astro also has the file-based routing and server-side rendering capabilities found in frameworks like Next.js.

James Q Quick has worked at Microsoft, PlanetScale, and Auth0, and is a popular technical content creator. He is an advocate of the Astro framework and joins the show to talk about what distinguishes it from next Next.js, SvelteKit, and other major frameworks.

This episode of Software Engineering Daily is hosted by Sean Falconer. Check the show notes for more information on Sean’s work and where to find him.

[INTERVIEW]

[0:01:14] SF: James, welcome to the show.

[0:01:15] JQ: Hey, thanks for having me.

[0:01:17] SF: Let's start off with some basics. Who are you and what do you do?

[0:01:19] JQ: Yes. I consider myself three things, a developer, a speaker, and a teacher. I've done some combination of those three things professionally for over 10 years now, which is kind of hard to believe. I have a lot of experience in developer experience, developer relations teams, software engineering. Then, I've spent the last several years focusing big on content, doing YouTube and podcasts, and courses and that stuff. I've been doing that full-time for myself now, for a little over a year, which is pretty cool.

[0:01:49] SF: What were you doing before that? Before you moved into full-time content?

[0:01:52] JQ: Yes. I had been doing a developer advocate role. So, working in developer relations for few years before going full-time for myself. Then, before that, was software development, before that, was technical evangelism, basically, the same type of thing at Microsoft when I started my career.

[0:02:05] SF: Awesome. So, we're talking about the Astro framework today. But before we get into that, I wanted to mention, we recently met in person, at the Shift Conference, and I didn't get a chance to tell you, you gave a great talk there, and I really enjoyed it. Maybe, could you give us a quick sort of TLDR of what you presented?

[0:02:21] JQ: Yes. So, it's about the impact that AI is having on developer experience. I didn't want to take the super traditional route of like, it's amazing, it changes everything, we should all be scared of our jobs. A lot of it was a meta talk, just kind of looking at the history of like evolution and innovation and how every time we have major inventions come along, like things change, and AI is no different, right? We look what it took to deploy, to build and deploy an application 10 years ago, and the things that we don't have to worry about now, because of the tooling. AI is just another one of those things. It's going to make it easier, I think, for us to continue to build, and people kind of have this fear of like AI is going to take my job. But the flip side of that is like, what if it doesn't take your job? What if it enables us to do more with the time we have, than we ever thought before?

Anyway, so I thought it was kind of a fun. A lot of meta-perspective on how we changed over the course of times, how we handle change, and how AI is just one of those changes that will get incorporated, I think, from a developer's perspective, into our daily workflow, and enable us to continue to do more and more.

[0:03:25] SF: Yes. I feel like we tend to have sort of a short-term memory when it comes to history of innovation. I even think, there was a time when people freaked out about the movement from assembly, coding and assembly to like higher-level languages, and they're like, “Oh, but I need to twiddle my bets and optimize.” But a lot of the companies that essentially refuse to adapt to things like C++, C, and other higher-level languages that came along, they don't exist anymore. Because essentially, they couldn't move at the same speed. I think we're in a similar space when it comes to this new generation of AI.

[0:03:59] JQ: Absolutely. Yes. That was a big part of the talk, too, was just handling change and how our reality changes on a daily basis. Something dramatic, like death, or getting married, or having kids, or whatever. Your world that you live in, that day, versus the previous day is definitively different. The world that we live in as developers now, is different than it was a few years ago, because we now have these tools at our disposal, and it's the people who are going to embrace that, and take advantage of that, that are going to be the most successful, and the people who don't handle that change, who aren't interested in learning anything new, they're going to continue to struggle. I think that's always been true. 

This maybe is more dramatized with AI, because it's come out of almost nowhere to be so popular and little overwhelming. But the reality is like you have to be able to handle change and to learn new things, and that's always been true. 

[0:04:48] SF: Yes, I think some of the, I don't know, the perception of threat from it is because it's a little bit Black Box-y, like even people who are experts in the space don't always know exactly what essentially is going to be split out from the neural network or whatever sort of models being used. So, I think that basically, when there's a lack of understanding from humans, a lot of times, there's also reaction in terms of fear.

But one of the things I thought was really refreshing about your talk was that you were really transparent of about your level of expertise in the area. You weren't saying, I'm an AI expert or anything. You're just like, “hey, I'm a developer. I've been working in a space for a long time. Here's what I'm thinking about.” And also relating that to like this history of innovation. There's so much happening right now in the AI space, that there's a lot of people that hadn't heard of a vector or reinforcement learning six months ago, that are posturing themselves now as like experts. So, I just thought that was really refreshing. I wanted to call that out.

[0:05:46] JQ: I think it's important because my talk was not from the perspective of someone who's done a deep dive into AI and all the buzzwords and the science behind it, because that's not me at all. I'm just your average developer like everyone else. But I see the impact. I see the way that it's changing that I write code, and I come up with ideas, and get creativity, and all sorts of things. So yes, that was important, I think, for me to share that to kind of give a level set of where the perspective was coming from.

[0:06:11] SF: All right, well, now that we have our mandatory generative AI talk out of the way, let's talk Astro. So, for anyone who isn't familiar with this framework, can you give a little bit of background? What is it and what do you use it for?

[0:06:22] JQ: Yes. So, Astro was predominantly known for, but there's a big caveat to this that we'll obviously dive into for creating basically static sites. If we look back over the course of maybe five years or so, we got really into the idea of the jam stack, and that was really focused on statically generating content. So, we had, in the JavaScript ecosystem, there was Gatsby, I think, was the thing for me that really brought my eye to generating static websites. What that means is like, if I have a blog, every individual blog page is generated at build time, and it's just a static HTML asset, basically, that lives on a CDN and gets served whenever the request comes in.

We kind of went through this revolving door almost over the last five years of looking at like, okay, that works really great for a lot of different reasons. But there's also a lot of reasons that we do want the server to be involved going back to something more traditional, like a Ruby on Rails, or a Node.js backend, where we're having a request come in to the server, we're going and loading data from a database or wherever, and then using that to generate markup that goes back to the browser.

So, we've kind of been like circling in the ecosystem and web development to try to figure out like, what's the best combination of all those tools, and I think what we found is it is with the modern frameworks that we have, it's important to have the ability to statically generate pages, to server-side render pages, and then kind of mix and match all that, so that we can strategically make decisions on what's going to be the right decision not only at an application basis, but on a page basis.

Anyway, so Astro has come in, and really ran with the idea of statically generated content. So, Astro, by default, you create a page, file-based routing. That page at build time is going to be generated statically, and then just serve statically from a CDN. Astro is really optimized and targeted at amazing developer experiences for content, heavy sites. So, things like working with Markdown, this is why I started using Astro, because it just kind of has everything built in. I don't have to like write any manual parsers of Markdown. I don't have to add any like manual code syntax highlighting and stuff. It just takes care of all of that stuff.

They've also gone into, I’m sure we'll talk about this more as well, another level of structure with your content and content collections, which allows you to use Zod to determine or to define TypeScript types for your frontmatter, et cetera, just making the entire process of working on content-driven sites easier and easier.

Probably, the last thing that is most important is that Astro doesn't ship any JavaScript by default. So, with those static pages, no JavaScript goes to the browser by default. Things like Next.js, for example, can create static pages, but they also then ship React to the browser to do hydration and do other interactive things like you would with a regular React application. By default, Astro does not do that. But you can opt in to JavaScript when and where you want. So, you can write just Vanilla JavaScript. You can also incorporate other framework libraries like React, Vue, Svelte, et cetera, which is really, really unique. But first and foremost, Astro is content-heavy. It is focused on performance, zero JavaScript, but, and this is something I'm sure we'll dive more into, that I am super excited about. It also has the entire server-side capabilities that something like Next.js has, so you really can use it as a full-stack framework. It's just kind of working its way into making a name for itself in the full stack piece.

[0:09:36] SF: Yes. You mentioned Vanilla JS there. I guess, I feel like writing Vanilla JS at this point is a little bit like being stuck in the world of, hey, insisting I need to write assembly and not C or C++ or something like that, versus the million frameworks that can make your job so much easier.

[0:09:53] JQ: It's hilarious timing for you to bring it up. I don't know if you saw Twitter today, but I posted something basically like that on Twitter. Just say like, I just don't have a use case to actually use Vanilla JavaScript for anything. What I get out of a framework and there's lots of different frameworks that are optimal for lots of different things. What I get out of a framework, I'm not willing to give up to build all that stuff from scratch. So, there's actually a lot of pushback and debate in that tweet, which is really interesting, and a fun, super fun conversation.

But I am of the mind, in this case, of like, yes, there's almost nothing I would do with Vanilla JavaScript, versus using a framework of some sort. I think Vanilla JavaScript is super important to learn. I think it's super important to work with and to try to build things as you're learning to give you a better appreciation and understanding of frameworks. But going forward, there's not a choice that I would make. Now, the interesting thing is like in Astro, you can choose to add tiny bits of Vanilla JavaScript wherever you want, which I think that actually makes sense. But you're still using a framework to give you the structure that Astro gives you for a lot of different things, while then throwing in Vanilla JavaScript on top of that, so it still uses a framework.

But it seems obvious to me, like personally, I would not build something with vanilla JavaScript, something real, like more than just a landing page. But that's also still a debated topic. So, there's a lot of fun conversation around that to be had, I think.

[0:11:05] SF: Yes. I'll have to check that out and see what the arguments for it is. Yes, I mean, I think that there's definitely value, of course, stepping away a little bit from Astro, but to the meta-conversation here. But there's value of like learning, I think, Vanilla JavaScript, or even learning how to write a programming language, or learning how to build a database from scratch. But I probably wouldn't advise a company unless you have like a really compelling reasons to go and roll your own programming language, your own encryption, and your own database, when there's such a plethora of really, really well-thought-out, well-vetted systems that have been out there for a really long time.

So, it sounds like the way that you're talking about Astro, it kind of came in with this approach or thought process around, “Hey, we're going to be really good at this particular thing, of statically generated content.” Then, since then, it's kind of like expanded out. So, it's not a CMS. It’s not competing directly, at least originally, with any of these like frameworks, like Next.js or Vue, or anything like that. It’s not a platform as a service type of application, like a Vercel or Netlify, or something like that. It's kind of trying to carve out its own niche, and then it sounds like it's expanding from there, probably to accommodate other use cases, because you could go and use Astro to generate a static content site, but then you might run into essentially some limitation of just being able to do that. So then, you're like, “Hey, how can I insert some JavaScript or some server-side scripting or rendering or something like that, in order to serve this use case. So, I don't end up having to leave the framework to go do that type of work.”

[0:12:40] JQ: Yeah, I think that's 100% it. The thing, I think that's most impressive and exciting for me about Astro, is if you look at like where they started and what they were targeting, exactly what you said, like content-driven sites, Markdown experience, MDX integration, et cetera. They have done that better than any other framework I've used. Hands down, for me definitively better than any other framework. So, the thing that they decided they were going to do well, they did really, really well, which makes me so much more and continued optimistic about when they decide to continue to make improvements on other things. Those things from developer experience perspective are going to be super, super good.

Again, you have the ability right now, to have server-side rendering. You could mix server-side rendering and statically generated pages. You can define API endpoints. You can handle form submissions. You can do all the things that you would expect with a server. But where they are right now, I think some of the niceties that you would get with something like Next.js aren't there, because that hasn't been a priority yet. But we're seeing more and more of those things come into play, and again, as they add those features, and really target them, I think they're going to implement whatever they implement as good as anyone else from a framework perspective.

[0:13:49] SF: Yes, it's kind of a land in expand strategy in terms of, if you think about my go-to market, essentially. It's like, “Hey, we're going to do this one thing better than anybody else and we're going to capture some portion of the market that way.” But then, we need to also serve these more expansive use cases as we essentially generate momentum with the market. Do you feel like by maybe diversifying away from the original vision or what they were known for, by serving these other types of use cases, might take away from the quality of the framework or anything? Have you seen stuff like that? Or is it that they're just like really nailing the feature expansion as well?

[0:14:25] JQ: I don't have that concern. That certainly is a reasonable question for people to think about. I think it's inevitable that to gain user, or to gain, not notoriety, but gain like an audience, but also just like usability, I think they have to go the route that they're doing of incorporating and adding server-side rendering and those type of features. I think, I'm not concerned about sacrificing that first part because that first part, the statically generated part and the content integration, one, it's already gotten better. But it also is just so much better than anything else I've used, that I'm not – even if they stopped improving on that, they're still above the other frameworks in my mind.

So, I think they could easily divert a lot of attention to bringing that type of developer experience to more of the backend, full stacky things, and still have top-notch experience on the things that they were immediately or initially known for. So, it's not a concern of mine. It definitely is a viable concern for anything that goes beyond their initial thing that they're good at. But it seems like it's very incremental. So, it's not like they're just throwing on a bunch of new things and trying to force you to do things differently. They're adding on these things, and kind of chipping away to the point of adoption along the way is super easy.

Then, at a certain point, and I kind of feel like it's almost there, it's just in the running of like, do you choose Next.js? Do you choose SvelteKit? Do you choose Astro? It's almost there, I think, of being a really viable choice from a developer experience perspective across the board. And I think again, it'll just get better and better without sacrificing the initial stuff that they're known for.

[0:16:01] SF: One of the things that you mentioned was the built-in support for Markdown and how that just kind of works out of the box. One of the things that kind of made me think about was leveraging this framework for developer documentation. I think a lot of the freely available, or even open source documentation sites out there, that kind of, for actual professional business, you end up like hitting certain limitations with them where they just don't fully serve your needs. Then, you end up rolling your own at some point. You see that cycle with companies a lot, where they end up just making this a project that they have to build a support internally. Have you seen any momentum around using Astro for technical documentation for developers?

[0:16:43] JQ: So, I don't have specifics, but I think that's exactly the primary use case that they started with. If you look at technical documentation, a lot of that is probably written in Markdown anyway. And then you look at how do you piece all this stuff together in a nice way? Not only does Astro have support out of the box for Markdown, it has support through an integration with a one-line terminal commands at MDX. You have the ability to use either or. It also is a first-class citizen and like file-based routing. So, you can have like an index.astro. You can have an about.astro. Then, you can have a cooldocs.md in that root directory. And that coo docs is going to be like a hosted page just based on that Markdown file being there.

Those things built-in are just, I think, that's exactly what this is for. And occasionally, I do this on my site where if I don't need to do a whole lot with my site, I'll throw a new page up as a markdown or MDX file, and it like has all the content. It has all the things and it's already there. Then, I think some of the surrounding pieces of that are how do you optimize images, that's a big piece, and they have already gone from not having an image component to having one, to now, in Astro v3, making it even better, and being able to collocate images easier with Markdown files. And they also have the idea of the content directory and content collections. Maybe again, we'll dive deeper later on, or maybe it's time to talk about it now. But I think it's one of my favorite features by far.

So, content collection allows you, in a specific directory, to kind of list out all of your content. Blog, speaking engagements, whatever, and each one of those has a folder. In your config file, you define the frontmatter for each one of those using Zod to get TypeScript types. What that means is for a blog, you'll probably have like title, author, date, description, tags, that sort of stuff. And you can define that as a model using Zod to get TypeScript types. Then, built into content collections as well is query function.

So, give me all of the content associated with this content collection. Posts or speaking or whatever. They also give you like built-in query by slug. So, if you look at like, how do you – if you have a link, a list of blog posts, and then you go to the individual blog posts, you needed to get that specific blog post and all of its details to be able to render it. So, it has that already in place. Anyway, I think the short answer is like its primary use case, first and foremost, is to target exactly what you're saying, which is documentation. Again, having the flexibility to do many other things as well.

[0:19:05] SF: How's the query language work? What are you writing that in? Or can you kind of walk through, for example, the case of like, I want to pull this subset of a collection that, I don't know, has been tagged with this type of information or something like that?

[0:19:19] JQ: So, these are JavaScript functions, which I like. One of my hesitations in a lot of places is learning a new query syntax. That's something I don't want to do. I write JavaScript every day. So, if I can get a JavaScript function, that's much better. So, the two use cases that I do know right offhand are just like, give me all the posts and then give me post by a specific slug. I'll have to double or we should double-check offline what other functions there are for searching by tags. Again, this is a relatively small amount of content. I've been like queering the entire thing and then filtering in. It still runs on the server and or at build time. So, if it's a statically generated page, it's not 100% optimal, but it's running on the server at build time. So, doing the full query to get references to Markdown files and then filtering that is not a big deal. There might also be built-in primitives for filtering. I just don't know right offhand.

[0:20:08] SF: Unless your documentation site is, I don't know, hundreds of millions of ages. What are some of the things that you've actually built using this framework?

[0:20:18] JQ: Yes. So, my personal site, jamesqquick.com is with Astro. I would say there's nothing really fancy or special about it. I think the developer experience of just getting there is really nice for all the reasons that we said. It was an interesting transition. I had a Gatsby site. I was looking to move off of Gatsby. I was looking to move to Next.js and I was going through and kind of doing this migration and having to set up writing scripts to parse Markdown to the files, then actually parse the Markdown, and then convert it and get syntax. All these things. It just felt way too much. So, I went to Astro and it was like, all that stuff is done. I just basically copied over the content.

Anyway, so my personal site is that way. The site for my course, astrocourse.dev is built in Astro. Although both of those need to be updated to Astra 3.0, if people go check it out and want to call that out, I understand. But probably the more important thing is for the Astra courses demo, we get more into building what's considered like what I consider a supercharged blog. So, we do the first part of the course is just building a statically generated blog, that's fine. That's the stuff you expect. But the second part is getting into some cooler stuff where we take advantage of the server. So, we convert everything to server-side rendering. We had automated cover images with Cloudinary. So, those were able to like, for a given blog, take a base image and overlay the title of a blog posts on the base image, to create an OG image.

We also do authentication and comments. So, this was an important part of that, was the ability to show, “Hey, we can do authentication. We can track cookies. We can gate pages. We can determine what type of content to show on the page, based on whether or not the user is logged in. And then we can save data to a real database, handle form submissions, associate that with a user, be able to display that all the things.” So, you can build, I think that's like the core example of like, you could build a full stack application or just like CRUD application, whatever you want, with the backend, you could do. That's the best example of like going more full stack, I think.

[0:22:07] SF: You mentioned this course. What are the backgrounds, I guess, on the types of people that are signing up for this course? Are they coming from engineering backgrounds? Or people are dipping their toe in the water or wants to start their own, I don't know, store website or personal website or something like that.

[0:22:23] JQ: I don't have much information on the people that actually signed up. The way it's phrased is the experience level would be like HTML, CSS, JavaScript, like kind of core concepts, and encouraged to have experience with a framework. I think, if you have experience with any framework, most of what Astro does make sense kind of out of the box. So, I wouldn't be expecting someone to take the course that is new to programming. I think this is one of the topics that has a lot of buzz around it, but not a lot of super structured content like a course. There's another one coming out from another creator, which is super exciting. But that was the void that I was trying to fill with this course of being able to provide that structured content. But expecting people to have basic web development background, probably experience with a framework, looking to go beyond their existing experience by learning maybe another framework, maybe learning the backend, maybe this is people's first introduction to doing backend type stuff, which I love full-stack frameworks like this, because it gives you a gateway to understand more about the backend, without having to think you're doing the backend, in some ways. It's in a more easily accessible way, I guess.

[0:23:31] SF: Then, can we maybe kind of run through an example like, let's walk through the typical development workflow for like getting started with using Azure. Let's say I want to create my own personal website. How do I kind of go about actually doing that?

[0:23:43] JQ: Yes, so basic, on the documentation page, you can find like the Create Astro project. Then there's a couple things that you can do. You can start from scratch. You can start with a base template, and then they have starters as well. So, I forget, I think it's astro.new. Don't super-quote me on that. But they have templates that you can go and see. They’re in StackBlitz, et cetera. What I typically do is run the command in the terminal to create a new project that has the base template, and what it has is like a layout file, it has an index file for the page, and it has a component file that shows you the basics of how to do a component.

So, I would kind of start with that, then rip out what you don't need, and then start adding what you do. So again, page-based routing means, if you want an about page, you add an about.astro file in your pages directory. You can update your layout to do your SEO, meta tags, things like that. You can have any sort of shared layout pieces in there as well. So, if you have a header and a footer that are going to be on every page, you can do that. Then, most likely, what you're getting into this for is the content piece. So, this is where I would go in search just like what's the configuration for content collections. You create your content directory inside of the source folder. You create a content.config. What's the name of that file? Anyway, a config file. They'll tell you the name of the documentation, and they'll walk you through like how to create the types for the content that you're creating. Then, you create the folder for that content, start throwing in Markdown files or MDX or whatever. Then, you can consume and display that on an index page for blog. Or you can do dynamic routes where you're creating an individual route for individual blog posts, and be able to display those there.

From there, you can expand into like if you want to add JavaScript functionality of some, you can expand into bringing in React, or Vue, or Svelte, or something like that. You can also then start to see kind of like we said earlier, are there other things that I may need to do, like take advantage of the server for some reason? Let's say I have a newsletter subscribe where I want to take emails for a newsletter, I can have that send a form submission to my backend, handle that, use an API key to save that to whatever email provider I'm using, and now all that is safe. API keys are protected, et cetera, and I'm able to kind of chip away at adding the functionality that I need.

[0:25:52] SF: For something like a form submission for say, like a newsletter signup. How does – typically, you would probably store that information in some backend database. How does that work with Astro? Is there something out of the box available? Or is that something you have to like connect to MongoDB or MySQL or something like that?

[0:26:10] JQ: Yes. You definitely have to do your own connection, and it's basically like anything else. I don't know, like, Next.js may have something more configured because they now have their own database services. But the same general principle applies is you get access to code that runs exclusively on the server. And in there, you can do whatever you want. So, in my case, we're using a Zeta database, which is a really nice experience on top of Postgres, and they generate TypeScript types for your data, like, based on the models that you define in Zeta.

So, we have TypeScript types, they define a client for us, and then we can just reference that kind of do a query, or save, or whatever it is, inside of those snippets of code that run on the server. There's a couple different ways to do that. There's inside of a page file in Astro. It basically processes JavaScript code, and then renders a template with server-side rendering. So, it's going to run all this code before it then generates a template that gets sent down to the browser, which means when it's running that code on the server, you can do whatever you want.

One use case for this is I'm doing a newsletter. So, on the /newsletter page, inside of that page file, I have a condition at the top that says, if this request is a post request, do X, Y, and Z. From there, let's say it's successful, you can redirect them to a success page. You could also, if there was some type of error, you could do validation, and then send those validation messages back to the browser, so you can handle like the validation messages on the frontend or from the server, whichever you want. Anyway, you can do server-side code inside of the actual page components. You can also define actual API endpoints that are specifically meant to handle API requests and not render content to the screen.

[0:27:47] SF: I see. What about deployment? Are you left your own devices to figure out how to deploy this somewhere?

[0:27:54] JQ: It's kind of again, like every other framework that you would expect, I think, where they have – in Astro’s case, specifically, they have integrations or like plugins, basically, for the different platform that you want to deploy to. So, in my case, I typically deploy to Vercel and Netlify. If you're deploying a static site from Astro, you don't need any of that. It just happens automatically. If you're deploying a server-side rendered page or server-side rendered application, it needs those plugins to basically know how to translate that server-side code and the stuff that's going to work on those hosting providers.

So, there's several other hosting providers that probably people would expect. Netlify and Vercel are the two that I typically use. But you just add the integration with a terminal command, and it updates the config, and that's basically it. It takes care of the rest for you.

[0:28:39] SF: Okay. Then, you've talked a little bit about how Astro is essentially framework agnostic from the frontend perspective, and you can plug in Next.js, Vue, Svelte, anything that you want. How do you go about actually doing that? Is it just a matter of having, like you normally might do with a node application or something that? just reference essentially the JavaScript library from somewhere in the frontend? Or is there sort of an Astro framework-defined way of leveraging those different libraries?

[0:29:06] JQ: Yes, it's definitely an Astro-defined way. So, one big thing, and this was similar with Gatsby at the time. It had a great ecosystem of plugins. Astro is the same way. They call them integrations. So, it's one-line commands to add support for one of those frameworks that you want to work with. React, I think they have angular, but Svelte, Vue, et cetera, et cetera, there's several of them. So, that is an Astro-defined way. It's not you just throwing in a script tag and loading React from a CDN. It's through the actual framework, which I think is definitely a plus. Then, it's kind of interesting. This trips me up and I'm sure it's tripped other people up. By default, even if you do create a React component, import it into your Astro page component and display it, it's not going to send the JavaScript of React to the browser by default. So, this is intentional, again, because you want to opt in a JavaScript. So, when you define that you're going to have a component that is from another framework and you want it to include JavaScript, like you state, for example, in React, like anything that it does on the frontend. You need to annotate that with a property inside of your reference to that component in your Astro file.

So, you can do, I forget exactly what they are. But you can determine when and how to load that JavaScript so that you can make educated decisions, still focusing on performance in the application and shipping as little JavaScript as possible.

[0:30:22] SF: I see. So, you might have most of the page statically generated, and then have some piece of component that depends on React, for example, and then only that portion of the page, essentially, is going to – if it needs it, is going to pull in the JavaScript?

[0:30:36] JQ: Absolutely. And that is the epitome of what Astro islands is. So, this is another big buzzword with Astro is the ability to do exactly what you're saying, only pull in the JavaScript in the specific islands or like pieces of the application that you need to.

[0:30:50] SF: Okay. Then, is there any advantages to using certain types of frameworks? Frontend frameworks in combination with Astro? Is it better set up for using Vue versus React or anything like that? Or it doesn't really matter?

[0:31:05] JQ: As far as I know, it doesn't really matter. I've never heard of a talking point or experience anything that was better, one way or another. The general advantage of this is, again, you get to focus on zero JavaScript by default, and then add that in in the sections that you want to. Then also, it's not like Astro is asking you to completely buy in to another UI library or framework, whatever you want to call it. You have the ability to bring those components over. Like if you're migrating Astro from a React application or Vue, whatever, you could bring some of those things over directly without even taking advantage of some of the optimizations Astro could do. You could kind of just copy those over into your new Azure application and just reference them.

So, I think that's a benefit as well. I think there’s an also an interesting mix. Sometimes I don't have, quite have my mind wrapped around like some of the things that you would do in React like sharing state in a pure React application, versus how you would do that in an Astro and React application. I think some of those things get kind of interesting. But it is an advantage, I think, to be able to just pull in components from other frameworks that you've already created or worked on.

[0:32:06] SF: You've mentioned this concept of islands, as one of the speed and optimization features of Astro. I think Astro is well known for website performance. What are some of the other key features that are built into the framework in order to optimize for speed?

[0:32:20] JQ: Images is definitely one. So, there's been a couple of iterations of that. It’s not a new thing. It's kind of par for the course. I think it's something that frameworks typically just kind of have to have, are having more and more, is an image component that will do things like allow you to determine the size beforehand to prevent cumulative layout shift. I always struggle with phrasing that. You can also do different sizes of images. You can have different sizes, render on different-sized screens, like you would if you were using like the picture tag or source set, for example, and just regular HTML.

So, images, I think is a big thing. The other thing that I think is also very useful that we've already kind of talked about is not just the benefit of doing statically generated pages, but you also have the ability to do stuff on the server if and when you need to, which means less JavaScript running in the browser. So, if you have server-side rendering for authentication, if you didn't have server-side rendering for authentication, you'd have that loading state on the frontend, where we ship a page, then we have to determine if the users logged in. So, we have a loading spinner. Then, we show whatever the content is, or redirect them. We can do all that on the server, with Astro, which has been a big, I think, kind of movement for a lot of people of trying to do more on the server in general, which again, like things process faster on the server, then they're going through in the browser, most likely, and then also less JavaScript, shipped to the browser, as well.

[0:33:42] SF: What are some of the things that I need to be thinking about if I'm using this framework to make sure that I'm optimizing for speed? So, you mentioned potentially moving some of this stuff to the server side to take advantage of, essentially, the speed of server-side rendering, and probably the advantage of maybe a VARCHAR machine or something like that, versus running that directly in the browser? But what are some of the other things that from a strategy standpoint, I need to think abou? Or is a lot of this stuff just going to happen magically out of the box?

[0:34:07] JQ: I think the conversation for that is not specific to Astro, I guess. It’s what I'm trying to formulate in my head. So, the nice thing about Astro, it's not just that it does a bunch of magic to magically make it performant. It’s that by default, you start with performance first. So, you have to be intentional about where you opt-in with JavaScript and or server-side rendering if you want and need it. Just out of the box, you get the fully static experience, where you go through the build process, and then everything is just going to be shipped down from a CDN on request time. That, as a starting point, I think is really nice, versus and – I love Next.js. I don't like take this as a shot at Next.js. But by default, Next.js is still going to ship JavaScript to the browser. Other frameworks are going to do the same thing, basically.

So, I think just that being a starting point, and then having to make intentional decisions to bring in JavaScript by itself, is going to give you a better idea of when, where, how, and why to bring in JavaScript.

[0:35:02] SF: Then, what tips do you have or recommendations for anybody who's like trying to ramp up with this? Are there any kind of [inaudible 0:35:02], as you're a new person using this framework, people should be aware of?

[0:35:14] JQ: Not to be super cliché, but mostly the answer is no and that's the reason why it was so nice. I think, if you compare the server-side capabilities to something like Next.js or SvelteKit, that's been around and done more of that, or Remix or something like that. I think the niceties are not going to be there. So, although you can do it, I think it's nicer experience probably in other frameworks right now. I think that will change and continue to change and be a better and better story. So, I think that's something to consider.

I think there's also – I kind of mentioned this earlier. My mind hasn't quite wrapped around. If you're pulling in a lot of React components, if you're pulling in other frameworks, for example, how does sharing state for example, work between them? That's something I haven't quite wrapped my head around. So, if you're thinking that you're going to convert an existing React site and continue to use all the different things that you're used to, that may not be quite true. I also don't necessarily have the answers to that. So, don't take my lack of experience in that specific situation to mean it doesn't work. It's just something I haven't quite tried in depth, and then haven't had my mind fully wrapped around how that works. I think that could be tricky. 

I think the mixing of Astro components and Svelte components, for example, or other framework components can be tricky. There's one specific instance that I don't know if I'll be able to articulate now, where, if you use a React component, you can't import an Astro component into a React component. You can create a React component and import that into your Astro component. The reason that could be tricky is oftentimes I'll have Astro components that are like an H1 component, or a header component, or a navbar component, or a call out, whatever it is. And then I'll want to reference that thing inside of my React component, or Vue or Svelte or whatever, and you can't do that. So, from the other frameworks, you can't then import an Azure component. You have to think about when and where, intentionally, how you define the components and how you're going to share them.

The last thing that has bitten me a couple times is I mentioned this earlier, if you are using a React component or other library, you have to intentionally tag that thing HTML property wise, to say I want the JavaScript to load. Because by default, it's not going to load, and then it just looks like nothing happens, and you have no idea why. So, make sure if you are using one of the other library, UI libraries in an Azure app, that you mark those when you import them as you want to load the JavaScript.

[0:37:33] SF: So, you talked about, you're not sure, essentially how state management might work if you have like a fully baked react site, and you're porting it over to Astro. But is that maybe, if you have a really heavy React site with a lot of dynamic components, a lot of React components built in. Is that really a good use case for porting over to Azure? Is that something where you're trying to, I don't know, put a round peg in a square hole at that point. It's not the right way to be thinking about maybe leveraging this tool? It's better suited for other types of web experiences?

[0:38:05] JQ: I think if you were starting that thing from scratch, it would make more sense. But if you're already deep into the React ecosystem, like you've got a bigger react application. You're doing a lot of things. I think going to Next.js as a more natural transition makes sense. There's still benefits that you can get out of Astro. Because you get file-based routing, you get server-side rendering, you get statically generated pages. You still get all those things. Porting that to Astro, if you've got something really big in the React ecosystem is probably a challenge.

So, maybe going in that case that you mentioned, and going straight to Next.js makes more sense. But there are use cases for still using some of that stuff, and then just taking advantage of some of the features of Astro. It's almost in a weird way, it's not quite the same, and it's not quite as beneficial, I don't think. But like what Next.js offers for React, Astro can offer similar things for React and other libraries. But at scale, how easy that is, and how integrated it is, is still kind of an open question on my end.

[0:39:02] SF: All right. Then what are some of the situations where maybe Astro is not the right choice?

[0:39:06] JQ: I think if you're building something that's heavier on full stack and backend. Again, I think other frameworks have niceties already built in that the developer experience for those specific things are probably going to be better elsewhere. Like with Astro, you get kind of – you can write if it's a post request, look inside there, and get what you need and do blah, blah, blah, and that works. I think other frameworks just are probably a little better at that right now. So, that's, I think, probably the biggest differentiator is I would look at something like Next.js, SvelteKit that's been doing that type of thing longer. And Next.js is going through its big transition now with the new app router directory with React server components. There's a lot going on there, and a little bit of question marks of adoption for people. Again, going back to like, you have to be willing to adopt and or adapt, and learn new things.

I think if you're getting really into doing more backend stuff, it's probably a little easier and more comfortable to use something else like Next.js, just knowing that you can also do it if you wanted to in Astro.

[0:40:03] SF: Then, what are some of the upcoming features or developments that are happening in the Astro world that are worth mentioning that might be exciting to people?

[0:40:10] JQ: Actually, I can give you one. There's also one thing I want to shout out if I can get to it really quickly, is there's an Astro weekly newsletter that I just signed up for. It's not by me. Astro was doing a lot with Vue Transitions. This is kind of a new thing that I am not super educated on. So, I'll do a little bit here. I think Vue Transitions. I think what it does is kind of take screenshots. As you navigate from page to page, it takes a screenshot of the previous page and kind of fades in or does some sort of animation to get to the next page.

So, what are the downsides, potential downsides, limitations that I should have caught up earlier? By default, Astro is a multi-page application, which means you don't have any like load the next page in the browser. You're doing the full-page refresh to get the next page. Vue Transitions helps mitigate that by kind of showing the nice transitions between pages to make it look like, and I think it actually does happen on the frontend. So, it gives you kind of the spy experience, while also still taking advantage of like Astro as a framework.

Also, they have a way to do shared state between pages, and I haven't done this myself. But Vue Transitions in Astro comes with the ability to share state between pages. So, you can keep a cart in the top right as you navigate pages that keeps the number one icon to show that you have one item in the cart, for example. I think that's super cool. They also just made an update that I would have to go back in and like read. Anyway, Vue Transitions is something that they had been really innovative with, it works really nicely. I think it really is kind of showing the flexibility of Astro being able to address potential limitations, like the full-page refresh limitation that was before, and giving people the nice experience around it. So, Vue Transitions is one thing I will definitely keep an eye out for. I don't actually know what the next like big features are that they're working on. But I am excited, maybe just like everyone else to kind of hear more in the future.

[0:41:59] SF: How's the project supported? So, I know it's open source. But is it company-backed? Who’s funding this project?

[0:42:04] JQ: Again, not the best person to answer. I don't think it is company-backed in the sense like SvelteKit is backed by Vercel. So, Vercel employees were chairs full time to work on SvelteKit. I don't know what the situation is exactly for Astro. I'm almost positive it's not company-backed in that way. I think they have taken funding, but I probably should just not speak on that, because I don't actually know the details.

[0:42:28] SF: Okay. Yes, throwing you a curveball there. But as we start to wrap up, is there anything else you'd like to share?

[0:42:32] JQ: Just to encourage people to try it out. Selfishly, I have a course. So, there's like money involved there. But aside from the course, I think it's just a really awesome framework. I think it's super exciting what they've already done, what they will continue to do. I think they're focused on community and developer experience is really pretty special. So, I would just encourage people to take an hour and try it out and just see what it's like. Maybe I've seen lots of people porting their site over and like me, been really happy with the experience. So, give it a shot and see what you think. If it's something that interests you, do more with it. If not, there's also lots of really amazing frameworks out there. So, no real downside of just giving it a shot.

[0:43:05] SF: At some point, I want to replatform our website for my day job at Skyflow. So, maybe we'll take a look at the Astro framework to do that.

James, thanks so much for coming on the show. It's great to see you again. I'm sure we'll run into each other again at some upcoming developer conference. But for anyone who wants to stay in touch with you, what's the best way?

[0:43:22] JQ: Yes. So, James Q Quick on most social media. Twitter being the biggest one. Website is jamesqquick.com. I have a newsletter where I send out, typically weekly, although it's been a couple weeks. Newsletter, James Q Quick on YouTube. So, that's where I do the majority of my content, and yes, any combination of those things is probably the best one.

[0:43:41] SF: All right. Awesome. Well, thanks for being here and cheers.

[0:43:45] JQ: Thanks for having me.

[END]