DEV Community: Cyril Seguenot

Starting a New Project with Eleventy

Cyril Seguenot — Mon, 21 Jul 2025 00:00:00 +0000

This article is the first in a series where you'll learn the basics of Eleventy by creating a mini-blog. In this article, we'll start by seeing how to initialize a new project from scratch. In the next one, we'll create the sources for our mini-blog.

What is Eleventy?

Eleventy is a static site generator (SSG). A static site is one where the visual rendering of pages is done before the site is published on the server. The site's HTML pages are all ready to be sent to the browser as soon as someone navigates to their URLs and don't need to be dynamically generated with each request.

💡Tip

Before going further, if you're unfamiliar with the concept of a static site, I highly recommend reading this article, which explains when to use one and the basic principles of building a static site using a generator.

Additionally, if you want to know how Eleventy compares to other well-known generators like Hugo, Gatsby, Astro, or Jekyll, take a look at this short article

I'll now assume you know what a static site is and understand the advantages of Eleventy as an SSG. So, let’s dive into the code and see how to set up an Eleventy project in practice.

Starting from a Starter Project... or Not

The Starter Projects page on Eleventy's website lists 170 starter projects. Each represents a basic site with its own page layouts, styles, and features. Starting with a project that matches your needs can save a lot of time compared to creating one from scratch.

However, finding the right starter project is far from easy for three reasons:

The project listing page only provides a very brief description of each project and offers no way to filter the list based on various criteria.
Some projects have a demo site, but it sometimes doesn’t show much.
Many projects haven’t been maintained as Eleventy has evolved and are now completely outdated or require significant updates.

In practice, this list is hard to use, and you can waste a lot of time jumping from one project to another.

🚨Warning
Moreover, choosing a starter project without being sure it fits your needs might end up costing you even more time.

My personal experience is this:

When creating my blog, I started with the official eleventy-base-blog starter project. But on one hand, this project isn’t natively multilingual, and on the other, once I became more proficient with Eleventy, I realized some of its technical choices didn’t align with what I wanted. As a result, my site’s current code looks nothing like the starter project. If I had to do it again, I’d start from scratch without hesitation.

In fact, adapting the code of an existing starter project can sometimes take longer than starting from zero, especially with the help of AI. Plus, there’s a significant risk of leaving behind dead code (like unused filters and styles) that will only confuse you later.

💡Tip

So, unless you’re in a hurry and not too picky, my advice would be to only use a starter project if it truly matches what you want to do. An alternative is to start a blank project and draw inspiration from other projects’ code to implement certain things more quickly.

In the rest of this article, I’ll show you how to create a project from scratch. If you’d like to try a starter project downloaded from Eleventy’s site, just unzip the file where you want it and run the npm install command we’ll see later.

Installing the Necessary Tools

Eleventy relies on Node.js to generate the site. Before creating a project, you’ll need to install Node.js on your machine if you haven’t already. You can download it from Node’s official website. The npm package manager is installed automatically with Node. It will be very useful for adding plugins and running the site generation.

ℹNote

Node.js is only used during the site generation phase, not for the site’s production operation. A static site doesn’t need Node.js or any server framework to function.

You’ll also need a code editor, of course. I’ll use VS Code as an example, but you can use another one.

I also recommend the Better Nunjucks extension, which adds syntax highlighting and snippets for the Nunjucks templating language we’ll use in our project.

💡Tip

The vscode-icons extension is also very handy for navigating the project’s many files more easily, as it assigns specific icons and colors to each file type. This makes it much easier to distinguish Nunjucks (HTML), Markdown, CSS, and JavaScript files.

Creating the Project

To create a new project, follow these steps:

Create a folder for the project wherever you want on your disk.
Open this folder in VS Code (File \ Open Folder).
Open a terminal (Terminal \ New Terminal or CTRL+SHIFT+ù). The prompt should point to the open folder. Run the following commands one by one:

npm init -y
npm pkg set type="module"
npm install @11ty/eleventy

The first command creates a package.json file that will reference all the npm packages (= modules) needed for the project.
The second specifies that we’ll use the ECMAScript Modules standard instead of CommonJS for referencing and using modules. In practice, this allows us to use the syntax import ... from "module_name";.
The third installs the Eleventy npm package and all its dependencies. It creates a node_modules folder containing over 1,700 files, but they only take up about 16 MB in total. You’ll never need to modify this folder manually.

Here’s what the package.json file looks like for a project folder named "demo":

{
  "name": "demo",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "type": "module",
  "dependencies": {
    "@11ty/eleventy": "^3.1.2"
  }
}

We can see that the Eleventy package is automatically referenced in the "dependencies" property. You can change the project name and add a description if you like. But the most important thing is to add build commands.

Adding Build Commands

These are the commands that will allow you to launch the site generation, i.e., generate the output files from the input files (the project’s sources). To do this, modify the "scripts" section with the following:

"scripts": {
    "build": "npx @11ty/eleventy",
    "start": "npx @11ty/eleventy --serve --quiet",
}

The first command runs Eleventy to generate the site from the sources. It’s mainly used to verify that all source files are correct and that the site builds properly, without launching it.

The second command does the same thing but also launches the HTTP server built into Eleventy and opens the site’s index page in the default browser. This allows you to check the site’s visual appearance.

ℹNote

As you can see, Eleventy is self-contained for building and running a site. This integration allows it to build a site much faster than other static site generators that rely on external tools like Webpack.

At this point, we have everything we need to start developing the site by adding source files.

Creating a Configuration File

An Eleventy project must include an eleventy.config.js file that describes its configuration. You can create this file now at the project’s root.

This file is, in a way, the project’s core, centralizing all its configuration. We’ll expand it as we build our example project, but we need it now to declare and configure plugins.

Adding Plugins

Zach Leatherman, Eleventy’s creator, wanted from the start to make Eleventy a modular framework by externalizing advanced features into plugins rather than integrating them into the base package. This keeps the framework’s core lightweight, and everyone can add the plugins they need. Here, we’ll see how to add the @11ty/eleventy-img plugin, which is almost essential for easily managing a site’s images (a complex challenge without the right tools).

Note : Installing the Eleventy package also installs a few default plugins. For these, the first two steps below aren’t necessary.

To add and configure a plugin, follow these 4 steps :

Reference the plugin’s package in the package.json file:

"dependencies": {
    "@11ty/eleventy": "^3.1.2",
    "@11ty/eleventy-img": "^6.0.4"
}

Note : To find the latest version of the package, you can search for it in the official npm package repository. At the time of writing, it’s version 6.0.4. The caret (^) before the 6 means you can automatically receive package updates as long as the major version number (6) doesn’t change.

Download the plugin by running the npm install command in the terminal. This command reads the package.json file and downloads the referenced packages into the node_modules folder.
Import the plugin into the configuration file eleventy.config.js that we created earlier:

import { eleventyImageTransformPlugin } from "@11ty/eleventy-img";

Here, we use the ESM syntax to import the plugin into an object named eleventyImageTransformPlugin (the name is up to you). This object gives us access to the plugin’s configuration.

Configure the plugin by adding the necessary code to the configuration file. Here’s an annotated example of the configuration for our image management plugin:

// Import functions of external libraries
import { eleventyImageTransformPlugin } from "@11ty/eleventy-img";
import path from "node:path";

