Bryce Wray

Posted on Apr 24, 2022 • Edited on Jul 26, 2022 • Originally published at brycewray.com

Is Astro ready for your blog?

#webdev #astro #staticsitegenerator #javascript

(Photo credit: Kaitlyn Baker, Unsplash.)

Have you been considering the popular new Astro static site generator (SSG) for maintaining your blog, whether it be a new website or one you’d be converting over from another platform?

Having just moved my own site to Astro yesterday after a week or two of experimentation and grunt work, I can offer some opinions which may help you with that question. I’ll go through the “boxes” which I believe any SSG or other website development platform should “check” before you should give it a shot at this task, along with how I judge Astro’s ability to do so in each case.

Remember that Astro is still in beta, although the Astro team announced earlier this month that they plan for version 1.0 to go to general availability in June. For each item, I’ll assess Astro’s associated compliance or performance vs. that of a few other platforms I’ve used: in alphabetical order, Eleventy, Gatsby, Hugo, and Next.js.

Templating

Every SSG uses templating to render web pages. Astro templates are .astro files, which are an interesting mixture of (a.) “code fences” confined within front matter and (b.) HTML-mixed-with-JavaScript plus JSX, which combines JavaScript with some elements of XML. If you’re comfortable with JavaScript, you’ll find it fairly easy to make .astro files, but note that they constitute the only choice for templating in Astro. Here’s a small example:

---
import Head from '@components/Head.astro';
import Header from '@components/Header.astro';
import Single from '@components/Single.astro';
import Footer from '@components/Footer.astro';
import Billboard from '@components/Billboard.astro';

const { content } = Astro.props;
const { title, subtitle, description, date, lastmod, permalink } = content;

---

<html lang={content.lang || 'en'}>
  <head>
    <Head {title} {description} {permalink} />
  </head>

  <body>
    <Header />
    <main>
      <Billboard
        title={title}
        subtitle={subtitle}
        description={description}
        date={date}
        lastmod={lastmod}
      />
      <Single >
        <slot />
      </Single>
    </main>
    <Footer />
  </body>
</html>

Comparison: One of Eleventy’s claims to fame is how it allows you to choose from among multiple templating languages as well as vanilla JavaScript. Gatsby and Next.js templates are built with JSX. Hugo is the only one of these platforms that doesn’t use JavaScript or a variation thereof for templates; instead, the Go-based Hugo relies on a very different, Go-derived templating language.

Markdown

SSG-based blogs almost always have you add content mainly through use of Markdown, so how a platform handles that is particularly important. Astro incorporates both the well-known Remark Markdown parser and rehype tool, and uses plugins from both. Some Remark plugins aren’t compatible with the latest version but, often, a rehype plugin can make up for that. Be sure to check for your specific use case. Also, notably, Astro allows you to put components in the Markdown (I’ll get to components further down). For example, if you’ve already imported an ImageBox.astro component as ImageBox, you could have Markdown like this:

<ImageBox />

Update, 2022-07-26: Astro has since moved to using MDX, rather than Markdown, for including components in one's markup. Be sure to check the most current Astro documentation for full details.

Comparison: By default, Eleventy uses Markdown-it; like Astro, Gatsby and Next.js use Remark; and Hugo uses goldmark. As for Astro’s ability to mix components and Markdown on a page, probably the closest analogy to this is the use of MDX files in Gatsby and Next.js; Eleventy and Hugo can’t do this (however, see also “Components,” below, for some words on how Eleventy and Hugo use shortcodes which can provide some degree of code-in-Markdown functionality). Note that migrating an existing site to Astro from any of these other platforms probably will involve far more editing to your existing Markdown content than if you were migrating between two of the non-Astro platforms in this mix.

Who's in charge?

Astro is maintained and developed by not only employees of The Astro Technology Company but also the Astro community. This should be a desirable situation for the long term, since any choice to move your site to Astro means relying to some degree on the project’s being around for the duration. By comparison, many other open-source projects have languished because they amounted to “side gigs” for a small set of developers (perhaps just one) who, inevitably, decided the work wasn’t worth their time.

