Why 11ty: Six Years Static — and Why I'm Staying for Build Awesome Too

On 5 June 2020 I typed git init in an empty directory. Two days later the first package.json was in place, and it contained exactly one line that decided everything that followed:

"devDependencies": {
  "@11ty/eleventy": "^0.11.0"
}

That line is six years old now. The repository behind it has 683 commits, the most recent one dated 21 August 2026, and it still builds www.jpkc.com. No rewrite, no framework switch, no migration. In an ecosystem where build tools rotate faster than I descale my coffee machine, that is the actual headline.

I am writing this article for two reasons. First, because people keep asking why someone who has been building websites for over 25 years would settle on a static site generator — and on this one in particular. Second, because something is changing around 11ty right now: the project is becoming Build Awesome. That has caused a fair amount of debate in the community, and I think an article that celebrates 11ty has to deal with that honestly rather than leave it out.

Up front: I am a fan. You will notice that in this text, and that is intentional. But being a fan does not mean glossing over the weak spots — and one of them is serious enough to get its own section here.

How I got here: HTML, my own CMS, WordPress

My first sites were plain HTML and CSS. By hand, file by file, with all the charm and all the tedium that entails. At some point copying the same header and footer around got too silly, and I did what developers do in that situation: I wrote my own CMS. JPKCMS, in PHP. It worked, it taught me an enormous amount, and it had exactly the drawback every home-grown CMS has — I was the only person on earth who could maintain it.

WordPress came next, for the obvious reasons: finished, extensible, documented, a huge community. Along the way I kept evaluating alternatives — Drupal, Contao, Backdrop CMS, Hugo as well. All of them locally only, none of them ever went live. Those were honest tests, not theatre: I wanted to know whether something out there fit better.

What eventually pushed me away from WordPress was not one single trigger but four, all pointing in the same direction.

The maintenance load. My site changes in terms of weeks, not hours. Yet it kept me busy at a cadence that would have suited a newsroom publishing daily: core updates, plugin updates, theme updates, and then checking every single time whether everything still stood. The ratio of upkeep to content no longer made sense.

Control over the markup. I care about semantic HTML and about accessibility that deserves the name. In a theme system you are constantly counteracting: a plugin brings its own markup, a widget sets heading levels however it likes, a builder nests <div>s around content that is really a list. I no longer wanted to correct what a system decided for me. I wanted to decide.

Performance. A site that boots PHP, queries a database, renders a theme and loads half a dozen plugins on every request stands no chance against a finished HTML file — not on Time to First Byte, not on LCP, not on stability under load. I optimised, cached and pruned plugins for a long time. In the end I accepted the obvious: the fastest way to serve HTML is to serve HTML.

Security. Every WordPress installation is a permanently running, publicly reachable PHP program with a database and an admin area. That is not a criticism of WordPress, it is simply the shape of the thing. And that shape means attack surface, at all times, for anyone looking for it — and plenty of people are looking, automatically, around the clock.

In June 2020 I made the cut. Eleventy 0.11.0 was four weeks old at the time.

What 11ty actually is

Eleventy is a static site generator written in JavaScript. You hand it a directory of templates, Markdown files and data, and it produces finished HTML. That is the core of it — and that restraint is the point.

What sets 11ty apart from most alternatives is stated on its own home page, and it is the reason I stayed:

"Eleventy offers full control over your project's output. We don't inject our own markup into your pages."

That is not a marketing slogan but a verifiable property. Whatever is in your template ends up in the HTML. No wrapper <div>, no generated class names, no runtime, no hydration bundle. Elsewhere the home page puts it even more plainly: "zero client-side JavaScript by default across the board". Every byte of JavaScript that reaches my visitors was put there by me, and I can take it out again myself.

