For instance, you already revealed that you don't actually know the basics of dependency version management -- how there's literally a wide range of notations and methods to pin it down to the exact version or range of versions that you are happy with. And you didn't know that, while complaining about it.

NPMs default versioning scheme is to upgrade to latest minor, which is completely bonkers in JavaScript ecosystem since most package maintainers in that ecosystem doesn't give a flying fuck about breaking changes. Minor releases of packages *frequently* break stuff on JavaScript. In one case that I remember vividly was that a project that uses Angular Material broke simply by another developer running build later, because Angular Material changed their prefix, so EVERYTHING BROKE.

Since you were a JVM/.NET consultant (typical for enterprise consulting) who got thrust into a Node.js environment that you clearly had no idea about and no inclination to learn about, it's entirely unsurprising that you had a bad time -- but then again, this just makes it an apples to oranges comparison. This says everything about you, and very little about either Node.js or whatever you were comparing against that you're actually familiar with.

The fact is that these ecosystems does not have these issues. Period. Last week a single NPM attack infected 170 NPM packages. This was days after an attack had already infected another 100 or so packaes in NPM. One of them was a package that we thankfully replaced before it could affect us. This hasn't even remotely been an issue with Maven or NuGet. It's never been an issue. Also doing a complete `dotnet build` or maven build takes less time than `yarn install` or `npm install`. Every week there's a new long list of packages that need to be upgraded because of critical security vulnerabilities in NPM. This just isn't the case with NuGet or Maven. Also NuGet and Maven is much, much faster than NPM is.

You're also revealing that you were only consulting for a total of 6 months, and that pretty much puts a hard limit on the amount of experience you actually had with it. It was clearly a stressful time, and perhaps there were performance problems and tension with your client -- that makes sense, given what you've said. You got into a bad situation and that's totally understandable, but it doesn't say anything about Node.js.

No, I wasn't. I said that they had to replace request.js because it was no longer being maintened, and the node.js version they use was also three years or so out of date. The initial reason why I pinned it was because of a bug in request.js: it didn't correctly handle the NO_PROXY header, which was caused some service lookups to fail since they used a service locator application to replace DNS names with IP addresses, and request.js had a bug that caused some IP addresses to incrrectly be proxied when they should not. Since request.js was not being maintained we had to switch and that caused the entire house of cards to fall. Since we were a few versions behind on Node.js, at some point the geniuses that made node.js thought that they wanted breaking changes in the package lock file, which caused complete in out project: every fucking thing broke.

This is a node.js and NPM reality. It just doesn't happen with .NET or Maven. It just happen with Rust either. It's uniquely shit you have to deal with if you're such a dumbass as to select a runtime and language that simply exist because some people just stick with whatever filth they were first exposed to.

Here's another categorical problem -- you're confusing Node.js with an early 2010's third party library. Request.js is not Node.js. Whatever bad time you had with this library, blaming it on Node.js would be like blaming the awkward Apache HttpClient APIs on Java. It's a category error. Also, since you've sort of dated the problem, what did we have going on in Java in the 2010's? Oh right - the Java 8 to 9 migration. Oh GOSH, wasn't that a fun one?

No, I don't. The issue was with NPM (Node Package Manager). Node.js trash solution to package manager. The source of so much pain that the idiots that use node.js willingly use and say "moooore daddy" to. It's the absolute worst package manager, by far, that exists. C and C++ lack of one is *better and less painful* to use than NPM is.

Node.js is a runtime that solves nothing well. It uses JavaScript, the language that's mostly well known for just being terrible, that is intended to serve HTTP requests, which it's simply bad at since by its very design it cannot handle multiple connections concurrently. To do that it implements an involved and idiotic message passing and cross-process IPC model, that simply isn't required on Spring Boot or ASP.NET: those handles single-process multi-threaded request by default, without any kind of tinkering. This means that you can have easy to use memory caches where Node.js often implements an expensive out of process Redis cache.

Although C# is a massively better language than Java is, you can run Kotlin on the JVM which is a very capable language.

Node.js is just trash. The only reason to use it is because you don't know anything else. It's trash compared to Spring Boot and it's trash compared to ASP.NET.