I think you've hit the nail on the head; npm was the real killer app - it makes it very easy to try out node and result in a real, usable app with very little code nor (visible) complexity.

npm is what pip could've been if wasn't mismanaged into oblivion.

> wasn't mismanaged into oblivion.

What's so "mismanaged" about pip? Honest question, I work with NPM every day but I've never really touched pip so all.

As someone who hasn't used npm beyond toy projects, what major features does it have that pip doesn't have?

Don't know nowadays, but a few years back when I was still using python something that drove me nuts from pip was how bad it was at managing transitive dependencies.

If package A depends on package B 1.0 and package C also depends on package B but 2.0, the order in which you run pip install for A or C will lead to a different version of B. And of course either A or V would break as soon as they hit an incompatibility. Obviously you would notice that only by running the application or tests.

So you have to use pip freeze to kind of generate a semi lock file,and every project uses it in a different way, because you also need different dependencies files for dev and production....and these are just plain TXT files which I don't think it is the best "format" for this.

Then you have these text files but also a "setup.py" which is for the package you produce, but hey you need to read the txt because otherwise you need to maintain them in two places. So you add a Makefile to tie all of this together, and that's another rabbit hole.

Add to this the mess of virtualenvs already explained in sibling comments and you have the perfect storm.

I know that nowadays are things such as Poetry, which work a lot better, but there are a good bunch of tools competing with each other.

To make an analogy, npm feels like using the latest, top of the line Macbook while pip feels like using a Casio calculator from 1985 with an external keyboard. That's the gap I feel between these two tools.

So if you ever use python, try first poetry or any of the other tools, pip is a terrible mess.

Installs in a local folder to the project (node_modules) instead of pip which installs packages to the global python installation unless ran in a virtual env. So getting anything up and running is trivial, compared to the amount of installations and steps needed with pip, unless you wanna bork your global python installation.

With npm it's also really easy (almost too easy) to take your current folder and push it to npm, making the ecosystem bloom with packages.

The virtual env thing is extra friction but isn’t terrible:

  $ python -m venv .venv
  $ source .venv/bin/activate
  $ pip install -r requirements.txt

Most IDEs will automatically pick up the .venv folder

Virtualenv used to be a third party package, which was a very high friction because you'll need to install it system-wide first (e.g. from distro's package manager) before you can use it to create virtual environments.

Not terrible, but still not as good and easy as npm. For example, you can't make a distinction between runtime and development dependencies, and it doesn't solve circular dependencies. Luckily there is Poetry which exactly does this.

I don't know what you're talking about—every time I have to do this I have no idea what I'm doing and I'm a senior engineer at FAANG.

I admit that I'm not a Python engineer, but I have been in the past—twice!

It's just a little switcheroo so that your shell environmental variables point to a project-local Python install rather than a global one.

It’s more of Python’s fault that pip’s, but (AFAICT) there isn’t a way to install multiple versions of the same dependency. You might have direct dependency A which needs version <2 of X, but also direct dependency B which needs version >=2 of X.

Since those version ranges of X don’t overlap, it isn’t possible to satisfy both A and B’s requirements. Node can handle this

I stand by the opinion that allowing multiple dependency versions was a major mistake that lead to both ballooning node_modules and abandoned packages getting caught up in your dependency tree just waiting for a malicious actor to hijack them.

In pip or composer, those dependencies have to be forked or removed or they will create conflicts.

Multiple dependency versions causes problems but the alternative is pretty bad, too. You can get stuck on older versions of a dependency because newer versions have a transitive dependency that causes a conflict with a different direct dependency

I feel like that's at least a solvable problem that makes itself obvious when the dependency is added. Multiple coexisting dependency versions sounds like a ticking time bomb to me.

Suppose I use a LibraryX that provides DataTypeX, and most of the functions in my project operate on DataTypeX. I later add another LibraryY, because it provides a utility function returning DataTypeX. I should be able to take the result and use it anywhere in my existing code. However, if my direct dependency on LibraryX is a different version than transitive dependency on LibraryX through LibraryY, then it may not have the same functionality. In trying to avoid a problem at compile-time, the package manager has introduced a huge potential problem at run-time.

Yarn lets you reject multiple versions.

Declarative dependency management. Every Node project has a package.json file, which is the first thing that I look at. It gives you so much information at a glance, and it allows for reproducible builds with just one command.

With pip you have to resort to hacky solutions like like pip freeze. It also doesn't solve circular dependencies. Luckily these days the Python world has Poetry, which exactly solves this issue, and might be even better than npm. Unfortunately it's third party and adoption is a bit slow, but I use it for all my projects.

Excuse me my snark comment, but npm doesn’t have a good story for dependency management either.

In 2010 it made it very easy to share libraries which helped Node grow in popularity. I don’t believe it was possible to do anything like this in Rhino without Java packages but I could be wrong. Certainly it wasn’t as easy as with npm.

Maybe it didn’t have package signing, lock files, or deduping, but clearly it was popular in spite of those faults.

There was Narwhal, which was on Rhino and had a package manager (CommonJS as well.) But it got overtaken by Node pretty quickly.

These days it’s cool to mock npm, but it was package management done right™ back then.

I hate all of them, use only when it’s almost inevitable, so I can’t really have an objective opinion.

Oh it was mocked back then too—mostly for the pre-npm@3 releases that didn't dedupe. If you thought node_modules was big today, imagine what it was like then.

Though it clearly worked well enough to be fantastically successful despite valid complaints about it.

Early npm would regularly create directory trees so deep Windows couldn't delete them, and I was just using it to pull down LESS and friends.

It’s the most successful one but okay.

Success has nothing to do with quality.

It's a good story though.

Why not?