Moving from Jekyll to Astro

Astrojs is a web frameworks that enables you to build fast, content-driven websites, it’s especially helpful if you want to have a blog. In this article, I will dive deep about transitioning from Jekyll to Astro.

The Beginning

So I created this website, at the time when the concept of static site generator was still at beginning and also at the time when Github Pages was created.

Even if you navigate now to the Github Pages website, you can see that for blogging Jekyll is still suggested and that’s because it’s still a good alternative to use. In my case, after using Jekyll for a long time I wanted to experience a different framework and that’s when I discovered Astrojs, a static site generator used for content driven websites.

Jekyll vs Astro: The Key Differences

The Structure

First if we look at the structure of a Jekyll project, we would have:

• _pages folder that contains our pages used in the website
• _posts folder containing all our posts written in markdown.
• _layout folder that contains all our layouts, and each page inside the _pages folder should have one of these layouts.
• _include folder that would contain components that we could include inside our _layout so we don’t write the same code more than once.

One of the biggest difference between the two is that Jekyll uses Liquid templates while Astro is using JSX like template language. An example of a layout file in Jekyll is the following:

---
layout: default
title: Archive
---
 
<section class="recent-posts">
    <div class="section-title">
        <h2>Archive of posts</h2>
    </div>
 
<ul class="posts">
{% for post in site.posts %}
  <li>
    <span class="archive-date">{{ post.date | date: "%b %-d, %Y" }}</span>
    <a class="post-link" href="{{ post.url | relative_url }}">{{ post.title }}</a>
  </li>
{% endfor %}
</ul>
</section>

So you can see between those lines --- it’s called the yaml frontmatter, here we define the main layout of this file and even the title to be used. Then you can see below the following code {% for post in site.posts %}, this is how you would iterate in the Liquid template language, and to access the properties you would use {{post.title}}, always to close the loop, you need to use the {% endfor %} at the end.

Now if we look at the structure of an Astro project we would see the following:

• pages folder which would contain all your pages, like about page or even 404 page.
• layouts folder which would contain the layouts used in ths project that can be written in astro or even react (tsx)
• content folder, this folder would organize your content used in the blog.

If you are familiar with React or any other web frameworks, you won’t have a hard time with Astro. So for example the following is a component in Astro:

---
const { date, class: className } = Astro.props;
 
const formattedDate = new Date(date).toLocaleDateString('en-us', {
  day: '2-digit',
  month: 'short',
  year: 'numeric'
});
---
<time datetime={date} class=`text-gray-600 ${className} font-medium`>{formattedDate}</time>

So as you can see in Astro inside the frontmatter you can write the Javascript and after the frontmatter, you can then write the html and also accessing the properties that you got from the Astro.props.

Integrations

Another nice feature in Astro is integrations in which you can easily add new functionality to your project by just adding a new package. For exmaple if I want to use tailwind in the project I can easily just execute the following command:

yarn astro add tailwind

and this would add tailwind() in the astro.config.mjs file:

export default defineConfig({
  integrations: [tailwind()],
});

and now you can start using the utility classes that are offered by tailwind. Another nice integration is the @astrojs/sitemap which would automatically create a sitemap index file when you are building your project.

Image Handling

Another nice feature in Astro is the Image component that is provided out of the box. Using the Image component, Astro immediately optimizes the image to avoid Cumulative Layout Shift (CLS). So by default the image would contain the loading attribute for lazy loading or even the decoding attribute, compared to Jekyll in which you had to optimize the images on your own or by using another plugin.

Astro island

Last point I want to talk about is Astro Island. So Astro by default is a static site generator which means all the pages would be converted to plain html pages during the build process and these same pages would be served to any user.

What Astro Islands does is that it enables part of the UI to be interative while keeping the rest of the page static html. Instead of hyrdrating the entire page in Javascript, only specific components would become interative.

So for example let’s say you create a navigation menu using React in which ofcourse you would use state and maybe some hook like useEffect, in that case you would need to use a directive to declare that this component needs to be interactive:

// Only loads and hydrates in the client
<Navbar client:only="react" />
 
// Hydrates immediately on page load
<Navbar client:load />
 
// Hydrates once the page is done with initial load
<Navbar client:idle />

So this feature, would help alot in performance because now you only have part of the page that would be rendered in Javascript but the most part would be just static.

Choosing Between Jekyll and Astro

In this article I didn’t go too much into the specific of Astro, I would keep that for another article. But in the end the question comes down to, which framework should I chose?

Personally, I enjoyed moving the website from Jekyll to Astro, I would recommend to try both in some sample project and see which one would be easier for you. But I think it’s better to move to astro since it’s a somewhat new framework with big support from the community, so you would always find new useful integrations or even support when needed.

Also the built-in image optimization and the partial hydration through Astro Islands helps alot in performance and to minimize some work that you would have been doing in a Jekyll project.