I recently migrated to Astro!
Before I go into reasons and juicy details, let’s understand what Astro is.
Let’s see what they claim to be, at their landing page:
If we extract the important pieces:
- JavaScript web framework - it’s built in JavaScript. It’s meant to be run in environments where JavaScript runs, so browser or on the server - Nodejs
- optimized for … - built with the purpose to optimize certain use-cases
- building fast, content-driven websites -the purpose. It’s meant to be used for content-driven websites
So, whether you want to build a blog, community site, documentation, marketing site or e-commerce, Asto is way to go.
There are other players out there that you might be familiar with:
- Gatsby
- WordPress
- Next.js
- Remix
- …
What they put in the center is the content you want to show, and speed this content needs to reach your readers.
What Astro and all these other players on the market are competing at:
- Loading time - how fast your content renders on the viewers screen. Both initial load time and page-transition load time
- SEO (Search Engine Optimization) - directly impacts visibility, reach and success of a website by optimizing it to rank higher in search engine results
- Developer experience & delivery time - how enjoyable and fast you can build something production ready
- Content management - since they’re meant for content-driven websites, how convenient and easy we can update our content (e.g. change existing content, generate new content)
Why is Astro so blazingly fast?
Nature of content driven websites is less interactivity, not much exchange between client and the server, most of the content is static and can be generated on build time.
That’s where SSG (Server-Side Generation) comes handy.
Obvious downside of this is if we need to render newer content from the server, we would need to build and deploy version with the updated content and then our users might be able to access it.
For use-cases where most of our content is static and doesn’t update that frequently this solution makes sense.
In a scenario where we want to load the newest data on page load (let’s say weather information, or news) SSG is not enough.
Even in that scenario Astro provides us with on-demand rendering. Also known as Server-Side Rendering (SSR)
But know that this adds on loading time.
What makes it cooler, possibility to choose whether we want to add this to all or only certain endpoints.
So we’re still able to keep most of our website SSG rendered and only certain pages SSR.
How cool is that?
SEO optimization
Astro also does SEO optimization out of the box whether we use SSG or SSR. That way our website can gain visibility, come up as most relevant by being ranked higher in the search engine results.
Developer productivity & delivery time
Astro by default is so simple, easy to grasp. There are so many templates that we can use to have a speed start.
Even without that whole setup is pretty lean. Only certain folder names are restricted and used to make things easer (as page routing, content folder for content collections, ..) On top of that there are certain conventions but not required.
Content Management
Astro includes built-in support for Markdown files with some extensions that let us populate data into the markdown or add certain metadata around our content.
If we want richer experience and advanced features we might want to consider integration with mdx which is also supported!
From our side little or no effort is needed to bring our content to Astro and eventually to our users.
Astro Islands
Another cool feature that Astro brought are islands. Those are pieces of our page that are dynamic, that bring certain amount of interactivity.
The general idea of an “Islands” architecture is deceptively simple: render HTML pages on the server, and inject placeholders or slots around highly dynamic regions […] that can then be “hydrated” on the client into small self-contained widgets, reusing their server-rendered initial HTML.
— Jason Miller, Creator of Preact
If we take an example from the official docs. Let’s consider the following page configuration:
Most of our page is static and pre-rendered on the server. Only what is being sent to us as a client is static HTML.
To add some interactivity on the client we need some JavaScript, but that will slow our page down?
Islands are a way to have this interactive components at the minimum cost. Only these little islands or call them components are loaded with their additional JavaScript. After which islands get hydrated.
These islands can be lazy loaded, so that most of our content is instantly available for the user.
To declare component as an island we only need to add client:*
directive. We don’t need to do that for .astro
components. And what this says is: load JavaScript that comes with this component to the client.
<!-- This component is now interactive on the page!
The rest of your website remains static. -->
<MyReactComponent client:load /> // load and hydrate immediately on page load
<MyReactComponent client:idle /> // load and hydrate only when browser goes into an idle state
<MyReactComponent client:visible /> // load and hydrate only once component gets visible
Without this:
This can be our own custom component but also component built in any of the popular frameworks that Astro supports (React, Preact, Svelte, Vue…)
So Astro provides us with the flexibility to integrate and use component coming from the other frameworks!
Conclusion
For my use case Astro was an ideal solution.
Almost all of the content is static and can be generated on build time (SSG).
Adding new content is pretty straightforward as I only need to add yet another md file into a collection and publish. Once everything is built and published, it gets available to the users.
There are certain parts that are interactive as theme toggle
and anchor
that does scrolling to the beginning of the page.
Building with Astro is a fun experience. I recommend you trying it out.
Anyway do not forget the fundamentals, they’re prerequisites to appreciate the abstractions.
See you in the next one :)