Hello, Solar System!

Hello World, again! I’ve rewritten this website using the Astro web framework. Astro’s very new — it had its 1.0 release just under two months ago. There’s three things that got me excited enough about it to rewrite my whole site.

1. JSX. JSX is best known as the templating syntax that powers React. While Astro can integrate with React, Vue, Svelte, or any other framework from a growing list , .astro templates are written with a mix of TypeScript and JSX and are rendered directly to vanilla HTML with no JavaScript at runtime. TypeScript is written in a preamble section that looks similar to Markdown frontmatter and sets up the scope for the rest of the template. I found Hugo’s templating system that is built directly on Go’s templating library to be very limiting by contrast. At this point, I definitely believe the adage that “any powerful templating language eventually grows into an awkward programming language” — I’d much rather use a full programming language as my templating language.
2. Scoped CSS. CSS written in .astro templates are scoped to that template only. I’m not a fan of dogmatic separation of concerns in CSS. I also don’t have much experience with Tailwind, and I enjoy writing SCSS. So scoped styles in all my templates is a happy medium where my styles live close to my templates while I can write in a familiar syntax.
3. Lightweight. With everything from archetypes to taxonomies, Hugo is really a static CMS more than a blog generator. It’s a much more general system than I need. Astro is a bit “closer to the metal” in that respect. When I’ve had to write some helpers that I took for granted in Hugo, writing custom helpers is much easier since it can be accomplished in a few lines of Typescript.

Astro is sponsored by Netlify, and in many ways it looks like their answer to Vercel’s extremely popular NextJS framework. NextJS is frontend-first and dynamic by default while it puts the option to export to static HTML off to the side. By contrast, Astro is server-first by default, making you opt-in to server-side runtime rendering and client-side reactive “Islands”. It’s an approach that was very attractive for building a static site, and I’m interested to see how they plan to evolve the framework from here.

The transition from Hugo to Astro wasn’t too bad since I was able to find a 1-1 mapping between my Hugo templates and partials with Astro components. I’d like to give a special shoutout to Bryce Wray, whose site repository and blog posts on Astro were a great reference when building out my own site. While the Astro docs are great, they are also new, and there’s a few things that I was able to find out about by snooping around Bryce’s repo.

I’ll miss Hugo’s support for rendering .org files – I’ve unfortunately had to convert posts from my time using emacs to Markdown using pandoc. For the time being, I’m stuck opening Chrome when working on the site because Astro’s dev server doesn’t hot refresh properly in Safari. Besides these two nitpicks, I’m overall happy with the move. I think it’ll help me make new additions to this site over time with less friction than before. We’ll see how that goes!