On top of that come three properties that matter more day to day than they sound. 11ty is zero-config, so it works without a config file, yet it can be configured deeply when you need it to be. It works with your directory structure instead of prescribing an app/ or pages/. And it allows incremental adoption — you can convert individual templates and leave the rest alone. That is precisely what made the switch palatable to me in 2020.

Not a minor detail, because it has become rare: 11ty collects no telemetry. "We don't have or use telemetry nor require you to opt-out of data collection," says the home page. A build tool that does not phone home ought to be the norm. It is not.

A short history: from Omaha to half the world

11ty comes from Zach Leatherman (opens in a new tab), a web developer in Omaha, Nebraska. The idea was decidedly unglamorous: he liked Jekyll, but Jekyll is written in Ruby — he wanted the same thing in JavaScript. The first version, 0.1.0, appeared in December 2017. The name comes from a family story: his grandmother recounted how, as a child, he mispronounced the number eleven. "Eleventy." Hence the 11ty shorthand and the circus of clock, lightning, balloon and possum emoji the project still carries on its crest.

The version history, straight from the npm registry:

Version	Released	Significance
0.1.0	December 2017	first version
0.11.0	2020-05-10	the version I started with
1.0.0	2022-01-08	first stable major release
2.0.0	2023-02-08
3.0.0	2024-10-01	move to ESM
3.1.0	2025-05-13	"11% faster and 22% smaller"
3.1.6	2026-06-02	current stable
4.0.0-alpha.10	2026-07-01	canary

Along the way, in 2022, came a Google Open Source Peer Bonus Award (opens in a new tab). Zach Leatherman himself has worked at Filament Group, Netlify and CloudCannon over the years, helped run NEJS CONF and NebraskaJS, and by his own count has given 89 talks in nine countries — including at The White House. Today he is a "builder for the web at Font Awesome".

Which brings us to the part that needs explaining.

Build Awesome: what actually happened

On 12 September 2024, Font Awesome announced (opens in a new tab) that Eleventy and its creator were joining the company. "Eleventy and its creator, Zach Leatherman, are joining Font Awesome!" A project that had long run on the side became a paid, full-time job.

On 3 March 2026 came the next step: "Eleventy is now Build Awesome" (opens in a new tab). The project moves under Font Awesome's "Awesome" banner, the way Shoelace became Web Awesome before it. The key statements: "Eleventy v4 will be Build Awesome v4" and "Build Awesome Pro will not be required to use Build Awesome (Eleventy)." The open source core stays MIT-licensed and free; "Pro" is a separate, commercial website builder layered on top.

A Kickstarter ran alongside it. Inaccurate accounts of that campaign are still circulating, so here is the documented timeline:

Date	What happened
2026-03-03	rebrand announced, Kickstarter launches
~2026-03-04	funding goal reached within a day
2026-03-06	campaign is paused
2026-04-28	campaign relaunches
2026-05-13	additional sponsorship tiers
2026-05-29	closes at 313% funded

The reason for the pause was mundane and painful at once. Font Awesome wrote (opens in a new tab): "Most of our announcements never landed. We won't get into details, but let's just say Gmail had other ideas. Our launch emails reached maybe 5-10% of the people they were supposed to." Kickstarter campaigns live off their first 48 hours — and those fizzled because the announcement emails went to spam. So: cancel, fix the email infrastructure, start again. The relaunch worked, and the campaign closed well above target.

None of that derailed the rename, contrary to what is occasionally claimed. Verifiable: the GitHub repository now lives at 11ty/buildawesome (opens in a new tab), and since 16 June 2026 there is an npm package @awesome.me/buildawesome — MIT-licensed, with 4.0.0-alpha.10 on its alpha channel. @11ty/eleventy continues to work unchanged alongside it.

The criticism — and why it does not change my mind

