Easy and yet ...
...the author completely overlooks the problem of scale.
The problem is easy to express. Software development today typically makes use of packages from online repositories. A developer sits down to create a web application and starts by installing libraries from npm.js (more than 1 million JavaScript packages to choose from), Maven (for Java), NuGet (for .NET) or PyPI (for Python).
You can't objectively compare packages in NuGet with packages in npm. A typical NuGet dependency graph may go a few levels deep but it'll usually terminate there. A typical npm dependency graph can go between 10,000s and 100,000s of layers deep and pull in gigs of code. Its like comparing an itchy nose to being shot in the face with an elephant gun loaded for rhino. With proper frameworks like .NET or Java you can achieve an awful lot of work very quickly just using the vendors own packages, whereas with JavaScript you can't.
Secure computing is anathema to JavaScript, so if its on your list of requirements, then you simply can't use node - it would require a total redesign of npm and the JavaScript language specification before you could ever hope to make it secure as its all insecure by design.
How many times now has a node package gone stale because the maintainer has gone to jail? Died? Got bored? The damage is impossible to calculate and your ability to update a package for a known vuln depends on a maintainer often 100s or 1000s of packages deep doing some work first, and so on up the stack. JavaScript is a great language for teaching kids to code, but once you seek to be a professional you need to learn a professional language.
Biting the hand that feeds IT
