npm has a feature that's broadly equivalent to virtualenvs, in that each directory is implicitly a virtualenv, and you use the packages installed in a given directory (or its ancestors). This is a bit less powerful than virtualenvs since it's tied to the directory structure, but in practice it ends up being really convenient for most use cases. Along those lines, there are also some cool affordances for managing dependencies – you can do e.g. "npm install --save <package>" to install a package and update the equivalent of setup.py with the new package, and it will automatically set that up with a semver range that matches the current stable release of that package.

That's actually not what I'm talking about, though, since ultimately those are just DX conveniences. The big difference is that, by default, npm installs dependencies in a nested rather than a flat manner. This means that you can install "library A" and "library B", which both depend on "library C", without worrying about potential incompatibilities between the required versions of "library C". This isn't possible in Python; one consequence is that you see a bunch of libraries that vendor their own small subsets of six to avoid having potential dependency issues – you don't get this in the Node ecosystem, because you can just pull in that dependency and not worry about potential version conflicts.

All of this adds up to a much nicer experience when developing libraries.