Howdy!
In the spirit of rewriting my blog site as many times as possible (version 4.0), I thought I should start off 2023 with migrating the current static site framework from GatsbyJS to Astro. Astro is the hot framework these days. From my recent exploration, it provides the developer experience that React devs post 2016 have come to expect, but with a focus on static site generation and bundling as little JS as possible. But more on that later.
Migration
To start, I took a gander at the Astro docs. The docs themselves are very helpful, allowing me to set up this new site with little effort. The CLI experience of Astro is also nifty, and has a warm charm that is lost in most CLI apps.
My current GatsbyJS project was getting very stale. It required an old node version to build, and its dependency install / build times were insane. Initially, I explored migrating the app to NextJS, but I opted for Astro instead.
Once I rebuilt the site, I ran a few comparisons to see how Astro performs against Gatsby. I ran time npm run build on both my Gatsby and Astro sites and the results were kind of shocking:
# astro
❯ time npm run build
6.93 real 11.92 user 0.79 sys
# gatsby
❯ time npm run build
55.72 real 75.44 user 5.96 syAstro was able to shave off nearly 50 seconds from the build time. What made this revelation even sweeter is GatsbyJS’s description on Github.
GatsbyJS: The fastest frontend for the headless web. Build modern websites with React.
lol.
Ok, maybe that isn’t fair, since I am comparing 2023 Astro with 2021 GatsbyJS. However, now let’s compare the build directory size.
#Astro
❯ du -sch dist
560K dist
560K total
❯ ls -lR dist | grep '\.js$'| awk '{sum = sum + $5} END {print sum}'
151667
❯ ls -lR dist | grep '\.html$'| awk '{sum = sum + $5} END {print sum}'
84419
#GatsbyJS
❯ du -sch public
21M dist
21M total
❯ ls -lR public | grep '\.js$'| awk '{sum = sum + $5} END {print sum}'
1666701
❯ ls -lR public | grep '\.html$'| awk '{sum = sum + $5} END {print sum}'
441683Whoa. The build directory size (what Netlify serves when navigating to my site) decreases by 40X! Drilling deeper, both the total html and JS file sizes decreased significantly as well.
On Astro
After setting up Astro’s boilerplate, migrating the site over was quite easy. In Astro’s file based routing, Markdown files are transformed into static sites automatically and are configurable by adding metadata onto the file’s front matter. With my experience with GatbsyJS and explorations with NextJS, I found Astro’s static site configurability to be much more intuitive and much harder to mess up. This is primarily because you do not have to worry about the collisions between React’s paradigms and your ultimate goal to produce some SSR’ed content. The best way I would describe Astro is a React-less NextJS or Component Driven HandlebarsJS.
It just works - Todd Howard
I also like the .astro file format. It reminds me of Svelte, which I have tried and failed to adopt. Like Svelte, it tries to close the gap between the component/partial code and its equivalent in pure html, css and JS (using explicit <script> and <style> tags).
Unlike Svelte however, (but similar to React), it allows for construction/templating of components by inlining javascript.
<!-- svelte -->
{#if answer === 42}
<p>what was the question?</p>
{/if}// astro / jsx
<>{answer == 42 && <p>what was the question?</p>}</>It’s like a Svelte component but with none of the Angular-isms.
The last thing that I love about Astro is the zero javascript by default. Reducing the amount of javascript on the page is an admirable goal but this opinion is rarely expressed in the webdev community. Less bundled and client UX-dependent JS allows for less energy to be used when serving/loading websites and provides an equitable experience to those in the world with slow network connections or devices with slow CPUs.
On this note, my site even works perfectly when javascript is completely disabled on the browser, which is also cool (albeit, you won’t be able to use darkmode or see the nifty webgl). With Astro (and NextJS, etc), there is no longer an excuse to write single page applications that load awkwardly and slowly (or even white-screen when the JS is blocked).
Final thoughts
Astro is interesting because it’s opinionated, yet minimal. It has the SSG experience of NextJS/GatsbyJS but it empowers the developer to use whatever they wish on the client side. I personally love this because it moves toward the philosophy of promoting a diverse world of client side frameworks instead of the React monopoly we enjoy/suffer today.