export default async function (eleventyConfig) {
    // --- ADD PLUGINS and configure it ---

    // Config for the @11ty/eleventy-img plugin
    eleventyConfig.addPlugin(eleventyImageTransformPlugin, {
        // Output images format
        formats: ["avif"],
        // Preserves original image widths and does not create other sizes
        widths: ["auto"],
        // Output files naming
        filenameFormat: function (id, src, width, format, options) {
            // extracts the file name, without extension, from its full path
            const name = path.basename(src, path.extname(src));
            return `${name}.${format}`;
        },
        // Lazy loading of images
        htmlOptions: {
            imgAttributes: {
                loading: "lazy",
                decoding: "async",
            }
        },
        // Options for the Sharp library used by the plugin to encode images in AVIF format
        sharpOptions: {
            animated: true,
        },
        sharpAvifOptions: {
            quality: 60,
            effort: 6,
            chromaSubsampling: "4:2:0",
            bitdepth: 8
        },      
    });
}

Note : Many plugins require much simpler and shorter configuration than this.

The configuration above automatically generates images in AVIF format from source files in PNG or JPG format. AVIF is a modern format widely supported by recent browsers; it significantly reduces image weight, improving page load times, user experience, and natural SEO.

Additionally, the plugin also implements lazy loading for images, allowing users to start reading content without waiting for all images to finish downloading.

We could also ask the plugin to generate a smaller version of each image to further optimize load times on mobile. But this is only really useful for heavy or numerous images. Keeping a single image size simplifies things. This is the choice I made for my own blog, in fact.

By default, generated images have alphanumeric code names. But you can specify a more explicit naming convention using the filenameFormat parameter. Here, we simply take the original image’s name and change its extension to avif.

Conclusion

This article has shown you how to set up an Eleventy project from scratch and how to add plugins.

We’ve now prepared the groundwork for the next steps, where we’ll create our mini-blog. I’ll see you in the next article, where you’ll learn how to create page templates, organize project files, and expand the configuration.

Let me know in the comments if this article helped you and if you have any questions.

Lessons Learned from My Collaboration with AI

Cyril Seguenot — Mon, 14 Jul 2025 15:00:00 +0000

In my previous article, I described my first experience with Gemini Code Assist, Google's coding assistant integrated into VS Code. To test it thoroughly, I recreated a monolingual version of my blog from scratch. Today, I’m sharing the lessons I learned from this experience and how I’m improving my collaboration with AI.

Lessons from My Collaboration with Gemini Code Assist

Take the Time to Describe the Project Well 🖋

When starting a new project, take the time to analyze the project as a whole and create a detailed and comprehensive README file. This first ensures clarity for yourself about what you want to achieve, then it makes the AI’s task easier and yields more relevant responses.

Don’t Be Too Lazy 🥱🏖️

During my test, Gemini generally produced high-quality code, but it still had room for improvement in some areas. The common advice to review the code generated by AI is therefore justified. In particular, it’s important to step back and ask whether the approach taken by the AI is relevant in the given context.

Sometimes, it’s faster to code simple things yourself than to write a prompt and wait for Gemini’s response, which can take over a minute to appear. Plus, this avoids becoming too lazy and saves energy!

Be Patient with the AI and Educate It 🫂

When the AI doesn’t respond to certain requests as desired, it’s easy to get frustrated and speak to it more harshly 🤬 instead of trying to understand why it produced such a response.

What’s important to remember is that doing this puts you in an emotional state that makes the work unpleasant. Usually, if the AI misses the mark, it’s because the request wasn’t precise enough or lacked necessary context.

In this case, there are two options: either refine or break down the request further, or do the work yourself. If you write the code yourself, you can take the opportunity to educate the AI by saying, "Here’s what I expected," and providing the code in context. This is also a great chance to let the AI suggest improvements!

💡 Tip

Ultimately, there’s only benefit in maintaining a collaborative mindset. It keeps you in a positive and pleasant dynamic and gives the AI the opportunity to improve and provide useful suggestions.

Don’t Be Too Greedy 🍰

To save time, you might be tempted to ask the AI to implement a large feature all at once. But this doesn’t work due to the AI’s inherent limitations 😏. And it’s not easy to have a clear understanding of these limits. That’s why, toward the end of the project, I asked Gemini the following question:

What are your limits regarding the number of files and the amount of code you can generate at once? For example, if I gave you the mockups for a complete blog, would you be able to generate all the files at once?

Here’s its response:

Hello! That’s an excellent question that gets to the heart of how best to collaborate with an AI like me.

To answer directly: no, I wouldn’t be able to generate all the files for a complete blog at once from mockups.

There are two main reasons for this:

Response size limit: Each response I generate has a maximum size. A complete project, even a simple static blog, contains many files (HTML, CSS, JavaScript, configuration, etc.) and would almost certainly exceed this limit.
Complexity and quality: Software creation is an iterative process. Asking for everything to be generated at once is an extremely complex task that leaves room for ambiguity. To achieve a high-quality result that truly matches your expectations, it’s much more effective to proceed step by step.

The most productive approach is to treat me as a "pair programming" partner. Here’s how we can collaborate effectively on a large-scale project:

Break down the project: Divide the work into smaller, logical tasks. For example: "Create the basic structure of the Eleventy project," "Create the base layout with the header and footer," "Now, add the CSS styling for the menu," "Implement the article list page," etc.
Work iteratively: Give me one task at a time. This allows you to review my work, correct it if necessary, and give me more precise instructions for the next step. This is exactly the approach you used to recreate your blog, and it’s the most effective.
Provide precise context: Even though I have access to the project files, specifying which files to work on in your request helps me focus and deliver a more relevant and faster response.

In summary, use me not as a "one-click website generator," but as a very fast and skilled assistant who helps you build your project brick by brick. This iterative collaboration ensures you retain full control over the architecture and quality of the final code.

❗ Important

The last sentence seems particularly important to me: "an iterative collaboration that ensures you retain full control over the architecture and quality of the final code."

This implies that you must already have a good grasp of the architecture and technologies you’re implementing!

My Personal Advice for Beginners👉

If you’re new to AI, to have a positive first experience and avoid disappointment from the start, I strongly recommend the following:

💡 Tip

Analyze your project thoroughly at the outset , taking the time to write a README file, for example. This will give you three benefits:

You’ll be much clearer about what you want to do.
The README file will be an excellent way to provide context to the AI.
It will also help you break down the work and formulate requests for the AI.

Another best practice I’ve adopted for quite some time and that helps me a lot:

💡 Tip

Break down important tasks into smaller ones , and write them as a checklist in a Markdown file named, for example, todo.md. As you complete these intermediate tasks, check off the corresponding boxes.

This list will help you stay on track and ensure you don’t forget anything. It’s especially useful if your work spans a long period (several hours or days).

My final piece of advice concerns job search preparation. With AI, it’s clear that beginner developers will find it increasingly difficult to land jobs. Hence my recommendation:

💡 Tip
Before applying for a developer position, first practice on fairly large personal projects without using AI , to familiarize yourself with the languages, frameworks, and architectural concepts you’ll be using. If you don’t have a project idea, a blog or a fictional e-commerce site will work just fine.

In a second phase , once you’ve gained some technical mastery, use AI to familiarize yourself with this tool.

It’s super important to follow this order! Because if you use AI right away without mastering the architecture and code yourself:

⌛ You’ll waste a lot of time in your learning , as you might think you understand the code, when in fact your understanding will be very partial. There’s a huge difference between understanding code written by someone else and being able to write it yourself.
🎭 You’ll likely suffer from imposter syndrome (and rightly so!), as you’ll quickly feel you can’t do much without AI.
💩 You’ll produce crap! Sorry to put it so bluntly, but let’s be realistic. AI is capable of producing very good pieces of code. But if you lack the big-picture vision, perspective, and experience to guide it properly, the overall result will be poor. Only a jeweler knows how to assemble diamonds correctly to make a beautiful necklace.

