← Back to context

Comment by yearesadpeople

12 hours ago

I've read OP blog and writings for a time. The one takeaway - for me - is how negative/defensive the writing is. And, I'm not sure why it has to be that way.

---

Node kept doing its thing when Bun, Deno, etc. was all the rage. And I do respect Node team for trying to improve little by little. It's not an ideal runtime but, it is _trying_... and that's a positive story.

This was the point the author lost credibility, IMO:

> This restriction is philosophical rather than technical. I get it though. TypeScript is a Microsoft product. Opening that floodgate would pollute the entire ecosystem. Nobody wants more Microsoft.

I've done a small amount of work with Node (with JavaScript), and many libraries appear to have TypeScript bindings. It "felt" like there was pressure on me to move to TypeScript. (And, my conclusion at the end of my work with Node was that the next time I do anything significant with it, I would start with TypeScript first.)

  • This confused me for a minute too, I believe the distinction is whether bindings (.d.ts) are allowed in packages, or the library source itself is in TypeScript (.ts). I agree that NPM should enforce library source uses .js files with .d.ts sidecars.

I think Bun is still all the rage in some areas. For us the fact that it makes it easy to work with compliance, means it's often what we pick in place of Node when we work with typescript. Being able to build an API without using anything but the Bun runtime, the Microsoft Azure and our own internal Node packages makes the NIS2 compliance much less of a burden than if we'd work with Node.

That being said. I don't think anyone in my team considers us a "Bun" team in regards to Typescript, all our internal packages are Node packages as an example.

I don't personally have an opinion on it being owned by Anthropic. It was part of our risk assessment, but it obviously passed.

  • If compliance is the main deciding factor, wouldn't Deno be a major selling point since its inherently NIS2 compliant out of the box? Security is its primary foundational selling point

    Bun has the same permissive trust model as Node

  • curious: given the pace of bun development, lack of LTS/support on older point releases etc, how does it qualify this compliance check assuming I believe you're alluding to fewer deps as the reason for "less burden"?