Deno 2.7 stabilizes the Temporal API, adds Windows on ARM builds, npm overrides in package.json, brotli compression streams, self-extracting compiled binaries, deno create, and dozens of Node.js compatibility improvements.

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.

  • spartanatreyu@programming.dev
    0·
    15 days ago

    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:

    1. Splits more functionality into first party plugins
    2. 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.