Feel free to share your thoughts in the comments. And if you have other best practices or tips on how to collaborate effectively with AI, don’t hesitate to share them too! 😉

Behind the Scenes of My Static Blog

Cyril Seguenot — Mon, 07 Jul 2025 02:00:00 +0000

In this article, I briefly introduce the functional and technical characteristics of the blog you're currently viewing. This will give you a good overview of what can be achieved with a static site generator like Eleventy and might even inspire ideas for your own blog.

Features of My Blog

Here are the main features of my blog:

💻 Ergonomics :

Responsive design for a pleasant reading experience on both mobile and PC.
Quick back-to-top button at the top of the page.
On mobile, table content can scroll horizontally for easier reading.

🌐 Multilingual :

The site is available in both French and English. The same pages exist in both languages.
Automatic detection of the browser's language upon arrival on the homepage.
Users can switch languages by clicking an item in the main menu.

🔎 Custom Taxonomy :

Articles are categorized and can have one or more tags.
Articles are first searched by category, then filtered by tags.
Tags can be nested, and their order defines their relevance level for the article. When filtering articles by tag, matching articles are sorted by the tag's position in their tag list to display the most relevant articles first.

🧭 Article Navigation :

The blog page displays article categories. Clicking a category shows the list of articles in that category.
At the top of each article, a breadcrumb trail shows the article's category and allows returning to the category page.
At the bottom of each article, links allow navigation to the previous and next articles.

🖋 Enriched Text :

Different fonts for titles, regular text, and code.
GitHub alert blocks to highlight notes, important elements, warnings, tips, and critical points.
Syntax highlighting for code blocks, with the ability to highlight specific lines.
Font Awesome icons to embellish the text.

💬 Comment Management : Visitors can log in with their GitHub account to leave comments.

✴ RSS Feeds : Automatically generated in English and French.

SEO and Social Media Integration Optimization using standard metadata, Open Graph data, canonical URLs, and Schema.org structured data.

Upcoming Feature

At the bottom of some articles, I plan to add a form allowing visitors to subscribe to my newsletter or receive zip files of sources associated with certain articles. The data entered in the form (name, surname, email address, and page ID) will be sent to an API I developed with ASP.Net Core. My API will then interface with the system.io API, an automated system for contact management and email sending.

👉 Note
What I love about static sites is that the technical architecture and deployment remain simple while allowing the use of external APIs for complex features. The overall solution is more fragmented than with a traditional SPA architecture, but it is lightweight and doesn't require any specific JavaScript framework.

Technical Characteristics

Without delving into code details, here are the essential technical characteristics of my Eleventy project:

✴ Styles : I don't use any CSS framework. All CSS code is embedded in <style> tags in the templates for a modular architecture and fast loading. Each page typically includes no more than 10 KB of CSS (unminified).

❌ JavaScript : I also don't use any JavaScript framework. I use vanilla JavaScript for filtering articles by tags, redirecting to the homepage matching the browser's language, the back-to-top button, and connecting to Google Analytics.

For the form management described earlier, about 60 lines of JavaScript are enough to collect form data, send it to the API, and display a confirmation message.

🗒 Templates : I use the Nunjucks language, which is powerful and versatile. Eleventy natively handles template inheritance. I use Nunjucks macros to create reusable components: breadcrumb trail, short article summary, form.

🌐 Multilingual : The language code ('en' or 'fr') is included in the URL and page metadata. Source files that depend on the language (Markdown files for articles and translated metadata files) have the same names in both languages but are stored in folders named en and fr. This simplifies navigation and language switching.

🔎 Article Categories and Tags : In the project, each category corresponds to a subfolder of the language folder. This makes it easier to locate articles. In the code, each category page contains its collection of articles, stored in the data cascade, a unique Eleventy architecture.

Article tags are defined in the YAML frontmatter of the Markdown files.

🖋 Enriched Text : Eleventy uses the Markdown-it engine by default to interpret Markdown, and I've added the following packages to enhance the syntax:

markdown-it-github-alerts for GitHub alert blocks.
markdown-it-anchor to add anchors to headings and build a table of contents.
@11ty/eleventy-plugin-syntaxhighlight for syntax highlighting.
@11ty/font-awesome to easily add Font Awesome icons to pages. It automatically generates sprites to avoid duplicates.

🖼 Images : All images are centralized in an img folder for easy reference and sharing between languages. My images are mostly diagrams and screenshots in PNG format, but I've configured Eleventy to convert them to AVIF to optimize their size (thanks to the eleventy-img plugin).

I don't create any size variants, and Eleventy automatically generates the HTML for dimensions and lazy loading, which is super convenient!

Finally, I prefix all image names with the article name in which they are used to quickly locate the images for each article.

👉 Note
This image management is pure bliss compared to what I was used to in WordPress!

💬 Comments are managed using the Utterances API and stored in a GitHub repository.

❗Important
The feature that had the most impact on my blog's technical architecture is multilingual support. Indeed, all articles, general interface texts, metadata, and RSS feeds must be available in at least two languages, which complicates things quite a bit.

But while a WordPress site would have required a paid and rather heavy plugin to handle this, my solution remains lightweight and entirely free! I'll present it in more detail in future articles.

Other Templates

On the Starter Projects page of Eleventy's official website, you'll find about 170 templates for different types of sites: blogs, showcase sites, portfolios, etc. The templates usually come with a minimalist demo site. However, it's often impossible to know their technical characteristics without downloading the template and examining its code, which is a shame.

I hope this article has given you a clearer idea of the possibilities offered by the Eleventy SSG. Let me know in the comments if you found it useful, and feel free to ask questions if you have any 😉.

My First Experience with Gemini Code Assist

Cyril Seguenot — Mon, 07 Jul 2025 00:00:00 +0000

In this article, I share my first experience using Gemini Code Assist, Google's new AI-powered development assistant, which was released in June 2025.

The Context of the Experiment 🧪

Until now, I had been using AI for development in a sporadic and non-integrated way, copying and pasting code snippets generated by Perplexity or DeepSeek into VS Code.

But the release of Gemini Code Assist (GCA), with its very generous free offering and its integration into VS Code, encouraged me to explore the potential of this AI assistant. To properly gauge its capabilities, I decided to recreate with GCA's help a complete project that I had previously developed myself without AI assistance. This would allow me to evaluate at least two things:

The relevance of the code generated by Gemini compared to what I had produced myself.
The time saved thanks to AI.

So, I attempted the following experiment: recreate a simplified version of my blog, develegant.com, based on the Eleventy static site generator, while relying heavily on Gemini Code Assist.

The main simplification compared to my original blog, whose full features I described in my previous article, is that this new blog is not multilingual. This is a significant simplification, as managing multiple languages impacts the entire project.

ℹ Note
This simplification doesn't allow for a rigorous comparison between Gemini's work and my own, but I didn't want to be overly ambitious for a first try with a tool I knew nothing about. Note, however, that since I created my original blog without AI assistance, I have a solid grasp of the Eleventy SSG, and I knew exactly what result I wanted to achieve and the steps to get there.

My Work Method 👷

To initialize my Eleventy-generated blog project, I manually created the folder structure and the few basic files required for this type of project in VS Code:

Configuration file: eleventy.config.js
package.json file describing the build packages and commands
Base layout file for all pages: base.njk
Index file for the blog's homepage

Most importantly, I reused the README file from my original blog, which describes all its features , removing anything related to multilingual support. This 800-word file served as a reference for Gemini to contextualize each request.

To work with Gemini Code Assist, I mainly used the chat feature, which is well-suited for requests affecting multiple files.

