Why we use Astro

Server first and performance driven

The purpose of Astro is to enable building performant content-driven sites and that’s clearly reflected in their framework’s functionality. By default, the framework’s build step takes your source and generates static, zero-Javascript HTML for you to deploy, leading to the quickest user experience.

For our use case, that’s a great fit, since we don’t need a lot of interactivity to share pricing insights. We simply rebuild pages when we have new contributions, so that the freshest data can be delivered quickly. And when we do need styles or client-side Javascript, they’re scoped and bundled smartly into just the pages that need them.

Built-in support for content

Astro comes with its own set of Content APIs, which enable type-safe access to datasets in a consistent way regardless of their source. Writing a blog article (like this one)? Store it as an mdx file in your repo. Have some tabulated data that you want to reference? You can store that as a JSON file - and the API to access that content remains the same throughout your application, making it easy to switch based on your needs.

There’s plugin support if you use a CMS, and you can reference other databases however you like. The Astro team recently announced they’re working on extending Astro’s Content API to cover those data sources too, so in the future these will start to look just like your other content (if you want them to).

In our case, we store all of our content into these collections. We use YAML for our structured data like category hierarchy and derived pricing insights and Markdown for all our rich content like blog posts.

Smart defaults and escape hatches

Astro comes configured out-of-the-box to build blazing fast static sites. But I found that if you want to make richer experiences and need something more, Astro makes it easy to do so.

Need to do some server-side rendering to customize a page’s content per user? You can opt into that functionality on a per page basis with a simple export statement, like on our contribution page. It smartly streams HTML content to the browser, so if you have a component near the bottom of your page powered by a hefty database call, it won’t block the rest of your page from rendering. Neat!

Want to include richer interactivity with a UI library? Astro’s islands architecture allows for you to render those components into specific sections of your site and gives you control over when to load them. We use this to render the account management dropdown in the header of each page based on whether you’re logged in.

Growing support and adoption

While still a relatively new framework (at least by Javascript standards), Astro’s foundation is built upon other mainstream libraries, such as Vite. It’s in active development, with solid documentation, and an active community. I mentioned earlier that it’s building in popularity, and the backing of Vercel, storyblok, Sentry, and sponsors helps to build my confidence in the project even further.

Significantly faster developer experience (for me)

This is the biggest selling point but also the most personal. I feel much more productive building in Astro than I did in other frameworks for a project like this. Astro comes with Typescript support by default, and with the installation of a VSCode plugin, it was easy to get Intellisense up and running.

The majority of my experience on the frontend is in React, but making components in Astro is very similar. They’re easy to build, compose together, and with Typescript support I can reuse and refactor them, confident that each is wired up correctly.

There’s a robust library of plugins and guides, making it easy to add Tailwind support, deploy to over 25 different infrastructures, handle form submissions, and much more.