This Blog's Stack

Here is a bit of my thinking when I chose to start this blog:

Requirements

Fast load time

The previous iteration of this blog was on Nuxt Content, running on headless Rails with Postgres on Fly.io and using CircleCI for the CI/CD. I was seeing some slow pageload issues on mobile and I wanted to fix that.

Simple stack

Making small changes in Nuxt/Rails/Fly.io/CircleCI were doable, but I wanted to spend less time on my portfolio site and more time honing my skills.

Small number of pages

For over ten years I’ve been maintaining a personal site with a handful of pages: home, about, projects, blog and contact. It’s never been a massive site, but I wanted it even smaller.

Simple CMS

Over the years I’ve alternated between having my content in my HTML pages and using blog engines like WordPress, Nuxt Content and Netlify’s Decap CMS. I’ve come to prefer my blog content separate from my HTML/CSS/JS and I wanted a fast way to be able to log in quickly and write a new post, sometimes from my phone. Logging into Decap was a pain - I usually had to log into both the CMS and netlify and it just felt a bit hacky or unfinished.

Markdown blog posts

I’ve recently grown to like writing markdown. I initally was using it for my GitHub readme files. Then I started using markdown for blogging with Nuxt Content. I enjoy using “front-matter” at the top of the post for the title, date, etc and then just writing the post in markdown below that. It gives me that “I’m writing prose, not code” feeling that a CMS and WYSIWYG give, but there’s no need to log into a separate CMS and no clunky blogging software to deal with.

Utility-first CSS

I’d avoided Tailwind for a long time even though I knew it was more scalable and sped up development time. I am a bit of a purist in my afterhours and I always thought Tailwind made markup look really ugly. For awhile now, I’ve gone the opposite direction in my hobby projects and used semantic PicoCSS in its classless form. I always thought that code looked really beautiful. But I knew it was time to bite the bullet and to force myself to learn tailwind.

Technology considered

I considered a few different technologies for this blog:

• WordPress: Wordpress is great, but a little clunky.
• Nuxt: I considered using Nuxt with server side rendering to reduce my pageload times, but GitHub pages doesn’t do SSR and Nuxt would have to pre-render my site into static HTML files, which defeats some of the purpose of using Nuxt.
• Hugo: I’d dabbled with Hugo before and it was ok. The templating was a bit odd though, written in Go.

Solutions

• Fast load time: Astro’s static site generation makes this blog load very quickly. Google Lighthouse says it loads in 0.2s on desktop and 1.1s on mobile and a 100% score for performance. It’s possible I can get this even lower, but for now that is great.
• Simple stack: Astro/GitHub Pages/GitHub User Site keeps things simple. No more frontend framework, no more backend framework, no database, no cloud, no docker, no CI/CD.
• Small number of pages: I sort of combined the about/projects/contact page into one page and moved it to GitHub’s user site where everything is just a single readme file. The blog page is now the only page I really have to maintain or think about at all.
• Simple CMS: Using GitHub as the CMS is awesome. I’m in GitHub all the time anyway, so I don’t really need to log into a separate CMS.
• Markdown blog posts: Astro supports markdown files, so I can write my posts in markdown and front-matter like I was used to with Nuxt Content.
• Utility-first CSS: I’ve come around somewhat on Tailwind. I still think it makes markup look ugly, but it’s so fast to work with I barely have to think about css, unlike Bootstrap, etc.

Tradeoffs

• No tags / no search: Not having tags on the blog posts make it harder to sort through posts to find what you want. No search makes it even harder. Building these out in Astro might be a fun project sometime.
• No comments: The lack of WordPress-like comments is both a pro and a con. The blog looks cleaner, I don’t have to worry about spam or moderate anything, but I also don’t get the feedback or engagement that comments give. I’ve seen some blogs use GitHub issues for comments and I plan on looking into that more.
• A new framework to learn. Astro is much simpler than Nuxt or Rails, but it’s still a new thing to learn. It was my first time using MDX and I thought it was a bit odd, but it does the trick and I enjoy it’s simple approach to components. I also was unable to port some of my blog posts that were very code-heavy. Certain characters like backslashes break the post and so far I haven’t found a solution like escape characters that fix it, but I do plan on working that out because I like posting large code tutorials.
• No CI/CD: I miss running tests on CircleCI a bit - it was a nice safety net.
• No big framework: The advantage of the big-framework approach for me was that I could embed my projects I wanted to showcase right into my site. I’ll probably end up linking out to my projects hosted on something like fly.io instead.
• No database: Having my content in markdown files with frontmatter makes it less portable. I can’t just export my content and import it into another blog engine. I’d have to write a script to parse the markdown files and store the content in a database.

Conclusion

I’ve been running this static, GitHub-based approach to blogging for awhile now and it’s been my favorite yet. I love the pageload speed, the speed of posting and the nimble tech stack. It helps keep all this fun.