Home Blog Goodbye eleventy, hello AstroJS
Astro
July 24, 2026

Goodbye eleventy, hello AstroJS

Goodbye eleventy, hello AstroJS

Some years ago, I wrote a post called “Goodbye Jekyll, hello eleventy” because I wanted something simpler and more flexible than my previous setup. Eleventy was a great move at the time. It was fast, easy to understand, and perfect for a personal website that was mostly static pages and blog posts.

And honestly, Eleventy still is a great tool.

But websites evolve, and this one did too.

As I kept adding content, layouts, and ideas for richer pages, I started feeling that I wanted a setup that stayed static-first while giving me a better component story, better content organization, and an easier path for adding interactivity only where I actually needed it.

That is what pushed me to move this site from Eleventy to Astro.

Eleventy did its job really well

Before talking about Astro, it is worth saying something clearly: this change is not about Eleventy failing me.

Eleventy is still one of the nicest static site generators around if you want:

  • simple templates
  • flexible data files
  • fast builds
  • very little magic

For a long time, that was exactly what I wanted. I could write content, generate static files, and deploy the site without much ceremony.

But over time I started wanting a bit more structure around the site itself, especially as it became more than “just a few pages and a blog”.

Why Astro felt like the right next step

The biggest reason is that Astro gives me a more natural way to build reusable UI pieces.

With Eleventy, you can absolutely create reusable templates and partials. But Astro makes the whole experience feel more component-oriented from the start. Headers, footers, cards, article lists, callouts, and page sections all fit into a model that feels very clean and easy to scale.

That matters because once a site grows, consistency becomes more important than raw simplicity.

Instead of repeating markup patterns in multiple places, I can keep those pieces in components and compose pages in a way that feels more intentional.

Better content organization

Another big win for me is Astro’s content collections.

One of the nice things about a content-driven site is that most of the important work happens in Markdown files. But as the amount of content grows, it becomes more useful to have a system that validates the shape of that content.

Astro gives me that out of the box.

That means I can define the fields a blog post should have, like:

  • title
  • date
  • image
  • category

And if I forget one of them, or write something in the wrong format, I find out immediately instead of discovering it later in production.

That kind of guardrail is small, but very valuable.

Static-first, but not limited

One thing I really like about Astro is that it keeps the static-site mindset I already enjoyed with Eleventy.

Most of the site can stay plain, fast HTML. That is still what I want.

But Astro also makes it much easier to sprinkle in interactivity when needed, without turning the entire site into a heavy client-rendered app.

That is probably one of its best ideas: ship as little JavaScript as possible by default, and only hydrate the parts that actually need it.

For a personal site, that is a sweet spot.

I get:

  • strong performance
  • a modern component model
  • room for interactive pieces later
  • less pressure to over-engineer the whole site

A nicer developer experience

This was another important factor for me.

Astro feels modern without being overwhelming. I can use Markdown for content, components for layout, and a structure that is easy to reason about when coming back to the project after some time away.

That last point matters more than people think.

Personal websites are often side projects. Sometimes you work on them a lot for a week, then barely touch them for a month. When you come back, you want the codebase to feel friendly.

Astro has felt very good in that sense:

  • routing is easy to follow
  • layouts and components are straightforward
  • content lives in a predictable place
  • the separation between content and UI feels clean

It lets me move quickly without feeling messy.

Performance and shipping less JavaScript

Performance was also part of the appeal.

Eleventy already produces fast sites, so this is not one of those “my old site was slow and now everything is saved” stories.

The benefit here is more about control.

Astro encourages a model where pages are rendered ahead of time and JavaScript is optional, not automatic. That leads to pages that stay lightweight unless I deliberately choose otherwise.

For a blog and portfolio site, that is exactly the kind of default I want.

Fast pages are better for readers, better for mobile devices, and usually better for maintenance too.

It feels like a better fit for where the site is now

That is probably the most honest summary.

Eleventy was a great fit for the version of the site I had before. Astro feels like a better fit for the version of the site I want now.

I wanted something that would keep the simplicity of a static site while giving me:

  • better component reuse
  • stronger content validation
  • cleaner long-term structure
  • easy opt-in interactivity

Astro checks those boxes really well.

Final thoughts

Moving from one framework to another is rarely just about features. A lot of the time it is about finding the tool that matches the current shape of your project.

Eleventy helped me move away from an older setup and taught me a lot about static site generation. Astro feels like the next step in that same journey: still content-first, still performance-minded, but with a developer experience that fits this site better today.

So yes: goodbye eleventy, hello AstroJS.

And just like the last migration, I am hoping this one gives me a nicer foundation for whatever I decide to build here next.