GCA has access to all the files in the project and can therefore modify multiple files at once. However, if the changes pertain to a specific file, it's better to specify it as a "context item" under the prompt box to make its task easier. By default, GCA automatically selects the file corresponding to the current tab in VS Code.

Note: Since the chat requests allowed me to generate almost all the code, I did very little manual coding and therefore rarely used the intelligent code completion feature.

The Results of This Experiment with Gemini Code Assist and the Eleventy SSG

Let me say it right away: the outcome is very positive!

Even though I knew nothing about Gemini Code Assist at the start, I was able to generate a new blog in a full day of work, while also learning new things. It even helped me improve some parts of the code in my original blog.

What Impressed Me 😲

🎯 Gemini's Technical Relevance

Gemini implemented article filtering by tag in JavaScript in less than a minute, whereas it had taken me at least a day to do it manually in my original blog. Plus, its solution is simpler than mine!

The code it generated for category management also gave me an idea for improving the one I had written in my original blog. When discussing certain technical hypotheses with it, Gemini provided excellent arguments for choosing the most suitable one. This clearly illustrates the added value of AI for specific technical tasks.

ℹ The Quality of Gemini's Explanations

I was impressed by the clarity and precision of Gemini's explanations, which were always tailored to the context of the question.

The Challenges I Faced 🫤

The main difficulty I encountered several times was breaking down certain tasks sufficiently. For instance, if a request, even a simple one, requires modifications to a large number of files, Gemini Code Assist displays the following error message:

❌ A code sample in this response was truncated because it exceeded the maximum allowable output. Please use the response carefully. You may also try your question again, selecting a smaller block of code as the context.

But the response isn't actually displayed at all...

To work around this, you have to tell Gemini that you didn't get the response and ask it to modify only certain files.

Note: In Google's satisfaction survey, I made the following suggestion: in such cases, GCA should display the list of files impacted by the request (just their paths) and ask us to break the work down further.

In a similar vein, I asked Gemini to tell me what the impacts would be of replacing the I18n plugin, which provides multilingual services, with custom code in my original blog.

The response it gave me was very incomplete , as it mentioned only one file to modify when there were actually about ten. Even though, in this specific case, the changes weren't too hard to make manually thanks to VS Code's global search, this type of response can be misleading.

Despite these technical limitations, my overall impression remains very positive due to the quality of the collaboration with Gemini.

Collaborating with AI Is Truly Enjoyable 🤩

Although I enjoy coding myself, I genuinely enjoyed collaborating with Gemini, both technically and relationally.

💻 On the technical side , Gemini made few mistakes and taught me things. It's better than me at some things, and I'm better than it at others. So, it's not a master-student or mentor-beginner relationship, but a true collaboration. Our strengths complement each other, and I work faster and better with GCA!

🤝 On the relational side , Gemini is very patient, never gets annoyed (fortunately), and adopts a courteous and encouraging tone. What more could you ask for?

This made me want to praise Gemini and adopt a friendly tone in our exchanges. Our dialogue was therefore very pleasant, constructive, and stimulating for me.

ℹ Note
The trap might be getting too used to this quality of dialogue and expecting the same from the humans around you 😁, or becoming too disconnected from the real world. But we can also take inspiration from AI to be more pleasant with our colleagues 😉!

Conclusion

This discovery of Gemini Code Assist was a pleasant and encouraging experience that made me want to continue. I'd be curious to see its capabilities on larger projects. I hope Google will better handle the issue of truncated responses mentioned earlier.

Given the quality of Google's free offering, I'm also eager to see how its main competitors—Windsurf, Cursor, and GitHub Copilot—will respond.

If you found this article interesting, please like it to support my work. And if you've tried Google Code Assist yourself, feel free to share your thoughts on this tool in the comments.

In a future post, I'll share the lessons and best practices from this experience.

The 4 Reasons Why I Prefer Eleventy Over Other SSGs

Cyril Seguenot — Mon, 23 Jun 2025 00:00:00 +0000

In this article, I’ll share why I chose the static site generator (SSG) Eleventy over more well-known generators like Hugo, Gatsby, Astro, or Jekyll for creating my blog.

ℹ Note : I’m not claiming that Eleventy is better than other SSGs. That would be like saying an apple is better than a pear, strawberry, cherry, or apricot. Each tool has its own characteristics, and each user has their own criteria for choosing.

❗ Important
The most important thing is to be clear about the criteria that matter most to you and to find the tool that best fits. That’s why I’ll share my own criteria and how Eleventy meets them.

The Criteria That Led Me to Choose Eleventy

My criteria are shaped by the frameworks and languages I already know and my natural preference for simplicity and lightness. I wanted an SSG that :

🧠 Requires learning few new things. As someone specialized in ASP.Net/Blazor for web development, I’m comfortable with vanilla HTML/CSS/JS but don’t master classic web frameworks like Angular, React, Vue, or Svelte, and I don’t have time to learn them.

With Eleventy, I only had to learn the Nunjucks templating language, which was very quick—probably 100 times faster than if I’d had to learn React, for example.

🪶 Has a lightweight technical environment , meaning little to install.

Eleventy relies on Node.js and doesn’t require any other specific installations. It provides its own lightweight web server. So, you just need to know how to initialize a Node project and the basics of npm and the package.json file to generate the site and run the local server. But the documentation guides you through this.

🗒 Allows writing blog posts in Markdown.

Eleventy uses the markdown-it engine to handle Markdown. It’s arguably the most popular and comes with extensions for advanced syntax elements like GitHub alert blocks, anchors, etc. What more could you ask for?

🔧 Allows complete customization of your site.

Eleventy is very versatile and flexible, letting you customize everything. To go faster, you can draw inspiration from templates close to what you want to do. However, for my blog, I struggled to find such a template and ended up adapting the basic "Eleventy base blog" template, which I barely kept anything from in the end 😊.

🗲 Fast (I’m talking about the speed of generating the site from template files, CSS, and images). Since you’ll be generating the site often, it’s important for this operation to be quick.

Eleventy is the speed champion, thanks to its lightness. Unlike other tools like Vite, Webpack, etc., it does fewer things, and that makes it much faster.

📖 Well-documented enough.

Eleventy’s documentation is the only point I find rather mediocre, though not outright bad. I’ll come back to this later...

🤩 Popular enough to ensure its longevity.

Eleventy isn’t the most popular SSG if you look at, say, GitHub stars. It currently has 18k stars compared to 51k for Astro and 56k for Gatsby. But it’s clearly popular and well-established enough to have a very good chance of lasting.

Areas for Improvement

I’m really super satisfied with Eleventy and have almost no complaints about the tool itself. However, I see three major improvements for the Eleventy website that, in my opinion, could significantly increase the tool’s adoption:

📖 Improve the documentation , which currently lacks context.

Many techniques are presented without their use cases, with overly basic examples. As a result, when you’re starting out, it’s hard to know when to use one technique over another. I had to do a lot of trial and error to deeply understand certain concepts and use them effectively. But on the bright side, I now have plenty to share on my blog 😉!

Note: As a trainer, I know I set the bar high for documentation because it’s my specialty. I’ve written thousands of pages of docs and articles and created hundreds of videos, mostly for beginners. So, naturally, I’m sharp and demanding on this topic...

🗹 Make it easier to select a project template. The Starter Projects page, which lists the 170 available project templates to date, offers no way to filter the list, and the template descriptions are very brief. It’s very hard to find a template that matches your needs. Not to mention that some templates are outdated because they were created with older versions of Eleventy...

🖺 Improve the official base template. I think the "Eleventy Base Blog" template provided by Zach Leaderman is of rather mediocre quality:

