Whether you end up with a hellish dependency tree is more up to the developer than the language. I’d say the only reason this is more common in node projects than it is in other languages is because dependency management in other languages is more tedious, so the barrier for introducing new dependencies is higher.

All of my node projects have had rather tidy dependency trees. It’s also been quite easy for me to use popular packages. If something breaks and hundreds of thousands of devs are impacted by it, it’s going to get fixed pretty quick. Which has been my experience in the rare occasions that in of my dependencies has broken, it’s been fixed before it even had a chance to impact me.

Trust me, its the lack of standard library. Python and Java are both "batteries included" . You can write apps decently with just 5-10 dependencies if you want. Every JS app I've worked on has like 10-20X the dependencies of projects written in languages with a good standard lib

I'm currently learning Go and it's at the other end of the spectrum. Most of my apps have only one to three dependencies and one is usually a database driver. It's a really good feeling when there is something missing from the standard library and you questioning yourself that you really need that thing.

> Trust me, its the lack of standard library.

It's almost certainly not, as R has plenty of batteries, and young nitwits in the Hadleyverse are writing preposterous node-like dependency graphs. It's fashion, and it should be curb-stomped.

I don't see how R of all languages is a useful counterexample.

It's as far a way from a general-purpose language as it can get while technically still being one, in both scope and intended use/audience.

It's a useful counterexample because the problem didn't exist for the 20 years before legions of nodejs bros descended upon it and bestowed upon us the mess of hot garbage it is today. At this point, there is an entire half of the ecosystem which is unusable unless you drink the 400 dependency kool aide.

To be fair though, there isn't as much good introductory resources on base R, that aren't very discipline specific.

I do completely agree otherwise, but those people will learn through bitter, bitter experience that those dependencies will break over time and will see the light that is base R.

Totally agree, I'm currently learning Elixir and it has been such a delight to work with compared to Javascript. I'm writing a simple static site generator and I've not used any external libraries yet, because everything I've wanted to do thus far has been easy to build with the functions included in the standard library.

Choose “proven” technology, or “boring” tech as the original article calls it, applies here too. Popular libraries that are embedded in multiple language runtimes are written in C. SQLite comes to mind. Choose boring dependencies written with boring integration interfaces.

> at some point you will have a look into your myriad of nodejs dependencies and see with horror that they rely on C++ extension

This is a big selling point of the most boring languages of all, Java and C#. Performance is close enough to C, and FFI is painful enough, that its rare to see any native code in a project. Other languages that are slower or have better FFI have a much bigger risk of bitrot if you're going to keep a backend around for decades.

Where I work we deploy the exact same pre-built artifact to our Mac dev machines, Linux servers, and Windows QA guys. With Go, Python, JS, Ruby, etc we would have to have it built specifically for the platform. They all use enough native libraries that you can't share a zip file. And its a huge pain to cross-compile for anything except Linux.

If a NPM package requires a C++ compiler, I ignore it and move on.

V8 (and other Javascript JIT compilers) are written in C++. Whenever you think you run Javascript code, what you are actually running is C++ code that will emulate and compile your Javascript into machine code, update the DOM with C++ code, access sockets using C/C++ code etc. all running on an OS written in C/C++. Your code is a very small percentage of the code that runs "your" application. C/C++ runs the world. Including Javascript, Python, Java etc.

I do trust the C++ of V8 and NodeJS because it's used by many and well tested in the field.

I do not trust a random npm package with C++. C++ is way too level and insecure and it's not worth it.

Well, in my experience you cache those dependencies via something like jfrog. That helps. But yeah, dependencies require maintenance.