← Back to context

Comment by user43928

17 hours ago

What did it get you?

For my projects, I am used to maintaining package manager configuration, bundlers, linters etc.

So I never had much interest in looking into benefits of Deno or bun.

As a former bun user, speed.

However I now work with software that requires PQC resistance and node's native ML-KEM and ML-DSA abilities made me switch back. Also I'm not particularly an Anthropic fan so that was also a separate nail in its coffin for me.

  • Now I'm fascinated why you've chosen the node/npm ecosystem for something with such high security requirements. Are you doing anything special to deeply pin dependencies, etc.?

    Finding the right balance of "being responsive to bugfixes, some of which may patch disclosed zero-days" and "not allowing a compromised package to be installed" is tough, these days.

    • npm has supported min-release-age since Februrary, both that and pinned dependencies are stuff I think everyone should be doing. wrt sensitive environments, I can't say too much about our internal processes but we have an audited private registry among other things. for containers, Iron Bank provides a free and publicly accessible baseline https://p1.dso.mil/iron-bank to build on top of.

      1 reply →

As a non-js developer, Bun compiles my ts code to local executables nicely. Allows me to experiment with the new diversity of ts frameworks and distribute the binaries (hobby scope).

  • I'm using Vercel PKG to compile my JS code to executables "nicely".

    But PKG is not supported by anyone any more (?) and it has an upper limit on the version of Node.js base-image it will support.

    If Bun supports compiling executables nicely I hope that feature somehow stays alive and is migrated to other runtimes. Or maybe it can become a standalone tool for exe-compiling?

I mean I used to do a lot of things I'm glad I don't have to anymore. I'm not a big fan of doing repetitive work just because I understand how to.

Node at least picked up --run, TS stripping support, .env loading, watch mode, and sqlite (plus some other things I'm probably forgetting) since Deno started so at least theres that.

  • I also don't like repetitive work, but I think it can be beneficial to understand how the tools you use work, and bun/Deno seem to abstract much of it away.

    Random example: I've worked with many frontend developers who seemed to believe listing dependencies in package.json in devDependencies instead of 'dependencies' controls what ends up in the production bundle.

    I'm under the impression few understand that this is only a cosmetic distinction unless you use the package manager's --omit=dev or --production flags during install.

    What is included in the production bundle is of course determined by the bundler's dependency-graph reachability from the entry point.

    For people who never configured these tools themselves, it's probably difficult to understand how the modern web stack works.

    However, nowadays you can probably have AI explain it to you well enough while it fixes the issues.

    • Silly drive by take:

      > I've worked with many frontend developers who seemed to believe listing dependencies in package.json in devDependencies instead of 'dependencies' controls what ends up in the production bundle.

      If so many believe that it’s how it should work, maybe it just should work that way. Principle of least surprise and all that.

      5 replies →

    • On most projects you really only need one person to set it up one time with any deep level of understanding. Having each person on a project go deep into the weeds on how the package manager works is not very useful. That time would be better spend on almost anything else.

    • One should understand how their tools work but there's no such thing as doing that without understanding things across the abstractions involved and at least a good portion of what happens under them, Deno or not.

      It works the same way you use a bundler instead of assembling your own and so on and so forth down the tree. The farther down the tree, the less focus you should give your understanding to, but that's not an excuse for giving no understanding below the first layer.

      1 reply →