Marcus Kazmierczak

Home mkaz.blog

What runs mkaz.blog

This post documents the various technology stacks I've run this site. Rather than creating a new post each time I switch, which I was doing, I'll keep this one updated as the guide to what powers mkaz.blog. Over the years, I've used my site as a playground to test out various technologies, though now I'm settling back to keeping it simple.

Current Stack: Hastie (Sept 2025 - Present)

After experimenting with various modern frameworks, I've come full circle back to Hastie, my own Python-based static site generator that I originally created and used for years.

Why I returned to Hastie:

  • Simplicity: Just a folder of markdown files organized by category
  • Control: I understand exactly how everything works since I built it
  • Performance: Slow but fine, generates 250+ pages in ~7 seconds
  • Flexibility: Easy to modify when I need new features
  • Reliability: No framework upgrade headaches or breaking changes

Current Architecture:

  • Content: Markdown files in pages/ directory organized by category
  • Templates: HTML/Jinja2 templates with Pico CSS for styling
  • Build: Simple Python-based generation to static HTML
  • Hosting: Vercel with redirects handled via vercel.json

The site structure is exactly what I want:

pages/
    code/
        what-runs-mkaz-blog.md
    working-with-python/
        ...
    life/
        ...
    about.md
    index.md

History

Astro (Feb 2025 - Sept 2025)

I switched to Astro after getting frustrated with Nextra's upgrade path. Astro initially seemed overly complicated with its .astro file format, but I found a good pattern using frontmatter layouts.

What worked:

  • Content collections for organizing posts
  • Frontmatter-based layouts: layout: "base"
  • Good performance and modern build tools
  • Flexibility with React components when needed

What didn't:

  • Still felt like overkill for a simple blog
  • Required maintaining knowledge of another framework
  • More complexity than I actually needed

See the Astro starter kit I made with the structure I liked.

What got me to switch off back to Hastie? I was loading some SVGs for an article. The SVGs had some style set in their file, which ended up changing the base style across every page on the site. A definite smell, why does loading an SVG in one article, change the style on the entire site? The fact that this could even happen, I didn't even want to dig in and figure out, it just showed the complexity in the framework is not what I want. My needs are simple, I just want a folder of markdown rendered to templates, so back to Hastie.

Nextra (2023 - February 2025)

I used Nextra built on Next.js as my company was running a Next.js site, I wanted to use something similar. Initially loved the developer experience, but as it seems with all JS projects the ongoing maintenance and upgrades were too much.

What worked initially:

  • Great markdown/MDX support out of the box
  • Built-in themes and components
  • Good integration with Next.js ecosystem
  • Automatic syntax highlighting with Shiki

What went wrong:

  • Nextra v3 and v4 upgrades were increasingly painful
  • Next.js app router changes created routing headaches
  • Forced me into patterns I didn't like (catch-all routes, page.mdx files)
  • Lost the simple "folder of markdown files" experience I wanted

The breaking point was when upgrading required restructuring my entire content organization or adopting patterns that felt like steps backward in developer experience.

I did create a Nextra starter kit, but it is probably outdated and won't work anymore.

WordPress Era (2013 - 2023)

I worked at Automattic for almost 10 years, so platform-wise probably the most stable and consistent. However, under the hood the most tinkering as I would test out plugins, latest WP versions, brand new editors, etc. See my WordPress articles to see a sampling.

Original Hastie Era (201? - 2013)

I originally built Hastie as a Golang static site generator inspired by Jekyll but tailored to my preferences. I wanted to learn Go and it was a good project for it. I used it for a bit until I got a job at Automattic and switched back to WordPress to eat our own dog food.

Early Days

My records get spotty going back this far and it'd take going to backups to get the full foresnics. I used WordPress for awhile, some other custom PHP solutions, and just good ol' HTML and CSS. The site dates back to 1997, so at some point I know I wrote custom Perl scripts and server-side includes to manage.

Lessons

Simple is Sustainable

The frameworks I tried were powerful but brought complexity I didn't need:

  • Build system complexity
  • Framework-specific patterns
  • Upgrade maintenance burden
  • Ecosystem dependencies

Know Your Requirements

My actual requirements are simple:

  • Markdown content in folders
  • Fast builds
  • Easy content creation workflow
  • Control over output HTML
  • Reliable long-term maintenance

My custom Hastie tool meets all these requirements without extra complexity.

Current Workflow

Creating a new post:

  1. Create markdown file in appropriate category folder
  2. Add title and date to frontmatter
  3. Write content in markdown
  4. Run just build to generate site
  5. Commit & Deploy (automatic via Vercel)

That's it. No complex build pipelines, no framework-specific gotchas, just write and publish.

Future

I expect to stick with Hastie for the long term now. Having gone through the modern framework exploration, I've confirmed that simple, well-understood tools are often the best choice for straightforward use cases.

The site has been running for 25+ years across multiple platforms and frameworks. The content is the constant - the technology underneath can and will change, but keeping things simple makes those changes easier when they're actually needed.