although I’m a little bit skeptical about having to integrate additional extensions and workflows
Just to allay your fears, it's not a mishmash of random extensions and brittle workflows.
11ty was originally built in a more all-in-one box style, but it was kind of annoying to have 10+ templating languages to choose from (and all the dependencies that came along with them), when you only wanted one.
Every update, the author does two things:
- Splits more functionality into first party plugins
- Removes, or forks and takes over third party dependencies.
You can see that here: (data taken from here: https://www.11ty.dev/blog/dependency-watch/#full-history)
| Version | Deps (3rd-party) | Change | node_modules Size | Change |
|---|---|---|---|---|
| v0.2.0 (2018 January) First npm release! | ×401 (400) | n/a | 51 MiB | - |
| v0.12.1 (2021 March) | ×362 (360) | -9.70% | 68 MiB | +33.30% |
| v1.0.2 (2022 August) | ×360 (357) | -0.50% | 71 MiB | +4.40% |
| v2.0.1 (2023 March) | ×213 (208) | -40.80% | 35 MiB | -50.70% |
| v3.0.0 (2024 October) | ×187 (174) | -12.20% | 27 MiB | -22.80% |
| v3.1.2 (2025 June) | ×134 (123) | -28.30% | 21 MiB | -22.20% |
| v4.0.0-alpha.1 (2025 July) | ×130 (116) | -2.90% | 16 MiB | -23.80% |
| v4.0.0-alpha.6 (2025 December) | ×105 (89) | -19.20% | 14 MiB | -12.50% |
The first-party plugins are all compatible with each other and all use the same 11ty config with the same sensible defaults, and 11ty is built with all of the first-party plugins in mind.
You can add them all in if you still want the all-in-one-box approach, but this way lets your environments be smaller.
It's basically pre-computed tree shaking.
There's also a security argument for it. By splitting everything apart, you isolate security issues. If one of the random 10+ templating languages got a security issue (e.g. supply-chain attack, redos, misglobbing, etc...), it will only affect the projects that decided to use that templating language.