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
    2·
    2 days ago

    The --self-extracting flag in deno compile --self-extracting looks awesome.

    I could compile my 11ty stack into a single executable that I could send anywhere, but it would still be able to read external markdowns so semi-technical coworkers can make content changes without the maintenance overhead of a CMS and without the coworkers needing to learn modern web dev.

    It would also be super awesome for all the internal tools I’ve built that need to run offline.

    • KissakiOPEnglish
      1·
      1 day ago

      11ty = Eleventy? Are you familiar with Hugo? Do you have an opinion or experience between the two systems?

      I’m somewhat dissatisfied with Hugo, which I have used for many years, but whenever I checked alternatives, nothing really spoke to me as a clear improvement worth the learning barrier and migration investment If I can use deno, a js static site generator could be viable too - something I traditionally avoided 🤔

      • spartanatreyu
        2·
        1 day ago

        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:

        • liquid template language, so I only have to write a layout once (header, footer, accessibility landmarks) and every page uses it by default.
        • my own custom extension that adds the build time in a html comment for debugging purposes
        • markdown (so content creator coworkers can create pages)
          • The project is set up in such a way where coworkers can write markdown in vscode, and see a live preview within vscode (using it’s own markdown renderer)

        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.

        • KissakiOPEnglish
          1·
          18 hours ago

          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.

          • spartanatreyu
            1·
            4 hours 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.

  • FizzyOrange
    6·
    3 days ago

    Deno is great. The best way to write web site and static sites IMO. I really hope they survive.