After two months of building this site with Hugo, I decided to migrate the stack to Astro. In this project, I found that my template structure became harder to extend as the site grew. Moving to Astro let me organize pages, shared UI, and validated content as separate parts of one codebase. This is a retrospective on my project and preferences, rather than a general comparison of the two frameworks.
I wasn’t looking for a standard blog; I needed a more flexible environment for technical documentation and experiments.
The Shift to Component Architecture
Navigation, the shared layout, and the footer live in reusable Astro components. Article and project content live in collections with their own schemas. This gives me separate places to change the interface and the content rules without editing each page individually.
Performance and Selective Hydration
The public pages mainly contain text, links, and images. I want the browser code to stay small and tied to the interactions those pages need.
Astro renders the content pages statically, and I add browser-side behavior only for specific interactions. The shared site shell still includes a mobile navigation controller and code-copy behavior, so this is not a zero-client-JavaScript site. The goal is to keep each script tied to a user-facing function instead of shipping an application runtime to every page.
Technical Comparison
| Area | What changed in this site |
|---|---|
| Page structure | Pages and reusable interface elements now live in Astro components. |
| Browser behavior | Interactive behavior is added for specific controls, including navigation and code copying. |
| Content | Astro content collections validate frontmatter against Zod schemas. |
Type-Safe Content Management
Accurate data is the core of this archive. Ingesting poorly structured metadata can lead to long-term maintenance issues. By using Astro’s Content Collections and Zod, I’ve implemented a more rigorous validation layer.
If content does not match its collection schema, the build reports a validation error. This catches structural mistakes; it does not verify that a claim or metric in the content is true, so those still need an independent source review.
Conclusion
The migration gave this site shared interface components and schema validation for content. I find that structure easier to maintain.
This retrospective does not include a controlled before-and-after performance benchmark. The conclusions here concern the code structure and my experience maintaining it.