Learning Astro

I’ve probably spent the last twoish years designing & building apps with React. So when contemplating on what I want to use for building my new portfolio, I settled with Astro as it was something I was meaning to get into and the fact that it’s perfect for static sites.

Features

So what does Astro offer? To name a few, according to Astro, they provide:

1. Great SEO.
2. Server-first by rendering the HTML on the server.
3. Fast loads due to zero JavaScript being sent to the user by default.
4. Great customizability with integrations.

Familiarity

Whether you’ve built sites with plain HTML, CSS, and JavaScript, or a framework like React, writing Astro code should be very familiar. The .astro file is very similar to writing Markdown, in which there’s 2 main sections, the Frontmatter & the Body:

1. The Frontmatter where metadata would typically be placed. Instead, this is where we can import content from other files and do some data manipulation/preprocessing that will only run at build-time (if the page is statically generated).

2. The Body contains the content that’s rendered and displayed to the user. This is where we can put any HTML, <script /> tags, or components built from any of the supported UI frameworks.

Speaking of familiarity, Astro provides the ability of taking what you learned and integrating it with your Astro code with the help of Integrations. These integrations provide access to using code written in a different Framework, or styling with Tailwind CSS if efficiency is your thing. If Astro doesn’t officially support an Integration, someone in the community might have made one.

Refreshing

I believe that the more you code, the more likely you end up sticking to a single pattern, which may be either good or bad. Astro really made me reconsider how I was coding with its single component per file approach. With single component approaches, you have to think about the ease of reusability and extendability (ie: simplicity and minimalism is key). After writing Astro components, I really feel that I’ve been overcomplicating things in my recent projects and should consider rewriting the components to be way simpler.

Another blast from the past is its file-base routing strategy that I find appealing, and reminiscent of Next.js’ Pages Router.

Pretty Good Documentation

One thing that’s a must with any tool you use is good documentation, and Astro doesn’t disappoint. It has a very good section on the basics of an Astro project (along with a really good tutorial that teaches these basics and some “advanced” features) and groups related content together.

If there’s something that I don’t like about Astro’s documentation, is that it’s difficult to find documentation on all the modules that Astro exports without happening to stumble upon them when reading documentation for the feature that uses them (ie: astro:actions, astro:contents, etc.).

Gripes

With Astro being very satisfying to work with, there are some gripes that I found while creating this portfolio in fact. The most annoying one that I found was the random spaces added to the start & end of a component when using a <slot />. Typically, when using components, you’ll do something along the lines of:

<MyComponent>
  Some text
</MyComponent>

Well, the problem Astro has is that depending on the way you create the component, you can have 2 different behaviors:

/* Below will render in the HTML: <p>Some text</p> */
<p><slot /></p>

/* Below will render in the HTML: <p> Some text </p> */
<p>
  <slot />
</p>

This ends up pretty annoying if you want to say use new line characters (/n) with the white-space CSS property as those extra spaces would appear in the rendered code, ruining the expected behavior.

This brings us to a different problem I have with Astro and that’s with how it handles components in MDX. Say you have a some sort of text that you want to wrap with a component inside an .mdx file such as:

<Text>
  Lorem ipsum odor amet, consectetuer adipiscing elit.
  
  Blandit auctor congue sed potenti molestie metus proin. Nulla nam sollicitudin sociosqu; potenti maecenas efficitur nisi curae sed.
</Text>

You would expect that the text inside of <Text /> would be styled based on the styling on the component, but in fact, it uses the default markdown styling. What is actually rendered is the following:

<Text></Text>
<p>Lorem ipsum odor amet, consectetuer adipiscing elit.</p>
<p>Blandit auctor congue sed potenti molestie metus proin. Nulla nam sollicitudin sociosqu; potenti maecenas efficitur nisi curae sed.</p>

which is pretty freaking annoying as the styles you want to apply actually don’t get applied.

Conclusion

Overall, learning Astro is something that I’m glad to do as it provides me with another option for building apps that might be a better choice. I think Astro would have been a great choice for my Caerula project as it’s mainly a static site which generates the pages from JSON files. Although the project has some interactivity, we can utilize Astro’s features to circumvent that.