Comparison: For the most part, Eleventy and Hugo are one-developer projects although, of course, each such developer does have some help from within the community. Similar to how The Astro Technology Company is in charge of maintaining Astro, Gatsby and Next.js are maintained by development teams within the companies—Gatsby, Inc., and Vercel, respectively—that control these SSGs. Eleventy is somewhat of a hybrid of these two situations in that Netlify, the employer of Eleventy creator/maintainer Zach Leatherman, recently made Eleventy development his full-time job.

Asset pipeline

Astro began life with Snowpack as its asset pipeline, which makes perfect sense given that the two projects came originally from the same development team. However, the developers soon reached the decision that Astro would be a better product if it used the impressive Vite package, instead. While the resulting switchover was a breaking change with a capital BC when it occurred, the capabilities it unlocked have proven the exceptional wisdom of this choice.

Comparison: Eleventy has no built-in asset pipeline, so crafting one is pretty much left to the user. Gatsby and Next.js process assets by building in the venerable webpack bundler, thus taking on all the advantages and disadvantages thereof. Hugo has its own asset pipeline, Hugo Pipes.

Developer experience

Building in Astro can be both pleasant and, occasionally, a little frustrating, so it’s a mixed bag where DX is concerned. The “pleasant” part is the relative straightforwardness of the code, especially if you’ve ever dealt with Next.js, although you will have to get used to those code fences in Markdown. As for the “a little frustrating” part, larger sites don’t refresh all that quickly when you edit either Markdown or an .astro file, although styling changes seem to show up pretty quickly. I think this is because, at this early point in Astro’s life, its team is still working out the kinks on Astro’s interaction with both Markdown and Vite.

Comparison: Where pleasantness of the coding experience is concerned: Astro and Eleventy probably tie for first; Gatsby and Next.js are in the middle of the pack; and Hugo, with its newbie-unfriendly Go-based templating, comes in last. (I doubt seriously that newbies are going to be familiar with Go.) However, where refresh-in-dev-mode speed is concerned, it’s a different story altogether: all the other competitors currently have an edge on Astro for this item, with the stunningly fast Hugo obviously leading the pack.

Documentation

Astro’s documentation, like Astro itself, is still in its early phases and gets changed a lot; but I’ve found little trouble in following it. If you’ve absolutely never coded before, you might find it daunting; but, then, that would be true for any of these SSGs.

Comparison: I’d rank the competitors’ documentation in the following order: Next.js, Eleventy and Gatsby tied in the middle, and Hugo.
That said: for all of these, I’d urge you to keep your favorite search engine a browser tab away, because there’s no such thing as SSG documentation which doesn’t have gaping holes—particularly since the SSGs’ developers end up writing a lot of the documentation and, after all, they already know how their products work, so they can’t accurately anticipate all the questions and misunderstandings that novices will have.

Styling

Astro has no built-in support for Sass¹ or Tailwind CSS, but accepts the usual packages to provide either. You can, of course, use vanilla CSS with no add-ons whatsoever.

Comparison: The same is true for Eleventy, Gatsby, and Next.js. Hugo has built-in support for an older, deprecated form of Sass, and needs some help to work with the current versions of Sass and Tailwind.

Correction: Ben Holmes of the Astro team (see the “Components” section further down) reminded me on Discord that Astro does offer an official integration for Tailwind CSS. Thanks for the catch, sir!

Hydration

You may have been hearing a lot in recent months about something called partial hydration. It’s extensively explained in Astro’s documentation thereof, but here’s a quick-and-dirty try at my own explainer.

The concept of hydration involves sending out code which, on arrival at the browser, gets hydrated with data (think of how astronauts used to immerse freeze-dried food in hot water to make it edible). This makes it possible to convert a static web page to a dynamic one. The problem is that websites built on JavaScript-based platforms, until now, typically have dumped a lot of JavaScript code to be hydrated on their visitors’ devices, causing so-so performance and a less-than-satisfying user experience. The idea behind partial hydration is to let the developer choose to deliver only that JavaScript which is absolutely necessary, thus optimizing performance and the UX. Of these SSGs, at the present time, only Astro is capable of partial hydration out of the box.

