Why Astro?
From the start I knew I wanted Astro as my web framework. There were three main reasons for this:
-
UI-agnostic. Astro allows you to use React, Svelte, Vue, Solid, etc all in one site. As someone new to web development, this means I can try all the UI frameworks without committing to one early on.
-
Server-first. In Astro, the server renders as much content into HTML as possible. This is ideal for static sites like blogs.
-
Islands architecture. Astro separates each page into different islands or components, each of which can be static or interactive and use almost any UI framework. This is performant while allowing me to choose the best framework for each component.
I didn’t want to start from nothing, so I went through every blog template on Astro themes. Erudite was the best fit at the time.
An anecdote on Erudite
Erudite claims to be loosely inspired by Astro Micro, which was a fork of Astro Nano. Astro Nano was actually my second choice template, since it had precisely the bare minimum for a quality blog and nothing more. Astro Micro added search, comments, and other features to Astro Nano, alongside a visual overhaul. For me, Erudite took the best principles of Nano and Micro, got rid of everything else, and added the ideal post navigation system.
Two examples solidified my choice of Erudite over every other template. Enscribe, the creator of Erudite, has a blog that exemplifies Erudite’s potential as a technical blog. Reza Rezvan’s blog exemplifies Erudite’s potential as an academic blog. He’s also the original author of the <Callout> component in this template.
Since then, I’ve actually gotten in touch with Enscribe, who ended up being very influential in determining the color palette for this site and getting me to use Figma.\
The tech stack
Astro is the web framework. The primary UI library is shadcn so Tailwind is also used. The site is 100% TypeScript. Most components are vanilla Astro, but more complex ones are in React, to be replaced by Svelte when LLMs get better at writing Svelte. The site is hosted on Github through Github pages.
The flowchart for a typical blog post is:
-
Brainstorming a topic. Surprisingly the easiest part.
-
Making the post’s banner art in Figma. This is second because I find illustrating forces me to concretely narrow down the topic in a way text cannot do.
-
Writing directly in
.mdxusing an IDE. This takes the most time. -
Making custom components for the post. It’s my unspoken rule to always make a new component for every post, both to practice and to give each post some individuality.
-
All this is done in a Github branch. When the first draft is ready, I make a pull request. If a post needs edits after that, I do it in the same branch and PR it back into main.
The Git branches allow me trace what post inspired what change, and work on multiple posts simultaneously.
On media
I try to store all images in WebP if its not a vector and SVG if it is. I’m having doubts about SVG though. Inspect the blog post banner file size and you’ll see why. I hope to never upload a video or large media file directly here, providing links to an external service instead.