JerryContent
Introduction
We’re going to talk about Astro.
Most folks see Astro as yet another framework but I think there is something more to it.
There is an unique use case for Astro that many folks are not talking about!
Before we talk about the use case, let’s review some of the key features of Astro.
The key features include:
Static (by default) - You can build your website using Javascript but the output is just a static site by default in Astro (Zero JS by default)
Partial Hydration - Usage of the “island architecture” to selectively add interactive components into the website
Flexible Framework support - Astro takes a compiler first approach, meaning it supports many frontend frameworks (React, Svelte, Vue etc)
These key features make Astro well suited for these specific scenarios.
Before we start that discussion, let’s start by looking at the different types of websites we build as developers.
This will help us to see which type of sites is most suited to be built with Astro.
The types of websites you build
If we take a step back and look at the types of website we build, the sites tend to falls into these 5 categories.
Here is what the spectrum looks like:
It can be further divided into the sub-categories:
Content Focused (more static) - Marketing, Publishing, Ecommerce
Interaction Focused (more dynamic) - Ecommerce, Stateful, Apps
The capabilities of Astro fits within the ranges of Marketing, Publishing and Ecommerce very well.
However, if you look at most companies, it typically is a combination of both.
You typically have a product then you also have a separate marketing site.
You may ask — Ok, how does Astro fit into this picture ?
The Use case
The use case that that many folks are not talking about is using Astro for rapid experimentation and prototyping (especially at scale).
So, that means using it for within the Marketing, Publshing and Ecommerce context when you already have a product in place.
This will allow you to re-use some of the code from existing Product (APIs, Components etc) to quickly build your prototypes or experiments separate from the product codebase.
Again, this an underrated use case because most folks see Astro as just another framework.
When applied in this way, I see it leveraging the full strength of what Astro has to offer.
I supose a good slogan to describe this process would be: Build simple, fast sites while leveraging existing code.
Why can’t I just use our existing stack to do this ?
In reality, you can use any stack to do this.
Astro just fits this use case a lot better (categories: Marketing / Publishing / Ecommerce).
This is the use case that it was originally designed for.
I guess it comes down to:
The level of fidelity of your experiments and prototypes
The quantity of experiments and prototypes
If we are talking about large quantities and high to medium fidelity prototypes and experiments, Astro definitely wins in this category.
Astro’s advantages (compared to other frameworks):
Great balance between flexibiltiy (Island architecture) and baseline performance (static by default)
Simplicity in deployment (Astro build outputs just html, js, css by default)
While the newer versions Astro provides features to build more complex sites (ie with SSR and API), I still see Astro being most powerful in this “sweet spot”.
Conclusion
And there you have it!
A different way of looking at how Astro can be used to its fullest potential.
And of course, the code that you re-use doesn’t have to be from a product, it can be any existing codebase (as long as Astro supports the framework).
You can re-use the code to come up with prototypes, and experiments without having to build something from scratch.
I hope this helps you to see Astro in a different way!
Give it a try, and let me know what you think.
If you enjoyed that or learned something new, please share this article with a friend or co-worker 🙏❤️! (Thanks!)
