I don't know that I'd agree with all of those statements, but my expertise lies in C#, with a bit of TypeScript/JavaScript/Front-end Web thrown in from time to

I don't know that I'd agree with all of those statements, but my expertise lies in C#, with a bit of TypeScript/JavaScript/Front-end Web thrown in from time to time. I used to write a lot in C++, have dabbled in C... The reason I don't write everything in TypeScript has nothing to do with TypeScript. Language-wise, it is my favorite experience, hands down. I can express things in a type-safe, strict manner, and do things generically that simply cannot be done outside of dynamic languages, while still gaining the benefits of a statically typed language. Not taking node into account[0], TypeScript on its own is my favorite language and it's not the one I write software in every day. While I agree with your arguments around pinning and such, node is a bit of a victim of its own success and suffers from dependency-hell in a way that is truly unique and interesting all on its own. The only way to be certain that code is good is if you write it, barring that ... a trusted, supported third-party for the important things, and inspect the rest. The problem on the node side is the impossibility of the last task, and if you aren't doing it, neither is your trusted third-party. I'm not saying it's hopeless -- I'd even wager a guess there's a comment in my past that is far more harsh on `npm` than it deserved/deserves[1]. I don't think "node-based" solutions for shell are bad. The biggest problem I tend to run into with shell scripts in constrained environments are related to dependencies. With node, `install`, done (usually). I target "what's probably there" like most people. Sometimes it's not. In the past, when this was a bigger problem than it is now for me, I would throw my hands up and build it in whatever I wanted because "if I had to get a waiver to add `jq` or some other thing to this box, I might as well have them put `python` on there" -- same amount of work arguing over BS but less work writing it. I'd probably apply that to `node` these days but those problems aren't mine any longer. :) [0] Which some will point to `npm` as the whole reason they use node while others will point out why it's the entirety of its problems. [1] And I hate the attitude of some that implies `npm`s problems have easy solutions, "if they just ...". No. It's almost everyone's first language. It's really easy to publish packages. There's a gajillion of them out there. (Yet, it works ... every? ... time I need to solve something using it.)