Our experience with Astro
Tags: astro, javascript, webdev
Published: 2021-07-09 17:10:22

We built [divRIOTS.com](https://divRIOTS.com/) with [Astro](https://astro.build).
"Here we go, another framework is out and another dude is making a website and blogging about it"

Let's see if we can make this interesting. 😉

## What is Astro?

If you already know [Astro](https://astro.build), you can [skip to the next chapter](#why-we-choose-astro).

> [Astro](https://astro.build) is a Static Site Generator (SSG). Build your pages in `.astro` files (very close to HTML/JSX) and sparkle them with React/Vue/Preact/Svelte components. It deals with file-based routing and templates neutrally. Bring your component framework. <cite>In my words</cite>

There is more to it. See [Astro's introduction blog post](https://astro.build/blog/introducing-astro).

And if you have time, there is a [90min video and Transcript](https://www.learnwithjason.dev/ship-less-javascript-with-astro) about it.

## Why we chose Astro

> Not because it's the new/latest shiny framework 😀

I shared my thought in April when I first saw [Astro](https://astro.build).

{% twitter 1380801812656226304 %}

When it was time to develop the new [divRIOTS.com](https://divRIOTS.com/) website, we searched for the best option.

Our requirements were:

- **Simple** - It's not going to be a massive site.
- **Runs on JavaScript** - Ecosystem we know well.
- **Generate 100% static HTML** - Good performance, good SEO.
- **File-based routing** - Very convenient
- **Allow component-driven development** - That's how we like to build
- **Markdown support** - For the blog posts

There are [many static site generators](https://jamstack.org/generators/).
But, believe it or not, there aren't many options matching our requirements.

Most component-driven options will come with some relatively heavy JavaScript
payloads for [hydration](<https://en.wikipedia.org/wiki/Hydration_(web_development)>), even if the content is 100% static.

On the other end, truly JavaScript-less SSG will use template-engine like [Nunjucks](https://mozilla.github.io/nunjucks/) or [Liquid](https://shopify.github.io/liquid/). They are amazing options but it's another language and another paradigm. Not component-driven.

> We just wanted a good Static Site Generator with a JavaScript Developper Experience and 100% HTML output by default. And [Astro](https://astro.build) is precisely that.

## Pure Astro

[divRIOTS.com](https://divRIOTS.com/) is built in 100% [Astro](https://astro.build).

No [React](https://reactjs.org), No [Vue](https://vuejs.org), No [Svelte](https://svelte.dev), None of the [partial hydration](https://github.com/snowpackjs/astro#-partial-hydration) or [islands](https://jasonformat.com/islands-architecture/) capabilities of [Astro](https://astro.build).

Just `.astro` files.

> You don't need to use the cutting-edge hydration capabilities of [Astro](https://astro.build) to already benefit from it.

[Astro](https://astro.build) comes with an elegant component model and a solid CSS pipeline with Scoped CSS, CSS Modules, and Sass support.

OUT-OF-THE-BOX.

## Underrated feature

> [Astro](https://astro.build)'s CSS Bundling is probably its most underrated feature. It never makes it to the headline but it's by far my favorite!

In [Astro](https://astro.build), you just layout `<style>` tags in your astro components where you need them and add lists of `<link ref="stylesheet">` in your `<head>`.

For example, [divRIOTS.com](https://divRIOTS.com/) uses 2 global css in `<head>` in the most idiomatic way.

```html
<link href="/css/reset.css" rel="stylesheet" />
<link href="/css/global.css" rel="stylesheet" />
```

None of these `.css` files are minified and calling them separately doesn't provide the best performance result.

But when built for production with `astro build`, `<style>` tags and `<link ref="stylesheet">` are minified and bundled automatically.

- If a style only appears on one route, it’s only loaded for that route. (`/_astro/[page]-[hash].css`)
- If a style appears on multiple routes, it’s deduplicated into a (`\_astro/common-[hash].css`)

In production, pages have:

```html
<link href="/_astro/common-[hash].css" rel="stylesheet" />
<link href="/_astro/mypage-[hash].css" rel="stylesheet" />
```

`/_astro/common-[hash].css` is the same on every page. It's cached and not re-downloaded during navigation on the site. It's hard to have a better result.

This means that I can write styles the way it makes sense for readability and maintenance and let `astro build` take care of best performance.

> I don't know any static site generator capable of doing [pure] CSS Bundling and minification so seamlessly.

More details in [Astro's Styling Guide #bundling](https://github.com/snowpackjs/astro/blob/main/docs/styling.md#-bundling).

## Performance results

The output is 100% optimized HTML/CSS. It's hard to be slow 😀

![Mobile performance results (98)](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/g0suko3raqa4kyt3rpcl.jpg)

![Desktop performance results (100)](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/inc12nwi92x87vpy684a.jpg)

## What's missing in Astro

In my humble opinion, not much. [divRIOTS.com](https://divRIOTS.com/) is proof of that.

But here is my wish list:

### JavaScript processing

Like [Astro](https://astro.build)'s CSS Bundling, I would like my `<script>` tags transpiled, bundled, chunked, and minified in the best possible way.

- Transpiled : I can write ES202X code and get a more compatible output.
- Bundled : I can import bare modules from `node_modules`
- Chuncked : If modules are used on many pages, move them into a single `common-chunk.js`
- Minified : Everybody wants small JavaScript - always.

With this, I don't need a [webpack](https://webpack.js.org/) or [gulp](https://gulpjs.com/) configuration on top of [Astro](https://astro.build).

[GitHub issue #370](https://github.com/snowpackjs/astro/issues/370)

### Image processing

Like JavaScript, image optimization is another fairly complex build process to add on top of static site generators. Having out-of-the-box support would help get maximum performance with minimal effort.

[GitHub Issue #492](https://github.com/snowpackjs/astro/issues/492)

### "Permalink” for certain pages

Today all pages are generated as `/slug/index.html`, but some pages need to be generated as `/slug.html` instead. Like `/404.html`.

[GitHub Issue #465](https://github.com/snowpackjs/astro/issues/465)

## Closing thoughts

> [Astro](https://astro.build) is more than a SSG

As described in [my tweet about Astro](https://twitter.com/georges_gomes/status/1380801812656226304), another compelling feature of [Astro](https://astro.build) is his neutrality to frameworks.

[Astro](https://astro.build) takes care of routing, layouts, data management and SSR infrastructure and you can bring your components from any other framework (currently [React](https://reactjs.org), [Vue3](https://vuejs.org), [Preact](https://preactjs.com), and [Svelte](https://svelte.dev)) but still keep zero JavaScript runtime on the output if you want.

It makes your site last longer as component frameworks come and go. It also makes your component last longer as you don't need to migrate them from one framework to another. Just use them as long as you want.

I called [Astro](https://astro.build) an "Agnostic Meta-Framework". And I think we will see other solutions emerge in this space because it makes a lot of sense to decouple the meta-frameworks from the rendering libraries.

## Another Astro website is coming up

[Backlight.dev](https://backlight.dev), our upcoming product to build and manage Design Systems on the code-side, will be revealed soon.

The full landing is also made in [Astro](https://astro.build) but taking it to a whole new level 🚀

> Stay tuned!