This site’s been on Next.js since 2021, and I’ve had very few complaints about it. I’ve appreciated things like its slick developer experience, the first-class support it enjoys from Vercel for features like incremental static regeneration, and the constant innovation driven by its community. It’s a great tool, and my high view of it hasn’t really changed since I first took it on.
But after many months of waiting for the hype to cool down, I decided to try building an integration for JamComments. I was floored by how easy it was. So, I took the next step and moved over my entire site. As I made that migration, I began to mentally organize some of my favorite things about the framework. Here they are. Keep in mind, these items don’t take into account the breadth of what Astro can do. It only considers what I encountered in migrating over my personal blog.
I was a victim of the Gatsby.js hype a few years ago. It was one of the first React-based static site generators with some momentum behind it at the time, and it also went all-in on using GraphQL as the protocol that supported its “content mesh.” These bold opinions and big words wooed me and several others, making us completely blind to the overabundance of complexity the approach brought with it. It didn’t take long for the excitement to wear off and the overbearing friction to become apparent.
Next was better. It didn’t care about how you sourced your data, so long as you did so using hooks like
getStaticProps() within a file that exists inside the
pages directory. (This was before the entrance of React Server Components and Next 13+ that permits you to collocate your components & data fetching.) Still, there were some moments when I wished I could break free from those constraints a bit.
Astro takes it multiple steps further, however. There’s no particular function I need to export. In fact, I don’t need to use a separate function at all — top-level
await is supported out-of-the box. All I need to do is set my variables and use them in my template. Done.
const response = await fetch('https://an-endpoint.com/api');
const data = await response.json();
Crazily enough, you can even do stuff like this (stolen straight from their documentation):
I imagine many don’t find this prescriptive enough. There are probably very good reasons to be wary of the risk this introduces for shooting yourself in the foot. But for a dude just looking to build a simple blog, I highly appreciate this freedom.
#2. There’s first-class (or readily available) support for integrations to take care of the boring stuff.
It’s easy enough to spit out some posts and pages. That’s the fun part. But if you’re going to build a site that’s syndication-ready, SEO-friendly, and as fast as possible, you also need worry about things like RSS feeds, sitemaps, and asset optimization. In my opinion, these are pretty boring processes to set up.
These are things that Gatsby, with its rich ecosystem of plugins, does well. If it doesn’t have an official plugin available, there’s likely one supported by the community at large. I recall relying on these plugins for my sitemap, image optimization, and RSS feed with little issue. And for the things they didn’t directly support, there was often dedicated documentation on standing it up on my own. Like how to build an SEO component for my blog.
Next, however, has some room for improvement. To be fair, I don’t believe Next has ever billed itself as a content-focused framework to the same degree as Gatsby. At any rate, I remember it being more than trivial to get my site going with these must-haves. I ended up rolling my own sitemap and RSS feed (with the help of a couple other dependencies), and I believe I built my own component to handle basic SEO configuration after seeking inspiration from some other blogs.
Doing all of this with Astro was pretty darn straightforward. It has official support for things like generating a sitemap, exposing an RSS feed, and optimizing images. And for stuff like managing SEO meta data, some pretty good open source packages exist. In the end, there wasn’t much pain in setting up these non-negotiables.
But there’s more available in Astro to aid in strong site performance too. It’s been really pioneering its “islands” architecture, which allows you to easily opt into client-side interactivity on a per-component basis. But even if you don’t go that route, you’re free to use a good, ol’
<script> tag in any of your components. Each of them will be automatically hoisted, deduplicated, and optimized on build. So, where interactivity is needed, it’s easy enough to sprinkle it in without a huge impact to your bundle. You get the banana without the gorilla.
This is a smaller one, but still something I really admire. Much of Astro’s lower-level API is based on web standards, which makes the learning curve a little smoother. For example, the
Astro.request object is just an instance of Request. You can freely use
fetch() for retrieving any data. Its server-side rendering mode depends heavily on basic Response objects.
For my migration, I didn’t use these a whole lot. Even so, in a world where frameworks run rampant and so many tools are introducing new DSLs and syntax, it’s refreshing to have something so fundamental to the web remain consistent.
This post will likely need an update at some point, because I’m admittedly still in the honeymoon phase. So far, there really hasn’t been much of what I’d like to see changed or introduced (aside from built-in support for parsing remote Markdown). But that’ll undoubtedly shift as my site does. That said, I don’t recall feeling quite the same way about first adopting Gatsby or Next. For both of those tools, despite enjoying the experience and being generally pleased with the result, I always felt a tinge of guilt at the end of the day, mainly because I knew there was so much code being sent on every page load that my site didn’t really need.
So, yes, I could be caught up in a haze of hype as I continue to dive into Astro. Or, maybe it’s actually a tool that has finally struck a good balance between developer experience and build quality. Time will tell.