Astro is my daily driver for creating websites in my freelance web development business, and I wanted to highlight the tool for anyone unfamiliar, and also to get readers acquainted easily to the code. I will have a second blog post on the usage: here.

Overview

Astro is a really lovely, well-thought-out framework for creating websites with little to no Javascript client-side. It uses Vite under the hood, with all the yummy features like CSS Modules, easy PostCSS, static route generation, and built-in SCSS. Astro is primarily a static-site framework because it builds everything into static assets to be served. The Astro team is leveraging a lot of SSR capabilities to not only optimize page load speeds but for using a full SSR implementation (in beta as of writing this).

It enables an "islands" approach to each component; each component created by default doesn't have any Javascript attached to it, forcing the developer to opt-in each component that needs some client-side code. When developers opt-in for JS, they have their own option for using a JS framework like React, Vue, Svelte, SolidJS, or just Vanilla with just a simple renderer installation with a CLI command like: astro add react.

Quick Background

I took up Astro the instant I discovered and read what makes it unique, because it fit into my development really well. Gatsby initially fulfilled this role of static-site generation for my small business clients, but discovering Svelte and SolidJS broke the React paradigm for me. By offering all modern capabilities of a major framework such as Gatsby (with the exception of the beta SSR), but with barely any runtime JS and a ton of flexibility. SolidJS is essentially what drove me to Astro, as it was one of the only ways of creating a MPA using SolidJS (at the time).

Page Load Comparison To NextJS

Astro mentions its benefits on its documentation site, but it's better to see a direct example for the statistics. I created the exact same basic website using NextJS and Astro. Here is the example website with each corresponding Lighthouse score.

For the purposes of consistency, I used the Image component per designated framework as an obstacle for page load, a simple external SCSS stylesheet import, and the SolidJS renderer installed for Astro. With the SolidJS renderer in Astro, anyone can literally do anything React is able to do (there's always vanilla, but just for React-fans).
For consistency, both websites are created:

• From templates taken directly from each framework's official documentation website.
• With Lighthouse audits executed on a Chrome private window to remove possiblities of extensions interacting.
• With a cleared cache every test.
• Using CSS Modules and Sass.

Out of the box, it's a bit surprising that such a simple website with only semantic HTML elements, and a dynamically presented image can show such a stark difference with frameworks (and let's not mention how we have to clarify a _document.js file for lang="en" for NextJS). With a previous project of mine, I used NextJS because it simply scored better in Lighthouse, being a more mature framework. But just as Astro surmises on their documentation site, it's all about content. And clearly, Google is heading in the same direction.

That's crazy.

The circled scores above are the most pivotal stats: Astro scoring and average ascore of 98ms, versus NextJS scoring values between 600 and 1000ms. Even viewing the amount of resources used for such a basic site is pretty shocking. Two big factors affecting these are React itself in the bundle, but perhaps Vite as well. Webpack looks remarkably sluggish compared to newer HMR bundlers. And speaking of bundlers, this Astro site would probably take around 6 seconds to build, costing the developers and clients even less for hosting.

Routing Patterns

Astro, like many modern frameworks nowadays, have a static file route option for easily creating pages. In the /src/pages/ folder, each .astro and .md file is automatically created into a page. For anyone familiar with NextJS's approach to this, it is exactly the same, particularly with dynamic routing using syntax like [blogPost].astro.

One perspective Astro takes, is clarifying layouts for use of pages. It's essentially just parent components that receive children components, and typically span or inherit the html, and head tags. NextJS's equivalent is a very special and particular approach by using proprietary <Head/> and _document.js tools to optimize its page load. Astro proves, if you keep it simple with great tools, these types of workarounds aren't necessary. In Astro, keep your <head> tags as they should be, and nest your components like you normally would.

Styling

CSS modules are natively supported in Astro, and are a great option for building, but Astro also has a built-in style method that assesses CSS from within a style tag inside the Astro component it belongs to. This style below is only applied to this specific component. There is a method of making this global if you need to though. Here's the example:

<button class="special">Button</button>
<style>
  .special {
    outline: 5px solid blue;
  }
</style>

Ease

Astro's team has offered really handy CLI tools for perpetuating their integrations idea of Astro's. Integrations are pretty much the same as any other frameworks' "plugin" system, with just a yarn astro ___ command. The integrations make it extremely easy to install Tailwind, SolidJS, native SSR tools, and more. I see this as very similar to Gatsby's plugin system, especially when/if the ecosystem expands in the future.

Misc. Built-In Tools

• Markdown
  • Out of the box, Astro natively supports Markdown, with even MDX-like capabilities for placing in custom components.
• RSS support
• A flexible Code component with tons of language support
• Powerful directive configurations for finely splitting code.

Check out the official Astro docs for more!

I'm planning on making an Astro primer article next for to make it easy for someone to jump in!