Some of the reactions were fierce. The most widely discussed post, "The End of Eleventy" (opens in a new tab) from 4 March 2026, argues that a visual website builder misses the actual audience: anyone who cares about building static sites would rather use a local development environment and a terminal than any click-together interface. And that the rebrand feels "corporate, pro-capitalist", turning one of the last remaining craft hobbies into a commodity. Others simply objected that the announcement barely mentioned the name Eleventy — a communication failure Font Awesome concedes in the pause post itself: "One thing we want to be clearer about in the relaunch…"

I understand the unease. A project that felt like yours for years suddenly gets a product name — that feels like a move somebody else decided on your behalf. And anyone who has watched open source slowly dry out after an acquisition has every reason to be suspicious.

I am relaxed about it anyway, for three reasons.

First: the commitment is explicit and unambiguous. "Build Awesome (née Eleventy) will always be free and open source. Always." That is in an official post, not a forum comment.

Second: the licence is MIT, and that holds for the new package name too. MIT cannot be retroactively withdrawn from code that has already shipped. If things ever did go wrong, a fork is not a threat but a tool that stays within reach.

Third, and this weighs most heavily for me: I have seen the alternative. An open source project that exists purely in one person's spare time is not a success model — it is a risk with a pleasant surface. When that person loses interest, gets ill, or life intervenes, your foundation stops moving. Funding that pays for full-time work on an MIT-licensed core beats romantic volunteer burnout in my book. The fact that I like "Build Awesome" less than "Eleventy" changes none of that. Names are taste. Maintenance is substance.

What I actually watch rather than merely believe: whether the open source core keeps shipping releases, whether the documentation stays maintained, and whether Pro features take anything away from the free core. The evidence so far says no, and it is evidence from after the rebrand: the free @11ty/eleventy received 3.1.6 on 2 June 2026, and the version 4 alphas landed on 18 June and 1 July. The project is shipping in precisely the months its critics feared a sell-out.

Why 11ty is the right choice for my projects

Now to the substance. Six reasons I have never regretted this decision.

Security: what does not run cannot be attacked

My site consists of HTML, CSS and a little JavaScript. No code runs on the server at request time. No PHP runtime, no database, no admin area, no session, no login form, no writable upload directory. The classic attack paths of a dynamic site — SQL injection, remote code execution, compromised plugins, guessed admin passwords — hit nothing, because there is nothing for them to hit.

That is not a hardening trick but a property of the architecture, which is why it holds even when I do not look at the site for a month. No security update to install on a Friday evening because a hole turned up in some extension that has been quietly running along for years.

The honest flip side: Node.js and npm

And now the part a fan article likes to leave out — I will not, because it matters.

The attack surface does not disappear. It moves. Away from request time, towards build time. The second I run npm ci, my machine pulls in dozens to hundreds of foreign packages and, by default, is allowed to execute arbitrary code from them via install hooks, before I have used any of it. That is the vector event-stream, ua-parser-js and the whole run of npm incidents relied on.

Anyone claiming a static site is "automatically secure" has missed that shift. The dangerous moment is not the page view, it is the build.

This is manageable, and I have written up my complete counter-setup in a separate article: Working Securely with Node.js and npm. The short version, exactly as it runs in all of my projects — including the one that builds this site:

Socket Firewall (sfw) in front of every npm call. Known malicious packages are blocked before they hit the disk — and therefore before an install hook could ever start.
ignore-scripts=true in .npmrc. Install hooks never run.
save-exact=true and exactly pinned versions, no ^ or ~. No build silently pulls a new version.
npm ci instead of npm install as the default. Reproducible from the lockfile.
"private": true in package.json, all dependencies as devDependencies.

