© 2025 Markus Toran

#featured5 min read895 words

Why I Migrated from Jekyll to Astro — Introducing Website V6

Why I Migrated from Jekyll to Astro — Introducing Website V6
Why I Migrated from Jekyll to Astro — Introducing Website V6

I did a major revamp of this very website.

It's completely rewritten from scratch based on Astro. Around 6 years ago, I migrated my website from Hugo to Jekyll. In a way, the reasons why I migrated to Astro are the same as why I migrated to Jekyll in the first place: more freedom to customize the design. With Jekyll, I had to place HTML directly in Markdown to get it to look the way I wanted. Now with Astro, I can just program it exactly how I envision it.

Motivation

With me blogging more regularly now, the features my old blog had were too limited. I thought I would implement features like proper code highlighting once I really needed it, but adding it onto the Jekyll stack proved hacky, and I couldn't achieve perfectly rendered results. Other aspects of the old blog also felt dated—the design, of course, but also technically. I was stuck on an old version of Jekyll from 2019, and when I tried to update, features broke and old unsupported plugins hindered new developments. The CSS framework was an old fork of Bulma called Bulvar. Dark mode support was hacked on. I couldn't leverage JavaScript libraries the way I wanted. Thus, I needed something new.

I briefly tried going back to Hugo, using an AI agent to port my website, and experimented with different themes like PaperMod and its derivatives. But nothing could meet my standards. Between the old website and this one lie 5 different stacks I tried out before I finally decided on Astro.

My Jekyll Website

My Jekyll website basically offered a blog and a site about me. The design was a customized variant of a minimal theme and very basic—I thought it looked too basic. At some point, I changed the colors by using a Prolog program to optimize a color palette based on defined requirements. The sites were written in Markdown and rendered to HTML with kramdown.

Other People's Websites

I drew inspiration from other people's websites when coming up with mine. In an upcoming post, I will highlight other cool websites, but the possibilities to innovate never end.

Why Astro + Tailwind

I initially tried using Next.js, but React and the way Markdown is parsed hindered achieving my vision. I migrated to Astro, as I can currently live with its limitations, and it gets the job done well.

I wrote a custom loader for my blog posts, which processes Markdown with unified and provides typed parsing of the metadata. The metadata is used in various parts of the website.

Tailwind has matured significantly since I last looked at it. My previous blog used Bulma, which became too difficult for me to use. Tailwind works very well for what I want to do—I can customize enough to match my vision, but it provides a framework that's easy to develop with.

Even when I started my Jekyll website, I looked at ways to leverage Node.js's rich ecosystem, but I couldn't make it work back then. Now I can. It's powerful and exactly what I needed.

The New Website

Design

A central feature of my design are these asset labels. You can see one in the footer. I originally created them as physical labels to place on my items, in several different sizes. The test card border was added because most printing services only do 4/0 color and not black & white directly, so I decided when I pay for all colors, I'm going to use all colors. In the future, I will write about the labels more in-depth. I was inspired to make my own asset labels from the ones created by Hexchen.

Blog Features

Besides the new design, I also implemented new features:

  • Better Markdown support based on a custom unified processing pipeline
  • Tags for organization
  • Nice syntax highlighting based on Shiki
  • Improved URL structure
  • Header with word count
  • Link post-processing for search console optimization
  • Link-to-heading functionality

I dropped support for multiple languages. English-only is the way forward.

Metadata

Schema.org and OpenGraph metadata is currently generated for posts, with room for improvement. It's okay, but it can be better. I learned a couple of things about SEO, and Google publishes an interesting guide: https://developers.google.com/search/docs/fundamentals/seo-starter-guide. I think it's all you need to know about SEO. Further, Google has an RSS feed and blog about updates they do to the search algorithm: https://status.search.google.com/products/rGHU1u87FJnkP6W2GwMi/history

Landing Page

The landing page is completely custom-built and showcases the design elements I wanted to highlight.

URL Design

I've carefully designed the URL structure to be clean and maintainable. Blog posts follow a date-based pattern that makes them easy to organize while remaining human-readable.

Migration

I made sure old links still work and forward to the new URLs. Cool URLs don't change. RSS generation is completely custom-built to ensure compatibility with existing feed readers.

Future Work

Still, I feel my website can be improved even further, which is why, until further notice, this is a beta release. There should be no major bugs, but some features are still missing:

  • Header images and assets for blog posts
  • Table of Contents (TOC), abbreviations, footnotes, and sources for blog posts
  • Generalization of features for easier reuse
  • Further design improvements. I want wow-moments for the design
  • Enhanced feed generation
  • Link monitoring and archival

Conclusion

I plan to use this current technology stack for at least the next 10 years. If my website inspires you for your own website, I'd be happy to know. If you have critical and constructive feedback, please let me know. If you don't like parts of my site, I'd appreciate hearing about it so I can continue improving.

If you enjoyed this post, consider sharing it on your favorite social media platform! Subscrible via Feed or via Fedi and comment via E-Mail.