this post was submitted on 28 Feb 2026
17 points (100.0% liked)
Web Development
5513 readers
15 users here now
Welcome to the web development community! This is a place to post, discuss, get help about, etc. anything related to web development
What is web development?
Web development is the process of creating websites or web applications
Rules/Guidelines
- Follow the programming.dev site rules
- Keep content related to web development
- If what you're posting relates to one of the related communities, crosspost it into there to help them grow
- If youre posting an article older than two years put the year it was made in brackets after the title
Related Communities
- !html@programming.dev
- !css@programming.dev
- !uiux@programming.dev
- !a11y@programming.dev
- !react@programming.dev
- !vuejs@programming.dev
- !webassembly@programming.dev
- !javascript@programming.dev
- !typescript@programming.dev
- !nodejs@programming.dev
- !astro@programming.dev
- !angular@programming.dev
- !tauri@programming.dev
- !sveltejs@programming.dev
- !pwa@programming.dev
Wormhole
Some webdev blogs
Not sure what to post in here? Want some web development related things to read?
Heres a couple blogs that have web development related content
- https://frontendfoc.us/ - [RSS]
- https://wesbos.com/blog
- https://davidwalsh.name/ - [RSS]
- https://www.nngroup.com/articles/
- https://sia.codes/posts/ - [RSS]
- https://www.smashingmagazine.com/ - [RSS]
- https://www.bennadel.com/ - [RSS]
- https://web.dev/ - [RSS]
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I haven't used Hugo.
I went with 11ty a few years ago because I wanted to stay as close to the actual web standards as possible (so, HTML/CSS/JS).
The main reason why is that every additional abstraction layer and every invocation of "magic", is just extra hidden complexity which makes things harder to debug, extend, and maintain.
Having a SSG in go/python/rust would have been an extra layer.
The "maintain" point above is something most others don't think about until it comes back to bite them. Nothing is more frustrating than reopening a project that worked fine a few years ago, and even though you haven't changed anything, nothing works, and when trying to update it you end up with Frankenstein's monster.
11ty went out of it's way to remain as simple as possible. Here's your input directory, and here's your output directory. That makes the maintenance and backwards compatibility really easy.
Then you can add the minimum required complexity/abstraction layers only when you need them.
In my case, I use:
I'll say the one thing I don't like about 11ty is that it's written in js, not ts. The author is all about simplicity and reducing layers of complexity. But now typescript has a typescript-lite version with the erasableSyntaxOnly flag, which basically allows it to run on node (deno and bun already ran typescript), so the next version (or one after), may be migrated to typescript.
I totally get the focus on avoiding "layers", it's something I'm very mindful of too.
Thank you for the insight, I'll have a closer look into it, although I'm a little bit skeptical about having to integrate additional extensions and workflows, which is it's own bag of worms for maintainability, longevity, and complexity in general.
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:
You can see that here: (data taken from here: https://www.11ty.dev/blog/dependency-watch/#full-history)
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.