Encouragingly, the 11ty project leads by example here. In December 2025 Zach Leatherman described (opens in a new tab) how the entire @11ty/* ecosystem moved to Trusted Publishers: "we are now npm Access Token-free!" That removes the long-lived access tokens somebody could steal — the classic route into a hijacked maintainer account. The reasoning is stated openly: "As we harden our release practices in the wake of numerous recent vulnerabilities in npm packages amongst high profile authors…"

Alongside that comes a consistent dependency diet. In 2025 the project cut the core's dependency count by 28% and its weight by 22%, from 187 to 134 packages and from 27 MB to 21 MB. The current 3.1.6 has 33 direct dependencies. In the version 4 alphas the curve keeps heading down. Every dependency that is not there cannot be compromised — the only supply chain measure with a hundred per cent success rate.

Accessibility: control is half the battle

Accessibility is not a downstream checkpoint in my work but part of how I build — and since the BFSG came into force it is a legal matter for many, too. This is where "we don't inject our own markup into your pages" pays off every single day.

If a landmark is wrong, that was my decision, and I can fix it in one line. If the heading hierarchy jumps, that is my template, not a plugin. If a focus style is invisible, no foreign stylesheet removed it. During my WordPress years I spent more time repairing other people's markup than writing my own — and with accessibility, repair is always a worse starting position than construction. How I build the structure in practice is in HTML Landmarks in Practice.

There is a good witness for this outside my own projects. Eric Bailey — the A11Y Project (opens in a new tab) runs on 11ty — put it like this:

"a11yproject.com launched with version 1.0.0 of Eleventy. […] It's been a little under three years and I haven't had to make any adjustments to its dependencies, and it can still install and run from a cold start with no complications."

That the web's best-known accessibility project builds with this generator strikes me as no coincidence at all.

Performance: an unbeatable starting position

With Core Web Vitals you win most of your points before you optimise anything — through architecture. A static HTML file served by Apache has no database query, no template rendering at request time, no PHP startup. Time to First Byte is a question of filesystem and network, nothing else. And because no framework JavaScript ships by default, there is no hydration step dragging INP down and no late-arriving components wrecking CLS.

That does not mean performance is free. Images, fonts and my own scripts still need managing, and that is exactly what Core Web Vitals & Performance is about. The difference is the starting position: I optimise upwards from a very good number instead of papering over a bad one with layers of caching.

On the build side I owe you an honest number, because this is where articles like this tend to fudge. A full production build of this knowledge base currently produces 1,936 files — 963 HTML pages, plus 962 Markdown mirrors (the 404 page has none) as well as feeds, sitemap and llms.txt. Depending on load it takes just under three to three and a half minutes on my machine — two runs while writing this article needed 176 and 209 seconds. That wins no prizes, and I am writing it down anyway, because "blazing fast" in pieces like this too often means "never measured".

What is more interesting is where the time goes — and 11ty tells you unprompted. Its built-in benchmark attributes the single largest item to my own configuration: around 35 seconds, roughly 19% of the total, for a transform that gives every external link target="_blank", rel="noopener", a marker class and a hidden "opens in a new tab" hint. That is my decision, not the generator's. And that is exactly what I value: I can see in black and white what costs me what, and weigh up at any time whether a feature is worth its seconds. Should it ever get tight, 11ty also ships incremental builds — I simply have not needed them here yet.

SEO and GEO: being crawlable is half the win

For search engines, a pre-rendered page is the friendliest case there is. The complete content sits in the HTML that ships — no rendering budget, no JavaScript execution, no two-wave indexing where the actual text arrives on the second pass. Structured data, canonicals, hreflang, sitemap: all generated at build time, consistent everywhere, without a plugin getting in another plugin's way. The technical groundwork for that is in Technical SEO: The Foundation.

With GEO, optimising for generative AI systems, the advantage grows further, and that is why this site exists at all. Because I have full control over the build, I can produce additional output formats no CMS plugin would have thought to offer. Every page here therefore also exists as plain Markdown: /db/en/blog/warum-11ty/ is also available at /db/en/blog/warum-11ty.md, carrying the unaltered original Markdown rather than an HTML back-translation. On top of that, an llms.txt indexes all content, and a <link rel="alternate" type="text/markdown"> in the <head> lets systems discover the noise-free format at all.

With 11ty that is a manageable amount of work: a pagination template, a filter, done. In a system that takes the markup out of my hands it would be either a plugin project or impossible. What it means editorially is covered in GEO: Visibility in AI Answers and Writing for AI.

Cost and effort: the argument nobody makes

The cost advantage of a static site is usually argued via hosting. That holds too — finished files need no PHP processes, no database server, no scaling under load, and they can be served from practically any web space. But the bigger item is a different one, and it appears on no invoice: my time.

No monthly update window. No chasing plugins that stopped working after a core update. No call at night because a hole is being actively exploited. No backup strategy for a database — the repository is the backup, and the build is reproducible at any time. Add up the hours a well-kept CMS installation costs over six years and you have the real figure. For me, over these six years, it has trended towards zero.

Stability: the underrated feature

For me the strongest point, and the one I only learned to value properly over the years. The project itself puts it best:

"Eleventy is stable. We've shipped 226 releases going back to the first version in December 2017 and only three of those releases have had Eleventy-specific changes requiring developer changes."

226 releases, three of them requiring changes. I checked that against my own repository, and the result is pleasingly boring:

2022-04-12, the jump to 1.0.0 — the version commit sits in the history between favicon and logo changes from the same day. No aftermath.
2023-02-28, the jump to 2.0.0 — the version commit and a node_modules update, both on the same day. The commits over the following days concern accessibility, not the migration.
2024-10-22, the jump to 3.0.0 — the ESM switch, the biggest break in the project's history. On my side: three commits, all on a single day.

In six years there was never a point where my choice was between rewriting everything and sitting on a dead version. Anyone who has spent the last few years in the JavaScript ecosystem knows how unusual that is.

Flexibility and extensibility

11ty ships with HTML, Markdown, JavaScript, Liquid, Nunjucks, Handlebars, Mustache and EJS out of the box; plugins add WebC, Haml, Pug, TypeScript, JSX, MDX and Sass. What matters is not the length of the list but this sentence from the documentation:

"Eleventy's super power is that it is built on an extensible architecture that can work with one or more template languages in the same project."

You do not have to choose. In this project I write content in Markdown, layouts in Nunjucks, the generators for the Markdown mirrors in Nunjucks as well, and the build logic in plain JavaScript. All in the same project, with no bridge between them.

Then there is the stance on formats, which I consider underrated: "We don't want to hold your content hostage with a custom format." My content is Markdown files with YAML front matter. If I wanted to leave 11ty tomorrow, I would take the directory and be done. That is not theoretical freedom — it is the reason I dared to switch in 2020 at all.

Extension happens in JavaScript, not in a template language with logic bolted on. A custom filter is a function:

// config/filters.js — the actual filter from this project
eleventyConfig.addFilter("mdUrl", function (url) {
  if (!url) return url;
  const trimmed = url.endsWith("/") ? url.slice(0, -1) : url;
  return (trimmed === "" ? "/index" : trimmed) + ".md";
});

That is exactly how the Markdown mirrors, the tag search and the bilingual navigation come about here. None of it is a plugin somebody planned for me — it is five lines of JavaScript in a file I fully understand.

pathPrefix is a nice example of how far that configurability reaches. This knowledge base does not live on its own domain but in a subfolder at https://www.jpkc.com/db/. That takes exactly one line:

// eleventy.config.js — shortened
return {
  pathPrefix: "/db/",
  dir: { input: "src", output: "_site", includes: "_includes", data: "_data" },
};

The built-in HTML base plugin then rewrites all internal links and assets in the output automatically. In my templates I keep writing /assets/css/main.css, and what ships is /db/assets/css/main.css. A subfolder deployment that is an afternoon of surprises in other systems is one config line here.

Platform independence: the Node bonus

11ty runs anywhere Node.js runs — officially from version 18 onwards. That is practically every system worth developing on: Linux, macOS, Windows, WSL, a container, a CI runner, a Raspberry Pi.

For me that is not an abstract argument. I develop under WSL2 on Windows, this blog additionally builds on a GitHub Actions runner under Linux, and it ships to an Apache web space. Very different environments, and the build behaves identically in all of them, because it requires nothing beyond Node and the lockfile. No compiler toolchain adventure, no platform-specific binaries missing on the CI runner — apart from a handful of native packages like sharp or pagefind, which ship their binaries cleanly via optionalDependencies.

The comparison with Hugo is honestly a draw here: a single Go binary is even less demanding at deployment time. The difference is what you hold in your hands when extending it. With Hugo you write Go templates. With 11ty you write JavaScript — the same language I think in anyway, with an ecosystem that already has a library for every job. That, together with the freedom in template languages, is what tipped it for me.

Automated deployment

A build that falls reproducibly out of a repository can be automated — and that is the second big win after security.

Both variants run side by side in my setup, and I find the contrast instructive. www.jpkc.com I still transfer manually: build, upload _site/, done. That sounds old-fashioned, but for a site that changes rarely it is entirely sufficient — and it has one merit I do not underrate: between my commit and the live site stands a deliberate decision.

This knowledge base, by contrast, is built and shipped through a GitHub Actions workflow. With 1,936 files generated per run and several changes a week, I no longer want to do that by hand — and a runner is welcome to spend those three minutes instead of me. What such a workflow does is always the same pattern:

Check out the repository.
Provide Node in the pinned version.
npm ci — reproducible from the lockfile, not npm install.
Run the build, including CSS, the JS bundle and the search index.
Transfer the result to the target.

The point I care about here: CI is also a machine on which foreign packages get installed. Everything I do locally in terms of hardening belongs in the workflow just the same — npm ci, pinned versions, no install hooks. A deploy workflow that pulls unchecked from the registry is not progress, just a faster route to the same problem. How I set up workflows of this kind is described, using a WordPress plugin as the example, in Shipping and Auto-Updating Your Own WordPress Plugins with GitHub Actions.

Where 11ty is not the answer

A fan who names no limits makes a poor advisor. There are three cases where I would steer you elsewhere.

Editorial teams without a terminal. 11ty assumes Git, a command line and an editor. For colleagues who want to write a post and click "Publish", that is the wrong shape. Git-based editing interfaces exist, and Build Awesome Pro aims squarely at this gap — but by default 11ty is a tool for people who work with files. If your team does not want that, take a CMS and be happy with it.

Genuinely dynamic features. A login area, a shopping cart, personalised content, a forum: all of that needs code at request time. It can be built around a static site, via external services or a separate backend, but then the complexity lives there instead. If the dynamic part is the heart of your project, you end up building two systems instead of one.

Very large page counts. At tens of thousands of pages, build duration becomes a topic. 11ty has incremental builds and a cache for that, and at my scale I notice none of it — but in six-figure territory that deserves an honest test before you commit.

And the fourth point, which I covered above: the Node dependency brings the npm attack surface along at build time. Manageable, but not to be argued away.

Conclusion

Six years, one generator, two websites, no rewrite. If I had to boil the value of 11ty down to a single sentence, it would be this: it takes off my hands the work I do not want to do, and leaves me in control of everything I care about.

Turning templates and Markdown into HTML is its job. Semantics, accessibility, the performance budget, structure, output formats — that stays with me. That division is exactly what separates it from a CMS that takes work off your hands by making decisions you would rather have made yourself.

Whether the tool is called Eleventy or Build Awesome a year from now is, honestly, all the same to me. What counts is the MIT licence, a core that keeps being maintained, and content in a format I can take with me at any time. Those three things hold, and they hold better today than in the years when the project depended on one person's spare time.

If you are facing the same question I faced in 2020: it takes an afternoon to try. A directory, a Markdown file, npx @11ty/eleventy --serve. That is all it takes to see whether it fits you.