About Deno:
Deno is an open-source JavaScript runtime for the modern web. Built on web standards with zero-config TypeScript, unmatched security, and a complete built-in toolchain.
About Deno:
Deno is an open-source JavaScript runtime for the modern web. Built on web standards with zero-config TypeScript, unmatched security, and a complete built-in toolchain.
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.