| ▲ | kuekacang 8 hours ago |
| I went all-in with bun. Did I bet wrong? |
|
| ▲ | user43928 8 hours ago | parent | next [-] |
| 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. |
| |
| ▲ | nateb2022 8 hours ago | parent | next [-] | | 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. | | |
| ▲ | btown 4 hours ago | parent [-] | | 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. | | |
| ▲ | nateb2022 4 hours ago | parent [-] | | 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. |
|
| |
| ▲ | threecheese 7 hours ago | parent | prev | next [-] | | 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). | | |
| ▲ | galaxyLogic 3 hours ago | parent [-] | | 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? |
| |
| ▲ | zamadatix 8 hours ago | parent | prev [-] | | 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. | | |
| ▲ | user43928 7 hours ago | parent [-] | | 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. | | |
| ▲ | KronisLV 6 hours ago | parent | next [-] | | 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. | | |
| ▲ | 8n4vidtmkvmk 5 hours ago | parent [-] | | You can and probably should set up your production builds that way but it's not automatic. It also gets messy if you're building 2 or 3 services simultaneously out of the same node_modules dir. E.g frontend, backend, shared, scripts... | | |
| ▲ | user43928 5 hours ago | parent [-] | | How would you set that up? Like say you installed only the production dependencies, then you'd be missing the build tools, bundler, etc. One idea would be to use hooks of your bundler to enforce that each module resolved during the production build is declared in the regular dependencies. It would be far from a standard solution though. | | |
| ▲ | andrewaylett 13 minutes ago | parent | next [-] | | https://github.com/import-js/eslint-plugin-import/blob/HEAD/... It's not built in to ESLint, but it's fairly widely used in my experience and helps ensure that you've got a sensible split between production and non-production. | |
| ▲ | mikeryan 2 hours ago | parent | prev [-] | | NX Monorepos work that way. Broadly speaking (and with many exceptions) all packages end up in the root. It “builds” release distributions with the correct package.json files and transpiled js. It helps keep all your related packages on the same dependencies. It’s hell for react native sometimes though. | | |
| ▲ | user43928 an hour ago | parent [-] | | I don't see what you mean. With nx you define the dependencies between your tasks, so that the packages build in the right order and with caching. I do not think it changes anything about how packages are installed by the package manager or bundled by the bundler. You can declare build tools in either the root package.json or packages/a/package.json, and I don't think anything prevents you from bundling something declared in devDependencies. On second thought, I see now that you probably mean it helps keep shared dependencies at the same version when you declare them in the root package.json. That's a feature of npm/pnpm/yarn workspaces though, not nx itself. And it only works with bundled dependencies, since they would be undeclared in the package itself and thus couldn't be installed externally. If you need that, I think pnpm catalogs would be the right tool. |
|
|
|
| |
| ▲ | zamadatix 6 hours ago | parent | prev [-] | | 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. |
|
|
|
|
| ▲ | behnamoh 8 hours ago | parent | prev | next [-] |
| Yup, Bun is at the mercy of Anthropic, and we know the extents they go to protect their competitive advantage. |
| |
| ▲ | simonw 8 hours ago | parent | next [-] | | "we know the extents they go to protect their competitive advantage" I don't. What do you mean? | |
| ▲ | buremba 8 hours ago | parent | prev [-] | | Use bun when it's drop in replacement of npm, never use Bun API itself. |
|
|
| ▲ | Buttons840 7 hours ago | parent | prev [-] |
| Bun always seemed weird because they decided to build it with Zig. I want Zig to succeed, but it's not stable yet. It reminds me of game engines. If you want to make a game engine, there's nothing wrong with that, but you should acknowledge that you're building a game engine, not a game--or rather, if your goal is to make a game, starting by making a game engine probably isn't optimal. It's the same for Bun. It's clear that they wanted to build a JavaScript runtime, and also they wanted to use Zig. They are doing both of these things, but when push comes to shove, their desire to use Zig was more important than their desire to make a JavaScript runtime, I believe. |
| |