Comparison: Eleventy has always been an as-little-JavaScript-as-you-want package in the first place; however, it can both include components (about which more, shortly) and partially hydrate them if it’s equipped with the Slinkity plugin. Gatsby and Next.js have no such feature; indeed, what they do is exactly the Bad Old Thing for which partial hydration is a remedy. Hugo by default provides no JavaScript, period; still, it, too, lacks any partial hydration capabilities regarding any third-party JavaScript you might bundle through its Hugo Pipes asset pipeline.

Components

Another of Astro’s most widely touted capabilities is how it enables you to use components from multiple JavaScript frameworks. Other SSGs which support component-based development out of the box are tied to just one framework, so this flexibility may move the needle for you if you don’t want to be tied to just one ballgame.

Comparison: Gatsby and Next.js support React components. You can use the aforementioned Slinkity package with Eleventy to enable Astro-like support for multiple frameworks’ components. (I suspect that’s a big part of the reason why The Astro Technology Company recently hired Slinkity creator/maintainer Ben Holmes, who has suggested that he may hand off Slinkity once it achieves its upcoming v.1.0 release.) Although Eleventy-without-Slinkity and Hugo technically don't use components², it’s been argued that their respective support for shortcodes can provide much of the same functionality. Even if that’s true, your success with either SSG on this score could depend in large part on your own ability to develop those shortcodes.

Dependencies-handling

Astro is a Node.js package and, within sensible limits, works with pretty much all the Node packages you can throw at it, at least so long as you’re willing to handle the necessary configuration and, of course, maintain all the resulting “turtles-all-the-way-down” sets of dependencies (not to mention those included within Astro itself).³

Comparison: The same is true for Eleventy, Gatsby, and Next.js. Hugo is a single binary and doesn’t use plugins, but many of its capabilities still come from external dependencies—which, in Hugo’s case, are baked into each Hugo release rather than being user-installable (and -choosable). You can add Node modules to a Hugo project (as in the aforementioned addition of Tailwind CSS v.3), but it’s not always possible to use them to override any of Hugo’s baked-in dependencies.

Image-handling

There is no official Astro solution for working with images, but Astro ImageTools gives Astro the ability to provide optimized, responsive images.⁴

Comparison: Among Eleventy, Gatsby, Hugo, and Next.js, each has either built-in functionality or official plugins for working with images. This was once a huge point of differentiation for Gatsby, but the others have pretty much caught up with it for all intents and purposes.

Data-handling

Astro's built-in data-fetching abilities make it relatively trivial to pull data from either remote locations or just your own site. In fact, that’s how you populate many commonly used variables, such as other pages’ URLs and titles. If you’ve used the Node.js fetch command, you likely will find Astro’s technique pleasantly familiar.

Comparison: There are similar ways to do this with Eleventy, Gatsby, Hugo, and Next.js. While I would argue that it’s somewhat easier with Astro than with the others (Next.js’s data-fetching methods and related code are the most similar to Astro’s), that’s really subjective—with one notable exception. Gatsby’s use of GraphQL makes its data-fetching powers impressive but overly complex to use, and its dependence on GraphQL for so many capabilities reminds me of the old saw that "if all you have is a hammer, everything looks like a nail."

Community

Astro’s community, as I’ve found when spending time on its Discord, is an amazing, welcoming, cheerful, unfailingly helpful, and kind bunch.

Comparison: I would say Eleventy’s community pretty much ranks with that of Astro’s, although the former’s Discord doesn’t seem quite as active; of course, this may be true at least in part because Eleventy is a more mature project, while Astro is still “busy being born,” as Bob Dylan once put it. I can’t say much one way or the other about the communities for Gatsby or Next.js, which exist more within their respective GitHub repos than in anything like a Discord. As for Hugo and its Discourse instance, I strongly suggest thoroughly searching not only the Hugo documentation but also the web in general before asking a question or making an observation there—and that’s a totally fair expectation for the purposes of lowering the so-called signal-to-noise ratio.

Feeds

At least for now, Astro clearly falls short in this category. Its built-in ability to provide RSS feeds is rather limited, and it doesn’t yet enable JSON feeds at all.⁵ In the meantime, some users, including Yours Truly, have gotten around this by using the third-party feed package, which supports RSS and JSON feeds.⁶

