> Can anyone say with a straight face that getting a new JS dev caught up on what all these different parts to compile a JS program is a solved problem?

You are intermixing dependency management with build tools. Webpack and Babel have very little to do with dependency management.

I loosely included Babel and Webpack as part of dependency management since Python does not have a similar compile step. I don't think it is unfair since they fall into the same category of wtf when trying to get your dev environment working.

With that said, I should have included Yarn and Npm with their own problems. I can't remember how often I solved my dependency problems with rm -rf node_modules.

Python does have a compile step if your packages contain C extensions and aren't bundled into binary wheels. This shit tends to only work because of a whole lot of effort by package maintainers to make sure it compiles on a handful of supported systems, but if you aren't running such a system you get to debug a bunch of C dependency errors buried under a mile of gcc warnings and other make output.

One thing node.js got right is the module resolution logic.

Node doesn't even need something like venv since module lookup is always local.

Also no problem with dependency hell. Each dependency can have its own private dependencies, even different versions of dependencies shared by sibling modules. Tools like yarn/npm can remove duplicates across a project.

It's a lot more of a pressing concern when you have an average of 1,200 dependencies per project.

(I'm actually not sure if it is the average but my anecdotal experience is that it's an order of magnitude higher than python, and 1200 wouldn't be unusual).

That's probably quite accurate for front-end projects which pull in a ton of packages for 1. A compatibility layer wih older browsers. 2. Build tooling.

Node projects tend to have a lot smaller dependency graphs.

Yes we all learned that virtual envs are not the right way to do it. Node definitely got this portion right.

I wish Python can abandon virtual envs. This is the most annoying part of setting up a project.

How come other tools don't just replicate successful models?

That's very true. Starting fresh definitely helps.

I would not say JS solved it, but yarn (and even npm these days) seem to be superior to all python dependency management tools before pipenv. None of them had a proper lockfile, for example.

Agreed. I think pipenv had a really good start but sputtered. Poetry does look hopeful to solve the dependency resolution.

> As pioneers in dependency management

Maybe a noob question, but how come they are pioneers? Weren't there languages with package systems before Python and JS?

Actually no. As diegof79 pointed out, Perl was the first one with a centralized package management system with CPAN. Perl was first released in 1987. Python was first released in 1990. Javascript was first released in 1995. The internet was the launch pad for these open source languages, which allowed the sharing of code written in these languages.

Another thing to note is that dependencies were not that complex in the 90s. The idea of dependency management started when there was too many dependencies to manage and the existing tools could not reliably reproduce builds. My guess is that all these package use took off after the dotcom boom in 2000 and everyone started building websites with Ruby, Python and eventually Nodejs.

My first encounter with something like a package manager was CPAN for Perl... maybe they were the pioneers