The implementation of the article list as a partial template is, in my opinion, a very poor choice. It makes the code complicated and non-modular, while also setting a bad example for usage.
The styles are lumped together in an index.css file, whereas it would be better to link them to the respective layouts to isolate them and make the code more modular and easier to maintain.

When Should You Use Eleventy?

To summarize, if you’re still wondering whether Eleventy would suit your needs, here are the factors to consider.

First, it’s important to clearly understand the characteristics of a static site compared to a dynamic one.

A static site is an excellent solution if...

💲 You want a completely free solution (including hosting if you use, for example, GitHub Pages).

🛡 You want to create a secure website, but implementing security techniques bores you. So, you want an effective but easy-to-implement solution.

🖧 You have few customer data to store on the server side, and you are ready to use external APIs for that.

🔧 You prefer customizing your site directly with HTML, CSS, and JavaScript code rather than through plugins (like in WordPress).

🖋 You want to write your blog posts in Markdown in your favorite editor (e.g. Obsidian)

🎛 You like to have complete control over your site (structure, appearance, performance, SEO...), without unnecessary complexity.

🔄 You want to create your site locally and deploy it easily to a server by changing its base URL.

ℹ For more details on static sites and their differences from dynamic ones, check out this article.

If you’ve decided to create a static site, why choose Eleventy over another SSG?

Eleventy is the SSG for you if...

🪶 You particularly appreciate lightness and simplicity, and don't want to have to install and master loads of tools.