Comparison: Eleventy and Gatsby use plugins to provide support for RSS and JSON feeds. Hugo natively provides an RSS feed and, with a little tinkering, it’s fairly easy to make a JSON-feed-savvy version of the built-in RSS template. Next.js provides no capability (built-in or otherwise) for either RSS or JSON feeds so, as in the case of Astro, you’d need to use feed or something similar.

SSR

I waited until the end to deal with server-side rendering (SSR), primarily because I doubt most personal sites will need it. Still, if yours does, Astro recently gained this ability, albeit for now on an experimental basis. It works by using adapter software in conjunction with a growing number of Jamstack-savvy hosts.

Comparison: Eleventy has no SSR capability out of the box, but can gain it via the project’s official Serverless plugin. SSR has long been part of the picture for both Gatsby and Next.js. Hugo, as the only non-Node.js SSG in this lot, doesn’t do SSR; and, to my knowledge, there are no plans for that to change.

Checkbox checkmate?

So what’s the bottom line? How do all the checkboxes line up? In my admittedly subjective opinion:

Astro definitely is ready to take on your site. I wouldn’t have migrated my site to it had I thought otherwise. It’s already quite capable; and, especially given some of the ideas and conversations I’ve seen floating around the Astro Discord, I think not only that Astro will gain even more features, soon, but also that its dev team will address the relatively few nits I raised herein concerning DX (and, perhaps less important, feeds).
If you’d rather stick with, or start with, platforms that are more mature than the nascent Astro, my judgments from my 2020 piece comparing/contrasting Eleventy and Hugo still stand. Either will serve you well. Just decide which you prefer: a better OoTB experience (Hugo, especially with a good theme that helps you avoid getting under the hood until you're ready to wrangle Go), or a more open and customizable experience (Eleventy with its category-leading templating flexibility).
With the exception of its current slow refresh rate in dev mode, Astro already offers a great deal of the pleasant DX that originally made Next.js so compelling; yet, thanks to partial hydration, Astro has none of Next.js’s built-in tendencies toward code bloat. Next.js may be perfect for corporate sites built by IT departments with React “shops,” but it falls short for a personal site.
And, frankly, my dear, Gatsby lately has been falling off many developers’ radars to the extent that, I think, its time in the sun has come and gone. You can do better with any of these other platforms.

Astro had built-in Sass support until v.0.23.x. ↩
If you use the CloudCannon CMS with Eleventy or Hugo, CloudCannon’s open-source Bookshop tool allows component-based website development. ↩
To see the levels of dependencies within a Node.js package, visit the Anvaka visualization site—but be sure you have some time to spare, especially if you try it with any of these Node.js SSGs (particularly Gatsby, which I’ve read can crash Anvaka on some browsers because of this SSG’s vast layers of dependencies). ↩
Also, for that matter: if you prefer, you can always write your own component for these purposes. In converting my site to Astro, that’s what I’ve done, using my existing Eleventy and Hugo image-handling shortcodes to build an Astro component. I did so chiefly because I use Cloudinary to manage my images and, frankly, I liked the way I was already doing so in those other SSGs. Cloudinary does all the image-processing, so all I need to do is provide the appropriate special transformation URLs in the site's HTML. ↩
I hope that, in the near future, the Astro team will make it possible for .astro files to produce files that end in .xml or .json, thus allowing for full customization of feed files. ↩
I haven’t yet learned how to parse (in a non-.astro file) the Content object that results from fetching a post, and a JSON feed must have either content_text or content_html. For the time being, with feed, I’ve made do with a post’s description, which I was able to derive from fetched front matter. Update, 2022-05-01: Ernesto Lopez’s article, “Astro — markdown content,” describes how to obtain HTML from an Astro site’s Markdown files; but, unfortunately, that HTML lacks the processing of components imported therein (e.g., a component import like the <ImageBox /> example from earlier would be rendered only as the actual text, <ImageBox />, rather than the results of that component’s activity). Thus, I must continue to wait until there is a way to get RSS and JSON feeds from .astro files. ↩

DEV Community