🗲 You need a fast SSG (I'm talking here about the speed of generating site pages from source files), especially if you often generate your site.

🖼 You want a simple, high-performance solution for managing your images and icons.

🔗 You don't want to depend on any particular JavaScript or CSS framework.

Note that Eleventy can generate all the types of static sites listed in my dedicated article on static sites:

Blogs
Magazines
Documentation sites, wikis, knowledge bases
Educational sites and online courses
Event sites (conferences, weddings, etc.)
Showcase sites (business sites, product pages)
Portfolios and online CVs
...

What about you? Do you use or plan to use an SSG? If so, what criteria guide your choice? Let me know in the comments.

The Superpowers of Templates Languages - Part 3

Cyril Seguenot — Mon, 16 Jun 2025 00:00:00 +0000

This article is the final installment in a series dedicated to server-side templating languages.

The previous article demonstrated how to inject data into HTML pages and how to efficiently manage page layouts using template inheritance.

Now, let’s explore another fascinating topic for modern websites: how to create reusable components using templates.

The goal is to maintain a clean and maintainable server-side architecture, even when using a non-component-oriented server framework. As you’ll see, templating languages excel at meeting this challenge!

The Challenge

Template inheritance is an effective way to share code between templates when all derived templates need the entirety of the parent template’s code. In the previous article, we saw the classic example of a parent template containing a header and footer shared across all site pages.

But let’s take the example of a blog where multiple authors publish articles. Suppose we want to display a brief author bio at the bottom of each article and create a page listing all the blog’s authors.

Creating a common ancestor for article and author list templates wouldn’t solve the need to display multiple authors on the same page.

Here, we clearly need an independent template to model an author, which can then be integrated into both article and author list templates. This calls for a composition relationship.

💡 Template composition is well-suited for the following cases:

For template fragments repeated multiple times on the same page.
For template fragments present in several (but not all) page types.
To replace inheritance in templating languages that don’t support it.

There are two types of templates for composition:

Partial templates , which are a limited solution, as you’ll soon see.
Macros , which are very similar to the concept of components.

Partial Templates

A partial template is simply a piece of a template stored in an independent file. Here’s an example of the partial template author.njk representing an author:

<div class="author">  
   <img src="/public/img/" alt="" class="author-photo"/>  
   <div>  
      <p class="author-name"></p>  
      <p class="author-bio"></p>  
   </div>  
</div>

To include this partial template in the article template, add the following code where desired (e.g., at the beginning or end):

{% set author=metadata.authors | getAuthorById(authorId) %}  
{% include "components/author.njk" %}

The first line retrieves the author by filtering the metadata.authors collection using the authorId property of the article. The set instruction stores the author in the author variable, which is the one used in the author.njk component.

❗The key point here is that the author template has access to the article template’s context, including the author. Unlike a component, a partial template doesn’t have its own data context but shares that of its host.

When generating HTML pages from the templates, each article page will include the code produced by the partial template.

⚠ Partial templates are a simple way to centralize static content. However, their lack of parameterization and shared context with the host significantly limits their usefulness. This creates a tight coupling between partial templates and their hosts, which undermines modular and maintainable long-term architecture.

Macros (= Components)

To avoid the coupling issue between partial templates and their hosts, some modern templating languages offer macros, which are very similar to the component concept found in frameworks like Nuxt.js.

Example

Let’s revisit our partial template author.njk and transform it into a macro:

{%- macro Render(author) %}  

<div class="author">  
   <img src="/public/img/{{ author.photo }}" alt="{{ author.name }}" class="author-photo"/>  
   <div>  
      <p class="author-name">{{ author.name }}</p>  
      <p class="author-bio">{{ author.bio }}</p>  
   </div>  
</div>  

{% endmacro %}

A macro is equivalent to a function and can accept parameters. Here, the Render macro receives the author object as a parameter.

To use this macro in the article template:

{% set author=metadata.authors | getAuthorById(authorId) %}  
{% import "../components/author.njk" as Author %}  
{{ Author.Render(author) }}

The first line retrieves the author whose ID is provided by the current article.
The second line imports the macro’s file content and assigns it the alias Author. This alias refers to the file’s namespace, which may contain multiple macros.
The third line calls the macro via this alias, passing the author as a parameter.

❗The key takeaway: The macro doesn’t share the host template’s context but receives the data it needs via parameters. This eliminates any coupling between the two.

ℹ The component’s CSS can be placed in an author.css file and imported into the base template using the standard syntax:

{% include "../components/author.css" %}

This way, the component’s CSS will be shared across all its instances if the component is used in multiple places.

Advantages of Macros Over Partial Templates

Macros:

Define an isolated context for variables, avoiding coupling with external code.
Can accept parameters.

Additionally, like partial templates, macros can be nested—meaning they can call one another.

Thus, even with server frameworks lacking native component support—such as Flask (Python), Symfony (PHP), Jekyll (Ruby), Express.js, and Eleventy (Node.js-based)—it’s possible to create clean, modular code using macros.

ℹ Macros are particularly well-suited for static server-side rendering. They don’t replace the client-side component concept introduced by React.

Which Templating Languages Support Components?

Most advanced templating languages support the concept of components, whether they’re called components, macros, mixins, or functions, as shown in the table below:

Templating Language	Framework	Component Implementation	Example Syntax
Nunjucks	Node.js	macros	`{% macro %}`/`{{ macro() }}`
Jinja2	Flask, Django	macros	Same as Nunjucks
Twig	Symfony	macros	Same as Nunjucks
Blade	Laravel	components	`<x-component>`
Pug	Node.js	mixins	`mixin`/`+mixin()`
EJS	Express.js	JS functions	`<% function() { %>`

Conclusion

Mastering a powerful templating language is a major asset for creating clean, modular, and maintainable code. In particular, components enable modular code architecture even with server frameworks that don’t natively support the concept.

For my static blog, I use the Nunjucks templating language with the Eleventy framework. I discovered both at the same time, and it took me a few days to get comfortable with Nunjucks’ syntax. Now, I truly appreciate its power and expressiveness.

I use template inheritance for layouts and components for breadcrumbs and article summaries (on category pages). My code architecture remains simple and clean, and I can handle complex challenges like translation and taxonomy much more easily, with greater customizability and performance than with WordPress. It’s a real pleasure!

Finally, I’d love to hear which templating languages you use and whether you’re satisfied with them. Share your thoughts in the comments! And if you found this article helpful, please like it to help spread the word. 😉

The superpowers of template languages - Part 2

Cyril Seguenot — Tue, 10 Jun 2025 00:00:00 +0000

This article is the second in a series dedicated to server-side templating languages. In the previous article, we covered the goals of templates and an overview of the main templating languages. Now, let’s dive into the technical aspects and explore two major features of templates:

Data injection into pages
Page layout management through inheritance

Injecting data into pages

Templating languages provide instructions to easily integrate data from the application into HTML pages. A template file is thus a mix of classic HTML/CSS and specific templating syntax elements, such as variables, loops, conditions, etc.

Example: A template file can be used to build a blog's article list from article metadata (title, date, tags, etc.).

The PHP, Python, JavaScript, or other backend code provides the collection of metadata, and the template iterates over this collection to construct an HTML list (using <ul> and <li> elements).

Here’s an excerpt from the first version of the Nunjucks template I used to build my blog’s article list. It uses a collection named category.posts containing the articles of a category.


{# List of posts of the category #}  
<ul id="postList">  
   {%- for post in category.posts %}  
   <li class="post" data-rank="0">      
      <a class="post-title" href="{{ post.url }}">{{ post.data.title }}</a>  
      <p>{{ post.data.description }}</p>  
      <div class="post-metadata">  
         <div class="post-taglist">Tags:   
            {%- for tag in post.data.tags %}<div class="post-tag">{{ tag }}</div>{%- endfor %}  
         </div>  
         <div>{{ labels.lastEdition }}:   
            <time class="post-date" datetime="{{ post.date | htmlDateString }}">{{ post.date | readableDate() }}</time>  
         </div>  
      </div>      
   </li>  
   {%- endfor %}  
</ul>

All the code between curly braces is Nunjucks template syntax. Three types of braces are possible:

{# #} for comments
{% %} for flow control (loops, conditions, etc.)
{{ }} for evaluating or displaying expressions

In the above excerpt, you can see a few syntax elements:

{%- for ... in ... %}...{%- endfor %} represents a for loop.
{{ post.data.description }} displays the article’s description.
{{ post.date | readableDate() }} calls the readableDate method on post.Date to format the article’s creation date.

Note

The | (pipe) operator allows calling a method while passing the starting object as a parameter.

Multiple | can be chained to call different methods in sequence. For example, the expression {{ object | filter1() | filter2() }} calls filter1() with object as a parameter, then filter2() with the result of filter1() as a parameter. This is called function composition, a powerful feature of some templating languages.

Without delving deeper into Nunjucks syntax, this example already gives you a good idea of how templating syntax integrates data into HTML. Now, let’s explore layout and composition techniques.

Managing Page Layouts with Template Inheritance

When creating templates for different page types (e.g., homepage, article list page, single article page, etc.), it’s common for these templates to share common parts like headers and footers.

Instead of repeating the code for these shared parts in every template, we can share them between templates using template inheritance. This concept is similar to what you’d find in object-oriented programming languages.

Warning

Advanced templating languages like Jinja2, Nunjucks, Twig, Django, Pug, and Blade support inheritance, but simpler languages like Handlebars, Mustache, HAML, or Markdown do not, nor does the Liquid language.

How template inheritance works

The inheritance relationship involves creating a base template containing all the shared elements and derived templates representing the different page types you need. Derived templates inherit all the content from the base template and can add or override specific elements (e.g., the main content area of the page).

For example, my Eleventy-powered blog uses 5 Nunjucks templates corresponding to different page types, all derived from a base template containing the header (with title and main menu) and footer.

The green shapes represent category and article pages. Articles are Markdown files, but they can still inherit from the Nunjucks layout post.njk thanks to an abstraction layer managed by Eleventy, which relies on frontmatter placed at the beginning of files (more info on this documentation page). However, in the following code examples, to avoid confusion, I’ll show you pure Nunjucks inheritance syntax.

Note

The inheritance relationship can, of course, be extended to more than two levels to create a more complex template hierarchy.

Implementing the inheritance relationship

As you’ll see, the technique is very simple.

Here’s an example structure for the base template :


<head>  
<!-- head content -->  
</head>  
<body>  
   <header>  
   <!-- header content -->  
   </header>  
   <main>  
      {% block mainContent %}{% endblock %}  
   </main>  
   <footer>  
   <!-- footer content -->  
   </footer>  
</body>

{% block mainContent %}{% endblock %} is Nunjucks syntax for defining a named block called mainContent, which is empty here but can be overridden in derived templates.

In all derived templates , add the following code to implement inheritance:


{% extends "base.njk" %}  

{% block mainContent %}  
<!-- code that describes the main content of the page -->  
{% endblock %}

The first line establishes the inheritance relationship. The following lines override the mainContent block by adding code specific to the derived template.

To be continued

Template inheritance already allows for efficient project structuring. But we can go further with advanced composition and modularity techniques, which we’ll explore in the final part of this series.

In the meantime, if you found this article helpful, please like it to help spread the word. 😉

The Superpowers of Template Languages - Part 1

Cyril Seguenot — Fri, 30 May 2025 00:00:00 +0000

This article is the first in a series of three aimed at giving you a comprehensive overview of the possibilities offered by server-side templating languages.

In this series, we will cover:

What templates are used for and the main templating languages available.
How to inject data into HTML pages and intelligently manage their layout using template inheritance.
How to create reusable components with templates to maintain a clean and maintainable server-side architecture.

Without further ado, let’s begin with the first part.

What Are Templates Used For?

When creating a website or application, we generally aim for code that is easy to read, test, and maintain. Centralization and modularity of code are particularly important. Templates can contribute to this in three ways:

Easily inject data into pages , typically data from a database, computed data, or metadata in the case of SSG (Static Site Generation). This ensures cohesive pages, simplifying debugging and maintenance.
Centralize page layout and facilitate the creation of new derived layouts.
Create reusable components , such as breadcrumbs, author profile cards, article summaries, etc.

These needs emerged early in server-side web development with frameworks like PHP, ASP.Net, Python, Ruby, etc. Each of these frameworks introduced a default templating engine.

Templating even made its way to the client side with JSX, introduced by React, though it’s more of a JavaScript transpilation syntax than traditional templating.

Today, structuring web applications into components has become the norm on the client side and is increasingly common on the server side. Frameworks like Blazor, Next.js, Nuxt.js, and Svelte Kit enable server-side rendering (SSR) with a component-based structure to meet the needs of code organization, maintainability, and reusability.

ℹ Note
However, we’ll see that some templating languages also allow implementing the concept of components in frameworks that don’t natively support it! This is one of the great strengths of templates!

A Simple Templating Language: Markdown

You may have already created templates without realizing it if you’ve written in Markdown. Markdown is a very simple templating language for creating written documents in formats like HTML, PDF, Word, etc. Here’s a small excerpt of Markdown with headings, lists, and bold text (a handy guide is available here):

### Lists  

**Bullet List:**  

- item 1  
- item 2  
- item 3  

Note: You can also use a + or * instead of -. The result is the same.  

**Numbered List:**  

1. item 1  
2. item 2  
3. item 3  

You can use different numbers or leave the number 1 on each line. The editor automatically increments the numbers in the final output.  

### Hyperlinks and Images  

Link to another site: [Markdown Guide](https://www.markdownguide.org/)  

Embed an image file: ![favicon](img/favicon.png)

To transform Markdown into HTML, you don’t need a complex web framework—a parser is enough. Note-taking apps like Obsidian and Typora (my favorites), for example, include a Markdown parser to preview the HTML output in real-time and optionally export it to other formats.

Markdown is well-suited for creating simple documents or pages, but for building complex websites with dynamic layouts and variable data, more advanced templating languages are needed. Let’s take a quick tour of the main templating languages available today.

What Are the Main Templating Languages?

You might think that each web framework has its own templating language, and that’s it! But reality is a bit more complex...

Each web framework does have a native templating syntax. The following table (non-exhaustive) provides a few examples:

Web Framework	Language	Native Templating Syntax
Symfony	PHP	Twig
Spring Boot	Java	Thymeleaf
ASP.Net Core	C#	Razor
Ruby on Rails	Ruby	ERB (Embedded Ruby)
Django	Python	DTL (Django Template Language)
React	JavaScript	JSX

However, some frameworks support other templating syntaxes, and conversely, some templating syntaxes can be used across multiple frameworks!

To give you an idea, the following table expands on the previous one by listing the templating syntaxes supported by the main web frameworks. It specifies the default templating language for each framework and other languages that can be used with the corresponding extensions:

Framework	Side	Language	Supported Templating Languages
Ruby on Rails	server	Ruby	ERB (default), Haml, Slim, Liquid
Django	server	Python	DTL (default), Jinja2
Flask	server	Python	Jinja2 (default), can integrate Mako, Cheetah
Laravel	server	PHP	Blade (default), Twig (via package), Smarty
Symfony	server	PHP	Twig (default), native PHP
Express.js	server	JavaScript	EJS (default), Pug (formerly Jade), Handlebars, Mustache, React/JSX
Spring Boot	server	Java	Thymeleaf (default), Freemarker, JSP, Mustache
React	client	JavaScript	JSX (built-in, transpiled to JS)
Vue.js	client	JavaScript	Vue templates (.vue), JSX (optional), Mustache
Angular	client	TypeScript	Angular templates (HTML + proprietary syntax)
Svelte	client	JavaScript	Svelte templates (.svelte), enhanced HTML

Remark: For React, JSX is not a templating engine in the traditional sense but a JavaScript transpilation syntax.

ℹ Note
In 2011, Mozilla released the Nunjucks templating language, a modern clone of Jinja2 designed for backends and static site generators (SSG) based on Node.js. For example, the SSG Eleventy supports Nunjucks (among others).

Conclusion

We’ve explored the main uses of templating and an overview of the associated languages and frameworks. In the next part of this series, we’ll see how to implement the concepts introduced here, with Nunjucks code examples. But beyond syntax, the most important aspect will be understanding the approaches used, which remain valid regardless of the language.

In the meantime, if you enjoyed this article, please like it to help spread the word. 😉

Why create a static website?

Cyril Seguenot — Thu, 29 May 2025 00:00:00 +0000

This article will give you a solid overview of static websites and their typical use cases. Who knows, it might even inspire you to create your next site!

To understand what a static website is, let’s start with a quick refresher on dynamic websites...

Dynamic websites

Today, the two most common ways to create web applications or websites are:

A server framework like Symfony, ASP.Net Core MVC, Django, Express.js, Ruby on Rails, etc., to create multi-page applications (MPAs). The diagram below illustrates the request processing flow in this type of application.

Or a client framework like Angular, React, Vue, Svelte, etc., leveraging a web API created with a server framework to build single-page applications (SPAs).

These two approaches can be combined to get the best of both worlds, albeit with some added complexity. For example, Nuxt.js, which builds on Vue.js for the client and Node.js for the server, offers this hybrid approach.

In all cases, page rendering is dynamic—either on the server (Server-Side Rendering) or the client (Client-Side Rendering). This means each page displayed to the user is constructed (at least partially) on the fly in response to their request.

Static websites

For creating websites, there’s a third, often overlooked approach that has been gaining traction in recent years: SSG (Static Site Generation). This method involves generating pages in advance, during development , rather than dynamically when clients request them.

With SSG, HTML pages are pre-generated and copied as-is to the server. The server then only needs to deliver them in response to client requests, requiring no frameworks or databases.

The top part of the following diagram shows the generation of static site pages from a set of sources (templates, data, and images) using a static site generator.

Once the site is deployed, users retrieve pre-built (and potentially cached) HTML pages when browsing, resulting in extremely fast navigation.

Use cases for static websites

Let’s be clear: static websites are inherently more limited than dynamic ones:

Limitations of Static Websites

They cannot directly process client-submitted data on the server. As a result, they don’t natively support features like authentication, user accounts, blog comments, etc.
They’re unsuitable for sites with frequently changing content, as each update requires regenerating and redeploying the entire site.

Note : To work around the first limitation, pages can use JavaScript to call external APIs or serverless services for storing and processing user data (the Jamstack principle—Jam for JavaScript, APIs, and Markup).

But in many cases, dynamic websites aren’t truly justified, and static sites offer a simpler solution!

Here are the types of sites that can be built as static websites:

Blogs
Magazines
Documentation sites, wikis, knowledge bases
Educational sites and online courses
Event sites (conferences, weddings, etc.)
Business websites, product landing pages
Portfolios and online CVs
...

As you can see, the range is quite broad!

Advantages over dynamic websites

Static websites offer substantial advantages over dynamic ones:

Advantage	Explanation
💻 Simpler development	SSGs provide many built-in features out of the box.
🚀 Blazing-fast loading	HTML pages are ready to be served immediately upon HTTP requests.
🔒 Highly secure	No database. Zero client data storage on the server.
🔖 SEO-friendly	Thanks to fast performance and clean, optimized code.
🔁 Easy deployment	No server-side framework or database. Wide hosting options (including CDNs).
🔧 Zero maintenance	No backups, restorations, or database optimizations needed.
⚙️ Easy automation	Automated builds/deployments via GitHub or other CI/CD pipelines.

One key point to remember:

Note

The term "static website" refers to how pages are generated and delivered , not their behavior. Pages can still include JavaScript for dynamic visuals or to call external services :-).

For example, a static page might include a script to let users filter table content without leaving the page.

How to create a static website?

Static websites have existed since the dawn of the web. The very first sites were purely static—but back then, every HTML page had to be created manually...

Static site generators

Today, modern tools called static site generators automate the process of building a static site from sources (templates, data, and images), as shown in the earlier diagram.

Popular static site generators include Hugo, Gatsby, Jekyll, Eleventy...

You’ll find a comprehensive, popularity-ranked list on this excellent page. Many are JavaScript-based, but not all.

Heads up

Frameworks like Next, Nuxt, or Astro can create both dynamic and static sites, but they aren’t the simplest tools for pure static sites!

Personally, I chose Eleventy for its lightness, speed, and versatility. This generator is a true gem!

Now, let’s dive deeper into the files needed to build a static site.

Templates

Template files are HTML page blueprints. They rely on template engines like Markdown, Nunjucks, Liquid, Pug, JSX, or Go to generate final HTML pages by injecting variable data (which I’ll detail next).

For static sites, simple content (articles, courses, product descriptions) is typically written in Markdown templates —a clean, concise, and readable format.

For composing pages from multiple elements and handling layouts, a more advanced templating language is needed. Here, HTML files (optionally including CSS/JavaScript) are enhanced with template directives like conditionals, loops, and partial template imports.

To create complex page structures, you can aggregate partial templates and use template inheritance , as shown below:

For my blog, I use a base template for the header and footer, with derived templates for different page types (homepage, blog, articles...). All pages inherit the header and footer.

I also created a partial template for breadcrumbs, referenced in pages that need it.

I won’t delve into template syntax here—that’s a topic for another article.

Data

Templates use various types of variable data to build HTML pages:

Page metadata : URL, title, description, creation date, language, category, tags, etc.
Collections : e.g., a blog’s article collection.
Computed data : e.g., breadcrumbs.
Translated labels for multilingual sites.
etc.

Static site generators provide various mechanisms to allow templates to access this data. For instance, Hugo and Eleventy (and to a lesser extent, Jekyll) offer the powerful concept of data cascade , while Gatsby relies on GraphQL queries.

A template representing blog posts can thus access the metadata of the article it describes. When generating HTML pages from templates and data, each article page incorporates its specific metadata.

The data cascade allows defining data in different places:

YAML front matter in Markdown template files.
JS or JSON data files.
Configuration file objects in the generator’s code.

Components

Nowadays, structuring web applications using components has become the standard. This is especially true for client-side SPAs (Single-Page Applications), but modern frameworks like Blazor , Next.js , Nuxt.js , and Svelte Kit also enable component-based architecture on the server side. These frameworks can even be used to build static sites.

However, even with traditional server frameworks that don’t natively support components, it’s still possible to create them using templating languages.

For example, Jinja2 , Nunjucks , and Twig allow component creation through macros—and they work exceptionally well!

On the server side, concepts like template inheritance and components help build a modular and maintainable architecture.

Important

Server-side components should not be confused with client-side components like those in React. Client-side components are primarily used to create dynamic and interactive interfaces, where the application state changes on the client side—something that doesn’t happen in static sites.

That said, it’s still possible to integrate a few interactive client components into an otherwise static site. For example, Eleventy offers this capability through its WebC plugin for components.

In summary

I love using the right tool for the job.

Heavyweight frameworks like Angular, React/Next, Vue/Nuxt, Blazor, and CMSs like WordPress are perfect for highly interactive or dynamic applications, such as e-commerce, social networks, chat apps, banking, etc.

Static site generators (SSGs), on the other hand, shine for sites with infrequently updated content and no server-side client data storage: blogs, magazines, portfolios, documentation, course sites, business websites, etc.

For these use cases, SSGs offer major advantages over dynamic sites in terms of editing, performance, security, maintenance, and deployment.

Personally, even though WordPress’s Gutenberg editor is powerful, I find writing blog posts in Markdown with Obsidian on my PC far more comfortable! In this article, I detail the other reasons that led me to switch from WordPress to Eleventy.

Finally, the Jamstack approach overcomes static sites’ limitations by using JavaScript to call external APIs, adding dynamic content or interactive features.

Have you ever created a static website, and if so, with what tools? Otherwise, do you plan to create one?

Why I chose Eleventy over WordPress for my blog ?

Cyril Seguenot — Wed, 21 May 2025 00:00:00 +0000

In this article, I’ll share why I chose the Eleventy framework to create this blog, even though I’m a big fan of WordPress. Along the way, you’ll see the major advantages of static sites over WordPress. Let’s dive in!

The WordPress journey

A rich ecosystem

To create a WordPress site, you need three essentials: a PHP server, a MySQL database, and a theme. But plugins quickly become indispensable for handling many aspects of the site:

Maintenance and security : Backups and restorations of files and the database.
SEO optimization : Sitemap generation and SEO tweaks.
Advanced blocks : Table of contents, popups, forms, etc.
Performance optimization : Bundling, caching, image compression...
Multilingual support.
...and more.

WordPress’s ecosystem is impressively vast—it’s rare to find a need not covered by a theme or plugin! This richness is a key reason for WordPress’s success.

The FSE revolution

Since version 6.2 (released in 2023), WordPress allows full-site customization using Gutenberg, its default editor. Headers, footers, menus, sidebars—everything can now be edited with Gutenberg, provided you use a compatible theme. This is called FSE (Full Site Editing), a still-evolving but already powerful technology.

I think this is fantastic because:

For advanced, custom layouts (like homepages), you no longer need third-party page builders like Divi or Elementor. Gutenberg alone suffices.
Theme choice matters less if it’s FSE-compatible. You can always tweak elements with Gutenberg, so themes save time without limiting creativity.
FSE reduces plugin reliance, making sites lighter and faster.
It’s still user-friendly. Despite the many components and options, I quickly got the hang of FSE.

My site bureautique-efficace.com previously used the OceanWP theme and Elementor. I rebuilt it entirely with FSE (WordPress’s 2024 theme) and just 7 plugins. The result? A much faster and simpler-to-maintain site!

So, is WordPress + FSE the perfect solution?

The flip side

Despite FSE’s progress, many plugins remain essential for the needs listed earlier—and this brings problems:

Plugins that affect page rendering often slow down the site.
Themes and plugins are potential security vulnerabilities.
Finding and testing the right plugins for niche needs can be tedious.
The best themes/plugins are usually paid, with expensive annual subscriptions.
While plugins cover almost every need, cobbling them together can’t match the customization and performance of integrated solutions.

As a developer and trainer, I’d rather invest time in honing my technical skills than testing and tweaking plugins...

What pushed me to explore alternatives

I’ve often been frustrated by plugin dependency and their costs. When I decided to create this blog, I searched for the best multilingual plugins—only to face familiar issues:

Complexity : Analyzing and testing plugins is time-consuming (and their flaws are often hidden).
Cost : The best plugins were pricey.
Performance/maintainability : How would these plugins impact my site?

I was growing weary but saw no alternatives. I assumed building a blog without WordPress would be tedious, like reinventing the wheel—with inferior results.

I was wrong.

I’d overlooked frameworks that create lighter, faster, and more customizable static sites than WordPress.

Discovering Eleventy

While reading an article on Gui Ferreira’s blog (a "minimalist software craftsman"), I wondered:

"His blog looks sleek and unlike WordPress. What’s it built with?"

The footer read: "Powered by 11ty." Never heard of it...

Curious, I clicked the link and landed on a quirky homepage featuring a bespectacled opossum floating with a balloon! :-)

The page title: "Eleventy is a simpler static site generator."

Key points caught my eye immediately:

Edit pages in Markdown (a developer’s dream!).
Blazing-fast HTML generation.
Total control over the output.
No forced JavaScript framework dependencies.

Wow—this spoke to me! I had to learn more.

First, I researched static sites. In short, they’re sites where pages are generated before deployment, not dynamically per request.

Static sites offer huge advantages in performance, security, maintenance, and SEO!

[TIP]
For a deep dive into static sites, check out this article covering use cases, pros/cons, and how they’re built.

Eleventy seemed perfect: simple, performant, and the right tool for the job—no sledgehammers to swat flies!

But one concern lingered: static blogs can’t natively handle visitor comments. A bummer... until I found an elegant solution (coming in a future article). "Static" doesn’t mean "cut off from the world."

The verdict

WordPress is ideal for non-technical users who want to assemble pre-built bricks into a functional site. It’s almost playful, and quick results are rewarding.

With FSE, WordPress is moving in the right direction—more flexibility, better performance.

But for those comfortable with technical tinkering, static sites (and frameworks like Eleventy) offer more control, precision, performance, and independence from plugin vendors. They also solve niche needs without opening your wallet.

Criterion	WordPress (FSE)	Eleventy (Static)
Ease of use	Very accessible, no-code	Requires technical skills
Customization	Highly flexible via FSE	Total, but manual
Performance	Good (plugin-dependent)	Excellent (pre-built pages)
Security	Plugin-dependent	Very high (no database)
Maintenance	Frequent updates	Local builds, minimal upkeep
Cost	Often paid plugins/themes	Free (excluding hosting)

Personally, since mastering Eleventy, I’m hooked! Unless I have specific needs, WordPress is now off the table.

And you, have you ever thought about replacing WordPress with something else for your blog?